almost every developer seems to be using this variable incorrectly. It is used in all of your favorite video games, and you'll find it in every game engine from Unity to Unreal to GameMaker to Godot. Which makes it even more frustrating that almost all developers know about it.

is I should multiply everything by delta time. If not, I'm committing a crime LOL. If only it were so easy, huh? And if you're one of those know-it-alls who thinks they know everything already, then grab a pen and a piece of paper. I will

test your knowledge. You're writing a game development test, my friend, and I will grade you at the end of the video. This is not a joke. Yeah, when our videos create the illusion of motion by showing you a bunch of images very quickly, and games work the exact

same way, but there's one important difference. In a video, all of the images have the exact same length. So for example, if you have a video with 25 frames per second, then one frame is shown exactly every one divided by 25 seconds. For games, unfortunately, it's a

mess. All of the frames are just shown whenever they finished rendering, which can be whenever. In a video, if you want to create the illusion of motion, we can just move the character by the same amount every frame, and it will look like a smooth motion. In a game, because all of

the frames are spaced apart differently, we cannot do that. Dear test participants, write me a line of code that makes a character move over the screen with a consistent speed. You have three seconds to lock in your final solution. Three, two, one. Here's my friend Jerry. He has a very

good computer so his game runs with 60 frames per second and this bet if she just loves toaster so she's playing this on a toaster and only has 5 frames per second oh what do I see here is this your final answer the update event is

called every frame this is the position of the snail and you want to go to the right so you multiply the right Vector times your movement speed how how far you want to move each frame so that up there is your solution let's run it and

see what happens Jerry is zooming away and Betty is Left Behind You monster what have you done so obviously that's because both snails move the same amount each frame but Jerry just has way more frames per second so obviously he's gonna move fast I'm pretty sure you're

not a criminal though because I'm pretty sure you remembered I should multiply everything by Delta time if not I am committing a crime let's do that then let's multiply in this magical variable that we don't quite understand yet and all of a sudden it works if we keep this

running forever they will always stay next to each other so if you're participating in the test and you got this correct then you get 10 points write down your point the question is why is this solution correct let's have a look at our film strips or game strips

and for this example we actually do have consistent time intervals between the frames for Jerry it's about 60 milliseconds between each frame and for Betty it's 200 and what you can kind of intuitively see here is that the more time passed since the last frame the

further we have to move the character and there's a direct correlation so Delta time is exactly that it is the time distance between frames if it's been twice as long since the last frame has been rendered we need to move twice as far how Delta time is measured is a

little different from game engine to game engine and in Unity it's measured in seconds so that means Jerry's Delta time is 0.016 and Betty's Delta time is 0.2 if we multiply that into our equation Betty moves way more than Jerry

every frame which is exactly what we need in a real game the frame rate will obviously vary sometimes you'll have 60 frames per second sometimes you'll have 5 frames per second so that is important to know Delta time is automatically recalculated every frame and it's

usually different every frame that way it's possible to go back and forth between being Betty and Jerry and it's still gonna work out just fine so little know-it-alls what do you think Delta time exactly is is it a the time elapsed between the last frame and the one

preceding it B the time elapsed between the frame currently being processed and the one preceding it C is answer B plus the time since the current frame started or is it D the time since this object last accessed the Delta time variable so dear test participants think

about it pause the video there are some points to be earned I will reveal the solution in three two one if you picked any of these two here then haha I trolled you real bad hey B is not the correct answer either but I'll give you

10 points, discuss. It's almost correct. Why is it only almost correct? Let's say we're here in the timeline and we're currently running our program code to calculate the next frame. In that case, we actually do have a problem because we do not have the next frame yet, nor do we

know when our calculation is going to be finished. So really the only thing we can do is use the data time from the last two frames and use that for our calculation. Is this the exact number we're looking for? Well, definitely not, but it's usually a reasonable assumption

that's at least roughly in the correct ballpark. And we're still going to use this interval as the delta time in the next frame, so it's going to even itself out in the long run. So if you picked a then I'm actually slightly impressed and

you get 20 points, congratulations! What that means is delta time always has a one-frame delay. Now there's a fun little experiment you can run in your game engine. You can create an artificial lag spike. I'm personally doing that by running a bunch of unnecessary

computations a bunch of times. So whenever I press X now, the game will have a huge lag spike. Here we have the two brothers, Jerry and Barry. Barry unfortunately suffers from leg spikes as we're using delta time. You can always catch up though. Let's watch one of

Barry's leg spikes frame by frame. As you can see, he's moving a little bit every frame, and all of a sudden the leg spike hits. So because of all of my unnecessary computations, the next frame takes way longer to be calculated. But what do you

think will happen in the next frame take your guess actually pause the video and take a guess now you can earn 10 points if you get it right the solution in three two one here it is I'm playing that same two frames over and over again

so you can see just those two frames and as you can see it's moving a little bit a tiny little bit so if you guessed anything like it moves a completely normal amount then you get 10 points and only in the next frame the expected teleport forward occurs why is it

important to know that Delta time always has a one frame delay well honestly it's only really useful for debugging and for avoiding your own confusion so now you know how it works for our next challenge we want to achieve the same result we want both snails to move at a consistent

speed but this time we want to code into fixed update instead of update don't worry these are still the very easy questions for those who don't know fixed update happens a fixed amount of times every second the question is what do we have to change here to make this code

work the video if you want to and I expect your answer in three two one we of course need to remove the Delta time oh you're really racking up the points then when we run our code and update then this is where our code is executed

or I guess to be a little more precise now all of that is taken up by the update events a huge portion of that is also taken up by rendering sometimes the irregularities caused by the system can be quite annoying to work around that's why most game engines offer a separate

system where you can execute code in Unity. Those are called fixed updates, and let's, for example, say we're executing some code right here. Why would we ever want to multiply anything by this interval right here? There's no freaking way that makes sense. If anything, then we

want to multiply by this interval right here, which is called fixedDeltaTime. So that means if you answered my last question with fixedDeltaTime in the solution, then that's obviously correct as well. Multiplying the same static number that never changes into everything you do is obviously a little

bit pointless. So you really don't have to. A fixed update is so much easier to use, and we don't have to worry about deltaTime. Why don't we just code our entire game in that? Well, actually, that is a valid coding style as long as our

code doesn't take too long to execute. But if it takes longer to execute than our fixedDeltaTime, then we are in trouble because then our game starts slowing down. Although, what about Emily with her high-end gaming PC? Maybe she wants to run the game at a higher frame

rate than the random number you decided on. So that's why usually using Update and deltaTime is the more resilient and scalable system. But fixed update still has its place. For example, in Unity, anything physics related, you usually want to put in the fixed update. That's

because the physics engine is running in the fixed update as well. And that way, your interactions with the physics engine are going to be more consistent and more reliable. To make things more confusing, you can also turn the main Update into a fixed update by adding weighting to your equation. So you can

essentially set a fixed frame rate and then just wait for the remainder of the time so in Unity if you limit the frame rate to 60 that's pretty much exactly how that looks like some game engines even work like this by default for example in GameMaker this is pretty

much the default way everybody writes code and once again the cool thing is as now all frames are spaced apart evenly you don't necessarily have to use delta time anymore the only problem is of course once again there is no such thing as a negative waiting time so if your update

and rendering take too long then you're in trouble take a deep breath take a sip of water and go on a toilet break if you need to because that was the easy part I downgraded Betty's toaster to two frames per second so we can more easily see when something is

wrong and this is what I would like you to create snails start with a speed of zero and then their speed linearly increases over time they do not have to loop around I'm just doing that for demonstration purposes the only thing that matters is that every time Betty

updates her position she needs to be exactly next to Jerry just as before we're using the same script for both snails so you cannot write separate scripts for both of them you have to write your code in update and you have to use delta time so I want them to start

slow and get faster and faster pause the video now and try to come up with a solution you have three two one okay let's see what you got so you have two variables that's nice yeah you have an acceleration variable and you have a speed variable very good so this

part is the exact same thing as last time and the only thing we added was this line here we add something to the speed now here we take the acceleration and we multiply it by Delta time so this is for movement this is for increasing the speed and both times we multiply in

Delta time okay I loaded a new solution let's try it out and oh oh Betty Betty hurry up let's check this out in slow motion where Betty updates to oh she's too short okay then I guess we have to move this before so first we add

something to our speed and then we use that speed to accelerate ourselves forward come on stay next to each other please please go go go and yay this time Betty is ahead what the hell this happens the other way around but when Betty updated her position they

were definitely not next to each other so if you got any of the solutions we just talked about then you only get 20 points because this is a good approximation but it's not entirely correct okay then so what happens if we apply half of the acceleration before

and the other half of the acceleration after we move the snails accelerating before the movement didn't work accelerating after the movement didn't work so let's try splitting it in two I guess will our random solution work the tension is immeasurable they need a

little more hype here come on come on more hype more hype what it is perfect there's one interesting question and that is why why does this work let's graph this out on the x-axis we have the time and on the y-axis we have the speed of the snail so

our snails start out with zero speed but they do get faster and faster over time luckily for every frame we know exactly how fast the snails are because the speed is just increasing linearly so now let's have a look at our first slightly

incorrect solution again the linear increase of speed is something we don't really have to worry about that's working correctly the more time passes the more we increase the speed very straightforward this is the part of the code that is responsible for calculating how far the snail moves so now let's

assume we're running this code right here in between those two frames what are we multiplying we're multiplying speed times Delta Time by multiplying those two numbers we calculate the surface area of this beautiful rectangle here so the surface area of this rectangle represents how much we're gonna move

between those two frames so can you start to see the problem here if our speed will look like this and was actually consistent then that would look a lot more correct wouldn't it because in that case multiplying speed times Delta time would create a rectangle that fills up the

surface area under the graph perfectly so we have to take into consideration that the speed is constantly changing and what that means is we're lacking a piece here or in other words we're not moving enough okay then I guess we have to move this before so first we add

something to our speed and then we use that speed to accelerate ourselves forwards well okay so in that case instead of using this speed you're telling me we should use this speed which results in this surface area which is too much we are moving too much now

we really just want the area under the graph so how do we get that well hey there's an entire field in math the thing you want to research are integrals or more precisely definite integrals which have a start and an end point luckily for this specific case there's

an easy hack we can apply we can chop off one corner and attach it back like so and we have a rectangle as you can see the speed we want to multiply by is exactly in the middle of the start speed and the end speed so in this case but

only because the speed is a linear function we dodge the bullet and we get away without doing any more complicated math and that is exactly why this is a correct solution this first line here gets us the middle point and then this last line here makes sure we add all of

the speeds that we need to add so if you got this solution or any solution that effectively achieves the same result then you get 50 points oh I feel like I'm probably clapping for nobody but still and by the way just a little addition or correction this calculation

is obviously not happening here it's happening here because of the one frame delay on Delta time so that means we're oftentimes not moving the exact amount that we should but with a one frame delay we're always moving the exact amount we should so that that's actually

completely fine and before you go scream at everybody who makes this quote-unquote mistake please don't because this is a very good approximation and 9 out of 10 times it's gonna get the job done just fine but you won't like this but I'm gonna upgrade

her to 30 frames per second for this experiment. The general rule of thumb is the higher the frame rate, the better these approximations work. So this is the exact same plot code that we already tried out earlier, but as you can see the snails do a really good job staying in

sync with each other. Let's keep this running for a little bit just to see what happens. And what you can see is it's not so flawed after all. They're starting to get slightly out of sync, but it's nothing too crazy. Why is that? The reason for

that is that with a higher frame rate, the speed is recalculated more often and therefore we have a higher accuracy. But, but did I hear a complaint that you want more points for your answer? Then don't get greedy. Remember that depending on the circumstances, these inaccuracies can

quickly add up and they can accumulate. So using approximations is fine. You should just be aware of the fact that you are using an approximation, which I feel like most developers aren't. And for everything where you do care about accuracy, like for example the player

movement from now on, you know that you can probably do a little better. How can you do better? Well, I even made a slide for all of those rule lovers out there. Whenever a variable changes over time, then this is the mathematically perfect solution, and this is the approximation.

The thing is you obviously only need this formula if the change speed itself is changing. If the change speed is consistent, then this is a mathematically perfect solution as well. If the change speed itself is changing, then you have to figure out the average change speed.

over the last Delta time second, so let's, for example, say Delta time is 0.5 seconds, then you have to figure out the average change in speed over that time period and multiply by that. This next mistake, however, is a really rough one and I've seen people make this mistake.

so that's why I have to include this in the video. All the experienced developers look away, this might hurt. So I made this little game called Flappy Snail, which is essentially the exact same thing we just talked about: we're accelerating in one

direction, and the only difference is that now I have a jump button. So in this case, for movement, we're using the approximation, which is fine, but I might have removed something very important from the jump code down here, and if you can tell me what's missing, then you'll

get some points. You have three, two, one, lock in your answer. And if this is your final answer, okay, don't lie to me, what's locked in is locked in, then you get minus 10 points because this is so wrong. Oh my God, don't ever do this, this is horrible. You want

to multiply by Delta time when something happens over time. When something happens immediately, like a jump, that is a point in time. When something happens at a point in time, you never want to multiply by a period of time, that just doesn't make any sense unless you want to jump

twice as high when the frame rate drops or something, but why would you ever want this? All right, I'm sorry for your loss if you fell for it, but if you were either confused or you are like, 'Seems all right to me,' then you get 10 points. Luckily,

There's an incredibly catchy rule, just say it with me: I should multiply everything by delta time, but only once and not accidentally twice. And only when we're not in fixed updates, and only when it's something that is really happening over a period of time. If not, I'm... if not, I'm committing a crime.

Oh yeah, and don't freaking mess up your freaking lerp functions. You OMG, just use your brain WTF! And that is exactly why rules stay... think there are too many exceptions, but what was that? Don't mess up your lerp functions. I think we should...

Look into that. If you don't know what a lerp function is, then this is probably not the best video to explain it. But I'll give it a brief shot. It allows you to interpolate between A and B with the value t. T has to be a value between 0

and 1, and the calculation happening underneath is fairly simple: It's just a times 1 minus t plus b times t. So, let's for example say you have two positions on the x-axis: minus seven and seven. So that means if you set t to 0, you'll end

up with -7. If you set it to 1, you'll end up with 7, and anything in between will give you something in between. Now using a lerp function, I would like you to create this: The snails that are fast, but they get slower and slower, and they never fully arrive at their

target destination. They're just getting closer every frame, but they will never arrive there. And I'll even give you a little tip: You can do this with a loop function that can interpolate from one position to another. The only thing you have to fill in is this last parameter.

of the lower function here this is the snail's current position this is the snail's target position and this is what you gotta by now you know how we roll we're looking for the mathematically perfect solution only so no pity points for approximations this time this is

your final test here's once again what to create and of course whenever Betty updates they need to be exactly on top of each other pause the video and you have three two one I'm actually gonna split this into two lines let's put in a blend variable here and

I'm sure the solution most of you got is just time dot Delta time multiplied by lerp speed honestly I don't even have to run this to prove to you that this can't possibly be correct because I told you the snails never reach their target

destination but what happens if we have the Giga like Spike of Doom and we have a two second lag spike there's nothing stopping this blend value from becoming really large even larger than one and what happens if T is one then we instantly jump to our target position

which is wrong alright so let's run the simulation and see how long it takes for those two snails to get out of sync and they're out of sync that's not too impressive so in these kind of scenarios we have to realize that we are on an

exponential function in this case on a reversed exponential function on the x-axis we have the time and on the y-axis we have the distance from the target so you can see the distance from the target is getting lower and lower but it's never reaching zero as we are

on an exponential function we have to use an exponential function mind blown all right I'm just gonna show you the correct solution here it is and it looks a little intimidating I admit that one minus we can remove that but then we have to switch those two around so let's do that

to simplify that a bit so we end up with 0.5 to the power of Delta time times LARP speed and that then is the number that we use to blend between our current position and our target position on an exponential curve what do we have to do

when you want to move to the right you have to change the exponent and you can see the exponent is just linearly correlating with time it's literally just counting up and that's why we can just put our time in the exponent and call it a day the 0.5 by the way are

completely arbitrary you can choose pretty much any number between 0 and 1. if you got that correct then damn I'm impressed and you get 50 points and now I can hear all of the formula lovers crying oh my God why didn't you use the

formula however you can do that here as well instead of looking at the distance you just have to look at the speed and as it turns out the speed is an exponential function as well it starts out very fast and then gets lower and slower but never reaches zero and now if

you've got a time interval defined by Delta time then we just once again have to calculate let the area under the graph which we can do by multiplying Delta time by the average speed within that interval the only problem is that the average speed is no longer just the

middle point between the start and the end point because this time we have a curved graph so if you want to get this correct using this method then you gotta look into integrals if you're still confused and you're like what the hell then remember that using the much

simpler approximation is usually fine although I got a brilliant bonus tip for you test your game one thing you can do in unity for testing is that application.targetFrameRate and I'll for example set that to 12 or something which is relatively low it's very much

like a slideshow uh this is a little painful but as you can see everything's working and everything's moving at the speed it's supposed to and stuff like that so just try it out just try your game at different speeds and see what happens most Unity users know about this

but you can actually pause the game by just setting Time.timeScale and if you set up your game correctly then nothing should move anymore this completely pauses your game with one line of code it's also a good line to test if you implement a deltaTime

correctly everywhere all in all don't stress out about it it's not as difficult as it seems about it you can't just multiply deltaTime into everything without even thinking about it and expecting it to work that's not how it works but it's

also not it's not rocket science here are your grades check out your points count your points and see what grade you got and are you I'm Jonas I usually make game development content this was a bit of a different video for me I actually make a bit of a different

video every once in a while I like mixing it up otherwise I get bored but in general I make videos about game development so check out my other videos and I'll see you in the next one take care bye don't freak out and mess up your lerp functions you OMG just use

Dear Game Developers, Stop Messing This Up!

Dear Game Developers, Stop Messing This Up!