Dear Game Developers, Stop Messing This Up!

DeltaTime. This video is all about that mysterious variable that oh so many game developers seem to struggle with. How to use DeltaTime correclty? I got the answers and hope this video will help to deepen your understanding about how to make frame rate independent video games.

0:00 - Intro
0:34 - Creating The Illusion of Motion
1:11 - Simple Linear Movement
3:25 - But What is DeltaTime Exactly?
5:42 - Fixed Updates
8:22 - Movement While Changing Speed
10:41 - Integrals And Why You Might Need Them
13:17 - Approximations And Why They Are Fine
14:30 - Movement Formulas
15:03 - The Unforgivable Mistake
16:54 - How to Lerp Correctly
20:43 - Test Your Game!
21:31 - Get Your Grade Here!

My Games:

For the game developers among you:

Hope you enjoy. :)
#gamedev #indiedev

[JonasTyroller]

Small corrections (I learn some things from you as well, how nice, haha):
- Using Time.deltaTime in Fixed Update is actually fine in Unity cause it automatically returns Time.fixedDeltaTime depending on where it is called from.
- Using Delta Time in fixed update still makes sense for various reasons (it keeps speed to units/second and helps when inaccuracies in the fixed update intervals occur)
That means 10 free points to you if your read this, haha. Will keep updating this in case I got anything else wrong. :P

[vast-games]

I just love how He's one of the only devs that instead of showing "what to do" shows "why does it do" which is something so important.

[tommysedin]

6:50 I would say that it's not pointless to multiply by fixedDeltaTime; Makes it easier to code consistent units (say if you're trying to follow SI units strictly, or if you have calculations in both Update and FixedUpdate that should follow the same unit). Also, if you ever end up changing the frame rate of the FixedUpdate, you'll have to change every single calculation.

[grbrigsted]

If you're not using fixed updates, you might end up clipping through walls from lag spikes, unless you're using rays to assert if the player has moved through a wall between the previous frame and the current.

[leffeup]

As someone who litteraly had a math test earlier today on the subject of integrals, this was a great ego boost

[JeanPhilippeBoucher]

Jokes on you, I multiplied my grade by delta time and now I'm above the maximum!

[Ochros]

21:50 From your testing scheme, it's actually possible to get everything wrong and also the -10 points, leaving you with a grading that is undefined according to your evaluation :P (if I didn't miss anything)

[XoIoRouge]

I love the presentation of this video, with an actual test. The whole "YOU WILL BE GRADED JOKE" actually motivated me to do well on this test that no one will see. I've seen many youtubers educate with information, by just telling us the right answer, showing it in examples, with great animations to help visualize. That process works, but I think many content creators forgot how effective it is to challenge our knowledge. At 3:41, despite me using deltaTime in many places, I realize that... I'm not EXACTLY sure which of these four are true.

Thank you for challenging my knowledge, and because of that, you've stuck out as a memorable youtube educator. I've subscribed and I look forward to learning more from you.

[sammtavv]

I didn't know i always wanted a video from Jonas directly to the developers. Gotta love these videos!

[klikkolee]

I'm going to contest question 2 based on the wording.

The presentation of a frame can be conceptualized as happening at specific instant of time, but the game logic of a frame takes meaningful time to happen. If I just see phrases like "the current frame" and "the last frame" in reference to timing and without further indication, I will interpret that as referring to those spans of time. In the context of timing, frames have a start and an end, and that end is before the frame's presentation. Since each operation can be conceptualized as contributing to a specific frame, the end of a frame is the same as the start of the next.

You don't know when the current frame will finish or when it will present, but you do know when it started. A game engine is going to use the most recent frame-time estimate it can, and that would be the time between the start of the current frame and the start of the previous frame. This is more consistent with the wording of option B than the wording of option A, and it is consistent with the wording in the Unity script reference for Time.deltaTime: "The interval in seconds from the last frame to the current one"

[MrWolfheat]

I think that in the latest unity versions using deltaTime in fixedUpdate will automatically use the fixedDeltaTime internally so you do not need to change this. Unity implicitly understand which one to use by the context it is used in.

[Randy]

I don't code, but I am a physics nerd and saw delta time and it peaked my interest. Was not disappointed to see the explanations of calculating changes in distance as a function of time when not accelerating, when accelerating, and with a changing acceleration value. With the questions that were math based and not definition based other then syntax i am happy to say I got the idea right lol.

[Random-kjgo]

please we need more of thisss this is the exact technical info no one talks about and it even has a visualisation very good video 10/10

[jaredschneider]

Someone needs to send this to Gearbox given the new Risk of Rain 2 update apparently commits several of these crimes.

[metalstarver]

Actually things get 100x more complicated if you have non-constant forces, you need to lookup numerical integration (initial value problem). Your recommended way is called Leapfrog integration. It can work really far from accurate if you have spring forces (with springs you need tiny timestep or other more sophisticated methods which usually are not suitable for real-time).

[Bobsteperous]

Now THIS is the kind of tutorial i need, ive had enough of people just telling me what to put in to get my desired output, and i need that perfect level between talked to like a baby, and expecting im Einstein. You hit that nail right on the head.

[Ombarus]

Very impressed, you've covered many of the pitfalls. Just two remark: Fixed Update is useful to avoid costly exponent which are very common in Physics calculation because if you have a constant delta time then the linear approximation is good enough (so the "bad" lerp in a FixedUpdate would work just fine). The big drawback with FixedUpdate is that you'll usually notice "jerking" as one frame you'll update 3 times, but then the next frame only 1, then the next 2. Usually to fix this you need to extrapolate the difference between the current frame's deltatime and the FixedDeltaTime.

[BicycleName]

For anyone interested in learning more about numerical integration, there's a whole range of other schemes you can apply which have different stability properties based on the deltaTime and the equations of motion of the players. Here at 8:22, if I can recall properly, he first uses Euler Forward then Euler Backward and after that, Crank-Nicolson. If you had a more complicated movement, you could as well switch to a spicier scheme (like Runge-Kutta) but it's propably over-engineering the task you're trying to achieve.

[APaleDot]

For those confused about the lerp section, I have a really easy way to think about it intuitively:
If your "lerpSpeed" is 1, then the base of the exponent (the number on the bottom) is the portion of the distance you want to cover in one second. So in the video this number is 0.5 which means the character covers 1/2 the distance to the goal every second. The reason this works is because when you do this multiple times in a row, the distance decreases exponentially. So, if you imagine your frame rate is 4 frames per second, then in the first frame the character covers 0.5 ^ 0.25 of the distance (because deltaTime is 0.25), and the next frame the distance will be less but they will still cover another 0.5 ^ 0.25 of _that_ distance. So the total distance covered will be (0.5 ^ 0.25)(0.5 ^ 0.25), which if you remember your exponent rules is equal to 0.5 ^ 0.5. In other words when you exponentiate like this, the deltaTime in the exponent adds linearly every time you lerp. In this example, if you lerp every frame for one second (that is 4 frames) then the exponent adds up to 0.5 ^ 1. In other words, you cover half the distance in one second, regardless of your deltaTime, as I stated in the beginning.

EDIT: as explained in the replies, the base of the exponent actually represents the portion _remaining_ after 1 second, not the portion covered after 1 second, because you start at t = 0 which would give a blend value of 1, so we use 1 - 0.5^t instead (or Jonas puts the current position in the second parameter of lerp, which is equivalent)

[Pontypants]

I am one of those. I know everything. No need for pen and paper. I already know. Even what I don't know I know... And then some..