Building an 80s-Style Game in a Few Days with AI: Phaser 3 and Role-Split Skills (dev.to)
Contents
A dev.to post about Claranet’s internal AWS Summit contest “INO INO Gameboy Challenge” crossed my feed.
The challenge: build an 80s-style game playable for 10–30 seconds at a booth, with a LEGO Game Boy as the grand prize, and AI tools fully encouraged.
The author took the 1982 Irem arcade classic Moon Patrol as a base and shipped “Moon Patrol Revisited” in a few days.
It’s a lightweight browser game built on Phaser 3 + TypeScript + Vite, hosted on Vercel.
A typical indie dev stack, recreating the 80s feel without reaching for heavy engines.
What I found interesting wasn’t the finished product itself, but the design choice of splitting into three role-specific skills rather than throwing one giant prompt at the AI.
This is the same structure that’s been gaining traction with Claude’s Skills feature and recent agent-style tools, and retro game development happens to be an especially good match for that kind of split.
Contest constraints
Briefly, the constraints looked like this.
- Playable standing at an AWS Summit booth, one play ending in 10–30 seconds
- 80s-style visuals and sound (the contest theme)
- AI tools OK, actively encouraged
- The deliverable is a playable prototype for internal attendees
In short, it’s a hackathon-flavored situation where “there’s no time to build properly, but the spec is clear,” which is a near-ideal fit for AI-assisted development.
The central point of the article is that, instead of “throw everything at one AI agent to save time,” the author chose to split the skills.
The 80s constraint and the 10-second constraint aren’t accidents
At a glance these look like pure nostalgia, but they land neatly at the intersection of booth exhibition and the “AI allowed” culture.
Booth games have different design assumptions from regular indie games.
A game on Steam or itch.io is played by someone who chose to buy it and puts in hours, but a booth game exists to stop passers-by and create a conversation starter, so 10–30 seconds isn’t decoration, it’s a number worked out in reverse. Time available for players to understand the rules is close to zero, one button must be enough, and a failed run just means the next person gets a turn. Moon Patrol-style horizontal-scroll one-button games got picked not just from nostalgia, but because “one button, left→right, die fast” is structurally booth-shaped.
The same 10-second framing was the design axis when I helped ship Meshide Software “Ten Second Dash!” on Steam — a short runtime looks like it’s killing game depth, but it actually sharpens the design.
When you think about it, 1980s arcades were also short-play games for passers-by dropping 100-yen coins.
Insert coin → instant start, one or two buttons, clear lose condition, and the rules fit on a sticker on the side of the cabinet.
They’re the original booth games, so the INO INO ”80s style” constraint isn’t just pixel-art nostalgia — it’s borrowing a proven design template. Inventing a 10-second game from scratch is hard, but arcade games have decades of refined templates to draw from.
On the visual side, 80s style also plays well with AI generation. Sprites at 32×32 to 64×64, a constrained palette, no lighting or shadows, 2D rectangular collision. In short, none of the things AI tends to break on even exist here.
3D shaders and physics simulation fall apart fast when handed to AI, but pixel art and 2D sprites don’t. On this blog, I’ve looked at how AI-driven pixel-art conversion actually holds up in Can Qwen Image Edit convert photos into pixel art? and Trying pixel-art conversion with Z-Image i2i. It’s not quite at the “mass-producing game assets” tier yet, but 80s-style visuals are clearly in the range AI handles well.
The organizer’s aesthetic preference is only part of the story — it’s fair to read this constraint as a realistic scoping decision to make AI use feasible.
One more thing: INO INO wasn’t just “AI tools allowed” but explicitly “encouraged”.
Around 2023–2024, internal hackathons usually called out “AI allowed / not allowed” as a rule. In 2026, the unnatural choice is forbidding AI. The event-operations side is starting to bake AI into its design, and this is one of those examples.
Don’t use one giant prompt — split into three skills
The author built three custom skills.
Similar to Claude’s Skills, each one is a specialized role with its own system prompt, reference material, and output format.
| Skill | Role |
|---|---|
retrogame-designer-expert | Writes the Game Design Document (GDD). Handles “designer-side decisions”: visual spec, color palette, scroll speed, scoring rules, etc. |
phaser3-expert | Implementation. Writes code in Phaser 3 + TypeScript + Vite while watching performance |
8bit-music-creator-expert | Sound. Creates 8-bit-style BGM and SFX |
The key point of this split is that it’s cut by role.
”Let one AI handle design, implementation, and composition all at once” just bloats the prompt and guarantees that at least one area ends up worse.
The author’s reasoning is straightforward: designers think in feel, developers care about performance, composers think in sound, so keeping them unmixed produces better output.
Another stated reason is “reusability.”
The phaser3-expert skill can be lifted as-is into the next game project.
A one-shot mega-prompt gets thrown away next time, but skill-sized pieces accumulate.
flowchart LR
A[retrogame-designer-expert<br/>writes GDD] --> D[Game Design Document]
D --> B[phaser3-expert<br/>implements]
D --> C[8bit-music-creator-expert<br/>composes]
B --> G[Moon Patrol Revisited]
C --> GThe diagram looks obvious once drawn, but what makes it work is that the author actually makes the AI respect the flow: “design is locked in as a document first” → “implementation and music run in parallel” → “everything merges at the end.”
Six iterations, each one producing something playable
The other thing worth stealing is how the iterations are carved up.
The author split development into six iterations, and each one was required to ship in a state where “something about this build is playable.”
Only two milestones are named explicitly in the article.
- Iteration 1: A buggy rolls over scrolling ground
- Iteration 6: Polish and AWS branding pass
The intermediate iterations aren’t detailed, but the “ship something playable every round” constraint clearly makes it hard to fall apart even when you lean heavily on AI.
The reason is that skill-split output doesn’t get merged all at once at the end — you run a short feedback loop where every round ends with a live playtest and a differential request to the next skill.
The same principle shows up in AI-coding production work, which I wrote about in Design principles for putting AI coding agents into production, covering compaction and real-world incidents around short iteration loops.
At the scale of personal development, the principle is the same. In fact, on this blog’s Soba-eating game dev progress posts, each update is also shipped in a “does this shape work?” playable state, and the cut ends up the same even without AI in the loop.
The tech stack stays lightweight
Game engine: Phaser 3. Language: TypeScript. Bundler: Vite. Hosting: Vercel.
Choosing Vercel probably comes down to the contest context: “share a URL, open it on the booth’s machine, play.” The convenience is hard to beat.
Not reaching for Unity or Godot is the right call for a 10–30-second game running at a venue.
Phaser 3 is an HTML5 Canvas–based 2D game engine that can switch between Canvas and WebGL.
For just moving 8-bit pixel art around, it’s lightweight enough that mobile browsers can handle it reasonably well.
And since it’s typed, phaser3-expert-style specialized AIs find the codebase easier to read (symbol names and types are explicit).
Part of why AI-assisted implementation clicks here is that LLMs can lean on existing type information.
On the broader topic of self-built browser games, I’ve also written scattered prototype-level posts like Soba-eating game prototype build, Writing an ADV game engine from scratch, and Card game prototype spec.
What they share is getting to a “playable minimum runtime” as fast as possible, and Moon Patrol Revisited’s Phaser 3 + Vite + Vercel setup sits on the same line.
On the “have the AI produce game-side data” angle, I’ve also written Pulling RPG parameters out of character images with a local Vision LLM, feeding images and asking for HP, attack, and abilities as JSON. If retrogame-designer-expert is AI as a role, the RPG-parameter experiment is AI as an asset source, and game × AI work roughly splits into these two lanes.
Music was the hard part
What resonated, and what the author admits honestly, is how hard the music generation was.
He aimed for an 8-bit arrangement in the spirit of A-ha’s “Take On Me,” but the generation AI wouldn’t land it, and he ended up “taking what he got.”
Visuals and code come out of AI reasonably well, but the bar for what the ear accepts is far stricter than the bar for what the eye accepts.
This is a classic individual-dev trap. 8-bit sound looks simple at first glance, but there are more steps than expected:
- Analyzing the melody of a reference track (basically transcription)
- Picking waveforms (square, triangle, noise, etc.)
- Tuning tempo and length
- Balancing volume against game SFX
If you want to offload this to AI, breaking 8bit-music-creator-expert down further into “song sketch,” “sound selection,” and “mix notes” is probably more realistic than chasing a finished track in one shot.
From the article’s structure, the music skill reads as the one left at a higher level of abstraction, without being drilled down the way the others were.
Music-generation AI itself isn’t nonexistent, though — a few production-grade options have shown up in the last couple of years.
| Tool | Notes |
|---|---|
| Suno / Udio | Commercial services that generate full songs with vocals from a text prompt |
| MusicGen (Meta AudioCraft) | Open-source music-generation model, runs locally |
| Stable Audio (Stability AI) | Stability’s audio generation, also suited to short SFX-leaning output |
The catch is that none of these pair all that well with 8-bit / chiptune.
The output is 44.1 kHz stereo, and it tends toward a “modernly mixed retro vibe” built on reverb and layered parts. It’ll pass a casual “sounds like a retro game” test, but the hardware-origin constraints that actual chiptune has — the “3–4 channels of square, triangle, and noise waves” and “no sampling” — aren’t reproduced.
Realistically, the sensible shape is a two-stage pipeline: use AI to sketch melodies and chord progressions, and let a tracker (FamiStudio / FamiTracker / Deflemask, etc.) render the final sound.
Why “skill split” works, compared with other cases on this blog
The main value of this dev.to post is that it demonstrates the “don’t throw one giant prompt at the AI” principle on a concrete game-development example.
I’ve looked at the same idea from different angles on this blog before.
First, in UI UX Pro Max Skill: Comparing a UI-focused Claude skill with earlier posts, the subject was a skill that delegates UI/UX decisions to AI.
That one also cuts off a specialized role from a style/color/font/industry-rule database, the same construction as retrogame-designer-expert.
The difference is that the UI skill is mostly referring to an existing database, while the retro-game GDD is generated fresh every time.
Next, After reading an OSS project that “distills a colleague into AI,” I looked into my own distillation approach covered an OSS direction that captures how a person works and turns it into a skill.
Claranet’s three skills are close cousins if you read them as “distilled job functions.”
One of the interesting properties of Claude Skills and similar frameworks is that the skill unit can be defined either per-person or per-role.
A slightly different comparison: Wiring Claude Code and Codex together with tmux and letting them build a game overnight (practical edition) was an experiment where separate agents argue overnight and produce a game.
That one is “run the same role through two AIs for automation.”
This one is “split the different roles across three AIs for a process design.”
The goals are similar, but one sides with “bet time, earn volume,” while the other sides with “carve the process, earn quality.” The opposite pair is what makes the comparison fun.
For individual AI-driven builds, the choice usually comes down to whether the goal is one finished product or a lot of trials.
Gotchas when copying the approach
This kind of post has some landmines if you actually try to copy it, so a few things stand out.
| Gotcha | Detail |
|---|---|
| Lock in the GDD first | Run the equivalent of retrogame-designer-expert independently for the first several hours. Changing the spec later costs double, once for implementation and once for music |
| Phaser 3’s type definitions are AI-friendly | Paired with TypeScript, the implementation skill’s reproducibility goes up. Raw JS to AI is a hallucination greenhouse |
| Treat music as an independent project | Keep it as a swap-out asset that plugs in at the last stage of the build. If the generated music isn’t great, you can replace the whole thing cleanly |
| Play the build every iteration | Stack AI-generated builds without testing and after three iterations your physics will be silently broken. 30 seconds of hands-on per round is enough |
| Vercel deploys are fast to share | For hackathon workflows, the preview-URL pattern is especially strong |
If I were doing this with my own assets
Writing all this, I started wanting to try it myself. Lining up the past posts and the tools I have at hand, this approach looks like it would reproduce reasonably well.
Here’s the inventory of material on this blog that could serve as groundwork.
- The Soba-eating game progress series (accumulated GDD and prototype decisions)
- Writing an ADV game engine from scratch (design notes on a custom engine)
- Card game prototype spec (slot / AP / CPU-logic design experience)
- The 10-second loop design experience from Ten Second Dash!
- The pixel-art conversion experiments: Qwen Image Edit / Z-Image
- Pulling RPG parameters out of character images with a local Vision LLM (images → JSON data conversion)
Feeding all of these to Claude Code as Skills reference material lets me layer my own weight onto Claranet’s three-skill structure. Mapped against the tools I have (Codex / Claude Code / Gemini CLI / local LLMs / generative AI), the rough division of labor looks like this.
| Stage | Tool | Purpose |
|---|---|---|
| GDD (designer role) | Claude Code + Skills | Feed past GDDs as references. The 10-second-loop knowledge from Ten Second Dash! can be recalled as well |
| Implementation (Phaser or custom engine) | Codex | High code-generation throughput. Passing TypeScript type definitions cuts hallucinations |
| Pixel art / asset generation | Local generative AI | The pixel-art conversion experiments slot directly into this pipeline |
| 8-bit music / SFX | Local LLM + owned audio assets | The weak spot even in the dev.to post. Give up on full generation and lean manual |
| Overall review / integration | Gemini CLI | Use the long context to read the whole codebase + GDD + assets in one sitting |
The obvious subject to apply this to is rerunning the in-progress soba-eating game through this workflow.
The GDD and prototypes from the progress posts are material I can feed directly into the three-skill structure, so it’s faster than inventing a different game from scratch.
Trying to split every stage across different tools from day one has the trap that you spend more time deciding who does what than actually shipping.
The pragmatic path is to first run GDD + implementation end-to-end through Claude Code alone until there’s a working build, and only split across tools when it’s time to raise quality.
The post wraps up with the author’s own quote: “AI doesn’t replace engineering, it amplifies it” — the standard line.
It’s become an AI-book cliché, but for the Moon Patrol Revisited case specifically, it isn’t wrong.
The situation where “even if implementation speeds up, game design and music still bottleneck you” really does happen, and splitting by skill is a direct attempt to design for it.
Personally, what I want most is the “LEGO Game Boy contest prize.”