08 — What’s Next

What works, what doesn’t, and what the numbers say.

Current State

Pokémon Ancient Ember runs 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

Every number in the game is a placeholder. That is the honest state of it.

• Gear stat bonuses — is +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 find good gear?
• Rift Zone difficulty — are Lv50-75 bosses right 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 (one-time only for now)
• 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

GBA Development, Tallied

What Is Hard

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

What Is Good

• The decompilation is first-rate. pret/pokefirered is 500K lines of readable C pulled from a binary ROM. Functions have names. Structs are documented. A masterwork of reverse engineering.
• C is the right level. Close enough to the hardware to control every byte, high enough for functions, structs, and enums.
• Constraints sharpen the work. 16 colors per palette forces intentional design. 240×160 forces information density. 32KB IWRAM forces you to know where every variable lives.
• The game is already complete. You start with a finished product. You extend — you do not build from nothing.

Working with AI

I have written software for decades — different languages, different platforms, different scales. I know how to design systems and architect software. GBA memory maps, tile engines, and palette management are another matter. 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. That planted the seed. Claude filled the gap that would have taken months of solo study to cross.

What Claude handled:

• Scaffolding repetitive code (5 map files × 3 files each = 15 near-identical files)
• Navigating the decompilation (finding the right hook point in 500K lines)
• Holding 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 not in training data (charmap encoding, IWRAM limits, section attributes)
• Visual debugging — Claude cannot see the emulator; I described “garbled text” and worked out what I was seeing
• Knowing when to stop — Claude will add features to a system at 99.7% EWRAM without hesitation
• Sprite art and palette design — I designed the merchant sprite; Claude registered it in code

The pattern that worked:

1. I designed the system (“I want gear drops after battles”)
2. Claude wrote the implementation plan and 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 made 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 would have run this project well alone — I would still be reading GBA hardware docs, and Claude without direction would have built something correct but hollow.

By the Numbers

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

What This Journal Doesn’t Cover

Some things that happened but did not 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