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 of game. We'll illustrate the steps with the recognizable example of a game of 8-ball (pool). And now, here is the process.

Find an idea.
Identify your audience, and modify your idea to fit it.
Decide on the look and feel of your game.
Identify what you do not know how to accomplish, and find the resources to help you accomplish it.
Cut back on game features where necessary.
Build the game.
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 new to game design, it's very important that you start with a simple idea. Starting with a complex game, it's easy to get frustrated or lose hope.

So how do you know if your game idea is complex? That is hard to answer. If your list for step 4 ("Identify what you do not know how to accomplish") is very long, then you may want to start with another game concept. In the beginning you may not know how to accomplish much at all, which is all the more reason to try to find a simple idea.

When you get your idea solidified, map it out step-by-step, as if you were explaining it on an instruction sheet 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 a pocket.

The Rules:

The game of 8-ball is played on a pool table with six pockets.
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.
This is a two-player, turn-based, multiplayer game.
Player one uses a cue stick to hit the cue ball into a triangular configuration of the 15 balls.
Player one chooses either balls 1 through 7 or 9 through 15 for his or her own; the other set goes to the 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 sure 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.
Each player takes turns knocking the cue ball into his or her own pool balls to send them into a pocket. This is typically done one by one.
When a player has knocked all of his numbered balls into the pockets, he then attempts to knock the 8 ball into a pocket. If the player succeeds, he wins the game.
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.
If the cue ball ever goes into a pocket, the player's turn ends.
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.

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 writing the ActionScript. Even if the rules are relatively simple, a quick, linear reference will probably help you organize your ActionScript more easily. And then, of course, with new and more complicated games, it may be difficult to remember every single rule.

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 (RPG). A good RPG is a multiplayer game with a complex story; it loads in graphics dynamically, builds screens dynamically, and makes use of pathfinding, enemy AI, and thousands of screens. A game 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 few 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, and only one of them that I know of has finished.

Identify Your Audience

Who's going to play? This is one of the most important things to remember when designing a game. If you are 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, lucky you, you can just create any game that strikes your interest! However, if you are designing a game for a client or for another purpose, then there is probably 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 is 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, they 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 already been shown to appeal to all ages, like checkers. If you are building a game for your 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.

How do you know if your game idea will appeal to a certain audience? This is a difficult 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 out 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 modifications and retest. There is no way to accurately predict who will like your game.

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 story and sounds. But the look itself can contribute to the feel as well.

Deciding on a look and feel for your game should, of course, be related to the intended audience. You don't want to create dark, gothic graphics for a game 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 corporate executives.

If you are unsure of what would be a good look and feel for your game, check out other games targeted to your audience. Note behaviors and operations that you think work particularly well. Studying those games should 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 your game, which will help you see how well you 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, and 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 those 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. The second column is where you indicate if you can meet that need. In this table, I have filled in the second column 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 to 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 that 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 specific game chapters in Part 3 that deal with multiplayer games.
Access to sounds that are needed for an 8-ball game, or the ability to create the sounds	Find someone who can create the sounds for you, or download software such as Syntrillium Software's Cool Edit (www.cooledit.com) to help you record and edit your own sounds. You can find sound effects on the Web at such sites as www.ultimatesoundarchive.com.
The ability to create all graphical elements needed for 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 people skilled in graphic design on the boards at Flash Kit (www.flashkit.com).

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 book, 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 good idea, as part of your quest to learn these things, to create several tests of each concept to make sure that you know how they all work. For instance, with the 8-ball game, you might want to start testing collision detection 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 number of spheres should you move on to testing collision reactions.

It's important to understand how these things really work. If you are just copying 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.

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 one 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:

Not being able to meet all the needs specified in the previous step.
Realizing (from your basic testing) that this feature would cause the game's performance to suffer.
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 the players. This is called a multiuser server or a socket server (as will be explained in Appendix B,"Multiuser Servers"). If you are running 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 the choice either to pay for a more expensive hosting plan (a dedicated server) or to axe this feature of the game. If you cut the multiplayer feature but don't want your audience to have to play alone, then you may have to consider changing another feature. For instance, you might want to develop the game so that two people who 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.

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 game from your own home computer!

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 words, it is easy to give Flash too much to do on each frame, hence increasing the amount of time that Flash needs to stay on each frame, which makes the overall frame rate lower. In our 8-ball example, if you don't employ some very tricky or extremely optimized ActionScript, chances are good that the Flash Player will play at a reduced frame rate when calculating collision detection between the 16 balls and each of the six pockets (I know this from personal experience). That is a total of 216 collision-detection checks per frame. While the speed at which these actions execute is dependent on the Flash Player, it is equally dependent on the processor of the computer running the game. If you are using a Pentium 4 computer with a 2-GHz processor and the game barely runs smoothly for you, then you can bet it will not run very smoothly for people with average computers.

So what is the solution? You can spend days or weeks finding ways to optimize the ActionScript for speed or you can step back, take a deep breath, and cut down on the number of balls your game uses. The pool game called 9-ball uses only ten balls. That means it would only have to calculate 105 collision-detection checks per frame. While calculating this many checks may still be slow on some machines, it is less than half the number of checks for your original game of 8-ball. With some simple ActionScript optimizations you can cut this down even further. For instance, you might only check for pocket collisions when a ball collides with the wall. That would bring the detection down to 45 checks per frame.

The more time and effort you have invested in developing an idea, the more important that idea becomes to you, and so cutting back its features can be difficult. One of the best things about using a design process like this to plan ahead is that you can cut back on some features before spending the time to develop them and getting emotionally attached.

Build the Game

Now that you have an excellent idea of what your final game is supposed to do, you can focus on actually creating it. Strategies for how to build specific games are covered in Part 3 of this book. As there are many types of games, so there are many ways to approach putting them together. In the most generic sense, you will always:

Create or collect all of the game assets, such as graphics and sounds.
Build all of the major ActionScript functions needed for things like collision detection, collision reaction, and detection of the game rules (like whose turn it is).
Hook up everything together to form a game ready for testing.

Quality Assurance

In the quality-assurance (QA) stage of development, you take your working game and test it heavily. (Depending on who you work with and how irreverent you are, you may hear, or make up, more descriptive terms for putting your game through its paces, such as "beating the heck out of it" or "making it cry.") You are looking for bugs and usability issues. Typically during this stage you put your game in front of several people who have not been involved with its development, give them some general direction and requests, and let them have at it. It's amazing the number of bugs that someone unfamiliar with your game can find in a very short time. After your testers are finished playing your game, ask them questions like:

Were the instructions clear?
Did the game make sense?
Was the game fun?
Did it hold your attention?
What changes or enhancements would you suggest?
Did you notice any bugs? If so, what were they?
Did anything happen that kept you from finishing the game? If so, what was it?
How were the sounds and music (if any)?

If you don't receive comments on your sound, take that as a good sign! When integrated properly into the game, sound is something most people will not consciously notice. However, if it's done poorly, people will be aware of it and comment on it.

You can treat this process as formally or informally as you like; for example, you can give your testers an official questionnaire. This has the dual benefit of providing them with an easy way to quantify their information, and you with answers to consistent and specific questions. I've created a checklist (QA_checklist.pdf) that you'll find on the CD, in the Chapter02 folder.

Armed with answers to these questions, you can make well-informed decisions about how your game can be improved. You may find that you run through this QA process multiple times until you get the response you want from your testing group.

The primary reason for planning ahead and using a process is to make your work go more smoothly. Without proper planning, you may find yourself having to abandon some of your work (due to unforeseen problems) after investing time in it. Following the process discussed in this chapter, you will be able to take your game idea, break it into logical pieces, identify the possible problems before they occur and solve them, and then assemble the game.