Where I left off

Last post I said the next job was to go shopping. Before writing my own server for Fury from scratch, I wanted to check whether somebody had already written one for some other Unreal Engine 3 game that I could stand on top of. Fury runs on the same engine as a bunch of other dead-but-loved online games, and some of those have communities that brought them back. Reusing someone else’s work here would save me weeks.

So I spent a session looking. This is what I found, and why it doesn’t help me as much as I hoped.

The thing I was hoping to find

Quick reminder of the problem. An online game is two programs. The client is on your machine, drawing the world. The server is the referee that holds the real state of the match and tells every client what happened. Fury’s servers died in 2008 and nobody kept a copy. Phase 2 showed me the client actually contains the server’s logic, written in a readable scripting language, just switched off. But the engine-level plumbing under that logic (the bit that actually moves bytes over the network, talks to a database, and so on) is compiled C++ machine code. Not readable. Not reusable.

The dream was: someone has already re-written that plumbing for another UE3 game, put it on GitHub, and I can adapt it instead of building it. Fury’s own script would still be my blueprint for what to say; their code would handle how to say it on the wire.

What’s actually out there

There’s a healthy little scene of UE3 game revivals. The ones I looked at:

  • Tribes: Ascend has taserver, a Python re-write of the game’s login and server-list system.
  • Unreal Tournament 3, Epic’s own UE3 game, has a community that keeps it running with a replacement master server (the “find me a game to join” directory) now that Epic’s is gone.
  • Blacklight: Retribution has BLRevive, a C++ modding framework plus a replacement backend.
  • Mass Effect 3’s multiplayer has Pocket Relay and ME3PSE, which rebuild EA’s online service.
  • APB: Reloaded has rAPB, a C# and C++ server emulator.
  • TERA, another UE3 MMO, has Almetica and a handful of others: full server re-writes, from scratch.

These are real, working projects. People play these games today because of them. Hats off, genuinely, it’s a lot of work.

The catch

Every single one of them cheats in the same way, and it’s a way Fury has already told me I can’t.

They don’t rebuild the referee. They rebuild the lobby around the referee, and then they let the shipped game be the referee.

Here’s the trick. Most online games can run in two modes. Normally you’re a client. But point them at the right switch and the same program you already own will host the match instead, acting as the server for everyone else. Tribes does this. Blacklight does this. UT3 does this. BLRevive’s own documentation says it out loud: the match runs on “the replication server which comes with UE3 by default”, and you start it by literally running the game’s .exe with the word server and a map name. The community project never touches the referee. It just rebuilds the website-y stuff: accounts, the “here are the servers you can join” list, matchmaking, stats.

Fury Community backend I have to build this Shipped game, server mode welded shut (Phase 1) the referee: nobody’s. I build this too.

Everyone else reuses the shipped game as the referee. Fury’s is welded shut, so I have to build that part as well.

I spent all of Phase 1 proving Fury’s copy of that switch doesn’t work. server gets treated as a map name. ?listen, the other way in, crashes the game before it runs a line of script. Auran welded both doors shut in the retail build.

So the projects I found rebuild the easy half and lean on the game for the hard half. I have to do both halves, and the hard half is the whole point of Phase 3.

The two that actually tried

Two projects on that list did aim at the referee itself. Neither hands me a shortcut, but they miss for opposite reasons, and the contrast is the clearest picture of where Fury sits.

APB: Reloaded, and its emulator rAPB. APB is an open-world game, so the lobby trick doesn’t really apply and the project has to rebuild the real thing. Years of work in, the README still has the line that stopped me:

You cannot enter districts yet.

A “district” is APB’s version of a match: the actual place where the game happens. After all that effort, the part they can’t do yet is exactly the part I need to do first. That’s not a knock on them. It’s the clearest possible sign that this specific thing (rebuilding a UE3 match server from the outside) is genuinely hard, and there’s no finished example of it to copy.

TERA, and emulators like Almetica. This one actually is a complete from-scratch server, the thing I just said doesn’t exist. The catch: TERA’s studio ripped out UE3’s built-in networking and bolted on their own. Custom message format, custom encryption, their own system for describing the game world. So the TERA emulators are a ground-up rebuild of TERA’s own protocol, which has nothing in common with the one Fury speaks. It’s proof the job can be done. It’s also zero lines I can reuse.

What I can still use

Not code, but not nothing.

There’s a free version of Unreal Engine 3 that Epic put out years ago called the UDK, the Unreal Development Kit. It’s missing the C++ source and the ability to build a proper server, so it’s not a shortcut on its own. But it ships the script for the engine’s own networking layer. That’s the half that’s invisible C++ inside Fury. So I can read Epic’s own code for how a UE3 client and server say hello to each other, the exact back-and-forth (“hello” / “here’s a challenge” / “here’s my login” / “welcome, load this map”), and line it up against Fury’s decompiled script, which shows the other side of the same conversation. Between the two I should be able to reconstruct the whole handshake without guessing.

Unreal Tournament 3 helps here too, in the same way. It’s Epic’s own UE3 game, its script is readable, and its login-and-join code is a close relative of Fury’s. Handy as a second reference for telling “this is just how UE3 does it” apart from “this is a thing Auran changed”.

[SIDE NOTE] Almost everything written online about Unreal networking is about Unreal Engine 4, which added a bunch of handshake machinery for security that UE3 just doesn’t have. UE3 is the older, simpler version. That’s rare good news.

So, the decision

No shortcut. I write the server from scratch.

It’ll be in C#, for one specific reason: my decompiler, the tool that’s been reading Fury’s files for the last two phases, is already C# and already understands Fury’s exact file format. The network protocol reuses big chunks of that same format (how you write down an object, a name, a property value), so building the server in the same language lets me reuse the parts I’ve already got working. The blueprint is Fury’s decompiled script plus Epic’s UDK script. The typing is all mine.

Next up

The first real task, finally. Point an unmodified Fury client at a port with nothing listening on it and watch exactly what it sends when it tries to join a match. Whatever those first bytes are, that’s the opening line my server has to learn to answer. I’ve got the capture technique from Phase 1, it’s the same setup I used to catch the login handshake, just aimed at a different port.