The failcakes are baking...

OK, this blog entry is a little depressing for me to write.

I am really, really struggling with the multiplayer thing. At the moment it feels like I've hit a brick wall and I can't see a way over. This is the first time during the life of this project that I have felt deflated, and came close to giving up on more than one occasion.

On a more positive note, I have learned quite a few things about how multiplayer games work. Although that is bittersweet because it also shows me how far off the mark I am. To break it down and really simplify it, the basic premise of client/server multiplayer is like this..

• Hosting server constantly listens for new connections
• Client connects and is assigned an ID
• Client is sent data regarding other player position, orientation, state etc..
• Client processes all this data and updates the game state as necessary
• Client then builds a "datagram" of its own playerstate and sends to the server
• Server receives and acknowledges that information, processes everything, then passes it on to the relevant player(s)
• Back to step 3..

Now that sounds easy, right? Well in theory it is. OK, I've not even mentioned projectile positions and paths, collisions, explosions, sounds etc, but I've learned two pretty major things lately...

Firstly, if you're going to write a multiplayer game, you need to code for it from the start. You can't just "bolt it on" at the end which I am pretty much trying to do. The multiplayer code is so embedded, so integral to the core of the program, that nothing short of a rewrite would make it happen properly. That's not going to happen here.

Secondly, the data packets that are transferred between the client and the host need to be unbelievably efficient. They need to contain all the necessary data, and yet be tiny, and at the same time need to be sent only when absolutely needed, and in a set order. Adding to this, data packets don't always arrive at the server in the same order they were sent, sometimes they don't arrive at all. So this raises the need for prediction and correction algorithms. And all this is happening 60 times each second.

So far, the multiplayer code alone contains more lines than the actual Tank game, and I've only just got it to connect reliably to the host. I'm not giving up on it yet, but I am so close!

All of this has made me realise (and respect) the amount of work that goes into modern day games that we all take for granted. Now I understand why games like CoD have seperate executables for single player and multiplayer, or those games which have a single exe, are usually huge in terms of redundant code.

So right now, I have written a hosting server. Clients can connect to this server and stay reliably connected. The server also knows (and handles the event) when a player leaves for whatever reason. All this works on a local host (127.0.0.1) or over a LAN connection, but that's it. One client doesn't know if another has joined, left, died, fired or anything. I'm still working on it but I'm starting to wish I'd gone down the AI/singleplayer route.

The failcakes are slowly baking but they're not quite ready to eat. Yet.