Draffurd, Mushu*, Dillon, Kenny, Alex, Eliwood, and Toxic Hippo. Forgive me if I listed anyone twice or not at all, as people were using some rather whimsical aliases ingame. :)
* And special special thanks to Mushu for inviting more than half of the night's players. :P
And of course what's a test without a screenshot hurled at you, dear readers?
How was the test itself, you ask?
Oh, it was terrible. List index errors popping up for people, access violations crashing people's clients, invisible players sometimes, respawn bugs, and general pandemonium. All in all a disaster. Still, everyone said that they enjoyed themselves. And that's awesome. :D
What's even more awesome is that I've realized through this shroud of disaster a way for me to vastly optimize my network routines. This should cut back the number of packets going in and out exponentially. Not only that, but it'll give me even higher resolution on player data. Fantastic. I've been giddy about this since the testing ended, and I'm really excited about implementing it. Sure it requires a rewrite of the whole network server/client code, but it's doubtlessly and unhesitantly worth it.
For a nice timeline-esque effect, here's how the networking methods of my online games have built up:
First, there was the initial attempt. Absolutely abysmal now that I look on it. For every action performed (firing, moving, dieing, chatting, etc) a packet was sent. I did the math, and the equation was rougly Players * (Players-1) * 2 for movement packets alone, per second. For 10 players that's 180 packets per freakin' second! :-O
Second, there's the current method. It improves things a lot, but still isn't making the cut. Several times per second (usually 3) movement data is send out about all of the players inside one packet. This saves heaps of packets, so I'm not sending one packet about each player's action to everyone. However, although I'm sending a list of players that have performed this action fit into one packet-a-piece, this still adds up quickly. The rough equation for packets send per second is Players * 15. Crud. When the playercount goes up it ends up being only marginally better than the old method. I dubbed this the "postcard method" because we send out a postcard to the client/server every single time some action happens.
Now, there's the new method. I really like it, even though I'm sure it's a "duh" thing for most of the dwellers of the Multiplayer and Network Programming area of GD.NET. I like to call it the "newspaper" method. Instead of sending data about every single action when it happens, we just record events that have happened since the last packet, and then 3-4 times per second we bundle all of that 'news' into one packet and send it off. So it's like a newspaper of all of the things that have happened since 250ms-300ms ago. It will obviously result in a bit of a delay in some actions, but I'm confident in my ability to make the game compensate. This allows the client to have a constant in/out packet rate of 3-4 per second. The server will have an in/out packet rate of (3-4) * Players. Sure the packets will be a little bit bigger, but I think that even a 56k modem can handle a hundred bytes or so.
Aye, that was quite the nice ramble. I doubt anyone got much from that, but I hope that it wasn't all for naught. ;)
So the game plan is to put the rest of v0.04 on ice and rewrite the network code for Skirmish Online. This will likely take a little while, and require painful testing. Now that I have a few more GD.NET folks on my MSN -- with no escape in sight -- I'll be sure to poke them now and then for help with testing. >:)
(Oh, and 50 points to Ravuya on his nifty GamesDB project. Go bug him for an account. :))