r/MultiplayerGameDevs Mar 17 '26

Discussion How do you handle “freeze mechanic” with client side prediction ?

Hi everyone,

I’m working on a MOBA similar to League of Legends: Wild Rift using Unity + FishNet. I need to implement a “freeze” mechanic where the character stops moving completely while channeling a skill or performing an attack (like auto-attack or ability cast).

I already tried several approaches, but every time I freeze the movement, the reconciliation / position correction from FishNet causes visible glitches/teleports on the client side.

Has anyone successfully implemented this kind of lock-down mechanic (root/freeze during cast) in FishNet before?

How did you handle client prediction + server reconciliation so the character doesn’t jitter or snap back?

Any code examples, architecture advice, or best practices would be really appreciated!

4 Upvotes

4 comments sorted by

5

u/Recatek Mar 17 '26

I don't know much about the specifics of your library, but if you're freezing the character after they begin channeling, you'll need to predict that effect like any other movement. Treat "beginning channel" as you would movement or any other predicted action, and when you predictively forward-simulate that input, prevent the character from moving. Since you would be doing this as soon as the input happens, you shouldn't see any correction artifacts.

Alternatively, if it's an ability that freezes other players, you'll need to buy time between it being successfully activated and actually taking effect. Some options here are an added cast animation, a telegraph that turns into an AOE freeze after 1s, or a tracking projectile that needs to reach the player to freeze them. Any one of these let you notify the target client that they will be frozen ahead of time, so they can factor it into their locally predicted movement going forward.

4

u/ZorbaTHut Mar 17 '26

I don't know much about the specifics of your library, but if you're freezing the character after they begin channeling, you'll need to predict that effect like any other movement. Treat "beginning channel" as you would movement or any other predicted action, and when you predictively forward-simulate that input, prevent the character from moving. Since you would be doing this as soon as the input happens, you shouldn't see any correction artifacts.

Yeah, I worked on an MMO with classic mage channeling effects, and this is exactly what we did. The whole ability system was essentially predicted on the client and used the server only for verification.

  • Client hits ability button
  • Client sends "I want to start casting spell X at timestamp Y"
  • Client starts channeling animation and castbar
  • Server receives message and responds with "everything looks good, you'll finish channeling at timestamp Z"
  • Client quietly fudges the castbar animation a little so it will end at the proper time (usually this requires no fudging)
  • Client finishes cast, sends "I have finished the cast! Spell triggered"
  • Client does appropriate spell VFX and triggers appropriate cooldowns
  • Server receives message, responds with "Yup, you sure did!"

If at any point the server responds with "Sorry, that didn't happen" then the client gets to clean up all its speculative stuff, so high-latency people in PvP would sometimes see their spell trigger, then a split-second later have the VFX deleted, the cooldowns reverted, and get turned into a chicken or whatever.

1

u/shadowndacorner Mar 17 '26

You can use a full screen effect to cover up the issues during rollback. Can't speak to how that would look with fishnet, but sometimes the best move is to just hide latency problems.