So I’ve been trying to get a replay system (similar to ye old Doom/Quake demos system rather than a timeline) going, and I’ve run into some problems that I don’t think I can fix on my own. As a side note, I did make the jump to the new Input System because I read the input recording/playback to be one of the features.
So I spent a couple of weeks wrapping my head around the recording/playback functions of the Input System and I’ve successfully gotten it to work. It’s just that there seems to be a lot of tiny discrepancies between the recording and the playback that add up and eventually cause a divergence.
As a disclaimer, I use Cinemachine for camera control and my player movement code uses the Character Controller through fixed update. Inputs are all handled through the new Input System. Here’s a video for comparison
On the left is the initial input recorded, on the right is the playback of the recorded input
xd8oy
Thinking it was due to some smoothing or acceleration shenanigans, I tried turning off all smoothing, acceleration, and even dampening on the camera and simply recorded looking around with keyboard inputs instead of sticks.
Initial input recorded on first iteration. Following iterations are playbacks of the first. I just try to turn 90 degrees and keep the crosshair close to between the streetlamps.
m1h89t
Will I not be able to use this system in a similar manner to Doom or Quake? Any tips on weeding out where the discrepancies occur (maybe an input timeline or graph) so I can figure out if its the physics wonking around?
Thanks in advance!
For reference, the Quake system is accurate enough that it perfectly preserves speedruns made up to 20 years ago.
oof, I just read what you quoted and I have to apologize. I had thought I was doing the character controller stuff in fixed update, but upon looking at it again, it was in update. my bad.
(On that note, I did try moving it to fixed update and it resulted in jerky movement)
I do have custom “ground” and “wall” detection in fixed update.
characterController.Move() is called in UpdateFinalDir()
On that note, though, I do still get the desync stuff when just rotating the camera around (like in the original post using Cinemachine without any acceleration, smoothing, etc and keyboard inputs) which I would like to figure out first.
I made the changes to my time settings like you said and tried to do the test again. Here is the result:
kclx1i
This is just the input recording and one playback of the recorded input.
Well, first off, the normal time scale has slowed down considerably (noticeable on the ambient traffic) and the errors in the playback are somehow worse.
The only controls I am touching are the horizontal look keys. No physics, damping, smoothing or acceleration is present. The camera is handled by Cinemachine.
On another note, I reviewed my movement code, and read up that character controller isn’t meant to be Moved in FixedUpdate and an attempt at moving most of my movement code to FixedUpdate (and updating all deltaTime calls to fixedDeltaTime) resulted in extreme visual jerkiness and wall clipping. The test above was done after reverting the changes.
I cannot give you a good advice how to find out what causes your problem. You have an entire product and you’re trying to measure all different moving pieces.
My advice is this: open a new project, put a simple shape in the scene, develop your input-recording system and write tests for it. Check if over time/with variable input, you get the same result. If not, adjust/report bug until you do.
Then you can move this whole stuff into your final product with the knowledge that your system is working, if you still see some discrepancies, then it is 99.9% somewhere else (so you can get the next piece… like character controller… which a notorious one, usually).
I appreciate the advice. I am not accounting for the character controller (for now) because I am only “looking around on the horizontal plane” which the character controller has nothing to do with as the camera is independent from the player gameobject.
I have already removed any sort of damping, acceleration and smoothing on the Cinemachine Virtual Camera component and using keyboard keys so it is being fed a single-axis value directly and not using analog inputs.
So the only things interacting with each other are the Input System, Cinemachine, and the script that reads the axis value on the input system and feeds it to the CM VCam.
I had hoped that these measures would be enough to get a solid and consistent recording+playback but that doesn’t seem to be the case. If the recording/playback system can only work reliably without Cinemachine then I’ll be fine with dropping the feature for now because Cinemachine is more important to overall game experience.
In any case, my overall experience with the Input System has been quite positive, though I definitely would like to see more attention brought to this feature. The only source with examples I’ve seen on the subject is on the Unity docs Input Events page, under Capturing Events
