Macromedia Flash™ MX Game Design Demystified: The Official Guide to Creating Games with Flash ppt

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

with the book and XML server software to facilitate multi
p
la
y
er
g
ames. If
y
ou're tired of the
g

• Table of Contents
• Examples
Macromedia® Flash™ MX Game Design Demystified:
The Official Guide to Creating Games with Flash
By Jobe Makar

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

• Table of Contents
• Examples
Macromedia® Flash™ MX Game Design Demystified:
The Official Guide to Creatin
g
Games with Flash
By Jobe Makar

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

Copyright

Acknowledgments

About the Contributors


Derek Baird


Eric Dolecki


Robert Firebaugh


Michael Grundvig


Introduction


Why Flash?

How to use this book


Part 1. Getting Started with Flash Game Design


Chapter 1. First Steps


Inspirational Kick-Start


Terminology


Game Genres


Flash Limitations


Points to Remember



Chapter 2. The Plan: From Idea to Design


The Design Process

Points to Remember



Part 2. Examining the Nuts and Bolts


Chapter 3. Trigonometry 101


Why Learn Trigonometry?


The Flash Coordinate System


Anatomy of a Triangle


The Pythagorean Theorem


The Heart of Trig


Vectors

Points to Remember



Chapter 4. Basic Physics


Introduction to Physics


Speed, Velocity, and Acceleration


Newton's Three Laws of Motion


Gravity


Friction


Points to Remember



Chapter 5. Collision Detection


What Is a Collision?

Detection Using hitTest()


Detection Using Math


Collision Detection with Advanced Shapes


Points to Remember



Chapter 6. Collision Reactions


Bouncing Off the Walls


Conservation of Momentum and Energy


Applying the Conservation Laws


Points to Remember

Chapter 7. Tile-Based Worlds


Introduction to Tiles


Top-Down Tile Creation and Management


Adding a Character to the World


Externalizing the World Data


Points to Remember



Chapter 8. The Isometric Worldview


Introduction to Isometrics


A Technical Look at Isometrics


Z-sorting

Deconstruction of a Simple World


Points to Remember



Chapter 9. Artificial Intelligence


Types of AI


Homegrown AI


The Perfect Maze


Pathfinding Algorithms


Points to Remember



Chapter 10. Using a High Score List

Administration of the High Score Lists


The List in Action


Points to Remember



Chapter 11. Graphics in Games


Taking a Graphic Approach

Stages of Graphic Development



Trouble-Free Techniques


Points to Remember



Chapter 12. The Sound of Games

Why Sound Is Important


Managing Sound Effects


Creating Sound Effects


Creating Music Loops


Points to Remember



Chapter 13. Dissecting a Chat


Introduction to the Chat


Hands-On Tour of the Chat


Points to Remember



Part 3. The Games

Chapter 14. Word Search


Game Overview


Game Logic


Points to Remember



Chapter 15. Ice World: A Platform Game


Game Overview


The XML and the Level Editor


Game Structure and Resource Files


Game Code

Possible Game Enhancements


Points to Remember



Chapter 16. Pinball


Game Overview


Game Code


Possible Game Enhancements


Points to Remember



Chapter 17. Tic-Tac-Toe: Your First Multiplayer Game


Game Overview


The Multiplayer Aspect

Game Code


Points to Remember



Chapter 18. 9-Ball


Game Overview


Multiplayer Aspects of the Game


Game Code


Possible Game Enhancements


Points to Remember



Chapter 19. Don't Fall!

Game Overview


Multiplayer Actions


Game Actions


Possible Game Enhancements


Points to Remember



Appendixes


Appendix A. Protecting Your Games


Theft and Antitheft


So You Found Your Game on Another Web Site?

Appendix B. Multiuser Servers


What Is a Socket Server?


Introducing ElectroServer



Appendix C. The ElectroServerAS Object


Click-and-Drag Actions


Methods and Properties of ElectroServerAS



Appendix D. XML Basics in Flash


Learning XML Basics


Using the XML Object


Introducing Socket Servers

Using the XML Socket Object



Appendix E. Developer Resources


General Game Resources


Flash Resource Sites


AI


Isometric


Math


Physics


Audio

Appendix F. Other Games


3D_race.fla


asteroids


cards.fla


foxandgeese.fla


fruit_smash.fla


invaders


iso_maze.fla


j
i
g
saw.fla

matching.fla


pacman


projectile_motion.fla


raiseTheBlocks.fla


robust_tracing


shared_object_highscore_list


ship.fla


shuffle_deck.fla


tic_tac_toe_ai.fla


tile_boat

Acknowledgments
Lookin
g
at the final draft of this book I can't hel
p
but be sur
p
rised and
p
roud of its
q
ualit
y
. What man
y

p
eo
p
le
don't realize is that a project of this magnitude can't be brought about by just one person. Actually, this book
is the combined effort of man
y

p
eo
p
le, some of whom have done as much work as the author himself, and all
of whom have brought their own brand of expertise to the task. So I have many people to thank:
Wendy Katz, for your amazing work. Thanks to your great edits, suggestions, and comments, my chapters

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
(

even thou
g
h the
y
can't read
)
, Free, Chance, Ha
y
es,
and Ross—you furry guys provide a frequent and welcome distraction. And finally, to Kelly, my amazing wife
and constant source of inspiration: thank you for being my toughest critic and yet my biggest supporter.

M





About the Contributors
I've alread
y
said that a book is not the work of a
j
ust one
p
erson. In the case of this book, four others hel
p
ed
actually get the material on the pages, and I want to recognize them specifically here.
I l

@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

A winner of numerous interactive awards, and with his work appearing in numerous publications, Eric seeks
help drive Flash in new directions.
Eric created all of the technical illustrations for this book.
I l
@ve RuBoard

I l
@ve RuBoard

Robert Firebaugh
www.electrotank.com
www.vectorkid.com

Robert Firebaugh, with over ten years of illustration and game design experience, is creative director and
founder of Electrotank, Inc. The games that he has designed have won numerous international awards and
have been acknowled
g
ed by many publications. In addition to his work with Electrotank, he runs a Web site
dedicated to photo-realistic vector artwork created in Flash.
Robert wrote
Chapter 11, "Graphics in Games."
I l
@ve RuBoard

I l
@ve RuBoard

Michael Grundvig
www.electrotank.com
Michael Grundvig is a co-founder of Electrotank Inc. He has co-authored and contributed to several books

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

terrain.
If you're new to Flash gaming, here you'll acquire the knowledge and techniques to build your own games
a good sense of the overall process and its pitfalls.
If you aren't new to gaming, you'll be able to see what you can do better (or worse) by using Flash, and
still come away with the knowledge and techniques necessary to build Flash games.
A book about games wouldn't make any sense without source material—would
y
ou rather learn how to create
platform game by hearing about it, or by playing through example files?—and this book is no exception. Each
chapter is accompanied by Flash movie files and sometimes other supporting format files to emphasize and
describe the point at hand, and allow you to see the function in action.
I welcome your input on this book; you can send me feedback at
I also encourage
to visit GameBook.net (
www.gamebook.net), the Web site for this book, for updates, innovations, and
inspiration.
I l
@ve RuBoard

I l
@ve RuBoard

Why Flash?
Macromedia Flash MX is many things to many people. In its few years on earth so far, it's been an animation
tool, a Web site creation program, an application development program, and now a game development
platform. In
Part 1 of this book you'll hear more about Flash's strengths and weaknesses in this area, and in
course of this book you'll be able to see some of the many things it can help you achieve.
System Requirements
Windows

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

amin
g
, its terminolo
g
y, and its basic
genres. The chapters in
Part 2 move through the important concepts that underlie the actual game creation.
While not exactly in linear succession, these chapters proceed from the most fundamental of gaming tools
(such as trigonometry) to the more complex topics such as collision reactions and the use of artificial
intelligence to add complexity and interaction to your games. In the latter portion of
Part 2 we introduce
chapters on enhancements such as fine-tuning graphics for your games, creating optimal soundtracks, and
using high score lists. We end
Part 2 with a chapter on understanding (and writing and modifying) an online
chat file, without which no online multiplayer game is possible. Wherever you start reading, we'll keep you
apprised of what you might need to refer to elsewhere to be sure you are getting the most out of the
In
Part 3 of the book, armed with the knowledge you've amassed in the several hundred pages leading up to
you'll work directly with complete games and see exactly what went into them. You'll even see ways you
improve them on your own!
Some of the appendices will guide you through a few complex topics that are intertwined with game design
development but which are, in fact, distinct topics with other applications as well.
We use the following icons to call attention to special sections:
This indicates a helpful suggestion—advice that will help you get the most out of the
subject at hand.
This means "Pay attention; important stuff here!"
Indicates that you should open a designated file from the CD to follow along with the
text.
Suggests another idea you might want to try in addition to the main point that's
made.

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

Chapter 1: First

Chapter 2: The Plan: From Idea to
I l
@ve RuBoard

I l
@ve RuBoard

Chapter 1. First Steps
Inspirational Kick-Start
Terminology

Game Genres

Flash Limitations

Points to Remember

So you want to make flash games? Well, this is a great starting place. If you're completely new to game
the whole idea can seem overwhelming. You may have a great idea for a game, but building an actual
from it is another whole story—setting up for multiple players, 3D motion, and so on. Don't worry—we've
that way. And we're here, after all, to demystify the process.
We'll proceed one step at a time. Before you jump in and start making games, I'll introduce you to some
general game-world concepts and terminology.
In this chapter, to orient you for your trip into game design, we will discuss the most common Flash game
genres, their terminology, and Flash's capabilities as a game-development environment.
I l
@ve RuBoard

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

y
ou don't need a de
g
ree in com
p
uter science to do it! You will learn how to ta
p

into the logic you already possess (common sense) and apply that with ActionScript (the programming
language used in Flash).
Pictured here are some of the games that you'll know—literally inside and out—when you're done reading this book.
9-BALL

WORD SEARCH

What kinds of games are possible in Flash? Take a look at some of the games that are dissected and
in detail in the third section of this book.
(
The source files for these
g
ames are
p
rovided on the accom
p
an
y
in
g

CD-ROM.) All of the information and techniques needed to make games like these are covered in this book.

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

g
ame view is sometimes referred to
the
point of view.
3D— This generic term encompasses almost all possible views of any game that is not two-dimensional.
Specific types of popular 3D views have their own terms (listed next). Almost all of the most popular store-
bought computer games (such as Unreal Tournament, at right) use a 3D view. While we will not be using a
generic 3D engine in this book, we will be using a specific 3D view,
isometric (see below).
Courtesy of Epic Games, Inc.

Chase— This type of 3D camera view is popular in some sports games, like hockey and football. The camera
(that is, what you see) follows the character or the action and may even swing around to get the best
This game view will not be used at all in this book.
First person— This view is what it would be like to see the environment from the character's point of view.
First- person-view games are very popular in shoot-'em-up games like Quake, Half-Life, and Unreal
Tournament. We will not use this view in any games in this book.
Isometric— This is one of the most widely used 3D views. You may have seen this view in games such as
Diablo (at right) or Electrotank's Mini Golf. It is used frequently because with this view you can get away
graphical tricks that reduce the work of both the programmer and the graphic artist. We will discuss this in
detail in
Chapter 8, "The Isometric Worldview."
Courtesy of Blizzard Entertainment
®


Side— This type of view lets you see what is happening from the sidelines. You may have seen this view in
g
ames such as Su
p

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,

can create a process to sort a list of names. This process is an algorithm and can be expressed with
ActionScript or any other programming language.
Artificial intelligence (AI)— This refers to an algorithm or set of algorithms that can make decisions in a
logical way. For example, the AI routine for a bad guy in a game might let him figure out how to find you.
Another use of AI is to have a maze or puzzle solved automatically.
Avatar— Sometimes chat rooms are designed to enable people in those rooms to have graphical
representations. These are called
avatars, and the chat is often referred to as an avatar-chat.
Collision detection— Also called hit detection, collision detection is the act of noting the intersection of two
ob
j
ects. This can be somethin
g
as simple as determinin
g
if the mouse is over a button or as complicated as
detecting the overlap of two moving objects.
Collision reaction— This is what happens after a collision has been detected. The term is usually used when
talking about physical reactions, such as two billiard balls colliding and moving apart, or a ball bouncing off
ground.
Console— A computer designed for the sole purpose of playing video games. Among the console
manufacturers are Nintendo and Sega.
Map— An area that defines the world of the game.
Real-time— Unlike turn-based games, in real-time games you can make a move whenever you like.
Render— To draw an object to the screen. This term is most often used in reference to 3D games: The 3D
engine calculates where a projectile should be, and then renders it.
Source code— Also known as source, source code is the original work created by a developer. Source code


com

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

abilities. Examples of adventure games range from Super Mario Brothers to the games in the King's Quest
series.
Casino— One of the most popular
g
enres to play on the Internet is casino (that is,
g
amblin
g
)
g
ames, such as
poker and roulette.
Educational— In an educational game, the goal is to educate the player. This game can also be a part of
another genre; for instance, you can have an educational puzzle game.
First-person shooter— This style of game lets you see a world through the character's eyes as you run
around and try to shoot anything that moves. Typically the action in these games takes precedence over
story.
Puzzle— A puzzle game, also called a logic game, challenges your mind more than your reflexes. Many
games are timed or limit the amount of time in which you can make a move. Games like Tetris and
are good examples of puzzle games. Puzzle games also include some classics like chess and checkers.
Sports— A sports game is an action game with rules that mimic those of a specific sport. For instance, NHL
2002, by Electronic Arts, is an ice hockey sports game.
Role-playing game (RPG)— An RPG is a game in which you, the game player, control a character in its
environment. In this environment you encounter other beings and interact with them. Depending on your
actions and choices, the character's attributes (such as fighting ability, magical powers, and agility)
and so may the story. Baldur's Gate is an RPG.
Strategy— This type of game focuses on your resourcefulness and deal-making ability as you try to build
and/or run somethin
g
. In some

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.

Web deployment— Since Flash files are designed to be viewed in Web pages, Flash is a good choice if you
want your game to be available on the Internet.
Small file size— Flash makes use of vector graphics and compressed sound files, so a Flash game's final file
size can be exponentially smaller than those of games developed on other platforms.
Plug-in penetration— The plug-in that's required for viewin
g
Flash files in a Web pa
g
e comes with all ma
j
or
browsers. More than 98 percent of people on the Internet worldwide can view Flash content. The exact
penetration for each version of the plug-in is listed on the Macromedia Web site (go to
www.macromedia.com/software/player_census
).
Server-side integration— Flash games can talk to the server seamlessly. Using Flash's built-in features,
can communicate with server-side applications that make chats, multiplayer games, and high score lists
possible.
File sharing between programmer and graphic artists/designers— With Flash, programmers and
artists can collaborate using the same files. This is rare in game development.
Ease of use— Perhaps one of the most attractive reasons for choosing Flash is that you can learn the
and start creating games in a very short time. With other languages, it could take years!
The cons of using Flash for game development
As I already mentioned, there are also some strong reasons for not choosing Flash as your development
platform. It's important to know them as well, before you get started and encounter unpleasant surprises.
Performance— Macromedia spent thousands of hours making the required Flash plug-in for the Web as
as possible so that the maximum number of people could download it easily. But that required some
and the major one was performance. Flash underperforms virtually all other game-development platforms
speed of code execution and graphics rendering. On the other side of the fence, game-development
like Macromedia Director and WildTangent perform very well—but have enormous plug-ins. As a result, few

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

frame rate close to the frame rate of your SWF. Complex scenes are often very CPU-intensive, and the
rate can suffer as a result.
Real-time multiplayer games
Creating this kind of game is certainly possible, but for many reasons it is not easy to accomplish. One of the
main factors is the nature of these games. Due to network latency, it would be very difficult, if even possible,
create a real-time multiplayer game like, say, Mortal Kombat. However, some real-time multiplayer games
lack interaction between
p
la
y
ers, such as a scaven
g
er hunt, mi
g
ht be more feasible. We will discuss this more
in
Chapter 17, "Tic-Tac-Toe: Your First Multiplayer Game."
Intense real-time calculation
I know this sounds like a vague limitation. But when you're creating a game, it is important (although
admittedly difficult) to think ahead and try to guess how intense the calculations are going to be. For
a game that has dozens of enemies—who all think for themselves and constantly run around trying to decide
what to do next—is an excellent candidate to bog down the computer processor! You'll have to do a lot of
testing and experimenting to determine exactly how many of these enemies the computer can handle and
perform well.
This chapter should provide you with a better idea of what types of games exist and which ones are possible
Flash. With this book you'll learn about all the pieces you need to build a game, from graphics to sound, and
you'll see how everything was put together in several finished games. By the end of the book you should be
well on your way to making your own gaming ideas a reality!
I l
@ve RuBoard

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

games created on virtually all other game-development platforms.
z
Flash is not a true 3D en
g
ine.
I l
@ve RuBoard

I l
@ve RuBoard

Chapter 2. The Plan: From Idea to Design
The Design Process
Points to Remember

If you are at all like me, then you may have at one time opened up Macromedia Flash and just started
a
g
ame. Maybe you had a va
g
ue idea of what you wanted the
g
ame to do, or maybe you made it up as you
went along. This shows that you have a strong creative side and are probably good at developing ideas—
is not a very good approach to designing a game. With this design-as-you-go approach, you are sure to
encounter problems. I have been in this situation before and always ended up wishing that I had planned
certain things in advance.
That's how I came to learn the hard way that you have to have a plan. Yes, tedious as it may seem, that's
bi
g

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.

4.
Identify what you do not know how to accomplish, and find the resources to help you
accomplish it.
5.
Cut back on game features where necessary.
6.
Build the game.
7.
Test your game for bugs and usability (quality assurance).
Looks pretty easy when it's just a list, right? Now let's talk about each of the parts of this process.
Find an Idea
This is probably the most fun step. Before building a game, you've got to come up with a concept. If you're
to game design, it's very important that you start with a simple idea. Starting with a complex game, it's easy
get frustrated or lose hope.
When you get your idea solidified, map it out step-by-step, as if you were explaining it on an instruction
in a commercial game. Make sure that the game has an objective.
The Idea: Multiplayer 8-ball.
The Object: To knock the cue ball into the player's own set of pool balls (solid or striped) to send them into
pocket.
The Rules:
z
The game of 8-ball is played on a pool table with six pockets.
z
There are 16 balls (numbered 1 through 15, plus the white cue ball). Balls 1 through 8 are each a
different solid color. Balls 9 through 15 are each marked with a different-colored stripe.
z
This is a two-player, turn-based, multiplayer game.
z
Player one uses a cue stick to hit the cue ball into a triangular configuration of the 15 balls.
z

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

If either player knocks the 8 ball into a pocket before he has finished sinking all of his numbered balls,
that player loses the game.
z
If the cue ball ever goes into a pocket, the player's turn ends.
z
If a player hits one of her numbered balls into a pocket without hitting the cue ball into a pocket, then
the player's turn continues; otherwise her turn ends.
So how do you know if your game idea is complex? That is hard to answer. If your list
for ste
p
4
(
"Identif
y
what
y
ou do not know how to accom
p
lish"
)
is ver
y
lon
g
, then
y
ou
may want to start with another game concept. In the beginning you may not know
to accomplish much at all, which is all the more reason to try to find a simple idea.
If 8-ball were your own original game idea, you would probably want to get into much more detail with the

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,

y
ou can
j
ust create an
y

g
ame that strikes
your interest! However, if you are designing a game for a client or for another purpose, then there is
an audience to whom your game should be tailored.
For instance, if you are making a game for a popular sugary breakfast cereal's Web site, then your audience
most likely young kids. A game of 8-ball is unlikely to hold their attention. If your original idea was for a
platform game, such as Super Mario Brothers, then you would probably want to modify this idea to use cute
characters and to have a simple objective. However, if it turns out that the cereal-eating age group is high
school students, then a somewhat more complex theme or objective for the platform game is more likely to
keep them interested.
Identifying your audience should not be a difficult task. If you are building a game for a company or client,
should be able to tell you who the intended audience is. If they say, "We would like this game to appeal to all
ages," then you are in a tough spot. It's difficult to design a game that will please everyone. In such a case,
you are probably better off taking (or looking for a minor new twist on) a tried-and-true idea that has alread
y

been shown to a
pp
eal to all a
g
es, like checkers. If
y
ou are buildin
g

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

If you are a novice game developer, do not be tempted by the lure of the role-playing game
A good RPG is a multiplayer game with a complex story; it loads in graphics dynamically, builds
screens d
y
namicall
y
, and makes use of
p
athfindin
g
, enem
y
AI, and thousands of screens. A
g
ame
with that kind of complexity—probably the most challenging type of game project you can take
on—would typically take you (and the rest of your team) several months to build. Over the last
years I have encountered many people who have brilliant game ideas for massive RPGs. I have
seen dozens of people and teams of developers start with an outstanding idea for a Flash RPG,
only one of them that I know of has finished.
How do you know if your game idea will appeal to a certain audience? This is a
question to answer. If your idea is not original or is very similar to some existing
games, then it would be in your best interest to use that game as an example. Find
if your target audience is interested in that sort of game. If your idea is unique, you'll
have to take the time to develop a simple prototype and try it out on your intended
audience to see if the response is what you expected. You can then make
and retest. There is no way to accurately predict who will like your game.
help you come up with good ideas for your own. (And during the final step, quality assurance, your test
audience will make comments on the look and feel of
y

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

Knowledge of multiuser gaming No
Access to sounds needed for an 8-ball game, or the ability
create such sounds
Yes
The ability to create all graphical elements needed for the
game
No
Table 2.2. Filling the Knowledge Gaps
Need Solution/Action
A copy of
Macromedia Flash
Install the 30-day trial version of Flash on the CD-ROM
comes with this book, or purchase Flash from
www.macromedia.com
.
Proficiency with
ActionScript
Learn ActionScript. You can buy a Flash book or read the
tutorials provided with Flash installation.
The ability to
calculate collision
detection
Read
Chapter 5, "Collision Detection."
The ability to code
realistic billiard-ball
collision reactors
Read
Chapter 6, "Collision Reactions."
Knowledge of

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.

z
Realizing (from your basic testing) that this feature would cause the game's performance to suffer.
z
A tight deadline will prevent you from finishing the game on time if you try to include all the features.
For example, one of the intended features of this 8-ball game is that it be multiplayer. In order to create a
multiplayer game, you need to set up a piece of software on a server that functions as the link between all
players. This is called a
multiuser server or a socket server (as will be explained in Appendix B,"Multiuser
Servers"). If you are runnin
g
your own dedicated server, you can, of course, install whatever you want. But
chances are that a regular, commercial ISP will not allow you to install software. So then you are left with
choice either to pay for a more expensive hosting plan (a dedicated server) or to axe this feature of the
If you cut the multiplayer feature but don't want your audience to have to play alone, then you may have
consider changing another feature. For instance, you might want to develop the game so that two people
are on the same computer can play against each other. Or if you have the time and inclination, you can
program an AI computer opponent.
Another potential problem is the Flash Player application's performance. While Flash is great for developing
games easily, one of its greatest limitations is the (lack of) speed at which it executes actions. In other
it is easy to give Flash too much to do on each frame, hence increasing the amount of time that Flash
the ability to create
the sounds
sounds. You can find sound effects on the Web at such
sites as
www.ultimatesoundarchive.com.
The ability to create
all graphical
elements needed
the game
If you are not skilled at creating graphics, it would be a

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!