SyntaxBomb - Indie Coders

Quote from: Steve Elliott on August 04, 2021, 11:34:16

Quote
Why is it important that the game runs at the same speed on all devices?

[...] Making vague and confusing statements from others doesn't really help.

Ashmoor was not really asking this question ... it was more a "why do something? ... let me explain why...".


And he sum'd it up quite well: your game needs to ensure to run the same speed on all computers. Else people could run it on a slooooow computer and have an easier game (eg. less good reaction time needed).

Decoupling update and rendering allows for individual adjustments - you can update as often as needed without requiring a capable GPU.
Think also of the famous "bullet hitting a thin wall / metal". If you only update 30 times a second, a fast bullet will be before the wall in frame 1 and after in frame 2. You _might_ fix that with interpolation but this will be way harder if eg the "thin wall" was also a rapid moving object. You would need to create "interpolated states" and then check for collisions etc.
It is easier to just update the physics 200 times a second then ... and when rendering you just render "what was right for that very moment".


Regarding "vague and confusing" ... it is up to the OP to be confused or not. It was also not "vague" as all the necessary information was given, allowing the OP to search for new information on its own. They might even search the forums for "delta timing" (or use google +syntaxbomb.com) and other existing threads will pop up.
If it was a BMX-specific question I would have linked my deltatimer code type/class. and the app framework using it.


I know the discussion about "delta timing" and "tweening" was done here 1-2 times. I am favouring to use both when really needed.
For "physics" delta timing is the way to go to keep stuff "moving smooth" - there Steve's suggestion is all you need (albeit you might even need a "lengthier" smoothing algorithm - smoothing over multiple frames, thought Steve used a similar approach in the past but am not sure). But once you decoupled logic from rendering (which you should try to do for the reasons given above) you might also check out "tweening". "interpolation" and "tweening" _always_ have the issue of only being "mathematically correct" but not necessarily gamelogic-wise correct.


What is missing in this thread here? The information that you can NOT guarantee smooth playback on multi-task-environments (smartphone, desktop computers running Windows...). There are schedulers which try to give every task the chance to do something. There might be little hickups here and there. On smartphones you can get a hickup right when it looses cell connection, or a BT devices comes near ...
If your process is "halted" for some short time, you cannot "smooth" that out. you do not know THAT it comes, or how LONG it will be.

QuoteAshmoor was not really asking this question ... it was more a "why do something? ... let me explain why...".

It was a little bit of both. There are degrees of consistency, a fast paced multiplayer game does not get away with delta time and needs to sync simulation across multiple devices at the same time. Therefore if you need high consistency, you probably need FRL more than delta time. If your game is single player, chances are it does not matter much if there are "slight" inconsistencies. By single player I mean in all aspects of the game, including comparing hi scores between players.  A move limited m3 game does need no consistency across devices.

I hope I made myself clear.

QuoteThis is what was requested - a better (smoother) version of delta time or similar solution.

Smooth does not always mean consistent across devices. Players may not mind that their game instance is running at 90% speed as long as it's smooth and responsive. If they don't gain a competitive advantage that can be exploited, I think it's perfectly fine. From a purely gameplay stand point, 10% slower may make players feel like god gamers and make the overall experience more fun! Of course, the opposite may be true as well so the OP should think about these game play aspects and figure out what's best for their game.

What of what I said do you consider vague and confusing statements?

Maybe Derron's right and hosch doesn't find it vague so codes up his own tweening routines, at least some more information has been added now.

Right, sorry for the late reply, I am quite busy adding the weekly leaderboard update to ORBITER.

Did I struggle with the delta time code? Absolutely. I had no previous experience with it and needed a fast solution to get the update out, which was kindly provided by Steve Elliott. This doesn't mean I'm not up for the challenge to make it better in my next game. Game development is about learning from your mistakes. My delta time code was abysmal and I definitely don't want to experience such problems again in the future

That being said, I will look into the input provided and try to improve ORBITER further, as it is a good learning experience. I started programming fairly recently with something small and I am working my way up to some bigger games. How many times have I read "Hey guys, this is my new game, it's supposed to be a Witcher 3 with some MMO elements. But I have one question: what is a for loop?" Fantastic Action Fishing Game didn't need delta time, it is a simple one button game. Super Spooky Alley was capped to 60 FPS and I called it a day. Those were not games for the rad competitive E Sports Scene, where dropping a frame meant a significant advantage for the other team. Those were learning projects.

I see no shame in me asking about the magic number of 2.0, which clearly should have been a variable called damping  No in all seriousness, thanks for the help everyone!