08 — What’s Next

Remaining work, reflections, and lessons learned

Current State

Pokémon Ancient Ember is playable from Pallet Town to the Rift Zone. Every major system works:

• ✅ Gear drops from battles with Diablo-style randomization
• ✅ 2 gear slots per Pokémon (Accessory + Armor), visible on the summary screen
• ✅ 7 relic types for the trainer, visible on the trainer card
• ✅ 8 Legendary items dropped by Gym Leaders
• ✅ Set bonuses for matching gear pairs
• ✅ Full economy: merchants, scrapper, altar, dual shard currencies
• ✅ Dark RPG-themed UI across 8 custom screens
• ✅ 5-tier endgame dungeon with boss fights and shard rewards
• ✅ Three-layer lore system woven into the existing world
• ✅ Custom sprites for merchant, chest, and altar NPCs
• ✅ In-game Codex reference with 8 pages including THE ANCIENTS lore
• ✅ Debug warp menu (L+R+SELECT cheat code) for rapid testing across all towns and endgame

What Remains

Balance Pass

The big one. Every number in the game is placeholder:

• Gear stat bonuses (are +5 ATK too strong at level 10? Too weak at level 60?)
• Drop rates (is 30% Common too generous? Is 1% Epic too stingy?)
• Shard economy (how many scraps to afford a reroll? How many rerolls to get “good” gear?)
• Rift Zone difficulty (are Lv50-75 bosses appropriate for post-Champion parties?)
• Relic effect scaling (is +50% XP from an Uncommon Mentor’s Tome too much?)

This needs playtesting. Real playtesting, not just “does it compile.”

Polish Ideas

• Repeatable Rift Zone bosses (currently one-time only)
• Rift Zone ambient effects (screen tint, corruption particles)
• More legendary gear tied to story events
• Additional relic types (capture rate boost, damage reduction)
• Gear set expansion beyond the current 8 base types

Reflections on GBA Development

What’s Hard

• Memory is the enemy. 32KB IWRAM, 256KB EWRAM, and the project is using 92% and 99.7% respectively. Every new feature is a negotiation with physics.
• No runtime debugging. Bugs manifest as grey screens, red flashes, garbled graphics, or silent wrong behavior. You debug by reasoning about code, not stepping through it.
• The build pipeline is invisible. Custom preprocessors, string encoding transformations, and section attributes create a gap between what you write and what runs.
• Documentation is tribal knowledge. The pret decompilation is well-organized but sparsely documented. How do you know COPYWIN_FULL vs COPYWIN_GFX? You read the code or you learn the hard way.

What’s Surprisingly Good

• The decompilation is incredible. pret/pokefirered is a masterwork of reverse engineering. 500K lines of readable C from a binary ROM. Functions have meaningful names. Structs are documented.
• C is the right level. You’re close enough to the hardware to control every byte, but high enough to have functions, structs, and enums.
• Constraints breed creativity. 16 colors per palette forces intentional design. 240×160 resolution forces information density. 32KB IWRAM forces you to understand where every variable lives.
• The game is complete. Unlike building from scratch, you start with a finished game. Every system exists and works. You’re extending, not creating from nothing.

What I Learned About AI-Assisted Development

I’ve been writing software for decades — different languages, different platforms, different scales. I know how to design systems and architect software. What I don’t know is GBA memory maps, tile engines, and palette management. I grew up on Pokémon Blue, played the cards, and about a year ago got back into it through emulation on a small handheld — QOL FireRed hacks mostly. That’s what planted the seed for building something in this space. Claude filled the gap that would have taken me months of solo study to cross.

What Claude handled well:

• Scaffolding repetitive code (5 map files × 3 files each = 15 nearly-identical files)
• Navigating the decompilation (finding the right hook point in 500K lines of code)
• Remembering constraints across long sessions (“don’t use TEXT_COLOR_YELLOW, it doesn’t exist”)
• Writing documentation from accumulated context

Where I still had to drive:

• GBA-specific gotchas that aren’t in training data (charmap encoding, IWRAM limits, section attributes)
• Visual debugging (Claude can’t see the emulator — I had to describe “garbled text” and diagnose what I was seeing)
• Knowing when to stop (Claude will happily add features to a system that’s already at 99.7% EWRAM)
• Sprite art and palette design (I designed the merchant sprite; Claude registered it in code)

The collaboration pattern that worked:

1. I designed the system (“I want gear drops after battles”)
2. Claude wrote the implementation plan + code
3. I tested in the emulator (“the text is garbled”)
4. Claude debugged and fixed
5. I pushed on aesthetics (“make it darker, more Diablo”)
6. Claude implemented the visual changes
7. Repeat

I brought the vision, the taste, and the visual QA. Claude brought code velocity and codebase navigation. Neither of us could have done this project efficiently alone — I’d still be reading GBA hardware docs, and Claude without direction would have built something technically correct but soulless.

By the Numbers

Written at end of Day 3, before the overnight sprint.

What This Journal Doesn’t Cover

Some things that happened but didn’t get their own post:

• The heap exhaustion bug (window buffers leaked 10-15KB per UI open, crashing after 3-4 NPC visits)
• The EMBER submenu tile conflict (baseBlock 0x0A0 collided with the help system’s reserved range)
• The BG1 green tint bug (tilemap loaded into RAM buffer instead of DMA to VRAM, except both RAM regions were full)
• The word-wrap algorithm (4 iterations from truncation → ellipsis → forward split → backward-search split)
• The altar sprite that went through 3 sizes before I got it right

Each of these is its own story. Maybe future posts.

This is a living document. As development continues, new posts will be added.

Back to README