Confused about some basic Netcode4GO concepts: server spawning and RTT delay

Hi,

I'm evaluating NC4GO for my game, which is a two person duel game (think of a first person FPS). How would I implement a player firing a bullet and collision detection? My understanding is:

1. One of the players in a 2p game will be Server, one will be the Client.
2. Client clicks mouse button to fire, RPC request to server must be sent to spawn a Bullet.
3. Server receives RPC, spawns Bullet locally, message sent back to Client.
4. Client spawns local copy of Bullet automatically but player perceives a latency.
5. Bullet trajectory is simulated on server (NetworkRigidBody or via updating a NetworkTransform manually).
6. Client receives transform updates over the network that drive Bullet motion.
7. Collision finally resolved on Server player's side.

This doesn't seem like it would work because of the perceived latency of 1-4.

Is there a pattern for spawning on a client and then replicating that in a synchronized manner without this initial round-trip?

For example, in e.g. Normcore, spawns occur locally and are then replicated to the other client. The spawner typically will retain ownership and the remote side will just interpolate the updates it periodically receives. The owner is the authority when a collision occurs (so if *I* fire a bullet and see it connect, it is counted, even if the other side thought they dodged). The reverse convention might be more suitable for a game like e.g. Blaston.

How would this be handled in Unity's NC4GO?

Thanks!

 

To solve this in a server-authoritative scenario, you'd need "predictive spawning", a features I believe NGO does not offer out of the box yet. You have to roll your own.

Predictive spawning means the client can spawn something right away, without waiting for the server response to the input. When the object spawns on the server, the server fast-forwards the object based on half the client's RTT (example: moving a projectile along its movement direction) so that the server projectile is more or less where the client is seeing it right now. When the client receives the server-side projectile, they destroy their "fake" projectile and fast forward the server projectile in the same way. It takes quite some work to make this look right (you need to do some interpolating to hide small discrepancies due to RTT being inaccurate), but the idea is using the fast forwarding to make the spawned projectile be displayed at the same real-time position on both client and server.

Usually it's not a good idea to trust the client to outright tell the server it hit something, but since this is a 2p game and one of the players is the server security is already limited anyway, so you can take the concept and modify it: do the fast forward on the server (so other players can at least get a more accurate view of where the projectile is) but have the server projectile be a harmless dummy, with the server waiting for the client to tell where it hit. Then have the server projectile be hidden in the client, so only their own projectile is visible.

 

Everything you wrote makes total sense but it does seem like fighting against the nature of the system. Is NGO not really intended for fast paced games like FPSes?

The second approach you mentioned could be workable initially.