Hello. I have a question about input in multiplayer game. In my game to prevent network stutter client is always behind a server. I'm giving 2 network ticks delay which should be around 100ms(20ticks per second). The problem I faild to solve is how to handle this delay from the server perspective. For example client is pressing HEAL button when enemy is about to finish him at tick X(from player perspective), server currently is at tick X + 2 and before this event arrives(let assume 100ms RTT/2) server will be at X + 4. Now I could rewinde server to client tick and reapply all the inputs but what about tick X + 3 that was send to players with info about player death? My game will be a slow rpg 100-200 player per server game, there will not be a fast accurate gameplay moves(more like tibia style) but still I think this is a problem that needs to be fixed.
Input lag in network game
Hi, if you are struggling with gaming lag check the points in this gaming lag post. Are you on a wired connection?
If your trying to keep lag in the code low, then try and send smaller packets if possible. Whats the ping time on the server?
@jinksey It is not question about high ping or drop packages. I'm searching for an idea on how to handle late packets. What should server do when it is on tick for example 25 and recive packets from client on tick 20. I heard about solution in which server would reverse its state to tick 20 and reapply all the inputs but wouldn't this be an invitation for cheaters? But applying inputs from player tick 20 in server tick 25 is also a bad idea because player action from tick 20 could prevent his death at later ticks. Applying packet(tick20) in a tick it actually arrived(25) would in some cases lead to “unfair” death.
Hi, sorry miss understood your question. I have not had to reverse the tick state before, never heard that as an option before.
Because of the speed of light, someone is going to have a bad experience.
Either, the command to heal myself will get to the server too late, and I will have a bad time healing, but the enemy will have a good time actually killing me, OR my local heal will be made to work based on the local state I see, which means that the remote player will see what looks like killing me, but I end up living, and he has a bad experience.
This also happens with the “dive around a corner” problem when someone's shooting at me; it's possible that I, on my machine, see myself just making it around the corner, only to have the server snap me back to lying dead right before the corner.
Developers will generally choose to run the local player ahead, and every other client behind, meaning that my HEAL command will get to the server in time, BUT I make decisions based on old data; by the time the command makes it to the server, another four ticks of whatever the other guy is doing has made it to the server.
To try to work around that, the client can send more information about what its point of view of the world was ("I shot at X who was at position Y when my tick was Z") and the server can try to patch it up with that world view. The more you open up to the client telling the server what it thinks, the more you can fix up, but also the more you open yourself up to cheating.
This is why, in high-speed, first-person shooters, low ping times and optimized netcode with high packet rates, really do matter. Someone with a lower ping, will make decisions based on a world view that is fresher. That's just how it is, information theory demands it!
The “most fair” way to solve this is to make sure that everybody makes decisions based on the same information. This ends up with the “every command is queued into the future” model, and everybody just sees the simulation, including the simulation of their own actor, delayed, at the same time. When you pilot large battleships, it's OK if it takes half a second for a steer command to start turning the ship. When you play an RTS game, the latency is hidden behind the “yes, sir!” acknowledgement animation. But in an FPS, well, the control response will not be acceptable to most players :-)
