Some time ago I started to port all the servers to Linux. Now that this process is more or less finished, it compiles fine with Clang (didn’t try GCC) and it even runs without any problems. For that I also had to port DirectXMath, which is used by the game server, to Linux.
Even the client compiles and runs on Linux, but it doesn’t work well, it always loses the connection to the game server.
Now that everything compiles and runs, I tried to connect with the client to the server running inside a Linux VM. What I realized first was that I’m dealing now with real world conditions when it comes to network latency. When the client connects to a server running on the same machine, I always had a Ping (actually a round trip) of 50ms, which is fine. When the client is connected to the Linux server, I get a round trip of ~200ms – ouch! To be honest, I have no idea why it is so high, because the server and client still runs on the same hardware.
Anyway, I think an online RPG must deal with pings above 200ms, and even much higher pings.
In the screenshot above, the round trip time (RTT) is ~250ms, this means it takes 250ms from sending the move command to get the new position. 250ms doesn’t sound much, but it is perceivable and feels really bad.
To deal with that problem, there are different techniques, one is Client prediction, what I made now. Client prediction means, the players client calculates its position on its own and moves the player to this likely position. It does not wait to get a position from the server. From time to time, the client checks if the client position and the server position are too different and adjusts the client position to the server position, also known as rubberbanding. This causes several problems:
- The position of the player on the client and server are probably not the same.
- Sometimes the players character is controlled by the server, e.g. when following an other actor. This is easy to fix, the server just sends a message to the player to turn off client prediction.
- The players client is always ahead of the server and all other clients, but that might not be a big problem, since it’s just visual.
- The client is very dump and does just a rough estimation of the likely position, without considering collisions resulting in even worse rubberbanding.
While the first are mere details, the collision checking seems to be a tough one. For now I have just added a message that forces the client to set the position of an object, e.g. when it would collide with an object. This results in even more jittering, but I look forward to implement basic collision checking also on the client.
>> Source Link