Replays, Networking, and Torque
Tuesday, September 18th, 2007Implementing Orcs vs. Martians’ replay feature is turning out to be a big project.
Replays already “mostly” work; currently, the biggest feature hole is that they don’t work for online games. The clients don’t have the replay data. So that’s mainly what I’m working on: sending replay data from server to clients, and sending it efficiently.
Technicals
I tell you what, working on this feature highlights a truism I’ve learned about game development - getting a game to be playable over the internet, adds a lot of development work.
At least, that’s been the case with OVM. I estimate, unscientificly, that implementing network support in OVM has increased its development effort by somewhere between 50% to 100%. That’s a lot.
IMO, it’s not too hard to make a game that sends bits over a network, especially not with Torque. But, it’s much harder to make a game that sends real-time data:
- bandwidth-efficiently - so the game is playable over a 56k modem
- with low latency - so the game doesn’t “lurch” due to bursty network traffic
- securely - so clients get minimal data that would allow them cheat
Those are hard to achieve.
When I first bought Torque, I imagined it would “automate” most of the networking stuff for me. That’s not the case, though. Torque doesn’t really automate anything network-wise, so much as it gives you a nice design pattern to follow, and the low-level tools to follow it. As your write your own networked object classes (for example, like OVM’s Unit and Building classes) you have to write your own data serialization code yourself.
That means those issues - bandwidth, latency, and security - still fall on the shoulders of the Torque developer, and not on the engine.
(I don’t fault Torque for this; in retrospect my expectation was unrealistic)
Anyway, back on the subject of replays: the main trouble with them stems from the fact that they involve a lot of data. For OVM, the worst case scenario will probably involve about 1-2 MB of replay data.
So, for one thing, that data needs to get compressed down before being transmitted anywhere.
And besides compression, another issue is that as far as I can tell, Torque lacks a mechanism for sending a large chunk of data over the network. Really, I’m not kidding! Ppppthth!! I guess Tribes/Tribes 2 never had the need for such a thing.
Torque is good at sending small, incremental, updates for objects, as the objects move around in a game. But I can’t find an API for a big chunk of data. That’s a problem for me, since I’d like to send the replay data at the end of the game, in one big chunk.
The closest thing Torque has to that is an API for sending files from server to clients. Unfortunately, I can’t use the file API, since (1) it only works for files, and (2) the files have to exist at game start-up, i.e. they can’t be created in-game. Plus, it has a few other limitations.
Fortunately though, the file-sending API is close to what I need, and it has a pretty small implementation. So I’m going to try copying the implementation, and modifying it to work for in-memory data. Then, I should be able to use it to send compressed replays.
