Inspiration
This project started because I was stuck.
Over winter break, I was playing Pokémon Run & Bun, one of the hardest Pokémon ROM hacks, and kept losing the same battles. There was no walkthrough I could copy because every player reaches those battles with a different save file, team, set of encounters, and pool of resources.
But Pokémon battles still felt solvable. Damage comes from formulas, opposing AI follows rules, and nearly every battle mechanic belongs to a predictable system. The hard part is searching through thousands of possible decisions to find the sequence that works.
I wanted to answer one question: How close can we get to solving a Pokémon battle automatically?
I eventually shifted the project from Run & Bun to Pokémon Emerald so it could serve more players. The idea behind it stayed the same: build the tool I wanted whenever I got stuck.
What it does
Pokémon Emulator Solver reads a player’s save file and searches for strategies using the Pokémon, moves, and resources already available in that save.
It does not stop after finding a strategy in a simulator. The program replays the strategy inside an emulator and only accepts it if the result can be reproduced there.
It also supports different ways of using the solver:
- Gauntlet Mode searches across several battles in sequence.
- Hint Mode gives players guidance without revealing the entire solution.
- Automatic replay generation lets players watch successful strategies instead of relying on written instructions.
The solver is not meant to play the game for someone. It helps players get through battles that have stopped their progress without taking the rest of the challenge away from them.
How we built it
The project connects save-file parsing, emulator automation, battle search, and emulator verification in one workflow.
My original design relied heavily on a battle planner. As development continued, however, I realized that finding a plausible strategy was only half the problem. The program also needed to prove that the strategy worked in the real game.
That led to the project’s central architectural decision: every successful strategy must be replayed inside the emulator before the user sees it.
GPT-5.6 and Codex handled a substantial part of the implementation process. I used them to build internal tools, automate repetitive work, debug difficult problems, and test new approaches quickly. That allowed me to spend more time on the decisions the tools could not make for me: what should count as proof, how the application should behave, and which features would actually help players.
Challenges we ran into
A simulator can look correct while still being wrong in ways that matter.
Small discrepancies appeared throughout development. A battle that worked in the planner could behave differently inside the emulator, and correcting one mechanic would often expose another inconsistency. Reliability did not come from writing one complicated algorithm. It came from finding and eliminating dozens of smaller disagreements between the solver and the game.
Performance created a separate problem. The number of possible battle sequences grows quickly, so searches could become computationally expensive. We had to make them faster without weakening the verification process.
The supporting systems also took more work than expected. Save-state management, replay generation, checkpoint organization, and testing utilities were not the main idea behind the project, but they became essential to making the solver dependable.
Accomplishments that we’re proud of
The project now works from beginning to end. It can read a save file, analyze the player’s team, search for a strategy, verify that strategy inside an emulator, and return both battle guidance and a replay video.
Several smaller decisions also made the solver more useful:
- Emulator verification prevents the program from presenting simulation-only solutions as fact.
- Hint Mode helps players who want direction without seeing every move.
- Gauntlet Mode accounts for consecutive battles instead of treating each one in isolation.
- Automatic replay videos show players exactly how a successful strategy plays out.
Most importantly, it has become the tool I originally wanted for myself: something I could use when a Pokémon challenge run brought my progress to a stop.
What we learned
Finding an answer and proving it are different engineering problems.
Early development focused almost entirely on generating strategies. By the end, verification had become just as important as the search itself. A strategy has little value if the player cannot reproduce it in the game.
I also learned that AI coding tools are most useful when they support engineering judgment instead of replacing it. GPT-5.6 and Codex sped up implementation considerably, but they could not decide what the product should do, which results were trustworthy, or where the project needed to go next.
The project also showed me how much engineering sits behind apparently simple game tools. Reading a save file is only the first step. Turning that data into something a player can rely on requires extensive testing, iteration, and supporting infrastructure.
What’s next for Pokémon Emulator Solver
Pokémon Emerald became the project’s primary focus, but the original idea was broader than one game.
The next major step is expanding support to Pokémon Run & Bun and, later, other ROM hacks while continuing to improve the Emerald solver.
Planned improvements include:
- Faster searches for difficult battles.
- More control over how much guidance Hint Mode provides.
- Advanced search options for experienced players.
- Better visualizations and clearer terminology.
- A simpler installation and setup process for new users.
Long term, I want Pokémon Emulator Solver to be something players open when they are stuck: not to remove the challenge, but to give them a path forward.
Log in or sign up for Devpost to join the conversation.