This release adds networking back into Egoboo. (There was once a link here, but no longer).

When Egoboo was written back in 1998 (I think), Programmer X added support for playing over a LAN using DirectPlay. Since that’s a Windows-only technology (that’s going the way of the dodo, as I understand it), it was removed when the game was ported to SDL/OpenGL. No one has bothered to try porting it until now.

In 2001 (I think), Aardappel started working on a game engine called Cube, for which he put together a simple but robust networking library called ENet. That’s the library I chose to port the DirectPlay stuff over to.

For the most part, it’s been pretty straightforward. The functions used to put packets together really didn’t change, except for adding code to make them endian safe. Sending packets was just pointing them through a different API, the concept was the same. The difficult part so far has been getting games started (with a host & client computers), and copying files across the network.

Egoboo stores saved players as complete copies of the object directories they were created from in the first place. Same thing with any inventory items a character might have. Because of this, players tend to be at least 600k big, and contain 60+ files each. As it stands now (and did back in ‘98), each remote/client/non-host computer copies each character & item that local players (of which there can be 2 or 4, I’m not sure) will be using up to the host/server computer. Once the host has collected all of the files from all of the clients, it sends them all back out again so that each client gets a copy of all the files necessary. So far, this has been preventing me playing over the internet. Too much stuff to send.

Getting it working was actually fairly easy, though it took me awhile to realize it. The original Egoboo code would split the files up into 2k chunks and send them across one at a time. I assumed I’d need to do the same thing with ENet. I spent days trying to get it working reliably until I took a look into the Cube engine’s code (since that’s where ENet came from) to see how it was done there.

Cube just shoves the whole file into one packet and lets ENet sort it out. That seemed way too easy. But it worked. Shove a file at a time into an ENet packet, send it across, and have the other computer send an OK packet back when it successfully receives the file. Easy.

It doesn’t entirely work perfectly, but I am getting files across reliably a lot more often, and with a lot more speed, than I was by splitting them up into chunks myself. I still have more work to do to make it totally robust, but it’s getting there.

Getting the game started hasn’t been too difficult, by comparison. DirectPlay handled a lot of the work getting games started up before; it has built in lobbying support and whatnot. Cube doesn’t handle that, so I had to rework things a bit so that you can specify a computer to connect to. That part really wasn’t all that hard, I just had to cut out the menu parts that refer to the lobbying functionality and add a new one for connecting directly. It’s kludgy right now; you have to specify the address of the host computer in setup.txt before you run the game, but it works.

And with those things in place, the game now connects and runs on 2 computers over a LAN. (I’ve left it deliberately at 2 players for now, I haven’t felt like figuring out how I should space out sending files to up 8 players at once yet.) The game runs ok, but the speed at which network updates are sent & received is very dependant on the speed of the computers, so it tends to get out of sync really quickly at the moment. So next up, I’m going to look into standardizing the rate at which the game performs it’s various updates. Tune in next time!