Producing Games - Building JavaScript Games for Phones, Tablets, and Desktop - page 373

Because it returns the new value, you don't have to store the old value, removing the need for that
temporary variable. You can use this to your advantage in the for loop, to make it more efficient:
for (var i = 0, l = myArray.length; i < l; ++i)
myArray[i] += 1;
These efficiency improvements may seem minor, but if the for loop is executed 60 times per second
for an array containing thousands of particles, minor improvements in efficiency may make the
difference between a smooth-running game and an unplayable game, especially on mobile devices
with limited computational power. Some browsers may perform optimizations on interpreting and
running JavaScript code, and these kinds of inefficiencies are relatively easy to detect automatically.
However, not all browsers or versions may perform the same optimizations. By making sure your
code is already efficient by itself, your game will run more smoothly on more platforms.
Mark: “Generally speaking, graphics are the main bottleneck. For some devices it
is more efficient to put everything in a large sprite and draw that. For other devices
that approach doesn't help because the bottleneck is in the number of pixels that are
drawn. As a result, we don't always know where bottlenecks are, because bottlenecks
are different dependent on the device, browser type and version, version of the
operating system, and so on. Our view is that we need to do everything as efficiently
as possible. Traditionally, we would use a profiler to find the bottlenecks and then try
to optimize the code accordingly. In JavaScript this is not feasible because of all the
different devices and browsers, let alone the fact that it's not always possible to use
a profiler for some combinations of device, browser, and operating system.”
The games developed in this topic don't focus at all on efficiency. A lot can still be improved,
particularly when drawing graphics. At the moment, the games in this topic redraw the entire image
in each game-loop iteration. In many cases, this isn't necessary. Large parts of the screen don't
change, so why redraw them? The HTML5 canvas allows you to redraw only a part of the canvas
screen. Games are much more efficient if you rewrite the code such that static parts of the screen
aren't redrawn. For example, if in a Sudoku game the player does nothing, there is no need to redraw
anything. If you use animated effects such as glitters, redraw only the part of the screen where
the effect is shown. Another way to improve efficiency in your games is to make a high-resolution
version and a low-resolution version. Depending on the capabilities of the device, you can then
automatically select which version of the game should be used.
Code efficiency is important, but it shouldn't be at the cost of code clarity. In many cases, efficiency
isn't as important as writing clear code. If a button click is handled one hundredth of a second later
due to inefficiencies in the code, the player won't notice it. On the other hand, if you've decided to
put all input-handling code in a single method to avoid method-calling overhead, your code will be
very difficult for others to understand, including a future you.
Mark: “In many cases, efficiency is not the problem, but hiccups are. An important
reason for hiccups are texture swaps. For devices with limited video memory, sprites
will be swapped in and out of memory while the game is running, leading to extra
computations. What we do to minimize this is to group sprites that are used in the
same place in the game on a single sprite sheet. For example, sprites that are used
for the title screen are placed on a different sprite sheet than sprites used for the