Game Development Reference
If a bullet crosses a boundary, it's removed from the stage and then from the [^qhhapo array.
Classes and events
This was a very condensed explanation of how the Space Shooter game works, so make sure that you
check out the complete code in the source files to see all this code in its proper context.
Space Shooter is a good model for you to base your game projects on because it shows quite clearly
how you can distribute different kinds of tasks among classes. The game logic and important game
actions, such as removing objects and updating scores, is handled by the document class. (It could
also be a manager class, as in Dungeon Maze Adventure.) The object classes don't know much about
what's going on in the game, but when something important happens to them, they can announce it
to the game by dispatching an event. Other objects can then decide whether that event is important
to them or whether they should ignore it. The key thing is that the no other objects are dependent on
those events or the objects that are dispatching them to function correctly, and this goes a long way
to solving the problem of tight coupling, discussed in Chapter 8.
There's one very important thing you should keep in mind when you design classes: make the classes
do as much work with the information they have instead of requesting more information from other
classes. Try to keep getters and setters to a minimum or avoid them altogether if you can, and use
events to notify objects of things that happen in your game.
With this in mind, the structure of the Space Shooter game could be fine-tuned much more. Instead of
registering the bullets in an array in the document class, you could design the game so that the Lh]uan
class registers circle bullets and checks for collisions with them itself. The player could then notify the
rest of the game by dispatching an event if a collision occurs. This would take much of the work off
the shoulders of the document class, which would then only have to update the score and do general
game administration. Figure 10-23 is a good map to help you design a game structured like this.
Hey, is the topic finished already? It is, but it seemed like the all the fun was only just starting! If you've
reached this last page in the topic, congratulate yourself: You're a game designer! With the skills
you've acquired over these ten chapters, there are few game design scenarios that you won't be able
to approach with confidence.
But if you're like everyone else who's ever started learning game design, you'll find that the desire to
learn more is insatiable. Although you've accomplished so much already, there's a great universe of
learning ahead of you. Here's a quick roundup of some of the areas you might want to explore:
Adobe's online help documentation : Adobe maintains excellent online documents detailing
most aspects of Flash CS4 and AS3.0 programming. You can access these documents by select-
ing Help ° Flash Help in Flash, or pointing your web browser to dppl6++dahl*]`k^a*_ki+
aj[QO+Bh]od+-,*,[QoejcBh]od+. I've made numerous references to sections of these docu-
ments throughout this topic, and they remain the most comprehensive primary source for all
things Flash and AS3.0. Although many of the topics they deal with and the approaches they
take are reasonably advanced, they should match your current level of ability. Spend some
time going through some of the hundreds of articles and you're sure to find great food to fuel
your developing programming skills.