I’ve never worried about deltatime, because I just always learned to scrap Ideas, as frame-rate approaches hardware limits…
But also, isn’t slow down nicer for a player, than sudden gaps? - at least in single player games.
… Will anyone try to convince me that a series of frozen still pictures are better than slow but fluid motion in an action platformer / metroidvania?
What you are suggesting is Fixed time step
with no dropped frames.
You have no recovery plan from a bottleneck.
I guess it depends on how you implement the fixed time step. If you just trigger an update after some interval every time, which could resullt in multiple updates per frame, you don’t really drop a frame. It happens eventually.
Though I guess you’re still using delta time somewhere! 
They’re the same thing? As nkast alluded to, you’re going to have dropped frames or a variable time between frames somewhere. I don’t think MonoGame enforces a framerate (ie, guaranteed tick rate) by itself, but I’m actually not sure.
So the question is, if your computer decides to deploy an update and pin your CPU, how do you want your game to respond?
By ignoring delta time the game cannot adapt to slower or faster machines.
It will run as slow as the cpu can keep up,
and as fast as the monitor vsync.
In early days of home computers, the games were fine tuned to each model.
The new and faster PCs had to add a ‘Turbo Button’ on the case, so that old games will still play at the designated speed.
After this first short period it is expected that a game can adapt to different systems.
I believe either you don’t know what a delta time is, or you are failing to explain what you mean.
If you move your player, say 1 unit every frame, and on your pc game runs in 60 FPS, the player will move 60 units in each frame
However, if you try to run it on your friend’s laptop (for example) and get only 10 FPS, the player will not only “lag” due to low frame rate, but also the game will play in super slow-mo.
The only thing that delta time does is to make bigger “steps” when you have less FPS, so no matter how smooth your game runs, you move with the same speed. If you have 10 FPS, you will move a lot more every frame, which combined with the game “lagging” will seem like “sudden gaps”, but I don’t think it is a reason to stop using delta time at all, because:
If I were forced to play a game with 10 FPS, I’d still rather have some sudden gaps than play in 10x slow-mo (that is 10 seconds of real gameplay taking 1 minute!), and I believe most of the people would agree with me.
If your game runs with 10 FPS, the slow code/lack of optimization is the real problem, and no matter which workaround you choose, it will still be only a workaround and won’t solve the actual problem. Also, delta time is a solution that not only handles this problem, but also problems explained below.
If someone plays your game and has something like 30 FPS, and you DON’T implement delta time, your game will be basically unplayable for them. As opposed to the previous example, games running in 30 FPS is still popular, and thus a case that is important to cover. Due to that, I believe you don’t wanna force anyone trying to play your game at 30 FPS to either constantly play at slow-mo or refund your game.
Even when running on a high-end device, if your FPS oscillates between 50 and 100, your game will randomly run two times faster or two times slower, causing you to either play in slow-mo or a super-fast version of the game basically whenever your PC feels like it. That’s not fun if you ask me
In conclusion, I believe you should use delta time, as it is an elegant solution which solves multiple problems at once when it should, and doesn’t when it (or any similar approach) can’t and shouldn’t.
And if you still don’t believe me how bad it is to play any game without delta time on 30-40 FPS, I recommend you to download Yuzu emulator on something like an old laptop, play Super Mario Odyssey (or any other 3D game to be fair) and see how fun it is to play having the game constantly run in slow motion.
Ok guys, I had no idea this would get such long responses, and I still have to parse the above wall of text.
I want to just clarify first what I’m talking about…
normally I always just update stuff like pos+=dir.
-Maybe have a scale or speed multiplier, depending on the situation. -I use 1/60s time fixed update.
But then I saw this random video, where a guy multiplied his updates by some elapsed time variable.
Basically, if you have lag, when the object finally does reach its update routine, it will just move further, per update… TELEPORTING instantly from one frozen spot to the other, no matter the distance traversed…
… Imagine that in tennis guys, or billiards… The ball just skipping around from location to location. You’d have NO way of tracking the ball…
-But if instead if the game slowed down, and chugged frame by frame, you’d STILL be able to at least play.
So would I just add *deltatime to every line of update code, ie every thing that happens at some rate in the game…? Is it that simple?
This just sounds broken to me, like when getting input. The player would move FAR under the input of some frame, long ago… I can’t even predict how physics systems would react.
Thanks for clarifying,
Remember, there’s no problem with not understanding some stuff. And sorry if in my previous post I was kinda ignoring that.
If you move linearly, yes.
If you are making a player movement system with some kind of acceleration, it will require more maths (here’s a great video explaining advanced delta time usage)
To would be really helpful if you could find that video and link it here
Remember, in videogames there’s not really such a thing as “movement”, but it’s an illusion achieved by teleporting object frequently. When player has low FPS, you either choose to keep all the movement/animation values etc. the same (the version without delta time) and the player ends up in slow motion.
It’s quite different for when we talk about something like 10 FPS and 30 FPS
In the former case, the game either will be a slide show (with delta time) or a super slow-mo version (without delta time). For game centered around precision etc. The latter would maybe actually be better. However, if you decide to not use delta time, you end up with problems I described in points 3 and 4
It is very important for you to understand than (as I said before) any movement in games is, in fact, teleporting. So yes, while it is possible for the player to teleport through the wall when they have something like 2 FPS and when the game has delta time,
it can (and does) also entirely happen for example when the player is just moving very quickly, no matter the FPS or delta time or not
(example - see the video here)
But remember, it’s just how movement in games works (by teleporting), and physics programmers know that well and consider that when programming physics engines. That’s why we have things like continuous collision detection, which is a system for making sure that when the object teleports over a big distance between two frames (when moving quickly or when low FPS + delta time) it doesn’t skip any obstacles on its way
Sorry for writing another wall of text.
Anyway, hope that helps at least a bit
I know all movement is teleporting, what I mean is “perception” of teleporting… I’m talking about the “appearance” of a ball bouncing off walls slowly, vs the appearance of a ball randomly jumping between unrelated positions…
How we read such a room, will produce 2 very different understandings of what is happening.
Well I have gravity in my game, and movement acceleration…
… I specify 60 frames per second, and fixed timestep, and v-sync… I thought this had me covered.
… This whole thing is strange, because I have been using this framework for so many years, and I don’t seem to SEE people using it…
So guys, at the end of the day… Are we (all of you as individuals) using *delta_time in all your update dmethods for your 2d side-scrollers, angry_bird clones, etc.?
I just have NEVER seen people caring about it, but I also don’t know any other programmers.
I thought this was done in init / load phase, where I specify desired framerate?
I mean, I got a new pc a few years ago, leaving an ancient one, and when I moved all my old projects over, sure they needed to be modernized a bit, but their FRAMERATES were all the same…
When I made games BEFORE monogame, I would use the computers timer to time frames, but I just figured monogame had this built in, foreseeing this need in EVERY game…
Maybe I am missing something here? Or you guys are overcomplicating it 
If you are using fixed frame rate you probably don’t have to use delta time. But you must note that if your frames start to take more than 1/60 of a second to finish, you will have problems with game suddenly becoming slow-mo.
Because of that, I usually go for unfixed frame rate and delta time, with the exception being physics calculations or camera movement
I would recommend reading this blog post by Shawn Hargreaves (one of the original XNA developers) which explains the differences between fixed and variable timesteps and the reasoning behind the way they are implemented.
https://shawnhargreaves.com/blog/understanding-gametime.html
Programming in movies: Have an AI skim the net for content, and drop it in the game in real-time, as the player with the headset moves around an endless procedural world, mirroring reality.
Programming in real life: How bout this frame timing. Anyone have a link?
Here’s a video worth watching
Lol, this was the random video suggestion that had me questioning.
I guess the bottom line here, is for a metroidvania game that uses WELL under 10% cpu on a normal house hold PC, you can just set it to fixed update and enjoy life.
It’s up to you. Reading through the Shawn Hargreaves blog above you will get your updates eventually so you have a choice. I wouldn’t get hung up on the 10% cpu utilization for two reasons…
With fixed timestep you’re supposedly going to get those updates eventually, you just might get multiple in a frame. As long as the time to perform a single update is less than the average time per frame you will catch up. If you calculate your movement based on delta time, your character will just appear in the right place after a slowdown. Of course, this can make collision detection and response tricky.
There’s merits to both and, to be completely honest, I would just utilize both approaches. Use a fixed time step but also calculate position as a function of time.
I was required to have a SMART PHONE to clock in to work, as a DISH WASHER…
So you know what? Everyone else can upgrade their hardware too… No sympathy.
I’m a bit worried you may have missed the point but ultimately it’s your code. If you don’t want to do the multiplication with delta time and assume a fixed framerate by all means, do so. You’ll likely be fine in almost every case.
Good luck!
You can have the best of both worlds: a variable frame rate game with “slow down syndrome” (as we call it in our studio) where the game does not advance faster than a fixed frame rate and runs slow to the user.
But, you have to trap for this yourself.