Game state management in LLD - System Design Exercise

Design: Game State Management System

Focus on the core game state management logic and synchronization. Out of scope are graphics rendering, network transport protocols, and user interface design.

Functional Requirements

FR1: Maintain the current state of the game including player positions, scores, and game objects.

FR2: Support multiple players interacting in real-time.

FR3: Allow saving and loading game states.

FR4: Ensure consistency of game state across different clients.

FR5: Handle state updates efficiently to minimize latency.

FR6: Support rollback or undo of recent actions for error correction.

Non-Functional Requirements

NFR1: Support up to 100 concurrent players in a single game session.

NFR2: State update latency should be under 100ms for real-time responsiveness.

NFR3: Availability target of 99.5% uptime during game sessions.

NFR4: Memory usage should be optimized to run on typical gaming devices.

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

❓ Question 6

Key Components

Game state store (in-memory or persistent)

State synchronization module

Conflict resolution mechanism

Save/load manager

Event queue or command pattern for state changes

Design Patterns

Command pattern for encapsulating state changes

Observer pattern for notifying clients of state updates

Snapshot and delta updates for efficient state transfer

Event sourcing for replaying and rollback

Locking or optimistic concurrency control for conflict handling

Reference Architecture

          +---------------------+
          |   Game Clients      |
          | (Players' devices)  |
          +----------+----------+
                     |
                     | WebSocket / TCP
                     v
          +---------------------+
          | State Synchronizer   |
          | (Handles updates,   |
          |  conflicts, pushes) |
          +----------+----------+
                     |
          +----------v----------+
          |  Game State Store    |
          | (In-memory database) |
          +----------+----------+
                     |
          +----------v----------+
          | Save/Load Manager    |
          | (Persistence layer)  |
          +---------------------+

Components

Game Clients

Any platform (mobile, desktop)

Send player actions and receive game state updates

State Synchronizer

Server-side module

Receive player actions, apply them to game state, resolve conflicts, and broadcast updates

Game State Store

In-memory data structure or database

Hold the current game state for fast access and updates

Save/Load Manager

Persistent storage (file system or database)

Save snapshots of game state and load them on demand

Request Flow

1. 1. Player sends an action (e.g., move, attack) from client to State Synchronizer.

2. 2. State Synchronizer validates and applies the action to the Game State Store.

3. 3. If conflicts arise, State Synchronizer resolves them using optimistic concurrency or locking.

4. 4. State Synchronizer broadcasts the updated state or delta changes to all connected clients.

5. 5. Clients update their local view of the game state accordingly.

6. 6. Periodically or on demand, Save/Load Manager saves the current state snapshot.

7. 7. When loading, Save/Load Manager restores the state to Game State Store.

Database Schema

Entities: - Player: id, name, score, position - GameObject: id, type, position, state - GameStateSnapshot: id, timestamp, serialized_state Relationships: - Player interacts with GameObjects - GameStateSnapshot stores full serialized game state for rollback and loading

Scaling Discussion

Bottlenecks

State Synchronizer becomes a bottleneck with many concurrent updates.

Game State Store memory limits with large game states or many players.

Network bandwidth limits for broadcasting frequent updates.

Save/Load operations causing latency spikes.

Solutions

Partition game sessions across multiple State Synchronizer instances (sharding).

Use delta updates and compression to reduce network load.

Implement hierarchical state synchronization (local and global states).

Use asynchronous save/load with snapshotting to avoid blocking.

Employ caching and memory optimization techniques for Game State Store.

Interview Tips

Time: Spend 10 minutes clarifying requirements and constraints, 20 minutes designing the architecture and data flow, and 15 minutes discussing scaling and trade-offs.

Explain how you maintain consistency and low latency in state updates.

Discuss conflict resolution strategies for concurrent player actions.

Describe how saving and loading game states works.

Highlight how your design supports scalability and fault tolerance.

Mention patterns used like command and observer for clean design.

Practice

1. What is the main purpose of game state management in a video game?

easy

A. To handle the sound effects and music

B. To keep track of what is happening in the game and control transitions between different screens or modes

C. To improve the graphics quality of the game

D. To manage the player's score only

Solution

1. Step 1: Understand the role of game state management

   Game state management is about tracking the current status of the game, such as menus, playing, or paused states.

2. Step 2: Identify the correct purpose

   It controls how the game moves between these states and keeps the game organized and less buggy.

3. Final Answer:

   To keep track of what is happening in the game and control transitions between different screens or modes -> Option B

4. Quick Check:

   Game state management = Track and control game modes [OK]

Hint: Game state manages screens and modes, not graphics or sound [OK]

Common Mistakes:

• Confusing game state with graphics or sound management
• Thinking it only manages scores
• Assuming it handles player input directly

2. Which of the following is the correct way to represent a simple game state using an enum in a low-level design?

easy

A. enum GameState { MENU, PLAYING, PAUSED, GAME_OVER }

B. class GameState { int MENU = 1; int PLAYING = 2; int PAUSED = 3; int GAME_OVER = 4; }

C. var GameState = ['MENU', 'PLAYING', 'PAUSED', 'GAME_OVER']

D. GameState = { MENU: 1, PLAYING: 2, PAUSED: 3, GAME_OVER: 4 }

Solution

1. Step 1: Identify enum syntax for game states

   Enums are used to define a fixed set of named constants, perfect for game states.

2. Step 2: Check which option uses enum correctly

   enum GameState { MENU, PLAYING, PAUSED, GAME_OVER } uses enum syntax correctly to define game states clearly and safely.

3. Final Answer:

   enum GameState { MENU, PLAYING, PAUSED, GAME_OVER } -> Option A

4. Quick Check:

   Enum syntax for states = enum GameState { MENU, PLAYING, PAUSED, GAME_OVER } [OK]

Hint: Enums clearly name fixed states, use enum keyword [OK]

Common Mistakes:

• Using arrays or objects instead of enums for fixed states
• Defining states as class variables without enum
• Mixing syntax from different languages

3. Given this pseudocode for a game state manager, what will be the output after calling changeState('PAUSED') twice?

class GameStateManager:
  def __init__(self):
    self.state = 'MENU'
  def changeState(self, new_state):
    if self.state != new_state:
      self.state = new_state
      print(f'State changed to {self.state}')
    else:
      print(f'State already {self.state}')

manager = GameStateManager()
manager.changeState('PAUSED')
manager.changeState('PAUSED')

medium

A. State already PAUSED
State already PAUSED

B. State changed to PAUSED
State changed to PAUSED

C. State changed to PAUSED
State already PAUSED

D. State changed to MENU
State changed to PAUSED

Solution

1. Step 1: Analyze first changeState call

   Initial state is 'MENU'. Changing to 'PAUSED' triggers state change and prints 'State changed to PAUSED'.

2. Step 2: Analyze second changeState call

   State is already 'PAUSED', so it prints 'State already PAUSED' without changing.

3. Final Answer:

   State changed to PAUSED State already PAUSED -> Option C

4. Quick Check:

   Second call same state = no change message [OK]

Hint: Second same state call prints 'already' message [OK]

Common Mistakes:

• Assuming state changes again on same value
• Ignoring else branch output
• Confusing initial state with changed state

4. In the following code snippet, what is the main bug that can cause incorrect game state transitions?

class GameStateManager:
  def __init__(self):
    self.state = 'MENU'
  def changeState(self, new_state):
    if self.state == new_state:
      self.state = new_state
      print(f'State changed to {self.state}')
    else:
      print(f'State already {self.state}')

medium

A. The method does not accept new_state parameter

B. The print statements are swapped

C. The initial state is not set properly

D. The condition is reversed; it changes state only if states are equal

Solution

1. Step 1: Review the if condition logic

   The code changes state only if current state equals new_state, which is wrong because state should change when states differ.

2. Step 2: Identify correct condition

   The condition should be if current state != new_state to update state and print change message.

3. Final Answer:

   The condition is reversed; it changes state only if states are equal -> Option D

4. Quick Check:

   State change condition reversed = bug [OK]

Hint: Check if condition matches when states differ, not equal [OK]

Common Mistakes:

• Not noticing reversed if condition
• Assuming print statements cause bug
• Ignoring initial state setup

5. You are designing a multiplayer game with complex states like LOBBY, MATCHMAKING, IN_GAME, PAUSED, and GAME_OVER. Which approach best supports scalability and easy state transitions for many players?

hard

A. Use a centralized state manager with a state machine pattern and event-driven updates per player

B. Store each player's state in a simple variable and update it directly without structure

C. Use global variables for all states and check them in every game loop iteration

D. Hardcode state transitions inside each player's input handler

Solution

1. Step 1: Understand scalability needs

   Many players and complex states require organized, scalable management to avoid bugs and support concurrency.

2. Step 2: Evaluate approaches

   A centralized state manager using a state machine and event-driven updates cleanly handles transitions and scales well.

3. Final Answer:

   Use a centralized state manager with a state machine pattern and event-driven updates per player -> Option A

4. Quick Check:

   Centralized state machine + events = scalable design [OK]

Hint: Centralized state machine with events scales best [OK]

Common Mistakes:

• Using global variables causing race conditions
• Hardcoding transitions making maintenance hard
• No structure causing bugs with many players