I would like to create a simple multiplayer game server for a simple game:

The game is supposed to be similar to Command & Conquer, you have a few tanks and a few soldiers. You can select one soldier and than click on the map, to where the soldier should go. If the soldier comes to an area where he could not go, he walks around. And soldiers can be shot down by enemies.

How should I structure the game server, and what should be done at the client?

I.e if a soldier moves from X to Y but around building Z, I guess the server has to be able to calculate exactly where the soldier is located (in case an enemy shot at him), and the client also has to know the position for painting the soldier.

What should be done at the server and I think I have to desing a protocol for this. I think the server has to keep track of the game state and the time. Is anyone having suggestions on how to do this? or could recommend some reading?


2 Answers 2


In general that's a very complex subject. You have two conflicting aims (at least if you don't plan on running every single game on a dedicated server):

  1. You'll want as much as possible done on the server, both to prevent cheating and to make sure all clients see the same things.
  2. But you also want things to be fair, which means if one person has a 0-time ping to the server while others have network lag, when both issue a command to their units at the same time, the "server" player has an advantage.

I can't exactly say how to solve that for an RTS. What we do for our FPS firing is have the server save a complete world state a while back and let the client timestamp every shot. When the network message for "I fired!" reaches the server, the server can roll back the world and do collision tests etc on the world "as it looked for the client when the shot was fired".

If you're planning on having lots of units, you'll also have the problem of potentially having too much processing for the server to handle. If you're not terribly worried about hacking or cheating, I'd suggest doing pathfinding on the clients, and sending the results of that over to the server.

Yet another option might be to go peer2peer on it instead, letting each client deal with the updates for the local teams, but that then opens up the question of how to determines who hits what and so on.

Depending on how complex this project is and how much effort you're willing to spend on it, my best suggestion would be to decide something preliminary and start working on it to test it.

  • 1
    \$\begingroup\$ Actually there are three (or maybe more) conflicting aims. The third is performance, keeping and updating the state of a realtime game fully on the server uses a lot of resources. \$\endgroup\$ Commented Jul 28, 2010 at 20:09
  • 2
    \$\begingroup\$ Oh, and you can easily solve #2 by introducing artifical lag that's equal to the average of the other players' lag. Well, if you can call "making it bad for everybody" a solution, that is. \$\endgroup\$ Commented Sep 3, 2010 at 9:41
  • \$\begingroup\$ @Bart: partly true, but of course there should be a cap on how much lag you artificially introduce, or slower connections could constantly force quicker connections to lag too much, which is definitely now what you want. \$\endgroup\$
    – o0'.
    Commented Sep 23, 2011 at 13:03
  • \$\begingroup\$ Finding the best path is no problem if done on the client, as long as once he has found it sends the solution to the server, which — as with all movement — checks if it is correct. \$\endgroup\$
    – o0'.
    Commented Sep 23, 2011 at 13:03

There are basically two approaches:

  1. Trusted client
  2. Untrusted client

The trusted client is a little bit more complex, but has the advantage that you can offload a lot of your computation from the server. Cost of server operation is one of the biggest problems for multiplayer games and will seriously reduce your scalability.

A good approach (for beginners) is to let each players client handle it's own units. In the next step you can use spare cycles to let players clients verify other clients actions. Server shouldn't need to do more than exchanging messages, keeping sync and ensuring persistence (e.g. database).

If you plan to have some kind of lobby or chat then then handle each of these topics in an extra server. It will make things a lot easier down the road.

  • \$\begingroup\$ Thanks, that was informative. I think I will go for untrusted clients, and do must of the work on the server. I will not have many players at the beginning. \$\endgroup\$
    – Jonas
    Commented Jul 16, 2010 at 13:39
  • 1
    \$\begingroup\$ "I will not have many players..." I can't count the number of developers giving me that line and coming back six weeks later with: "I have these 5000 players wanting to pay to play my game, but I cannot scale :(". Just keep that in mind! \$\endgroup\$
    – Andreas
    Commented Jul 16, 2010 at 13:43
  • 9
    \$\begingroup\$ "Trusted client" is not an approach, it's a mistake. \$\endgroup\$
    – o0'.
    Commented Nov 17, 2010 at 11:08

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .