15

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?

  • 1
    In my experience, they don't. This is why gamer machines exist; the ones who pay 5 grand for a state of the art flame thrower automatically have an advantage of the ones still using a Commodore 64. – Robert Harvey Jun 20 '16 at 17:55
  • 1
    So my game play is going to look slow because we have to play to the lowest-common denominator? Seems like the game server should set the tempo and it's up to the clients to keep up or you'll just have to lag. – JeffO Jun 20 '16 at 18:15
  • 3
    I may be misunderstanding the question, but using a tick based client and server model is probably what you're after. gamedev.stackexchange.com/questions/81608/… Basically you just only process input and logic every X amount of time (usually 1/N seconds, such as 1/60 for 60Hz logic) – Christopher Wirt Jun 20 '16 at 18:32
  • 4
    After reading the question a bit closer, it seems that you're too focused on the client aspects of the game. If you want a "fair" multiplayer game, your server is going to have to be authoritative. Meaning that everything that happens to the clients is verified or done by the server. Then you restrict things from here, probably through a tick based system as above. – Christopher Wirt Jun 20 '16 at 18:35
  • 1
    Ah, real-time netcode. The Deepest, darkest place of game development. Welcome to the ship, mate! – T. Sar Jun 20 '16 at 19:42
8

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.

  • 3
    @ProQ it's worth to note that writing good netcode isn't trivial! If your app doesn't work nicely from the start and your netcode seems to suck, don't give up. Even people that do that for a living everyday have issues with it. it is just that hard! – T. Sar Jun 20 '16 at 20:40
0

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.

0

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.

  • faster keyboard speeds isn't about typing, its about how many commands can be sent if you hold down the "move forward" key or the "shoot" key. – gbjbaanb Jun 21 '16 at 7:26
  • @gbjbaanb And how is that a problem? You should only care about pressed and released commands. You should not care about how fast the update it. – Euphoric Jun 21 '16 at 7:29
  • You care if you were handling all events like the OP expected - on the client So if pressing w made you go forward a little distance, and your keyboard was faster than someone else's you'd go faster than them. Last thing you want is to make a racing game you had to keep pressing a key to move forward! – gbjbaanb Jun 21 '16 at 9:32
  • @gbjbaanb No. That is wrong. The server knows "player is going forward" and then every 1/60th of the second it updates positions of ALL players based on if they are going forward. This is how ALL games work. The update loop is same for all entities in game and updates ARE NOT based on events from UI. – Euphoric Jun 21 '16 at 10:01
  • 1
    No, that's not what the OP's understanding was, which is why he asked it, and which is why you said "I don't even know what that means". If you understand the OPs position, then his question makes sense. If the OP has coded his game to work with a game loop based entirely on how fast events are delivered from the client then that's what he is asking about - you are wrong to apply some hypothetical game design to what the OP is actually asking about, regardless of whether his design is wrong by most standards. – gbjbaanb Jun 21 '16 at 10:09

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.