Note About This Book: Advanced Lingo For Games was written by Gary Rosenzweig in 2000 for users of Macromedia Director 7. It is presented here for free on an as-is basis, with no updating. Most of the information and code here can be used in the most recent version of Director. The book has been reproduced from the final editing files archived in 2000, and not the final proof galleys. So some minor differences between this version and the printed version my exist. The entire contents of this book are Copyright 2000, Gary Rosenzweig. No part may be reproduced or copied without written permission. The text here is provided for individual use only.

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 1 Section 3

Making Games

Each time I create a game I use a slightly different process. However, I often get asked how it is done. So, I will suggest a method of creating games, but this is by no means that only way to go about it.

I use a variety of factors to determine how I will create a game. I take into account the type of game, its complexity, and the amount of time I have to create it. Sometimes I choose one method over another simply because I feel like a change of pace, or I wish to experiment with different styles of programming.

Game Screens

It is sometimes useful to have a checklist of things that need to be done to make a product. Games vary greatly in what they include, but there are some elements of games that keep reappearing. Think of these elements before planning your game. All of them are optional, however.

The Introduction Screen--This is usually simply the screen that has the a button that reads something like "click to begin". However, you can color this screen up with graphics and text to get the user in the mood to play. Figure 1.2 shows one of my favorite game introduction screens.

Figure 1.2

The introduction screen to "The Peanut Butter and Jelly Wars" game. This game is just a simple Reversi game. However, the introduction screen proposes a metaphor to the player.

The Instruction Screen--Some game developers, myself among them, argue that you should try to make your game so easy to play, that instructions are not necessary. However, even when you are successful at that, you should provide an instruction page simply because some people will appreciate it. Figure 1.3 shows a sample instruction screen.

Figure 1.3

Here is an example of an instruction screen. This one uses a little humor, based on the fact that objects in arcade games don't always have real names, to lighten up the game a bit.

The Backstory Screen--While an introduction screen may suggest a metaphor for the game, a backstory screen is more direct. It tells the player, with text or narration, what has happened to bring them to this point. It could be as simple as "you have entered a race" or "prepare to play in the U.S. Open". It can also be as complex as a story involving an alien invasion that you are the last line of defense against.

The Game Background--The screen where the action takes place can also have a lot of other elements. Will there be a "score" field? How about "level" or rank"? Sometimes there is a summary of which keys do what. You will also want to add graphics that continue to suggest a theme introduced in the previous screens. For instance, in my game "Meltdown," the background image, seen in Figure 1.4, suggests an industrial machine of some sort. The music soundtrack carries that even further.

Figure 1.4

Here is an example of a game background screen. The industrial theme of "Meltdown" turns a simple puzzle game into a deeper experience.

Between Levels Screen--If your game has levels, you might want to add a screen that appears between each level. This gives users a break, and lets them ready themselves for the next level. For instance, in a space invaders game, it could simply say "Ready for level 4". In a golf game, it could recap the score and show a preview of the next hole. Figure 1.5 shows an example.

Figure 1.5

This example of a "between levels screen" is from my game Rapid Fire.

End Game Screen--When the game is over, you can recap the score and ask if the user wants to play again. You can also place a button that takes them to a high score screen. Figure 1.6 shows an example.

Figure 1.6

The "end game" screen for my game Bomb Squad. This also allows the player to submit a high score to the Internet.

High Score Screen--This screen allows the user to enter her name and then saves the score to a high score board. It could be a local high score board, only recording scores played on that computer, or an Internet high score board where players compete from around the world. You could combine this screen and the end game screen into one, as shown previously in Figure 1.6.

High Score Display Screen--This can be at the start or end of a game. It displays the high scores in a list, just like the classic game machines did. This could give the players incentive at the start of the game, or simply let them compare their score at the end of the game. Figure 1.7 shows an example.

Figure 1.7

The "high score display" screen for my game Aztec Underworld.

Payoff Screen--Another version of the end game screen is the payoff screen. This screen rewards the player for completing the game. You usually do this for games where there is no score other than winning. Or, you could use a payoff screen as a reward for reaching a certain score by the end of the game. Deciding what to include on a payoff screen is sometimes tougher than making the game itself. Most developers who use the payoff screen usually end up creating an animation of some sort. Or, you can make the payoff real by linking to a prize on the Internet, such as a coupon or a sweepstakes entry.

Planning and Preparation

The first step in developing any game is to come up with an idea. Sometimes this is a totally new idea. But, more often, the idea has some roots in a previously made game. Maybe you are out to remake an arcade classic. Or, maybe you want to translate a non-computer game.

Either way, you want to define the game as well as you can. What elements are involved? What are the rules by which the elements move or change? What is the goal of the game?

For instance, in a game like Asteroids, you would determine that the game elements are a spaceship, some asteroids, and a flying saucer. The rules are that the ship can rotate, thrust and fire shots. The asteroids move around and break apart when they are hit. The flying saucer moves around, fires shots, and explodes when hit. The goal is simply to get a good score.

These are the basic rules of an Asteroids game. Of course, there are more details to be worked out, which you work out if you were actually planning to make the game.

The next step is to determine how the user will interact with the game. A key choice is whether to use the mouse, keyboard, or both. Then you need to determine what the mouse button, mouse movement, or certain keys will do.

After this, you can begin to plan out your Cast and Lingo code. What sort of behaviors will you use? How many cast members are needed? How will all the elements interact.

There are usually many answers to these questions. You can't necessarily determine that one way is right and another wrong. Ten Lingo programmers will probably create a certain game ten different ways.

It's important that you think about your method, however. Try to make a plan. Make a list of which cast members you will need and which scripts you will need to create.

All this planning, however, can't predict the problems that might arise while creating the game. Be prepared to make changes as you go.

Where to Start

Now that all your planning is done, it's time to get down to programming. Just as with planning, there is no one right way to go about doing it. Here are some suggestions, however.

You could start by gathering all your media together. You make, or get someone else to make, the bitmaps, sounds, and other elements. Then, you gather all this together in the Cast before doing any programming.

You could also jump right into the programming, and fill the media elements in as you go along. This works especially well if the programmer and artist or sound designer is a different person. Then you are all working in parallel.

You could also try to experiment with Lingo to see how you are going to accomplish your hardest tasks. I use this technique a lot. I determine which part of the game will be the most difficult, and I start writing the behaviors to handle it. I usually experiment with different methods to see which is faster, or seems more elegant.

Finishing the Game

During game development, some of the minor details are usually left out until the end. These are things like scoring, levels, high score boards, payoffs, congratulatory messages to the player, sound effects, background images, introduction screens, and instructions.

Oddly enough, these are often the most important elements of the game to the player. I have seen many Director-based games that have shown promise, but have suffered because the programmer simply did not finish the game by adding one or more of these elements.

After you get the game mechanics working, and you find that you can finally play your own game, remember to add these seemingly little touches. They can make the difference between a good game and a bad one.

Troubleshooting and Debugging

At the beginning of this chapter, I wrote about taking programming tasks on one step at a time. You need to apply the same principle to debugging your game.

Every programmer has to debug. Writing anything other than the shortest program will result in some issues arising before the program works perfectly.

When someone is trying to fix a bug in his program, I usually get asked: "What is wrong?" The only appropriate reply is "You tell me."

This is because no one is in a better position to fix a bug than the original programmer. You know the code because you wrote it. You probably have it right in front of you. The best way to kill the bug is to simply start investigating.

If your problem is a Director error message, use the Debug button in the error message dialog box to check out the values of the variables at this point in the program. You will often be able to spot which variable is not what it should be. Then chase the variable backward through your code to see what went wrong.

What most beginner programmers do not realize is that debugging is a slow process that cannot be avoided. Most of the calls for help that I get through email are simply cases of a beginner that sees trouble and panics. Don't panic, just take your time and debug.

User Testing

Bugs are not always as obvious as error messages or unexpected behavior. Sometimes, a game can work exactly as the programmer intended, but still have a bug in it.

This is because the game has not yet been tested by its audience. Only they can find bugs like usability problems and game inconsistencies. These need to be fixed just as much as error messages.

How you test and how much you test is up to you. Both extremes are bad: not testing enough so that the game is released with problems, or testing so much that the game never gets released at all.

You have to choose your method of testing and implement it. Here are some common techniques that I have used:

Alpha Testing--Alpha testing should really be conducted among employees of your company, or occasionally among friends and trusted acquaintances. This is a controlled way of testing, where you can give exact or difficult testing instructions and expect to be able to talk personally to anyone in the test. The object of alpha testing is to thresh out any major bugs or issues before anyone you don't know sees the product.

Beta Testing--This is usually the next step after alpha testing. The game is given to a number of people outside the company who are expected to report back on its performance. A private beta test is usually by invitation only. A public beta is done by simply posting the game on your Web site and requesting those that play it to report any problems. Often, beta test versions of games are programmed with an expiration date, so they don't continue to be used after the final game is released.

Live Testing--This is a technique I like to do with my Shockwave games, as long as the game is for one of my own sites, and not for a client. I simply do a round of alpha testing, and then release the game as version 1.0. Because the game only exists on the Web site anyway, it is easy to change and I can fix a bug and implement the change worldwide by simply uploading a new copy. The advantage of this type of testing is that it allows you to get a finished product up on your site quickly. However, it does not work well for CD-ROM delivery for obvious reasons.

Focus Group--Many companies like to bring in focus groups to look at a game and test it out while being observed. I don't like this technique because it usually does not involve enough people to give you valid results.

Fan Testing--This is sort of a cross between a private beta test and live testing. I do this quite often. CleverMedia has a newsletter that goes out on Thursday nights. We release new games on Fridays. So, we announce the game and give the link to it in the newsletter and let the subscribers play the game overnight, so if any bugs turn up that night and the next day, we can fix them quickly, or even postpone the launch of the game. CD-ROM game developers do something similar by giving preview versions of their games out to fan sites and magazines.

Distribution

After the game is complete, you need to get it to the people who want to play it. Rejoice in the fact that Director gives you more distribution options than the game engines used by the largest development companies.

Director movies are already cross-platform, which, in this case, means that they can be played on both Mac and Windows computers. If you are making a standalone application, called a Projector, you need to make a Mac Projector and a Windows Projector.

Projectors allow you to deliver games on CD-ROM or other hard media. You could also deliver a Projector over the Internet as a download.

If you are creating a game for Web delivery, your compressed Shockwave file will work on players with either type of computer.

Shockwave delivery is an extremely powerful feature of Director. You can't exactly make Quake III with Director, but you can reach millions of people over the Internet with almost no distribution cost.

Shockwave works with both Netscape Navigator and Microsoft Internet Explorer. It even works with other browsers that support the Netscape plug-in architecture.

In addition to the Projector and Shockwave delivery, there are also some variations. Director 7 and 8 allow you to make Shockwave projectors. These are small Projectors that use the Shockwave engine installed on the user's computer. If they do not have Shockwave installed, it allows the user to install it.

The best part about distributing your Director-based game is that you don't have to decide the format at all. You can create the game even if your distribution method has not yet been decided.

Before putting these techniques into practice, take a look at Chapter 2, "An Introduction to Games," to review the history of gaming and computer games, and see where Director fits in.

Advanced Lingo For Gamesby Gary Rosenzweig