0
\$\begingroup\$

Soon I'll have to start implementing networking for a game. To be able to simulate the game on both client and server and have no deviation, simulations need to be deterministic.

But how can any simulation be deterministic and produce the same output, if it is run on different hardware? (which implies execution of instructions at a different pace).

Should we treat server and client state as "approximately equal" opposed to equal and not correct the client when states are a little different? I missing something and deterministic simulation is possible?

\$\endgroup\$

1 Answer 1

2
\$\begingroup\$

The problem with determinism in multiplayer games is not just that people use different hardware, but also that due to network latency the order in which events happen is not always the same for each player. For example, in a fast-paced shooter with high latency it is pretty common that two players will both believe that they shot the other player first.

A common solution is to have an authoritative server. Authoritative server means that the servers simulation of the game is always right. Clients might use their own simulation to extrapolate the game to provide a more fluent game experience to the player. But when it turns out that client and server disagree, then the client has to correct accordingly. That can result in phenomenons like "rubber banding": The player under fire sprints into cover and sees their character reach it. But then the game moves them back a couple meters and kills them. That's because the server says someone killed them while they were on the run, but due to latency the client didn't know it yet.

Yes, this can be frustrating for the players. But authoritative servers are really the only practical way to make a fast-paced multiplayer game fair. Because without authoritative servers, it becomes really easy to develop cheats.


However if your game is very slow-paced, for example a turn-based strategy game with concurrent moves, then there is another option: Using a network protocol that's based on a fixed lockstep.

  1. Every player makes their move but does not yet update their simulation
  2. The clients exchange each others moves (which might or might not require a server, but using a server would probably make a lot of things a lot easier)
  3. When every client knows the moves of all other players, they update their simulation according to a deterministic algorithm.

Note that this algorithm must include rules for how to resolve player moves that contradict each other. For example, when two players move into the same tile, but the game rules say only one player is allowed there, then there must be a rule to resolve that tie which does not just rely on who clicked first (because that's impossible to determine). What could that rule be? That's a game design question, not a technical one.

The problem with this method is that it is slow. At least one full network roundtrip. That makes it infeasible for fast-paced action games.

\$\endgroup\$
1

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .