Introduction

The aim of the project was to create a small puzzle game for a mobile VR device. Learning the development process of a VR environment, targeting the experience to users instead of myself, and iterative development including user testing were key aspects of the project.

In addition to the minimum requirements done in the lessons, I wanted to try to create something unique; I added the pulsating magic barrier behind the puzzle and timekeeping for this reason.

This project was for the VR Design of the Udacity VR Nanodegree course.

Results

A playthrough video is available in YouTube.

Development process

We started with a statement of purpose:

Puzzler is a mobile VR application for new VR users which challenges them to solve a familiar type of puzzle in a new way.

An exercise user persona for the target user was created. Initial sketches of the play area were created to brainstorm some ideas for the puzzle.

User testing was used in various stages during the development to verify different choices in the design.

Personas

I created a user persona based on a friend. My test subjects ended up a bit younger and varied more in the amount of play experience, but it did not really have a negative impact.

Tim, 51

“I enjoy being challenged”

Tim and his family live in a house he renovates himself. Tim has great attention to detail and works as a mechanical engineer. Tim has been gaming for decades on various platforms and gaming devices. Tim enjoys games with a social aspect, but soloes as well. He often plays games with his children as he enjoys spending time with them.

VR experience: limited to none.

Sketches

I created sketches for the user interface menus, which were just two menu panels to start and restart the game.

I also created sketches for the play area, but in the project I just used the pre-created dungeon instead of creating a new scene from scratch.

Iterating with user testing

A lot of user testing was done, almost after every addition in the scene. In the beginning, the user tests were very short due to the very small number of user interactions available, but in the end, with all the game mechanics, these took many minutes per participant.

User testing was done mostly with my wife as the subject, and I discovered a lot of issues in the game with her assistance.

With user testing, I verified that:

• the UI is intuitive
• the dimensions of the dungeon and play location felt natural
• the ambience, lighting, and sounds are as expected
• game mechanics and feedback are intuitive and function correctly
• simulation sickness is minimal

In total, I had 5 subjects try out the game, all of whom were novices with VR applications.

If more than one person participated in the user testing, the tests were done in isolation, so that the test subjects were not affected by each other. The questions that were asked from the subjects were mostly predetermined, with the exception of some follow-up questions. Leading questions or questions with just yes or no answers were avoided.

I give an example of a user-testing session in the following section.

Initial user test

User testing with two people, J and D. The users were interviewed separately to avoid corrupting the results.

Me: Can you describe for me the dimensions of the place, do you feel very big or very small?

J: Door couple of meters (high?), about 10 meters to the back wall. Looking up, the ceiling somehow feels closer than when looking to the far end of the room.

D: The room is about 10 metres long and 3 wide. I feel normal-sized.

Me: Can you describe the mood of the place, the overall feeling you get?

J: Dungeon, some kind of puzzle, mainly because of the orbs.

D: I get the feeling of Dungeons and Dragons dungeon. Orbs are weird.

Me: Do you have any problems observing anything? Can you see the orbs without moving your head?

J: No problems. The fact I can't see my legs makes me a bit dizzy.

D: No problems.

Early screenshot of the project.

Actions

The scale and mood are ok based on the user testing. Neither subject made a mention of a magical pulsating barrier that I put behind the orbs, so it may be a bit too subtle. I was looking into making it the thing that logically blocks the traversal through the room. I'll add some sparkling and maybe accentuate the pulsating a bit for further tests.

Final version

In this section, I go through the design decisions in the game.

Start menu

I wanted an atmosphere in line with the provided dungeon template, and I chose a nebulous background image as the skybox. This gives the illusion of floating in space.

When clicking the start button, the player is moved to the dungeon play area.

Play area

The template project and the course videos encouraged building a room in a dungeon for the play area.

The torches in the wall have point lights to make them look illuminated. The orbs are lit from above to highlight them for the player.

The orbs automatically play a sequence, and the player should repeat it. On error, an indication sound is played and the sequence is shown again for the user. On success, the magic barrier briefly flashes and disappears, a success sound is played, and the player is moved to the restart menu.

The sounds here comprise the clicking of the orbs and the ambient eerie background tune, in addition to the success fanfare and failure alarm.

Magic barrier

I wanted to add a reason for the player to complete the puzzle. A pulsating magic wall behind the orbs and in front of the exit should underline the motivation to pass the challenge.

Restart menu

The restart menu congratulates the user and gives the time spent on the puzzle for the user for small replay value.

When pressing the restart button the dungeon is reset and the player is moved to the start menu.

Conclusion

In the process of creating this game, I learned quite a bit about Unity scripting and animation while getting familiar with the scene editor and data model in Unity.

The project took a very long time, more than a year, for me to finalize as I encountered some crashes that were fairly tricky to debug during development and I just did not find the time to debug the issues. The issues were not big and were mostly due to missing connections in the Unity editor, but the error messages that were given in the debug log in Xcode did not really help at all. A couple of issues got resolved only after I upgraded GVR or upgraded to use ResonanceAudio instead of GVR audio; these resolutions required a fair amount of work, not really related to the project and VR development.

When writing this report, I noticed I had been a bit lazy in writing the user testing reports, and I need to improve this aspect in my upcoming projects.