Search Unity

  1. Improved Prefab workflow (includes Nested Prefabs!), 2D isometric Tilemap and more! Get the 2018.3 Beta now.
    Dismiss Notice
  2. The Unity Pro & Visual Studio Professional Bundle gives you the tools you need to develop faster & collaborate more efficiently. Learn more.
    Dismiss Notice
  3. Let us know a bit about your interests, and if you'd like to become more directly involved. Take our survey!
    Dismiss Notice
  4. Improve your Unity skills with a certified instructor in a private, interactive classroom. Watch the overview now.
    Dismiss Notice
  5. Want to see the most recent patch releases? Take a peek at the patch release page.
    Dismiss Notice

Capping delta time as safety measure

Discussion in 'Game Design' started by 00christian00, May 15, 2018.

  1. 00christian00

    00christian00

    Joined:
    Jul 22, 2012
    Posts:
    759
    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?
     
  2. marcV2g

    marcV2g

    Joined:
    Jan 11, 2016
    Posts:
    115
    Your are meant to put critical logic in fixed update and only use the frame dependant update for input and display.
     
  3. Doug_B

    Doug_B

    Joined:
    Jun 4, 2017
    Posts:
    1,395
    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".
     
  4. marcV2g

    marcV2g

    Joined:
    Jan 11, 2016
    Posts:
    115
    Anything that will softlock the game if the time deltas gets too high or low but physics is the most common.
     
  5. 00christian00

    00christian00

    Joined:
    Jul 22, 2012
    Posts:
    759
    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....
     
  6. Martin_H

    Martin_H

    Joined:
    Jul 11, 2015
    Posts:
    3,680
    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.
     
    theANMATOR2b and Doug_B like this.
  7. Doug_B

    Doug_B

    Joined:
    Jun 4, 2017
    Posts:
    1,395
    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.
     
    theANMATOR2b likes this.
  8. 00christian00

    00christian00

    Joined:
    Jul 22, 2012
    Posts:
    759
    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.