Quiz with random order and text evaluation
January 9, 2000
by Pat McClellan
Dear Multimedia Handyman,
I need to create a quiz in which the student types the name of an object shown on the page. If they get it right, they move on to the next picture. If they don't, they try again before being told the answer. I also need to ask the questions (show the pics) randomly so that the next student to do the test can't cheat. I'm using director 7 and "think" this can be done via lists but I'm not sure how to tackle it. Any suggestions?
Any help would be greatly appreciated.
Tee
Dear Tee,
There are two issues to look at. We'll need a way to randomize the order of the questions. But first, we need to have a way to compare a user's input to a set of acceptable answers. I say "a set of acceptable answers" because often there are several ways to enter an answer. For example, let's say you showed me a picture of Lassie (canine star of film and television.) The correct answer could be any one of these: dog, collie, Lassie.
What we'll need to do is to create a list which contains all of the acceptable answers, then we will compare the user's input to each of the possible answers to see if we have a match. The question is... when. When do we do the comparison? That depends on your interactive design. You could have a ENTER or SUBMIT button beside the text entry field. When pressed, the answer evaluation would occur. However, I prefer to have the task handled more automatically. So my method happens when the user hits the Enter or Return key -- that means our behavior will have a keyUp handler, and the behavior will be applied to the field sprite itself (not on a button).
Now let's think about the consequences of a correct or incorrect answer. If the match is made, we'll want to advance to the next question. This will need to interact with the question randomizer, so let's think about that now. Let's say that you name each question with a marker. If you create a list of those marker labels, then you could select from the list at random -- thus mixing up the questions. To prevent a question from being repeated, you'll need to delete the label from the list when it is selected. All of this will happen independent of any particular frame or sprite, so it makes sense to put all of this into a movie script.
Here's a demo of a poker test where you have to name each hand. Try it out for yourself. It's not a hard test, since I'm displaying the list of acceptable answers below, but that's just so you can see what's going on.
A sample movie is available for download in Mac (135 K) or PC (108 K) format. This is a D7 movie.
In this demo you can see all of the things we've discussed. If you take the test several times, you'll see that the sequence of the questions is random. I've tried to think of all of the obvious variations for the names of the hands, but that's easily editable during authoring. Let's take a look at the code.
I started with a movie script which handles setting up the list of questions (frame labels). These labels could be anything. They're not intended to be the answers. To start the quiz, there's the startQuiz handler which resets the score to 0 and creates a duplicate of the list of frame labels.
global gThisQlist, gQList, gScore
on startMovie
gQList = ["jacks","3kings","straight","flush","4kind",¬
"fullhouse","royal"]
end
on startQuiz
gScore = 0
gThisQlist = duplicate(gQList)
nextQ
end
The startQuiz handler calls to another handler called nextQ. This handler is the randomizer. First it checks to see how many questions there are remaining in the gThisQList. If there are no questions remaining, then it calls to end the game. Otherwise, it selects a random number between 1 and the number of questions remaining. It then goes to the frame with the corresponding name and deletes that name from the list of remaining questions. (Note that all of these handlers are in the same movie script, with the global variables declared at the top. If you separate them into different movie scripts, you'll need to re-declare the global variables.)
on nextQ
remainingQs = gThisQList.count
if remainingQs = 0 then
endGame
else
thisQnum = random(remainingQs)
go gThisQlist[thisQNum]
deleteAt gThisQlist, thisQNum
end if
end nextQ
on endGame
alert "You got" && gScore && "out of" && ¬
gQList.count && "correct."
go to "start"
end endGame
on correctAnswer
gScore = gScore + 1
nextQ
put "RIGHT"
end
on wrongAnswer
beep
put "WRONG"
end
The other handlers in the movie script are self-explanatory. You can edit them as needed to meet your individual needs.
Now we need write the behavior for the text entry fields. (It's really just the same field member repeated.) The main property value will be a list of the acceptable answers. We'll let the author enter those when the behavior is dropped on the sprite. The author will enter a string. However, we need this to be a list, so in the beginsprite handler, we'll call the initList handler which will convert the author's string into a list of answers. The initList handler also trims any spaces which may have preceeded any of the answers.
-- textAnswer behavior
-- copyright © 2000, ZZP Online, LLC
-- free use for Director Online readers
property pAnswerList, pMem
on getPropertyDescriptionList me
set pdlist to [:]
addprop pdlist, #pAnswerList, [#comment:"Answers ¬
(separate with comma):", #format:#string, #default:""]
return pdlist
end getPropertyDescriptionList
on beginSprite me
pMem = sprite(me.spriteNum).member
pMem.text = ""
initList me
end beginSprite
on initList me
the itemDelimiter = ","
tempString = pAnswerList
itemQ = tempString.item.count
pAnswerList = []
repeat with thisItemNum = 1 to itemQ
thisItem = tempString.item[thisItemNum]
repeat while thisItem.char[1] = " "
delete thisItem.char[1]
end repeat
add pAnswerList, thisItem
end repeat
member("display").text = string(pAnswerList)
end
on keyDown me
if the key = ENTER or the key = RETURN then
stopEvent
userText = pMem.text
repeat with thisAnswer in pAnswerList
if userText = thisAnswer then
correctAnswer
exit
end if
end repeat
wrongAnswer
else
pass
end if
end keyUp
The main processing in this behavior is done by the keyDown handler. When the user hits the ENTER or RETURN key, the keyDown handler compares the entered text to each of the acceptable answers. If a match is found then it calls for the correctAnswer handler (in the movie script). If no match is found, then it calls for the wrongAnswer handler (also in the movie script.) That's it.
This behavior simply evaluates whether the answer is right or wrong. It leaves it to the movie script to decide what to do with that information. That's an important concept because that makes the behavior more flexible and reusable, and that's a goal we always strive toward.
Good luck with your program.
Copyright 1997-2025, Director Online. Article content copyright by respective authors.