Problem statement
Design the object model and core APIs for a Snakes and Ladders game engine that runs a single match end to end. The engine drives a linear board of numbered cells, walks a fixed roster of players around it turn by turn, applies jump transitions (a ladder lifts a token forward, a snake drops it back), and stops the moment someone reaches the final cell.
Operating context. One in-process match at a time, driven by a host loop (a CLI or a test harness) that repeatedly asks the engine to take the next turn. The board size, the starting cell, and the set of jumps are all supplied as configuration at construction — nothing is hard-coded to a 100-cell grid. Two to six players each own a single token and move in a fixed rotation. The host owns the randomness source and passes it in, so a match can be replayed deterministically. There is no UI, no rendering, and no persistence between matches.
Out of scope. The board rendering / visual grid, networked or multi-process play, matchmaking and lobbies, AI opponents, undo / rewind of a completed turn, and saving a match to disk. Focus on the in-process object model, not any transport or storage layer.
What to produce. The class hierarchy (entities, value objects, and the engine service), the public API each class exposes, and the state transitions of a match (setup to in-progress to finished) and of a turn. Be explicit about: how the dice is abstracted so a test can force a known roll; how the board resolves a landing cell through zero or more jumps; how the turn rotation and win condition are decided; and how the design extends to variants (e.g. an exact-finish rule, double-six re-rolls, or a jump that teleports sideways) without editing the core turn loop.
Functional requirements
- Advance the current player by a dice value, then resolve the landing cell through any ladder or snake jump anchored there.
- Rotate turns through the player roster in a fixed order, skipping no one until the match ends.
- Detect and report a win the instant a token reaches the final cell, and refuse further turns afterward.
- Construct the board from supplied configuration: total cells, start cell, and the list of jump (from, to) pairs.
- Expose the current match state on demand: whose turn it is, every token position, and the winner if any.
- Reject an invalid setup, such as a jump whose endpoints fall outside the board or two jumps sharing a source cell.
Non-functional requirements
- Resolving one turn (roll, move, jump lookup, win check) is O(1) in the number of players and jumps.
- The dice is an injected abstraction so a deterministic stub can force any roll for a unit test.
- Adding a rule variant (exact finish, double-six re-roll, sideways jump) touches a new class, not the core turn loop.
- The board and jump map are immutable after construction, so no turn can mutate the topology mid-match.
- The engine is unit-testable with no wall clock, no real randomness, and no I/O.
- Illegal configuration is rejected at construction time, never surfacing as a mid-match crash.
Topics
- System Design LLD
- Oop Solid
- Patterns Strategy
- Statemachine
- Testability Clock