No. 02 · Case study · Browser game
Splash Olympics
Rebuilding a teenage favourite with an AI, one playtest at a time
As a teenager I lost hours to Dolphin Olympics, a Flash-era browser game: you dive deep, build up speed underwater, burst out of the pool, and do flips in the air. I asked my AI assistant to rebuild it from scratch. It wrote every line of code, drew every graphic and made every sound. My job was to play it and say what felt wrong.
Play it What we built
The whole game is one self-contained HTML file. There are no image files, no audio files and no libraries. Every graphic is drawn in code on an HTML canvas, and every sound (splashes, flips, wind, warning ticks) is generated live in the browser with the Web Audio API. My AI assistant, which runs on Grok Bot, made all of it.
Underneath sits real game physics. There’s gravity, and there’s water you dive into to build speed. Your launch power grows with every clean dive entry, and a perfect entry boosts it more. A belly flop costs you power and your combo.
The camera zooms out the faster you fly. You can climb from the pool past seagulls, hot-air balloons, planes, satellites, astronauts and UFOs, out past the Moon and the planets to Pluto. And there are nerdy easter eggs on the way: Hubble, the ISS, a falling whale and a pot of petunias, a towel, a roadster in space, Voyager and a teapot in orbit. Altitude 42 gives a bonus for “the answer to everything”, and right at the top sits the Diner at the End of the Galaxy (“So long, and thanks for all the fish”).
Front flips and back flips are scored separately, with a bonus for mixing them. Touch the sand at the bottom of the pool and the game is over. There’s a five-minute clock, a local top-5 leaderboard, and live alerts when you’re close to your record, in the top 5, or beating it.
Five versions, driven by playtesting
I never wrote code. Every round went the same way: the assistant shipped a version, I played it, I described what felt off in plain language, and the next version fixed it.
- The core loop. Diving, launching, flipping and splashing down.
- A bug report. “When I come down from above 300 km, the camera stops following the dolphin.” The assistant added a camera that always keeps the dolphin in frame, biased towards the top of the screen when you fall fast, so you can see what’s coming.
- Rule changes. Drop the original time limit, make hitting the pool floor end the game, and count front flips and back flips as separate bonuses. I also asked, half-joking, whether the “restaurant at the end of the galaxy” existed. It does now.
- Game feel. “The fall back to Earth is too fast, the easter eggs blur past, and it’s nearly impossible to lose.” The assistant removed the time-acceleration on the way down and zoomed out at speed instead. It tightened the margin for error, brought back a total time limit of five minutes, and added the record system.
- Polish. More variety (seven different balloon designs), more easter eggs, and full sound.
Who did what
The assistant did all the code, all the graphics and all the sound design, and it tested its own work. It ran the game in a headless browser (a browser without a window, driven by a script) with a bot that played automatically, took screenshots during the descent from maximum altitude, and checked for errors and a smooth 60 frames per second. That test caught real problems. The Diner, for one, was out of reach even at maximum power, and the assistant fixed that by rebalancing the game before I ever saw it.
My part was the vision (“make it like the game I loved”), the playtesting, and the judgement calls about what felt fun. The assistant could measure frame rates. It couldn’t feel whether a fall was boring or a jump was satisfying, and it couldn’t hear its own sound effects. That part stayed human.
What you can learn from this
- Describe feelings, not fixes. “The fall is too fast and I can’t see the easter eggs” worked better than prescribing a solution. The assistant found a better fix, zooming out, than the one I would have suggested.
- Ship small and play every version. Five quick rounds beat one giant spec.
- Split the testing. Let the AI test what it can measure: errors, performance, whether a goal can be reached. Keep what it can’t measure for yourself: fun, timing, sound.
- Keep a backup of every version, so you can always go back.
- Expect some friction. Long runs of work sometimes left me wondering whether anything was happening at all. Asking for a status update is normal and fine.
- Constraints help. “One HTML file, no assets” kept the project simple to host and easy to share.
Same game, five other models
Once the game was finished, I wrote down everything those five rounds had taught me as one brief and gave it to five other AI models, each with one go and no feedback. Same concept, very different games. Play all six versions and see how they compare.
Slightly off topic, but not really
Back then, this kind of game needed the Flash plugin, and it lagged. Today it’s a standalone HTML file that runs smoothly in virtually any browser.
Self-contained interactive HTML files like this one are something current AI models are incredibly good at making. You can send one by chat or email, and they get information across very well. At Carewell we use them all the time to explain things to each other: rules, processes, concepts, anything. That works much better than a PowerPoint presentation or a boring text file. If you want to see the idea applied to something practical, The Weekend Trip That Came With Its Own App is one.
A prompt to start from
Try it yourself
Pick a game you loved and start with a prompt like this:
Recreate [game] as a single HTML file with no external assets. Draw all graphics in code on a canvas and generate the sounds with the Web Audio API. Start with just the core loop. Then I'll playtest it and tell you what feels wrong.
Play it, describe what feels off, and repeat.