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!

Jonas Tyroller

많은 개발자가 게임 개발에서 델타 시간 변수를 잘못 사용합니다.

연사는 시청자에게 캐릭터의 이동 속도를 일정하게 유지하는 코딩 문제를 해결하도록 도전합니다.

비디오와 게임 프레임 렌더링의 차이점을 설명합니다.

게임은 동영상과 달리 프레임 시간이 일정하지 않습니다.

캐릭터의 움직임을 일관되게 유지하려면 다양한 프레임 속도를 고려해야 합니다.

일관된 캐릭터 이동 속도에 초점을 맞춘 코딩 과제가 제시됩니다.

프레임 속도가 다른 두 캐릭터, 제리와 베티를 사용하여 문제를 설명합니다.

델타 타임이 없는 초기 솔루션은 이동 속도가 일정하지 않습니다.

델타 타임을 통합하면 일관성 없는 움직임 문제를 해결할 수 있습니다.

델타 시간을 사용한 올바른 해결 방법을 설명합니다.

델타 타임은 프레임 사이에 경과한 시간입니다.

델타 시간과 캐릭터 움직임의 상관관계가 표시됩니다.

델타 시간 측정은 게임 엔진마다 다릅니다.

Unity의 델타 시간은 초 단위로 측정됩니다.

델타 시간은 매 프레임마다 다시 계산되며 변동될 수 있습니다.

객관식 퀴즈로 델타 타임에 대한 이해를 테스트합니다.

한 가지 답이 거의 정답에 가깝지만 전부는 아닌 이유에 대해 토론합니다.

델타 타임의 한 프레임 지연에 대한 설명입니다.

한 프레임 지연이 계산에 미치는 영향에 대해 설명합니다.

지연 스파이크 실험과 그 시사점

델타 타임의 동작을 보여주기 위해 인위적인 지연 스파이크가 도입되었습니다.

지연 스파이크가 캐릭터 움직임에 미치는 영향을 분석합니다.

랙 스파이크가 다음 프레임에 미치는 영향에 대한 퀴즈가 출제됩니다.

지연 스파이크의 효과에 대한 해결책과 설명이 제공됩니다.

델타 타임의 한 프레임 지연에 대한 이해의 중요성이 강조됩니다.

문제는 업데이트가 아닌 고정 업데이트를 사용하여 일관된 속도를 달성하는 것입니다.

해결책은 고정 업데이트 코드에서 델타 시간을 제거하는 것입니다.

고정 업데이트의 작동 방식과 델타 타임이 필요하지 않은 이유에 대한 설명입니다.

사용 사례를 포함하여 업데이트와 고정 업데이트의 비교.

고정 델타 시간에 대한 설명과 고정 업데이트에서의 사용법에 대해 설명합니다.

고정 업데이트 사용의 장단점에 대해 논의합니다.

선형적으로 증가하는 속도 도전

선형적으로 속도가 증가하는 달팽이를 만드는 새로운 과제가 제시됩니다.

챌린지에 대한 구체적인 요구 사항은 자세히 설명되어 있습니다.

코드는 업데이트 함수에서 작성해야 하며 델타 시간을 사용해야 합니다.

솔루션에 대한 초기 시도가 제시되고 분석됩니다.

움직임 전후에 가속을 적용하는 것의 중요성에 대해 설명합니다.

솔루션에 대한 추가 시도가 표시되고 분석됩니다.

올바른 해결책은 움직임 전후에 가속도를 분할하는 것입니다.

이 솔루션은 개념을 설명하기 위해 그래픽으로 표현되었습니다.

속도, 시간, 움직임의 관계에 대해 설명합니다.

초기 잘못된 솔루션의 문제점을 설명합니다.

곡선 아래 면적을 구하기 위해 적분 개념을 도입했습니다.

올바른 해결책은 간단한 방법을 사용하여 설명합니다.

더 높은 프레임 속도가 근사치의 정확도에 미치는 영향에 대해 설명합니다.

프레임 속도가 더 높은 실험이 표시됩니다.

더 높은 프레임 속도에서도 약간의 부정확성이 발생하는 이유에 대해 설명합니다.

근사치 사용에 대한 인식의 중요성이 강조됩니다.

플레이어의 움직임과 같은 특정 상황에서는 정밀한 정확도의 필요성이 강조됩니다.

플래피 달팽이 게임과 점프 메커니즘

또 다른 일반적인 실수를 설명하기 위해 새로운 게임인 Flappy Snail을 소개합니다.

점프 코드에서 누락된 요소에 대한 퀴즈가 제시됩니다.

잘못된 해결책과 그 결과를 설명합니다.

점프와 같은 순간적인 이벤트를 처리하는 올바른 접근 방식에 대해 설명합니다.

델타 타임을 사용하는 유용한 규칙이 요약되어 있습니다.

Lerp 함수와 보간에서의 사용에 대해 설명합니다.

기하급수적으로 속도가 감소하는 달팽이를 만들어야 하는 과제가 주어집니다.

챌린지 해결을 위한 힌트와 안내가 제공됩니다.

솔루션에 대한 초기 시도가 표시되고 분석됩니다.

지수 함수를 사용한 정답이 공개됩니다.

Dear Game Developers, Stop Messing This Up!

Dear Game Developers, Stop Messing This Up!

스크립트