|
|
|
|
Reply From: |
avencherus |
Consider how much of an amount you want to be gone from one continuous second. Say it’s 100 boost fuel.
# Lose 100 units per second.
fuel_loss_per_second = 100
Then use the delta given by the _process(delta) function and multiply it into that amount, while the conditions are met.
What happens with this, is in a game operating at 60 frames per second, that will be 60 updates that take about (1 second / 60 frames) .016666~ seconds each.
Now if you’re multiplying 100 by .016, you’re expending 1.6 fuel points every update while holding your button down. After 60 frames that will total up to 100 (or super close) after 1 second of game time.
func _process(delta):
if boosting:
fuel = fuel - fuel_loss_per_second * delta
OK that’s a pretty cool and simple solution. What happens though if the game chugs down and frame rates decrease? I’d assume the boost would not work to plan? What are your thoughts on that?
Robster | 2016-08-22 04:10
I think the problem you’re worried about is what is going to happen if you don’t use delta, or game logic or nodes that are fed by delta time.
The game loop measures and works to keep timing synchronized. Delta is a value it reports as it works to do this from frame to frame.
Another benefit worth mentioning is that if you decide to change the frame rate of your game, and you’re using delta, you don’t have to manually adjust any of your code or values.
I should’ve pointed out too that you may want to use fixed_process() rather than process() for mechanics that need to be more accurately handled over time.
The process() function is more for rendering, and the delta will be variable. I haven’t tested it in Godot, but I think it still will give a value that tracks to the elapsed time. It tries to hit your frame rate, but it if it doesn’t it will adjust the delta it sends to reflect the difference since the last time it updated. Meaning if you lost a whole frame, the next update you will have a delta that is twice as large, which should keep the values accurate over time.
If you want to see the difference I would recommend just doing a print(delta) in each function, and watch the output console.
A game loop is generally split into two parts, the physics and the rendering. For the physics part, which is fixed_process(delta) in Godot, it will generally aim to keep time as best it can, and all timesteps are a fixed size. This is important, because of lost precision in rounding floating point numbers. If you have .01444 then .01788 next frame, you might lose some small amount of accuracy in the multiplications, even if it averages out to .01666 over 1 second.
When using a fixed time step, if the game loop falls behind, it will begin doing multiple updates per frame to catch up, and begin to defer the rendering. As long as it can do this, it will keep the simulation accurate. The game may hiccup visually, but it will do all the calculations in the meanwhile. So your amounts like distance traveled and fuel consumed will still be calculated 60 times a second. The loop will measure and check the time to make sure it is staying faithful to 60 updates a second, even if they end up being awkwardly spaced out because of performance problems.
If your game can never catch up, than there is only one solution for that, you have to reduce something or find some optimization solution, because the machine you’re using cannot handle what you’re asking it to do.
For the occasional spike in performance, things should be fine, this is what delta time is designed to handle. However, in the extreme cases, when things are so bad and physics frames have to be dropped to keep the game from locking up (spiral of death), then you have to consider the metrics of how much work is being done and how much the hardware can handle.
avencherus | 2016-08-22 05:54
That is the best description of how it works that I could have read. I really want to just stop and say thank you.
Interestingly I’ve gone and made up a whole set of logic which I’ll paste below to help others in the future but the description you gave is priceless. It’s a shame there’s no “sticky” feature here.
Thanks again friend. It’s really cleared up a lot of things for me.
Robster | 2016-08-22 13:14
You’re quite welcome Robster. X)
I’m glad it was sensible enough that you got value from it.
avencherus | 2016-08-22 14:33