Want to thank me for making this book available for free? Just buy Special Edition Using Macromedia Director MX and we'll call it even!

Advanced Lingo For Games
by Gary Rosenzweig

Chapter 8 Section 2

In this game, there are two different types of objects. The first is the one under the player's control. This object, which is represented by as a baseball glove in the example movie, is used to catch the falling objects. The player can move this object from left to right across the bottom of the screen.

The other type of object is the one that falls from the top of the screen. We must allow for one or more of these to be falling at one time. We also have to take into account the fact that some objects are desirable, while others are not.

For instance, in our sample game, the objects falling are going to be objects from the world of sports: baseballs, footballs, basketballs, and so on. The object of this particular version of the game is to catch the baseballs, but to avoid the other objects. Figure 8.1 shows this game in action.

Figure 8.1

The falling objects game uses objects from different sports.

As always, there are a lot of different techniques that need to be considered before the programming begins. The most important of which is to determine what code is needed.

Many Behaviors or One?

When designing the code for this game, it is tempting to write a behavior for the glove and a behavior to be used for the falling objects. This makes sense at first, until you think about the fact that all items are closely related to each other and need to be in constant communication.

For instance, the game needs to know when to drop new objects. At the start of the game, approximately one object at a time should drop, but then the frequency should increase as the player scores more points. In addition, as each item is dropped, it needs to be assigned a sprite, and that sprite needs to use a member. This needs to be a sprite that is not already in use. The messaging between sprites gets to be more and more complex with the addition of other features as well. The result is that it is actually better to create one game behavior that gets assigned to the frame, rather than a behavior that gets assigned to each and every sprite.

This frame behavior keeps track of all sprites and the general game properties. This also makes the game easy to set up after the behavior is complete.

Timing Drops

A game like this definitely needs to get harder as the player does better. We can do this one of two ways, or both. First, we can increase the speed at which items drop. Second, we can increase the frequency of drops.

At the start of the game, the frequency of drops should be at about the right speed so that there is one item falling at any given time. Then, as the user racks up points, the frequency increases. Soon, the screen is filled with many items at once.

Defining a Catch

In this game it's important to define when a catch occurs. Is it when the rectangles of the object and the glove intersect? Is it when the location of the object enters the rectangle of the glove? We will offer both of these options.

In addition, we will offer the option of defining a catch as when the rectangle of the object contains the registration point of the glove. This is useful if the objects are going to be much bigger than the glove. This option will be a parameter that you will set when you drop the behavior onto the Score.

We will also have two purely mathematical ways of determining if there is a catch. The first uses the horizontal and vertical location of the object and the glove. If both of these measurements are within a certain amount, a catch is made. The other method uses the distance calculated with the standard mathematical equation.

These last two distance methods allow us to determine a catch has been made irrelevant to the size of the two sprites involved.

Game Over Options

There are three ways in which our example game can end. The first happens when the player misses a certain number of items that he or she is supposed to catch.

The second option is to count the number of times the player catches an item that he or she is not supposed to. When this count gets too high, the game is over.

A third option is not nearly as useful, but is still included. This game over option simply waits for the player to attain a certain score.

Although I have not added the ability to combine the options in the example game, the code can easily be adapted to that. In one scenario, you may want to have the game end and go to a "you lose" frame if the player misses a certain number of objects. The same game would go to a "you win" frame if the player attains a certain score.

Penalty for Bad Catches

If there are some objects that the player is supposed to catch, and others that the player is supposed to avoid, what happens in the latter case? If a player catches a bad object, they should obviously not be awarded points. But, should they be penalized?

If you have the game set to end when the user catches a certain number of bad items, then they are already penalized for this. However, if the game ends because of another condition, you might want to also subtract points from the user's score when they catch a bad item.

Increasing Difficulty

A game like this should start off easy, and get more and more difficult as time goes on. We can do this simply by increasing the frequency of falling objects.

This can be done over time, or a little each time the player adds to the score. We'll use the latter in this example.

Distinguishing Good Objects from Bad

The member from each object is chosen at random each time. Sometimes the falling object will be a good one, meaning that the player should catch it. Sometimes the object will be a bad one, meaning that the player should avoid it.

A simple method of determining which items are good and which are bad is to use the member names. We'll just name the bitmaps that represent good objects "good" and the bad objects "bad." When a catch is made, the member name is examined to determine which one it is.

Special Effects

We're going to include more sounds than usual in this game. We want a sound when a play catches an object. There should be one for catching a good object, and one for catching a bad object. There should also be a sound for when the object first falls from the sky.

A fourth sound would be used to represent when a good object has fallen to the ground, thus being missed by the player.

All these sounds are optional, as in earlier chapters.