How Underwater Arcade Games Work Under the Hood

An underwater arcade game looks like a world with water in it. What it actually is, underneath, is a list of numbers that gets updated sixty times a second and a set of drawing instructions that run immediately afterwards.

This article explains how that works in plain terms — no code required — using the eight games on this site as the worked example. It covers the render loop, how water is faked, how collisions are detected, how difficulty rises, and where your score actually lives.

The render loop

Everything starts with a loop that runs once per display refresh, typically sixty times a second. Each pass does three things in order:

1. Measure the time since the last frame. This is the delta, usually about 0.0167 seconds.
2. Update the state. Move everything, check for collisions, spawn new objects, adjust the score. Nothing is drawn.
3. Draw the state. Clear the canvas and redraw everything from scratch, in one pass.

The browser schedules this with requestAnimationFrame, which fires just before the display refreshes and — usefully — stops firing entirely when the tab is hidden. That is why the games on this site pause automatically when you switch tabs: it is not a feature so much as an honest response to the loop stopping.

The important detail is that every movement is multiplied by the delta. Speeds are stored as "pixels per second", not "pixels per frame". Without that, the games would run at double speed on a 120Hz display and in slow motion on a struggling phone.

There is one more safeguard worth knowing about: the delta is clamped, on this site to a maximum of 0.05 seconds. If a frame takes longer than that — a background tab waking up, a phone stuttering — the game pretends only 50 milliseconds passed. Otherwise a one-second stall would teleport every object a full second's worth of distance, straight through walls.

How water is faked

There is no fluid simulation in any of these games. Water is three cheap tricks.

Drag

Each frame, velocity is multiplied by a number slightly less than one. That is the entire model. Something moving at 300 pixels per second is moving at 290 next frame, then 280, and coasts to a stop on a curve that feels exactly like resistance.

Because the multiplier is applied per second rather than per frame — raised to the power of the delta — it behaves identically at any frame rate.

Buoyancy

A small constant added to vertical velocity every frame, regardless of input. In Deep Sea Explorer it is a gentle downward pull; the effect is that idling sinks you slowly. That single line of behaviour removes "wait safely in a corner" as a strategy, which is worth more to the design than it sounds.

Acceleration instead of movement

Pressing a direction does not move your craft. It adds to velocity, and velocity moves the craft. Combined with drag, this is what produces the heavy, deliberate feel of the whole genre — and why inputs have to be early rather than reactive.

Three numbers, no physics engine, and the result reads convincingly as water to anyone who has ever swum.

How collisions are detected

Almost entirely with circles.

Two objects are touching if the distance between their centres is less than the sum of their radii. In practice you compare the squared distance against the squared sum, because that avoids a square root — a small saving repeated thousands of times a second.

Circles are used even for objects that are visibly not circular. The submersible in Deep Sea Explorer is an ellipse with a fin, and its collision shape is a circle slightly smaller than it appears. That undersizing is deliberate: players consistently judge near-misses generously, and a hitbox that matches the artwork exactly feels unfair.

The exceptions on this site are rectangular. Lane obstacles in Underwater Obstacle Run use a box overlap test, and the canyon in Submarine Adventure uses neither — it simply looks up the wall heights at the submarine's horizontal position and compares.

How the canyon is generated

Submarine Adventure's canyon is a good example of procedural generation that cannot fail.

The terrain is a list of columns, each 14 pixels wide, storing two numbers: where the passage centre is and how wide the gap is. As the world scrolls, the leftmost column is discarded and a new one is appended on the right.

The new column is derived from the previous one plus two slowly drifting targets. Both movements are clamped — the centre can shift by at most about 2.2 pixels per column, the width by about 1.4 — and the gap has a hard floor at 26% of the stage height.

Those three constraints guarantee three properties: the canyon never jumps, it never becomes impassable, and everything is telegraphed roughly a second in advance. A generator without them will eventually produce a section nobody can survive, which is the fastest way to lose a player's trust.

How objects appear

Two patterns cover nearly everything.

Timer-based spawning. A countdown runs; when it hits zero, something appears and the countdown resets to a random value within a range. Adjusting that range is how difficulty is tuned — in Deep Sea Explorer the hazard spawn interval shortens by up to 45% across the first 55 seconds.

Wave-based spawning. A set of objects is placed together according to a rule. Underwater Obstacle Run shuffles its four lanes, blocks between one and three of them, and fills some of the rest with bubbles. The shuffle is a Fisher–Yates pass, so the blocked set is uniformly random rather than biased toward the lanes early in the list.

Both patterns share one rule that matters more than any other: never spawn something the player cannot avoid. The wave generator blocks at most three of four lanes. Boulders in Submarine Adventure are placed between 18% and 40% of the gap away from its centre, so the middle stays clear. These are not accidents; they are the constraints that make the games fair.

How difficulty rises

Four dials, used in different combinations.

Speed. Submarine Adventure adds 16% of its base scroll rate per 250-metre tier.

Spawn rate. More hazards, more often.

Window size. Underwater Reflex shrinks how long each target stays visible, from 1.85 seconds toward a floor of 0.62.

Resource supply. The subtlest and most interesting. Deep Sea Diver reduces the chance that a spawned item is an air pocket, from about 42% down to a floor of 14%, while the drain rate rises. Nothing gets faster; the economy simply tightens until it breaks you.

Notice that every one of those has a floor or a cap. Difficulty that rises without limit eventually becomes arbitrary, and the player stops believing the game is winnable.

How the graphics are made

Nothing on this site is an image file. Every submarine, fish, bubble and coral is drawn from canvas primitives — ellipses, arcs, lines, gradients — every single frame.

That sounds wasteful and is not. A fish is roughly a dozen drawing calls, and a browser handles thousands per frame comfortably. The benefits are substantial: nothing to download, nothing to decode, perfect sharpness at any resolution, and colours that can change at runtime because they are parameters rather than baked pixels.

One detail worth explaining if you have ever wondered why canvas games sometimes look soft: a canvas has two sizes, its CSS size and its internal pixel buffer. On a high-density display these differ, and if the buffer is not scaled to match the device pixel ratio, everything is upscaled and blurry. The games here set the buffer to the CSS size multiplied by that ratio, capped at 2× — because 3× costs a great deal of performance for a difference almost nobody can see on flat vector art.

Why the HUD is not on the canvas

A small architectural decision with outsized consequences: the score bar over each stage is real HTML sitting above the canvas, not text drawn into it.

Canvas text does not scale with browser zoom, cannot be read by a screen reader, cannot be selected, and has to be redrawn every frame. HTML text does all of those things correctly for free — and updating it only when the value actually changes costs essentially nothing.

The same reasoning puts the start and game-over panels in HTML. It means the instructions are real text a browser can enlarge or read aloud, which matters more than it might sound.

Where your score lives

In your browser's local storage, under a key naming the game and the metric. Reading and writing it is two function calls, and both are wrapped in error handling because in a private window or with site data blocked, the attempt throws rather than failing quietly.

That is the whole persistence layer. No account, no database, no network request. The trade is plain: your scores are private and require nothing of you, and they are also device-bound and disappear if you clear site data. There is more in how browser games save high scores.

How input is unified

The last piece is making keyboard, mouse and touch behave as one system.

The approach that works is to normalise early. Rather than writing separate handlers, everything is reduced to a small shared state: a set of active directions and a pointer position with a pressed flag. A key press sets a direction; a virtual D-pad button sets the same direction; a drag sets the pointer. The game logic reads only that shared state and never knows which device produced it.

Modern browsers help here — pointer events unify mouse, touch and stylus into one stream — but the principle matters more than the API. The moment a game has separate code paths for touch, the two behave differently, and one of them is always worse.

Where to go next

For more on the drawing layer specifically, read how HTML5 canvas powers underwater games. For the difficulty side, how difficulty curves work goes deeper into the four dials and the numbers behind them.

And for the player-facing version of all this, the high score guide translates the mechanics into decisions you can act on.