Wednesday, April 18, 2012

Quick Update

I didn't do a lot of programming in the last weeks, because I was busy designing the network functionality and considering different techiques of lag compensation and stuff. I finally came up with a concept that I plan on implementing. If all goes well, the system will be very easy to expand, but I am still worried about performance issues.

What else happened? Creating and joining a game, as well as disconnecting seems to work pretty well now. A basic chat system with a very simple user interface is also in place. This allows me to enter commands without having to program a sophisticated ui. This will most likely look a lot better in the final game, but it does its job for the moment.

Here is a screenshot:
Basic chat interface with join/leave game messages
That's it for now. I will post about my plans for the more advanced network stuff as soon as I verified that it will work.

Thursday, April 5, 2012

Netcode

As mentioned in the last post, I started working on the netcode. It was a more difficult task than I thought initially. The problems weren't with the network itself, but how to structure the code and how to store data.

The netcode is based on the TCP/IP protocol. I did some research and there seem to be a lot of people who say that you have to use UDP, or it will be to slow to work for real-time purposes. In my opinion it really depends on the amount of data one wants to transmit and how frequently that data is sent. The reason I chose TCP is just because it is a lot easier to use. TCP makes sure that all packets will arrive and also that they arrive in the right order. To make UDP usable for such an application, you would need your own TCP-like protocol on top of UDP to make it reliable. The benefit of this approach is that you can decide which packages should be transmitted this way and which shouldn't. I just hope that TCP will be fast enough and I will try to only send data that is necessary to improve network performance.

The hard part was to program the network interface and I am still not very happy with it.
Data is being send in packets. Each packet starts with a packet identifier (e.g. 1 for the login packet), it is then followed by arbitrary data (like a name, a color, a position). The server has two threads for each client, one thread for sending packets and one for receiving. To avoid concurrency problems, the server stores every packet in a packet buffer which is processed and emptied in the server's main thread.

The next thing I am going to do is a basic login and player management system. Every player will need a unique identifier, so he can be referred to in the packet data. I am also going to start working on the class that will later represent the world. The server will modify this class using the information provided by the clients and send the resulting changes back to them. The right choice of what data is processed by the server or the clients is very important. For example if the client would send a position update and the server just takes the information as the player's new position, that would allow for all kinds of hacks like speed hacks or teleport hacks.
Though the game will allow for singleplayer, I do not plan on explicitly programming a singleplayer "mode". That means that if you start a singleplayer game, what happens essentially is that the game will start a local server and connect to that server. The benefit of that is that the code is the same and everything that will work in singleplayer will also work in multiplayer, so the experience will be the same. It is also easier to test the code.

I hope that for the next post I will have some images or videos. This one was rather dry, but I thought it was worth sharing.