MRO-Server: Rebuilding a Dead Mech Game by Decoding Its Network Ghosts

The game is gone. The protocol is not. That is the useful way to read shanzenos/mro-server. The repository is not trying to be a flashy MMO backend. It is trying to make a vanished 2009 mech shooter answer the client again, using the scraps that survived: packets, constants, and timing quirks.

The README says it plainly: "MRO Server This is a server emulator for the game Metal Rage Online, written in nodeJS." That sounds modest until you look at what the code is actually doing. It has to speak HTTP for launcher pages, persistent TCP for gameplay, and a custom binary protocol that only makes sense once the handshake, salt, and checksum all line up.

How the server learns to speak client

The protocol work is the most interesting part of the repo. A connection does not start with readable game events. It starts with opaque bytes, a handshake message, and a server-generated secret that feeds the session-specific XOR path. Only after the header is partially decrypted can the server even know how long the packet is.

// Simplified flow from the repo's packet handling
if (messageId === MSG_HANDSHAKE) {
  const secret = randomBytes(4);
  const salt = computeSalt(secret);
  session.setSecret(secret);
  session.setSalt(salt);
}

const packetLength = peekLength(buffer, salt);
const decoded = xorDecode(buffer, secret, salt);
if (crc32(decoded) !== expectedCrc) {
  throw new Error('bad packet');
}
handleMessage(messageId, decoded);

A dispatcher, not a monolith

The repo's architecture is organized around dispatch. That matters, because the server is not one giant game loop. It is a chain of services that inspect each message ID in sequence and let the right module consume it. In practice, that means login, lobby, room, and social behavior are separated instead of tangled together.

The split between the dispatch server and the game server reinforces the same idea at a higher level. One side handles account and channel selection. The other handles the live session where rooms, chat, and combat state have to stay consistent.

That is why the repo feels unusually precise. It is not trying to invent a better MMO backend. It is trying to reproduce the one the client already believes in.

Room creation is where the illusion gets real

Room creation shows the project's best design instinct. The server does not just allocate a room index and move on. It parses room settings, updates state, and then delays notifications with a timeout so the client experiences the transition the way the original game expected.

// Conceptual shape of the room flow
const roomIndex = allocateRoom();
const settings = parseRoomSettings(packet);
createRoom(roomIndex, settings);

setTimeout(() => {
  notifyPlayers(roomIndex);
}, 2000);

That two-second delay looks small. It is actually a strong signal about the project's intent. The emulator is not only chasing correctness in the abstract. It is chasing the feel of the original session, including pacing, sequencing, and the moment when the UI is ready to accept the next thing.

Why Node.js is a believable choice here

Node.js is not the obvious pick for binary protocol work, but it makes sense here. Buffers are first-class, TCP is straightforward, and the code needs orchestration more than raw throughput. The hard part is not squeezing every last cycle out of a hot loop. The hard part is maintaining enough state to decode the next byte correctly.

That trade-off is the point. JavaScript is not being used here because it is the fastest possible server language. It is being used because it lets one developer move quickly while matching the client's expectations across several protocol layers.

What this project sits beside

MRO-Server does not sit comfortably next to a conventional private server or a polished commercial backend. It is closer to a reconstruction lab. The comparison is useful because it shows how unusual the project is both technically and culturally.

That is why the repo feels significant even in partial form. It is not large. It is careful. The codebase earns attention because it bridges a documentation gap with working software.

The preservation problem underneath the engineering

The most interesting thing about MRO-Server is not that it runs a dead game. It is that it preserves behavior no one wrote down. The server has to infer structure from packets, preserve timing from observed client behavior, and keep rebuilding trust every time a session starts.

That makes the project fragile, but also historically meaningful. A repo like this is a reminder that software history is often held together by people who are willing to decode the ghosts after the official servers are long gone.