Problem statement
Design the object model and core APIs for a two-player Battleship game engine that a single process runs to drive one match from empty grids to a decided winner. The engine owns the rules and both boards; whatever sits on top (a console loop, a GUI, a test harness) merely places ships, fires shots, and reads state back.
Operating context. Two players, each with a private NxN grid (10x10 by default) and a fleet of ships of fixed lengths (for example one length-5, one length-4, two length-3, one length-2). The match has two phases. First, each player places every ship on their own grid: a ship occupies a straight run of cells, horizontal or vertical, fully inside the grid, and no two ships of the same player may overlap or (by house rule) touch. Once both fleets are placed, players alternate firing a shot at a coordinate on the opponent's grid; each shot is a hit or a miss, a hit that fills the last remaining cell of a ship sinks it, and the same cell may not be fired at twice. A player wins the moment the opponent's entire fleet is sunk. All input arrives as method calls; there is no clock, no network, and no concurrent access — one caller drives the engine on one thread.
Out of scope. Rendering or drawing the grids, any input parsing or console I/O, an AI opponent or shot-targeting strategy, persistence or save/resume, networking / matchmaking, and hidden-information enforcement across a wire (assume the single caller is trusted). Design only the in-process rules engine and its object model.
What to produce. The class hierarchy (entities such as Board, Cell, Ship, Fleet, Player, Shot, Game, and value objects like Coordinate or Orientation), the public API each class exposes, and the state transitions for the match (setup -> in-progress -> won), for a ship (afloat -> sunk), and for a target cell (unfired -> hit | miss). Be explicit about: how a placement is validated before it is committed, how a shot is resolved into miss / hit / hit-and-sunk, how per-player fleet progress is tracked so win detection is cheap, how turn ownership is enforced, and how the design extends to a variant board size or fleet composition without rewriting shot resolution.
Requirements
This assessment is a Premium feature.
The statement above is free to read. The functional and non-functional requirements, and the graded canvas that scores your design against them, come with Premium.
Topics
- System Design LLD
- Oop Solid
- Statemachine
- Extensibility
- Patterns Strategy