Jump to content

View more

Image of the Day

Boxes as reward for our ranking mode. ヾ(☆▽☆)
#indiedev #gamedev #gameart #screenshotsaturday https://t.co/ALF1InmM7K
IOTD | Top Screenshots

The latest, straight to your Inbox.

Subscribe to GameDev.net Direct to receive the latest updates and exclusive content.

Sign up now

Sending Messages for Entity Creation/Deletion vs. State Updates

4: Adsense

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
1 reply to this topic

#1 sufficientreason   Members   


Posted 07 June 2012 - 01:07 PM

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.

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!

#2 hplus0603   Moderators   


Posted 07 June 2012 - 06:06 PM

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

enum Bool { True, False, FileNotFound };

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.