T+26

By now there might be some random (missclicked) readers who are not affiliated with me @ school or otherwise and might want to know what are these two games about. Actually Tanksalot is maybe over 80% complete and Quickrally - while never going to be totally finished - has come a rather long way too.

Quickrally

Quickrally is my flagship project at the moment. It is going to be very much multiplayer-only driving game. I'm leaving out all the boring career modes and fony stories. Focus will be on driving and driving only. One feature that sets Quickrally apart from other driving games is the procedural side of it: The track will be different everytime you race. Now it's more about driving skills and less about memorizing all the tracks to beat your friends.

Tanksalot

Tanksalot is a game I've been coding couple of months now. It's a school project for a course called "Introduction to Game Development Tools". I have three other people besides myself in the group doing modelling, 2d-art and audio. It is split-screen tank duel with non-linear fire and very simple game mechanics. We decided to do cartoon-like style celshading and I really like how it looks now. I might do celshading in Quickrally too.

First day of war

I got over the fence and into the trenches tonight. Coke bottles were opened, coffee ended up being very strong and beautiful code started to emerge. Well, not so much emerged, but the existing code took some refactoring blows and heavy cleaning was being made by our late night coding hero. I also started to get better vision how to implement networking into Quickrally and that is what I'm going to explain next.

Networking

Networking in a real-time fast-action multiplayer game is not very easy or straightforward. I would not recommend it to anyone doing their first project. There are no complicated mathemathics involved, but quite alot of ways to hang yourself while implementing your multiplayer extravaganza. Be warned: You are almost always screwed, if you try to add multiplaying features to your game afterwards, unless you have used some very sophisticated event-based architecture in your game. And even then you are still probably screwed anyway.

The story of multiplayer networking

Once upon a time, you were player in this distributed world (it means that the world exists in multiple computers). You decide, that it is time for you to walk forward, so you send the server a message: "dear server, I would like to walk forward, if this is anyway convenient for you, sir". Notice the polite tone in the message. This is due the fact, that in this very world, the server is in charge of everything. The server is the KING. You do not f*** with the king. After all, what kind of world would it be, if every person could decide the laws of physics for themselves? A world very hard to implement in any programming language I know.

So back to the story: The allmighty server gets your request. It does some calculations and decides to reply: "So you little punk, you wan't to walk eh? ... well go ahead, your coordinates are now x,y,z and your velocity is v". This message is sent to all the players nearby, so that they all would see you in your new position. After all, all the other players are in a different dimensions, interconnected only by his highness the server.

So everyone got your new location. Well, everyone except your cousin riding on a horse toward you. The king uses high-speed messagepidgeons to deliver these messages, and the very bird that was going to deliver your cousin the information, had one too many tortillas for lunch, and has stopped somewhere along the way to take a dump. So now you're cousin is not aware of our hero's new location, which happens to be right across his path. The king has also set a new law, that in order to save money, he always waits for the pidgeons to get back to send new messages. So while the king is waiting for your cousins constipating pigdeon, his next physics calculations get closer and closer to a crueling outcome: You, my friend, are kaputt.

Afterwards, your cousin decides to bury you right there in the spot. While he is digging your grave, the unfortunate pidgeon finally arrives and delivers the message. The cousin reads it and goes red-hot-al-qaida-mad, screaming his lungs out: "what the f*** am I going do with this now?!". If only the message got there in time.

The pidgeons in this story were UDP-based by the way. It means that they are fast and light, but not guaranteed to arrive in order, or better yet, not arrive at all. There is a simple solution: The king has to send pidgeons after pidgeons and not wait for the comebacks. In a time-critical game, the information gets old the very second it is being sent. Nobody wants to know your location 2 seconds ago. It's yesterdays news.

TCP or UDP?

Awhile back, when I started to research the subject, there was alot of dispute over which protocol to use. I don't know if the disputes still go on. If I had to guess, they are. Have you ever heard a dispute being settled in the wonderful world of interwww? I sure haven't.

My advice is this: The more time-critical your games, the more you want to lean toward UDP. If I'm doing a game like fast FPS-shooter or driving game, all the milliseconds in our response-time are going to make a huge difference. UDP gets things done faster and lighter, so it is the weapon of choice for fast-action. After all, how wrong can mr. Carmack be?

Then again, if you are creating turn-based strategy or slow-based roleplaying game: Go for the TCP. It guarantees order and delivery which makes life alot easier when your needs are more toward events and less about current state.

There is also third option: the hybrid model. Use UDP for time-critical data and TCP when you need more hi-fidelity order and delivery. I personally dislike this approach (in theory) for it's messiness, but have actually never tried it myself, so I try to refrain myself from making foolish comments about stuff that I'm too retarded to implement.

This ended up to be a very long post indeed. I got a little carried away by the subject, but no harm done I guess. Tommorow I might get my multiplayer implementation to actually work and maybe I'll explain my approach in a little more detail.