Libgdx multiplayer data management

Question

I think about creating a multiplayer game with Libgdx.
Now i just want to ask which kind of data should handle the server and which kind should handle the client.
Basicly the game should be a 2D platform-shooter kind of game, where you can create your own levels/maps. So i think the map files should be placed in the server files, and sent to the client on connect. Is this right?
Later i think every client should handle its own movement (including collision detection) and send the current position (as Vector2) to the server. Again the question: Is this how it should work?
And one more thing:
If a client shoots, should he:

1. Only send "I am shooting" and the server decides, which kind of bullet to shoot (depending on clients current weapon)
2. Manage this himself and again send only the position of the bullet as Vector2 (and the type of bullet) to the server

In case

1. The server would need to update the position of all bullets and manage their collision detection and then send the positions (and effects, if bullet hits someone/something) to both clients.

2. The client would handle the collision with walls and himself and send data to the server, which would send it to other client. Then the other client needs to check for collision with this bullet. So both clients need to check for collision with the bullets + one client checks bullets-wall collision.

Which way is better or is there an even cleaner solution?

Answer 1

There are several factors to consider when deciding what to compute on the client side and what on the server side. A lot depends on the type of the game and how to handle lag, packet loss, etc. Let us assume that a client determines when an enemy bullet collides with it. The positive thing with this approach is that a player is hit only if the player's character and the bullet collide on the player's screen. However, due to lag, an opponent might observe that a bullet hits another player but on that player's screen the bullet misses. This might be annoying to the opponent as the player seems to "tank" the bullet hit.

Things are not perfect when a server decides when a bullet hits either. Now it can happen that on your screen it seems that you masterfully dodged a bullet but a fraction of a second later you die as your position on the server was slightly different that on your screen and the server decides that you were hit. Personally I'm more OK with other players "tanking" than myself dying without apparent reason.

Of course the game speed affects a lot how much the latency between a client and a server affects the game-play. I guess testing different possibilities is the only good way to determine what works for your game and what does not. It is possible to simulate different amounts of lag and it is possible to compensate for lag (google lag compensation, for example).

One additional thing to notice is that if a server handles all the computation (positions etc.) it can result in jerky or delayed movement of game objects. For example, if some position update packets are lost or delayed, the game object might seem to jump from place to place if the client is not allowed to interpolate the position of the object. Therefore a client should at least be able to handle player's position updates locally. Otherwise there will be a delay between using the controls and seeing the effect on the screen. Of course if the game-play is really slow or all players are on the same LAN this might not be an issue.

Of course the danger of allowing a client to handle most of the logic is that it is easier to create cheats for the game. However, cheats usually start to appear only after a game gains some popularity. Therefore I wouldn't initially worry about cheating and instead concentrate on making the game-play as fun as possible.

Answer 2

It's difficult if the client handles all the logic like collisions etc. One problem is cheating since the server cannot check anything in this case and has to trust the clients. Another problem is synchronization. Two players might have a bad internet connection and have a delay of half a second. They hit each other locally, but on the other client they would not get hit. Synchronizing Box2D, which you might use, is very difficult.

It could be easier if your server handles everything and is responsible for the game world. The clients would only send their "input" to the server, like shoot, run, switch weapon. And the server sends all status information to the clients, like positions, health points etc. The clients would then only render those information.

Multiplayer is never easy and how you should do things mostly depends on the specific game, so it's not really easy to make any statements in general. It really depends on what you need. If you think that you don't need any cheat protection for example, the clients could do more work.