OpenMMO

One person, working with AI, built an online game that actually runs and took it to live service. The most valuable finding in this piece is not that game — it is my own mistake.

Start with the scale. One developer, 347 days, 116,000 lines of code. And of 1,163 code changes, 71% carry a signature saying “worked on this with AI.”

Why “an online game, alone” is hard

Plenty of people build games alone. Games where many people connect at once are a different animal.

A single-player game only has to be self-consistent inside one computer. An online game needs dozens of screens telling the same story at the same moment. Where I saw you standing, you have to be. What I handed you has to arrive. And it all has to stay consistent when someone’s connection drops and comes back.

The world here is 32 square kilometres — over 260,000 tiles.

And my summary of it was wrong in two places

This is the actual subject of the piece.

I first wrote a summary having read only the front-page description. Then I opened the code. Two things were not as described.

Wrong thing one — “the AI plays like a human” is not what happens. The marketing reads as though AI characters play under the same rules as people. In the code, the AI side holds several privileges of its own.

What the AI character gets	What that means
Doesn’t collide with walls	It passes through what stops a person
Paid daily	It is handed what a person must earn
Can force a trade window open	For a person, the other side must accept

So they are not playing on equal terms — they are playing with an advantage.

I learned more from that mistake than from the repository

I was wrong twice, and wrong in both directions. Some parts I wrote up as more impressive than reality, others as less.

So I wrote a rule:

A description document is the plan. The code is the state. Don’t read a plan as a state.

The author didn’t lie. Descriptions are mostly written before the building and rarely updated after. Documents and code drifting apart is the natural condition, and the reader has to price that in.

One structure worth stealing — “two places share one brain”

There is a technical takeaway.

A classic failure when putting AI characters in a game: the game and the AI controller each run their own calculation and disagree. The game says blocked, the AI says walkable, and the AI character shudders against a wall forever.

This developer made disagreement structurally impossible. The judging code exists once, and both sides call it. One copy cannot contradict itself.

I took the concept but did not build it — the work costs more than it returns for me right now.

The code can’t come across

The licence says “not for commercial use.” So copying code was never an option. I looked at structure only.

Last — the qualifier that must ride along with an impressive number

“71% of commits co-authored with AI” and “zero instances of the dangerous pattern” are striking numbers. But reading them as “this is what using AI gets you” is wrong.

Most people using the same tools do not produce those numbers. What produced them was not the tool but the discipline this person imposed on themselves. Cite the numbers with that attached, or don’t cite them.

The detailed record starts here

The most valuable result in this piece isn’t about the repository, it’s about my summary of it. A Rust + Svelte MMORPG built by one developer, largely by prompting, and taken to live service. 116,000 lines, 1,163 commits, 347 days, and 71% of commits carry an AI co-author trailer. But the summary I wrote from the README before opening the code was wrong on two counts — and correcting them taught me more than the repository did.

What it is

An MMORPG one developer built over 347 days and actually runs in production. Rust on the server, Svelte and WebGPU-only on the client, and a binary protocol rather than JSON. The world is 32km² across 262,144 tiles.

The quality indicators are striking. Zero unwrap, zero unsafe in the server code. 270 tests. 825 of 1,163 commits (71%) carry an AI co-author trailer, and the substance of this repository is that the result still holds that much discipline.

⚠ The licence is non-commercial. Commercial use is out, and borrowing code is not allowed. Design reference only.

What broke — my summary was wrong twice

Correction 1 — “the model connects and plays over a tool protocol” is not true.

Two related crates appear in the dependency declaration. But searching the entire source gives zero usages. It compiles and never runs a line. The related port in the config example is commented out, and the config struct has no such field at all. The tool list in the docs is a design sketch, and the same document marks it “priority 4, not started.”

The actual interface is far simpler — a JSON action schema with seven entries (speak, attack, move, revive, propose trade, open trade window, wait). The model picks one of them.

Correction 2 — “the server can’t tell humans from agents” is the exact opposite of true.

There is a dedicated authentication message, and the result is branded permanently onto the session as one boolean flag. That flag then changes the game’s rules in at least six places.

Where	Effect	Character
Collision	agents skip it — effectively walking through walls	privilege
Daily wage	only agents receive gold	privilege
Trade window	only agents can force a trade window onto someone’s screen	privilege
Trade proposals	proposals from humans are refused	restriction
Monster spawning	spawning is suppressed near agents	optimisation

Half of it is right — the transport layer really is the same. Same port, same frames, same messages, same pathfinding code. But the other half of “no privileged API” was sitting inside one boolean.

What matters is that the README didn’t lie. The document said it was a design document, and the not-started marker was inside the same file. I read a design document as a status report. And I stretched “the transport layer is the same” into “the rules are the same.”

That the two point in opposite directions matters diagnostically. Wrong in one direction would be expectation bias; claiming what isn’t there and denying what is means I simply never opened it.

Held against my own setup

I can’t take the code — the licence is non-commercial, so borrowing is out. Design only.

The most instructive part is the crate sharing. Pathfinding and world generation run from the same code across server, bot and browser. In my QA automation, the logic the bot judges with and the logic the game runs are separate — which is exactly how you get “the bot thought it was passable and the game blocked it.” Make it one body of code and that class of mismatch cannot occur.

⚠ But it doesn’t transfer directly. The game engine and the bot’s runtime differ, and unifying them means changing the game side. Cost exceeds benefit.

The combination of 71% AI co-authorship and zero unwrap also stays with me. It is a counterexample to “AI-written code is lower quality” — but ⚠ this is the product of one developer’s discipline, not a property of the tool. Same tool, different person, different numbers.

Verdict

What	Verdict
Borrowing code	⛔ not allowed. The licence is non-commercial
One body of code across runtimes	concept adopted. It blocks bot/game verdict mismatch at the source ⚠ applying it now is cost > benefit
“Never read a design document as status”	adopt — as a rule. I got it wrong twice here
71% AI co-authorship · zero unwrap	qualify when citing. That number came from a person’s discipline, not a tool

The lesson I paid for here: a summary written from documentation flips when you open the code. And it flips in both directions.

And ⚠ it is better to keep a wrong summary as a correction than to delete it. Delete it and the record reads “I knew this correctly all along”, when in fact I held two wrong beliefs right up until I opened the code. Next time I am about to judge from a README, this record is what stops me.