0
\$\begingroup\$

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 enter image description here 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 .

\$\endgroup\$
  • \$\begingroup\$ Just for learning more about game networking, parallel simulations (server/client) and getting in touch with the problems of this topic you might be interested in this great presentation: Video, Slides \$\endgroup\$ – Sebastian Barth Jan 29 '15 at 9:51
1
\$\begingroup\$

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.

\$\endgroup\$
  • \$\begingroup\$ I think I should choose the way I thought, because if I run physics on the host it can't support several rooms (dual core 2.8ghz ) \$\endgroup\$ – Vahe Muradyan Jan 26 '15 at 16:16
  • \$\begingroup\$ I'm not sure if I got you right or you misunderstood me. I propose to have a physics simulation per room (game session). This simulation is hosted at the creator at beginning of the game. This host is responsible for only this game session and its physics. If it is not strong enough it passes the ownership of the game session to another, stronger client in the same room (game session) which from now on plays the local server for physics and coordination: For all clients in the same room there is only one of them which acts as the server and only for this room and no other. \$\endgroup\$ – Sebastian Barth Jan 26 '15 at 18:47
  • \$\begingroup\$ I understand what you say , I`ll try to do in that way, thank You \$\endgroup\$ – Vahe Muradyan Jan 26 '15 at 20:06
0
\$\begingroup\$

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.

\$\endgroup\$
  • \$\begingroup\$ The correction of the position (when the message about the final position comes in) can be smoothly done over time. Imagine a rubber band connecting the correct position with the character on a wrong calculated position. The greater the distance the bigger is the force toward the correct position and so the way the player is moved toward the correct position per tick. \$\endgroup\$ – Sebastian Barth Jan 26 '15 at 14:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.