Dear Game Developers, Stop Messing This Up!

also man your very odd

FUCKING TLDR?!

a C is not that bad right?

I love your videos Jonas. I'm making a pokemon style gatcha game where you collect homeless people and stream their fights.
It's a love letter to everything that's wrong with humanity. Your videos inspire me to bring my ideas to life <3 thank you for sharing your brain with us.

no

I saw this video from
blargis who made a speedrunning game.

And this video was so awesome I wanted to subscribe…

So I did, of course.

I just found this channel and I was annoyed at first, but that's because my power went put. As I sat here and watched, I slowly started to sink in 😂. You are a good teacher.

The formula shown in the video can also be written as follows:
position += ((0.5 * acceleration * deltaTime) + velocity) * deltaTime
velocity += acceleration * deltaTime

That notation originates from integrating the equation of motion along time (x = position, v = speed, _0 = previous value, a = acceleration, t = time)
∫ 1 * dv = ∫ a * dt
--> v = a * t + v0 (acceleration assumed to be constant during deltaTime)
∫ 1 * dx = ∫ (a * t + v0) * dt
--> x = 1/2 * a * t² + v0 * t + x0 (same as shown above)

For physics I would generally recommend to have deltaTime dependent on the minimal allowed movement distance. Calculating these step sizes can be rather complicated but avoids wall glitches at high velocities.

transform.position += Vector3.Right*(PreviousSpeed*deltaTime+0.5f*acceleration*deltaTime*deltaTime)

C grade, glad i'm not the worst 😊

although I know delta time (change/difference in time between one frame and another) this video is useful

Hi. Do you know why this solution isn't accurate on turbowarp? (scratch alternative).
I'm programming a track and field game but theres a small margin of error between running test times.
I used delatime x speed each frame, but when the fps is high, the movement is slower, and vice versa

How do sport games, that need to be fair, usually deal with that? Is it turbowarp fault (running at average at 35fps when i set framerate to 60...)? is it because of my pc ? I tried to make my game in another engine but it's so hard and i'm more familiar to turbowarp, wish it was faster.

so what should i use?

I learned that I should multiply everything by deltaTime. If not, I am committing a crime.

deltaTime is not only useful for animations, but in physics too, since pretty much every practical function in physics has a "per second" attached to it.

I didn't work on a game, but I worked on a flight simulation tool and we ran into an issue where our deltaTime wasn't appropriate for a certain part of the simulation, which caused the plane to be extra bouncy.

what about fixedDeltaTime and calculate position in fixedUpdate, then move in update but with compensation for fps drop?

This is a great video Ideea this should be a entire series.Cheers!!

deltatime sucks
i spent one and a half hour for one single line of code

Thanks a lot, i have fixed my lerp functions finally!

I missed the first question, but got the second question right how the heck does that work?

its been a year since you dropped this, but ive come back multiple times specifically for the final chapter. i always forget it and then end up needing it. maybe i should write it down lol.

Doing this kind of destroys your game's determinism...
Maybe you don't care about that, but it can be important sometimes, like if a player can cross a certain gap, make through a certain obstacle, etc...

This is a bit of an old video but the lerp section confused me a little bit because I got a similar answer, but different, and I couldn't figure out why it would be different, or what's even going on in the video's version, so I did some testing. Made a scene in godot specifically to test this, setting target framerate and moving an object with lerp in different ways.

The formula for mine and the video can be broken down into: x^(delta * y).
Where for me x = 1 - speed and y = target framerate. End effect is "move "speed'% of the way, per frame at 60 fps, and adjust to other framerates
For Jonas here, x = 0.5 (not sure why) and y = speed. End effect is "move halfway every 2 seconds". Which, while a bit strange, does work just fine.

Both of these methods differ in speed obviously, but they're both consistent with very different framerates
The x variable determines inverse speed (closer to 1 is slower, 0 is instant), and y determines across how large of a timeframe this step x happens. So effectively they're both speed

I've also seen someone say to use "Math.Exp(-lerpSpeed * delta)", which effectively is the same formula, but with x = 1/e and y = speed. As an example with speed at 0.5 you'll end up with moving about 63% of the way in 2 seconds, regardless of framerate

I think most intuitive way to think of it would be to forget the y value entirely and just focus on x
x^delta, where x is the inverse of how much does the object need to move per second. Other than that, regardless of the values you choose and if you multiply either side by anything, as long as they're constants you're just changing the speed, but it'll stay consistent across different framerates

Im going to use that 0.5 * deltaSeconds trick that is good.

The fixed update one kinda depends on the details of the platform, doesn't it?

The Flappy Snail one is kind of an issue, though, because how often the player can jump matters. At 2fps, you can only jump once or twice a second (depending on how much your underlying platform does for you, you might be unable to distinguish it being pushed, released, and pushed again), which creates a ton of problems. You need a better solution for player input if you want to handle extreme slowdown.

Also as a wrinkle, in a rhythm game you want to ignore delta time entirely and do everything based on where in the song you currently are, because staying locked to the audio is the single most important thing.

Math!

you know, you are right, it being mathematically perfect is *better*, but it's generally not a requirement for it to be fun which is generally what matters the most.

I only just started GameDev and I already know that for Rigidbodies you don't tie it to framerates or delta time. Except when checking keypresses that apply a forces to the rigidbody

You should slow down your speech framerate, it's unbearable

So what I learned is do something. Test it, if it doesn't work then multiply be delta time. If that doesn't work go google the answer.

Wait, do I need unity for this? What if my game is just written in C and my deltaTime/FrameDelay is just a function? I just multiply everything but single actions by DeltaTime, and I never read or heard about any of this nonsense.

OK, i did messed up with lerp function

haha there is actually an even better solution to this. Take the global time of the world subtract the time your application started, set an animation starting point and now you can very accurately calculate (run over) the delta time of your application

you're great Jonas, keep up the good vibes brother

I get right answer only in first question....well I can make open world rpg extration shooter with horror elements

great video . fun and informative

Actually, FixedUpdates aren't guaranteed to be always the same delta time, so you should still use delta time there, even if it seems redundant.

The very basic principle is you're using your computer's internal clock to anchor your game to realise life time.

"9/10 times it gets the job done"

guess im the 10th time.

"The time elapsed between the last frame and the one preceding it" , well, chatgpt says its the wrong definition and says: Delta time is the time elapsed between the current frame and the previous frame. I'm confused, if its the current frame thats being processed and the previous frame, then that's different from the previous frame - (the previous frame - 1)
[ 1 2 3 4]
Say we're currently running the start of frame 4, so is delta time the time between the start of 3 and the start of 4? Or the start of 2 and the start of 3?

I love the German accent (I am german too)

you know what, Im gonna do all on the server

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