How to deal with faster computers in a client/server real-time videogame

Question

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.)

1. 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.

2. 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).

3. 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?

Answer 1

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.

Answer 2

The following system makes sure all clients and the server share almost the same game state at any time.

Have the state of the game on both client and server.

When a client tries to use a command (mouse, keyboard, etc other input), look on its state of the game if it is valid.

If it is , send the command to the server, without executing it on the sending client.

When the server receives the command, look on its state of the game if it is valid.

If it is, send the command back to ALL clients with the exact future date after what it should be finished being executed on the server, then execute the actions requested by the command after a delay equal to the minimum time to send the command to clients. then record the date, this helps make future prediction. If the time varies too much, make your game system more time deterministic.

When a client receives a command from the server, look on its state of the game if it is valid immediately execute the actions requested by the command, then look at the the current date and compare it to the date prediction received. If it is not valid the client is out of sync. (All clients with a similar connection receive at the same time)

If the date is before, you got a problem in the previous step, fix that. If the date is slightly after do nothing, If the date is long after, the client is out of sync, i.e. the client lags behind too much.

When a client is out of sync, request a copy of the entire game state of the server, and use that one. If that happens too often, fix that because it is more expensive than sending commands.

On the clients, render stuff on screen ONLY when there is nothing else left to do. In simple scenarios the render function takes only current game state as input.

On top of that you can optimize alot, by using predictive systems, grouping commands, render only diffs etc...

Validation should differ, for instance, it's up to the server to limit the command requests / time unit.

Answer 3

I don't know if this is problem of libraries or environment you are using, but I think you are approaching it totally wrong.

In massive majority of multiplayer games, it is only server that is doing any real calculations. Clients are only dumb IO machines where only real performance problem is drawing 3D graphics. And it that case it doesn't matter if client can run at 20 or 200 FPS, because that only affect visuals. That means "client update" has absolutely no meaning. Client might try to "predict" what server might calculate, but that is only to smooth out the feeling of gameplay and has no actual impact on gameplay itself.

faster keyboard speeds

I don't even know what that means. Most people can't even keep up with speed of low-end keyboards, so how would that affect the performance of players?

Otherwise, the question seems quite too broad and you should instead focus on single actual problem, instead of trying to make up "general" problem that you might not even have.