So
y
ou wanna be a hotshot
g
ame desi
g
ner? Well, if
y
ou have a basic
g
ras
p
of Macromedia Flash MX,
y
ou can.
Unafraid to tackle some of the more complicated aspects of game creation (including physics and
trigonometry!), this comprehensive reference covers it all. Macromedia Flash Game Design Demystified starts
out with the basics: planning, adapting ActionScript techniques, using introductory Flash game techniques,
and more. Then it gets down to the real business of building simple games. You'll tackle simple-lo
g
ic and
q
uiz
games before moving on to multiplayer and complex-logic games (chess, for example) learning about
importing 3-D graphics, adding sound effects, and licensing your games in the process. The book's
companion CD includes the source files for a number of games as well as the tutorials and lessons that go
alon
g


Publisher : Peachpit Press
Pub Date : September 09, 2002
ISBN : 0-201-77021-0
Pages : 648

Copyright

Acknowledgments

About the ContributorsDerek BairdEric DoleckiRobert FirebaughMichael GrundvigIntroductionWhy Flash?

Points to Remember
Part 2. Examining the Nuts and BoltsChapter 3. Trigonometry 101Why Learn Trigonometry?The Flash Coordinate SystemAnatomy of a TriangleThe Pythagorean TheoremThe Heart of TrigVectorsDetection Using hitTest()Detection Using MathCollision Detection with Advanced ShapesPoints to Remember
Chapter 6. Collision ReactionsBouncing Off the WallsConservation of Momentum and EnergyApplying the Conservation LawsPoints to RememberDeconstruction of a Simple WorldPoints to Remember
Chapter 9. Artificial IntelligenceTypes of AIHomegrown AIThe Perfect MazePathfinding AlgorithmsPoints to Remember
Chapter 10. Using a High Score List


Why Sound Is ImportantManaging Sound EffectsCreating Sound EffectsCreating Music LoopsPoints to Remember
Chapter 13. Dissecting a ChatIntroduction to the ChatHands-On Tour of the ChatPoints to Remember
Part 3. The Games

Possible Game EnhancementsPoints to Remember
Chapter 16. PinballGame OverviewGame CodePossible Game EnhancementsPoints to Remember
Chapter 17. Tic-Tac-Toe: Your First Multiplayer GameGame OverviewThe Multiplayer Aspect


Game OverviewMultiplayer ActionsGame ActionsPossible Game EnhancementsPoints to Remember
AppendixesAppendix A. Protecting Your GamesTheft and AntitheftSo You Found Your Game on Another Web Site?
Using the XML Socket Object
Appendix E. Developer ResourcesGeneral Game ResourcesFlash Resource SitesAIIsometricMathPhysicsAudio

matching.flapacmanprojectile_motion.flaraiseTheBlocks.flarobust_tracingshared_object_highscore_listship.flashuffle_deck.flatic_tac_toe_ai.flatile_boat


look like an intelligent person wrote them!
Eric Dolecki, for doing a magnificent job with the figures and screenshots for this book, turning my scribbled
instructions into clear illustrations, thanks a lot!
Robert Firebaugh, for the phenomenal graphics you created to go with the games in this book, and for the
very informative chapter on the graphical approach in games.
Mike Grundvig, for developing ElectroServer, miscellaneous server-side scripts, and for writing the appendix
on multiuser gaming. Not to mention your great suggestions and guidance for good code structure.
Derek Baird, for your contribution of music and sound effects for the games in this book, and content for the
Sound chapter.
Branden Hall, for your wddx_mx.as file, which is a great asset to multiplayer gaming.
I am grateful for the support and contributions of the entire Peachpit Press crew and production team,
es
p
eciall
y
Wend
y
Shar
p
, Mar
j
orie Baer, Lisa Brazieal, David Van Ness, Elissa Rabellino, and Rebecca Plunkett.
I also want to acknowledge Kurt Wolken of Wolken Communica for the cover design and Bentley Wolfe of
Macromedia for his sharp-eyed technical verifications.
Support and encouragement of friends and family have enabled me to gain the experience and determination
needed to write this book. A big all-around thank you to mom, dad, Grambo, my grandparents, and Janie. Of
course I also need to acknowled
g
e the smaller creatures
(

@ve RuBoard

I l
@ve RuBoard

Derek Baird
www.wireheadmedia.com
Derek Baird is a composer, sound designer, and multimedia developer with a degree in music composition
North Carolina School of the Arts. He's pursued additional studies in film music and music technology at
LaGrange College. He is also a professional guitarist who has performed with Grammy-winning acts and
on internationally released albums. Derek currently runs
Wireheadmedia.com, an Internet multimedia
that specializes in sound design and high quality music composition.
Derek contributed the "
Creating Sound Effects" and "Creating Music Loops" sections of Chapter 12, "The
of Games."
I l
@ve RuBoard

I l
@ve RuBoard

Eric Dolecki
www.ericd.net
Eric E. Dolecki is currently a Director of Interactive Technological Innovation, working in Boston, MA. He
maintains his own site (
www.ericd.net) and contributes regularly within the Flash community. Eric recently
Macromedia Site of the Day for his Flashforward 2002 NYC Event Guide application (which runs via Flash on
Pocket PCs, utilizes local XML data storage, and even allows for wireless polling). Eric is co-author of
books, including Macromedia Flash Super Samurai, Flash MX Audio Magic, and Flash MX Dynamic

Flash, presented at an international Flash conference, and moderates on several prominent Flash community
Web sites. He is currentl
y
em
p
lo
y
ed at Hallmark Cards Inc., in the IT Solutions Center Of Excellence, focusin
g

primarily on Java and Application Architecture development.
Michael contributed
Appendix B,"Multiuser Servers."

I l
@ve RuBoard
I l
@ve RuBoard

Introduction
People are always asking me about game development—how they can get into it, what's the best tool for it,
etc. I answer questions like this wherever I go. And it got me thinking that if so many people had all these in-
depth questions, there must not be a good resource out there….
This book brings you into the world of game development—specifically, game development in Flash, with the
powerful ActionScript tool to help you automate, repeat, change, anticipate, and govern the actions of games
from a simple word game to a complicated multiplayer game of pool. It is in no way a basic Flash tutorial,
fair amount of familiarity with Flash is assumed, without which you might have a hard time navigating the

200 MHz Intel Pentium processor
Windows 98 SE, Me, NT4, 2000, or XP
64 MB of free available system RAM (128 MB recommended)
85 MB of available disk space
1024 x 768, 16-bit (thousands of colors) color display or better
CD-ROM drive
Macintosh
Mac OS 9.1 and higher, or OS X 10.1 and higher
64 MB of free available system RAM (128 MB recommended)

85 MB of available disk space
1024 x 768, 16-bit (thousands of colors) color display or better
CD-ROM drive

I l
@ve RuBoard

I l
@ve RuBoard

How to use this book
This book introduces you to the world of online gaming, shows where Flash fits into the larger universe of
online gaming, shows what it is and isn't good for, and goes into great detail on how to create games using
Flash.
Game development isn't all fun and games. It requires a lot of planning, projecting, and imposing logical
structures on information.
Part 1 introduces you to the
g
eneral world of
g

This arrow refers you to a related section of the book, where the same topic is
The CD-ROM component
The accompanying CD-ROM includes all the exam
p
le and su
pp
ortin
g
files necessar
y
to dissect and understand
the games discussed in this book. There are also trial versions of ElectroServer and Macromedia Flash MX, as
well as 8 additional full and partial games that are not actually dissected in
Part 3, but that you can dig into
yourself.
discussed in more detail.
This symbol warns you of pitfalls or disadvantages you may encounter in the process
being discussed.
I l
@ve RuBoard

I l
@ve RuBoard

Part 1: Getting Started with Flash Game Design
I l
@ve RuBoard

Inspirational Kick-Start
Flash is an incredible authoring tool. With it you can create rich Web pages, advanced applications, and, of
course, games. As a Flash game developer, you can create amusements as simple as tic-tac-toe or as
complicated as a real-time multi
player game. Imagine what it would be like to think of an amazing game idea
(
which
y
ou ma
y
have alread
y
done
)
and then sit down at
y
our com
p
uter and actuall
y
build it. With Flash, this
p
rocess can be ver
y
eas
y
, and

Soon you will be making your own!
DON'T FALL! PINBALL

ICE WORLD I l
@ve RuBoard

I l
@ve RuBoard

Terminology
What do you think of when you see the word
isometric? Tile-based? Avatar? Don't worry, there's no need to
for your dictionary. Enterin
g
the world of
g
ame development, you'll find that, as with all specialized fields, a
of descriptive terms are commonly used when talking about games. It is important to understand, or at
have some idea of, what a word means when you run across it in this book. Most of these terms will be
described in more detail in later chapters, but here's an overview to get you started.
Game Views
A
game view is the player's perspective in the game. Is the player seeing everything through a character's
eyes, or from above? Each of the possible views has its own name. The

er Mario Brothers or Donke
y
Kon
g
. Side views are ver
y

p
o
p
ular in
p
latform
g
ames and are
almost always two-dimensional. This view is used in Ice World, shown at left and dissected in
Chapter 15.
Third person— This term describes any view that isn't either first person or through another character's
Most of the views listed here, such as isometric, are third-person views.
Courtesy of Electrotank, Inc.

Top down— The top-down view shows you the game area as seen from above, the way a bird would see it.
This view is popular for games like the original Zelda, and for many puzzle games like Minesweeper. At
course, is Pac-Man.
Courtesy of Namco Holding Corp.

General Terms
Here are some commonly used game-development terms whose meanings you should be aware of.
Algorithm— An algorithm is a logical process by which a problem can be solved or a decision made. An
algorithm can be represented in a programming language, but it is more abstract than that. For instance,

p
iled, or
p
ublished, into a new file. This com
p
iled file is what users will see, not the source itself. In Flash,
the source is a .fla (or FLA) file, and its published version is a .swf (or SWF) file. The .swf file contains only a
fraction of the information of in the .fla file. This serves to protect the author's work so that another person
cannot take the source. This book's accompanying CD-ROM contains the source for many games.
Turn-based— This refers to a restriction on when you, the game player, can make a move. For instance,
is a turn-based game; rather than make a move whenever you want, you must wait for your turn. Many
multiplayer games are set up this way, as we will see later in the book.
Vector graphics— Notable for their small file sizes and scalability, vector graphics are defined by sets of
mathematical points. Flash uses this graphics format to great advantage.
World— The environment of the game.
I l
@ve RuBoard

I l
@ve RuBoard

Game Genres
A
game genre is a type or category of game. As with movies, there are many game genres, and they are
hard to classify. Some games may fit in more than one genre. Here's a list of the most popular genres.
Action— An action game has moving objects and focuses on your timing, reflexes, hand-eye coordination,
quick thinking to achieve a good score. Most games have some action in them but aren't necessarily
"action games." Space Invaders and Half-Life are good examples of action games.
Adventure— Often confused with RPGs, adventure games let you control a character in an environment
the story is discovered. Unlike what happens in an RPG, your actions do not affect your character's overall

g
ames, your
g
oal is to successfully build and run a city; in others, what you
have to build or run can be anything from an army to a roller coaster.
I l
@ve RuBoard

I l
@ve RuBoard

Flash Limitations
Like all software applications, Flash games have limitations. Macromedia has added an amazing number of
features and capabilities to Flash with each release, but it can't do everything (yet). In this section I'll talk
about the major advantages and disadvantages of using Flash to develop games, as well as discuss certain
types of games that are not easily workable in Flash.
Flash vs. Non-Flash Games
While I'd like to tell you that Flash can outperform all other game-development platforms with its hands tied
behind its back, that's
j
ust not the case. There are man
y
reasons to choose Flash for
g
ame develo
p
ment, and
there are many other reasons not to choose Flash. In this section we discuss the major reasons for both.
The pros of using Flash for game development
Not surprisingly, as I've put a lot of time and effort into Flash game development, I'll list the benefits first.

people can view such content without being forced to download the plug-in in addition to the game.
Lack of 3D support— Flash doesn't provide native support for real 3D engines or for any sort of texture
mapping (the act of applying an image to a 3D polygon).
Lack of operating-system integration— When you run your game as a Projector file, Flash cannot easily
talk to the local operating system to do things like browse files on the hard drive. (But this type of
possible with the use of third-party software such as Northern Codeworks' SWF Studio, available at

.)
Most of the developers who choose Flash as their game-creation tool do so because they want their games
be available to many people easily on the Internet. If the intention is to have the game available offline on
ROM, then Flash is still a choice—just not necessarily the best choice.

Infeasible Game Features
It is much easier to talk about things Flash cannot do easily than to discuss everything it
can do. Here I'll
on some things that are very difficult to achieve in Flash, or that aren't feasible for another reason. I don't
to say anything is impossible with Flash, because there are so many creative people out there with dozens
tricks to make the seemingly impossible possible.
3D rendering with texture mapping
Many people have created 3D engines with ActionScript. A 3D engine is code that can take 3D coordinates
map them onto your screen. While these engines actually manipulate coordinates in 3D space and then map
them correctly back onto a 2D screen, there are three major limitations:
Texture mapping— You cannot map textures (bitmap images) onto an object in Flash. As I have already
mentioned, many people make creative attempts to get around program obstacles. This is one of them.
people have successfully done very simple mapping onto flat surfaces. Nevertheless, this is a limitation.
Mapping is not achieved easily and only works in some conditions.
Z-sorting— This refers to the order in which objects appear in front of other objects. In real 3D rendering
games, the sorting order is not limited to whole objects, but can actually pierce surfaces of objects (if two
things happen to be moving through each other). Flash is limited to sorting at the movie-clip level.
Speed— Three-dimensional engines written in Flash can typically handle only simple shapes, and they retain


I l
@ve RuBoard

Points to Remembe
r

z
Flash is a powerful authoring tool that can help you create games from the simple to the extremely
complex.
z
Flash's strengths and limitations make it ideal for creating some kinds of games and less than optimal
for others.
z
ActionScript—the programming language used in Flash—is going to be the main tool through which
bring your games to fruition. z
Familiarizing yourself with game genres and terminology is a good first step toward deciding what
and levels, of games interest you as a developer—and will also show you where you need to brush up!
z
For reasons of portability, extensibility, integration, file size, and near-universal access, Flash is a
g
ood
choice for games you'd like to make available on the Internet.
z
Flash is easy enough to learn that you can be up and creating games in a very short time.
z
A high cost of the small file sizes and accessibility of Flash games is their slow performance relative to

secret. A plan will help you identify possible problems ahead of time and anticipate steps for avoidin
g
or
solving them before they ever come up.
In this chapter we'll discuss one game-desi
g
n process that can help you structure your ideas and build your
game intelligently and efficiently. This simple design process will help you plan for every part of the game.
course, I don't claim that this is the only way things should be done—there are many equally effective
processes out there. This just happens to be the one that works best for me!)
I use the word
design here to encompass everything about your plan, including your
idea, your code, the graphical elements of your game— the whole works.
I l
@ve RuBoard

I l
@ve RuBoard

The Design Process
All the tasks involved in creating a game can be organized within the steps of the seven-step program I'm
about to lay out for you. You'll soon see why: These top-level, quantifiable steps will be relevant to any sort
game. We'll illustrate the steps with the recognizable example of a game of 8-ball (pool). And now, here is
process.
1.
Find an idea.
2.
Identify your audience, and modify your idea to fit it.
3.
Decide on the look and feel of your game.

Player one chooses either balls 1 through 7 or 9 through 15 for his or her own; the other set goes to
other player. The 8 ball belongs to neither.
If you choose to have an alternate method or rule for dealing with some facet of your game, make
to spell that out, too. In our example of pool, there's a widespread alternate way to assign stripes or
solids—the first player to sink a ball "owns" that style of ball.
z
Each
p
la
y
er takes turns knockin
g
the cue ball into his or her own
p
ool balls to send them into a
p
ocket.
This is typically done one by one.
z
When a
p
la
y
er has knocked all of his numbered balls into the
p
ockets, he then attem
p
ts to knock the 8
ball into a pocket. If the player succeeds, he wins the game.
z

game rules. Writing out all the rules of the game gives you something concrete to refer to later, when you're
writin
g
the ActionScri
p
t. Even if the rules are relativel
y
sim
p
le, a
q
uick, linear reference will
p
robabl
y
hel
p

y
ou
organize your ActionScript more easily. And then, of course, with new and more complicated games, it may
difficult to remember every single rule.
Identify Your Audience
Who's going to play? This is one of the most important things to remember when designing a game. If you
designing for a specific purpose, you should use that information to help identify your audience. For many of
you, your audience may be just yourself—in which case, luck
y

y
ou,

a
g
ame for
y
our own Web site, make sure
you have a good idea of the type of visitors you receive or the types of visitors you are trying to attract.
Decide on a Look and Feel
You probably know that the term
look and feel is widely used when describing the creative side of a software
application.
Look refers to the game's overall graphical style, color usage, and animations. Feel refers to the
usability, as well as the parts of the game that can affect the user on emotional or tactile levels, including
and sounds. But the look itself can contribute to the feel as well.
Decidin
g
on a look and feel for your
g
ame should, of course, be related to the intended audience. You don't
want to create dark,
g
othic
g
raphics for a
g
ame that will end up on a children's site. Likewise, you probably
wouldn't want to have heavy-metal music playing in the background for a game intended to appeal to
executives.
If you are unsure of what would be a good look and feel for your game, check out other games targeted to
audience. Note behaviors and operations that you think work particularly well. Studying those games
RPGs are like the lure of the Sirens

our
g
ame, which will hel
p

y
ou see how well
y
ou hit the
mark.)
Identify Your Weaknesses
In this step of the process you look at the rules of your game and list all the gaming concepts, knowledge,
other skills you need in order to complete the game. This is not the place for bluffing! Identify the areas that
you know you cannot complete by yourself. With this information you can then find a way to fulfill each of
requirements where your existing knowledge isn't enough. Some of the steps you'll need to take will require
research; others may require asking for help.
Let's list the major things needed to create the game of 8-ball.
In
Table 2.1, the first column contains a list of the requirements for creating a game of multiplayer 8-ball.
second column is where you indicate if you can meet that need. In this table, I have filled in the second
as a typical beginning game designer might.
Table 2.2 contains information on how to satisfy each of these
requirements.
Table 2.1. Knowledge and Assets Checklist
Need Do I meet this
need?
A copy of Macromedia Flash Yes
Proficiency with ActionScript Yes
The ability to calculate collision detection No
The ability to code realistic billiard-ball collision reactions No

multiuser gaming
Read
Appendix B,"Multiuser Servers," and all of the
game chapters in
Part 3 that deal with multiplayer games.
Access to sounds
that are needed for
an 8-ball game, or
Find someone who can create the sounds for you, or
download software such as Syntrillium Software's Cool
(
www.cooledit.com) to help you record and edit your own
In this step the main objective is for you to identify all elements of the game that you do not have the
resources to develop. One of the best things you can do to learn more and get help (other than read this
of course) is to ask other people for advice on the boards at popular Flash resource sites (see
Appendix E).
As a new game programmer, you will probably encounter many things you do not know how to do. It's a
idea, as part of your quest to learn these things, to create several tests of each concept to make sure that
know how they all work. For instance, with the 8-ball game, you might want to start testing collision
with just two circles. Then, when you understand this level of collision detection, try it with multiple circles.
Only when you are confident that you fully understand how to use collision detection with the needed
of spheres should you move on to testing collision reactions.
Anything on your list that you will not be able to satisfy, or that you can't find someone to help you with, is
subject to being cut from your game. The next step addresses this.
Cut Back
In this step you decide if any features or game rules need to be changed or cut. If you could not meet any
of the requirements in the previous step, then you should consider cutting that feature. Following are some
grounds for cutting a feature from your game:
z
Not being able to meet all the needs specified in the previous step.

good idea to find someone to help you. You can find
skilled in graphic design on the boards at Flash Kit
(
www.flashkit.com).
It's im
p
ortant to understand how these thin
g
s reall
y
work. If
y
ou are
j
ust co
py
in
g
and
pasting code from examples in this book or from another resource without fully
understanding the concept, you're going to have trouble later when you're trying to
work through any bugs that crop up.
Don't have a dedicated server? Don't worry!
In
Appendix B,"Multiuser Servers," we briefly explore options for people who do not have a server
with which to host the multiuser software. For example, you may be able to host a simple
g
ame
from your own home computer!