Skip to main content

Game State

The game state represents (as the name implies) the state of a game at a given time. During a new game creation, each game will receive the initial game state. After that point, any changes to the game will be applied using game events. This means the latest game state is always the result of the initial game state and all the game events that have been applied to it.

Biased game state​

Biased game state, describes the game state which a player receives as part of a game he is participating. It is called a biased game state (maybe not fully accurate naming ;)), because it only contains the information known to the player. For example, the cards, which the player does not know yet, are anonymized.

Type definition is as follows:

interface BiasedGameState extends Omit<GameState, 'cards'> {
	/** all available cards in the game, not all of them are visible */
	cards: Record<string, GameCard | GameCardUnknown>;
}

The gameUpdate S2C event on the game socket namespace is the channel on which the server sends the updates to the players.

The game queue is responsible for emitting these updates after a game event has been pushed (see in the code).

In the Front-end the WS subscription to that event will update a svelte store when any changes are received.

Mutable game state​

Mutable game state is referring to the game state that the game queue creates and passes to game task which is intended to be mutated by any changes caused from any given game task.

What happens once a game task has been executed successfully, is that the game queue will take the mutated game state and compare it to the previous game state. Any changes that were made are then converted to a just diff diff.
This diff is what a game event resembles. getGameState will do the reverse. Apply the previously generated diffs using just-diff-apply to get the latest game state.

<code references>​

General:

Front-End UI: