In this chapter, we will explore the low-level design of a snake and ladder game in detail.

Lets start by clarifying the requirements:

Before starting the design, it's important to ask thoughtful questions to uncover hidden assumptions and better define the scope of the system.

Here is an example of how a conversation between the candidate and the interviewer might unfold:

After gathering the details, we can summarize the key system requirements.

After the requirements are clear, lets identify the core entities/objects we will have in our system.

How do you go from a list of requirements to actual classes?

The key is to look for nouns in the requirements that have distinct attributes or behaviors. Not every noun becomes a class, but this approach gives you a starting point.

Let's walk through our requirements and identify what needs to exist in our system.

1. The game is played on a standard 10x10 board with 100 numbered cells.

The board is central to everything. We need something to represent it. This gives us our first entity: Board.

Unlike Tic-Tac-Toe where each cell holds a symbol, Snake and Ladder cells are just positions. The interesting part is what happens at certain positions. The Board needs to know which positions have snakes or ladders and where they lead.

2. Support configuration of snakes and ladders with flexible start and end positions

We clearly need Snake and Ladder entities. Both have a start position and an end position. A snake's start (head) must be higher than its end (tail). A ladder's start (bottom) must be lower than its end (top).

Notice the similarity?

Both are "board entities" that transport a player from one position to another. This suggests an abstract base class BoardEntity that Snake and Ladder can inherit from. The base class holds the common logic (start and end positions), while subclasses enforce their specific validation rules.

3. Allow multiple players (minimum two), with turn rotation in round-robin order

We need to represent players. Each player has a name and a current position on the board. This gives us the Player entity.

Players start at position 0 (off the board) and move toward 100. Their position changes after each dice roll, potentially modified by snakes or ladders.

4. Simulate dice rolls with random values between 1 and 6

We need a Dice entity to simulate random rolls. While we could just call Math.random() directly in the game logic, encapsulating dice behavior in its own class provides several benefits:

5. The game should manage turns, apply snakes and ladders, and determine when a player wins

Something needs to coordinate the gameplay: roll dice, move players, check for snakes/ladders, handle the special "roll 6 for extra turn" rule, and detect when someone wins. This orchestrator is our Game entity.

The game also needs to track its current state. Is it still running? Has someone won? An enum GameStatus with values NOT_STARTED, RUNNING, and FINISHED captures all possibilities cleanly.

Entity Overview

Here's how these entities relate to each other:

We've identified three types of entities:

Enums define fixed sets of values. GameStatus tracks the game lifecycle.

Data Classes primarily hold data with minimal behavior. Player tracks name and position. BoardEntity (and its subclasses) holds start and end positions.

Core Classes contain the main logic. Dice generates random rolls, Board manages position transitions, and Game orchestrates the entire gameplay loop.

With our entities identified, let's define their attributes, behaviors, and relationships.

Now that we know what entities we need, let's flesh out their details. For each class, we'll define what data it holds (attributes) and what it can do (methods). Then we'll look at how these classes connect to each other.

We'll work bottom-up: simple types first, then data containers, then the classes with real logic. This order makes sense because complex classes depend on simpler ones.

Enums

Enums define fixed sets of values that provide type safety and make code self-documenting.

GameStatus

Tracks where we are in the game lifecycle.

Three distinct states cover the game lifecycle. Unlike Tic-Tac-Toe, there's no DRAW state because Snake and Ladder always eventually produces a winner.

Data Classes

Data classes are simple containers that hold data with minimal behavior.

Player

Encapsulates all relevant information about a player

The Player starts at position 0, which represents "off the board" (before cell 1). The position is mutable because it changes after every move. The name is immutable since it never changes during gameplay.

BoardEntity

Abstract base class for snakes and ladders.

Snake

Represents a snake on the board.

When a player lands on the snake's head (start position), they slide down to the tail (end position). The constructor enforces that the head is always higher than the tail.

Ladder

Represents a ladder on the board.

When a player lands on the ladder's bottom (start position), they climb up to the top (end position). The constructor enforces that the bottom is always lower than the top.

Core Classes

Core classes contain the actual game logic.

Dice

A utility class responsible for simulating a dice roll.

Board

Manages the game board and position transitions.

The Board doesn't store individual cells because we don't need to track cell contents. Instead, it maintains a map from snake/ladder start positions to their end positions. When a player lands on a position, we check if there's an entry in this map. If so, we return the mapped position; otherwise, we return the original position.

The Board also validates its configuration while building this map. Every entity must start and end within the board, and no two entities can share a start cell, since the map can only hold one destination per cell. An invalid layout fails fast in the constructor instead of producing silent, hard-to-debug behavior mid-game.

Game

Main orchestrator that coordinates all game elements.

Key Design Principles:

You might notice some structural patterns emerging in our design. Let's make them explicit and justify why each pattern is appropriate here.

Builder Pattern

The Problem: Creating a Game requires multiple configuration steps: setting up the board with snakes and ladders, adding players, and configuring the dice. If we use a constructor with many parameters, it becomes hard to read and error-prone. What order do the parameters go in? Which ones are optional?

The Solution: The Builder pattern encapsulates the construction logic in a separate Builder class. Each configuration step returns the builder, allowing method chaining. The final build() call validates everything and creates the Game.

Facade Pattern (Game as Controller)

The Problem: External code shouldn't need to understand the internals of Board, Dice, and Player management. They just want to start and play a game.

The Solution: The Game class acts as a facade, providing simple play() method that hides all the complexity of turn management, dice rolling, position updates, and win detection.

The Game class provides:

Before reading the full implementation, try building this yourself. Below are template stubs for the classes from the design. The enums, data classes, and the demo are already written for you. The job is to fill in the core logic where the TODO comments appear.

Your task: Implement every TODO using the design from the previous sections. When you are done, run the demo. A correct implementation produces the expected output.

Now let's translate our design into working code. We'll build bottom-up: foundational types first, then data classes, then the classes with real logic. This order matters because each layer depends on the ones below it.

The base design keeps each concern in its own class, so most new requirements land as new classes or new fields rather than edits to the game loop. The Game orchestrates turns, the Board owns position lookups, the Dice produces rolls, and BoardEntity covers snakes and ladders. The four extensions below build on those same classes.

Scenario: "Let players roll two dice per turn, and grant an extra turn when both dice show the same value."

The current Dice rolls a single value through roll(). To support multiple dice, we wrap a list of Dice in a DiceRoller that returns the total and reports whether the roll was a double. The takeTurn logic uses the total exactly as it used a single roll today, and an extra-turn rule reads the double flag. Because Dice.roll() stays unchanged, the existing single-die game keeps working by passing a roller with one die.

Game replaces its direct dice.roll() call with diceRoller.rollAll(), adds the returned total to the player's position, and re-adds the current player to the front of the turn queue when isDouble is true. The win and overshoot checks in takeTurn stay the same because they only depend on the total.

Scenario: "Generate boards of different sizes with snakes and ladders placed by different rules, including a randomized layout."

The Board constructor already takes a size and a list of BoardEntity objects, so a 10x10 board is just one configuration. To vary how snakes and ladders are placed, we introduce a BoardSetupStrategy that produces the entity list for a given size. A fixed strategy returns a hand-authored layout, while a random strategy generates valid snakes and ladders. The Game.Builder.setBoard step calls the strategy and passes the result to the existing Board constructor.

The strategy respects the same constraints the Snake and Ladder constructors enforce, so each generated entity passes its own validation. A production version would also reject overlapping starts and entities that chain into each other. The Board itself does not change, since it still receives a size and a list of BoardEntity objects.