Information Technology: Controlling information in Director

November 9, 1999
by Danny Kodicek

Background

This article is about a slightly different way of perceiving the art of programming: as controlling the flow of information. What do I mean by information, here? Information is anything that can be accessed and controlled by a program. The concept might seem synonymous with data, but for me, information is meaningful data. To be concrete, the number 1 is a single piece of data, meaningless on its own. But if it is used as a marker to signify the boolean state of a property, it becomes information. When I describe programming as controlling information, I mean that it is the process of finding the meaning in intrinsically meaningless data.

What makes Director particularly special as a programming medium is that it provides an enormous number of ways of storing and controlling information. Pieces of information about Director entities, are instantly accessible and in most cases instantly controllable (I use the term entity, to denote autonomous things, in Director, the word object being already taken. An entity can be a cast member, sprite, list, variable, child object, etc.). What is more, the Director authoring environment makes it a straightforward affair to alter many of these pieces of information during development.

This way of looking at programming is in many ways the flip-side of conventional entity-based programming. Rather than seeing sprites and cast members as the primary focus, one considers instead the pieces of information that are changing and flowing, and the onscreen entities simply as carriers of this information. The end result is the same, but by considering first the informational content, it makes efficient coding far easier. In the rest of this article, I will be developing this concept; first by examining the intrinsic information of the Director environment, then by looking at the further potential created by variables, objects and encapsulation.

A simple example

Let's start by looking at the information contained in the simplest possible Director movie. We have a single sprite on the stage, in a single frame. The movie is set to loop, so we don't even have a frame script. But even in a small movie such as this, there are enormous amounts of information available to us, should we wish to use them. The cast member has a name, a member number, a castlib number and castlib name, as well as all its intrinsic properties (we shall look at the correlation between information and properties in a moment). As a sprite, it has a sprite number and a frame number, as well as a marker name should we choose to use it, a loc, a rect, and many other properties.

Beyond the entities we can see there are many more pieces of information behind the scenes. The platform, screen size, timer, freebytes and many other values are all available to us if we need them. Now when we start the actual coding, our job is to use these pieces of information appropriately to the task. Our dicta are these: Keep the information where it's relevant. Don't store information twice. Leave the information out there until you need it.

Using these concepts, how might we, for example, write a simple tooltip behaviour? Below there is a small movie with three main sprites and a text sprite that acts as a tooltip. Two of the sprites have an associated tooltip, the third does not. Incidentally, this is not a particularly sophisticated behaviour in terms of the display options. The tooltip merely appears at the mouseloc after a certain time rolled over the sprite. What I am interested in here is the question of how best to organise the primary piece of information: the tooltip text for each sprite.

The best way to do this is of course going to depend on other factors, such as whether any sprites contain duplicate instances of the same cast member. But I am going to assume that the tooltip is related primarily to the cast member, not the sprite. So how do we organise this information?

There are two pieces of information to consider here. The first is the tooltip text for each particular sprite/cast member; the second is which of these tips (if any) is currently required. (Further information, such as that required to work out the timing and location of the display, I shall not be discussing here, but there are some notes about it in the code for the behaviour itself in the sample movies). Sample movies are available for download in ZIP format. These movies are Director 7 format.

So where is the most appropriate place to store this information? I have chosen to put the tooltip information into the cast member name. So that I can distinguish between those members which have an associated tooltip and those which don't, I have named the members "Square tt This is a square", "Triangle tt How about a triangle" and "Circle no tooltip". The string "tt" marks the point at which the tooltip begins. This also enables us to use the Lingo function "contains" to determine whether the member name is a tooltip. The other information is controlled in a single behaviour, which is attached to the tooltip sprite.

Here is the code for the main handler of the behaviour:

on settooltip(me)
  t=sprite(prollover).member.name
  
  if t contains "tt" then
  
    repeat while true
      if t.word[1]<>"tt" then delete t.word[1]
      else exit repeat
    end repeat
    
    delete t.word[1]
    sprite(me.spritenum).member.text=t
    sprite(me.spritenum).loc=the mouseloc 
    
  end if
  
  ptooltipchecked=1
  
end

The property ptooltipchecked is used to ensure that the tooltip is only displayed once, and only checked once if no tooltip is available at all.

It is interesting to compare this approach to the tooltip behaviour in the D7 library, where the information is held primarily in behaviours on the individual sprites and controlled via the propertydescriptionlist, while the tooltip sprite itself is a passive recipient of the information. This is a far more sprite-based approach, and of course just as effective. But for a simple movie, the information handling of the movie above is very efficient, and uses the Director environment to make our lives easier, because we can see the information we need directly in the cast window.

There are many other ways in which this environmental information can be used to access essential aspects of your movie. You could store Lingo handler names in cast member names or frame markers and execute them with the "do" command at an appropriate moment. You could use sprite numbers to determine the location of a square in a grid array (I do this all the time with a little bit of modulo arithmetic).

You could store large and small versions of pictures in equivalent member numbers in two different casts to make zooming in and out easier. And, of course, text and field members, and external text files, can hold as much information as we like in their actual contents, and are ideal for storing data to be read in when setting up the movie. There are an unlimited number of ways to turn meaningless data into meaningful information.

Variables

Okay, so we have seen how it is possible to use the information that we have available to us purely as a virtue of the Director authoring environment. But these are really best as places to hold the information which is constant throughout the movie. When information needs to change during runtime, the best way to store it is usually in a variable.

Director has three forms of variable. Local variables are scarcely information-bearers at all. At best they are temporary vehicles for transmitting and manipulating information from moment to moment. Global variables are ideal for holding information that is needed everywhere, the main parameters of the movie that belong to all the actors in it, but are often overkill, simply overburdening the movie with inappropriate information. In my opinion, the most interesting type of variable is the property.

Property variables are a natural extension of the principles of the previous section, and it is interesting to observe how Lingo syntax treats property variables and intrinsic properties of entities identically, using the property of x, (or x.property,) for both. The beauty of property variables is that they are ideal ways to observe the dictum mentioned above: Keep the information where it's relevant.

This may sound familiar, and indeed it is in some ways just a broadening of the standard OOP concept of encapsulation, which says that script objects should be self- contained entities, referring only to their own properties and communicating via handler calls. Sometimes this principle can get a little obsessive, but in terms of keeping one's code compact and easy to understand, it makes a great deal of sense. In light of this discussion of information, it is now easy to see why. Encapsulation allows information to be kept in one place, rather than being spread around.

Here is one more example of the information principle. There are many ways to create a bank of lights with chasing effects. The most obvious is to use a behaviour which sends the flash on to the next sprite while stopping it on itself, but this has a disadvantage, which is that it is hard to distinguish between separate waves of flashes. If you click on the buttons in the movie, you will see that you can create two overlapping sets of flashes, at random speeds. Not only do the circle and line share sprites, but it is possible for waves of different speeds to catch each other up and overtake on the same sprite group. How is this achieved?

A single parent script is the answer, holding three pieces of information: its speed, current sprite and group of sprites on which it is travelling. The buttons add instances of these scripts to the actorlist, where they stay until they reach the final sprite in their list, at which point they put themselves into a global list for removal on the next exitframe.

The important point about this system is that it recognises the fact that the entity that needs the information about a flash is not the sprites that display the flash. These are simply the medium through which it travels. The flash itself is the true entity, just as we psychologically perceive it. So we put the information where it is relevant, and we have a versatile, efficient and ultimately quite simple system for controlling our lights. This could be easily expanded to other effects and media.

Conclusion

We have gone a long way in the space of two thousand words. From a bare bones, one-sprite movie, we have come right through to encapsulated child objects. What I have been trying to show is that the same principles of information handling can be applied at all levels of programming, and in my opinion is the key to efficient coding. I would like to finish just by summing up the advantages that this approach gives.

Information handling allows you to use the flexibility of Director to its best advantage. It makes changing essential parameters of your movie much simpler, by keeping the relevant data, that are the source of information for your movie, in a single place. This is the principle of soft coding, where as few pieces of information are stored directly in your code as possible. In a simple movie, this may seem to make life more complicated, but it very soon becomes essential, especially in a large project where things may change radically from day to day.

The core question to ask yourself all the time, from the very first paper development to the last day of debugging is this one: Who knows what when? By keeping track of where the information is, what entities need it, what entities control it, when it changes, when it is constant, life becomes so much easier for everyone.

Danny is a mathematician by training, an occasional writer, actor and, for the last four years, programmer. He is self-taught in Director and it occasionally shows. He is part of the company Wellspring Interactive Ltd and has just finished working as Head of Clues on their first major project, TimeHunt.