Sign in to follow this  
sufficientreason

Sending Messages for Entity Creation/Deletion vs. State Updates

Recommended Posts

I have a simple question that's been nagging at me for awhile, since there are a number of ways to handle it. I'm writing a little fast-action 2D shooter game following a traditional FPS networking model, with the following few message types. I'm using a reliability layer on top of UDP (lidgren-gen3), so in particular I'm trying to figure out how to pass various kinds of messages.

[b]Cosmetic Effects[/b] (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.

[b]Entity State Updates[/b] ("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.

[b]Game State Updates[/b] ("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!

Share this post


Link to post
Share on other sites
hplus0603    11356
Best practice is to only send game inputs, and simulate in parallel on all clients :-) But for state replication, best practice is to send important messages (create, delete) using some reliable or semi-reliable mechanism.

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.)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this