Extensibility (NxN board, multiple players) in LLD - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Architecture

intermediate

Designing a scalable NxN board for multiple players

You are tasked with designing the architecture for a game that supports an NxN board and multiple players. Which architectural component is MOST important to ensure the system can easily scale to larger boards and more players?

A A monolithic service that handles all game logic and player interactions synchronously.

B A centralized game state manager that holds the entire board and player states in memory.

C A fixed-size board array with hardcoded player slots to optimize performance.

D A modular board component that dynamically allocates cells and supports variable dimensions with event-driven updates.

💡 Hint

Think about flexibility and how the system can adapt to different board sizes and player counts without major rewrites.

Option D is correct because a modular board component that dynamically allocates cells and supports variable dimensions allows easy extensibility for any NxN size and multiple players. It also supports event-driven updates which help in scaling and responsiveness.

Option D centralizes state which can become a bottleneck. Option D is inflexible due to fixed size and hardcoded players. Option D's monolithic synchronous design limits scalability and extensibility.

❓ scaling

intermediate

Handling player actions in a multi-player NxN board game

In a multi-player NxN board game, what is the BEST approach to handle concurrent player actions to maintain consistency and responsiveness?

A Ignore conflicts and let the last action overwrite previous ones.

B Use optimistic concurrency control with versioning and conflict resolution on the game state.

C Lock the entire board for each player action to ensure no conflicts occur.

D Process all player actions sequentially in a single thread to avoid conflicts.

💡 Hint

Consider how to allow multiple players to act simultaneously without blocking or losing data.

Option B is correct because optimistic concurrency control allows multiple players to act concurrently while detecting conflicts and resolving them gracefully. This maintains consistency and responsiveness.

Option B is slow and reduces responsiveness. Option B causes heavy locking and poor scalability. Option B leads to inconsistent game states.

❓ tradeoff

advanced

Tradeoffs in storing NxN board state for multiple players

Which storage approach balances performance and extensibility best for saving the state of an NxN board game with multiple players?

A Store only player moves as events in an append-only log and reconstruct board state on demand.

B Store the entire board state as a single JSON blob in a relational database.

C Store each cell's state as a separate record with player references in a NoSQL database.

D Store board state in memory only and persist snapshots periodically to disk.

💡 Hint

Think about how to efficiently save changes and allow flexible replay or rollback.

Option A is correct because event sourcing (storing moves as events) allows efficient storage, easy extensibility, and the ability to reconstruct any board state by replaying events. It supports multiple players and large boards well.

Option A is inefficient for large boards. Option A can cause overhead and complexity. Option A risks data loss and is less reliable.

🧠 Conceptual

advanced

Extending game rules for multiple players on NxN board

When extending a two-player NxN board game to support multiple players with different win conditions, which design principle is MOST important?

A Hardcode all possible win conditions in the main game logic for quick access.

B Allow only one universal win condition to simplify the game rules.

C Use a strategy pattern to encapsulate different win condition algorithms and select dynamically.

D Implement win conditions as global variables accessible by all components.

💡 Hint

Consider how to add or change rules without modifying core logic.

Option C is correct because the strategy pattern allows encapsulating different win conditions as interchangeable algorithms. This supports extensibility and clean separation of concerns.

Option C is inflexible and hard to maintain. Option C limits game variety. Option C leads to poor design and tight coupling.

❓ estimation

expert

Estimating capacity for a multi-player NxN board game service

You are designing a cloud service to support a multi-player NxN board game. Each game has up to 10 players and a board size up to 100x100. Estimate the approximate memory needed to hold 10,000 concurrent games in memory, assuming each cell stores 1 byte and each player state requires 1 KB.

A Approximately 1 GB

B Approximately 100 GB

C Approximately 10 GB

D Approximately 500 MB

💡 Hint

Calculate memory per game first, then multiply by number of games.

Each board has 100x100 = 10,000 cells, each 1 byte = 10 KB. Each player state is 1 KB, for 10 players = 10 KB. Total per game = 10 KB + 10 KB = 20 KB.

For 10,000 games: 20 KB * 10,000 = 200,000 KB = ~195 MB. Considering overhead and metadata, approximately 1 GB is a reasonable estimate.

Option A is closest to this estimation.

Practice

1. What is the main benefit of designing a game system with an NxN board and support for multiple players?

easy

A. It allows the game to be easily extended to different board sizes and more players without major code changes.

B. It limits the game to only two players and a fixed board size.

C. It makes the game run faster by using fixed-size arrays only.

D. It removes the need for input validation.

Solution

1. Step 1: Understand extensibility in game design

   Extensibility means the system can grow or change easily without rewriting code.

2. Step 2: Apply extensibility to NxN board and multiple players

   Using flexible data structures and modular code allows changing board size and player count easily.

3. Final Answer:

   It allows the game to be easily extended to different board sizes and more players without major code changes. -> Option A

4. Quick Check:

   Extensibility = Easy growth [OK]

Hint: Extensibility means easy to add features later [OK]

Common Mistakes:

• Thinking fixed size is more extensible
• Ignoring input validation importance
• Assuming extensibility means faster code

2. Which of the following code snippets correctly initializes a flexible NxN board in Python for any given size n?

easy

A. board = [[0]*n]*n

B. board = [[0 for _ in range(n)] for _ in range(n)]

C. board = [0]*n

D. board = [0 for _ in range(n)]

Solution

1. Step 1: Understand list initialization for 2D board

   Using list comprehension creates independent inner lists for each row.

2. Step 2: Compare options for correct 2D board creation

   board = [[0 for _ in range(n)] for _ in range(n)] creates a list of lists with separate inner lists, avoiding shared references.

3. Final Answer:

   board = [[0 for _ in range(n)] for _ in range(n)] -> Option B

4. Quick Check:

   Independent rows = board = [[0 for _ in range(n)] for _ in range(n)] [OK]

Hint: Use nested list comprehensions for independent 2D lists [OK]

Common Mistakes:

• Using [[0]*n]*n causes shared inner lists
• Initializing only 1D list for 2D board
• Confusing list multiplication with comprehension

3. Given a game system supporting multiple players, what will be the output of this Python snippet?

players = ['Alice', 'Bob', 'Carol']
turns = 5
for i in range(turns):
    current = players[i % len(players)]
    print(current)

medium

A. Bob Carol Alice Bob Carol

B. Alice Bob Carol Carol Carol

C. Alice Alice Alice Alice Alice

D. Alice Bob Carol Alice Bob

Solution

1. Step 1: Understand modulo for cycling players

   The modulo operator cycles index through player list length (3).

2. Step 2: Trace each iteration's player

   i=0 -> Alice, i=1 -> Bob, i=2 -> Carol, i=3 -> Alice, i=4 -> Bob.

3. Final Answer:

   Alice Bob Carol Alice Bob -> Option D

4. Quick Check:

   Modulo cycles players = Alice Bob Carol Alice Bob [OK]

Hint: Use modulo to cycle through players repeatedly [OK]

Common Mistakes:

• Not using modulo causes index errors
• Assuming players list is longer than turns
• Confusing player order in output

4. Identify the bug in this code snippet for initializing a variable-sized board and multiple players:

def setup_game(n, players):
    board = [[None]*n]*n
    for p in players:
        print(f"Player: {p}")
    return board

setup_game(3, ['A', 'B'])

medium

A. The board rows are references to the same list, causing shared updates.

B. The players list is not printed correctly.

C. The function does not return anything.

D. The board size is fixed to 3 regardless of input.

Solution

1. Step 1: Analyze board initialization

   Using [[None]*n]*n creates rows that reference the same list object.

2. Step 2: Understand impact of shared references

   Changing one cell affects all rows because they share the same inner list.

3. Final Answer:

   The board rows are references to the same list, causing shared updates. -> Option A

4. Quick Check:

   Shared inner lists cause bugs = The board rows are references to the same list, causing shared updates. [OK]

Hint: Avoid list multiplication for nested lists [OK]

Common Mistakes:

• Ignoring shared reference problem
• Thinking players print is incorrect
• Assuming function returns nothing

5. You are designing a turn-based game with an NxN board and support for multiple players. Which design approach best supports easy extensibility for future features like variable board sizes, more players, and custom rules?

hard

A. Write all game logic in one large function for simplicity.

B. Use fixed-size arrays and hardcoded player count with separate functions for each board size.

C. Use flexible data structures (lists/dictionaries), modular functions, and validate inputs dynamically.

D. Use global variables for board and players to avoid passing parameters.

Solution

1. Step 1: Identify extensibility requirements

   Extensibility needs flexible data structures and modular code to adapt easily.

2. Step 2: Evaluate design options

   Use flexible data structures (lists/dictionaries), modular functions, and validate inputs dynamically. uses lists/dictionaries and modular functions with input validation, supporting future changes well.

3. Final Answer:

   Use flexible data structures (lists/dictionaries), modular functions, and validate inputs dynamically. -> Option C

4. Quick Check:

   Modular + flexible data = extensible design [OK]

Hint: Modular code + flexible data = easy extensibility [OK]

Common Mistakes:

• Using fixed sizes limits future changes
• Writing monolithic functions reduces flexibility
• Using globals causes maintenance issues