This week we presented our work thus far to the ETC faculty at what is known as “halves,” around here. It’s crazy to think that we’re already halfway through this semester and that in eight weeks, this project will have concluded and that we’ll be graduating. Days can seem endless but somehow entire months can go by before you even realize it.
The presentation went off mostly without a hitch, and in the photo above, you can sort of make out our unofficial 6th team member, the prototype version of Martian Terrain Surveyor 977-B, otherwise known as [insert name here], because the guests in our experience actually give the robot character its nickname.
Concerns that the faculty had were centered around the nature of the robot’s role in the experience as well as the number of puzzles that we aim to include in the experience. The robot’s role, along with playing a significant part in the story we’re creating, is to provide in-world assistance to the guests and help them solve the puzzles if they’re stuck. In traditional escape rooms, when the players are stuck, they’ll usually call out for help and receive some kind of hint from the escape room staff, completely shattering any immersion that the players feel within the world/story of the experience. Having a robot character that fits within the world of our story who can deliver this information solves this immersion issue.
As far as the number of puzzles we presented (13), not all of these are of equal difficulty, and some can only be counted as puzzles in the sense that the guests have to figure out how to do something and execute an action, not because they’re challenging. For example, early on the experience, guests have to open a crate to progress. This crate is opened by typing the crate designation number into a DOS-style prompt on a computer, at which point a crate opens. Hard? No. But a puzzle? Technically, yes, for our purposes.
After the presentation and feedback, the team wasted no time in preparing for our next playtest on Thursday. We put together a rough animatic of the pre-show video that we’re planning to film so that our testers could have an understanding of the story and world of the experience. Then, with cameras, rolling, we stepped back and observed (except for cases where we needed to explain/facilitate something that would only be possible in the more finalized version that we create).
In the images captured from the playtest above, we can see our testers working together to solve puzzles and interact with the robot character, who they decided to name Murphy. The group had a lot of fun piecing together the information, until they got stuck trying to assemble some bone fragments into a cohesive appendage. This took up most of their time and they were unable to complete the experience, which is, in our case, very problematic!
It’s up to us as designers to make sure the puzzles are easy enough to complete but still feel challenging and give the guests the sense that they are doing cool science. The next step is to determine when and how the robot should intervene in helping the guests complete puzzles.
With spring break next week, this blog will be on temporary hiatus, but we’ll return in two weeks with more tales from Evolve!
