Extensibility (NxN board, multiple players) in LLD - System Design Guide

Problem Statement

Hardcoding a fixed board size and a fixed number of players makes the game rigid. When you want to change the board size or add more players, you must rewrite large parts of the code, causing bugs and slowing development.

Solution

Design the game logic to accept any board size and any number of players as parameters. Use flexible data structures and loops that adapt to these parameters, so the game can easily scale without code changes.

Architecture

Game Engine

(Game Logic)

→Board Manager

↓

Input

Handler

This diagram shows the game engine coordinating between a flexible NxN board manager and a player manager that supports multiple players. Inputs flow into the game engine, which updates board and player states accordingly.

Trade-offs

✓ Pros

→

Allows easy changes to board size without rewriting core logic.

→

Supports any number of players, enabling new game modes.

→

Improves code maintainability by separating concerns.

→

Facilitates testing different configurations quickly.

✗ Cons

→

More complex code due to abstraction layers.

→

Slight performance overhead from dynamic data structures.

→

Requires careful design to handle edge cases for large boards or many players.

Use when the game needs to support variable board sizes (e.g., 3x3 to 10x10) and multiple players (more than 2), or when future extensions are expected.

Avoid if the game is simple, fixed-size (e.g., always 3x3), and single-player only, where added complexity is unnecessary.

Real World Examples

Google

Google's Tic-Tac-Toe demo supports variable board sizes and multiple players to demonstrate flexible game design.

Discord

Discord bots for games like Connect Four allow users to customize board size and player count dynamically.

Amazon

Amazon's Alexa games support multiple players and variable board sizes to enhance user engagement.

Code Example

The before code fixes the board size to 3x3 and supports only two players. The after code accepts any board size and a list of players, updating the current player in a round-robin fashion. This makes the game flexible and extensible.

LLD

### Before: Fixed 3x3 board and 2 players
class Game:
    def __init__(self):
        self.board = [[None]*3 for _ in range(3)]
        self.players = ['X', 'O']
        self.current_player = 0

    def make_move(self, row, col):
        if self.board[row][col] is None:
            self.board[row][col] = self.players[self.current_player]
            self.current_player = 1 - self.current_player

### After: Extensible NxN board and multiple players
class Game:
    def __init__(self, size=3, players=None):
        if players is None:
            players = ['X', 'O']
        self.size = size
        self.board = [[None]*size for _ in range(size)]
        self.players = players
        self.current_player = 0

    def make_move(self, row, col):
        if 0 <= row < self.size and 0 <= col < self.size:
            if self.board[row][col] is None:
                self.board[row][col] = self.players[self.current_player]
                self.current_player = (self.current_player + 1) % len(self.players)

Alternatives

Fixed-size board with hardcoded players

Board size and player count are constants in code, no flexibility.

Use when: Choose when the game requirements are simple and unlikely to change.

Plugin-based extensibility

Game logic loads external plugins to add new board types or player rules dynamically.

Use when: Choose when you want third-party developers to extend the game without modifying core code.

Summary

Hardcoding board size and player count limits game flexibility and increases maintenance.

Designing for extensibility allows easy changes to board size and player number without rewriting code.

Extensible design improves maintainability and supports future game feature expansions.