Lessons from an Early 'QR Story Quest' Prototype

I have been working on an iPhone app as I've had time over the last few months.  It's essentially a platform to run what I call QR Story Quests, which are somewhat like traditional QR code scavenger hunts but with more structure.  Instead of just finding objects in whatever order you want, you have to do things in a particular order that suits the game's story.  In some parts of the story you might have to do a mini-scavenger hunt, and you sometimes have choice in terms of the path to take, but the overall story structure is well defined and enforced.

Since I was finally able to concentrate on this 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.  Stay tuned!