When writing good framerate-independent game code, you take some sort of deltaTime
parameter in your main render()
function and then scale your calculations based on that -- this is essential for things like physics engines.
However, in my game there are often discrete tasks -- the AI system might add components representing a "task" to the agents that should be removed (finished) after x
seconds have passed. To make a contrived example, if a task/component takes 60ms to process, and the game is running at 60fps (16.6ms/frame), then the first three frames will run, bringing the "work done" on that task to 50ms, and then one last frame will do 10ms of work, but then the remaining 6.6ms will be "lost", because the AI system won't run and schedule new work until the next frame.
Ideally, I'd like to not lose the "loose change" of ms that occurs at the end of tasks.
How do people normally deal with this? I can think of a few options:
- Ignore it -- the shortest tasks will probably never be less than 100ms anyway, generally more in the 1-5 second range. It's not multiplayer, and provided the game can maintain 60 fps (which it probably can), the experience should be the same for all players.
- "Carry" the remainder over to the next frame. In the example above, give the agents 23.2ms of time to "spend" in the next frame.
- Amp up the framerate. At 60fps, the most time you can possibly waste is 16.6ms, but at 200fps you can lose at most 5ms. (Currently my logic loop and render loop are coupled and capped at 60fps, but I can easily change that.)