In Part 1 of this series I laid out the project parameters and assumptions in creating an interactive experience based on the operation-style games. What I would like to do with this next post is just test the assumptions made about the project. Technology, experience, and hardware.
Possibly the largest assumption is the WinBook being used as the primary computer in the experience. Even though it runs a full version of Windows 8.1 the processing power is not spectacular, but it just may be enough to run a simple application that is triggered by the MaKey MaKey.
To be certain if the communication and processing power are fast enough I created two simple applications to help test my assumptions. Both are on Github and provide simple key detection and show how fast/slow the application responds to the MaKey MaKey.
- WPF Application for MaKey MaKey keypress detection
- Unity3D Application for MaKey MaKey keypress detection
In each of these I approximate a standard set of PC gaming user keys and see how well the compiled applications run on the tablet, responding to the MaKey MaKey sending its events as key presses. For those that can’t run these applications here is what that looks like:
After cloning the repositories on the WinBook and running the programs it looks as though they both run fairly well. There really should be no limitations so far that would be problematic. Knowing that they both run doesn’t make the decision for me as to which direction to take, unfortunately.
Unity project running on the WinBook, with MaKey MaKey detecting up press
For the sole reason that I have not had a fun Unity3D project in a while I am going to make the final application using it. Both will get me where I need but this is a great chance to update my knowledge in Unity3D. The release of version 5 adds a lot of enhancements that may be useful for this and other projects.
This really came down to my playing several games with the common mechanic of extracting objects from a patient. Some of these can get fairly serious and have storylines that augment the game mechanic to make it a more unique experience. There are some good games built on this mechanic, so we can be somewhat comforted that the right experience will be well received.
My implementation will be a bit silly and aimed at children aged 10 and under. Not that it matters much. If it looks fun people will play regardless of what we may expect.
The cabinet and removal tool are the main hardware to consider and both seem pretty simple to implement. Both will be wired to the MaKey MaKey to detect a user’s attempt to remove the fox models.
Just to prove out the concept I took a bit of aluminum foil and cardboard to stand in as the game cabinet. Holes were cut and lined with foil to allow players a place to pull models from the cabinet.
This worked very well in these materials, and I have a fairly good backup in case something goes awry with making the final cabinet. It’s not pretty yet but at least it works. Not that I am anticipating catastrophic problems, but it is good to be prepared just in case.
Next post in the series
My next steps are to draw the stylized map of the city, design and 3D print the game pieces, and construct the cabinet. The Unity 3D project I will leave for last as the material aspects of the project have a greater risk, and I am moving to complete things in order of complexity and project risk.