Finishing the Jewel Jam Game - Building JavaScript Games for Phones, Tablets, and Desktop - page 228

You also want to show the player a message that they got extra points in the case of a double or
triple combination. To do so, you can show an overlay for a couple of seconds. As a first step, let's
load two overlays for that and add them to the game world in the JewelJamGameWorld class:
var doubleOverlay = new SpriteGameObject(sprites.double, ID.layer_overlays);
doubleOverlay.position = new Vector2(800, 400);
this.add(doubleOverlay);
var tripleOverlay = new SpriteGameObject(sprites.triple, ID.layer_overlays);
tripleOverlay.position = new Vector2(800, 400);
this.add(tripleOverlay);
As soon as the player gets multiple combinations, you want to show this overlay on the screen for a
couple of seconds. In order to be able to do that, you first need to understand a bit more about how
you deal with time in games.
Time in Games
Time is a very important concept in games. For example, it's used to measure how fast a player
executes a task, to update positions of objects according to their velocity, to keep track of the last
time the player beat an enemy, to determine whether it's currently day or night in the game, and
so on. To accommodate these things, a game engine generally contains many classes to deal with
different aspects of time. Because time is so important in games, game-loop methods such as
handleInput and update always have a parameter delta that indicates how much time has passed
since the last game-loop iteration. The game time doesn't have to be the same as the time in the
real world. In the game, time can go three times as fast, or ten times as slow, or whatever the game
designer wants. For example, a game designer could decide that in a simulation game, time at night
goes much faster because not much happens at night. The game time begins only after the game
has started. Furthermore, the game time can be interrupted. For example, if the player switches to
another tab in the browser, the game time is paused because the browser stops executing the script
(whereas real time continues).
When the game starts, the game time is zero: zero hours, zero minutes, and zero seconds have
passed. Every time the game-loop methods are executed, you get as a parameter a real number
indicating how much time has passed. The examples in this topic follow the fixed timestep paradigm,
meaning you assume a fixed number of game-loop iterations per second, regardless of how fast or
slow the machine is. You can see this when you look at this line of code in the Game object:
var delta = 1 / 60;
So, even if the game loop is running less often than 60 times per second, all the objects in the game
behave as though the game loop is running exactly 60 times per second. The advantage of this
approach is that user interruptions (such as switching to another tab) simply pause the game time so
that when the user comes back, they can continue to play like nothing happened. The downside is
that on very slow computers, the game may slow down considerably.
Another option is to use real time. That way, it doesn't matter what the speed of the computer is (or
whether the player switches to another tab): the game always continues. When using real time, it's
also possible to call the game-loop methods more often than 60 times per second. The interruption