From the Lab
Lessons from an Early 'QR Story Quest' Prototype
Gail Carmichael — April 25, 2011 - 10:43am
Since I was finally able to concentrate on my Story Quest project in the last couple of weeks, I now have a fully working prototype. I created a little example game with a Zelda theme using objects and locations within my own house.
The general story idea is that you have just volunteered to battle the monsters that have been terrorizing your town's cattle herds. You first have to equip yourself with a shield (found in the wooden box) and ask the local swordsmith to create you a weapon. The swordsmith needs you to find a certain set of materials, leading you through a mini-scavenger hunt where each clue leads you to a related real-world object (such as tinfoil for the metal to create the sword out of). Once equipped, you are off the find the mother beast and slay her (I used clues related to our cat to help the player find the correct locations). You have a choice in terms of where you look for her, and each path is slightly different.
I asked my husband Andrew to play the game last night. Through observing him and asking him about it afterwards, I learned the following:
- Multiplayer would make the game a lot more interesting on a larger scale (while he enjoyed the prototype well enough, he had all kinds of ideas for similar games with both collaboration and competition, and was most excited about those).
- The QR code library worked really, really well. Andrew admitted to purposely making it difficult, but the scanner managed to read the codes most of the time. Only when the image got unreasonably blurry from movement or low light did it fail. (I am using the ZBar bar code reader library, so kudos to them!)
- I thought the UI for the prototype might have garnered some complaints, but it did not. I worried there were too many button pushes to go from the main story node to a scavenger hunt list to an individual item to the code scanning, but that didn't seem to be a problem at all.
- Andrew said that the existence of QR codes in places they wouldn't normally be changed the way he looked for the next location or item. Still, when I observed him, he really did use the clue to figure out where to go - whether there was a code there only confirmed whether he was right. An approach without codes (i.e. based on location or natural feature recognition) might help alleviate this, but whether you want to may depend on the goals of the game (or even one part of the game).
- Related to this, Andrew felt that the story and reality were fairly separate since the objects were not represented exactly in the story (even if they had a fairly close mapping). I figure this isn't necessarily a bad thing - it again depends on what the goals of the game are.
Based on all this, it looks like the main considerations at this point are more related to content than technology. However, to make multiplayer a reality, I will need to do some code redesign, so that's what I'm working on now. I'm planning on adding the concept of teams, player roles, and virtual items.