Friday, May 4, 2012

Faster Network and a Name

I am still working on the network code, which will now run on UDP instead of TCP. The decision was not an easy one, but I wanted network play to be as smooth as possible, so I chose UDP, because it doesn't have as much overhead as TCP does.
As mentioned in an earlier post, UDP has several issues. The first is that it is a connectionless protocol, which means that it is not defined wether a client is currently connected or not. The second is that UDP is unreliable. You don't know if packets will arrive and you can't be sure they arrive in the correct order. It is very likely that most packets will arrive in the correct order, but when packets get lost, you will run into serious problems.

So how do we tackle these problems? Solving the connectivity problem is pretty easy: Whenever a player attempts to join a game, the client will send a CHALLENGE_REQUEST message to the server. If the server has a free slot, it will respond with a CHALLENGE_ACCEPT message and add that player to the playerlist.

But what happens if either the request or the accept message get lost? There is a simple solution: the client will send requests until it receives an accept message. If the server already got an accept message and added that player to the playerlist, but receives another request, it will just send an accept message back to the client. This way, if a request gets lost, the client just sends another one. And in case the accept message gets lost, the server will know that, because it will receive multiple requests from the same ip.

A similar system is employed for regular game messages. All game messages are bundled into packets. Each packet has a consecutive sequence number. In every tick (e.g. every 50ms) one of those packets is send through the network. If the packet arrives, the receiver will send that sequence number back during the next tick. This way, the sender knows which packets got through and it can resend packets that got lost. This protocol is a bit more complicated in detail. If you want to learn more about it, you can find all information on this website.

There is still a lot to do in terms of network programming. Using this kind of reliability, packets can still arrive in the wrong order which leads to inconsistencies. How I am going to solve this will be a topic for a future blog post.

We've also decided on a better name than "Dungeon" for our game. The game will be called 

Einherjar 
- Requiem for the Metal Gods -

That's it for now. I hope I get finished will all this network stuff soon, so I can work on things that are more fun and metal-esque.

Rock on! \m/