I Built a Diablo-like Game with Codex, Then I Buried It

An Indie Developer's AI Game Development Experiment

Diablo-like games—grinding for loot, checking affixes, assembling builds, watching your character grow stronger—these games have an intoxicating loop. At its core, this loop is what psychologist B.F. Skinner identified as the "Variable Reward Schedule": uncertain rewards drive repetitive behavior more powerfully than fixed ones. The randomness of gear affixes, the eureka moment when a build comes together, the exponential growth in character power—together they form the internal drive that keeps players saying "just one more run." This design philosophy has defined the entire genre's DNA since the original Diablo in 1996.

For a developer who loves these games, "making my own" has been a thought buried deep for a long time. But building a numbers-heavy game solo is brutal: classes, gear, loot tables, affixes, skills, monsters, maps, save systems, UI… each module looks simple on its own, but stacked together they become a mountain impossible to move alone.

Then Codex appeared, and suddenly that mountain didn't look so heavy. OpenAI Codex is a large language model built on the GPT-3 architecture, specifically trained for code generation tasks, and serves as the underlying engine for GitHub Copilot. Trained on tens of billions of lines of public code, it can understand natural language descriptions and generate corresponding code implementations, excelling particularly at function-level code completion, modular architecture generation, and documentation-to-code tasks. It can write code, decompose documents, fill in architecture gaps, and generate implementation plans. And so, a project that had been shelved for too long was officially greenlit.

The Speed Illusion of AI Programming: Early Excitement and Traps

The beginning was genuinely thrilling. World-building, classes, gear, idle mechanics, greater rifts, loot drops, affixes, skills, mercenaries, maps, save systems, UI—everything was growing at breakneck speed. For someone with software development experience, this velocity is absolutely intoxicating: you describe a system, and it unfolds; you describe a feature, and it gets implemented. The project was getting bigger every day, and it felt like there was progress every day.

But this is precisely the most dangerous aspect of AI-assisted development—speed creates the illusion of progress.

It's worth noting that Codex is fundamentally a "pattern matching and completion system." It excels at inferring "what should come next" based on existing context, but it has no product judgment—it cannot distinguish between "technically implementable" and "actually important for this game." This is the technical root cause of everything that went wrong later.

Systems Were Bloating, But Core Gameplay Never Solidified

Gradually, something started feeling off. It wasn't a specific bug or a piece of bad code—it was that the entire project's center of gravity was quietly shifting:

• Pages were getting heavier, logic more convoluted
• Test data and production data were mixed together
• Documentation said "complete," but nothing was truly closed-loop in the actual build
• Systems looked increasingly comprehensive, but the foundational gameplay never stood firm

The critical question was this: Select map → idle combat → loot drops → open inventory → equip gear → next run feels stronger. This sounds simple, but it never solidly held together. I built all the things a Diablo-like "should have," but never first proved why a player would want to do one more run.

This is exactly what the "Minimum Playable Prototype" concept in game design emphasizes: implement only the smallest set of features needed to validate the core game loop. Edmund McMillen, developer of The Binding of Isaac, has publicly stated that his prototype had just one room, one character, and one type of enemy—but the core feeling of "random rooms + resource trade-offs" was already fully realized. Feature completeness is an engineering goal, not a game design goal.

Core Reflection: AI Won't Help You Decide What Actually Matters

Later, I saw what I truly wanted to make in other games—not some grand system, but perhaps just one piece of gear design, one numerical rhythm, one moment of feedback after a drop, one feeling when a build clicks into place. In that moment I suddenly realized: I'd spent massive amounts of time building systems, architecture, documentation, pages, and data pipelines, but what I actually wanted were those tiny moments—

• The instant a godly piece of gear drops
• The instant a build comes together
• The instant your character suddenly feels smooth

I thought I wanted to make a Diablo-like game. What I actually wanted to make were these moments.

These moments have a precise description in game design theory: psychologist Mihaly Csikszentmihalyi's "Flow" theory, which can be concretized here as a "desire loop"—at the end of each cycle, the player must receive sufficient positive feedback while simultaneously generating anticipation for the next cycle. Whether this loop holds is the fundamental criterion for whether a game can retain players—not the number of systems or feature coverage.

This is the biggest lesson from this experience. AI can help you start faster, but it won't automatically help you determine what's actually core. In fact, it makes it easier to lose control—because it's too productive. You say you want a gear system, and it unfolds a gear system; you say you want maps, and it builds maps; you say you want idle mechanics, rifts, mercenaries, skills, loot—it can keep going indefinitely.

This creates a very dangerous illusion: the project seems to always be moving forward. But games don't succeed based on the number of systems—they succeed based on a repeatable desire loop.

The Obsession with Completeness: The Easiest Trap for Indie Developers

The mistake I made was being too obsessed with replicating a full-featured Diablo-like:

• I wanted the restraint of low-stat legendaries
• I wanted Diablo's gear-driven progression
• I wanted the lightweight loop of idle games
• I wanted the satisfaction of builds coming together
• I wanted rifts, maps, loot, and progression systems

None of these were wrong individually, but combined, they were far too much for an early prototype. In the end, it didn't look like a game—it looked like a game systems encyclopedia rapidly incubated by AI.

This has a corresponding classic warning in software engineering—Donald Knuth's famous quote "Premature optimization is the root of all evil" can be rewritten here as: "Premature implementation is the root of all evil in indie development." AI tools eliminate the friction of implementation, whereas in traditional development, the high friction of implementing a system itself forces developers to repeatedly confirm its necessity. The disappearance of this friction makes the impulse to "build first, ask questions later" easier to act on, and causes the cost of course correction to grow exponentially over time.

Of course, it wasn't all bad. The idle logic itself, for example, was still directionally correct—players don't need high-intensity input; they grow stronger gradually through repeated idle runs, loot drops, and gear swaps. It was just designed too complex from the start—so complex that before it ever had a chance to become fun, it had already become heavy.

Deciding to Bury the Project: Not a Rejection, But a Fresh Start

Ultimately, I decided to bury this project. Not because it was worthless, but because it was no longer suitable as a starting point for the next phase. I don't want to keep patching an increasingly heavy project. Instead, I want to take this failure with me and start over with something smaller and more interesting.

Next time, I won't start from "I want to build a complete Diablo-like."