I have a question about creating a game loop with variable frame rates in Unity.
Until now I have used a fixed 60fps rate when making (mostly 2D) games. This has worked great for me as I know how long each frame takes. For the game loop logic I usually have a gameState enum variable and each gameState usually is controlled by a gameTime integer (+1 each frame) . So for example during gameState Jump I move the player during 60 frames and then reset the gameTime integer and set the gameState to Fall.
I am now trying to wrap my head around how I would do this with a variable frame rate. I can’t have a gameTime integer and do something for say 60 frames if the frame rate can be anything from say 5-250.
I’ve thought about using FixedUpdate() for all the logic and then try to interpolate all graphics between values in Update() but then I have to keep a lot of duplicate values to know what to interpolate between. Seems like a lot of overhead?
Is there a best practices example I can look at for this?
Don’t overengineer it. You’ll be surprised how little you can get by with on fine timing.
For my PalmOS and MS-DOS games (native games running at specific frame rates under Unity), I simply accumulate Time.deltaTime in a float, and when it exceeds 1 / frame rate, I do a frame (or two or three frames if I’m behind) and move on.
Thanks, I have tried that approach, but if I have a fixed rate of 60fps on my game logic and the player has a monitor set to lets say 50hz or 75hz, what’s the best approach to handle that?
Step #1: define what you mean by “handle that”
Step #2: go do that thing.
Seriously, you’re already overthinking it.
When you have an issue, come back and say “I did A,B,C and when the monitor update rate mismatches my intended game FPS, terrible things X, Y and Z are happening.”
Ideally you shouldn’t have your game logic running at a fixed rate. Digital Foundry has been railing on this topic lately where developers are locking their physics to 50Hz and then running the game at 60Hz, and to quote them “the whole thing is juttery looking, it doesn’t look smooth, it’s awful”. Granted that’s physics and not game logic but the point remains that you shouldn’t have the game functioning like this in an ideal scenario. Math exists and is easy to use to make a game that is below or above 60Hz behave identically to it running at 60Hz.
99.99% of the time it’s just about multiplying values by Time.deltaTime and… that’s about it. But yeah, don’t code your game logic to a fixed rate. Unity works on a frame-by-frame basis, so your game should too.
I do agree with this in a sense, but if you’re an oldskool 60hz console programmer used to doing all your work in frames… it can be quite a shock to come to floating point time.
That’s why I say just preserve the frame-count method, but use a floating point number to decide how many times in a given frame to call your “one frame” method.
If you love integer modulo for your engine discrete state logic, I say by all means keep your per-frame timing backbone.
That’s what I’m doing in KurtMaster2D, at anywhere from 10fps to 30fps, depending on game. Some of the TRS-80 Model 100 games ran at about 10-12fps on original 1983 hardware. Emulating them today I can run them at 1000fps or more, so it’s all FPS-ed down in floating point accumulators, then translated to discrete native “main one frame” calls.
