   Sequencing "simultaneous" events.
  I'm trying to decide how best to handle a few scenarios regarding server events. The game in question is a top-down 2D game over tcp with around 5 ticks per second.Typical example of how it works now:1. Someone fires a weapon at an enemy which hits for X damage. Server generates an appropriate weapons fire event.2. If the damage kills the target, the server generates a "target killed" event.3. Maybe the death of the target creates a drop. Server generates a "drop spawned" event.All of these three events happen sequentially during the same tick and will arrive at the client in the same message frame (the order is preserved, though).This works fine, but client side the illusion is a little broken, because currently the client doesn't know the events were causally related. It starts the firing anim, target explode anim, and spawns the drop all at the same time, which looks off, because they really should play out in sequence.How would you solve this problem?   
  Play the firing animation as soon as the fire key is pressed (on the client), play the explode animation when the server returns the event and create a clientside timer to spawn the drop approximately when the explosion animation has played thru.   ;  Including sequencing information in the pulse packet. This may be as simple as "time since start of pulse" for each event.   ;  Sounds like we're working on very similar games.For weapon firing, the server sends a message that looks like this:[Firing Ship ID].[Target ship ID].[weaponID].[Damage Amount].[Target Died Flag].[Drop Item ID]The clients know how to draw each type of weapon fire and how to draw the resulting explosion from each type of weapon when it hits.  There is an additional explosion and potential loot drop when the target ship is destroyed.  When damage is 0, this indicates a miss.This weapon fire string is tacked onto the end of our update string that gets sent every xx ms.;  I think I've decided to go with a system where the server doesn't need to know anything about event causality. Instead, the client will generate the effects and attach them to entities. It will be the entity's responsibility to realize, "oh I'm dying now? I'll get right on that after I'm done being shot."@nate, yes looking at your recent posting history it looks like both our projects are very much in the same genre. :)   ;  If you play that game on the Internet with regular PCs, someone will figure out how to send the "you died" message whenever they wish. The server really has to be the arbiter of game state.   ;Quote:Original post by hplus0603If you play that game on the Internet with regular PCs, someone will figure out how to send the "you died" message whenever they wish. The server really has to be the arbiter of game state.The server is authoritative on everything and all messages are generated by it. When I said the server doesn't need to know anything about event causality, I meant it doesn't need to keep track of causation with respect to events.I.e.:Server handles a weapon being fired, dispatches weapon fire event.Server handles an entity being destroyed, dispatches entity destroyed event.The entity destroyed event doesn't carry information about specifically which weapon event caused it.   ;  Hey Kevin,IMO that's not an efficient way to handle it.  I'm sure it's elegant code, but the resulting message structure I think is too inefficient.I view a weapon fire and the result of it as an atomic event.  At the instant the weapon is fired, the server knows if it hit or missed.  The server also knows when hit if the result of the hit was the ship being destroyed, and if so, what loot to drop.  I really don't think you can afford to be firing off events for this on the server and then sending discrete data off to the clients.Even if we assume the server-side performance loss is acceptable for the sake of your elegant encapsulated and highly decoupled weapon system, ship, loot manager, I think unless you have a smart way to package up all those messages to the client, you're going to be killing your bandwidth with extraneous data/messages.Most efficient message structure for ship firing weapon is going to be something along of the lines of firingShipID,targetShipID,weaponType,damage,lootI think you're saying you're going to have discrete messages for each action:firingShipID,targetShipID,weaponTypetargetShipID,damagetargetShipID,dropLoottargetShipID,destroyFlagand then on the client you're going to write the logic to intelligently put these discrete pieces back together to again communicate what is really one atomic action ... firingShip attacks targetShip using this weapon and casuing x damage [which may have destroyed the target] and caused a loot drop.I'm sure what is "right" depends on where you're system is constrained and also exactly how the client needs to display this visually.  Do you have different types of weapons?  Is a weapon hit explosion different from a ship destroy explosion? Can loot be seen and picked up by all players or only a specific player?  etc., etc. For me, limiting bandwidth consumption is the top priority and so the integrated message is the only option.;Quote:Original post by NateDogHey Kevin,IMO that's not an efficient way to handle it.  I'm sure it's elegant code, but the resulting message structure I think is too inefficient.I view a weapon fire and the result of it as an atomic event.  At the instant the weapon is fired, the server knows if it hit or missed.  The server also knows when hit if the result of the hit was the ship being destroyed, and if so, what loot to drop.  I really don't think you can afford to be firing off events for this on the server and then sending discrete data off to the clients.Even if we assume the server-side performance loss is acceptable for the sake of your elegant encapsulated and highly decoupled weapon system, ship, loot manager, I think unless you have a smart way to package up all those messages to the client, you're going to be killing your bandwidth with extraneous data/messages.Most efficient message structure for ship firing weapon is going to be something along of the lines of firingShipID,targetShipID,weaponType,damage,lootI think you're saying you're going to have discrete messages for each action:firingShipID,targetShipID,weaponTypetargetShipID,damagetargetShipID,dropLoottargetShipID,destroyFlagand then on the client you're going to write the logic to intelligently put these discrete pieces back together to again communicate what is really one atomic action ... firingShip attacks targetShip using this weapon and casuing x damage [which may have destroyed the target] and caused a loot drop.I'm sure what is "right" depends on where you're system is constrained and also exactly how the client needs to display this visually.  Do you have different types of weapons?  Is a weapon hit explosion different from a ship destroy explosion? Can loot be seen and picked up by all players or only a specific player?  etc., etc. For me, limiting bandwidth consumption is the top priority and so the integrated message is the only option.I'm concerned about bandwidth, but not in this context. Entity deaths and drops are "rare" events and not particularly bandwidth heavy. For example, an entity death message is I think about 4 bytes (1 byte for the message type, 1 byte for the event type, and 2 bytes for the entity id).   ;  That's a good point on the deaths.  Depending on game, probably not such a frequent event as to make a big impact on performance.  Weapon firing depending on game could be the bigger issue.  In our game there's a fairly high frequency of weapon firing.  Though still, a fraction of the overhead of the general update string.   