Rebuilding a dead racing game's protocol from scratch

The first job was not writing code. It was getting the original client's logic into a form a person could read. The assets were compiled SWF files, so they were decompiled and the ActionScript was read line by line — the older AS2 and AS3 layers both, because the codebase had pieces of each.

Decompilation gives you structure, not intent. You get the branches and the constants, but names are frequently meaningless and nothing explains why a rule exists. What you end up with is a map of behaviours rather than a design document — which is still the most useful artifact you can have, because it turns “nobody knows what this does” into a list of things that can be checked.

The client talked to a server over a protocol that had never been written down. Before anything could be rebuilt, that protocol had to be reconstructed: live traffic captured and decoded until message boundaries, framing, and the meaning of each message were understood, then documented for the first time.

Two details matter more than they sound. TCP gives you a stream, not messages, so the framing — how one message ends and the next begins — has to be recovered exactly, or you get intermittent corruption that looks like a random bug. And message versioning has to be handled deliberately, because a client that has been open for hours will send something an updated server no longer expects.

The written protocol became the specification the rebuild was built against, and later the basis for the checks that proved it. That is the part people skip, and it is the reason most “we rewrote it” projects discover halfway through that they were guessing.

The original design trusted the client. That is convenient to build and impossible to secure: anything the client decides, a user can edit. So the rebuild put a Node.js server in charge of accounts, sessions, and gameplay, and the client stopped being the source of truth. Every meaningful action gets validated server-side before it counts.

This costs time up front, and it is worth saying plainly. Every shortcut the old client took becomes a real problem you now have to handle: reconnects, disconnects mid-action, state synchronization, and reconciliation between what the screen shows and what the server actually recorded. None of that was ever a problem before, because nobody was checking.

Car data, parts, tunes, and compatibility rules lived in merged, half-duplicated stores. They were normalized into a real schema with validation rules and duplicate detection, and only then was player data migrated across — with verification passes run on both sides so a mismatch was caught during the move instead of six weeks later.

The reason for that order: migrated garbage is worse than garbage. Once it sits in the new system it is authoritative, and everyone assumes somebody checked it.

Race simulation runs server-authoritative and deterministic: the same inputs produce the same result. That is not a performance choice, it is an evidence choice. When someone disputes an outcome, there is a record to replay instead of an argument about what probably happened.

The same property is what makes regression testing possible at all. If a result depends on timing or order in ways nobody wrote down, you cannot tell a real regression from a flaky run — so the checks stop being trusted, and then stop being run.

Live packet capture and decoding, run telemetry and timing splits, dyno and tuning validation surfaces, admin panels, and regression harnesses all shipped as part of the build — not afterwards. Hard bugs in a system like this are usually just undocumented problems, and instrumentation is what turns “it happens sometimes” into a case that can be reproduced and fixed.

The tooling also changes who can work on the system. Once content and data can be edited through a panel with checks in front of it, the people who understand the game can make changes without waiting on a deploy — which is the difference between a system that keeps improving and one that only changes when someone is paid to.

The platform runs on an Ubuntu VPS behind a reverse proxy with SSL, process supervision, backups, log access, and restart-on-crash. Releases go through a test pass in front of every build. None of this is interesting until the night something dies and the question is whether it comes back on its own.

If you have software where the only documentation is the person who built it, or a build that works and nobody can say why, that is exactly the kind of problem this method was made for. Send us what exists — code, screenshots, a database dump, a description of what breaks — and you'll get a straight answer about what it would take.