If the game keeps its clock in a low-precision floating-point type (float), the longer it runs, the worse its time resolution (the smallest time difference it can tell apart) becomes, and movement and effects start to shake.
Why Time elapsed since launch is accumulated in a float or passed to shaders as is → Effect The longer the game runs, the larger the smallest difference a float can represent → On screen Only clients left running for days see characters, animations, and scrolling effects shake; a restart fixes it
Store elapsed time as a double (64-bit) or an integer, wrap the time passed to shaders back around at a fixed interval, run automated tests that last several days.
Ballpark numbers
A 32-bit float has just over 7 significant digits, so after a day of running (about 86,400 s) the time resolution is about 8 ms, roughly half a frame at 60 FPS (16.7 ms), and after a week about 60 ms, more than a whole frame.
On the graph
Slow climb · Shaking reports by how long the client has been running
Where to look
Collect how long the client has been running with each shaking report and compare before and after a restart. On the development side, a test that sets the game start time several days back and runs from there
Confirmed if
Shaking only on clients left running for days, gone after a restart, and worse the longer the client has been running
Ruled out if
Shaking right after launch: “Missing or too-short interpolation buffer” or “Timer resolution”
Check with
The player’s own environment
Learn more
This shows up especially in mobile MMOs where players leave auto-hunting on for days without closing the game. Unity’s Time.time is also a float, so Unity provides a separate double version, Time.timeAsDouble, and recommends it.
Sources
Time.timeAsDoubleUnity The double version of Time.time; more precise than float the longer the game runs, so it’s recommended in most cases