Developing a VR Escape Room using physical objects

Formal title:

Audio-Visual Experiments: Increasing Presence in a Virtual Environment by Adding Physical Objects

Semester:

5th

Year:

2017

My roles:

Research, Writing, Game and Puzzle Design, 3D-modelling, Audiovisual Production, User testing, Evaluation

Overview

This was one of the most fun projects we did during both the Bachelor's and Master's programs. We developed an short escape room experience in virtual reality, and we tested it in two conditions: one was a purely VR experience, but the other condition had a twist where two key items in the VR experience were also physically present at the exact location where they stood in VR. The aim with the physical objects was to increase presence in VR. While unfortunatly there were no significant differences in presence between the two conditions, we ultimately created an interesting and fun experience. There is a lot to this project, and if you would like to know more, you can read the project report and the portfolio.

Using VR equipment has the drawback of limited space that we could make use of. In order to "increase" the play area, we employed self-overlapping architecture, where the rooms basically occupied the same physical space, and this involved tricking the users using change blindness. We achieved this by moving the door to the room the user entered when they were not facing it, which was achieved by the placement of the puzzle in the room. No users detected the change in the door's location.

Image depicting our self-overlapping architecture.

We created a few puzzles for the experience, and we decided on three to use in the actual tests: a riddle, a cipher wheel and a puzzle using lights. The pitfall of doing puzzle games is that they are fun to design, but one has to make sure that the users can actually understand the mechanics of the puzzle. Unfortunately we were so tangled up in designing the game and implementing it, that we did not put emphasis on early user testing. This ended up with some users struggling with some parts of the puzzles and they needed hints to solve them. While this is not necessarily a problem, I feel this could have been avoided with more careful designs and a way to teach the mechanics to the players within the game.

This is how the users experienced the architecture.

In the end, I came away from this project with some important lessons in design, the need for prototyping, planning and executing of user testing. I still think fondly of this project, but with 5 more semester's worth of experience following this project, I believe this could be improved to create a really good experience with a few tweaks to the process and system. The design lessons I have gained here came in handy in designing Hallowgods and the game for our Bachelor's project.

Puzzle Design

Here you can see some designs of the puzzles we created for this game. We tried to create more than we knew we would get to use, so we could see what is possible using our setup and room design that would also fit with using the physical objects. Some of these initial ideas ended up being slightly modified and combined for use in the game. Since the real objects would no be moved during the test, we had to keep in mind that they had to be placed strategically and made use of in one way or another. For example, when the player completed the third and last puzzle, they got to open a chest. Since the chest stayed in place, that meant that there would have to be something there in the first room as well, and we created a barrel model with the same width and height to indicate to the players that something is there so they don't accidentally trip and fall over it.