Battleship Ship-Finding Game — Free HTML CSS JS Snippet

Battleship is one of the oldest "search and destroy" grid games, and building a working single-player version is a genuinely useful exercise in constraint-based random placement, coordinate-based state lookup, and win-condition detection. This snippet implements a complete, playable version entirely in vanilla JavaScript — a hidden fleet is randomly placed on an 8x8 grid with real collision and boundary checking, and the player fires at cells to locate and sink every ship.

Randomised fleet placement with retry-on-collision

The fleet consists of four ships defined in SHIP_DEFS — a 4-cell Carrier, two 3-cell ships (Cruiser and Submarine), and a 2-cell Destroyer — mirroring a simplified version of the classic fleet composition. placeFleet() places each ship in turn: it picks a random starting row and column, a random orientation (horizontal or vertical), computes the full list of cells the ship would occupy, and calls canPlace() to verify every one of those cells is within the 8x8 boundary and currently unoccupied on the board array. If the random placement collides with another ship or runs off the grid, the loop simply tries again with a fresh random position and orientation, up to 200 attempts per ship. Because ship placement order and position are both randomised independently for every new game, no two games have the same fleet layout. placeFleetSafe() wraps the whole process in a retry loop that restarts fleet placement entirely from scratch if any single ship exhausts its attempts (extremely rare on an 8x8 grid with this fleet size, but a real safeguard against ever leaving the game unplayable).

Board representation and coordinate lookup

The hidden board is a 2D array, board[row][col], where each cell holds either null (empty water) or the numeric index of the ship occupying it. This gives instant O(1) lookup of "what ship, if any, lives at this cell" via findShipAt(), which is the core operation every fired shot needs. Each ship object separately tracks its own cells array (its full list of occupied coordinates) and a hits Set of coordinate keys that have been successfully struck — using a Set rather than a counter means the sunk check, ship.hits.size === ship.length, is both correct and cannot be thrown off by a duplicate hit being counted twice.

Firing, hit/miss rendering, and the shot log

Every fired cell is recorded in a shotLog object keyed by a "row-col" string, storing either 'hit' or 'miss' — this both prevents firing at the same cell twice and drives the entire visual re-render. cellState() derives what a cell should look like purely from shotLog and the ship data: a miss renders as a pale dot on a darker water tile, a hit renders as a red cross, and a hit whose owning ship is now fully sunk gets an additional sunk class for a darker red treatment, visually distinguishing "you hit something" from "you finished it off." This derive-from-source-of-truth approach means the render function never needs its own separate tracking state — it always reflects shotLog and ships exactly.

Sunk detection and win condition

After every shot, isShipSunk() compares a ship's accumulated hit count against its length; when they match, a "Ship sunk!" toast names the specific ship. checkWin() runs after every shot and checks whether ships.every(isShipSunk) — only when every ship in the fleet independently satisfies the sunk condition does the game declare victory, at which point it reports the final accuracy percentage, calculated as hits / shotsFired, rounded to the nearest whole percent.

Why this is a strong constraint-placement exercise

The interesting engineering problem in Battleship isn't the UI, it's guaranteeing a valid random layout under real constraints (no overlaps, no out-of-bounds cells, both orientations supported) without ever falling into an infinite loop or producing an invalid board. The retry-with-attempt-cap pattern used here — try random placement, validate, retry on failure, cap total attempts — is broadly reusable any time you need procedurally generated content that must satisfy hard non-overlap constraints, from level generation to seating charts.