Here’s where I think most people conflate two different problems: animation-driven movement vs. physics-driven movement. Root motion bakes the character’s displacement directly into the animation frames, which looks clean but means your client is trusting the animation timeline for positional authority. In a server-authoritative shooter, that’s a liability because the server recomputes your transform from velocity and input commands anyway, so you’re paying the root-motion cost (extra CPU skinning, per-frame IK solver passes) without gaining sync accuracy. For competitive play I’d keep movement purely kinematic on the server and use root motion only for cosmetic transitions like sliding or vaulting where the exact displacement is small and the server can snap-correct it within one tick. The real latency winner is decoupling the animation state machine’s blend tree evaluation from your input queue—if your transition durations are locked to frame rate instead of delta time, you’ll see stutter during rapid fire states that adds real feel degradation even if the netcode is fine.
On the hardware side, the benchmark that matters most is 1% lows during sustained combat, not peak FPS. State machine transitions spike CPU single-thread usage because the animation controller runs on the main thread while the physics/
"[Competitive Setup] • [i9-14900K / RX 7800 XT / ASUS PG248QP 540Hz]"
