Hello folks

I have researched about State Synchronization in networked games, and couldn't find a material that could solve the specific requirements that I have, my goal through this discussion is to understand High Level how such an algorithm would work to accommodate my needs.

The game I'm working on is an Action/RPG built in a coop mode, I have logics such as: “Perks”, “Skills”, “Items” etc.

Currently I'm using an event-driven approach to sync the clients, whenever I get a command packet from the client I process it (without locks) and queue a task that will send the data to nearby players.

The above approach allows for race conditions between state modification - I think I should also queue up the task that modifies the state as well (what are your thoughts about this?)

And I wonder if shouldn't I create a “StateDelta” that contains all the modifications that have been performed during this tick, and then extract from it a matching “delta” for each player.

@hplus0603

hplus0603 said:
Send all inputs, and make simulation fully deterministic, and use some kind of lossless, pause-when losses-occur, kind of simulation. RTS-es do this – the classic Age of Empires article is a good case. The GGPO library for fighting games is another (which trades re-simulation for latency.)

If I understand this point correctly:

• Perform each state mutation in a deterministic fashion (make sure that no race condition can occur)
  • Would queuing the mutation tasks be considered a better practice than simply locking the mutation itself?
• “and use some kind of lossless, pause-when losses-occur, kind of simulation.” - Do you mean that the input packets themselves are stored and then during the next tick are processed and later sent?

hplus0603 said:
Send all outcomes (states) as they happen. Events only go from controlling client to the server. This has the benefit of trending towards eventual consistency even when you temporarily get something wrong. It has the draw-back that states can be pretty big, and various smart game-dependent compression approaches end up being useful.

Why does states have the chance to become big in this scenario?

For example:

• I sent a packet at tick X
• The server received it between X and X +1
• The server processed the packet and sent an output before X + 1

Does the above flow match the point you've mentioned?

hplus0603 said:
One of the ways of compressing, is to send events opportunistically, but occasionally baselining anyway (send a state snapshot every N seconds, where N might be smaller for people in the same group, or physically nearby, or who have seen in some sense “larger” changes, for example.)

This is the current method that I use, does it suffice for the “Action/RPG ”Coop (fast pace)?

Thanks for your input

@hplus0603

As always thanks for your knowledge, I'll dive deeper into the reference you've mentioned.