Don’t multiply velocity/position changes with delta time! End of story.

Okay, not quite. There’s a rationale that goes with it. And there are situations where applying delta time is important, if not required – but probably not in the way you’ve been taught by tutorials and fellow developers.

This is important stuff because applying delta time wrongly makes for a bad game experience.

What is this delta time thing anyway?

If you integrate velocity to a node’s position every frame, you have the option to multiply that velocity with the delta time passed in the update: method. Delta time is simply the time difference between the previous and the current frame.

Actually that is not entirely accurate – delta time is the time difference between the last and current execution of the update: method. This usually occurs every frame, but doesn’t have to be. On a scheduled selector that runs every second, the delta time is – tadaa – one second.

Okay, not even that is accurate. On a scheduled selector that runs every second, delta time is at least one second. It could be slightly more. This can depend on the resolution of the timer and how well one second divides with the time allocated to render a frame, or (as you’ll see later) whether time delta was calculated with the same means as the screen refresh rate.

What does multiplying with delta time do?

The effect of (not) multiplying a node’s velocity with delta time is as follows, assuming that 60 fps is the maximum achievable framerate as on iOS:

  • Don’t multiply with time delta: the node slows down as the framerate drops below 60 fps. 
  • Multiply with time delta: the node moves the same distance regardless of the framerate.

Multiplying with delta time is often referred to as “framerate independent” (updates, movement, gameplay, etc). In contrast not multiplying with time delta is often called “framerate dependent” (updates, movement, gameplay, etc).

Unfortunately, framerate independent updates are said to be “important” and often taught by fellow game developers without actually teaching the implications, drawbacks and situations where you don’t want to apply delta time. Here’s one key point to take away early:

Applying delta time only makes a difference when the framerate drops below 60 fps.

If your game always runs at 60 fps there’s absolutely no point to multiply with time delta. If time delta is only used to combat the effect of short-lasting framerate drops, possibly introduced by system events, you’re doing it wrong.

In this case, and most others too, you’re almost always better off not applying delta time on iOS. And if you do, there’s a whole set of things to consider, including the architecture of both the game and the engine.

Continue reading »