Hi!
When you change scene or game state in game your elapsed time is then big because of all the stuff happening to change and also all the loading needed for this new scene or game state.
That can give a big jump in anything related to the elapsed time like physics or animation.
Is it common to reset the elapsed time when scene or gamestate is changed?
Is it better to not touch it and keep the value it will give?
Any comment about this thing?
Thanks a lot!
🎉 Celebrating 25 Years of GameDev.net! 🎉
Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!
Reset elapsed time when changing scene or game state?
Author
Why would you want to continue the game simulation while you load and set up a “new scene”? You should wrap up the previous scene, recording and computing important details and forgetting the rest, and initialize the new scene deliberately.
For example, at the end of a level in a single-player FPS you'd probably forget the position of the player and all state of enemies and objects in the previous level, remember health, ammo and active weapons, and place the player and all new enemies and objects in the designated starting position in the new level. Time stops (or rather ends) and restarts.
On the other hand, if you want to continue play without interruption it's implied that there is no “scene change”: what you want to do is probably loading and unloading assets in advance conservatively, in your engine's spare time.
So, what kind of game are you making and what transitions are you worried about? How do similar games behave?
Regarding how time advances: you are probably running variable simulation timesteps (advancing the game state by the actual elapsed time since the previous frame). This is a potential problem even in good cases, due to lack of reproducibility and roundoff errors, and to potential slowdown amplification and overload: you should at least consider using a fixed timestep (at least for simulation and input; rendering is less critical) to ensure consistency and limit slowdown.
Author
The main loop while the app is not stopped is:
1) Switch to next game state if needed (that call Close() of the current state and Call Load() of the new state)
2) Process inputs / window events
3) Process fixed timestep update (16ms)
4) Process variable timestep update
5) Render the current frame
The elapsed time and time accumulator for the fixed time step update is updated based on the elapsed time from 1 to 5.
This is certainly a very common main loop for sure, in Unreal and Unity game state is your scene that you load/unload.
The problem is when you switch game state, that will do the first update using the last elapsed time which is certainly OK but then the next frame you have all the close of last game state + load time of the new game state in account so you can have a big jump.
One solution is to do on step 1:
if (SwitchToNextGameState() == true) {
// Reset elapsed timer and fixed time step accumulator to 0.
}But yes I wonder if it's really good to do that and if it's a common issue and solution.
You could make a function that does 2 to 5 as a loop until it stops. Then return, load new scene, and call the function again.
The main function is then about changing scenes only, while the function is a subroutine to play a scene.
I'd say this depends tremendously on your game.
If your game is set up for everything to behave as if real time is elapsing, then transition times and loading times need to take real time. In that scenario, develop your simulation code to handle the large advances. For example, if you had a greenhouse or garden loading back up you'll need code that can advance as though seconds, minutes, hours, or even days have passed, all done with a single update. In one case it may mean advancing the age or spoil timer slightly, if different time elapsed the single update might spoil an entire inventory or even kill a plant that wasn't maintained.
If your game is set up for the world to effectively stop as transitions happen, then by all means stop the simulation and stop all updates. When the transition is complete, resume the simulation time. For this example, if the gap is extremely large your code would treat it as an unintentional blip, and run a single step update or a tiny update or no update at all, depending on what makes sense for your game.
Author
Thanks for the comments, all good things there. My question is more on a general elapsed time for the update loop. A simple example is let say you change game state and you have a fade in animation, if your loading takes a lot of time you will get a jump on this fade in animation and then if your fade in is 1s, maybe that will jump to the end of the fade in animation directly because of this big elapsed time.
Let us assume you're in another game state and you want to cycle something for 5 seconds after loading. Assume elapsedTime is in seconds.
cycleTime = 5 seconds
startTime = elapsedTime
finishTime = startTime + cycleTime
Then the difference between your start and finish time regardless of the update elapsed time will be whatever time you wanted.
You'll also set your startTime and finishTime after your loading is finished in your update section.
This is just one example if you want to keep your elapsed time going without resetting it.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
