Introduction
I love watching moving things progress on their own. Whether it's a factory line or a simulation, I can watch things that keep moving even if I leave them alone for hours.
Watching AI work is no different; I love it. Seeing Claude Code or Codex repeatedly call tools and advance tasks is fascinating—I never get tired of it.
However, there is a limit. Staring at terminal logs scrolling endlessly is, frankly, a bit dull.
So, I made something to make the waiting time a little more fun. I usually build serious projects, so for once, I wanted to create something completely meaningless.
What I built is rpgdev. While the AI writes code, a small RPG progresses automatically in the corner of your Mac screen. You don't control it. While you write code, a hero goes on an adventure right next to it. That's all.
It's available on npm and is exclusive to Mac. I'll tell you now, it's silly. But it's fun. Give it a try! (lol)
Chapter 1: What Happens?
The actual overlay screen of rpgdev. In the bottom left, the hero performs a technique, in the center is an enemy, and in the top right, the AI's TODOs are lined up as quests
Here is how it works: every time the AI uses a tool, there is a certain probability that an enemy will appear. If one appears, it's battle time. The hero performs a technique to defeat it.
The names of the techniques are the names of the tools themselves. If the AI uses Bash, the hero uses "Bash"; if it applies a patch, the hero uses "ApplyPatch". The tools the AI is currently executing appear on the screen as special moves.
TODO lists created by the AI are lined up on the screen as a quest list. The statuses—"Not Started," "In Progress," and "Completed"—switch accordingly using icons.
The setting also progresses. As work advances, the player moves deeper from Field to Dungeon to Castle. Both the background and the BGM change.
Three background stages. From left: Field, Dungeon, Castle. As work progresses, it shifts to the right
When the AI sets up a sub-task (sub-agent), spirits join the party as companions. There are four elements: Fire, Earth, Wind, and Water. They follow up after the hero's attacks.
The backgrounds, BGM, sound effects, and pixel art are all my own work. There are seven BGM tracks in total, across "Field, Dungeon, Castle" and "Exploration/Battle." I made the castle BGM a grand, solemn march. Nobody will probably notice, though.
In short, your AI coding automatically becomes an RPG battle log. It progresses on its own just by watching it.
Chapter 2: At First, "Error = Monster"
The first idea I had was much more straightforward: If the AI produces an error, a monster appears. Failure is the enemy, and fixing it is the defeat. It makes sense, right?
The problem was figuring out how to distinguish "failure." For a quick fix, I decided that if the tool's output contained the word "error," it was a failure.
This failed miserably.
File reads and searches that were perfectly successful would trigger monsters simply because the output happened to contain the word "error." When I counted my own logs, a quarter of the battles were against fake enemies.
Furthermore, ironically, the software I was building was all about error handling, so it was covered in the word "error." The more I developed, the more fake enemies spawned. It felt like I was being beaten by the very code I was writing.
I concluded that distinguishing failure by keyword was unreliable and abandoned this method. Now, it's just a simple random encounter system where an enemy appears with a certain probability every time a tool is used. Since it's an RPG, that's enough.
By the way, there are two opponents. I wanted it to work with both Claude and Codex, so I restricted myself to using only notifications that exist in both. As an aside, Codex doesn't even tell the outside world when a tool fails. So, on the Codex side, enemies don't counterattack. It's peaceful.
Chapter 3: The Real Struggle Wasn't the Code, It Was the Art
To be honest, the mechanics so far weren't that difficult. The part I struggled with the most was the images.
Having AI draw pixel art characters—that part is fine. The difficult part was "variations of the same character." Versions with wounds, different orientations, standing poses, and battle poses. I wanted to change only one part while keeping the same appearance.
This is the weakest point of AI image generation. Even if you ask it to "keep this character and change only this part" in text, the AI has the freedom to redraw everything. So, every time, they become slightly different people. The outlines get thinner. Before you know it, it's not pixel art anymore, but a high-resolution illustration.
Ultimately, what solved this was Codex's built-in image generation tool. I provided the original image as a base and had it edit it. I made sure to include fixed spells like "retro pixel art, limited color palette, thick outlines" in the prompt every time. I would mechanically strip the background from the generated image and align the display position pixel-by-pixel against the original image.
The repository still contains the list of "forbidden" items that accumulated during that process, such as "Don't draw by hand; if you don't like it, regenerate," or "Don't use this background color because it clashes with the character." They are fossils of my struggle. But thanks to that, the grain size of the pixels for the four Fire, Earth, Wind, and Water spirits finally matched.
15 monsters appearing in Field, Dungeon, and Castle, plus the Hero and the spirits of Fire (Ignis), Earth (Terra), Wind (Sylph), and Water (Aqua). All are original pixel art.
Chapter 4: My Own Custom Tool to "Do It Properly" Was a Miss
Actually, I went on one more detour.
It's a hassle to chant spells manually every time to align positions. So, I built a dedicated, separate tool to efficiently produce variations locally. It decomposes characters into a tree of parts like "hair," "outfit," and "weapon," manages prompts for each part, and toggles states to regenerate—it was a reasonably elaborate piece of work.
This was completely useless.
To run the main model required to move the critical parts for consistency, my local graphics board (16GB of memory) couldn't handle it. Even when I forced it to run, the accuracy wasn't there, and the resulting images were unusable.
In the end, my elaborate custom tool flopped, and the built-in tool that was already available simply won. Well, that's a common story.
I want to properly test the local route, so I ordered a graphics board with more memory (a 32GB one). I'm currently waiting for it to arrive. Once it gets here, I'll have a rematch.
Conclusion
And so, that's rpgdev. A small adventure progresses on its own while the AI works. You get nothing for defeating enemies, and nothing happens even if you reach the castle. It's completely meaningless.
The repository is at github.com/kitepon-rgb/rpgdev. You can install it with npm install -g rpgdev. It's Mac-only for now, but I'm working on support for Windows and WSL2.
It's silly. But having a hero fight on their own while you write code isn't as bad as you might think. Give it a try! (lol)
Top comments (0)