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.
I just downloaded this intriguing iPhone app: Inception the App. I haven't tried it yet, but based on some commentary I've seen on Twitter and on reading the website, this might just be the coolest audio augmented reality application I've heard of to date.
This TED Talk by MIT's Cynthia Breazeal is full of really neat stuff. Near the end, she talks about a newer project that creates a play space for children using robots and mixed reality. I'm not sure if the main purpose is for learning, but you can easily see how that would fit in. I found this project pretty inspiring.
A lot of us in the lab use Processing for a variety of things, such as prototyping game ideas. While the little IDE Processing comes with is ideal for those just getting started with programming, it's a bit too simplistic for many of us. Luckily, it's possible to use all the Processing library has to offer in a regular Java project.
Here are my notes on how I set up Eclipse to work with Processing and SVN.
There's a bit of extra work in getting this JavaHL thing, so be sure to not ignore the information at the top of the page (follow the link to the wiki they mention).
Start a New Project
Note: You may want to create your project using the subclipsing plugin described below ("Exporting to an Applet Like Processing Does"), but you don't have to - you can still use the plugin to export if you create the project as per this section.
Start up Eclipse with the workspace you want to use.
Create a new Java project naming it whatever you want.
Right click the Java project, go to Team > Share Project. Choose SVN. Create a new repository location if yours isn't there yet. Otherwise just select it.
When choosing the repository location, choose the folder that the new project folder will go into. Eclipse will make a new folder for you, so don't worry about creating it with an SVN repository browser ahead of time.
Getting Processing Into the Project
These basics are from the more detailed article on Processing's website. I am assuming you have installed Processing on your computer already.
To import the Processing library, right click your project and say Import. Choose General > File System.
Browse to the location of your Processing installation folder and find the lib folder (Windows) or Java (Mac).
Choose the core.jar in the list of jars and click finish.
The jar file is now physically in your project. You will probably want to include it in your SVN repository to ensure everything is complete. To do this, right click, say Team > Add to Version Control. Now when you commit your project it will be included.
Running as an Applet
As per the same detailed article linked to above, we do the following to use Processing in our project:
Import the core Processing library: "import processing.core.*;"
Extend PApplet. PApplet is the parent Processing class that allows us to have access to all the Processing goodies.
Write setup() and draw() (and specify "public" for these Processing functions).
The best way to run is to add the following to the main method and to run the program as an applet:
You can uncomment the --present part to run in full screen mode.
Differences from Processing IDE
In the Processing IDE, you always have access to the PApplet members and methods. This is because each tab you create adds an inner class, and each class within the tabs is an inner class to that. So everything ends up inside a PApplet.
In Eclipse, you wouldn't set it up this way. Your main class that extends PApplet is like what you get in the Processing IDE. But the rest of your classes won't extend PApplet as well, since you really only want one applet. Instead, what you can do is pass the PApplet class to the other classes you create so they can access the applet's members and methods (almost like in the IDE, except now you go through the reference to the applet that you stored).
I like to create a new class for each object that will appear on the screen, and give each of these objects its own draw method (as well as any others needed such as for handling mouse clicks). Then in the main PApplet's draw method, I go through each object I've created and call its draw method. Since each object has a reference to the applet, it can make use of the usual Processing functionalities to do the actual drawing. This keeps everything organized in a nice way.
A final thing to note is how to use fonts with the Processing text() commands. You can open up the usual Processing IDE and create a font there. After saving the placeholder sketch, go find the data folder, and copy that into your bin folder for your Eclipse project. Then you use the font as you normally would. If you are using SVN you'll probably want to add that data folder so you will always have the font from there on in.
Exporting to an Applet like Processing Does
That whole one-click export thing that the Processing IDE does is pretty handy. Luckily, you can get the same thing in Eclipse with proclipsing. Check out their site for instructions on installing and setting up their plugin.
If you want to use the export, you will have to use numerical values in the size() function of your PApplet class's setup(). Otherwise it doesn't know how big to make the window.