Battleship Game Logic on a 2D Grid: Object Design, Shots and Production Concerns

Implement the game logic for a game in which a player fires shots at warships placed on a two-dimensional grid, in the style of the classic Battleship game. The interviewer expects an object-oriented design. Later in the round, the discussion moved to running the game in production: deployment, online performance and system-level issues. The report does not spell out the rules, so agree on them first; the parts below start from the classic rules, in which ships of fixed lengths lie horizontally or vertically without overlapping, each shot is a miss, a hit, or a hit that sinks a ship, and a player wins by sinking the whole opposing fleet. ### Clarifying Questions - What are the grid size and the fleet (ship lengths and counts), and are they configurable? - Who places the ships: the players, the program at random, or the caller as input? May ships touch? - Is it two players taking turns against each other, or one player shooting at a hidden fleet? - What should a shot outside the grid, or at a cell already fired at, do: raise an error, return a distinct result, or cost the turn? - Does a hit reveal which ship was hit, or is the ship named only when it sinks? ### Part 1 — Model the board and the fleet Design the classes for the board, the ships and the game, and implement ship placement with validation. ```hint Who knows a cell was hit Decide whether the board, the ship or both record that a cell has been hit, and what each lookup costs. ``` #### What This Part Should Cover - Clear responsibilities for the board, ship and game objects, with state kept inside them - Placement validation: inside the grid, horizontal or vertical, no overlap, fleet composition - A structure that finds the ship at a cell quickly ### Part 2 — Fire shots Implement firing at a cell: return whether the shot missed, hit, or sank a ship, switch turns, and detect the end of the game. Handle shots outside the grid and repeated shots according to the rules you agreed. ```hint Count, do not scan Think about how to know that a ship has sunk, or that a fleet is gone, without scanning the board after every shot. ``` #### What This Part Should Cover - Correct results and state changes for every kind of shot - Turn order, the end of the game, and rejecting moves after it ends - Unit tests for placement errors, repeats, sinking and winning ### Part 3 — Run it in production Suppose this logic powers an online game played by many users at once. How would you deploy it, what performance problems would you expect, and which system issues would you need to handle? ```hint Where a game lives Ask what happens to a game in progress when the server holding it restarts, and when two requests for the same game arrive at the same moment. ``` #### Clarifying Questions for this Part - How many games run at once, and how quickly do players move? - Is the game turn-based over request and response, or must players see the opponent's move pushed to them at once? #### What This Part Should Cover - Where game state is stored, and how a game survives a restart or a deploy - Concurrency control and idempotency for moves on the same game - Deployment, scaling and the metrics you would watch ### What a Strong Answer Covers - A clean object model whose rules can be tested without any user interface or network - Constant-time shot resolution, sinking and game-over detection - Rule edge cases agreed up front and enforced in one place - A server that is the only authority on game state, safe under restarts and concurrent requests - Senior-level judgment about trade-offs, testing and operations ### Follow-up Questions - How would you add a computer opponent that shoots better than at random? - How do you stop a client from learning where the opponent's ships are? - A deploy goes out while thousands of games are in progress. How do you avoid breaking them? - How would you replay a finished game to debug a reported problem?