Red Brick Games

Gorgeous screenshot of a shallow-water cove, generated algorithmically. Click for full-size.

Other nice screenshots.

I’ve started testing multiplayer using two side-by-side comps, and things are starting to work. Most significantly, replay downloads work. I can’t believe all those 0’s and 1’s are coming out correctly, considering the pounding and mangling they get. I’ve now got about 11 general bug fixes and cosmetic changes I want to make to the game, then it’ll be on to the 1st beta.

A few gratuitous screenshots to celebrate:

Hooray! I just finished coding the last essential parts to networked replays. The server should now send the replay over the network at the end of the game to all connected clients. While clients are waiting, they should see a “downloading” progress bar, until all the data gets there. The progress bar should then go away and the user can play the replay.

There are still a few corner cases I need to finish implementing, mainly when clients disconnect in the middle of the download, but that shouldn’t take long.

Phew.

Implementing the replay feature has felt very reminiscent to implementing the game setup screen, way back in April 2006. Both took similar amounts of development effort, and both were not that fun to work on in the sense they had nothing to do with the gameplay. Actually, the setup screen was worse since the amount of effort it took blindsided me, and it was early in the project when I was eager to make progress on other parts of the game. With replays, at least, it was more apparent beforehand they were going to take a bit of work (with their downloading, loading/saving, compression, etc. aspects)

The replay data compression ratio is now up to 8:1, and graph compression is up to 14:1. A sample game, 30 minutes long and with 4 players, yielded 354k bytes of replay data (raw; compressed it was 42k).

Close enough to my original goals of 10:1 and 15:1. Time to move on.

In other “good news”, if you can call it that, I’ve realized this replay compression is more important than I assumed a couple of posts ago. I was originally thinking the bottleneck was going to be at the clients, receiving the replay.

It’s not.

The biggest bottleneck is at the server. It has to send the replay to as many as 9 clients. Doing a little math, and assuming the server has a 128kbits/s upstream speed (pretty typical of low-end DSL), the worst-case scenario comes out to taking over half an hour to send a big replay out to everybody. Whoa!

With compression, that drops to about 4 minutes. Much better.

It’s good to know that all this development effort is indeed useful.

Here’re a couple of random screenshots. I love the sand texture in these.

Got the replay compression ratio up to about 7:1. (up from 3:1)

Uncompressed replay size for a 25-minute, 3-player game was about 181k bytes.

Joke: how can you tell when an engineer is an extrovert?

Answer: when he talks to you, he looks at your shoes.

I’ve hit a hard spot in Orcs vs. Martians, where it has become difficult for me to get motivated to work on it. I kind of figured this was coming; based on past experience, it seems like when a software project gets near completion, motivation dries up. So, as much as I’d like to write about some interesting progress, progress has been slim. OVM’s replay and compression code has really been kicking my butt as of late.

And to make matters worse, replay compression isn’t even an essential feature. OVM could always just send its replays over the network un-compressed. So not only is my butt getting kicked, it’s getting kicked by something that’s not all that important.

Groan.

Oh well. I made the judgement call that I didn’t want to make players wait 200-400 seconds at the end of a networked game to receive replay data. That’s the worst-case scenario I estimate that a 56k modem user would have to wait, for a large uncompressed replay to download. So here I am working on this mess.

There is some progress. I’m currently getting about a 10:1 compression ratio on compressing the graph data, and 3:1 on the actual replay data. I’m using run-length encoding to get those, plus a lot of other fancy footwork with the actual replay data. I hope to push those ratios up to about 15:1 and 10:1 when I’m done.

It’s also now possible to load & play replays from disk. Loading & saving ended up being a fairly large amount of work, because the replay code had a lot of assumptions in it that a real game had just finished playing. But those assumptions are all out now, and replays now work without any outside context.

I guess I’m fairly close to finishing this phase of the replay work, but the compression code still has bugs to fix, and I still haven’t gotten to the network transmission part.