Empire5 — Rewriting a Legacy C Game Server in Rust

The starting point

Empire is a persistent multiplayer strategy game with a legacy C server codebase (Empire 4.4.1) and its own custom binary wire protocol. Rewriting a live game server from scratch in a memory-safe systems language is exactly the kind of high-blast-radius migration most teams are (rightly) nervous about — get it wrong and every connected client breaks at once.

A phased approach, not a big-bang rewrite

The rewrite was broken into sequential phases rather than attempted as one pass — each phase implementing and proving a specific subsystem before moving to the next, so a regression could be traced to a specific, recent change instead of hunting through an entire reimplemented codebase at once.

Testing discipline mattered as much as the rewrite itself: rather than validating the new Rust server against mocked or scripted test clients, verification ran against the actual legacy C client binary talking real wire protocol — the same integration surface real players would hit. A test that passes against a simplified mock and a server that survives contact with the real client are two different claims; only one of them is the one that matters in production.

Where it stands

The rewrite has progressed through multiple phases of the core game loop and server logic, with remaining subsystems tracked explicitly rather than left implicit. Alongside the server work, a lightweight automation layer drives routine in-game actions on a schedule — a small, real example of the same "automate the repeatable, keep a human in the loop for judgment calls" philosophy TekMage applies to client infrastructure.

Why this is here

Cloud infrastructure work and systems programming pull on the same underlying skill: understanding exactly what a system guarantees, what it doesn't, and what breaks first under real load or a real protocol — not a simplified version of either. This project is where that muscle gets used somewhere the stakes are personal, not billable.