Lesson 16: Building Behaviors

Goal

In this exercise you will learn how to create a behavior that includes advanced authoring features such as sliders and pop-up menus.

Background:

A behavior is a special Lingo script that makes use of the properties of Sprites and related Cast Members to produce reusable scripts. Behaviors require a special type of script. When you write a behavior you need to make sure it is a behavior type script or you will not be able to drop it onto sprites and frames.


The above image shows a behavior script named "Fire Bloom" from the script editing window. If you do not see the words "Behavior Script" at the top of your script editing window you are not working with a behavior script.	To change a script from one type to another go to the Property Inspector Window, choose the Script tab, and choose the type of script you want to convert to from the pop-up menu.

Once you have created a Behavior script and you have written one or more handlers for it you can drag-and-drop it onto a sprite or frame. Sometimes the same behavior will work on a sprite or frame, depending on how it is written.

on mouseUp me
sprite(1).loc = sprite(1).loc + point(5,0)
end

The above script is a perfectly valid behavior that can be used on any Sprite in channel 1 of the Score, or in a Frame Script. The difference in how the script will work is that when it is attached to Sprite 1 it will move Sprite 1 to the right 5 pixels every time Sprite 1 is clicked. If the same behavior is attached to a frame that contains a sprite in Channel 1, that sprite will move to the right 5 pixels when the mouse is clicked anywhere on the stage. In the latter case the frame itself receives the mouseUp message, but in the former case only the sprite the script is attached to will receive the mouseUp message. It is up to you to make sure a particular behavior is appropriately associated with a given sprite or frame.

As it stands, the above behavior wil only work for a sprite that is located in channel 1 of the score. This behavior could be immediately improved by substituting a relative sprite channel where the number '1' is used. This is done by accessing the sprite number property of the object reference 'me'. The me keyword always refers to the object to which the behavior is attached. One of the properties of me is the channel number (in the Score) of the sprite to which the behavior is attached. Substituting (me.spriteNum) for the number '1', in the above handler, allows the behavior to be dropped onto a sprite in any channel, so it is much more versatile. (me.spriteNum) will automatically return the number of the sprite channel the behavior is attached to, so using it instead of hard-coded sprite channel numbers is generally a good practice to adopt.

on mouseUp me
sprite(me.spriteNum).loc = sprite(me.spriteNum).loc + point(5,0)
end

Planning & Designing a Behavior:

Behaviors are very versatile, but they can be confusing to implement if they are not carefully authored. The main point of creating a behavior is to have reusable code that is easy to apply to a variety of situations. By adding a few handlers to the above script we can create a much more flexible behavior that can be used for a variety of applications. Before doing this, however, we need to decide what exactly the behavior needs to do. Once we know what the behavior should specifically do we can craft the behavior to our specification. Below, are four steps that are good to follow when designing and constructing a "brightBox-emphasis"

1. Specify what the behavior should do. Draw a diagram, or describe the behavior's features on paper, if necessary. To ease the development process for the implementation of the behavior it is essential that you know, up-front, what the behavior should and shouldn't do.

2. Determine what variables will need to be defined to control the properties or features of the behavior.

3. Determine the #format of each variable, and use one of the default types (shown in the table below), where appropriate.

4. Establish the methods (handlers) that will make the behavior work. This includes determining which handler messages will need to be implemented to get the behavior to perform to the specification.

The specification for each of the four above development steps are:

1. This behavior will allow sprites to be moved across the screen from left to right, or right to left, at a speed ranging from 1 pixel per frame to 100 pixels per frame, forward or backward. The behavior will animate sprites horizontally according to the frame rate of the movie, which is assumed to be 30 FPS, by default. When the sprite reaches a specified horizontal position at the right side of the stage it will move across again from a specified position at the left side of the stage. If the sprite moves to a position at the left side of the stage it will automatically move to a specified position on the right side of the stage. Essentially, the sprite will "wrap" from a leftmost and rightmost horizontal position on the stage while it moves.

2. Three variables will be needed. pSpeed will control how many pixels (1-100) per frame the sprite moves. pLeftPos determines the leftmost position the sprite will move to on the left after it has reached the pRightPos rightmost position.

3. All variables in this example will use the #format type of #integer, since the values for the variables will all be whole numbers.

4. This behavior will use an exitFrame message to animate the sprite. This means that the overall frame rate, or frames per second (FPS) of the movie will have a direct effect on the sprite's animation speed.

The completed behavior is shown below:

property pSpeed -- the speed the sprite moves in pixels per frame
property pLeftPos -- the lefmost position of the sprite
property pRightPos -- the rightmost position of the sprite

on getBehaviorDescription me
return "Moves a sprite horizontally at a definable speed."
end

on getPropertyDescriptionList me
list = [:]
addProp list, #pSpeed, [#comment: "Sprite Speed:", #format: #integer, #default: 5, #range:[#min: -100, #max: 100]]
addProp list, #pLeftPos, [#comment: "Leftmost Position:", #format: #integer, #default: 0]
addProp list, #pRightPos, [#comment: "Rightmost Position:", #format: #integer, #default: 100]
return list
end

on exitFrame me
sprite(me.spriteNum).loc = sprite(me.spriteNum).loc + point(pSpeed,0)
if sprite(me.spriteNum).locH > pRightPos then
sprite(me.spriteNum).locH = pLeftPos
end if
if sprite(me.spriteNum).locH < pLeftPos then
sprite(me.spriteNum).locH = pRightPos
end if
end

When the behavior is dropped onto a sprite a "Parameters" window appears. The parameters that appear are those that were defined in the getPropertyDescriptionList handler in the script. These parameters are only visible to the author (you), and will not appear when the movie runs. Specific interface elements such as sliders and text fields appear based on how the properties are written within the getPropertyDescriptionList

Let's break down the behavior to see how its parts work together.

property pSpeed -- the speed the sprite moves in pixels per frame
property pLeftPos -- the lefmost position of the sprite
property pRightPos -- the rightmost position of the sprite

Properties in a behavior must always be declared, similarly to the way a global variable is declared. When writing a behavior it's easiest to think of the properties as the variables you'll be using within the behavior. Using a lower case "p" as the first character of each property variable name reminds you that it's a property variable. The advantage of property variables is that they will store unique values for each sprite you apply them to, so you don't have to use global variables. You can just rest assured that once a behavior is applied to a sprite, that it's property values will be unique to that sprite.

Each property declaration includes a description to make it easier to remember what each property does. Since these lines have a double dash "--" they are useful as comments only. It's generally a good idea to include this kind of comment for your behaviors so you will more easily remember how they work.

on getBehaviorDescription me
return "Moves a sprite horizontally at a definable speed."
end

The "behavior description" is the text that shows up at the bottom of the Behavior Window in the Director interface when you examine the events and values of a behavior. You don't need it for a behavior to work, but it's a good place to include information about who wrote the behavior, or what the behavior does for other multimedia authors to see.

on getPropertyDescriptionList me
list = [:]
addProp list, #pSpeed, [#comment: "Sprite Speed:", #format: #integer, #default: 5, #range: [#min: -100, #max: 100]]
addProp list, #pLeftPos, [#comment: "Leftmost Position:", #format: #integer, #default: 0]
addProp list, #pRightPos, [#comment: "Rightmost Position:", #format: #integer, #default: 100]
return list
end

This is the most complicated part of the behavior to understand, but it is essentially a property list that stores the property values for the "Parameters" window that pops up when the behavior is first attached to a sprite. The property list is stored within a single variable and the behavior uses it to determine what variables can be used in the behavior interface window, and the default values of properties. If you set it up correctly you can get slider bars to change the property values for a behavior. The #min and #max properties for the pSpeed variable determine the range for the slider bar to control "Sprite Speed." In this example the minimum slider value is -100, and the maximum is set to 100. The range of the slider can be set to any value, but you should always declare a default setting for any properties you want to access through the "Parameters" window. Default settings may be 0, "", or VOID, if no other default value is needed.

When building your own behaviors that make use of a "Parameters" window it is easiest to use a handler like the getPropertyDescriptionList handler above as a kind of template, then substitute or change the variables and interface settings in that handler to suit your purposes. It's often much easier to alter an existing getPropertyDescriptionList handler than to remember how to construct one from scratch.

The #format Property of a Behavior:

The #format property of a behavior, shown in bold red text below, specifies the type of data or object the declared property variable will access.

on getPropertyDescriptionList me
list = [:]
addProp list, #pRotationSpeed, [#comment: "Rotational speed of the sprite:", #format: #integer, #default: 0]
return list
end

Changing the above #format type from #integer, to some other type, such as #string, or #float, may be necessary, depending on what a given property variable needs to do. Take care in choosing a proper #format type for each variable you use in a behavior to avoid runtime errors, or unpredictable results.

Director currently supports 22 different #format types for behaviors. They are listed in the table below:

Type	Dialog Window Result	Resulting Value
#integer	Text entry field.	Integer (whole number).
#float	Text entry field.	Floating point number.
#string	Text entry field.	String.
#boolean	Check box.	TRUE or FALSE (1 or 0).
#symbol	Text entry field.	Symbol.
#member	Pop-up list of all cast members.	Cast Member name.
#bitmap	Pop-up list of bitmap cast members.	Cast Member name.
#filmLoop	Pop-up list of film loop cast members.	Cast Member name.
#field	Pop-up list of field cast members.	Cast Member name.
#palette	Pop-up list of palette cast members.	String with the name of the palette.
#sound	Pop-up list of sound cast members.	Cast Member name.
#button	Pop-up list of all button type cast members.	Cast Member name.
#shape	Pop-up list of shape cast members.	Cast Member name.
#vectorShape	Pop-up list of vector shape cast members.	Cast Member name.
#font	Pop-up list of font cast members.	Cast Member name.
#digitalVideo	Pop-up list of digital video cast members.	Cast Member name.
#script	Pop-up list of script cast members.	Cast Member name.
#text	Pop-up list of text cast members.	Cast Member name.
#transition	Pop-up list of built-in transitions.	Visual Transition.
#frame	A text field.	Frame number.
#marker	Markers in the score and relative markers.	String or symbol for a marker.
#ink	Pop-up list of inks.	Ink number.

This exercise has only skimmed the surface of how to construct behaviors. The best way to learn more about them is to explore as many as you can find. The web site http://mediamacros.com is a good resource for behaviors, and there are many other online sites that publish free, easy to use Director behaviors as well. Director itself contains a large library of very sophisticated behaviors that you can study and re-engineer for your own purposes. Some of the included Director behaviors in the library will take a lot of time to reverse engineer, but you will discover a wealth of excellent Lingo scripting techniques, along with numerous well-commented handlers.

Exercise:

Using the example movies in this exercise as a reference, develop one or more behaviors that you can use and reuse in your Director Movies. Here are some ideas for behaviors to construct:

Make a behavior that allows you to animate one or more properties of a sprite.
Make a behavior that allows you to choose which sound is played when the user clicks a sprite.
Make a behavior that allows you to specify which marker you want to link to when the user clicks a button.
Make a behavior that simplifies the creation of a rollover effect, such as swapping one cast member for another.

Example Movies:

Simple Sprite Move Behavior (6 KB)

Flip Sprite Behavior (8 KB)

Jump Sprite Behavior (12 KB)

Image Swap Behavior (83 KB)

Table of Contents

Set as favorite

Bookmark

Email this

Trackback(0)

TrackBack URI for this entry