Capping delta time as safety measure

So lately while debugging I am thinking that using delta time for motions without any safety measure can lead to the game breaking easily as a phone slow down could teleport the player in unplanned areas.
I was thinking of putting a limit on the delta time value, is there any draw back I am not thinking of?
Like some gained advantage or somebody may leverage on it to cheat in any way?

Do you cap it in your game?

 

Your are meant to put critical logic in fixed update and only use the frame dependant update for input and display.

 

I wouldn't recommend capping it manually, just set an appropriate maximum delta time and let Unity handle that problem.

If by 'critical logic' you mean physics, then that is correct. From the FixedUpdate API reference : "FixedUpdate should be used instead of Update when dealing with Rigidbody".

 

Anything that will softlock the game if the time deltas gets too high or low but physics is the most common.

 

I never thought about using fixedupdate for character movement, it does make sense.
I always relied on that for physics and if I remember correctly all example were using the update method.
Feel stupid for never thinking about that, guess I am going to solve lot of camera jitter now too....

 

Depending on the actual framerate people are getting and the rate at which fixed update is run, I think they might experience more (subjective) jitter when you put things like camera movement in fixed update. I think you were on the right track with your first idea of capping the delta to make sure it doesn't go crazy if it gets too big. My vote is: fixed update for things that need stable behaviour accross different framerates, like e.g. projectiles, and update for almost everything else (probably forgetting some sensible exceptions right now), with sensible upper limits in place where needed (that's for you to decide). Think about what's the worst that could happen when you feed something waaay too high delta, and if it's bad, then better cap it. Or just cap them all by using a globally defined constant and experiment how it affects the game when you tweak that and introduce lag spikes yourself to provoke the edgecase behaviour.
My prediction would be the game feels like it slows down when that happens over many frames, and feels like a micro stutter when it's just one frame.

 

As Martin_H says, you do not want to put camera stuff in FixedUpdate (LateUpdate, sure, but not FixedUpdate).

1. Update() and LateUpdate() are called once per frame drawn to the screen.
2. FixedUpdate() is for calculations performed at fixed intervals of time - not necessarily per frame.

You can get zero, or more, FixedUpdate calls per frame, but all of their collective updates will not be shown on screen until the subsequent Update and LateUpdate have been called. Hence the potential for increased camera jitter if camera updates are done in FixedUpdate.

 

Was talking about the character motion updating in FixedUpdate but on a second thought it's not changing anything since the move delta is still dependent of frame rate, so it fixed possible teleporting and missed events but not jerkiness.
Anyway I noticed FixedUpdate is called way before of LateUpdate and I have many interconnected scripts which I don't have the time to test for possible issues caused by some now firing earlier, so I went and reused some code I had from a prototype simple cloth solver I made and never used(too many unpredictable behaviors), to simulate the fixedupdate inside Lateupdate. It's few lines of code, won't make much difference.
I barely use any rigidbody so I don't have a lot of use from Unity builtin physic slowdown.