Bezgelor

On fidelity: what we can and can't reconstruct

A response to "Why agentic AI isn't the solution to MMO emulation (but probably part of it)"

In 2026, u/der_dotte, who spent several years working on NexusForever, posted a long essay to r/WildStar about AI and MMO emulation: Why agentic AI isn't the solution to MMO emulation (but probably part of it). It is one of the clearest explanations we have read of why reviving a lost online game is hard. We recommend reading it in full, comments included.

This page gives our view of the piece, says where it applies to Bezgelor (much of it does), and lists what we are doing about it. Much of it applies to projects like ours, and we think it is right on the important points.

What the essay says, briefly

  • The hard part isn't writing code; it's recovering meaning. A data-driven game like WildStar ran a small number of generic systems over thousands of rows of data. The data survives in the client; the specification of what each field means does not.
  • Data is not documentation. A table tells you a field exists and which values it takes. It doesn't tell you which system reads it, how, or under what conditions.
  • The dangerous failure is the one that works. An implementation can reproduce every case you tested while modelling the system wrongly ("A → X" standing in for "A + B + C → X"). It keeps looking right until the case that tells them apart turns up, deep below the symptom.
  • Agents can amplify bad assumptions. An observe → hypothesise → implement → test loop mostly tests the implementation against itself. Without ground truth it optimises for consistency, and can become "increasingly coherent while increasingly wrong", with each guess quietly becoming architecture.
  • Uncertainty has to be kept, not resolved by convenience. Good reverse engineers hold competing hypotheses with confidence levels, evidence, counter-evidence and the next experiment. "We don't know yet" is a result.
  • Architecture before features. Fixing one quest with a special case solves one symptom. Recovering the generic mechanism solves all of them.
  • The goal is a reconstructed specification, shared so that the whole community benefits, not just one codebase.
  • A good test: can the implementation handle valid data it has never been shown? If every new case needs a patch, you are approximating examples, not reproducing the system.
  • AI is still very useful, as an instrument that speeds up understanding rather than a substitute for it: searching, correlating, generating tests, building tools, and managing evidence.

The comments add three things we take seriously:

  • The truth isn't (all) in the client. WildStar has no equivalent of the large live-game databases some older games have, and server-side behaviour (damage rules, creature AI, scripts, drop rates, encounter timing) mostly can't be read from the client.
  • The cases only the server triggered. A server can satisfy every message the client sends and still be wrong about behaviour that only the original server ever caused. Studying the client can't reveal those.
  • The reviewer is the bottleneck. Generating code is cheap. Confirming it matches the live game needs people who remember the live game, and they need to know exactly what to look at.

Where it applies to us

We'd rather say this plainly than defend ourselves against it.

  • We have written special cases. Some of our fixes recovered a generic mechanism: target groups, objective types, exclusive quests, kill experience by creature rank. Others patch individual quests or stand in for missing events, which is the pattern the essay warns about. We track them, and the aim is to replace them.
  • Most of our tests check our model, not the original. Our headless "day one" levelling runs show that the content can be completed with our interpretation, not that our interpretation is right.
  • We generate a lot of content because the data is incomplete: spawn placements, boss ability timings, and values chosen in code. Each piece is labelled, but labelling a guess doesn't make it right.
  • We move fast, which is exactly the setting in which a guess can harden into architecture.

What gives us some ground truth

Some evidence is stronger than inference, and we lean on it.

  • The client's own code. The client contains the logic it needs for prediction and the user interface: prerequisite checks, telegraph shapes, parts of combat maths, how messages are read. We run the client's own message reader on every packet our server sends (the client oracle), and we can run other client functions the same way to check our implementation against the original. That covers the client's half of the contract with certainty.
  • Retail captures. NexusForever's world database was built from captures of the live game. Where it covers something, it is real server behaviour, not a hypothesis.
  • Several independent sources. The client's tables, its decompiled code, its UI scripts and their documentation, captures, statistical patterns across thousands of rows, and patch notes and guides. Where they agree, confidence is earned. Where they disagree, that disagreement is the next experiment.

What we are doing about fidelity

  1. Label everything we didn't get straight from retail data. Every generated record is labelled reference, derived or guess, with its basis, and a test fails if new data arrives without a label. The WildStar delta lists every guess.
  2. A semantic registry. One entry per data field and enum value of the generic systems, starting with quest objectives and prerequisites. Each entry holds the best current meaning, the competing hypotheses with confidence, evidence and counter-evidence, the code that implements it, its tests, and the next experiment. Unknowns stay recorded as unknown. This is the reconstructed specification the essay asks for, published so anyone, NexusForever included, can use it. The pilot also runs every data row through our code, lists every per-id special case with its issue, and checks prerequisites against the client's own evaluator; the first pass found and fixed six places where we read prerequisites differently from the client.
  3. Measure generalisation, not just passing tests. For each generic system we'll report how many of the data rows that use it our implementation handles without special cases. We'll also count the special cases themselves, which should fall over time.
  4. Check against the client's own code wherever the client implements the logic, by running its functions as a reference. First result (2026-10-12): running the client's own prerequisite evaluator against ours over 6,000 real cases found six places we read prerequisites differently from the client. Two came from a reading we had inherited, with comparison operators swapped. They changed which quests players can take. All six are fixed, and both evaluators now agree on every recorded case.
  5. Inventory surviving ground truth. We've catalogued what still exists about live behaviour, such as captures, archived community databases, guides and patch notes, and what each source can settle, in Ground truth: what survives of retail. Facts only memory or footage can settle become specific questions for people who played.
  6. Make human review count. Each feature ships with a client-test checklist: exact commands, expected results, and specific "report whether…" questions. They're precise because, as the comments point out, testers need to know exactly what to look for.
  7. Say how we test, exactly. How we test instances describes the encounter simulator and states plainly that our retail timing references are estimates (nobody on the project has timed footage), not measurements.
  8. Rate every part of the game on one scale, with evidence. The fidelity map rates each system and zone on one scale (Unbuilt, Working, Complete, Checked), each word with a written test, links the evidence for each rating and says what would raise it. Its zone ratings are checked by a script that refuses a rating its numbers don't support.
  9. Publish the knowledge, not just the code. The protocol reference, the Lua API reference, the oracle, the test reports, the delta and the semantic registry are all here, so a discovery made once doesn't have to be made again.

Why "Bezgelor", not "WildStar"

This essay is part of why the project has its own name. Copyright and trademark are one reason. The other is honesty: rebuilding WildStar exactly is close to impossible. Too much of the server's behaviour existed only on servers that are gone, for exactly the reasons the essay gives.

What we think is possible is getting close, being open about where we're guessing, improving as evidence turns up, and having fun building it and playing it together along the way. Bezgelor is our name for that: a game that grows out of WildStar's surviving data and the community's memory, labelled where it differs.

How you can help

  • If you played WildStar: the guesses in the WildStar delta are questions only players can answer. "Did this boss's ground circle last about 45 seconds?" Answers with a source (your own footage, a guide, a screenshot) are the most valuable thing anyone can give us.
  • If you test: each feature's client-test issue on GitHub has a checklist. The "report whether…" lines are the ones we most need.
  • If you reverse engineer: challenge our registry entries. Counter-evidence is as welcome as confirmation.

Thank you to u/der_dotte for taking the time to write it, and to everyone in the thread who added to it.