The purpose of this article is to show you how important frame rates are when creating games. For the sake of simplicity, we are only going to draw Cleverti’s logo and we will animate it.

Let’s start comparing things!

If we run an animation without controlling the frame rate, it can run at different speeds for different computers or devices, this is not good when we are talking about games, because we want all the players to experience the game with the same rules! In other words, if your game is running slowly (that is, fewer frames per second), your object will also appear to move slowly, whereas if your application is running quickly (that is, more frames per second), your object will appear to move quickly. Having such unpredictable gameplay experiences is undesirable. In this example, we can see how an animation without any frame rate controller and at a speed of 0.1 can be:

//...

function gameLoop() {

   // Call update function to update game logic
   update();

   // Call draw function to draw our logo to canvas
   draw();

   // Call gameLoop recursevly
   requestAnimationFrame(gameLoop);
}

//...

Now let’s see how important it is to control the frame rate. In the example below, we will add a frame rate controller system, so every player is able to see the animation at the same speed. No matter how fast or slow the device is, the speed will be the same for everyone. This is the same example but here we can see how an animation with frame rate controlling and at a speed of 0.1 and 10 frames per second can be:


// Simulate 1000 ms / 60 FPS = 16.667 ms per frame every time we run update()
let time_step = 1000 / 60,
delta = 0,
last_frame_time_ms = 0, // The last time the loop was run
max_FPS = 60; // The maximum FPS we want to allow

function gameLoop(timestamp) {

   // Throttle the frame rate.
   if (timestamp < last_frame_time_ms + (1000 / max_FPS)) {
       requestAnimationFrame(gameLoop);
       return;
   }

   delta += timestamp - last_frame_time_ms;
   last_frame_time_ms = timestamp;

   let num_update_steps = 0;
   while (delta >= time_step) {

       // update our game logic before draw things to canvas
       update(time_step);
       delta -= time_step;
   }

   // Call draw function to draw our logo to canvas
   draw();

   // Call gameLoop recursevly
   requestAnimationFrame(gameLoop);
}

Once we get the frame rate system, we can control the maximum frames per second we want to allow. This is the same example but here we can see how an animation with frame rate controlling and at a speed of 0.1 and 25 frames per second can be:

This is the same example but here we can see how an animation with frame rate controlling and at a speed of 0.1 and 60 frames per second can be:

So… Why should we use a controlling frame rate system?

As the objects are moving at varying distances in each frame – and some of those distances are pretty large- they start to behave erratically without a controlled frame rate. In games, this phenomenon can allow players to run through walls, or prevent them from jumping over obstacles. We can also experience small rounding errors from multiplying the velocity with the frame delta. This will result in the object’s position “drifting” over time.

A solution to fix this is to separate the amount of time simulated in each update() from the amount of time between frames. This approach avoids inconsistent rounding errors and ensures that there are no giant leaps through walls between frames.

Now that you know this… go make some awesome games!

 

 

Written by Nuno Barão |  Developer at Cleverti