Game Development Reference
In-Depth Information
Returning to the example of Asteroids, imagine that there are
never more than 10 of the aforementioned space rocks on screen
at any given time. According to the rules of that game, every time
you shoot a full-size asteroid, two to four smaller ones are created.
Using the standard creation or deletion process, this will mean that
if the player destroys all of the asteroids successfully, the game will
have generated and garbage collected 40 objects (or more if the
smaller asteroids also split apart). While this may not seem like
much in the grand scheme, keep in mind that we are working in a
constrained mobile environment and this example scales to much
larger projects as well. If you used a recycling process, once an
asteroid was
by the player, it would have some sort of
reset method called on it that would kill any processes and return
it to the state it was in just after creation. This prevents the object
from garbage collecting, thereby foregoing the deletion phase. In
the example later in this chapter, we
destroyed
ll use object recycling to
increase performance and decrease memory usage.
'
Avoid Extremely Large Frameworks and Libraries
There are numerous open- and closed-source frameworks and
code libraries for helping Flash developers to write their code fas-
ter. These can range from text formatting utilities to encryption
libraries to design pattern frameworks (such as pureMVC, for
example). Some developers rely on these resources regularly for
speeding up their jobs. Many of these libraries are large and con-
tain many thousands of lines of code and potentially hundreds of
methods. In the standard Flash Player, only methods that are called
are compiled into machine code (using the JIT compiler). This
means any methods that are not used are never allocated memory
beyond the tiny bytecode that is compiled into the SWF. In the AOT
compilation process for the iPhone, Flash must assume that every
function may potentially be called during the course of an applica-
tion, so it has to compile all of them into machine code. This means
there is a considerable increase in file size of the final application, as
well as a moderate increase in the amount of memory needed to
store all of the code (that might not even be called at runtime).
Whenever possible, avoid using libraries from which you call only
a handful of methods. A good example of this might be any number
of the utility packages for formatting strings and text for display. Say
you use it for a convenient method to properly insert commas into
large numbers (meaning 1000 becomes 1,000) for readability. If the
class has, say, nine other methods for performing different opera-
tions and you are only using the one method, consider copying and
pasting that method into your own code. That will result in machine
code one-tenth the size it could have been and more memory for
essential code that is used. This is not a hard-and-fast rule
some
Search Nedrilad ::




Custom Search