Multiplayer game principles

Question

I am developing game using libGDX libraries . I want to create multiplayer mode , where several players can play at the same time in the same room , each player can create his own room and other players can connect to the room they want , I thought a mechanism like this In this mechanism the left client is the one who has created the room and other 3 clients are connected to that room . The game physics runs on the room creator and sends the positions of physical bodies to the server , server sends that positions to other clients , other 3 clients send their input to the server and the server sends that inputs to the room creator and that inputs influence on the physic. But I think this cycle is not good because if the device of room creator runs slow then the game will start lagging and the fps will drop down and other clients will see the game with the same fps which is in the creators device . So can anyone offer me another mechanism for multiplayer game? I am using Node.js for server-side program and Java for client side .

Answer 1

I guess the reason why you were choosing this architecture was to keep the computation costs and computation effort low on the server, allowing it to be lightweight. (Another advantage of this approach is that the usually low upstream of the clients are relieved by a server acting as a broadcasting intermediator.) Of course the downfall is that it now depends on the clients performance. There is no way around this connection.

So you have to decide on what to prioritize:

• Better network performance of the hosting client.
• Better performance of the game on the hosting client.

If you have slow handheld devices which should act as clients you might prefer the first solution, using a strong, scalable server that hosts EVERY game/room. If you always have strong clients with a good connection you might keep your infrastructure low in cost by choosing the second.

Another solution would be to do peer-to-peer communication using the server only for initialization of a game, eg. register as hosting client. Thereby you are able to lower the impact on the bandwidth of the server and you don't have to limit the number of games because of a limited bandwidth: The clients do the work.

I would stick with your approach but with a dynamic part. Since every client can start a game/room in your approach it has the ability to run as hosting client. So why not let the clients provide information about their current performance (FPS/CPU/RAM/Bandwidth/Latency) on which the current host decides if another client is a better host. If this is the case the game migrates from the bad to the new, better host.

What you get is:

• Low impact of running games on the server in aspects of network, CPU and RAM.
• Much simpler and better scalable server implementation.
• Always get the best host for every game session, even if my client accidentally starts an antivirus scan or my damned brother a download of pr0n in the middle of the game.
• Low performance handheld devices profit from strong game partners.

As far as I know Awesomenauts uses such dynamic host approach in a peer-to-peer network.

Answer 2

It's usually not a good idea to couple the framerate to the update rate of the network. The internet is just too unreliable for this. Your clients will feel every single lag and jitter.

A better method is to have the server only send changes and have the clients interpolate with them.

So when an object is moving from position A to position B over the course of 50 game ticks, you don't send 50 messages with 50 intermediate positions. You only send two messages. When it starts moving, you send a message "Object O starts moving from position A into direction X with speed V" and when it stops the second message "Object O stops at position B".

This allows the clients to start showing a smooth movement the moment they receive the first message. Any short-time lags during the movement will be invisible. When there is a lag just when the object stops, they might experience a slight jump to the end position, but that's it.