Network code of the game - forecasting and correction on the client side

Question

I am creating 2d scrolling mmorpg using winsock and C ++, and I wanted to ask how to program client-side prediction and correction? Well, especially the correction, because the prediction basically just runs the physics code that you use on the server on the client. The server sends patches every two seconds. These messages contain positions X and Y and speed X and Y, and the input is left 0, right 1, jump 1 ...

Edit: Is it normal that I do the same for other clients? Therefore, instead of sending snapshots of position and speed, I send only the changed input, and the local client will predict where other clients are going. The server sends patches every 2-3 seconds.

Thanks a lot!

Answer 1

As a rule, what is done in games of this type:

• Prediction is a "dead calculation" when the server has a client engine with some constant speed (of course, adjusting this speed for gravity, explosions and everything else that happens on the server) until the client updates its current position and speed. For an action game, it’s difficult to find a more advanced prediction than this speed movement * (i.e., try to predict which input is coming).

• Telling the server you are on is tricky. If the server relies on players to send their positions and speeds, the client can fake their position to circumvent obstacles. Ideally, the server will simply receive client input and process the received movement directly, so it can be sure that people are moving legally. However, the delay in receiving input to the server makes this impractical, so you may need a midpoint solution where the client says: "I was here in (x, y) when I changed my speed to (s, t)" (i.e. e. the jump key was pressed at point x, y), and the server looks at this information and says: "In accordance with my predictive movement for this client, it was actually quite close to this point only 0.7 seconds ago, so I think what he really did change his speed to (s, t) at this point. And my forecast for after days 0.7 seconds were inaccurate, so the player is actually at (x, y) + (s, t) * 0.7 "If the server does not agree, he must tell the player where he thinks she or she is currently , so that the player returns to the position indicated by the server. For example, if an explosion occurred on a server before a client logged on to the server, then the client’s self-image in the world ceases to be accurate. Similarly, if a customer tries to send a false position away from their current location or at an absurdly high speed. The server should postpone, so to speak, a hit :)

• The server sends each client the position and speed of each player in his or her surroundings. The position and speed are enough to fully predict and extrapolate the player’s movement. In other words, it doesn’t matter to other players which keys are pressed or something like that, the accuracy has already been confirmed by the server. NPC and AI movements can be processed on the client side, so they do not need to be sent.

• Network games almost always run with UDP sockets. UDP sockets have much lower overhead than TCP because packets are not acknowledged by the recipient. If they are lost, they are gone forever. Although this retains a round-trip confirmation, you cannot assume that the packet ever went to the server or vice versa. This is a difficult task to send input events. It’s ideal to always send the current “snapshots” of the state, not the state changes, because even if the packets get lost along the way, you know the correct state as soon as the packet arrives. In other words, you always want to say: this is where I am and what I am doing right now, and not "I hit Jump 3 times."

So, to summarize, customers could send speed updates and the position the avatar was when the change occurred. The server checks all current states for reasonable values. The server sends this data to other neighboring players (ideally packing all the data about the movement of nearby players in one packet), and the clients use the same prediction model minus the verification of reasonable movement.

Sorry if this is too long ...