Anatomy of a Game: Changing the Gamestate

  • We have updated our Community Code of Conduct. Please read through the new rules for the forum that are an integral part of Paradox Interactive’s User Agreement.
The interface is only able to read the gamestate, and this is enforced by the code systems we have.

Out of curiosity, how do you enforce this? If another system wants to get data from the game state, can it just read that data directly? If so, assuming you're passing by reference, could the outside system then (inadvertently, perhaps) write directly into the game state?
 
  • 1
Reactions:
Out of curiosity, how do you enforce this? If another system wants to get data from the game state, can it just read that data directly? If so, assuming you're passing by reference, could the outside system then (inadvertently, perhaps) write directly into the game state?
The function to get write access to the game state is not compiled into the interface module, so through using the "proper" functions you cannot get write access to data unless you start const casting things at which point all bets are off and you should feel bad anyway.
So its super hard to do accidental writes to the game state from the interface module.
 
  • 2
Reactions:
The function to get write access to the game state is not compiled into the interface module, so through using the "proper" functions you cannot get write access to data unless you start const casting things at which point all bets are off and you should feel bad anyway.
So its super hard to do accidental writes to the game state from the interface module.

Interesting! If the interface wants to fetch and display some state variable (e.g. character gold, or something), what's the official way to get it? Does the state module expose safe getter functions that return read-only versions of the various parts of the game state?
 
Interesting! If the interface wants to fetch and display some state variable (e.g. character gold, or something), what's the official way to get it? Does the state module expose safe getter functions that return read-only versions of the various parts of the game state?
Yeah it uses the read only function to get a read only version of the game state so it can get read access to everything
 
  • 2
Reactions:
This is an amazing post!

I think I understand, but i think I have conflicts in my understanding.

1. There’s an initial phase during which all players are simultaneously deciding what to do for the next update, and it might include decisions which are made daily, monthly, yearly, whatever. This phase also includes updating UI. It’s a read-only phase.
2. The next phase allows actions that alter the game state to be carried out. Actions which are no longer valid are skipped.

During phase 1, if there’s an action that impacts game state that’s only visible to the one character, then it gets triggered immediately instead of getting added to the queue which is executed during phase 2. Do I have that right?

thanks again, really insightful post!