By Andrew Curley
The Hidden Village is an educational game that teaches students geometry through motion capture technology. Various characters in the game prompt the player to imitate a series of poses on screen, each pose followed by a multiple choice geometry question related to the motions performed. The project is a collaboration between researchers from the University of Wisconsin and Southern Methodist University (SMU), aiming to improve the math-learning experience for children in today's shifting educational landscape.
Development on The Hidden Village began in 2015 on the now-defunct Extreme Reality motion capture SDK. With this technological foundation in place, SMU Guildhall students Katie Wood and Leo David provided narrative and artwork, respectively, to ground and improve the player experience. I joined the project as the game's producer from May 23 to July 14, 2016 as part of a Directed Focus Study course at the Guildhall. During my time on the project, I worked with a student programmer John Wilson to port the game from the Extreme Reality SDK to the Unity engine, with the Microsoft Kinect as the game's new motion capture platform.
The process was new and exciting for both Wilson and I, and we learned many valuable lessons in this short amount of time.
What Went Well
University bureaucracy was a blessing in disguise.
Unlike the beginnings of typical game dev projects, where teams are abuzz in a flurry of brainstorming and prototyping, we had to conquer a mountain of paperwork first. To complicate matters, The Hidden Village project is a collaboration between, for all intents and purposes, three universities: the University of Wisconsin, SMU main campus in Dallas, and SMU Guildhall in Plano. In addition to nailing down deliverable expectations from my stakeholders, getting my programming intern on Wisconsin's payroll, and getting up to speed on the game's current state, we had to wait about two weeks to receive the Kinect hardware essential to our development, thanks to a multi-step ordering and approval process.
For anyone familiar with the rapid pace of Guildhall projects, finding yourself in a holding pattern can be an extremely frustrating experience. But it forced me to get smart about how to best use the team's time while we waited, to think about what the project needed beyond simply the product we were working on. And that gap, like many projects, proved to be clear documentation. So I set out to create a library of documents that could help future developers once I left the project: a Technical Design Document (TDD), Asset Database (ADB), Asset & Development Plan (ADP), a Trello board for bug-tracking, and a Google Drive account for file sharing between the various universities, among other things. Meanwhile, I had the team's programmer alternate between reading through as much of the existing code as possible and building a database of resources and tutorials for developing Kinect software (neither of us had prior experience with it).
The results were fantastic. After learning the ins and outs of the Kinect, our programmer was able to hit the ground running once our hardware finally arrived, and he was able to complete a full port of the existing game in only a month. At the time of this writing, the project is about three and a half months ahead of our stakeholder's expectations, and we now have an extensive body of documents to help future teams as The Hidden Village enters further stages of development.
(If you are interested in learning about developing for the Kinect, check out our Research Database here.)
Happenstance provided the perfect usability test group.
The Hidden Village is targeted towards middle school students, and just so happened that our development phase coincided with the Guildhall Academy, a summer camp for middle and high schoolers. Not only did these students fit our target age range, but as aspiring developers themselves, they were very eager to participate and do their part to help improve the game.
The playtest revealed a major design flaw that the team had predicted but had no means to confirm previously: players come in all shapes and sizes, and the Kinect needs to be ready to adapt to that. With only one programmer on the project, the Kinect only had one body type as a reference, and as a result, the game was almost unplayable for several of our testers.
Halfway through our testing group, realizing our usability data was not very valuable given the circumstance, I decided to pivot and have the remainder of the testers help train the Kinect to detect a larger variety of body types. The students were very happy to play their part in helping improve the game, and we were able to begin the foundation for training a better, smarter Kinect. Everybody wins!