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-2024, Director Online. Article content copyright by respective authors.