Hello Internet,

it’s time for an update! I finally completed the work on fps-v0.2 and have now an release candidate to do more testing. Feature-wise I mainly added Client-Side-Prediction, Server-Reconciliation and Delta-Compression and to show you how much better the current version handle’s lag I again made an small Video.

I challenged me to do an simple task: Target the left wall corner and then the right wall corner, in the test-map you have seen earlier. The video show’s the old implementation on the lower row and the current-version on the upper row. The left column doesn’t have any lag, the middle column does have a round-trip-time (rrt) of 100ms and the right column an rrt of 200ms.

As you can clearly see in the left column and the upper row I only struggle with my lack of skill, but without lag-compensation I clearly waggle around my target and with increasing lag the harder it got for me.

Another issue was the packet-size for each snapshot, I added delta-compression to approach this issue. To measure a result I again recorded me, but this time playing against an ghost. The resulting inputs where used to let 4 clients play against each other. Those matches have been played on the old implementation and the current-version.

On the old implementation the client-payload is constant with 30 bytes. The server-payload where on average 435 bytes with min-size 59 bytes and max-size 535 bytes. With the new implementation the client-payload is on average 49 bytes with min-size 18 bytes and max-size 65 bytes. The server-payload where on average 351 bytes with min-size 29 bytes and max-size 631 bytes.

I honestly don’t know how I should feel about that result. I do safe around ~20% of average byte-size but I imagined it would be more. On the other hand I know I have a lot of room for enhancements, but either way it is clear for me I, that need to implement something for packet-size above 1400 bytes.

Next step: make another match against real humans with an real network and evaluate result.

Cheers,

qriz