The Game I Always Wanted to Make: How AI Let Me Finally Build My Childhood Obsession

I’ve been carrying a game in my head for forty years.

Not a design document. Not a spec. Not even a napkin sketch. Just a feeling — the specific feeling of hearing a Commodore 64 say “HEY, TAXI!” through a speaker that had no business producing human speech in 1984. I was ten. The computer talked. I’ve wanted to rebuild that moment ever since.

I never did. Not in college, not during my first engineering job, not during twenty years of increasingly senior roles where I shipped software for other people every day and came home too drained to ship anything for myself. The game stayed in my head, perfectly preserved in amber, right next to the memory of a friend’s notebook where he logged every high score in pencil.

Last week I built the whole thing in a day. 8,143 lines. 26 levels. Four characters loosely inspired by real friendships. A procedural audio engine that synthesizes speech from raw waveforms. A rival taxi that steals your passengers. A cutscene system that tells a story about four 50-year-old men becoming kids again. Zero sprite assets — every pixel drawn from math.

(A note: the characters in the game are affectionate caricatures — real names, exaggerated personalities, turned up to eleven for comedy. Nobody actually talks like their in-game version. Except maybe about the pizza.)

The tool was Claude Code. But this isn’t a post about AI capability benchmarks. This is a post about the shelf. The one in your head, where the project you’ve always wanted to build has been sitting for five, ten, twenty years — gathering dust because life is long and evenings are short.

The Shelf

Every engineer I know has a shelf. Some version of “I’ve always wanted to build ___.” A particular game. A specific tool. An app that scratches an itch nobody else has. The ideas don’t die — they just recede, year after year, behind the daily work of building things for someone else.

The shelf isn’t about skill. I could have built Space Taxi in any of the last twenty years. I had the ability. What I didn’t have was the budget — not money, but the emotional budget to spend 200 hours of evenings and weekends on something that might not work, might not be fun, and would definitely come at the cost of sleep and family time.

That’s the real cost of pet projects: not the technical challenge, but the risk of investing limited free time and ending up with an unfinished src/ directory that makes you feel worse, not better. Most of us have been burned by this. You start a side project on a Friday night high. By Sunday you’re staring at a half-working prototype that needs 10x more time than you have. It goes on the shelf. It stays on the shelf.

The Prompt That Started It

Here’s roughly what I told Claude on a Monday morning:

Rebuild Space Taxi — the 1984 Commodore 64 game by John Kutcher. Godot 4, pure GDScript, all rendering done with _draw() — no sprites, no textures, no image assets. The game should feel like the original: gravity pulls you down, thrust pushes you up, land on numbered pads to pick up and deliver passengers, land too hard and you explode. But make it about four real people: Eric, Steve, Pierre, and Tony. They’re childhood friends. Give them personalities. Make it funny.

That’s it. No design doc. No wireframes. No Jira epic with 47 subtasks. Just a paragraph describing a feeling I’ve carried since 1984.

Forty-six minutes later, the first commit landed: 3,199 lines of working code. A playable game with 10 levels, 4 characters, taxi physics, crash debris, a cutscene system, procedural audio, and a CRT overlay. Not a prototype. Not a scaffold. A game I could hand to someone and say “play this.”

Was it done? No. Was it the game in my head? Not yet. But it was real. For the first time in forty years, the thing on the shelf was a thing on a screen.

The Love Is in the Iteration

The initial build was impressive and hollow. It had the mechanics, the structure, the bones — but it didn’t have the thing. The thing that made Space Taxi matter wasn’t the gameplay. It was the voice. The personality. The feeling of a machine reaching out and talking to you.

So the day became about that. Not writing code — describing people.

I told Claude about the archetypes from our group — the optimizer who tracks everything in notebooks, the storyteller who turns every moment into narrative, the quiet pragmatist whose highest praise is “Understandable,” and me, the one who suggests pizza as conflict resolution. Real traits, cranked way past reality for comedy. Nobody in my friend group actually gives stock tips while waiting on a floating platform in space. But the energy is right.

Each description generated 20 idle lines per character. Some of them were perfect on the first pass — “I’m calling it: heads!” needed no editing, because that’s the exact cadence of a certain kind of friend. Others needed work. Claude’s first attempt at my character’s lines made him too self-aware. The real version of that guy doesn’t know he’s the heart of the group. He just orders pizza and worries. I adjusted, Claude regenerated, and the lines landed.

The guilt-trip quotes for passenger deaths were the most collaborative part. I gave Claude the structure — “when you crash with a passenger on board, the game should make you feel terrible in a funny way” — and it came back with lines like “Eric was 3 days from retirement” and “Eric’s spreadsheet will never be completed.” We went back and forth until each character had six quotes that fit their in-game personality. “Tony’s pizza is getting cold. Forever.” works because the game establishes Tony as the pizza guy. Claude can’t know your friends. But Claude can build on the characters you describe and turn them into quotes that land.

This is what I mean by the love being in the iteration. The AI doesn’t know the people who inspired your characters. It doesn’t know the specific rhythm of forty years of shared jokes. What it does — remarkably well — is take that context and run with it. You describe the feel. It builds the system. You react to what it built. It adjusts. The loop is fast enough that you can have the conversation you always wanted to have with your code, where you say “no, more like this” and the code changes in seconds instead of hours.

Describing Feel, Not Implementation

The best prompts were the ones where I stopped thinking like an engineer and started thinking like a player.

“Crashes should feel dramatic when you have a passenger.” I didn’t specify slow motion, or camera zoom, or ragdoll physics, or guilt-trip text. I described a feeling. Claude produced the entire system: time scale drops to 0.2x, camera zooms to 1.4x on the crash point, screen shake at intensity 14, the passenger’s body separates into six parts — head, torso, two arms, two legs — each with independent velocity, rotation, gravity, and platform collision. They tumble and scatter and bounce off platforms in slow motion while text fades in: “Pierre’s last words: ‘Understandable.’”

That’s about 80 lines of code across three functions. It took one prompt and maybe 20 seconds of generation. To build that by hand — the physics, the timing, the camera work, the text overlay — would have been a solid evening of work. Not because it’s hard, but because the iteration cycle of change-compile-test-adjust is slow when you’re tuning feel.

“Passengers should get impatient if you take too long.” I expected a timer and a complaint. Claude built a rival taxi service called GUBER. When your fare timer hits zero, the passenger yells “I’m calling GUBER!”, a green taxi descends from above with a wobble animation, picks up your passenger, and flies away — taunting you with lines like “Your taxi license came from a cereal box.” Three GUBERs and you’re fired.

I didn’t ask for any of that. I described impatience, and the AI found a game mechanic inside it. The GUBER system turned out to be one of the best features in the game — it creates genuine urgency, it’s funny, and it punishes you in-fiction rather than with a arbitrary timer. That came from the AI, not from me.

“The voice synthesis should sound like the original C64 but chunkier.” Claude built a syllable-by-syllable speech synthesizer that constructs “Pad 3, please” from noise bursts, saw waves, and square taps at 22,050 Hz, with envelope shaping for each phoneme. Forty-two years of audio engineering condensed into a GDScript function. The result sounds like a drunk robot doing a C64 impression, which is exactly right.

What the Human Brings

There’s a narrative in tech right now that AI replaces the human in the loop. After building a complete game in a day, I can tell you exactly what it replaces and what it doesn’t.

What AI replaced: Typing. Boilerplate. The mechanical translation of ideas into syntax. The tedious parts of game dev — collision detection edge cases, input mapping across three platforms, state machine transitions, the fiddly math of making a camera zoom feel right. The 6,600 lines of GDScript that implement the systems.

What AI cannot replace: Knowing that one character should suggest pizza during a crisis because that’s what the real inspiration would do. Knowing that a childhood notebook full of high scores matters to the story. Knowing that “Understandable” is funnier than any elaborate punchline for a certain kind of person. Knowing that the game should be about friendship, not scores. Knowing that the specific sound of a Commodore 64 voice chip in a wood-paneled basement in 1984 is the feeling the whole project needs to serve.

The creative direction, the emotional core, the lived experience that turns a game engine into a love letter — that’s yours. That was always yours. AI didn’t give me a new ability. It removed the bottleneck between the game in my head and the game on the screen.

The 200-hour budget I never had? It’s a 16-hour Saturday now. Not because the work is simpler, but because the ratio between deciding what to build and building it has been inverted. I used to spend 20% of my time on creative decisions and 80% on implementation. Now it’s closer to 70/30. The thinking is the work. The typing is handled.

Zero Sprites, Zero Excuses

One technical decision made this whole thing possible: no assets.

Every visual in the game is drawn with Godot’s _draw() function — polygons, rectangles, circles, lines. The taxi is a 10-vertex polygon with a checkered stripe drawn from individual rectangles. Passengers are stick figures with articulated arms. Stars are circles with sine-wave brightness. The entire game is math and text.

This means the AI can read, write, and modify every visual in the game through code alone. No sprite sheet to edit in Photoshop. No texture atlas to repack. No binary asset formats. When I said “give Pierre a chef hat,” Claude added 8 lines of polygon coordinates to the costume drawing function. Done. No asset pipeline. No round trip to a graphics tool.

The code-only architecture is an enabler for AI-assisted development in a way I didn’t fully appreciate until I was in it. If your game’s visuals live in PNG files, the AI can’t touch them. If they live in code, the AI can iterate on them as fast as it iterates on gameplay logic. The decision to draw everything procedurally wasn’t an artistic choice — it was an accessibility choice for the tooling.

Is it pretty? It’s stick figures and rectangles. But it’s consistent stick figures and rectangles, with costume accessories that persist through ragdoll deaths and crash debris that bounces off platforms with proper physics. Polish doesn’t require fidelity. It requires attention to detail, and attention to detail is cheap when your iteration cycle is measured in seconds.

The Numbers

Because I know HN will ask:

Metric	Value
Total lines of GDScript	8,143
Script files	18
Scene files (.tscn)	1 (a 6-line bootstrap)
Story mode levels	10
Gauntlet mode levels	16
Cutscenes with dialogue	12
External image assets	0
External audio assets	44 MP3 voice lines (optional — game runs without them)
Development time (wall clock)	~16 hours across one day
Lines at first playable commit	3,199
Input methods	3 (keyboard, touch, gamepad)
Git commits	11
AI tool	Claude Code (Opus 4.6)

The Point

I’m 50 years old. I’ve been a software engineer for 25 years. I’m a Director of Engineering at Samsara. I ship software for a living and have shipped software at scale for most of my career.

And the thing I’m proudest of this month is a game about a stick-figure taxi picking up stick-figure passengers on floating rectangles, set to procedurally generated bleeps that sound like a drunk Commodore 64, wrapped in a story about four idiots who still argue about the same video game after forty years.

I built it in a day. Not because AI is magic, but because AI eliminated the part that always stopped me: the sheer volume of mechanical work between “I know exactly what this should be” and “it exists.” The gap between vision and artifact used to be hundreds of hours. Now it’s a conversation.

If you’ve got a game in your head — a tool, an app, a thing you’ve been carrying around for years — the shelf is optional now. The emotional budget calculation has changed. The risk of starting a side project and ending up with an abandoned src/ directory is genuinely lower when you can reach a playable state in an afternoon instead of a month.

Take the thing off the shelf. Describe what it should feel like, not what it should do. See what happens.

Play It

You can read the full technical making-of here, or just play it:

Open Fullscreen

Controls: Arrow keys or WASD. Gamepad supported. Land softly. Pick up passengers. Deliver them. Don’t crash with someone on board — the guilt is worse than the score penalty.

Based on Space Taxi (1984) by John Kutcher for the Commodore 64.