Requirements for Snake and Ladder

Let's define exactly what our Snake and Ladder game engine needs to do. Each requirement is specific enough to drive a design decision — you should be able to trace every class and method back to one of these.

1. R1: Configurable Board Size — The game shall support a board with a configurable number of cells. The default board is 100 cells (10×10), but the design should allow boards of any size (e.g., 36 cells for a 6×6 board).

2. R2: Multiple Players — The game shall support 2 or more players. Each player has a name and a current position on the board. All players start at position 0 (off the board).

3. R3: Queue-Based Turn Order — Players shall take turns in a fixed, round-robin order. The system must cycle through players fairly — after the last player's turn, the first player goes again. No player should get consecutive turns (exception: some variants allow extra turns on rolling a 6, but we won't implement that in the base design).

4. R4: Dice Rolling — The game shall use a standard 6-sided die (values 1–6, uniformly random). The design should support configurable dice — e.g., a single die (1–6) or multiple dice (2–12 for two dice).

5. R5: Player Movement — On each turn, the current player rolls the dice and advances forward by the rolled amount. If the resulting position exceeds the board size (e.g., player at position 97 rolls a 5 on a 100-cell board), the player does NOT move — they stay at their current position and their turn ends.

6. R6: Snakes — A snake occupies a pair of positions: a head (higher position) and a tail (lower position). If a player lands exactly on a snake's head after moving, they slide down to the snake's tail position. A snake always moves the player backward (head > tail).

7. R7: Ladders — A ladder occupies a pair of positions: a bottom (lower position) and a top (higher position). If a player lands exactly on a ladder's bottom after moving, they climb up to the ladder's top position. A ladder always moves the player forward (top > bottom).

8. R8: No Chaining — If a player is moved by a snake or ladder to a new position, they do NOT trigger another snake or ladder at the destination. Only the initial landing position triggers an entity effect. (This simplifies the game logic and avoids infinite loops in degenerate board configurations.)

9. R9: Win Condition — The first player to reach exactly the last cell (e.g., position 100 on a standard board) wins the game. The game ends immediately when a player wins.

10. R10: Game State Tracking — The system shall track the game state: NOT_STARTED (before first turn), IN_PROGRESS (game is running), and FINISHED (a player has won). Operations like playTurn() should only work when the game is IN_PROGRESS.

11. R11: Board Validation — The board configuration must be validated at setup time: no snake head or ladder bottom at the start cell (position 1) or end cell (position 100), no snake and ladder at the same position, and start/end positions of every entity must be within the board bounds.

Beyond functionality, our design should meet these quality attributes:

1. Extensibility (Open/Closed Principle) — It should be easy to add new types of board entities without modifying existing code. For example, a "Power-Up" entity that gives the player an extra turn, or a "Portal" that teleports to a random position. Our abstract class hierarchy must support this.

2. Testability — Each component should be testable in isolation. The Dice should support deterministic injection for testing (so we can control roll outcomes). The Board should be configurable with known snake/ladder positions for predictable test scenarios.

3. Single Responsibility — Each class should have one clear reason to change. The Board manages entities. The Game manages the loop. The Dice handles randomness. No god class that does everything.

4. Clean Separation of Concerns — The game logic (whose turn, has someone won) should be separate from the board structure (where are the snakes and ladders). This makes it possible to reuse the Board class with different game rules.

In Scope:

• Board model with configurable size and entity placement
• Snake and Ladder entity hierarchy (abstracting the shared move-to-destination behavior)
• Dice with configurable range
• Player model with position tracking
• Turn management using a queue
• Game controller with game loop, state tracking, and win detection
• Board validation (no overlapping entities, bounds checks)

Out of Scope:

• Extra turn on rolling 6 — a common house rule, but omitted for simplicity. Could be added as an extension.
• Multiple dice — the design supports it via a numDice parameter, but the core game uses a single die.
• Chaining effects — landing on a snake/ladder destination that also has a snake/ladder does NOT trigger the second entity (R8). Some variants chain; ours does not.
• Networking / Multiplayer — all players are local. No server communication.
• Persistence — no saving/loading game state to a database.
• GUI / Rendering — the engine is logic-only; any UI layer would consume it as a library.

In a real LLD interview, spend 3–5 minutes clarifying requirements before writing any classes. For Snake and Ladder, here are the questions a strong candidate would ask:

• "How many players should the system support?" → This determines whether you use a simple list or a queue.
• "Can a snake and ladder occupy the same position?" → This affects your board validation logic.
• "What happens if a player rolls past the end of the board?" → The interviewer might say "stay in place" or "bounce back" — don't assume.
• "Do snakes and ladders chain?" → If a snake drops you onto a ladder bottom, do you climb? This is a critical design decision.
• "Is the board always 10×10, or configurable?" → Shows you think about extensibility.

These questions demonstrate that you think like a developer who builds robust systems, not just someone who codes the happy path. Interviewers specifically watch for candidates who clarify ambiguity before designing.