Skip to content

Instantly share code, notes, and snippets.

@rcmagic
Last active August 5, 2023 17:01
Show Gist options
  • Star 1 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save rcmagic/27e80b9143a5ca7f172c9dd3a6a93589 to your computer and use it in GitHub Desktop.
Save rcmagic/27e80b9143a5ca7f172c9dd3a6a93589 to your computer and use it in GitHub Desktop.

Note: This is excerpt from a larger document and does not contain the introductory material required to fully understand all the concepts listed below.

Determinism

Now I wish to dive into the concept of determinism in our game. For us, determinism means that the game state is entirely determined by the behavior of the game tick.

Let's think carefully about what can effect the game tick's behavior. Let's assume that variables which make up the game state are used by our tick to make decisions which drive behavior. Just imagine a variable x which keeps track of the current position of a player. The game's code then may check to see if the player is walking into the side of the stage or not by reading the value stored in x. In this example, we can easily see how the game state influences the behavior of our tick. Can you think of anything else other than state which would influence our tick?

Take a situation where you want a character to perform a certain animation after sunset in the real world. In this case you might assume it would be a good idea to read the current time from the operating system. We know that the game state is entirely determined by the tick, which now will be influenced by the system clock. This is an external source of influence which will be difficult to keep track of and would not be consistent between instances of our game. It's true that the game is still deterministic in this case as the same time read would always produce the same state, but an essential quality we need for state synchronization over a network is to eliminate anything that can effect our tick which cannot easily be shared among instances of our game. So it's best to avoid designing game behavior which depends on the value of external systems.

For those familiar with physics, it may be easier to just think of our game as a closed system. This means that our game simulation itself must be the entire system. When reading from an external clock, we are adding a dependency to a system that is no longer part of our simulation. That system has its own state and its own behavior which we are not keeping track of in our game simulation. Reading from it would create a leak in our closed system making it open. An open system isn't useful for deterministic lock-step synchronization which we use for rollbacks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment