How I Used AI to Build an 80s-Style Game in a Few Days

Intro

An AWS Summit booth. A retro game. A LEGO Game Boy as the prize. That's basically the brief my company gave us for an internal contest called the "INO INO Gameboy Challenge": build a simple, 80s-style game that people can play in 10–30 seconds at the stand, with AI tools fully allowed and even encouraged.
I couldn't say no to that. In this post I'll walk through how I'm designing and building my entry, which AI tools I'm using along the way, and the trade-offs between "retro feel" and "playable in 20 seconds." Let's get into it.

The Game: Moon Patrol, Revisited

When I read the brief, my mind went straight to one place: Moon Patrol, Irem's 1982 arcade classic. It's one of the very first games I remember playing as a kid — a moon buggy racing across a cratered lunar surface, UFOs dropping bombs, and that unmistakable parallax scroll making the mountains drift lazily in the background. Not just a game. A time machine.
I had to actively push the nostalgia aside to get back to work. The idea was set: bring Moon Patrol back to life, with a little AWS Summit twist on top. Now I just needed a way to actually build it — without writing a game engine from scratch.

Setting Up the Workspace: The Skills

Before writing a single line of game code, I took a step back and thought about what kind of "team" I'd need if this were a real studio project. A retro arcade game is more than just code — it's game design, pixel art direction, and chiptune music, all working together. So I created three custom skills, each acting like a specialist I can call on when needed.
Here's a quick overview of each one.

retrogame-designer-expert — The Game Designer

This is the skill that thinks like a legendary 80s arcade designer. Its job is not to write code, but to produce a complete Game Design Document (GDD) before any development starts. Given a screenshot or a description, it deconstructs the visual style, infers the mechanics, and specifies every detail — sprite dimensions, color palettes, scroll speeds, HUD layout, scoring rules, atmosphere (CRT scanlines, cabinet frame, attract mode).
The output is structured enough that the next skill can implement it with zero guesswork. Think of it as the "creative director" of the project.

phaser3-expert — The Developer

This is the skill that turns the GDD into a working game. It specializes in Phaser 3 + TypeScript + Vite, with an obsessive focus on performance: object pooling, texture atlases, scene lifecycle discipline, and 60 Hz frame stability. It knows how to build a clean scene stack (Boot → Preload → Game → UI → GameOver), handle audio in dual format (.ogg + .mp3), and configure pixel-perfect rendering for that crisp retro look.
It's the skill I'll spend most of my time with once the design is locked. Think of it as the "lead engineer" of the project.

8bit-music-creator-expert — The Composer

A game without chiptune music is not an 80s game. This skill handles the soundtrack side: BGM loops, SFX design, and 80s-style dance/pop references when needed. It knows the hardware constraints of the NES, Game Boy, C64, and Amiga, and composes inside those limits for authenticity. It also covers classic synth patches and drum machine patterns (TR-808, TR-909) in case the game needs a more Hi-NRG or Italo Disco vibe.
Its role is to make sure the game sounds as retro as it looks.

Why Three Skills Instead of One

I could have dumped everything into a single big prompt, but splitting the roles gives me two real benefits:

• Separation of concerns. The designer thinks about feel; the developer thinks about performance; the composer thinks about sound. Mixing all three in one context creates noise and worse outputs.
• Reusability. These skills aren't tied to this specific contest — I can reuse them for any future retro game project.

With the team in place, it's time to brief the designer and start the real work.

The Work Plan: Agile Meets AI

With the game in mind and the skills ready, I needed one more thing before diving in: a plan. Jumping straight into code with an AI agent is tempting, but it's the fastest way to end up with a tangled mess. So I paused and asked for two documents, in order.

Tech Stack

First, I needed to pin down the technology stack. Leaving it fuzzy means the AI will decide silently — and not always well. The output was short and decisive: Phaser 3 + TypeScript + Vite, deployed on Vercel. Phaser 3 for the game engine, TypeScript for safety when AI writes large chunks of code, Vite for fast hot-reload, Vercel for free instant deployment. Boring, proven, exactly what you want on a short timeline.

Dividing the plan into iterations

Next, a detailed work plan split into 6 iterations. What came back looked exactly like a well-structured Agile backlog: each iteration has a clear goal and produces something playable at the end — from "a buggy driving on a scrolling ground" in Iteration 1, to polish and AWS branding in Iteration 6.

Why Agile Fits AI Development So Well

This wasn't a coincidence. Agile and AI-assisted development pair remarkably well:

• Short iterations match AI's sweet spot. "Build me a game" is a terrible prompt. "Add a scrolling ground with parallax mountains" is a great one. Iterations naturally produce prompts of the right size.
• Working software every sprint. You can play what was built, spot what feels off, and correct course immediately.
• Embrace change, cheaply. Rewriting a feature becomes a 10-minute conversation. Agile's tolerance for change stops being a principle and starts being a superpower.
• The human stays the Product Owner. The AI is fast and capable, but has no idea whether the game is fun. That's still my call. I'm the PO; the AI is the whole dev team.

Agile turns "vibe coding" into something closer to a disciplined sprint — just faster. Stack defined, iterations laid out, time to build.

The Implementation: Feedback Loops on Steroids

With the plan locked in, I stuck to Agile: one iteration at a time, no shortcuts.
The loop was simple: ask the developer skill to implement Iteration N, play it, file a Change Request if something felt off, adjust, then move on. Only once the iteration felt right did we move to the next.

The Feedback Loop Is Everything

This is where AI-driven development really shines. In classic development, feedback loops are slow and expensive. With AI, the same cycle collapses into minutes:

• Plan → short conversation
• Build → AI ships the code
• Play → 60 seconds of testing
• Adjust → another short conversation

The shorter the loop, the more the product evolves toward what actually feels good — not what looked good on paper.

Why This Matters More with AI

With AI, the cost of change drops to nearly zero. That means saying "this doesn't feel right, let's redo it" costs nothing. And I said it many times — on jump physics, spawn rates, scroll speed, HUD layout. All tuned by playing, not by guessing.
Agile has always said "respond to change over following a plan". With AI in the loop, that stops being aspirational and becomes the default.

What Didn't Work: The Music

Not everything went smoothly. The part that gave me the most trouble was the music.
Using the 8bit-music-creator-expert skill, I tried to generate an 8-bit arrangement of A-ha's "Take On Me" — feeding it sheet music, keyboard tabs, every reference I could find. The result was never quite what I had in mind.
That said, what came out was still a solid 8-bit track that fit the game perfectly. So I kept it, with a mental note to revisit the topic properly another day.
In fairness: I spent very little time on this, mostly in spare moments between other tasks. With more focused effort, I'm sure the result would have been much closer to what I wanted.

Conclusions

It's genuinely incredible how, in just a few months, coding with AI agents has reshaped the way we think about software — and how fast we can ship real things. "Vibe coding", "AI-native development", "prompt-to-prototype" — the hype is everywhere, and for once, it's not entirely wrong.
But here's the part the hype always skips: discipline and method are non-negotiable. Without them, this isn't engineering — it's improvisation. Improvisation is fine for throwaway demos, but if you want to build something robust, reliable, production-ready, you still need the same fundamentals we've always needed: clear requirements, a solid plan, short iterations, tight feedback loops, and a human driving the vision.
AI doesn't replace engineering. It amplifies it. The developers who'll thrive aren't the ones who stop thinking — they're the ones who bring more structure, not less, to a workflow that suddenly moves ten times faster.
Game on. 🕹️

👉 Source code: github.com/massimobiagioli/crew-moon-patrol