Matching game behaviors

October 17, 1999
by Pat McClellan

Dear Multimedia Handyman,

I read your example of developing a simple paint program with your eyedropper and paintbucket behaviors... got an additional question for you. What if you wanted to have the user (a child) select a specific numbered colored bucket and click on the same number in the simple picture -- paint by numbers. If they get it correct, that part of the picture changes to the appropriate color. Thanks.

Tricia

Dear Tricia,

This actually sounds more like a matching game -- which happens to use color -- than a paint bucket situation. The paint bucket behaviors I used are a bit limited because they require that you use 1-bit images (that's the only way the forecolor and backcolor properties will work). That means you couldn't have a colored pattern or a more sophisticated graphic. For your situation, I'm going to suggest a more versatile solution -- one which you'll be able to reuse for other matching programs (using letters or numbers or animals or foods) for your students.

Let's make a list of what we want this to be able to do for us, as well as the options which will make it most versatile. The basic functionality is as follows:

The user clicks on a sprite to select the first of a pair (in our example, a color.)
The user clicks on a second sprite. If this sprite is the corresponding match to the first selection, the image changes.

Here's how we'll accomplish these basics. Both the colored numbers and the shape sprites will have an ID. This will simply be an identifying name, such as #red, #blue, or #green. When the first sprite is selected, it will set a global variable equal to this identifying name. Then, when the second sprite is clicked, it will compare that global variable to its own name. If it matches, then the member of that sprite will be swapped with another member. We'll need a simple behavior for the color numbers which just set the global variable, and a more complicated behavior for the shape sprites. Here's the simple one for the colored numbers.

-- Selector Behavior
global gSelected
property pMyID
on getPropertyDescriptionList me
  IDlist = [#red, #blue, #green]
  set pdlist to [:]
  
  addprop pdlist, #pMyID, [#comment:"My ID:", #format:¬
    #symbol, #default:#red, #range: IDlist]
    
  return pdlist
  
end getPropertyDescriptionList
on mouseUp me
  gSelected = pMyID
end mouseUp

Test out these basic features in this demo movie. Click on a colored number, then click on the corresponding shape.

Download a sample movie in Mac or PC format. This movie is a Director 7 file.

Now, let's consider the behavior for the shape sprites and the optional features we'll want to include for versatility. If the user selects a color but then clicks on the wrong sprite, what happens? One option is to have nothing happen, leaving the global variable (gSelected) set to the currently selected color. That means that the user could then click on the correct matching sprite and be rewarded. The other option is to have the color selection canceled (be resetting gSelected to #null) if a wrong selection is made.

To see this functionality, reset the demo movie above. Click on the red numeral one. Next, click on the shape designated with a two. Notice that gSelected is reset from "red" to "null", so if you now click on the correct #1 shape, nothing happens. In contrast, click on the blue numeral two. Now, click on the #1 shape. Notice that in this case, gSelected does not get reset to null -- the color is not canceled. So you can now click on the #2 shape an be rewarded.

That takes care of what happens when the wrong sprite is selected. But what are the options when the correct sprite is selected? Obviously, the image will change (and you could also play a reward sound effect or add points to a score.) My question is specifically related to our gSelected variable. Does the selection persist? What if there are several sprites which are the same (or related) color? Notice in the demo that if you select the green numeral three, you can click on both of its corresponding sprites without having to renew the selection. What's happening here is that if the match is correctly made, gSelected is not reset to #null. Instead, it persists.

Given those basic and optional features, here's what the getPropertyDescriptionList dialog box should look like when we drop it on the sprite (the black shapes).

First, like the behavior above, you'll select an identifying name (note that these names must exactly match the choices for the Selector behavior.) You'll use the pulldown menu to select the bitmap member which will be swapped for a correct match. (Because the ID and the swapped image are separate selections, you can have sprites which share an ID but have different swapped images -- as the two sprites designated by number 3 in the demo.) Then, you select whether you want the color canceled for an incorrect match, and whether the color will persist after a correct match. Here's what the behavior looks like.

-- MatchSwap Behavior
-- copyright © 1999, ZZP Online, LLC
-- free use for DOUG readers
property pMyID, pSwapMem, pSprite, pCancel, pPersist
global gSelected
on getPropertyDescriptionList me
  IDlist = [#red, #blue, #green]
  set pdlist to [:]
  
  addprop pdlist, #pMyID, [#comment:"My ID:", #format:¬
    #symbol, #default:#red, #range: IDlist]
  addprop pdlist, #pSwapMem, [#comment:"Swap member:", ¬
    #format:#bitmap, #default:0]
  addprop pdlist, #pCancel, [#comment:"Wrong click cancels?", ¬
    #format:#boolean, #default:1]
  addprop pdlist, #pPersist, [#comment:"Color persists?", ¬
    #format:#boolean, #default:0]
  
  return pdlist
  
end getPropertyDescriptionList
on beginSprite me
  pSprite = sprite(me.spriteNum)
end beginSprite
on mouseUp me
  if pMyID = gSelected then
    pSprite.member = pSwapMem
    if NOT pPersist then
      gSelected = #null
    end if
  else
    beep
    if pCancel then
      gSelected = #null
    end if
  end if
end mouseUp

As you can see, the optional features are as simple as a check box. The properties pCancel and pPersist are booleans -- just switches which are on (1) or off (0). You can use them in your if statements just by saying...

if pCancel then
        do whatever
end if

You don't even have to say "if pCancel = 1"... that's implied with booleans. If you want to see if the value is False (or O, or off), then you can just say...

if NOT pPersist then
        do whatever
end if

You don't have to capitalize not, I just do for clarity. The important thing to learn here is the value and simplicity of using boolean values as switches for your optional functions in behaviors. Notice that you can set the default value (1 or 0) up in the getPropertyDescriptionList handler. You can see that in this behavior, pCancel defaults to 1 (on) while pPersist defaults to 0 (off).

Good luck with your program -- and all the future matching games you can make with these simple behaviors. Play with the code and expand the functionality as needed.

Patrick McClellan is Director Online's co-founder. Pat is Vice President, Managing Director for Jack Morton Worldwide, a global experiential marketing company. He is responsible for the San Francisco office, which helps major technology clients to develop marketing communications programs to reach enterprise and consumer audiences.