Writing Lingo Scripts for Macromedia Director MX

This chapter is from the book

Special Edition Using Macromedia Director MX

Learn More Buy

This chapter is from the book

This chapter is from the book 

Special Edition Using Macromedia Director MX

Learn More Buy

Writing Lingo Code

There are many ways to go about creating a Director movie with Lingo. Over time, you will adopt your own method.

For instance, some programmers create one movie script member to hold all their movie handlers. Others break them up into several script members by category. Some people even create one script member per handler.

If you do a lot of programming, you will find that your style adjusts over time. There is no right or wrong way to go about doing it. However, some basic programming guidelines can help you get started.

The Lingo Programmer

Lingo programmers are really of two types. The first type is someone who has a background in computer science or engineering. These programmers probably know languages such as C or Pascal, and took courses such as "Data Structures" and "Linear Algebra" in college.

The second type is far more common. This is the graphic artist or multimedia producer. These programmers may have used presentation tools before, even Director, but have never used a programming language before. They have explored the basic range of Director and want to go beyond the basics. They are now ready to start learning Lingo.

For both types of programmers, starting to learn Lingo can be difficult. For experienced programmers, Lingo takes care of much of the tedious work that they were used to in the past, but gives them control over graphics elements and the user interface. For graphic artists, Lingo can seem like lines and lines of text that stand between them and their end products.

The important point to remember is that programming is an art. Programming languages, such as Lingo, provide a wide canvas for programmers to express themselves. Two programmers given the same task are almost certain to write two different programs. Each one shows the programmer's own style.

For experienced programmers, this means that programming in Lingo provides another type of canvas on which they can create. As an experienced programmer myself, I will even venture to say that Lingo will enable them to be more creative than before.

For graphic artists, this means that Lingo is a new brush with which they can paint. I know many artists who have become Lingo programmers and used it as a way to create the art they envision.

Programming as Problem Solving

Programming is just problem solving. If you want to make a Director movie, think of it as a problem. Your goal is to find a solution.

As with all problems, more than one step is usually needed to solve the problem. You have to examine the problem, take it apart, and find out what you know and what you don't. Then, you need to come up with a plan for solving it.

To solve a programming problem, first define it. What, exactly, do you want to have happen? Saying "I want to animate a sprite" is not a well-defined problem. Saying "I want to move a sprite from the left side of the Stage to the right side" is better. What you really should be going for is something like "I want to move a sprite from position 50,200 to position 550,200 over the period of 5 seconds at the rate of 10fps."

After a problem has been defined, you can start to see how it can be solved. Imagine that your goal is to move a sprite 500 pixels in 5 seconds at 10fps. At 10fps, 5 seconds will be 50 frame loops. So, you want to move the sprite 10 pixels per frame loop.

Only by clearly defining the problem can you start to envision a solution.

Solving Smaller Problems

The key to writing a program in any language is being able to break it down. You start off with a large concept, such as "A quiz that teaches children about geography." That's a fairly tall order. You can bet that Lingo has no quizKidsOnGeography command.

So, you break it into smaller parts. Maybe you want to have each question of the quiz show a map of the world with one country lit up. Then, three choices are presented as to what the country might be. So, now forget about the whole program and start to concentrate on just asking one question.

But this part is also too big to tackle all at once. However, it has smaller parts. How does the map display a country? How do the three choices appear? How do you make sure one of the three choices is correct?

A very small part of this might be just having a Lingo program that selects a random country out of a list of 100 names. Now that you have broken the problem down this far, you might begin to program. The result is a handler that selects a random country and outputs it to the Message panel. You build it and test it and you've solved your first small problem.

Then, you continue to identify and solve other small problems in this way. Before you know it, you have a working program.

The concept of breaking big problems into smaller ones is the most important aspect of programming. If you ever get stuck while programming in Lingo, it is likely to be because you have not broken the problem down into small enough pieces. Take a step back from what you are doing and decide how you can break it down before continuing.

Many Ways to Do Things

The first thing to realize about programming in just about any language is that there are usually many ways to accomplish the same task. This is particularly true of Lingo.

For instance, suppose you want the movie to loop on the current labeled frame. You could use a go to the frame command in an on exitFrame handler. Or you could use go loop. Or, you could use go marker(0). All of these will work. They have differences when used in other situations, but for a single labeled frame, they will all behave exactly the same way.

So why use one method over the other? You might choose one method because you use it more often, so you want to be consistent. You might choose one because you are using that same method elsewhere, where the slight differences in the commands will bring about different behavior. Or, you might just like how one sounds.

In some cases, one solution is more elegant than another. For instance, there are several ways to change the volume of a sound. One method changes the volume setting for the entire movie, not just that one sound. So you may find that advantageous in some cases and a problem in others. In some cases, that technique is not compatible with certain sound cards. So you fall back on another technique which will work better in your situation.

Calling one of these methods the "right" method is subjective. So don't worry too much if you are doing things the "right" way, as there may be no such thing. Instead, work toward getting your program to correctly solve the problem.

Setting Up Your Script Members

If you are creating a small Shockwave movie or projector, a useful way to organize your scripts is to have one movie script member and several behavior members.

In fact, you might not need to have any movie scripts at all. Well-written behaviors can eliminate the need for movie scripts.

If your movie requires mostly buttons, some behavior scripts can handle it all. Each behavior can be attached to a button and tell the movie what to do when it is clicked.

A larger Lingo project might require a few movie scripts. Movie scripts are needed for items placed in the on startMovie handler, for instance, where commands need to be executed when the movie is initially run.

Movie scripts can also hold handlers that are used by more than one behavior. If you want various behaviors to play a random sound, for instance, you might want them all to call your on playRandomSound handler that is stored in a movie script member. This saves you from having to include a similar handler in many different behavior scripts.

It is always a good idea to keep movie scripts together in the Cast. The same goes for behaviors. There are exceptions, of course. Sometimes, you might want to place behaviors near the bitmap members that they usually control.

Commenting Your Code

Director is equipped with an automatic script color function. This function color-codes different types of words in your scripts. For instance, Lingo keywords are blue and comments are red. The goal is to make it easier for you to read. You can also turn this function off in the Script Preferences dialog box. If you do, you can use the Text Inspector to color and style your code manually.

The most important task to complete when writing code is to remember to add comments. Comments are words, phrases, and even sentences that you can sprinkle throughout your code to help clarify what the code is doing. You can place comments on a new line, or at the end of a line of code. Use a double dash to tell Director that everything after it is a comment and should be ignored when the Lingo runs. Here is an example:

-- This handler outputs powers of 2 to the Message panel
on powersOfTwo
 n = 2 -- start with 2
 repeat with i = 1 to 100 -- output 100 numbers
 put n -- send to the Message panel
 n = n*2 -- multiply by 2 to get the next number
 end repeat
end

Now compare that with the same exact handler that is not commented:

on powersOfTwo
 n = 2
 repeat with i = 1 to 100
 put n
 n = n*2
 end repeat
end

The first can be understood immediately. If you wrote the second one, and then saved the file and came back to it a year later, would you be able to remember what it did immediately? Now imagine a 100-line handler that picks random geography quiz questions and modifies a map on the Stage.

Use Descriptive Names and Comments

In addition to straightforward commenting, you can also accomplish a lot by using sensible names for handlers and variables. You could name a handler on convTemp, for instance, but it would be better if it were named on convertTemperature. You could have variables in it called f and c, but it would be much more readable code if they were named fahrenheitTemp and centigradeTemp.

Because you can use long variable names in Lingo, take advantage of it to make your code more readable. Because you can copy, cut, and paste in the Script panel, there's really no reason to use short, one-character names.

Using colors, styles, comments, and realistic handler and variable names will save you time and frustration. Get used to using them now, from the beginning, and your work will go much more smoothly.

Write Re-usable Code

While writing your code, there will be times when you find yourself solving the same problems again and again. For instance, you may have a game where sprites are always trying to determine how far they are from other sprites.

To solve this problem, you will need to write some code that takes the locations of the two sprites and return the distance between them. If you need to do this in several places in your code, you might be tempted to use copy and paste to duplicate that code everywhere it is needed. Saves typing, right?

But there is a better way. You can instead develop your own custom handler that takes two sprites as input and returns the distance. Then, in every spot where you need to perform this task, just call this function that you created.

You can take this a step further by creating a whole library of functions that you find useful in your current project and grouping them together. You might even find them useful for your next project.