Members - Reputation: 194
Posted 07 June 2012 - 01:07 PM
Cosmetic Effects (Position-related Explosions, Sounds, etc.)
These are straightforward. Server says, "put an explosion here", and the client does it (with no context, we don't say "put an explosion here because Player A died"). These aren't crucial, so they can be sent unreliably.
Entity State Updates ("Player A's position is now (x, y)")
These are also straightforward. I buffer these by 100ms for interpolation as per the Valve model. These won't necessarily be sent every server tick though -- lower-priority entities won't necessarily get lots of updates, so there will be times where the client doesn't hear about an entity for awhile and has to extrapolate. We'll be sending lots of these, so we can afford to lose some. We'll send these unreliably.
Game State Updates ("Player A's score is now N", "Player A killed Player B", "Player C joined the game")
These are pretty important and infrequent, so we'll send these reliably and ordered.
Now, the problem here is with entity state updates. In particular, knowing when a new entity is created or an existing entity dies. If we don't hear about an entity for awhile, that doesn't necessarily mean it's dead. I'd like to send entity state updates unreliably, but what about changes to their existence? Should I reliably send entity creation/deletion events? If I'm firing lots of rockets, isn't that costly? The other option is to send the state of every entity every tick, and then if the client doesn't hear about that entity when it gets the next update, it can infer that the entity is dead. This is clean, but doesn't allow me to prioritize entities differently for different update frequencies.
What's the best practice here? Thanks!
Moderators - Reputation: 10320
Posted 07 June 2012 - 06:06 PM
I'm going to assume that you pack many messages into a single packet, and actually send packets on some fixed schedule. This is a best practice in itself!
For example, you can put entity delete into every third network packet, until you get back an acknowledge for a packet that the entity delete message was in.
Note that packet acknowledge really doesn't add any overhead, and is not the same thing as a reliable system. You simply number each packet with an incrementing number, and send the packet number as part of the packet. You only need to send the lowest 8 bits or so. As another part of the packet, you also send the lowest 8 bits of the last packets you received from the other end, plus perhaps a bitmask of another 8 packet ids for the packets before that (bit N set means that packet <last>-N was received.)