The VR Maze project is a prototype demo created at the Center for Immersive Experiences (CIE) for potential collaboration and research opportunities. The goal of this demo prototype was to create a maze environment in Virtual Reality (VR) which users could navigate, discover, and explore. This post will cover the initial steps taken while developing the first prototype for the project.

 

 

 

This post will cover the following sections:

 

Intro

Mazes have been used for storytelling, art, entertainment, research, and so many other fields for most of human history. I imagine every one of us has seen, solved, visited, or interacted with at least one maze throughout out lifetime. That being said, its no wonder that mazes are so often used for a variety of research endeavors.

The VR Maze project is a prototype demo created at the Center for Immersive Experiences (CIE) for potential collaboration and research opportunities.

In this post I will cover the steps taken during the development process of this prototype demo. For this demo, we were requested to build a maze made of discrete grid squares which a participant would be instructed to navigate. This maze needed to be built and run in Virtual Reality (VR). Unlike most VR applications which give the user a variety of options for movement mechanic and teleport functionality, in this prototype the users would need to be restricted to only moving to grid squares adjacent to their current location. This would limit the users movement to one square at a time, creating a direct trail or path throughout the maze environment.

 

Grid Builder

When starting development on the prototype for this project, the most logical first step in my mind was to create the grid of tiles for the maze. Normally, most people would imagine that the easiest way to set this up would be to use a two-dimensional grip similar to a piece of graph paper composed of sets of rows and columns where each square or tile inhabits a coordinate location comprised of an X and Y value. Conceptually, this matches the way I picture the tiles. But building and navigating two-dimensional arrays in code can get tricky, and the Unity Engine doesn’t tend to like when a developer builds things this way.

So, in order to build and navigate the structure of the grid and tiles, I thought back to one of the earliest projects I build when first learning to be a programmer. The project is a staple of computer science education, a programming exercise called “Conway’s Game of Life”. For this project I had to create a one-dimensional array but use X and Y coordinates in conjunction with the width and height values of the grid in order to navigate and display the one dimensional array as through it were a two-dimensional grid. An video example of my game of life school project is displayed below.

 

 

 

The same concepts, logic, and algorithms were also used later in my schooling while learning about rasterization and computer graphics. Rasterization essentially uses this same idea of creating a one-dimensional array of pixel data which gets displayed as though it were a two-dimensional array when it gets displays to a computer screen.

 

Naturally, these previous experiences instantly came to mind when I was asked to create a grid of tiles to be used in a maze. I started this development by writing code that would use height and width values to create and place cubes in the correct positions to form a grid. All while saving each cube in an organized one-dimensional array for quick and easy access later.

 

 

 

 

Grid Tiles

Now that I had the functionality for building and placing the grid, I wanted a way to easily track, save, and navigate the contents of the grid. So, I created the grid tiles functionality. This simple code allowed each grid square (tile) to save pertinent information about its location in the one-dimensional array, as well as it’s coordinates within the two-dimensional grid structure. Each tile’s one-dimensional array location gets saved as a Tile ID number. Each tile’s location coordinates get saved as a simple X and Y value.

Eventually I would add additional data storage functionality to each of these tiles such as occupied state or ability to be teleported to, etc. But for the initial setup of the prototype, these three saved starting variables made navigation of the grid through code very fast and easy.

 

 

 

Grid Manager

With the grid built and the tile data saved, it was now time to build a Grid Manager to track some additional functionality for the grid and maze prototype. This manager allowed me to save useful data such as which tiles were walls, which tiles were the starting and ending points for the maze, which tile the user was currently occupying, and which tiles were viable options for the user to teleport onto from their current location.

After creating some additional editor code functionality, this manager allowed me to easily build, edit, track, clear, or rebuild the grid and grid tiles.

 

 

Tile Color Change

While developing prototypes and new functionality in Unity, I often find that adding visual debugging elements to the code helps streamline the debugging process. These can be extremely useful when something isn’t working correctly, and a bug needs to be hunted down. They can also be extremely helpful in simply verifying that a new piece of code is functioning as expected.

To make sure that my logic and code worked correctly while navigating and manipulating the tiles of the one-dimensional array when displaying and treating them as a two-dimensional grid, I added a visual debugging element to the grid tiles in the form of a color change feature. This color change mechanic allowed each tile to visibly change color based on certain states it could be set to throughout the experience.

This feature can be seen in the short video clip below. In this clip, the tiles change colors to indicate being in one of three states. The blue tile indicates the location that the user is currently occupying. The green tiles indicate locations that are currently valid tiles for the user to teleport/move to next. The red tiles indicate locations which are currently not valid teleport/move tiles. The white squares are locations where walls are currently covering the tiles underneath.

 

 

 

 

Tile Labels

The next element I added to each tile was a text canvas used as a label. These Tile Labels allowed me to display various information about each tile, adding further visual debugging functionality to the system. Which the click of a button I could now get each tile to display in text its tile ID, X/Y coordinates, and tile state. This feature could also be hidden just as easily for user demos and eventual project builds.

 

 

 

 

Movement Tracker

Since most of the project prototypes created at CIE are intended for educational classroom use as well as research, it made sense to me that some form of data storage or collection feature would eventually be useful if not required. So, the next element I built was the Movement Tracker. This functionality allowed me to create a dataset of relevant information about the user’s location and movements throughout the maze experience.

Each time the user moves to a new tile, a new entry is created and added to the dataset. Each entry stores the tile ID for the occupied tile, the timestamp when the user moved to the tile, the timestamp when the user exited the tile, and the duration of time the user spend occupying the time during the visit.

After getting the basic setup of this movement tracker working correctly, I then added a few additional data points which I assume may be useful to researchers using this program. The next data points I added tracked the total number of tiles in the grid, total number of visitable tiles, total number of wall tiles, starting tile, ending tile, total number of tiles visited (moves made by the user), number of unique tiles visited (excluding duplicate or revisited tiles), and duration of time spent completing the maze.

 

 

 

Movement Replay

Going further above and beyond the initial requirements for the prototype, and anticipating potential future requested for additional features, the next element I built into the project was a replay mechanic. This Movement Replay functionality creates a duplicate of the player which uses the information stored in the movement tracker data set to replay the user’s original movements through the maze. The duplicate of the player moves to each tile that the user had visited during their time in the maze. These replays could be created at any point during the maze and would replicate the user movements up to the point that the replay was created.

Although this functionality would most likely not be utilized while the user is actively solving the maze, it seemed to me that researchers would be able to use these replays to gather additional data at any time after the user has completed the maze.

 

 

 

 

Data Export Setup

Tracking and saving data and datasets during an experience can be very useful for research purposes. But what good is this data if it only exists while the program is actively running? With this thought in mind, the logical next feature for me to build was a method to export the saved data.

The Data Export functionality is not complete at the time of writing this. Without knowing what method or format future researchers may want this data exported in, it didn’t make sense for me to build an entire data export mechanic. But, with future additions in mind, I did build the foundations for a data export feature into the current prototype.

This data export foundation allows me to automatically organize and consolidate all of the data saved in the movement tracking dataset and display it in a single textbox. This feature also makes the text displayed to this textbox easily available in the code as a string, which future code/functionality can easily access and export. Building this foundation means that if/when a collaborator or researcher does eventually request the movement tracking data in a specific format, the development team can easily access it for the export process.

The image below displays an example of this exported dataset shown on a large example panel placed above a maze.