I recently completed KiroweenGBC, a supernatural action shooter built entirely in Z80 assembly for the GameBoy Color. This project was an exciting journey into retro game development, combining the nostalgia of 8-bit gaming with the raw challenge of programming directly on the metal.

The story follows Kiro, a brave ghost who must battle evil spirits that have been corrupted and taken over by AI forces threatening to destroy the world. The goal was to create an authentic action shooter experience that would feel right at home alongside classic GameBoy titles, with smooth movement, satisfying combat mechanics, challenging supernatural enemies, and that unmistakable retro aesthetic.

Working directly with GameBoy assembly meant every byte, every cycle, and every memory access mattered. The GameBoy Color’s Z80-derivative CPU runs at just 4.19 MHz, with only 32KB of cartridge space and 8KB of working RAM to play with. These constraints force you to think creatively about every system.

The game architecture revolves around a clean state management system with three main states:

• Title Screen - Welcoming players with classic arcade-style presentation
• Story Mode - Brief narrative setup introducing Kiro’s supernatural mission
• Gameplay - The core action where Kiro battles AI-corrupted spirits

The Development Experience

Let’s be honest—writing assembly code for 1990s hardware isn’t exactly a common task these days. The Game Boy Color uses a modified Z80 processor, requires careful timing around VBlank periods, and has strict memory constraints. There’s no garbage collector, no standard library, and definitely no Stack Overflow answers for "why won’t my metasprite render correctly?"

But that’s exactly what made this project interesting. Could an AI assistant actually help with something this niche and technical?

Rather than diving straight into code, I used Kiro’s spec feature to formalize what I wanted to build. I created three documents:

• Requirements: Eight clear user stories covering hero movement, enemy spawning, collision detection, and the build system
• Design: A detailed technical architecture including memory layouts, data structures, and the game loop
• Tasks: A step-by-step implementation plan with 8 major milestones and 30+ subtasks

This upfront planning turned out to be crucial. Assembly language doesn’t forgive mistakes easily, and having a clear roadmap meant I could tackle the project incrementally without getting lost in the weeds.

The Build Process

The game itself is simple: a player-controlled hero sprite that moves around the screen while avoiding falling enemies. But implementing it required:

• Setting up the RGBDS toolchain (assembler, linker, graphics converter)
• Writing a Makefile that converts PNG sprites to Game Boy’s 2bpp tile format
• Implementing fixed-point arithmetic for smooth sub-pixel movement
• Managing Shadow OAM for sprite rendering
• Writing collision detection with bounding boxes
• Synchronizing everything with the 60 FPS VBlank cycle

Where Kiro Excelled

Kiro really shined in a few specific areas:

1. Boilerplate and Structure: Assembly requires a lot of repetitive setup—section declarations, memory layouts, include files. Kiro handled this quickly and consistently.

2. Pattern Recognition: Once I established patterns (like the module structure for game objects), Kiro could replicate them for new components. The hero and enemy systems follow similar patterns, and Kiro maintained that consistency.

3. Documentation: Every function got proper comment headers explaining inputs, outputs, and side effects. In assembly, where a single typo can cause hours of debugging, this documentation was invaluable.

4. Build System: The Makefile handles graphics conversion, assembly, linking, and ROM generation. Kiro set up all the dependencies and targets correctly on the first try.