# Lag Compensation with Fish-Networking: Collider Rollback and Projectiles for Fair Multiplayer in Unity

*Fair hits for dense IO-style fat games—free accelerated projectiles and Pro rollback under real latency and WebGL budgets*

![Lag Compensation with Fish-Networking: Collider Rollback and Projectiles for Fair Multiplayer in Unity](https://pub-07fb5e4955ba485b822d6b388be96d9a.r2.dev/627e11da-a23a-494d-9964-843e8f31c507/fishnet-lag-compensation-collider-rollback-projectiles-unity/hero-d0313349-e009-459c-95aa-db81e9fef944.jpg)

**TL;DR:**

- Pro collider rollback rewinds server hitboxes to the client’s view time so raycasts land fairly despite latency.
- Free accelerated projectiles spawn instantly for the owner and catch up on server/spectators—no per-tick movement networking.
- Send PreciseTick with fire/action RPCs and match TickSmoother Additional Ticks so rollback depth is exact.
- Schedule server-only states (EMP, slows) a short future tick via ObserversRpc to avoid prediction desync.
- Pair with pooling, interest management, and URP (SRP Batcher / Resident Drawer) so dense IO scenes stay WebGL-viable.

In dense IO-style and fat multiplayer games, a hit that felt perfect on the client often misses on the server. Latency, tick misalignment, and prediction all pull the world the player saw away from the world the server is simulating. The result is frustration, not skill expression. Fish-Networking solves that gap with two complementary techniques that keep authority on the server while still feeling instant to the player who fired.

**Lag compensation, also known as collider rollback, is the act of placing colliders back in time on the server to provide accurate raycast hit detection regardless of client latency.** Fish-Networking Pro supplies ColliderRollback and RollbackManager for that path. Over-time projectiles do not require Pro: they hide lag by accelerating on the server and for spectators while the firing client shows the projectile immediately, and they avoid networking projectile movement each tick—saving bandwidth and CPU in crowded scenes. Even with a 220ms client ping the projectile stays aligned on the server when you pass the right timing data.

This article walks through both approaches end to end: when to use rollback versus accelerated projectiles, how to send PreciseTick with fire RPCs, how to keep server-only states (EMP, slows) in sync with future-tick ObserversRpcs, and how to combine the whole stack with client-side prediction, object pooling, interest management, and URP WebGL budgets so fair hits scale to high player counts without melting the frame or the bill. You will leave with concrete patterns you can drop into a live Fish-Net project and validate under simulated latency.

## Why Hits Still Feel Unfair After You've Fixed Prediction

minimal overhead. Yet plenty of teams stop once client-side prediction and reconciliation feel solid, only to watch players still rage about “I clearly hit that” moments. Authority decides who owns the truth and prediction makes local movement buttery; neither rewinds the world’s colliders to the shooter’s view time. When the fire RPC arrives, the server validates against bodies that have already advanced by a full round-trip. The shot that looked perfect on the client simply misses.

In fat and IO-style games that gap shows up as more than classic hitscan frustration. Overlap eats fail because the server has already separated the blobs. Skill-shot contacts land a beat late and glance off. Multi-body pile-ups resolve on the wrong tick, so chain reactions and area bursts never match what the acting player saw. The verbs that define the genre—engulf, chain, burst, absorb—stop feeling fair the moment latency creeps in.

Lag compensation closes exactly that hole. As Fish-Net puts it, lag compensation (also known as collider rollback) is the act of placing colliders back in time on the server to provide accurate raycast hit detection regardless of client latency. The server briefly restores historical hitboxes, runs the validation against the world the shooter actually saw, then restores present-time state. Hits become trustworthy again without handing the client authority over damage.

The success bar is practical: fewer “I clearly hit them” disputes in playtests, a stable combat feel even under everyday 100–200 ms conditions, and no sudden explosion in per-tick traffic that would break WebGL budgets or dense lobbies. With the problem framed that way, the next decision is which Fish-Net path actually delivers those results for your projectiles and skills.

## Free Projectiles or Pro Rollback: Choose Before You Code Combat

That choice splits cleanly along two Fish-Net paths—one available in the free tier, the other locked behind Pro—and picking wrong early means rewriting hit detection later. Fish-Networking Pro is required for raycast lag compensation; over-time projectiles may use another approach and do not require Pro. The free path hides latency by spawning the projectile instantly for the owner and letting server and spectators catch up with accelerated motion. Pro collider rollback instead rewinds server hitboxes to the shooter’s view time so a single authoritative raycast or overlap resolves against the world the client actually saw.

Route the verbs that already have travel time down the free path: eating orbs, thrown blobs, skill-shots that arc or linger, and any ability whose visual flight already buys you the milliseconds you need. Reserve Pro rollback for hitscan weapons, melee traces, frame-critical grab or eat overlaps, and anything that must answer “did this ray connect on the exact tick the client fired?” Those checks need historical colliders; faking them with delayed projectiles just re-introduces the fairness complaints you already fixed in prediction.

A quick decision matrix

QuestionFree over-time projectilesPro collider rollbackDoes the attack have visible travel time?Yes — spawn local, accelerate othersNo — hitscan or instant overlapNeed historical raycasts / rewound colliders?NoYes — PreciseTick + RollbackManagerLicense tierFreePro requiredBandwidth sensitivityExcellent — no per-tick motionStill light, but rollback state is Pro-onlyTypical IO / fat usePrimary fire, orbs, blobs, DoTsUlt traces, melee snaps, precision eats

Most dense IO titles land on a hybrid without drama: free accelerated projectiles for the spammy primary fire that fills the screen, Pro rollback only for the handful of ultimates or precision traces that must feel frame-perfect. That split keeps the free tier doing the heavy lifting on bandwidth and WebGL budgets while the Pro features stay focused where fairness is non-negotiable. Once the matrix is filled for every combat verb in your design doc, you can write the projectile and hitscan code once instead of thrashing between approaches mid-production.

## Accelerated Projectiles: Instant for the Owner, Catch-Up Without Streaming Motion

With every combat verb sorted on that matrix, the free-tier over-time projectile pattern is where most of an IO game’s visual density actually lives. The firing client spawns and shows the projectile the instant the input lands—no round-trip wait—so the shot feels immediate under the player’s own hands. Server and spectators receive the same fire intent, then accelerate the projectile by the time that has already passed. That catch-up uses elapsed time so the simulated path converges with the owner’s view despite RTT; everyone ends up watching the same arc even when latency is non-trivial.

The bandwidth win is the real production unlock. You never network the projectile’s transform every tick. A lean fire RPC—or a pooled spawn carrying initial velocity and a timestamp—is enough; local simulation on every machine does the rest and the paths stay aligned. Fish-Net’s own guidance states it directly: projectiles that move over time hide lag by accelerating on the server and spectators while the firing client shows the projectile immediately, and another bonus is that you are not networking projectile movement each tick, which saves tremendously on bandwidth and performance. Their example shows the projectile still aligned on the server even when the client sits on a 220 ms ping—proof the technique holds under real latency, not only lab conditions.

For fat-game production habits this maps straight onto everyday pipelines. Networked object pools keep orb spam, blob showers, and skill-shot volleys from thrashing the allocator when dozens of projectiles are alive at once. Fire RPCs stay tiny—direction, speed, owner identity—so interest management and WebGL budgets remain comfortable. Spectators run the same accelerated catch-up, which keeps IO spectator cams honest instead of trailing ghost projectiles that only the shooter ever saw. The result is authoritative simulation that still feels snappy for the owner, stays light on the wire, and scales to the dense entity counts those games demand without ever streaming per-tick motion.

## Pro Collider Rollback: PreciseTick, Hitboxes, and Fair Instant Hits

When the ability is hitscan, melee, or any frame-critical overlap instead of a travel-time blob, the free projectile pattern is not enough. That is where Fish-Net Pro’s collider rollback takes over: the server rewinds registered hitbox colliders to the acting client’s view time, runs the raycast or overlap there, then restores present-state colliders so the rest of the simulation stays authoritative.

Register hitboxes and drive depth from PreciseTick

Setup is deliberate. Mark the colliders that represent damage volumes—capsule hitboxes, sphere volumes, thin melee arcs—and register them with the RollbackManager so they participate in historical snapshots. On fire or swing, the client includes its current **PreciseTick** in the ServerRpc. That value is the rollback depth: the server rewinds only as far as the shooter’s perceived moment, not an arbitrary fixed window, before casting the ray or performing the overlap test. Instant ability hits therefore validate against what the owner actually saw, which is the fairness gap prediction alone cannot close.

ServerRpcs that carry the tick, then rewind before cast

A typical fire or melee ServerRpc therefore ships a lean payload: aim direction or origin, optional ability id, and the PreciseTick. Inside the RPC the server calls into ColliderRollback with that tick, executes the historical raycast or overlap, applies damage or status only on confirmed hits, and exits the rollback so colliders snap back. No per-tick motion is networked; the authority path is a single intent plus the tick that unlocks the correct past geometry.

Keep TickSmoother and Additional Ticks aligned

Visual smoothing must not fight the validation window. Match TickSmoother settings and any Additional Ticks buffer to the same compensation depth you allow on rollback. If the smoother is holding more history than the server is willing to rewind—or less—you get visual-vs-validation drift: the client sees a clean hit that the server rejects, or the reverse. Aligning those values keeps the owner’s camera and the server’s historical cast looking at the same moment in time.

Serialization hygiene on tick and aim payloads

Because these RPCs fire constantly in dense IO combat, keep the types intentional. Fish-Net automatically serializes public fields and properties of types used in RPCs and SyncTypes; if a field should not cross the wire, mark it with **[ExcludeSerialization]**. Custom serializers exist for awkward types, but for tick-plus-aim payloads the default path is enough—as long as every public member is something you actually want on the network. Lean, explicit fields keep bandwidth predictable and prevent accidental bloat from helper properties that only matter locally.

With hitboxes registered, PreciseTick driving depth, smoother buffers matched, and RPC payloads kept deliberate, instant abilities finally share the same fairness bar the accelerated projectiles already delivered for travel-time shots.

## Future-Tick States, Observer LOD, and Bandwidth at Fat-Game Scale

That fairness bar still has to hold when the server alone owns the outcome—EMPs, slows, zone debuffs—states prediction cannot invent on the client. Apply them the instant the server decides and predicted movement will desync from the authority the moment the packet arrives. Instead, schedule the change a short future tick through an ObserversRpc so every client lands the effect at nearly the same local time.

Fish-Net’s documented pattern is deliberately small: convert a short delay into ticks and broadcast once. For an EMP, set application **50 ms** ahead with `uint futureTicks = base.TimeManager.TimeToTicks(0.05f, TickRounding.RoundUp);`, then fire the ObserversRpc carrying that tick. Clients that are already predicting continue smoothly; when the future tick arrives they all apply the slow or disable together, so rollback-validated hits and accelerated projectiles stay consistent with the new state instead of fighting it.

Nearby precision, distant silence

Close-range eats, melee traces, and projectile catch-up still need exact colliders. Far blobs, idle spectators, and off-screen feeders do not. Pair the RollbackManager’s hitbox precision with ObserverManager and LOD so entities outside combat radius stop generating traffic while the players actually fighting keep full authoritative resolution. Interest management becomes the quiet partner of lag compensation: you only pay for the collisions that can still be disputed.

Those same production levers keep the compensation path itself cheap at fat-game density. Delta compression, SyncVar optimisation, configurable tick rates, and networked object pooling are what let Fish-Net deliver bandwidth efficiency and server authority for **1,000+** concurrent players on cost-optimised AWS. Lean fire RPCs, pooled projectiles, and future-tick state broadcasts ride the identical stack—no per-tick motion streams, no surprise bandwidth spikes when the arena fills.

Ship checklist

Watch **BandwidthDisplay** under full orb storms and multi-body pile-ups—confirm compensation traffic stays flat when entity count spikes.Tune ObserverManager interest ranges to your eat and combat radii so distant bodies drop off before they cost anything.Run simulated latency and packet loss against future-tick states and rollback traces before you ship; fix any client that applies EMP or slow out of step with the server.

## URP WebGL Budgets When Arenas Stay Entity-Dense

Once interest ranges and loss tests keep compensation honest, the remaining ceiling is the frame itself—especially when hundreds of networked bodies, hitbox proxies, and accelerated orbs share a single browser view. Unity’s web guidance is unambiguous here: prefer URP because it customizes and scales cleanly across hardware, and turn on the SRP Batcher so CPU rendering work stays efficient instead of thrashing under entity load.

Rollback-era density turns that advice into a practical constraint. Pro hitboxes you register with RollbackManager, free pooled projectiles that spawn for the owner and catch up elsewhere, and the temporary collider proxies used during rewind all multiply Mesh Renderers in the same camera frustum. If those meshes break batches—unique materials, constant property writes, or one-off scales—draw-call cost climbs even when bandwidth is already lean. Keep projectile and hitbox visuals on shared materials, stable transforms, and the same pooling paths you already use for fire intents so the batcher can collapse them.

On editor and standalone targets you can push further with the GPU Resident Drawer in Unity 6 URP. It can cut rendering CPU cost by up to 50% on object-dense scenes; a test with over 35,000 foliage objects dropped draw calls and batches from roughly 43.5k to 128 and freed both CPU and GPU frame time. The feature is gated, though: Forward+ path, compute-capable platforms (not OpenGL ES), Mesh Renderer components, and SRP Batcher enabled, with static batching off for best results. Treat it as a desktop lever for stress scenes and tooling, not a blanket WebGL assumption.

Close the loop the same way you opened combat design. Prove hits first—PreciseTick rollback for traces, accelerated projectiles for travel-time verbs, future-tick states for server-only effects—then profile the WebGL build under peak orb storms and player counts. Watch frame time alongside BandwidthDisplay, keep materials batch-friendly, and only then decide whether Resident Drawer or further LOD cuts belong in the shipping path. Fair multiplayer that still runs in the browser is the product of that order, not the reverse.

## Conclusion

- Fairness gap after prediction — Server colliders still sit at the wrong time for the shooter, so hitscan, melee, and multi-body overlaps feel wrong until you add lag compensation.
- Choose the right tool first — Route travel-time orbs and skill-shots to free accelerated projectiles; reserve Fish-Net Pro collider rollback for hitscan, melee, and frame-critical traces.
- Accelerated projectiles stay lean — Owner sees the shot instantly, server and spectators catch up from passed time, and only a tiny fire intent is networked—no per-tick motion stream.
- Pro rollback needs PreciseTick — Register hitboxes, send the client’s view tick on the ServerRpc, rewind before the raycast or overlap, and keep TickSmoother depth aligned so validation matches what the player saw.
- Scale with observers and future ticks — Schedule server states ~50 ms ahead, LOD rollback to nearby fights, and lean on delta compression plus pooling so dense IO arenas stay under bandwidth and WebGL budgets.
- Profile fair hits before frames — Get compensation feeling right under 100–200 ms, then lock URP batching, pooled proxies, and Resident Drawer so entity-dense arenas still hit WebGL frame targets.

Open your combat prototype, pick free projectiles or Pro rollback for each ability, and run the BandwidthDisplay plus loss simulation before you ship the next arena.

## Frequently Asked Questions

### Does lag compensation require Fish-Networking Pro?

Fish-Networking Pro is required for raycast lag compensation (ColliderRollback). Over-time projectiles may use the free acceleration approach and do not require Pro.

### How do accelerated projectiles hide lag without networking every tick?

Projectiles that move over time spawn immediately for the firing client. On the server and for spectators they accelerate using the passed time so they stay aligned—even at 220ms ping—while never networking per-tick movement, which saves bandwidth and performance.

### What is PreciseTick and why send it with fire RPCs?

PreciseTick tells the server the exact client view time to rewind to. Sending it with fire or action RPCs lets RollbackManager place colliders correctly; pair it with TickSmoother and matching Additional Ticks so prediction and rollback stay in step.

### How should server-only states like EMP or slows be applied without desync?

Schedule application a short future tick (for example 50ms via TimeToTicks) through an ObserversRpc so every client applies the state roughly together and prediction does not fight a past change the owner never saw.

### Can this stack support high concurrent player counts?

Yes. FishNet’s bandwidth efficiency, server authority, delta compression, configurable tick rates, and networked object pooling have supported 1,000+ concurrent players on cost-optimised AWS for MMO-scale titles when combined with interest management.

### What URP settings help dense WebGL multiplayer scenes?

Unity recommends URP for web builds for efficient scaling; enable the SRP Batcher. In Unity 6 the GPU Resident Drawer can cut rendering CPU cost by up to 50% on object-dense scenes (Forward+, compute-capable platforms, Mesh Renderers) so draw calls stay manageable alongside Fish-Net traffic.

## Sources

- [https://fish-networking.gitbook.io/docs/guides/features/lag-compensation](https://fish-networking.gitbook.io/docs/guides/features/lag-compensation)
- [https://fish-networking.gitbook.io/docs/guides/features/lag-compensation/raycast](https://fish-networking.gitbook.io/docs/guides/features/lag-compensation/raycast)
- [https://fish-networking.gitbook.io/docs/guides/features/lag-compensation/projectiles](https://fish-networking.gitbook.io/docs/guides/features/lag-compensation/projectiles)
- [https://fish-networking.gitbook.io/docs/guides/features/data-serialization](https://fish-networking.gitbook.io/docs/guides/features/data-serialization)
- [https://fish-networking.gitbook.io/docs/guides/features/lag-compensation/states](https://fish-networking.gitbook.io/docs/guides/features/lag-compensation/states)
- [https://oceanviewgames.co.uk/technologies/fishnet](https://oceanviewgames.co.uk/technologies/fishnet)
- [https://unity.com/how-to/profile-optimize-web-build](https://unity.com/how-to/profile-optimize-web-build)
- [https://generalistprogrammer.com/tutorials/unity-mobile-game-optimization-complete-guide](https://generalistprogrammer.com/tutorials/unity-mobile-game-optimization-complete-guide)
- [https://theknightsofu.com/boost-performance-of-your-game-in-unity-6-with-gpu-resident-drawer/](https://theknightsofu.com/boost-performance-of-your-game-in-unity-6-with-gpu-resident-drawer/)
- [https://docs.unity3d.com/6000.0/Documentation/Manual/urp/gpu-resident-drawer.html](https://docs.unity3d.com/6000.0/Documentation/Manual/urp/gpu-resident-drawer.html)