A Documented Approach to Virtual Reality
Following a design process when creating a virtual reality (VR) application.
The 7 P’s. Prior Proper Planning Prevents Piss Poor Performance. Succinct, but too many times I’ve had to learn that jumping in feet first is not the best approach. In order to attack a problem or complete a project, I have to do some homework and head in prepared. This makes for a much less painful process and a much better outcome.
Measure Twice, Cut Once
When first learning development in VR I would dive right into Unity and inch my way through the finish line. This entailed scouring documentation, debugging, trial and error and frequent back-steps.
With this puzzle project from Udacity, I follow a process. If I am to focus on design while creating a familiar game, I need to be prepared.
Have a Plan
The goal here is to build a game people can actually enjoy in VR. My design process includes, but is not limited to
- Who I am building for.
- What I am building.
- User testing and iteration.
In parallel with these steps is documentation. I need to make sure I record my progress throughout. Using sketches, writing down questions and answers and capturing screenshots and/or videos will provide a great trail from start to finish.
Sticking to these steps will help me stay on track as well as create something everyone can enjoy, especially in VR since it is such a new medium.
1. Who I am building for
Obvious fact #1: I know I’m making a game. Someone enters a dungeon, plays a memory game and leaves. Okay, I’m done!
But who’s it for? That would be the persona I create. This lets me know who my end user is and gives me a North star to go back to in case I get off track. When creating a persona, I paint a clear picture of someone who I think that end user is.
Here’s Matt
He’s 25, single and a salesman. He’d tell me,
“I work to pay my high city rent and spend my free time enjoying IPAs on the weekend with my friends.”
His VR experience is none.
Everything during my project, from a design standpoint, will come back to Matt. Am I meeting his needs or just my own?
I know a user with no VR experience will likely be more sensitive to simulator sickness created by some VR applications today. Whether that is movement, frame rates, resolutions etc, I need to account for all of these items at each step. For more reading on simulator sickness, check out Oculus’ guidelines on this topic.
2. What I am building
The other side of knowing who I am building for is understanding what I am creating with a statement of purpose. This can be one or two sentences but this really helps lay the foundation and set the scope of the project.
In my case, for Puzzler, the statement of purpose will be:
Puzzler is a mobile VR game for new users of VR which requires them to solve a familiar puzzle in a new medium.
3. User testing and iteration
The last step and the most extensive is building it! At each step, I draw things out, create them in my VR app, test and repeat. Iteration only works best if I move quick and often.
Pencil beats computer
Sketching out my idea in advance will be a big time saver and a lot easier to reference when building out. I do not want to jump straight into Unity and spend hours making a scene, only to find out it stinks and do it again.
With a few elegantly placed lines, I know the user will start at the entrance of some castle, enter a dungeon where the orbs are (memory game objects) and upon winning, leave out the back. Some background elements are included as ideas for the final renderings.
Then I build the initial structure for the game.
User Interface
In addition to the layout, there’s obviously a need for the user (Matt) to know what he’s in for and how to navigate through the game. If Matt’s a non-experienced gamer, I need to be explicit. Nothing groundbreaking here, but again, it helps to sketch things out before wasting time actually building bad UI’s.
In my case, #3 is the winner. I prefer the rectangle buttons and the idea of a simple animation on the victory UI. If the canvas is placed within the user’s comfortable view, then I can also eliminate any discomfort from the persona’s perspective.
Building the UI
When creating any UI elements, especially in mobile VR, I need to account for low pixel density. This means using large and bold text will be easier to read. Also, placing the canvas 2 meters (2 Unity units) away from the player seems like a good distance to start. Anything within 0.5 meters from the user’s view is too close and considered a “don’t”.
These canvases are created using world space versus screen space. I then scaled them way down, ensuring the text is clear and large enough to read. I think it looks good, but that’s just my opinion.
User Test One
Part of good design is rapid iteration, which means testing early and often and making changes as needed. This is much easier than making big changes at the end. When user testing, I pick one user and ask a few open ended questions about each step of the process. Ideally, I would like five users, but I don’t have that many testers at my disposal for this project.
In my case, the UI is the first test. After explaining to my friend what I am building and what I am testing, I have them check out the UI while in VR.
What do you see in front of you? I see two boxes with text.
What do you think these are trying to tell you? That there’s a game called Puzzler and I can hit start. And there’s a way to play again.
How big or small do you feel in front of the UI? I feel fine. Normal.
Okay, so that is a quick and easy user test. I don’t really need to make any changes, but I validate that the distance of the canvas is good and it is legible. Small tests like these at each step is where I can make important adjustments and iterate effectively.
Constructing the Environment
Building upon the scene according to my sketch is the next step after creating the UI. Fortunately, I have some prefabs of the dungeon scene already created.
Piecing together the building I have a room with some cozy decor, but need to build the castle I have envisioned in my sketch, not just a concrete box. I use Blender to create simple objects, starting with the towers.
Notice that the tower is only created with the sides that I know the user will see. In VR, especially mobile, optimization is important. No need to make Unity render anything that the player will never see. If I look at the front versus the back view, I can see the objects essentially disappear since there is no rendering on the other side.
With the initial level built, it’s on to the next user test. I will not go into the Q&A, but the conclusion is that the scale seems too small and the room is too small. In summary, it feels like an itty bitty level with a giant player.
Build and Scale
Revisiting Blender, I create some more castle walls. At the same time, I create the environment by adding a terrain and to keep things eerie, a black skybox. I am going for spooky, so as long as the user test validates that, it’s a success.
With the building scaled up, I test again and confirm that the changes are on point. The new feedback is that the castle itself doesn’t match…true. Also, the exit seems to be too close, visible and is distracting.
To address each, I go in and reapply materials to the castle walls ensuring that they are all the same. For the exit, I add a hallway that the player can leave through, providing a less abrupt exit. After another test, everything checks out.
Final Optimization
Going through the objects in my scene again, there are a couple things I need to confirm. Since I am building this as a Cardboard VR app, in order to easily optimize this, I ensure that anything not moving is marked as static. Any shaders on each object should be mobile>unlit (supports lightmap) and in my case, all lighting is baked.
This takes forever to render, but once I generate the baked lighting, all the lighting effects are rendered on the textures themselves. If all my lighting is baked, anything not marked as static will not be included.
Baking the Non-Statics
The orbs in this app that serve as the memory game, are not static, but if I bake the scene they do not seem part of the environment. Since they are not static, only realtime lighting will be applied and my lighting is all baked. The current set up just looks like they’re floating there and not quite part of the scene.
To fix this, I mark them as static, bake the scene and again, make them not static. The result is a nice lighting effect on them, producing good shadows on the floor.
The Puzzler Pieces
It is now complete! With all the steps that went into getting here, it’s time to see the finished version. Below is sample gameplay footage of Puzzler taken from Unity editor. The game is played like this…
- Once the player launches the game, they are presented with a start UI. This welcomes them to the game and provides a call to action to hit START.
- After selecting start, the player is moved forward into the castle dungeon where they are presented with five orbs.
- The orbs will light up in a random order five times. Audio for any orb lighting up will also cue the player something is happening. During this time the user’s input will be disabled and they cannot select an orb until the sequence is finished.
- Once the pattern is displayed, the player clicks the orbs attempting to replicate the sequence. If selected incorrectly, the pattern will display again. If selected correctly, they will be moved out of the dungeon through the exit.
- Upon exiting, the player will be presented with a victory UI, where they will have an option to select ‘Play Again’ and recreate the experience.
Finishing Up and Continuing On
A lot of ground was covered here in regard to designing my game. Remember those 7 P’s? If I consistently follow a process during the planning, building and testing of the application, life is much easier when fixes are needed. That means I know who I am building for, what I am building and I am always testing and updating. Rapid iteration is important to moving quickly and creating an experience that everyone will enjoy.
The next steps are to come back to Puzzler, adding more levels and challenges, all while following the design process. I hope you are able to utilize any of these concepts in your projects in the future. If you have any questions or suggestions, let me know!
