Creating Sonic's water-running ability was fairly simple. Detect if Sonic is sprinting; if so, check the block under him. If the game detects a water block, calculate the vertical displacement from the surface boundary. Then, apply a corrective upward velocity vector to the player to maintain the surface alignment.

Use arrow keys to navigate

Drag to change slides

The problem with implementing his ability this way is that it's very prone to breaking due to lag.

If the game misses a couple of ticks due to lag, the player using Sonic will no longer be pushed upwards. When the player inevitably starts to fall, they will touch the water and immediately stop sprinting.

Use arrow keys to navigate

Drag to change slides

This bug creates an unpleasant player experience for players on low-performance devices.

Creating the low-performance fix for Sonic's water-running ability

The simple solution was to move the server player physically higher so that small lag spikes wouldn't immediately cause them to fall into the water.

However, small adjustments weren't enough to mitigate the issue, and large adjustments made the player look like they were floating way too high above the water.

That's when I came up with an interesting solution.

Since the player model and the server player are separate, we can offset the server player upwards and the model downwards when they start water-running as Sonic.

If you look closely, you can see the split second when the player moves upwards, and then the model corrects downwards.

This slight issue with the timing of the offsets is unavoidable, as there will always be a delay between the server moving the player and the client receiving the information to move the model downwards.

Semantically, we could reframe this issue into a feature by saying that Sonic is jumping onto the water, because that's kind of what it looks like.

Either way, Sonic's water-running ability is much safer now on low-performance devices.