download gameloop

 

Game Loop.

• Fixed time step with no synchronization:

  This was our first sample code. You just run the game loop as fast as you can.

  • It’s simple. This is its main (well, only) virtue.

  • Game speed is directly affected by hardware and game complexity. And its main vice is that if there’s any variation, it will directly affect the game speed. It’s the fixie of game loops.

• Fixed time step with synchronization:

  The next step up on the complexity ladder is running the game at a fixed time step but adding a delay or synchronization point at the end of the loop to keep the game from running too fast.

  • Still quite simple. It’s only one line of code more than the probably-too-simple-to-actually-work example. In most game loops, you will likely do synchronization anyway. You will probably double buffer your graphics and synchronize the buffer flip to the refresh rate of the display.

  • It’s power-friendly. This is a surprisingly important consideration for mobile games. You don’t want to kill the user’s battery unnecessarily. By simply sleeping for a few milliseconds instead of trying to cram ever more processing into each tick, you save power.

  • The game doesn’t play too fast. This fixes half of the speed concerns of a fixed loop.

  • The game can play too slowly. If it takes too long to update and render a game frame, playback will slow down. Because this style doesn’t separate updating from rendering, it’s likely to hit this sooner than more advanced options. Instead of just dropping rendering frames to catch up, gameplay will slow down.

• Variable time step:

  I’ll put this in here as an option in the solution space with the caveat that most game developers I know recommend against it. It’s good to remember why it’s a bad idea, though.

  • It adapts to playing both too slowly and too fast. If the game can’t keep up with real time, it will just take larger and larger time steps until it does.

  • It makes gameplay non-deterministic and unstable. And this is the real problem, of course. Physics and networking in particular become much harder with a variable time step.

• Fixed update time step, variable rendering:

  The last option we covered in the sample code is the most complex, but also the most adaptable. It updates with a fixed time step, but it can drop rendering frames if it needs to to catch up to the player’s clock.

  • It adapts to playing both too slowly and too fast. As long as the game can update in real time, the game won’t fall behind. If the player’s machine is top-of-the-line, it will respond with a smoother gameplay experience.

  • It’s more complex. The main downside is there is a bit more going on in the implementation. You have to tune the update time step to be both as small as possible for the high-end, while not being too slow on the low end.

See Also

• The classic article on game loops is Glenn Fiedler’s “Fix Your Timestep“. This chapter wouldn’t be the same without it.

• Witters’ article on game loops is a close runner-up.

• The Unity framework has a complex game loop detailed in a wonderful illustration here.