This trimester I have been fortunate to work on an Augmented Reality project for a client in Studio 3. The AR app, which we called Project Sapling, is an entirely different product compared to the game we normally make. Serious Games – games with a purpose outside of entertainment – are a category that we never touched before now, and in doing this project I’ve learned a lot about how Serious Game development differs from regular games.
For one, the game is targeting an entirely different customer. While normal games might target an emotional response in a specific demographic of people, Serious Games are caught in the middle – how do you design an experience that teaches students a very specific list of criteria while also remaining engaging regardless of how boring and disengaging the content may be in any other setting? The secondary challenge was that while the product needed to meet the needs of the customer, the end user was the consumer the product was created for. So while the product we created was intended to demonstrate the value and ability of the product at the high-level for the customer, it needed to also appear to provide value and engagement for the school kids it is designed for, which needs a solid testing methodology to do correctly.
During development we employed a variety of testing “layers” to break down the testing process into a few procedures.
During the first stages of development, we created layouts of our menus and basic features. For every feature that we implemented, we tested it individually and as a group to highlight any bugs and issues. At this initial stage, we were testing the finer aspects of the product based on our design, so we weren’t seeking feedback about our design more broadly, because we aren’t the customer or end user.
We continued this approach throughout development, as mini games were finished they were added onto the testing stack and were played by everyone to ensure they were ready for showing to the client, in addition to visual features, like textured buttons and the like to ensure that we weren’t complicating the experience or introducing bugs or hitting software and hardware limitations with our test devices.
Each fortnight, we met with our client to show him the progress we’d made and discuss where to go from here, similar to a scrum meeting. We would demonstrate the features and content we had added and he would asses where we were at with our design and process as a whole. The feedback the client provided was for our design more broadly, he would provide suggestions and criticism for our mini games which we would take into consideration and demonstrate to him our solutions for the next fortnight.
Benefits and Limitations
This cyclical approach to testing for both low and high level features was very effective, and meant that we had a solid and complete source of criticism for all aspects of our game. We were limited in that we didn’t have access to our demographic’s school kids for testing, so all of our feedback in that regard was helped by researching similar products in the market for both AR apps, education products and apps/games for kids as a whole. The two-stage approach to design afforded us the feedback we needed to continue to iterate on our product and give us the time to properly address the feedback continuously.