Building a Fish-Table Arcade Game in Pure JavaScript

There’s a single idea worth holding onto before writing a line of code for a fish-table game: every shot the player fires is a tiny gamble dressed up as an action sequence. That one principle — that aiming, firing, and watching the result is really a loop of risk and payoff — explains why these underwater shooters are so addictive, and why they make such a satisfying target for a js13k-style coding challenge. Cram a complete one into 13 kilobytes and a developer learns more about juice, feedback, and probability than a dozen tutorials could teach. And the genre’s roots run straight into a corner of the web where that exact loop has found a second home.

Those neon fish shooters didn’t stay in arcades. They migrated online, and one of the busiest places to see modern versions is the world of online sweepstakes casinos, where US players use virtual currencies like Gold Coins and Sweeps Coins to play and, in the sweepstakes model, redeem winnings for real prizes. Guides that rank the best of them — comparing sites like SpinBlitz and Mega Bonanza on game variety, no-deposit bonuses, fairness, and redemption policies — almost always list a few fish-table titles alongside the slots and live dealer tables. For a developer studying the genre, that’s a goldmine of reference material: live examples showing how shot economies, weapon tiers, and payout pacing are tuned for a polished audience. That’s exactly what makes the genre worth reverse-engineering in a tiny build.

The Core Loop Is the Whole Game

Strip a fish-table game down to its bones and the guiding idea holds: it’s a probability engine wearing a cannon. The player taps the screen, a bullet flies out, and when it connects with a fish, the game rolls a hidden check. Bigger, flashier fish carry lower hit chances but heftier payouts; the little ones scatter and die easily for small returns. That’s it. Everything else — the bubbles, the swaying seaweed, the boss kraken that drifts across the screen — is presentation layered on top of a single risk-reward decision repeated hundreds of times a minute.

For a 13KB build, this is liberating news. A developer doesn’t need a physics engine or a sprawling state machine. A handful of objects, a spawn timer, a collision check, and a weighted random roll cover the entire experience. The hard part isn’t the math. It’s making each of those rolls feel like something.

Spawning Fish Without Spending Bytes

The screen needs to feel alive, and that means a steady parade of fish swimming across it on varied paths. The naive approach — hand-placing sprites — burns memory fast. The lean approach leans on procedural motion: each fish gets a spawn point, a speed, and a sine-wave offset, then the update loop nudges it along a gentle curve. A few lines of trigonometry produce dozens of distinct swimming patterns from almost no data.

Drawing them is where the byte budget really bites. Many jam veterans skip bitmap art entirely and build their creatures from canvas paths — an ellipse for the body, a triangle tail, a couple of arcs for fins. One developer’s detailed writeup of a 13KB entry walks through exactly this kind of trade-off, showing how procedural drawing and tight asset reuse keep a game playable without ever opening an image editor. Apply that thinking to a school of fish and a single parametric function can render an entire reef in a few hundred bytes.

Making the Shot Feel Like It Matters

Here’s where the core idea — every shot is a gamble — has to translate into something the player can feel in their thumbs. A hit that simply deletes a fish is boring. A hit that pauses for a single frame, flashes white, spits out a burst of coin particles, and pops a rising score number sells the payoff. That micro-celebration is the entire emotional contract of the genre.

Sound multiplies the effect. A short rising chime on a kill and a heavier thud on a boss takedown can be generated on the fly with the Web Audio API — no audio files, no wasted kilobytes. The principle of designing tight, responsive feedback loops is a staple of intro game courses; assignments like this browser game-building exercise push students to wire input, collision, and visible response into one snappy chain. Nail that chain and a plain circle bullet hitting a triangle fish becomes genuinely thrilling.

Tuning the Odds So the Game Stays Fair

Behind the fireworks sits the weighted random roll, and balancing it is the most delicate work in the whole project. Set the boss kill chance too high and the game becomes a slot machine that always pays. Set it too low and players feel cheated and quit. The sweet spot keeps the loop tense: frequent small wins, occasional big ones, and a long tail of near-misses that keep a thumb hovering over the screen.

A clean way to model this is a simple probability table mapping each fish type to a hit chance and a payout value, then letting one function resolve every shot. Walking through guided exercises on randomness and game state — such as this interactive media programming lab — helps cement how a single seeded generator can drive an entire experience while staying transparent and testable.

Why the Constraint Sharpens the Design

Come back one last time to the guiding idea. A fish-table game is a gamble in disguise, and the 13KB limit forces a developer to expose that gamble in its purest form — every byte earning its place. What emerges is a small, fast, honest little machine of risk and reward. And whether it runs in a jam submission or alongside the underwater shooters players already enjoy with Gold Coins and Sweeps Coins, the appeal traces back to that same irresistible loop: aim, fire, and hope.

🔙 Back to Articles list.