Home>

Help me decide on a lag compensation algorithm for a browser-based agario-like game. Communication between client and server via websockets. That is, it should be taken into account that instead of disappearing UDP packets, in which case we will encounter a belated arrival of rotten TCP packets. I read a huge number of articles on the topic of lag compensation for shooters. Everything seems to be clear with the theory, but in practice, questions arise for the arcade version.

Preparation:The server models the game world at regular intervals -1 tick= 50ms. To increase the accuracy, the simulation itself is performed 5 times for one tick, that is, 10 ms each. An important point -if a little more than one tick has passed, the rest of the time is transferred to the next tick. At each tick, a change frame is formed and sent to all clients. On the client, all objects are conditionally divided into 2 groups -the player's body and all the rest. The server models the world according to its own time, without backtracking anything.So far, there are no timestamps from the client side. All player actions are buffered and applied at the same time at the beginning of the next tick, as the action would have been triggered for that particular time.

Suggested algorithm (client side):The player's bodies are simulated on the client at the current time without waiting for server confirmation. All other bodies are modeled using interpolation with a delay of 50 ms. We have two frames -past and future. The position of the body is interpolated from the past frame to the future. On the timely arrival of the next frame, the frames are shifted. If there was a delay of the next frame, extrapolation is used for another 100 ms of spare time or until the arrival of this frame. After the spare time expires, the body stops.

The following is not clear:how to correctly combine the division of the player into two parts with this approach? After all, the enemy that the player is attacking is slightly in the past on the player's screen (50 ms for interpolation + the player himself is half a ping ahead of the server). It turns out that the server is obliged to roll back the positions of at least the players (and in the general case of all moving objects) in order to accurately calculate the interaction? Or is it possible to somehow simplify the algorithm and calculations? Perhaps this game plan needs a completely different approach?

@Vladimir Gamalian, yes, it's a browser game, it's good that there are web sockets. By the way, you can see what has already been implemented at the link in my profile.

sba2022-02-13 15:25:25
  • Answer # 1

    On the server side, you can predict the positions of the players. For example, if a player is running, then knowing his speed, previous coordinates, and the time of the last synchronization, you can roughly determine his current position through sines and cosines. By the way, you can add ping to this formula.

    As for "late packets", if I'm not mistaken, they come strictly sequentially, and it seems like there will be no such thing that 1 packet overtakes another.

    And about the "frames" I did not really understand the scheme. At one time, we made an online game according to the following scheme: The player, for example, presses the run button directly, thereby sending information about his action and coordinates to the server. The server receives the package, and sends it to other players who currently see it, well, it also starts to run for them. If the player stops, then accordingly sends a packet that he stopped, and his exact coordinates, and the server sends this information to other players. To prevent the player from "teleporting" sharply in other clients, we made it so that it smoothly moved to these coordinates according to the formula "the farther the player, the faster it moves."

  • Answer # 2

    On the server side, you can predict the positions of the players. For example, if a player is running, then knowing his speed, previous coordinates, and the time of the last synchronization, you can roughly determine his current position through sines and cosines. By the way, you can add ping to this formula.

    As for "late packets", if I'm not mistaken, they come strictly sequentially, and it seems like there will be no such thing that 1 packet overtakes another.

    And about the "frames" I did not really understand the scheme. At one time, we made an online game according to the following scheme: The player, for example, presses the run button directly, thereby sending information about his action and coordinates to the server. The server receives the package, and sends it to other players who currently see it, well, it also starts to run for them. If the player stops, then accordingly sends a packet that he stopped, and his exact coordinates, and the server sends this information to other players. To prevent the player from "teleporting" sharply in other clients, we made it so that it smoothly moved to these coordinates according to the formula "the farther the player, the faster it moves."