VR Puzzler Project Harkens back to “Stargate”

The coursework for Udacity’s VR Developer curriculum necessitated the design, development, testing, and iteration of a project appropriately entitled Puzzler. The primary goal was to create a mystical dungeon in which the player is asked to solve a light-pattern puzzle in order to move on, or complete, the level. The secondary goals were to design an environmental setting that effectively transports the player to another world and to apply standard VR UI principles to the level design that will facilitate the navigation and comprehension of the application goal.

Outcomes

The Puzzler project proved to be a difficult undertaking as my original concept was somewhat grander than my skill could really afford. I am pleased with the final product, and my friends (testers) were surprised to see the final product actually resembled my initial vision of a Stargate-like setting.

Demo of Puzzler Level
Perspective view of pyramid dungeon in Unity editor

Development Process

Statement of Purpose
Puzzler is a mobile VR game for users new to VR that challenges them to solve a puzzle using a familiar mechanic in a new way.

Audience

Before embarking upon the creation of Puzzler, I took the time to consider who my audience for this application would be. I created personas to represent the types of people that I assumed may be exposed to this or a similar VR app. Malik was a persona that I consider at the core of my intended audience.

Persona Example
Name: Malik
Age: 21
Occupation: Student
Motivation: Malik is a business student with a passing interest in software development. His main daily objective is to get through his classes while staving off boredom. Evenings and weekends are spent watching TV and movies, gaming, and spending time with friends at the local bar.
Experience with VR: Mild experience in Mobile VR with an interest in purchasing an immersive PC VR setup.
Quote: Playing games during class helps me concentrate!

Vision

Development began with the initial paper drawings of what I envisioned an “out-of-this-world dungeon” might look like. Being a fan of sci-fi and fantasy, I immediately drew from my extensive mental library of film and literary fiction for inspiration. I created three unique designs for the assignment.

Initial Puzzler Environmental Visions

I wanted to challenge myself, but not sign-up for more than I could reasonably handle, so I settled on my initial pyramid design. Design #2 (giant forest) seemed that it would require more experience than I possessed in 3D-level design, and design #3 (grasslands w/ cube dungeon) seemed too simple which could possibly cheat me out of a valuable learning experience.

After I decided on the direction I wanted to take, I began building the dungeon using the prefabs supplied to me. This took me a several hours to accomplish given that the prefabs were meant for a cube-shaped dungeon. After some creativity and a rather steep learning curve for correct object positioning, the outer pyramid structure was complete. I quickly realized that I needed to create an inner dungeon room, so the object clipping and exposed corners of the pyramid could be hidden from the player.

Actual Dungeon Room within the Pyramid

Testing and Iteration

Initial testing was centered around environmental scale. I needed to verify that the user felt as if the world and objects around her were the correct size and dimensions.

Early Dungeon Development used for Initial Tests
Initial Tester Feedback
I feel like I am standing on my knees.
The torches on the wall look about half as big as I would expect them to.
Where is the torchlight coming from?

I expected to have to adjust scaling early on, but a light source would have to wait until I moved into environmental polishing. I dialed in the camera height and object size then revisited my tester to verify the changes. Once the primary scaling was complete, I moved on to adding player/camera movement and the game mechanic.

Subsequent Tester Feedback
Felt like floating in. [to the pyramid]
I am too close to the orbs, but the movement felt comfortable.
Oooo, the balls light up. Ok, I get it. I have to repeat the pattern.
Start and restart panels are obvious because of the button highlight.

Accurate camera movement and the game mechanic turned out to be the toughest obstacles I had to overcome for this project. Both of these project aspects were in initial working states during development and early tests, but an environment crash in Unity broke the game mechanic whose solution wound up breaking the camera movement. I developed a few extra scripts to help debug the game mechanic and found that extra method calls were being made when the dungeon orbs were selected. This took both Unity and GoogleVR SDK upgrades to solve. However, these upgrades included the deprecation of several GoogleVR components, Android Manifest XML changes, and new, silent rule enforcement for final builds.

The GoogleVR component updating was simple enough after reviewing the SDK release notes, but after building and deploying the project to my Android device, the main camera movement mechanic failed to execute when intended. Unity testing continued to work smoothly with no thrown errors or warnings related to the camera or movement mechanic. In order to test that this was unrelated to the previous crash (in case there were corrupt settings files), I created a new project with a couple different basic movement mechanics. These worked in Unity but also failed on the Android device. I did some digging around in forums to see if this was an issue anyone else had seen due to the upgrade. The only information I found was unrelated to the upgrade but helpful nonetheless. Unity apparently does not allow the direct movement of the camera. I believe previous GoogleVR components were able to make the camera appear to be in a container thus allowing the camera movement. The change in GoogleVR components must have ceased that function. After explicitly putting the camera into a container object, the movement mechanic began working again on the build device.

I submitted the final build to my tester for review of the working game mechanic, movement, and environmental changes.

Final Tester Feedback
I love the sky.
This makes me think of Stargate”.
The torches look much better.
Oh wow, this takes me backward. [when selecting to play again]

Final Deliverable Breakdown

Environment

The setting for Puzzler is an extraterrestrial desert during late afternoon. A pyramid dungeon in full view of the player, and the stars/galaxy skybox is intended to support the extraterrestrial feel (though if the planet/moon had an atmosphere, very little of this would actually be visible during the late afternoon). This primary visible environment was achieved by creating a custom terrain painted with a sand texture. The pyramid and internal dungeon were created using the supplied dungeon prefabs. Due to the prefabs being intended for a cube dungeon, I had to take some creative liberties with the pieces in order to achieve the desired look of the Pyramid.

User Interface

The UI is represented in three parts, the start panel, the restart panel, and the game orbs. The two panels were created to be simple and intuitive. The idea is to give direction to the user without taking up precious real estate with expository text. The orbs function as the third piece of the UI. This is were usability really hinges. In keeping with the mystery/other-worldliness of dungeon, I wanted to keep it as basic as possible. The course material helped provide guidance in this with both audio and visual feedback.

Player Movement

Aside from being able to look around at all times, player movement is limited to three location translations: from start location to play location, from play location to end location, and from end location back to start. iTween was used to handle these movements. I merely needed to adjust the speed at which the camera moved to make sure it minimized motion sickness.

Game Mechanic

The orbs game mechanic is fashioned after the old electronic game, Simon. A random order is generated at the start of the puzzle. Then, this pattern is displayed on the dungeon orbs. The game then waits for user input. Should the user click on the orbs in the same order as they were displayed, the user is taken out of the dungeon and notified of puzzle solution. Should the user click on the orbs in an order contrary to the displayed order, a failure noise is immediately sounded, and the pattern is displayed again for the user to attempt once again to repeat upon conclusion.

Conclusion

The Puzzler project proved to be quite a challenge, and at times I felt discouraged by the development issues I encountered. But (and this is a very important ‘but’), I reluctantly dug in, and endeavored to complete the task. This project gave me the opportunity to stretch my current development skills as well as learn a few new ones. Terrain was completely foreign to me, and I definitely benefited from extra experience with lighting.

With the application now in a publishable state, I can move on to my next assignment. However, with so many hours invested in this project and it now being a point of pride for me, I would like to revisit it and add some additional content. Specifically, I would like to revamp the main Pyramid in order to present a more seamless structure. Also, the game mechanic could use some tuning as well as the ability to increase difficulty over time. I may create an Easter egg or two, so I can put my official stamp on the application.

Show your support

Clapping shows how much you appreciated Stephen Johnson, PMP’s story.