From Veloren: link to original post

- AngelOnFira, TWiV Editor

Contributor Work

Thanks to this week's contributors, @zesterer, @Christof, @juliancoffee, @tygyh, @xMAC94x, @Isse, @aweinstock, @Treeco, @AngelOnFira, @Sharp, @Treeco, @DaforLynx, @LunarEclipse, @Socksonme, @VincentFoulon80, and @UncomfySilence!

@LunarEclipse has updated the Polish translations.

The roadway to better server-side physics by @xMAC94x

There are currently 2 physics modes: client-side physics which is prone to hacks and has low latency, and server-side physics which is not hackable (or so we think) but has high latency. Here's how we want to get the best out of both.

First, let's have a look how current server-side physics works. Assume we have a Server, ClientA. and ClientB. The latency (ping) of ClientA is 300ms and the latency of ClientB 200ms. This means that sending a message to the server for ClientA takes ~150ms, and getting a message back takes ~150ms. So when ClientA jumps it takes 150ms for the server to find out, and then 100ms for ClientB to get that update. ClientB sees this after 150 + 100 = 250ms. Even worse: The same goes for ClientA, it sends the message to the server, waits for the servers answer and therefore starts the jump animation after its ping time, or 300ms+. 300ms till the press of a button and seeing something happen is unplayable.

Our new server-side physics will work with 2 clever tricks:

1. A client no longer waits for a message to go to the server and back, but will start the animation immediately
2. Voxygen does not show you what the server sends you, but always "project" a latency + a bit in the future.

Lets deep dive into the latter one. The server counts the time since its start, the so called tick time. starting with 0s, and increasing every tick by ~33.3ms. Lets look at what happens a bit after the game starts, at time t=10s. The server makes it calculations and sends an event to the client: Arrow is flying to your feet and will reach you in 1s!

ClientA does not yet know about this arrow, as the message hasn't been sent over the internet. It takes 300ms, so at t=10.3s, the client receives the message of the arrow. Now comes the fancy part. ClientA knows the message was sent at the server at t=10s, so the client will revert it's time back to t=10s and now simulates 300ms. If we would keep it like that the client would see the arrow 700ms away.

This is good, Voxygen already substracted the 300ms for the latency from server->client. But we dont stop here. We are simulating another 300ms + a bit (lets say 50ms) = 350ms. This way, we are taking into account the time it will take from the client to the server. The 50ms are a small buffer that will be explained later.

The actually image ClientA will see shows the arrow only 350ms away from their feet, as we show 10.75s even though the time is t=10.3s The client now sees exactly what the server will see once their message arives, so they quickly press the jump button. ClientA sends a message to the server: Hey, I want to jump at exactly t=100.65s. When the server receives that message another 300ms are gone, it's not t=100.6s. The server processes the jump-request and sees: it's still valid, it was send 50ms ahead of time and starts the jump of ClientA.

All this what we spoke about will repeat endlessly. with each message from the server additional info is send, e.g.: your message was 50ms early. This will then be used at the client to tighten the timings and calcualte the ping.

For this algorithm to work flawlessly we need to improve the accuracy of our tick calculations and physics calculations. We need to predict a lot of variables and constantly need to adjust the 50 ms buffer we talked earlier about so that the image doesn't appear laggy. All this is another story for anther blog but needs to be done first. Expect it NOT before the next release party.

Support the project!

Veloren Open Collective