Blur Busters Forums

The Game Feels Sluggish, Enemies Are Too Fast, and You Die in a Millisecond

Here's a theory that might explain this — and it's not about your FPS, ping, or hardware.

Have you ever played an FPS game where:

- Your aim is solid, but you still lose
- Enemies feel “snappy” or teleport while you feel stuck in molasses
- You die instantly, even with perfect ping and no packet loss

If so, you're not alone — and this might explain what's happening.

Theory (based on tests in games like Rainbow Six Siege):
Some games dynamically adjust the size of the packets they send to you based on their evaluation of your connection quality.

If the game thinks your connection is stable, it may send larger packets that contain more data (e.g. 10 gameplay frames worth).
If it suspects issues — even in the absence of real packet loss — it may start sending smaller packets with fewer frames of data.

The server continues sending data, so you see zero loss.
But your client is now forced to interpolate or wait for more updates — causing you to constantly “chase” the server state instead of being up-to-date.

Analogy:
Imagine a mailman is delivering 10 frames of a movie every second.
If the network is perceived unstable, he starts delivering only 5 frames per second.
The movie keeps playing, but now it’s missing half the real information — either repeating, guessing, or skipping parts.

It’s technically a “delivery success,” but you’re no longer seeing the full picture.

Captured Data:
We recorded packet traces in a controlled game session.
Despite similar ping and zero loss, the average size of inbound packets was almost twice as large on one client compared to the other.
That client reported significantly better responsiveness and clarity of movement.

Note:
I’m not from gamedev and can’t name the exact mechanism. But from my background in network engineering, this pattern looks like a deliberate safety-net behavior in the netcode.

Personal Observation:
When the game starts sending me fuller packets (same game, same session), the difference in feel is massive — aiming feels direct, hitreg improves, and movement becomes readable.

Technical Note:
I'm approaching this from a network engineering background.
In the graphs below, please ignore occasional spikes or drops — these are likely noise, such as non-gameplay data (menus, pause screens, etc.).
Focus instead on the consistent baseline of inbound packet sizes during active gameplay.

Graphs from multiple sessions attached below for reference:

What do you think? Does this sound plausible?
Would love to hear from someone with deeper insight into FPS netcode mechanics.

First of all, thanks for sharing your data. I have been trying to analyze this game behaviour for so long and i came to the same conclusion, we are getting few missing packets, that's why the game is not smooth and we die instantly.

My conclusion:

If a few packets are missed, delayed, or contain reduced data, the client may not receive intermediate updates about an enemy player’s movement or actions.
For example:

• The enemy was at position (x1, y1, z1) at time T1, performing action1.

• But due to lost or reduced packets, the client doesn’t get updates for T2, T3, etc.

• The next usable packet shows the enemy at position (x4, y4, z4) at time T4, now doing action4.

That missing interval — from T1 to T4 — forces the game engine to:

• Interpolate or extrapolate the enemy’s position.

• Guess or skip motion entirely.

• Suddenly "snap" the enemy to the new position.

To the player, this looks like:

• The enemy moves too fast.

• They appear late in your field of view.

• They kill you instantly, before your client could register their presence.

less packets → more game mouvement prediction → higher error risk → the feel of sluggishness

jassine wrote: ↑

28 Jun 2025, 12:07

First of all, thanks for sharing your data. I have been trying to analyze this game behaviour for so long and i came to the same conclusion, we are getting few missing packets, that's why the game is not smooth and we die instantly.

My conclusion:

If a few packets are missed, delayed, or contain reduced data, the client may not receive intermediate updates about an enemy player’s movement or actions.
For example:

• The enemy was at position (x1, y1, z1) at time T1, performing action1.

• But due to lost or reduced packets, the client doesn’t get updates for T2, T3, etc.

• The next usable packet shows the enemy at position (x4, y4, z4) at time T4, now doing action4.

That missing interval — from T1 to T4 — forces the game engine to:

• Interpolate or extrapolate the enemy’s position.

• Guess or skip motion entirely.

• Suddenly "snap" the enemy to the new position.

To the player, this looks like:

• The enemy moves too fast.

• They appear late in your field of view.

• They kill you instantly, before your client could register their presence.

less packets → more game mouvement prediction → higher error risk → the feel of sluggishness

Yes, you're absolutely right — you've essentially arrived at the same conclusion I did.

I personally lean toward the idea that the game might be reducing packet size rather than simply dropping them.
Because when packets are lost or corrupted in transit, the game typically starts showing obvious signs (rubberbanding, teleporting, etc.).

But when packets are intentionally reduced in detail, those signs may be absent — the game stays "smooth", but the responsiveness suffers.

That’s why I suspect this is deliberate optimization:
the client gets fewer updates, or ones with trimmed data. Maybe even both — less frequent and smaller packets.

The result is a massive disadvantage for many players, especially those whose connection is falsely labeled as "stable" by the system.
They get downgraded updates and end up seeing enemies late, reacting too slow, and dying instantly.

This completely breaks the idea of fair competition.
There can be no real competitive integrity if the netcode favors certain clients with richer data and leaves others with predicted junk.

It also completely undermines all the talk about "electric input lag".

It seems to me that it would be unlikely for devs to spend time/money on a really strange and highly questionable feature like that.

It sounds like a nightmare to maintain/fix... involving different parts of the engine... a blackhole for dev time, because it'll never work correctly... whatever correctly means in this case -- not even sure.

There's two right ways to do it:
1) just use tcp
2) use udp and then implement some parts of tcp within the data portion

But either way, there's no guessing about someone internet connection quality.

daemonjax wrote: ↑

28 Jun 2025, 12:23

It seems to me that it would be unlikely for devs to spend time/money on a really strange and highly questionable feature like that.

That's a fair assumption — if we were talking about explicit, well-documented features.
But this isn't about some exotic menu option labeled "cripple clients silently".
This is likely an internal scalability mechanism — a kind of adaptive packet shaping —
meant to keep the servers stable under load or to optimize traffic globally.

Games like these handle millions of packets per minute, and small optimizations at the network layer
(e.g., reducing update frequency or data granularity for "stable" clients)
can have a huge aggregate impact on bandwidth and CPU.

So yes — it might not be a "feature" in the usual sense,
but more of a silent trade-off baked deep into the engine.

And unfortunately, this kind of logic punishes players who happen to be routed through cleaner connections,
leaving them with delayed or reduced awareness — while others with noisier traffic get full updates for compensation.

That's why it matters — not because it's evil, but because it's invisible and breaks fairness.

And honestly — trying to understand this low-level behavior is still more productive than switching wall sockets or blaming "electricity"
like some support threads suggest.

Also worth noting: similar adaptive networking systems do exist in other multiplayer games already —
where update rates and payload sizes vary depending on perceived "connection quality" or player prioritization.
This is not a theory anymore — in some engines, it's a confirmed design choice.

jassine wrote: ↑

28 Jun 2025, 12:07

...
less packets → more game mouvement prediction → higher error risk → the feel of sluggishness

*Additional note to your theory:

It's also important to highlight that the client doesn't just miss updates between T1–T4 —
the real problem is that it misses them in the expected tick window.

So either:

• The client starts interpolating stale data.
• Or it stalls, waiting for the next tick to begin processing.
• Or worse — it holds the last known state until fresh data arrives, introducing visible lag or desync.

This behavior severely affects real-time responsiveness,
especially in games where precise timing and animation sequencing matter.

Even a small deviation in expected tick delivery leads to misalignment between perception and server state,
which directly results in unfair deaths, ghost bullets, or delayed enemy visibility.

It's not just packet loss — it's about packet timing relative to the game engine's tick cycle.

Interesting point, but I’m not entirely sure I follow your logic — especially the mention of TCP.
We're talking about real-time FPS games, which typically rely on UDP with custom netcode layers, not TCP-based logic.

As for implementation:
It's actually quite feasible to correlate packet size or update frequency with client ping.
This kind of adaptive behavior is already present in some open-source engines —
and there’s no technical reason major studios couldn’t take it even further.

Now, of course, I agree that devs probably have their own complex solutions,
maybe tied to traffic shaping, entity culling, or smart interpolation buffers.
But if this theory holds, then it wouldn’t be far-fetched at all.

Just to note — so far, I haven’t seen a strong counter-argument that disproves the possibility.
So I think it’s still worth exploring.

Instead of discussing you could use Wireshark to record session, ask someone without issues to do the same and compare them to prove your point.

dervu wrote: ↑

28 Jun 2025, 13:07

Instead of discussing you could use Wireshark to record session, ask someone without issues to do the same and compare them to prove your point.

Colleague, Wireshark is a great tool — but not fully decisive in this scenario.
Each game world and client session is highly dynamic: packet content depends on line of sight,
player position, nearby activity, and even tick timing. So results are inherently non-deterministic.

Also, believe me — I’ve gone through Wireshark back and forth, inside and out.
The graphs I posted already come from those captures.

On top of that, I ran comparative tests with a friend who has a lower ping.
And consistently, his client was exchanging noticeably larger packets than mine,
despite playing under nearly identical game conditions.

That suggests the client may adapt packet size or detail level based on perceived network quality.

No, it's not a cryptographic proof — but it’s enough to seriously consider the theory.

Now we only need to figure out why VPN sometimes fixes this feeling and enemies getting slowed down and suddenly the hitreg connects better ...