Basic Game Objects - Building JavaScript Games for Phones, Tablets, and Desktop - page 96

This way of calculating the past time in a game loop is called a fixed timestep . If you have a very
slow computer that is not able to execute the game loop 60 times per second, you still tell your
game objects that only 1/60 of a second has passed since the last time, even though that may not
be true. As a result, game time is different from real time . Another way to do it would be to calculate
the actual passed time by accessing the system time. Here is how you do that:
var d = new Date();
var n = d.getTime();
The variable n now contains the number of milliseconds since January 1, 1970 (!). Every time you
run the game loop, you could store this time and subtract the time you stored the previous time you
went through the game loop. That would give you the real time that has passed. There is no fixed
timestep in this case, because the passed time depends on the speed of the computer/device that
is used, the priority of processes in the OS, whether the player is doing other tasks at the same time,
and so on. Therefore, this approach to dealing with time in games is called variable timestep .
Variable timestep is especially useful in games where high frame rates are desirable: for example,
in first-person shooters where camera motions can be quite fast because the camera is controlled
directly by the player. In those cases, a variable timestep in combination with trying to call the
game-loop methods as often as possible can result in smoother motions and a more pleasurable
gaming experience. The disadvantage of variable timestep is that the time continues even if
the player is temporarily doing something different (like opening a menu in the game or saving the
game). Generally, players won't be very happy if they discover that while they were browsing their
inventory, their character was killed in the game world. So, as a game developer, you need to fix
such issues when using variable timestep.
Another example of when using variable timestep may interfere with the playability of the game is if
the player switches to another application (or tab in a browser) temporarily. This happens quite often,
especially when you're developing games that run in a browser. This is also one of the main reasons
you use a fixed timestep in this topic. When the player switches to another tab, the JavaScript code
execution in the inactive tab is automatically paused until the player returns. When using a fixed
timestep, the game simply continues where it was paused when the player reactivates the tab, because
the game objects don't care about the real time that has passed, only about the fixed delta value.
Let's go back to the ball.update method. If you look at the body of the method, you can see that
the first part consists of an if instruction. The condition of the if is that the ball.shooting variable
should have the value true . So, if the ball is currently moving, the body of the if instruction is
executed. This body again consists of four instructions. The first two instructions update the velocity,
and the last two update the position. The first instruction updates the x direction of the velocity. You
multiply the velocity with a value of 0.99, the effect of which is that the velocity slowly decreases.
This is done to simulate air friction. The second instruction increases the y velocity in each update.
This is done to simulate the effect that gravity has on the ball. Together, the velocity changes in the
x and y directions result in plausible ball behavior. Of course, in the real world, the gravity is not 6.
But then again, your real world doesn't consist of pixels, either. Physics in game worlds doesn't
always accurately represent physics in the real world. When you want to incorporate some form of
physics in your game (be it very simple or extremely complex), the most important part isn't that
the physics is realistic, but that the game is playable . This is why in a strategy game, an airplane will
move as fast as a soldier walking on the ground. If the game used realistic speeds for those two
objects, it would result in an unplayable game.