Where We Left Off
A year ago I wrote about the start of this project as a gut feeling, a sailor smelling land long before it shows up in the spyglass. Last quarter the coastline came into focus. I built a tactical combat engine, rewrote the map in real 3D, reskinned the whole thing in pixel art, and laid out a set of convictions about what AI-native game design actually is. I ended that post saying it was full speed ahead toward the coast.
This quarter was landfall. I am also graduating, so it’s my final quarter of CS399. This quarter featured a shift in the type and quality of the work I was doing. Over time the Wizard’s Codex has evolved from an interesting idea I was exploring out of curiosity into a project I’m building into a product, and a project other people can build with me. Those are the two stories I want to tell here. The game got real enough to ship, and the project got organized enough to invite people in.
The earlier posts were about finding the thing. This one is about building it out. Less discovery, more construction, and for the first time, less of it was just me.
What is this project?
The Wizard’s Codex is an AI-native fantasy RPG. A real game engine simulates a living world (dice, terrain, an economy, characters with their own lives), and an AI Game Master runs that world like a puppet master, voicing its characters, steering its events, and shaping a story around whatever you decide to do. The pitch is that you can attempt any story you can imagine, inside a world that pushes back, remembers what you did, and makes you earn the ending. The name carries a second meaning too: in the game’s lore, the Codex is an undroppable magic book said to hold every story the world could tell. Its the game you’re playing, but also an in-game object that serves as the connection across all the worlds in its multiverse.
The thing I keep insisting on is that the AI is not the game. A language model on its own is a wonderful improviser, but improvisation by itself isn’t a game. For a story to mean anything, the world has to track what’s real, let you fail, and remember it afterward. So the design is a real game engine first, the kind of deterministic, rule-driven simulation that games like Dwarf Fortress and RimWorld have long used to grow stories nobody scripted, with the AI living in the seams to make all that emergent machinery legible as narrative. The Game Master pulls the strings of the story, voicing the cast and deciding what happens next, but it never gets to overrule the engine on what’s actually true. The engine produces the consequences that stick, and the model’s job is to turn a flanking move and a lucky roll into a scene with characters reacting in voice. The goal this quarter, and from here on, is to carry that from a working engine to a game real people can sit down and play.
What Got Built: The Game
It went live
One of the most important things that happened this quarter is that I registered thewizardscodex.com domain and launched the game site. The Wizard’s Codex went from “runs on my laptop” to a real, deployed game living at a URL. It’s not polished, combat breaks the game, its not built out to support a lot of players, but it’s live. For three quarters the honest answer to “can I play it?” was “well, if you clone the repo and set up a pile of API keys.” Now there’s a link, and that sets us up for the next phase of development. The game is just short of an MVP game loop, and at that point the thing I need most, more than any single feature, is other people playing the game and giving feedback.
The world got real
Last quarter I rewrote the map in 3D and called the move pure upside. This quarter I cashed that in. The world now renders coherently at every scale, from a whole continent down to the single scene you’re standing in, and I’m working to make sure it transitions smoothly between them as you zoom, so the world feels continuous rather than like a set of separate screens.
Underneath that, the terrain got a lot less like a spreadsheet and a lot more like a place. Elevation flows across boundaries instead of snapping at grid lines, hills actually read as hills, and biomes bleed into each other the way they do from a plane window. I wrote a set of animated pixel-water shaders for rivers and oceans, then spent an unglamorous stretch killing flicker at the edges of the map, because the world wraps around like a globe and the water did not initially agree. Settlements grew buildings and trees and little shimmering window lights. The camera learned some manners, settling onto clean angles, with a compass and smooth overscroll. The map is no longer an afterthought, but a core interface into the game world.
What you can do in it
With the foundation in place, a lot of the actual game filled in this quarter. You can pick up and carry items, look them over, put on equipment, and manage a loadout. There’s money, on a gold/silver/copper scale, and shops where you can haggle and trade. You keep a journal as you go. There is a lot of work left to do to create the sense of an economy and other ways that items can hook into gameplay and narrative within the game engine.
Conversation got more alive too. Instead of a basic chatbot, characters are agentic now. They can reflect on what you tell them and choose to leave a dialogue, initiate trade, fetch memories, and more in the future. After you act, the game offers a few suggestions for what you might do next, so there’s always a thread to pull. Character creation grew into a fuller process as well, where you set an age, sample traits, and watch your stats and strengths take shape as you build them. It’s now enough for a fast random world pathway in the game, which enables rapid playtesting and sharing of the game.
Combat, and what the milestone actually needs
Getting combat playable is one of the core goals for the first real milestone, so I want to be straight about where it stands. The more I dug in, the clearer it got that combat doesn’t mean much all on its own. For a fight to land, it has to happen in a world worth fighting in, and that raised two questions the combat engine couldn’t answer by itself: what does this world actually look like to a player, and would anyone want to play combat in a game like this at all?
The mechanics themselves are the lower-risk part, because I’m leaning on a proven tabletop ruleset (the SRD) rather than inventing one from scratch. The real unknown was the visual world, which is a big part of why so much of the quarter went into the map and the overall look of things. The combat engine is built, but it’s largely untested in the way that counts, because it hasn’t yet been driven by real play. For us to test combat in game, we needed the maximum zoom map level of detail to look like a combat map, and that work has absorbed a lot of time. So the honest status is that you can’t fight anything yet. The pieces exist, the remaining work is wiring them into the live world, and enough groundwork is down now that it should come together before long.
A question I’m still working out
One thing I spent time on this quarter is less a feature than an open question about how the game’s pieces should fit together. I started pulling apart the idea of a “world” from the idea of a “game,” and doing that surfaced a pile of questions I don’t have settled answers to. Is a character bound to one world, or can you make a character and drop it into a different one? Is a saved game tied to a world or separate from it? Could people hand worlds around to each other? I’m working through these in real time, and honestly some of it is still murky enough that it may change shape entirely. I mention it not because it’s finished but because it’s the sort of foundational question that quietly decides what the game can become later, and it’s the kind of thing I find genuinely interesting to chew on. The more flexibility I want to have, the more work I sign up for, and with cognitive overload more flexibility isn’t always the right answer to begin with.
What Got Built: The Project
The other half of the quarter went somewhere a game project usually doesn’t: into the scaffolding around the work itself.
Look at the tech and AI industry right now and there’s a strange imbalance. Companies are paying staggering sums for senior engineers while the rungs of the ladder that produce senior engineers are quietly being kicked out. The boilerplate, the grunt work, the “go figure out this corner of the codebase” tasks that juniors used to cut their teeth on are exactly the things agents now do. Everyone’s optimizing for the people who already know how to direct this stuff, and nobody’s minding the pipeline that creates them.
There’s an opportunity hiding in that gap, and a good chunk of this quarter’s non-game effort went into poking at it. Two threads, really: making the project legible to other people, and turning the codebase itself into a place someone could learn.
Getting it out of my head
For most of its life this project lived in my head and in a scatter of personal notes. That’s fine when you’re the only one who’ll ever touch it and useless the moment you want anyone else involved. So I spent real time this quarter turning private thinking into shared artifacts. There are documents now about how the project works, how the game is designed and why, how work gets tracked, and how a newcomer should find their footing. The planning that used to be invisible leaves a trail.
The thing that makes this sustainable is that it costs me almost nothing. With Claude wired into my tools, the workflow is: I have a long design conversation, the kind I’d be having anyway, and then I hand it off and the organizing happens for me, written up into a tracked plan that lives somewhere other people can see. I’m not doing extra project-management busywork on top of the design. I’m getting the project-management artifacts as a byproduct of the design I was already doing. What that buys me is observability. The work I’m doing and the work I’m planning is visible to collaborators and to anyone watching, instead of trapped in my notes app. It’s a record of how the project actually thinks, kept up almost for free.
The codebase as a teacher
One thing I built this quarter is a skill called /learn. It’s a way to learn this codebase, and the ideas underneath it, by just asking. A newcomer can sit down with Claude or the coding agent of choice, get a read on what they already understand, and be handed a sensible place to start instead of a wall of unfamiliar code. From there they can ask about any part of the system, or any concept, in plain words.
What I cared about was the stance it takes. It answers your question directly, no quizzing, no making you guess, and then it widens the lens: here’s the answer, here’s how it fits the bigger picture, and here are the questions a more experienced engineer would be asking that you didn’t yet know to ask. That last part is the actual skill, and it’s the hardest thing to pick up on your own. The bet is that if an agent is going to do a lot of the typing anyway, the most useful thing it can do alongside that is build the person’s understanding, so they come out able to direct the work rather than just having watched it happen. The talent pipeline we’re neglecting gets rebuilt by letting people do real work at the right level of stretch, with something that teaches while it builds. It’s all very early, more sketch than system, but it’s a direction I want to keep pushing on.
On folding in automation
One more thing, because it’s not written down anywhere else and I think it matters.
I did not start this project moving fast. Every layer of automation I now lean on took real time to get comfortable with before I trusted it enough to speed up. I’d add one tool, get genuinely productive with it, feel where it was still rubbing, and only then reach for the next one. The setup I run today would have buried me a year ago. I grew into it one piece at a time.
I also deliberately stay a step behind the frontier. There’s a whole crowd out on the edge experimenting with the newest agent workflows, and I read what they find, but I rarely adopt something until it’s been tried enough to become common knowledge. Those folks are excited about building workflows. I’m excited about building this game. I’d rather not burn my hours debugging an unproven way of working when I could be making the product, so I let the workflows prove themselves first and pick them up once they’re boring and reliable.
A lot of people feel a low-grade panic about learning these tools, like there’s a race and they’re losing it. I’d rather the framing be the opposite. Nobody has this figured out. It’s a few years old and we’re all making it up as we go. The good version of adopting this stuff isn’t pressure. It’s the small relief of “oh, this is doing the boring part for me,” the file-shuffling and the busywork handed off so you spend more of your time on the work that’s actually interesting. The principle I keep coming back to, in the game’s design and in how I work, is the same one: automate the gathering of information, not the thinking. Let the tools pull everything into one place and make the obvious calls, and keep yourself where the taste and the trade-offs live. Showing someone how to work this way should hand them ideas and let them find their own rhythm, not press a stack on them. It should feel like help.
What’s Next, and a Goodbye
The road ahead is the clearest it’s ever been. The next milestone is a build I can hand to a real playtester, and have them go through the core loop, explore a world, talk to its characters, fight something, without feeling I’ve wasted their time. The bar for that first slice isn’t “is it great.” It’s “does the concept read.” Greatness is what comes after, from watching people actually play and chasing the fun from there. I’ve spent a long time confident in the engine, but being confident in the engine isn’t the same as knowing the game is fun. That part only comes from real play. It’s going to be panning for gold, and getting it in front of players is the pan.
Running alongside that is the quieter bet: whether this project can become a place people learn, and whether the scaffolding I started this quarter actually lets other people pick up real pieces of it. That part is just beginning.
So this is where I sign off on the CS399 chapter. Three quarters ago this was an amorphous idea I was a little embarrassed to be excited about. Two quarters ago it had a coastline. Now it has a link you can open, a world you can move through, and, for the first time, a set of doors built so other people can come in. I started this sailing solo on a hunch. Now it’s time to build a town.
A real thank you to Christina for three quarters of space to explore these ideas. The room to start with “I don’t fully know what this is” and follow it on its way to a real game was a real gift. Somewhere along the way this stopped being a class project and became the thing I most want to build. I’m glad I got to spend my last stretch at Stanford on it. I’m not done.
