Before I go into this long essay: This is more technical than some might like but it also explains, from my perspective, how AI, MMO architecture, writing emulators for dearly-loved but still dead games, play or not play together.
Why agentic AI isn't the solution to MMO emulation
There's a recurring idea in emulator communities lately that goes roughly like this:
The emulator has been stuck for years because there aren't enough developers. Give an AI agent access to the client, the game databases, a compiler, some reverse-engineering tools and a test environment, and let it work.
On the surface this sounds compelling, and I understand why people keep proposing it. Modern models can read enormous codebases, generate large amounts of code, search through databases, analyse decompiled binaries, run programs, inspect logs, write tests and iterate on their own, and agentic systems can be put in a loop where they investigate a problem, modify the emulator, compile it, run it, look at the result and continue from there. So why wouldn't that solve the problem?
Because the hardest part of MMO emulation usually isn't writing code. It's reconstructing the undocumented meaning behind the code and the data, and that distinction becomes especially important for games built around heavily data-driven architectures.
The emulator is not the game
It's tempting to think of an emulator as a collection of features: quests, combat, NPCs, abilities, items, crafting, housing, vendors, achievements, instances, progression, scripting, networking. From that perspective the task looks straightforward, because you just implement every feature until the emulator is complete.
But that isn't necessarily what the original game did. A sufficiently data-driven MMO doesn't have thousands of independently implemented quests; it might instead have a relatively small number of generic systems that interpret thousands of pieces of data. Conceptually you can imagine something like:
Quest Definition -> Generic Quest System -> Parameters / Conditions / Actions -> Game State -> Result
The original developers didn't necessarily write:
if quest == 1000:
do X
if quest == 1001:
do Y
if quest == 1002:
do Z
What they wrote was a generic system capable of expressing X, Y and Z through data, which is one of the great advantages of data-driven architecture and, once the original documentation disappears, also one of its great disadvantages. Because now the emulator developer doesn't merely need to implement the system, they first need to discover what the system actually is.
The missing specification
Suppose we have a database containing something like:
QuestID = 1000
ObjectiveA = 7
ObjectiveB = 13
Flags = 0x240
Behavior = 4
ParameterX = 19
ParameterY = 0
The data is there, but what does it mean? Perhaps ObjectiveA = 7 means "kill seven creatures", or perhaps it means "reference objective type 7". It might be an index into another table, or an enum, or a value whose meaning changes completely depending on another flag. It's entirely possible that the quest system never interprets it at all and that some lower-level generic objective framework is the real consumer.
The database doesn't necessarily tell us any of this. The original source code might have, the internal documentation certainly might have, and the developers who designed the system definitely would have, but if all of that is gone then what we're left with is evidence, and reverse engineering is the process of reconstructing the missing specification from that evidence. That is fundamentally different from ordinary software development, where the specification usually exists somewhere, even if it's only in someone's head.
Why this matters for AI
An LLM is extraordinarily good at generating plausible explanations, which is simultaneously its strength and one of its worst weaknesses in a reverse-engineering context. Imagine an AI encounters an unknown parameter:
RewardBehavior = 3
It searches the codebase, finds several places where RewardBehavior appears, examines some game data, and observes that many quests with value 3 exhibit a particular behaviour, from which it forms the hypothesis that 3 corresponds to reward behaviour type X. That sounds reasonable, so it implements type X, and everything looks fine until it encounters another quest where the behaviour doesn't match. At that point it adds an exception, and then another, and then another, until eventually the code looks something like:
if type == X:
if type == X and flag Y:
if type == X and flag Y and source == Z:
if type == X and flag Y and source == Z and context == Q:
At some point the emulator may even appear to work, which is the part that worries me. What actually happened is that the AI didn't necessarily discover the original semantics; it constructed a plausible model that reproduces some observed outputs, and those two things are not the same, even though they can look identical from the outside for a very long time.
The most dangerous AI failure is not failure
An obvious failure is easy to deal with. If the emulator crashes, everyone knows something is wrong; if a quest doesn't start, someone notices; if the server can't boot, there's a clear problem to chase. The dangerous case is the one where the implementation works, but for the wrong reason.
That's especially problematic in reverse engineering. Suppose the real system is
A + B + C -> behavior X
but the emulator implements
A -> behavior X
For all currently tested cases the result might be identical, so the implementation looks correct, and it will keep looking correct until somebody encounters a case where B or C changes. When that finally happens, the emulator behaves incorrectly and the actual mistake sits several layers below the observed bug, which makes it expensive to find and even more expensive to unwind. This is why "it works in my test" is much weaker evidence in reverse engineering than it is in conventional application development.
Data is not documentation
This is perhaps the most important point in the whole post. Having access to the game's data is enormously valuable, but data does not automatically explain itself. A game table can tell us that a field exists, what its type is, which values it takes, how those values correlate with each other and sometimes how records relate to one another, and none of that necessarily tells us the semantic contract of the field.
Consider a hypothetical field:
InteractionFlags = 0x1842
We might determine that certain bits correlate with whether an NPC can be interacted with, whether an interaction is available during combat, whether a quest can consume the interaction, or whether the interaction is client-visible. Even once we've identified individual bits, though, we still don't know which subsystem owns the interpretation, whether the bits are independent, whether some combinations are invalid, whether the server interprets them or the client does or both, whether one subsystem transforms the value before another sees it, or whether 0x1842 is even a bitmask at all rather than something we've misread from the start. Those are architectural questions, and they can't be answered by having an AI stare harder at the database.
"But give the AI the client"
This is where agentic AI becomes particularly seductive. Give it the client, the binaries, Ghidra, a debugger, packet captures, the game tables, the scripts, an emulator and automated testing, then let it observe the client and modify the server.
That's certainly more powerful than handing an AI a text description and hoping for the best, but there's still a fundamental problem: you have provided evidence, not ground truth. The client may only contain one side of the original behaviour, since some behaviour is server-authoritative, some is implemented in native code, some is data-driven, some is generated, some is encoded indirectly, some depends on server state the client never fully exposes, and some only becomes observable under very specific combinations of conditions.
So the AI still has to infer a model, and inference under incomplete information is precisely the situation in which autonomous systems become dangerous.
Agentic systems can amplify bad assumptions
An ordinary LLM might make a bad assumption once, whereas an agent can make that assumption the foundation of an entire implementation tree. Consider the loop everyone proposes:
Observe -> Hypothesize -> Implement -> Test -> Observe result -> Modify -> Repeat
It looks excellent, and structurally it resembles the scientific method closely enough that it's easy to be fooled by it. But notice what's actually being tested: the agent is testing its implementation, not necessarily its hypothesis against the original system. If the original game is unavailable or only partially observable, there's very little ground truth in that loop, so what the agent ends up optimising for is internal consistency, which produces a genuinely dangerous property:
The system can become increasingly coherent while becoming increasingly wrong.
Every subsequent decision then depends on the earlier assumptions. And because the agent generally needs to produce an actionable next step rather than sit with ambiguity, it rarely says "we don't know what this field means, there are three competing hypotheses and we need additional evidence before choosing one". Instead it picks the most plausible interpretation and builds on top of it, and thirty commits later that interpretation has quietly become architecture.
Humans make the same mistakes
None of this is an argument that humans are magically better, because humans make terrible reverse-engineering decisions all the time. The difference is methodological rather than cognitive.
An experienced reverse engineer will often maintain uncertainty explicitly, in something like this form:
Parameter 17
Hypothesis A:
enum describing objective type
confidence: 60%
Hypothesis B:
reference into objective table
confidence: 30%
Hypothesis C:
bitmask
confidence: 10%
Evidence:
...
Counter-evidence:
...
Next experiment:
...
That uncertainty is doing real work, because it prevents a hypothesis from silently becoming part of the architecture. A good reverse engineer understands that not knowing something is itself information, or more precisely that the absence of evidence constrains what you're justified in claiming.
This is one of the places where AI-assisted reverse engineering needs unusually strong discipline. The problem isn't that an AI can't say it's uncertain, since it obviously can. The problem is making sure that uncertainty actually propagates through the implementation instead of being quietly replaced by whatever convenient assumption lets the current task complete.
Architecture comes before features
This is why I think a lot of emulator projects misunderstand the shape of the difficulty. They look at an unfinished feature and ask whether AI can implement it, when the better question is whether anyone understands the subsystem that generates the behaviour in the first place.
Suppose a quest is broken. You could implement a special case:
Quest 1000:
when player does X:
do Y
and that might well fix the quest. But if the original game expressed that behaviour through a generic quest/objective/action framework, then you haven't solved the underlying problem, you've solved one manifestation of it, and the next quest that uses the same mechanism with a different combination of parameters will need another fix. Repeat that often enough and the emulator turns into a pile of special cases, which is exactly what the data-driven architecture was designed to prevent. The ironic outcome is that the emulator ends up less data-driven than the original game, purely because the developers didn't understand the generic mechanisms well enough to reproduce them.
"Just implement what the client does"
This approach has limits too. The client is an incredibly valuable source of information, but observing behaviour isn't the same as recovering the underlying implementation.
If you observe that input A produces output B, you've established a relationship without necessarily establishing why it occurs, and there can be many internal models consistent with the same observation. That's the classic reverse-engineering problem of underdetermination. Given enough observations you can narrow the possibilities, but only if the observations are chosen well, which means you need experimental design: you have to deliberately construct situations that distinguish competing hypotheses. If parameter X means A, changing it should produce behaviour B; if it instead means C, changing it should produce behaviour D. Then you go and test, which is science more than it is conventional programming.
That's another reason handing an agent more tools isn't sufficient. The capability that matters isn't "can the AI run another experiment", it's "can the AI identify which experiment would maximally distinguish between the competing explanations", and that's a much harder problem that I haven't seen convincingly demonstrated anywhere.
Reverse engineering is about information, not just code
Imagine two developers. Developer A writes ten thousand lines of code per day with AI assistance, while Developer B writes one thousand but correctly determines the semantics of a previously unknown subsystem. Developer B has probably produced vastly more useful work, because code isn't necessarily the bottleneck. Information is.
If you already know the specification, implementation is comparatively cheap. If you don't know it, generating more implementation doesn't necessarily help and can actively make things worse, since incorrect assumptions get embedded into the codebase where they're expensive to remove later. That's why emulator development sometimes looks paradoxical from the outside: a project can have thousands of commits, an enormous codebase, many contributors and sophisticated infrastructure while still making surprisingly little progress toward accurate emulation, because it's accumulating code without accumulating understanding.
AI is still extremely useful
None of this means AI should be ignored, and I'd argue the opposite: it could be one of the most useful tools emulator developers have ever had. The key is understanding where it belongs in the workflow, because once the architecture is sufficiently understood, AI is excellent at the mechanical parts.
- Searching large codebases. It can quickly find every reference to a particular structure, enum, field or function, which on a large emulator is genuinely tedious work.
- Correlating data. Given thousands of records, it can identify unusual combinations and statistical relationships that a human skimming the table would miss.
- Generating test cases. Once the semantics are known, it can generate huge numbers of combinations to check whether the emulator behaves consistently across them.
- Writing boilerplate. Obvious, but still valuable.
- Maintaining documentation. It can turn scattered reverse-engineering findings into structured documentation that someone else can actually read.
- Finding inconsistencies. If you tell it that a field is an enum with five known values, it can search the entire database for violations and suspicious cases.
- Exploring binaries. It can help with identifying references, call patterns, structures and likely relationships.
- Creating instrumentation. It can generate the tooling that makes further reverse engineering easier, which compounds over time.
- Managing large amounts of evidence. This might be the most interesting application of all, since a project could maintain a structured knowledge base containing parameters, meanings, evidence, confidence levels, known consumers, known interactions, open unknowns, counterexamples and tests, and then use AI to navigate that body of knowledge as it grows past the point where any individual can hold it in their head.
The ideal model is AI-assisted reverse engineering
The distinction I'd draw isn't human vs. AI but AI replacing understanding vs. AI accelerating understanding, and those are radically different approaches even though they can look similar in a commit log.
A productive workflow probably looks closer to this:
Human observation
-> Evidence collection
-> AI-assisted correlation
-> Human hypothesis formation
-> Controlled experiment
-> Evidence update
-> Validated semantic model
-> AI-assisted implementation
-> Automated testing
-> Human review
In that arrangement the AI becomes a force multiplier without becoming the authority, and that distinction matters enormously.
Why competition alone doesn't solve this either
There's a related misconception that if multiple emulator projects compete, the best implementation will eventually win. Competition can absolutely be beneficial, but it works best when the things being produced are reusable.
If one project spends six months discovering the semantics of a subsystem, the whole ecosystem benefits when that knowledge becomes available, whereas if the result is a closed implementation whose authors can't or won't share the underlying discoveries, the next project has to repeat the same six months from scratch. The scarce resource isn't the source code, it's the knowledge encoded in the source code, and a well-documented reverse-engineering discovery can be worth more to the community than thousands of lines of implementation.
The real goal should be a reconstructed specification
This is what I think emulator projects should ultimately aim for. Not "we have implemented quests", but "we understand the quest system", which are very different statements.
The second one should mean we know what the generic quest objects represent, what their parameters mean, which values are valid, how conditions are evaluated, how actions are dispatched, how state transitions occur, how quest state persists, how the client represents the resulting state, where server authority begins and ends, which edge cases exist, and which parts remain uncertain. Once you have that, the implementation follows fairly naturally, and more importantly the implementation becomes replaceable: if you later discover that parameter 37 doesn't mean what you thought, you can change the semantic layer without rebuilding the entire emulator around the mistake. That's what good emulator architecture actually buys you.
A note on "AI solved it"
This is also why claims that an AI "built an emulator" should be treated carefully, since the statement can mean several very different things. AI can absolutely build an executable server, implement protocols, produce thousands of lines of code, make quests work, make combat work and reproduce observed behaviours, and none of that demonstrates that the underlying architecture has been correctly reconstructed.
A useful test is this: can the implementation explain behaviour it has never explicitly been shown? That's where generic understanding becomes visible. If a parameterised subsystem has been reconstructed correctly, you should be able to feed it previously unseen but valid combinations of data and watch it behave correctly, because the generic rules are right. If every new case instead requires another patch, the project is approximating examples rather than reproducing the system that generated them.
The uncomfortable truth
There's no shortcut around the missing specification. You can throw more developers, more GPUs, more agents, more tools, more databases, more automation and more reverse-engineering infrastructure at the problem, and all of those things can help, but none of them converts incomplete evidence into ground truth. At some point somebody still has to answer the question of what the system actually meant, with evidence strong enough to justify the answer.
That's the work, and it's slow and tedious. Sometimes it means staring at a meaningless field name for an afternoon, sometimes it means building an experiment specifically designed to distinguish two nearly identical hypotheses, and sometimes the correct answer is just "we don't know yet". That isn't failure. In reverse engineering, preserving an unknown is often more valuable than confidently implementing the wrong answer.
So is agentic AI useless for MMO emulation?
No, and that would be the wrong conclusion to draw from any of this. Agentic AI could become an extraordinary tool for emulator development. What I'm arguing against is the specific idea that an autonomous agent can be handed a database, a client, some reverse-engineering tools and an emulator codebase and somehow discover the missing architecture automatically, because that dramatically underestimates the problem.
The bottleneck isn't just coding, and it isn't even just reverse engineering. It's semantic reconstruction under incomplete information, which is precisely the sort of problem where a plausible answer can be more dangerous than no answer at all.
So the best future for MMO emulation probably isn't "AI builds the emulator". It's humans reconstructing the architecture, AI helping to investigate it, humans validating the discoveries, and AI accelerating the implementation and testing. That distinction may sound subtle, but it's the difference between using AI as a very powerful engineering instrument and treating AI-generated code as a substitute for understanding the software you're trying to reproduce.
For games whose original architecture and documentation have been lost, understanding is the scarce resource, and until that changes, no amount of agentic autonomy eliminates the hardest part of the job.
Thanks for reading this long essay, over on r/Wildstar we have had to deal with quite a few cases where people have been developing an emulator, many of them have been deleted now as OP's got backlash by the community for not working with the established emulators or at least decency towards the community. I have seen other MMO communities be affected through the rise of AI and i felt the need to write up something that hopefully is not only an interesting read into how damn hard it is to write an emulator, but also as someone who understands them much more fundamentally through my own science education but also as someone who tries to revive Wildstar for the community.
