Board and piece hierarchy in LLD - System Design Guide

Problem Statement

When designing a board game application, mixing all board and piece logic in one place causes code to become tangled and hard to maintain. Adding new piece types or changing board rules becomes error-prone and slows development.

Solution

Separate the board and pieces into a clear class hierarchy where the board manages the game state and pieces encapsulate their own behavior. Use inheritance or composition so each piece type defines its unique moves and properties, while the board handles placement and game rules.

Architecture

Board

- grid

→Piece (base)

↓

Pawn

- move()

This diagram shows the Board class holding the game grid and referencing a base Piece class. Specific piece types like Pawn, Knight, and Bishop inherit from Piece and implement their own move logic.

Trade-offs

✓ Pros

→

Improves code organization by separating board and piece responsibilities.

→

Makes it easy to add new piece types without changing board code.

→

Encapsulates piece-specific behavior, reducing bugs and duplication.

→

Supports polymorphism so board can treat all pieces uniformly.

✗ Cons

→

Requires upfront design effort to define clear interfaces.

→

May add slight complexity for very simple games with few piece types.

→

Inheritance misuse can lead to rigid hierarchies if not designed carefully.

Use when building board games with multiple piece types and complex move rules, especially if the game will evolve or add new pieces over time.

Avoid if the game has only one piece type or very simple rules where separate classes add unnecessary complexity.

Real World Examples

Chess.com

Uses a piece hierarchy to represent different chess pieces, each with unique move logic, while the board manages piece placement and game state.

Lichess

Separates board and piece logic to allow easy implementation of chess variants by extending piece behaviors.

Hasbro (digital Monopoly)

Uses a board and piece model where pieces represent tokens with specific rules and the board manages property positions.

Code Example

The before code mixes all piece move logic inside one Game class, making it hard to maintain. The after code separates pieces into classes inheriting from a base Piece class, each implementing its own move method. The Board class manages piece placement and delegates move validation to pieces, improving clarity and extensibility.

LLD

### Before: All logic in one class
class Game:
    def __init__(self):
        self.board = [[None]*8 for _ in range(8)]

    def move_pawn(self, from_pos, to_pos):
        # pawn move logic here
        pass

    def move_knight(self, from_pos, to_pos):
        # knight move logic here
        pass

### After: Board and piece hierarchy
class Piece:
    def __init__(self, position):
        self.position = position
    def move(self, new_position, board):
        raise NotImplementedError

class Pawn(Piece):
    def move(self, new_position, board):
        # pawn-specific move logic
        pass

class Knight(Piece):
    def move(self, new_position, board):
        # knight-specific move logic
        pass

class Board:
    def __init__(self):
        self.grid = [[None]*8 for _ in range(8)]

    def place_piece(self, piece, position):
        self.grid[position[0]][position[1]] = piece
        piece.position = position

    def move_piece(self, from_pos, to_pos):
        piece = self.grid[from_pos[0]][from_pos[1]]
        if piece and piece.move(to_pos, self):
            self.grid[to_pos[0]][to_pos[1]] = piece
            self.grid[from_pos[0]][from_pos[1]] = None
            piece.position = to_pos
            return True
        return False

Alternatives

Monolithic Game Object

All board and piece logic combined in one class without hierarchy.

Use when: For very simple games with minimal piece types and no plan for extension.

Component-Based Design

Pieces are composed of reusable components instead of inheritance, allowing more flexible behavior combinations.

Use when: When pieces share many behaviors that can be mixed and matched dynamically.

Summary

Separating board and piece logic into a class hierarchy improves code organization and maintainability.

Each piece type encapsulates its own behavior, allowing easy addition of new pieces without changing board code.

This pattern is ideal for complex board games with multiple piece types and evolving rules.

Practice

1. What is the main purpose of having a base Piece class in a board game design?

easy

A. To manage network communication between players

B. To define common properties like position and type for all pieces

C. To handle user input events

D. To store the entire board layout

Solution

1. Step 1: Understand the role of a base class

   A base class provides shared properties and methods for all derived classes, avoiding repetition.

2. Step 2: Apply to board game pieces

   All pieces share common traits like position and type, so the base Piece class holds these.

3. Final Answer:

   To define common properties like position and type for all pieces -> Option B

4. Quick Check:

   Base class = common properties [OK]

Hint: Base class holds shared traits for all pieces [OK]

Common Mistakes:

• Confusing board layout storage with piece properties
• Thinking base class handles user input
• Assuming base class manages network tasks

2. Which of the following is the correct way to declare a subclass King that extends a base Piece class in a typical object-oriented design?

easy

A. class King extends Piece { constructor(position) { super(position); } }

B. function King() { this.position = position; } extends Piece

C. class King inherits Piece { constructor() { } }

D. King = Piece + position

Solution

1. Step 1: Identify correct subclass syntax

   In modern OOP, a subclass uses extends keyword and calls super() in constructor.

2. Step 2: Check each option

   class King extends Piece { constructor(position) { super(position); } } uses correct syntax: class King extends Piece { constructor(position) { super(position); } }.

3. Final Answer:

   class King extends Piece { constructor(position) { super(position); } } -> Option A

4. Quick Check:

   Subclass syntax = extends + super() [OK]

Hint: Subclass uses extends and calls super() in constructor [OK]

Common Mistakes:

• Using incorrect keywords like inherits
• Placing extends after function declaration
• Trying to add properties with '+' operator

3. Given this code snippet for a board and pieces, what will be the output of console.log(board.pieces[0].type);?

class Piece {
  constructor(type, position) {
    this.type = type;
    this.position = position;
  }
}
class Board {
  constructor() {
    this.pieces = [];
  }
  addPiece(piece) {
    this.pieces.push(piece);
  }
}
const board = new Board();
board.addPiece(new Piece('Knight', 'B1'));

medium

A. undefined

B. "B1"

C. Error: pieces is not defined

D. "Knight"

Solution

1. Step 1: Understand object creation and storage

   A new Piece with type 'Knight' and position 'B1' is created and added to board.pieces.

2. Step 2: Access the first piece's type

   board.pieces[0] refers to the first piece, so board.pieces[0].type is 'Knight'.

3. Final Answer:

   "Knight" -> Option D

4. Quick Check:

   First piece type = 'Knight' [OK]

Hint: First piece type is stored in pieces[0].type [OK]

Common Mistakes:

• Confusing position with type
• Assuming pieces array is empty
• Expecting an error due to missing pieces

4. Identify the error in this piece hierarchy code snippet:

class Piece {
  constructor(type, position) {
    this.type = type;
    this.position = position;
  }
}
class Queen extends Piece {
  constructor(position) {
    this.type = 'Queen';
    this.position = position;
  }
}

medium

A. Position should not be passed to constructor

B. Queen class should not have a constructor

C. Missing call to super() in Queen constructor

D. Type should be passed as parameter to Queen constructor

Solution

1. Step 1: Review subclass constructor rules

   In subclasses, the constructor must call super() before using this.

2. Step 2: Check Queen constructor

   Queen constructor assigns this.type and this.position without calling super(), causing an error.

3. Final Answer:

   Missing call to super() in Queen constructor -> Option C

4. Quick Check:

   Subclass constructor must call super() first [OK]

Hint: Always call super() before using this in subclass constructor [OK]

Common Mistakes:

• Forgetting super() call in subclass constructor
• Trying to assign this before super()
• Assuming constructor is optional in subclass

5. You want to design a scalable board game system where each piece type has unique movement rules. Which design approach best supports adding new piece types without changing existing code?

hard

A. Use a base Piece class and create subclasses for each piece type implementing their own move logic

B. Store all piece types and moves in a single large switch-case statement

C. Keep piece types as strings and handle moves in a separate global function with if-else

D. Use a flat list of pieces with no hierarchy and hardcode moves in the board class

Solution

1. Step 1: Understand scalability and extensibility

   Good design allows adding new piece types without modifying existing code, following open-closed principle.

2. Step 2: Evaluate design options

   Subclassing Piece lets each piece implement its own move logic, enabling easy extension.

3. Final Answer:

   Use a base Piece class and create subclasses for each piece type implementing their own move logic -> Option A

4. Quick Check:

   Subclassing = scalable and extensible design [OK]

Hint: Subclass each piece type for unique moves [OK]

Common Mistakes:

• Using large switch-case blocks that are hard to maintain
• Handling moves globally with if-else reduces flexibility
• Hardcoding moves in board class limits scalability