Udacity VR Nanodegree, Project 3:

A Maze


When I saw that I'd have to build a functional maze game, I was intimidated. How would I create a believable and fun interactive world? How would users navigate my scene? It would also mean lots of C# scripting (something I'd never done!). This project took about 30-40 hours to complete plus an additional 12-14 hours of Udacity Classes and research. I created a very intricate maze design that's fun, challenging and feels like a real game!

The game was created using Unity 2017.1.0p4 and GVR SDK v1.60.0 and deployed on iPhone. See below for a walk through of the gameplay.

    My Process:

    I started by building the maze itself using pre-existing wall prefabs, where each block was made up of two wall pieces and an adjoining column. To make the design as intricate (and complicated!) as possible, I set up an 8X18 grid using my walls. I then deleted 1x1 walls from different sections of my grid to make a maze that worked! See below for an overview of my maze (which also gives you the solution!)

    Screen Shot 2017-10-02 at 10.44.15 PM.png

    I then worked on placing my waypoints and coin collectibles, key to the temple door and UI displays inside the temple. After the designing process was complete, I worked on scripting that:

    • Made the coins disappear after making a sound and 'poof' display when clicked on.
    • Opened the temple door when clicked on, only AFTER the user had found and clicked the hidden key.
    • Allowed users to reset and restart the scene after completing the game. 

    Scripting in C# was definitely the most challenging part. I was still in the process of learning the language but found that the more time I spent with it, the more intuitive it became. The scripting in this project now seems so easy! Regardless of that, I still spent way more time on designing and building than I did on scripting (maybe a 70/30 split).

    User Testing

    After building the game, I tested it with a few users. The number one problem was that people didn't understand the aim of the game. That's when I decided to test out a little bit of scripting and UI toggling by creating a different 'opening scene' that asked users if they wanted to play a game and gave them the rules:


    Creating this scene was easy but it took me a while to figure out the scripting to toggle between the UI's. I used Unity's Manual (which is epic by the way) to figure out how to allow the user to toggle to a second UI after clicking 'yes' to the 'would you like to play a game' question; and then send the user to the maze scene after they'd read the rules. The environment was made using a free skybox that I thought gave the game a sense of mystery.

    My grader for the project (a sort of user tester) suggested I add a coin collection scoring system. I took the suggestion and created a script that allowed the user to see how many coins they'd collected after completing the game. 

    Breakdown of Final Design

    The game can be broken down as follows:

    1. Read the rules of the game in a separate scene before being transported to the maze.
    2. Use the waypoint navigation system to navigate around the maze and collect as many coins as possible on your way.
    3. Find the hidden key to the temple.
    4. Find the door to the temple.
    5. Enter the temple and see how many coins you collected in total.
    6. Click the 'restart' UI to play again!


    I loved this project because it gave me a really deep end experience of programming and designing for Virtual Reality with Unity. Here are some of the things I learned:

    • Creating new C# scripts in Unity
    • If then, loops, arrays, and other programming constructs
    • Attaching scripts to objects
    • Using the built-in Monobehaviour methods
    • Triggers and Gaze Based Interaction
    • Creating, moving and animating objects procedurally
    • Scripting Dynamic UI Objects
    • Debugging
    • The Unity Event System.
    • Managing and Reloading scenes.
    • Controlling particle systems.
    • Create an Audio Clip and playing sounds.
    • Waypoint Navigation System.
    • Profiling scenes for performance.

    At the time of creation, it was definitely my most challenging project. Even though I'm extremely proud of it, there are several pain points I'd like to improve on going forward.

    • The waypoint navigation system isn't always the best navigation tool. The waypoints can seem obtrusive and the range of my pointer for this game was quite short meaning I had to create a LOT of waypoints. Users and I found it quite painful to use. I hope that I can add an autowalk system that doesn't use teleportation between points but rather, a gradual movement between points. I also figured out how to increase the range of my pointer which would allow maybe only one navigation point per corner, or 1x1 space, of the maze.
    • To create a random maze generator. I would have loved to have the maze change every single time the game was played! There are several random maze generators accessible in the asset store that I can add to my game. The reason I didn't add one is because I'd made my game using individual blocks of prefabs to create my own grid instead of creating single column/row blocks, evenly spaced, that a generator could automatically "chop up". Even when I'd deleted blocks of my maze, I would have to manually re-size and move blocks to get rid of small gaps and un-evenness.
    • Adding checkpoints. I would have loved to have UI check points that told a user if they'd been to a certain point or not and if they were on the right track! Because the maze is quite difficult and the waypoint system isn't the best, these checkpoints would have made the game easier.
    • Adding enemies! This would have made the game more challenging. Enemies, in the form of monsters or robots, could return a user to the last "checkpoint" if interfered with! Wouldn't that be fun?!

    Check out the full project on Github