One of the best things about letting people play your game early is that they notice things you don’t.
During our latest playtest, someone gave me a piece of feedback that seemed simple enough:
“If you strafe left and right really fast, it feels like players start desyncing.”
Anyone who’s played an online shooter knows that feeling.
An enemy suddenly slides across your screen.
Someone appears to teleport a few feet.
A gunfight just feels…off.
Most people call it “lag.”
So naturally, I assumed it was a networking issue.
It wasn’t.
The Problem With Testing Alone
Up until this point, most of Voyager’s multiplayer testing happened on my own machine.
Everything felt great.
There was just one catch.
There wasn’t really a network.
When the client and server run on the same computer, there’s virtually no delay between them. That’s great for developing features, but terrible for finding multiplayer problems.
So I rebuilt my testing setup to behave more like a real online match.
I added latency.
Packet loss.
Network hiccups.
In other words…
I made the game feel more like playing with someone on the other side of the country.
Within minutes, the bug appeared.
The Numbers Didn’t Lie
Unreal Engine has a debugging tool that tells you every time the server disagrees with where a player should be.
Think of it as the server saying,
“Nope…that’s not where you actually are.”
After less than three minutes of testing, I counted:
178 movement corrections.
That explained why players felt like they were rubber-banding.
Now I had something better than a feeling.
I had data.
Looking for Clues
The interesting part wasn’t how many corrections happened.
It was how similar they were.
Instead of seeing random values, I kept seeing the exact same numbers appear over and over again.
That shouldn’t happen.
Random network problems create random results.
Repeated numbers usually mean one thing:
There’s a bug in the code.
Somewhere, the game was making the same mistake every single time.
It Came Down to One Line
After digging through the movement code, I finally found it.
One comparison.
One character.
A single “<“ symbol.
During rapid left-and-right movement, the client and server could disagree by the tiniest amount about which direction the player was moving.
To a player, the difference was invisible.
To the game, it completely changed how fast the player should move.
One machine thought you were moving at full speed.
The other thought you should be moving slower.
Those tiny disagreements built up over time until the server finally stepped in and snapped the player back into place.
The players described the bug perfectly.
They just didn’t know what was causing it.
The Fix Was Surprisingly Simple
I didn’t increase the networking update rate.
I didn’t hide the problem with smoothing.
Instead, I removed the sharp cutoff that caused the disagreement in the first place.
Now, instead of instantly switching between two movement states, the transition blends smoothly.
The gameplay feels exactly the same.
The networking behaves much better.
The Difference
Running the exact same test again told the story.
That’s roughly a 50× reduction in movement corrections without changing how the game feels to play.
Exactly the kind of improvement players should never have to notice.
Why I Love Playtests
This bug would have been incredibly difficult to find if I waited until launch.
Instead, one player noticed something felt strange.
That single comment sent me down a rabbit hole that ended with a huge improvement to the game’s networking.
It’s also a reminder that “lag” isn’t always caused by the internet.
Sometimes it’s just one tiny bug hiding in thousands of lines of code.
