Designing a Puzzler VR Application

By Michael Oakes.


The second term of the Udacity VR Development Nanodegree course required me to develop a Virtual Reality Puzzler app for use on Google Cardboard. This post outlines the development and testing process, and the iterations undertaken in order to deliver a fully working Puzzler application.

The puzzle game itself is a simple “Simon Says” type application, whereby the user is required to watch and then mimic a sequence of illuminating lights, by clicking on the lights in the same sequence as the initial pattern. The game is hosted in a Virtual Reality dungeon-like environment, which is aimed to create a mysterious and magical ambiance as shown below.

An early design of the dungeon puzzler play area.


The video below demonstrates the final version of my puzzler VR application, which was built using the Unity development tool and some provided scripts and game objects. We were required use these artifacts to build the environment from scratch, creating a scene using the game objects and amending/fixing the scripts where necessary. I named my application Mayan Puzzler and tried to give an ancient Mayan type theme by importing, converting and implementing some additional game objects from the Unity store and Sketchfab.

A video of the final gameplay on an Android device.

Starting the process

Our initial task was to outline a target audience for whom we were aiming our application for. Once decided, we were required to create a target “persona” to represent an example case of our target audience. I was aiming for a casual gamer who would play on a mobile device without requiring expensive VR equipment.


Sheila — 20, student.

“I like to play games for a bit of escapism, when I get a break between lectures during the day.”

Sheila has a little VR experience.

Sheila is a full-time student at college. When she gets short breaks between lectures she likes to play games on her phone to pass the time and take her away from the college and classroom environment.


With a target audience identified, we need to start to do some rough sketches of our gaming environment. We created a few sketches (dragon, Mayan, pagoda) which you can see below, before making a decision on the layout to use (Mayan):

User Interface

With a gaming environment planned, we were required to design a user interface to allow the user to interact with the game, be instructed on how to play and get feedback on completion of the game. Again this involved doing some rough sketches before deciding on a final choice.

Building the environment and setting the mood

The next step was to build the environment in Unity. This was a painstaking part of the process as consideration had to be given to scale, distance, viewing angles and ergonomics whilst also ensuring that the environment matched our required mood of mystical and mysterious.

Initial build of the Dungeon.
Adding color to the orbs.

Adding movement, game mechanics and user feedback

Once we had built our environment and were happy with its mood and ergonomics, we need to add movement, game mechanics and user feedback to the application. This was the most painstaking part of the process as it required implementing movement and mechanics through C# scripts and the Unity framework whilst ensuring the interaction was intuitive for the user and using design best practices to ensure that risk of causing simulator sickness in the user were reduced.

Game movement between Start, Play and Restart positions.

User testing outcomes and iteration

Throughout the above process, we used an iterative method of development in that we build the sections of the game outlined in the section above and conducted user tests at each stage to ask validate our design decisions and to reiterate where appropriate to ensure satisfactory goals where achieved at each stage. User tests were conducted with an independent user (my wife in this case) because as the developer, the “User Is Not You” and also as a VR programmer it is likely I have developed resistance to the affects of simulator sickness.

The testing at each stages was in the form of a series of questions (ensuring they were non-leading and not dead-ended) and also observation of the user interaction with the app. The notes below outline the questions asked of the subject, and responses given:

Initial Environment, Scale and Mood Test

UI Test

Movement Test

Movement Re-Test

Final Test

Final Re-Test

As shown above, initial outcomes of testing where successful with the user giving satisfactory responses during the testing so no real adjustment was required to the environment, the UI or the mood of the application. However, feedback from my test subject when testing the movement and game mechanics indicated feeling some disorientation and puzzlement when the player was moved backward through the experience to the Start position, after clicking restart.

I made changes to the game restart mechanism accordingly, changing the ‘backwards on rail movement’ to a ‘teleport to position’ movement instead in order to reduce the feeling of disorientation and potential affects of simulator sickness. On re-testing the application, the user confirmed that this removed their feeling of discomfort and improved the experience.

Also on the final test, there seemed to be some initial confusion with the user as to what was expected for playing the game when in the play area. Again I reiterated by making some changes to the UI this time, adding some initial instruction on how to play game which on retest the user agreed would have given them clarification.

Breakdown of final piece

For my final piece, I added in some external game objects to place the dungeon on the top of a Mayan temple with some other Mayan temples visible in the background. The user is initially placed near a Start UI screen. They click on the start button and are transported in a rail type motion to the Play Area. Here they are shown a light sequence of 5 orb lights, which they have to click on in the same order to complete the game. If they get an orb out of sequence the game replays the sequence again for them. On successfully mimicking the sequence they are transported in a rail type motion to the Restart UI screen. Here they can click on the Restart button and be moved by Teleport back to the Start UI screen.

Final UI screens with Mayan Artifacts

Potential next steps

The Puzzler experience is quite short so potential next steps to help maintain user interest may be to add additional difficulty, such as increasing the number of orbs or even the pattern speed of the puzzle. Further enhancement could be the adding of different styled dungeon environments on the other Mayan pyramids which the user could progress too once achieving certain difficulty levels with the puzzle.


Overall I thorough enjoyed working on this project. Although using some pre-built scripts and artifacts, there was a great deal of artistic license in building out a whole scene yourself and plugging the game objects together as you desired. Being able to import and use external game objects helped this feel more like a real development project. Additionally there was some real scripting requirements on this project and many of the provided scripts had framework parts missing or code that was buggy and had to be corrected. I found this more of a skilled task in that you had to correct another persons code, whereas the areas of writing code myself was a lot simpler. And finally going through the planning, testing and documenting process of the development is a good habit to get into.


Acknowledgement goes out to the following Sketchfab artists for allowing me to incorporate their models within my Unity project:

Mayan Temple or Stage by BytesCrafter is licensed under CC Attribution.
Mian Piramyd Aray Cuts Modifier by Julievr is licensed under CC Attribution.