Part 1 : Building a Game in 30 Hours Using AI — Here's the Actual Timeline

Source: Dev.to

What Happens When You Treat AI as a Development Partner Instead of an Autocomplete Tool?

I wanted to find out, so I ran an experiment: build a game as fast as possible, prioritising speed and iteration over polish. No extensive planning phase. No detailed specs. Just prototyping at velocity to see what’s actually possible.

The result is MagLava – a magnetic platformer where you swing between nodes to escape rising lava. Six development sessions, roughly 30 hours of work, and a published game with 25 levels, 7 language translations, and a desktop app.

Note: This approach was the point of the experiment. For production software or anything beyond rapid prototyping, proper planning and testing remain essential (I’ll write a post about that later). Here I’m stress‑testing the opposite extreme.

The Commit Log

I commit frequently using an AI tool that generates summaries after each task, so commit clusters map well to actual work sessions. I went through my Git history and reconstructed the timeline:

Notice the gaps: nine days between Dec 21 and Dec 30, and sixteen days before the final session. The calendar says “one month of development,” but the reality is about a week of actual work, scattered across that month.

What “AI‑Assisted” Actually Meant

The first day alone produced 6,555 lines of code – project structure, game config, menu systems, routing, storage services, the event bridge between Vue and Phaser. That scaffolding would have taken me days to write manually.

The surprising part wasn’t the code generation; it was what else emerged:

• Promotional website with SEO, sitemaps, and structured data – AI‑built.
• Full Electron desktop app with a level editor – same story.
• Internationalisation system supporting 7 languages – implemented in a single session.

I didn’t set out to have AI handle all of these. They emerged because, once you’re in a flow state with an AI partner, the friction for “one more feature” drops dramatically. Adding a desktop build went from “future roadmap item” to “let’s just do it this session.”

The Method Behind the Numbers

You might have heard the term “vibe coding.” In this case it meant staying in player mode and describing problems experientially rather than technically. Here’s an actual prompt from one of my sessions:

game just freezes! I can't actually SEE the LAVA LINE!!! I WANA SEE THE LAVA line.
And finally, we start way too close to the lava.

Typos, caps lock, frustration – all of it. I didn’t calculate a pixel buffer. I expressed a feeling of unfairness. The AI translated “way too close” into a concrete fix: increase the spawn buffer from 150 px to 500 px above the lava line.

This only works because emotion is a valid technical spec when your goal is player experience. “This feels unfair” contains more design information than “adjust the Y‑offset parameter.”

Why the Timeline Matters

I’m not claiming 30 hours is fast or slow – game complexity varies wildly. What I am claiming is that this timeline was possible because of how I worked, not just the tools I used.

The traditional solo‑dev pipeline looks like this:

1. Plan extensively.
2. Build the architecture.
3. Implement features.
4. Test.

You front‑load decisions before you have information.

My pipeline inverted that:

1. Build something immediately.
2. Play it.
3. Describe what feels wrong.
4. Iterate.

The AI handled the translation from “this sucks” to “here’s the code change.” Every system stayed disposable. Every change stayed focused and modular. When something wasn’t working, I didn’t defend it – I described a different vision and let it get rebuilt. That’s hard to do when you’ve personally written every line; it’s easy when you’re directing rather than typing.

What the Numbers Don’t Show

The timeline looks clean in retrospect. It wasn’t.

Day 3 – the massive 27‑commit session – included throwing away the entire movement system I’d built on Day 2. The original concept was polarity‑based climbing: red platforms attract, blue platforms repel. I built the whole thing, played it, and it felt indirect, frustrating, disconnected from what I actually wanted.

So I described something different: “I want swinging. Like Spider‑Man but with magnets.” Within hours the game had a completely new identity.

That pivot – and one other major pivot that came later – are probably the reason MagLava works at all. But that’s a longer story.

Next in this series: The two pivots that almost killed the project, and why emotional prompts caught problems that specs would have missed.

Play MagLava | itch.io page

Tech stack for the curious: Vue 3 + Vite, Phaser 3, TypeScript, Electron (desktop), Firebase + itch.io (hosting), Claude (Opus via Claude Code CLI) for AI assistance.