How to structure a simple game server for a multiplayer game?

Question

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?

Answer 1

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.

Answer 2

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.