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.
Looks pretty easy when it's just a list, right? Now let's talk about each of the parts of this process. Find an IdeaThis 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.
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:
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.
Identify Your AudienceWho'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.
Decide on a Look and FeelYou 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 WeaknessesIn 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.
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.
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 BackIn 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:
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.
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 GameNow 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:
Quality AssuranceIn 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:
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.
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. |