Framerate independent games are games that run at the same speed, no matter the framerate. For example, a game might run at 30 FPS (Frames Per Second) on a slow computer, and 60 FPS on a fast one. A framerate independent game progresses at the same speed on both computers (objects appear to move at the same speed). On the other hand, a framerate dependent game progresses at half the speed on the slow computer, in a sort of slow-motion effect. Making framerate independent games is important to make sure your game is enjoyable and playable for everyone, no matter what kind of computer they have. Games which slow down when the framerate dips can severely affect gameplay, making players get frustrated and quit!
This tutorial describes how you can make your game framerate independent. The same technique also enables time scaling, which allows for deliberate slow-motion effects and easy pausing.
The
dt system expression
The key to framerate independence is the dt system expression. dt stands for delta-time. Delta means a change in a quantity, so delta-time means the change in time. It is the time, in seconds, since the last tick.
For example, at 100 fps dt will be 0.01 (one hundredth of a second), and at 10 fps dt will be 0.1 (one tenth of a second). In practice, dt varies tick-by-tick, so it is unlikely to be exactly the same value for long periods of time.
Notice that if you add dt to a variable every tick, it adds 1 every second, because the time between all the ticks over a period of 1 second must add up to 1! Here's an example showing just that. (Adding dt to an object's instance variable is also a handy way to have a timer in an object.)
How to use
dt
Typically, framerate dependent motion is done with an event like this:
Every tick (once per frame), the object moves one pixel to the right. Notice that at 30 FPS this means 30 pixels per second, and at 60 FPS this means 60 pixels per second. Those are different speeds, depending on the framerate.
Remember from the example above that dt always adds up to 1 every second. So if we change the event to the following:
...the object will move to the right at 60 pixels per second at any framerate. Since dt adds up to 1 every second, 60 [] dt* adds to up to 60 every second. This means at both 30 FPS and 60 FPS our object moves to the right 60 pixels every second - the same speed, regardless of framerate.
Use
dt everywhere
Any time you move an object at a steady speed, you need to use dt in that way to achieve framerate independence. For example, Sprite's Move forward action takes a number of pixels to move the object forward. If you constantly move the object forwards, you could move it forward 60 [] dt* pixels to move it at 60 pixels per second at its current angle.
Behaviors already use
dt
All of Construct 2's behaviors use dt in their internal movement calculations. That means anything moved by behaviors like Platform and 8 Direction don't need any special treatment - they do this already!
Note that Physics is an exception. By default it does not use dt, and therefore is framerate dependent. This is because dt usually has small random variations. These variations can make the same setup in a physics game give different results even if exactly the same thing is done twice. This is often annoying for physics games, so by default it is framerate dependent. However, you can enable use of dt by using the Set Stepping Mode physics action on start of layout, and choose Framerate independent. Note in this mode it still clamps the maximum timestep for physics to 1/30 (about 33ms), because using a very large timestep can cause instability in physics simulations.
Timescaling
A really cool feature in Construct 2 is timescaling. This allows you to change the rate time passes at in the game, also known as the time scale. You can set the time scale with the system Set Time Scale action. A time scale of 1 means normal speed. 0.5 means half as fast, and 2.0 means twice as fast. If you set your game's time scale to 0.1, it's going ten times slower but still smoothly - a nice slow-motion effect!
Timescaling works by changing the value returned by dt. This means behaviors are affected, and any movement using dt. If you don't use dt in your movement calculations (like the first event above) the motion is not affected by the time scale! So to use time scaling, you simply have to use dt properly in all movement.
Pausing
You can set the time scale to 0. This stops all motion. It's an easy way to pause the game. Set it back to 1 and the game will resume.
You might notice you can still do things like shoot using the game controls. You can get around that by putting your main game events in a group, and activating/deactivating that group as you pause and unpause.
It's also a good way to test you have used dt correctly. If you have used it correctly, setting the time scale to 0 will stop everything in the game. If you have not used it correctly, some objects might continue to move, even though the game is supposed to be paused! In that case you can check how those objects are moved, and make sure you are using dt properly.
Other kinds of movement
It's important to realise that dt must be used for all kinds of motion. This includes rotation and acceleration.
Rotation
Similar to before, the following event rotates the piggy 1 degree every tick:
This is 30 degrees per second at 30 FPS, and 60 degrees per second at 60 FPS - again, different speeds for different framerates. Using dt in the same way solves the problem again. This way the piggy rotates at 60 degrees per second regardless of the framerate:
Acceleration
Acceleration is also fairly straightforward. Usually this only applies when you are making a custom movement via events.
If you have a speed variable, your object will be moving at Object.Speed [] dt* pixels per tick. Your object's speed variable therefore contains a speed in pixels per second.
Suppose you want to accelerate the object by 100 pixels per second over one second. You simply need to add 100 [] dt to the object's speed variable every tick, and it will accelerate in a framerate independent way. In other words, you use dt* both to adjust the object's position, and to adjust the object's speed.
Lerp
If lerping from two fixed positions, simply ensure the factor (x in lerp(a, b, x)) increases using dt like any other moving value. A more complicated case is when lerping from the last result of lerp, e.g.
Set X to lerp(Self.X, TargetX, factor)
In this case the correct form is to use:
lerp(a, b, 1 - f ^ dt)
...where f is between 0 and 1, e.g. 0.5. Commonly lerp(a, b, f [] dt)* is used instead, but this is not perfectly accurate and has some other pitfalls. The maths involved is explained in more detail in the blog post Using lerp with delta-time.
Common mistakes
Never use dt in the Every X seconds condition! An event like Every 1 second will run every 1 second regardless of the framerate, thus is already framerate independent. The condition measures time, not frames. If you make an event like Every 60 [] dt seconds, you have inadvertently made the condition framerate dependent - the opposite of what you want to achieve! Such a condition will run every 6 seconds at 10 FPS (when dt = 0.1), or every 0.6 seconds at 100 FPS (when dt = 0.01); if you just use Every 6 seconds*, it already runs every 6 seconds regardless of the framerate.
Advanced considerations
Minimum framerate
At very low framerates, dt can become very large. For example, at 5 FPS, dt is 0.2. An object moving at 500 pixels per second is therefore moving 100 pixels per tick. This can cause it to "teleport" through walls or miss collisions with other objects.
Games are usually unplayable at such low framerates, but it is even worse if they become unstable like that. To help the game stay reliable even at very low framerates, Construct 2 does not let dt get larger than 1/30 (about 0.033). In other words, below 30 FPS, dt stays at 0.033. This does also mean below 30 FPS the game starts going in to a slow-motion effect (described earlier as one of the issues of framerate dependent games), however this is usually a better result than the "teleporting objects" problem.
If you want to set a different limit to 1/30, you can use the system action Set minimum framerate.
Random variation
As mentioned with physics, dt usually has small and random variations, usually due to imperfect timers in the computer. Like with physics, this can also cause slight random variations in your game. However, usually the effect is negligable and much less noticable than with physics. It's recommended that you always use dt in your games unless exact precision is required (which is rare).
Object time scales
You can set a time scale for an individual object, via the system Set object time scale action. This allows you to have, for example, a game running in slow-motion with a time scale of 0.3, but still have the player acting at full speed with a time scale of 1. This is achieved by setting the time scale to 0.3, then using Set object time scale to set the player's time scale. The system expression dt is only affected by the game time scale. Objects have their own dt expression (e.g. Player.dt) which you must use instead of the system dt for all motion relating to that object. This way, there are now two values of dt: one for the game, and one for the player. Since they return different values, different parts of the game can progress at different rates.
In this example, to return the player back to game time, use the system Restore object time scale action.
Conclusion
It's important to design your game from the start using dt. This improves the gameplay, ensuring the pace never slows down in particularly intense parts of the game. As an extra bonus, you can also use the time scaling feature, easily pause the game, and even control object's individual time scales.
Don't forget behaviors already use dt (except with Physics where you must turn it on yourself). If you use behaviors to control all motion in your game, you don't have to worry about dt at all! However, most games have some event-controlled motion, and it's important to remember how to make it framerate independent.