// Fixed size steps
while( true ) {
for( frameTimer % stepSize ) {
stepGame();
}
}
// Varriable size steps
while( true ) {
stepGame( frameTime ); // Everything that wants frame rate independence scales it's self by the frame time
}
Do most engines use fixed or variable time step for game logic?
Author
Well the title pretty much says it all, do most engines use a fixed time step or variable time step for game logic?
such as:
Quake based engines? Ogre?
I recall that Age of Empires (And probably most RTS games with networking) uses a fixed step size in order to keep all peers in the game fully synchronised.
The second version, as you described it, is very non-robust, because it will update things independently of each other, and create issues with objects creating in the middle of the time step. It's always necessary to perform collision handling checks (or similar cross-object operations) "at the right time": either at a fixed step which guarantees that everything behaves with enough granularity, or by using collision detection and executing things with a variable time step using an event scheduler.
In the end, both fixed-step and variable-step engines have their purposes. Fixed-step updates are usually best used for networking because they're much easier to work with, while variable-step updates are better at expressing durations in script code.
However, the choice is not fixed. It's possible to use a fixed-step engine as if it were variable-step, and a variable-step engine as if it were fixed-step.
In the end, both fixed-step and variable-step engines have their purposes. Fixed-step updates are usually best used for networking because they're much easier to work with, while variable-step updates are better at expressing durations in script code.
However, the choice is not fixed. It's possible to use a fixed-step engine as if it were variable-step, and a variable-step engine as if it were fixed-step.
Most of the engines I've worked with use a variable time-step in most systems. You only need to run your update code once, and in most cases It Just Works™. But there are a lot of times (physics, collision detection, and networking come to mind) where variable time-steps cause a lot of trouble. In those cases you can easily retrofit fixed time-step logic into the relevant systems using the variable time-step. So the bottom line is, it depends!
As for games that are heavily synchronized, usually it doesn't matter whether you're using fixed or variable time-step since synchronization would be based on something like the frame number (which is why such games are always no faster than the slowest machine).
As for games that are heavily synchronized, usually it doesn't matter whether you're using fixed or variable time-step since synchronization would be based on something like the frame number (which is why such games are always no faster than the slowest machine).
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
