In this tutorial I’d like to discuss the use of lists (as Director calls them) or arrays (as most other software packages call them) in simple puzzle games as a way of checking if a solution has been found. This particular game called ‘Animal Misfits’ had a few possible solutions, and using lists was the most obvious way to go.

Aimed at the younger age bracket (as you can probably tell), this game splits up 3 animal characters into head, body and legs sections and jumbles them up. The player can drag and drop the sections into the spaces on the screen and try to complete the characters. Once all three characters are put back together properly the game plays a tune and then jumbles them up again. There is a complication from a programming point of view in that the characters can be recompiled in different orders left to right, and all possible successful combinations have to be checked for.

How does it work?

Well, after a little intro sequence you can click on the screen to start the game.

Unsurprisingly, each piece is a separate sprite in Director’s score and as such can be identified with a sprite number. In my case, the sprite channels used range from 18 to 26. A frame script handles the bulk of the game, and the game part of the movie runs in a single frame.

The frame script compiles a variable called gGameList, which is actually a list of sprite numbers. Each item in the list represents a square on the grid on screen where a piece can be placed. There are 9 pieces (3 per animal) and there are 12 boxes on the grid, giving us 3 blank squares at anytime so the pieces can be moved out of the way in order to build up the animals - try the game and you’ll see why the 3 blank squares are needed!

So, gGameList is a list with 12 items, 3 of which will always be 0 (representing a blank square) and 9 of which will contain a unique number from 18 to 26, representing the sprite channel of the piece that’s been placed there.

The framescript runs code at the start of the game to populate the first 9 items in gGameList with numbers chosen randomly from 18 to 26, making sure no number is duplicated. First the list is created and populate with zero’s:

gGameList = []
repeat with a = 1 to 12
add gGameList,0
end repeat

and then a sequence is run to mix the animals up a bit, and also take note of the invisible sprites I’ve placed on the stage to indicate where the squares are:

pieceSprites = [] -- sp nos for init only
snapSprites = [] — sp nos for init only
repeat with a = 1 to 9
add pieceSprites,(a + 17) — adding 17 to a will give us a valid sprite number
end repeat
repeat with a = 1 to 12
add snapSprites, (a + 4)-adding 4 to a gives us valid sprite number
end repeat
– populate board
pFlag = FALSE
repeat while pFlag = FALSE
r = random (pieceSprites.count)
r2 = random (snapSprites.count)
if getAt (gameList,r2) <> 0 then
next repeat
else
setAt gameList,r2, (getAt (pieceSprites,r))
deleteAt piecesprites,r
if pieceSprites.count = 0 then
pFlag = TRUE
exit repeat
end if
end if
end repeat
end if

Then, when the sprites initialise they look at the global variable list and place themselves in the correct location on screen.

For non-director programmers, I’d better mention that Lingo uses 1 to refer to the first item in a list, not 0 as used in many other languages!

Using simple code for drag and drop, the pieces snap into position if dragged to an empty square, or snaps back to the starting point if dropped on a full square or not on a square at all. I’ve used code to decide if a drop is close enough to a square to be considered accurate enough or not, which basically checks if the mouse position when the piece is dropped is within the target square on the grid.

As a finishing touch, and partly for my own amusement, I’ve added sound effects of each creature on mouseUp when they’re dropped in a valid place, and a ’snap back’ sound when they zoom back to their starting position.

Now then, the point of this tutorial was how to use lists! So, the secret with this game is quite simply to predict the possible winning combinations, which I store in a global list when the game begins:

gWinningWays = [[21, 18, 24, 19, 22, 25, 20, 26, 23, 0, 0, 0],[18, 21, 24, 22, 19, 25, 26, 20, 23, 0, 0, 0],[18, 24, 21, 22, 25, 19, 26, 23, 20, 0, 0, 0],[21, 24, 18, 19, 25, 22, 20, 23, 26, 0, 0, 0],[24, 21, 18, 25, 19, 22, 23, 20, 26, 0, 0, 0],[24, 18, 21, 25, 22, 19, 23, 26, 20, 0, 0, 0]]

The list above show a list containing the 5 possible winning combinations, and also gives another insight into how the positions of each piece are referenced by the code. Each time a piece is dropped it uses sendsprite to tell the frame script where it is. The frame script then decides if it’s a valid position or not (it has analyzed the valid positions and stored them in, yes you’ve guessed it - another list) and tells the piece sprite whether to snap into position or jump back to the starting point.

After each movement of a piece, the frame script does a check to see if gGameList is equal to any of the possible solutions nested within gWinningWays. If it finds a match then it plays a quick flashing sequence, plays a victory tune and starts the game all over again.