Game Development Reference
In-Depth Information
they should be marked as static . The third value, health, is specific to
each Enemy, so it should be remain instance based. The same applies
to methods as well. Consider these two methods:
public function getScore():int;
public static function getHighScore():int;
If you create a new instance of a game class for each session of
play, it might have individual values, such as the player
this case, it makes sense to have a method for retrieving that speci-
fic score from a specific game instance. However, in the case of the
highest score achieved over multiple sessions of a game, it makes
more sense to store this value in a static variable and retrieve it
from a static method.
Make Final Your Answer
Another seemingly trivial optimization that can be made to your
classesandmethodsistomarkthemwiththe final keyword. When
a method or class is final , it cannot be extended through a subclass,
and the compiled code that is generated requires less lookups in
memory to execute the method. In fact, the compiler is smart
enough to make decisions about how to generate the final method
code based on how many times the method is called and its size. If
applications, it wouldn
t be practical to declare it as final. However,
all of the application-specific classes (those that are not generic and
are only related to the application at hand) for a game should easily
be marked as final. Even when a class might need to be extended
and you don
t want to mark it final, there are often individual meth-
ods that would make sense to
every little bit helps.
Recycle, Both In Your Code and In Your Home
The process of creating and destroying objects in memory is taxing
for the iPhone (or any limited-resource mobile device). Some types
of games, such as modern-day Asteroids
knockoffs, create
numerous objects on the Stage and then proceed to destroy them
and create new ones. This technique is very common in game
development, and as long as guidelines for proper garbage collec-
tion are followed, it is not a noticeable performance hit until the
number of objects being created and destroyed gets into the thou-
sands at a time. iOS devices have a much lower tolerance for that
much creation and destruction, so we want to limit these processes
in our code as much as possible. We can
t really do so much about
the initial creation step
the objects have got to get there some-
how. However, an alternative to deletion (and thus the creation of
new objects) is to re-use or
Search Nedrilad ::

Custom Search