I'm creating my first online game using socket.io, and I'd like it to be a real-time multiplayer game like agar.io or diep.io.
But I've run into the issue of trying to figure out how to get all the computers to work at the same speed.
I have three ideas for models, but none of them seem right, and I'm wondering how normal videogames do it. (You can skip reading my ideas; they just give you a way to see the problems I'm having.)
-
The server lets the clients run on their own and pass updates to the server, which then broadcasts them to the rest of the clients. This has the issue that some computers run faster than others, letting them update faster and move across the screen faster.
-
Have the server tell the clients when to update. I can then wait until the last client responds (a terrible idea in case one person has a slow computer), wait until the first client responds (again, waiting for communication before each frame), or just send them as fast as possible (which seems to run into the same issue as number 1).
-
At the beginning of the game, have the server tell the clients how quickly to update. This would mean the client would be responsible for restricting movement in between that time period. For example, if someone somehow managed to press a button twice within that time period, it would only send one button press event. This has the issue that some actions would be ignored (such as the double button press), and that the interaction would rely on the clock of the client, which might not match the clock of the server. The server would then have to keep track of each client and make sure their updates are being submitted at the correct time.
I've done some research, but the articles I read don't seem to specifically address what to do if a client sends updates faster than other clients.
In my particular case, I'm dealing with people who have faster keyboard speeds (their computer would send more keyboard updates than other computers).
How do programmers usually deal with this?
Best Answer
Your third idea seems to be the closest to what I think of as the industry solution to this sort of problem.
What you're describing is commonly referred to as Ticks. In each tick, a fixed number of actions would be processed for each client in serial. Often times, game servers will have some parallel actions when capable, but this is a much more complicated problem.
A tick is likely going to be in the form of 1/N seconds, N being the number of ticks per second, or Tickrate. This tickrate could be very very often or very infrequent, depending on your use-case. My personal suggestion would be to avoid a tickrate above 60 ticks/second unless you are sure you need more. You probably don't :)
Actions should be atomic. For example, in slither.io, an action such as moving should not immediately process something like breaking your chain, unless the player you hit has already taken their move. This may seem trivial for something on the level of pixels, but if you're dealing with tile-based movement, it becomes much more obvious, and ensures fairness. If Player A moves to tile X,Y and Player B is currently on that tile, you must ensure that by the end of the tick, player B will still be on that tile for any actions to take place between them.
Further, I'd say avoid having any of your calculations done on the client side unless they are independently done on the server side. This gets complicated and expensive with physics (many games opt for a lower tick-rate for physics than many other actions and events because of this)
For reference, here is a good link to supplement your own understanding of game servers and multiplayer networking.
Lastly, I'd say don't let fairness ruin your server. If there are exploits that cause your game to be unfair, fix those. If it's a matter of a better computer having slight advantage, I'd say it may not be as big of a deal.