Process: Puzzler 👨‍💻

Over the past few months I’ve been studying with Udacity to learn VR software development. The course has been great so far, so I thought I’d share a little of what I’ve been up to with a game called “Puzzler”.

About Puzzler

Puzzler is a simple VR experience for Google cardboard. Basically anyone with a phone and a $15 cardboard headset can give it a try. The game has a simple UI where the user is thrust into a dungeon, where 5 magic orbs present a puzzle. Successfully playing a single round of “Simon” gets the player out of the dungeon to victory.

Here’s a brief video of the “final” version of the game:

[wpvideo 8UewsFr7]

The process

Of course, I didn’t just wake up one morning and build this thing. There is quite a process to go through to create a good VR experience. As I mentioned on this blog before, a good process can make all the difference when you’re building for someone that isn’t you. Which, let’s face it, is almost always.

The approach taken for this work was no exception so let’s break it down a bit.

Statement of purpose

I started the process by creating a simple statement of purpose for the game:

Puzzler is a mobile VR app which gives new VR users a quick taste of VR via their existing smart phone. The entire experience should take no more than a few minutes and be accessible to most anyone that's physically able.

With this in mind, I selected the nearest available human to be a test subject and personify my ideal target audience. My 6-year-old daughter Emma was the winner on the day. When starting out the build, first I documented a little about her, so I had a clearly defined outline to work too. Here’s the persona for Emma:


Name: Emma
Age: 6
Role: Child
VR Experience: Has played a few simple VR games, but not many
Quote (that sums up their attitude): “Can I play with your phone thingy, it’s cool.”
About this person: Emma is an enthusiastic VR user, she loves to explore and have adventures. She’s young and enjoys content that's exciting and interesting, but not too scary or intimidating. She will ask lots of questions and enjoys the discovery. I think it's fair to say she has moxie.

With a clear purpose and audience/persona defined it was time to get going with an initial design and an “alpha” build of Puzzler.

Concept sketches

I started by creating a bunch of really nasty looking sketches for what puzzler might look like. And when I mean nasty I mean nasty.

Here are a few concepts I had for the game initially:

My thinking with the above designs was my audience is young. Given that, it was better to use a large simple UI that could be easily understood and a very simple scene design that wasn’t overly difficult to understand. Once I sketched out something I was happy with I then took the designs and built something in Unity.

User testing

With the first cut done it was time to get going with user testing. It’s so important to get an early version in front of your audience to test assumptions. My early tests were really all about determining the basics, like the scale of the scene in relation to the subject.

Basically, from there on it was a process of iterating on the project. A mix of making assumptions, asking questions, and testing it all as often as was practical. To give you some idea of the things I asked, here’s a few of the Q&A sessions I had with Emma:

User test 1

Me: How big do you think you are in this scene?
Emma: I feel a bit smaller, normally I think I’d be taller than that barrel. I feel little.
Me: What’s the mood or atmosphere of the environment?
Emma: A bit spooky, but I like the purple balls. Not too scary, there are no witches, I don’t like witches. It’s a bit bright for a dungeon though.
Me: Is there anything you find difficult to see, or anything visual you think could be improved?
Emma: No I can see everything, but I can’t hear anything should I be able to hear things?
Conclusion: Emma picked up on the spooky dungeon, she was feeling too small so I adjusted the player's height slightly. I moved the orbs to be closer to the player since Emma liked them so much. I also added some sound to the environment.

[wpvideo yRXZXHVj ]

User test 2

Me: How big did you think you are in this scene?
Emma: I think it's right. I'm the right height.
Me: What’s the mood or atmosphere of the environment?
Emma: Spooky, the sounds are spooky, it sounds like night time. It’s a bit dark.
Me: Is there anything you find difficult to see, or anything visual you think could be improved?
Emma: The balls are too close to me. I feel like I’m going to bang into the balls.
Conclusion: Emma feels the right size now, but I think the scene is a bit too spooky for her now and the orbs are making for feeling a bit close. I’ll move the orbs to a different location and increase the lighting a bit so it's not so scary.

Emma hard at work user testing

User test 3

Me: How do you feel about the scene
Emma: It looks cool, I like the lights, it feels dark outside and spooky inside, but warmer.
Me: Do you understand how to start the game
Emma: Yes I click the big “Start”
Me: Do you know how to play the game?
Emma: Yes it's like “Simon says”. I do what the puzzle does.
Me: Is there anything else?
Emma: The balls are in the way of the door. I have to crash into them when I win. The game is too hard for me.
Conclusion - The game has matured to the point Emma is happy with it and can play it well, she still isn’t happy with the placement of the orbs so I’ve moved them back and did a quick retest, she’s now happy. I also reduced the complexity of the game to 5 steps.

[wpvideo lglcbCAV ]

Breakdown of final deliverable

So, in the end, we’ve got a dungeon puzzler that isn’t too scary for a 6-year-old to play. Emma likes the game and can successfully play it.

The basic break down of the “final product” is:

  • The user is presented with a simple UI screen to start the game.
Screen Shot 2017-07-30 at 3.06.40 PM

The start screen as see from the Unity editor

  • On clicking start the player is moved into the dungeon where they are presented with 5 magic orbs. Emma’s feedback had a significant influence on orb placement and the feel of the dungeon.
  • The orbs chime and blink in a random sequence which the player must complete to “escape”.
Screen Shot 2017-07-30 at 3.05.49 PM

The magic orbs as seen from the Unity editor

  • If the player fails to repeat the sequence a “fail sound” plays, and the puzzle is repeated to give the player another chance. If they get it correct they’re moved out of the dungeon and are presented with congratulations and the ability to restart.


Over all, it was a fun educational exercise doing this project. Plenty of things to learn from a process perspective but also in Unity 3D development. The work has given me a few ideas for other projects to experiment with, and further solidified my view of user testing and rapid iterations in the development of a product.

Next steps

Next I think I’ll move on to a new project, but stay focused on something for that target audience. I think it would be of value to include a few more testers, including Emma’s brother and friends.

If you’re interested in playing around with the above project I’ve shared the source code via bitbucket. The other projects I’ve done via the Udacity course are also available on the Geekpulp bitbucket page.

Hardware for VR development 🖥

Starting out in VR development it’s easy to think you’ll spend the earth on special hardware to get going. The reality is that’s just not true. The below 360 image (which I took with the google street view app on iOS) is fairly rough as 360 images go. The room was a mess as I was in the middle of a fairly ugly hardware transition. The stitching isn’t very good, so there’s lots of bung parts to it, but you get the idea of the space and gear I work with.

Until recently I was using a late 2009 Mac Mini and was managing just fine on my Udacity VR developer course. Well I was managing, not sure about the fine part. So I upgraded to a late 2012 mac mini, still 5 year old hardware, and I’m going gang busters doing google cardboard development with it.

[vr url= view=360]

Here’s a few more details on the hardware setup i’m running in the 360 image above:


Displays – Two second hand 1080p displays I purchased on Trademe for $300 total. The one on the left is in portrait orientation for my code editor. The one on the right in landscape for the Unity editor. Both are on this monitor stand I purchased from PB tech for around $100.

Input devices – There’s a bunch of keyboards in the shot but the one I’m actually using now is a Logitech K380. I managed to get a refurbished one on 1-day for $40 shipped. Honestly it’s such a good keyboard I’d be happy to pay retail for it. Logitech claims 2 AAA batteries will last 2 years. Far better than the 2 months I was getting out of my Apple keyboard and a fraction of the price. For a pointing device I’m using a stock standard magic mouse. I’d prefer a Logitech MX Master 2S, but it’s a nice to have rather than a must.

Computer – I have two in play now. My development machine is a late 2012 Mac Mini I purchased on Trademe for $500. Even though it’s from late 2012 it’s actually the fastest model of Mac Mini ever made, the quad core i7. I’ve put 16GB of ram in it and replace the spinning disk with an SSD. I’m really happy with its performance. It does everything I need for Unity development, especially given the contrast of my other machine the late 2009 Mac Mini. That machine is now running as the server for the house. I’ve modified it a bit adding 4.5TB of storage and 8GB of ram. It can no longer run the latest version of MacOS but it’s doing a great job as a cache and Time Machine server.

Future plans

Audio hardware – Something I’m really aware of with VR is the impact of audio. Obviously visuals are important in VR, but good quality audio can also have a huge impact on immersion. It’s also very useful in directing the users attention. I’ve got a few bits of hardware on order to support creating more of my own audio for various projects. The main bit of kit is a USB audio interface, or more specifically a Focusrite Scarlett Solo (2nd Gen). I got mine via Amazon as it actually worked out a bit cheaper than buying local, even with the shipping costs via youshop.

I’m trying to play a longer game with this purchase. It’s likely better than I need at this stage, but it will last me 15 years or more.  With budget in mind, for the rest of my audio gear I opted for a cheap XLR mic, arm, and pop filter from Aliexpress. I’ll upgrade those later when I have more funds available and other parts of my setup mature.

360 camera – At the moment i’m just using my iPhone 6s and various 360 apps. Over time I’m expanding my capabilities as I need/can afford them. I’m in the market for a 360 camera, likely something like the Ricoh Theta S or a 2017 Gear VR camera. I’m hoping to purchase one of these in the next 3-4 months.

Mac Pro and a 6DOF VR setup – Ultimately I want to replace my Mac Mini with a far more powerful setup so I can expand into more immersive VR development. I’m aiming for a new Mac Pro when they become available later next year. I’m also delaying purchase of something like a Vive or an Oculus as long as I possibly can. It’s such early days in VR hardware and i’d prefer to wait to buy when there’s gen 2 or even 3 out. I suspect 2018 is going to be an expensive year.

The thing to take away here is you don’t need to spend the earth to get started with VR. Some second hand hardware and a drive to learn will take you a long way before you need to invest more.

Locomotion 🚂

You know what’s really fun? Being able to move around and interact in a virtual environment. You know what isn’t? Barfing all over your new all birds.

That’s exactly what’s at stake when designing a good VR experience. Particular one that includes movement. When developing for VR it’s important to build a good understanding of “simulator sickness” and what can be done to eliminate, or at the very least, minimise it.

Just like with other forms of motion sickness, simulator sickness affects different people in different ways. As it’s still early days of mainstream VR, there’s still a lot of research to be done into causes and solutions. Having said that there’s also a lot of good material out there that can help you provide comfortable experience for users.

Some general rules of thumb to follow include:

  1. Tightly control the users speed and rate of acceleration. Slower speeds are generally more comfortable for users, as is a very high rate of acceleration. Any gradual acceleration at all in VR can trigger simulator sickness so it’s best to keep speed transitions short and infrequent
  2. Leave your user in control of their vision. In other words don’t disconnect what you see from the users head tracking. If you need the user to look in a certain direction use other techniques such as sound or lighting to draw their gaze.
  3. Make sure your experience is performant by maintaining a suitable frame rate. 90 FPS is optimal.

The best way to stay on top user comfort is to test things on them as early into development as possible. Ask them questions about their comfort levels and always make sure you let them know to remove the headset right away if they feel any discomfort. After all, The last thing you want is to push a tester to the point of ruining their shoes.

VR and the power of scale 💗

One of the most powerful things about VR is its ability to have a shared experience at scale.

From an education perspective this is an extremely exciting thing. The below TED talk is a fantastic example of how VR can bring multi million dollar facilities to every student without the cost of traditional real world labs.

Not only that but the evidence in the video suggests that combining teachers and VR in this way results in a 2x improvement in learning outcomes. Just awesome!

Process: User experience testing 🔬

As I said in my previous post on process, it’s important to test your work early and often. This means getting in front of your users and collecting feedback, aka UX testing.

When you’re starting out with user testing it can be quite intimidating, but with a few tips and a bit of preparation it can be very valuable. There’s a few basic things to consider when carrying out tests.

Asking the right questions

Just rolling up to your user and asking questions may provide some value, but it may also give you some bias or low value results. To avoid this it pays to prepare your questions in advance of the interview. When formulating the questions themselves make sure you avoid both leading and dead end questions.

Leading questions

An example of a leading question is “do you find the mood of the scene magical?”. By asking a question in this way you’re influencing your user to think of the scene in a magical context. This may effect their answers, reducing the value of the feedback. A better question to ask would be “can you describe the mood of the scene?”. It’s more open ended, leaving the user to describe the mood without bias.

Dead end questions

Likewise asking dead end questions also provides little value. Dead end questions are questions that can be answered with a simple yes or no. An example would be “did you enjoy the experience?”. A better option would be “tell me about the experience?”.

If need be, you can always ask follow up questions to clarify anything you feel isn’t clearly communicated in the users answers.

Sample size

On the surface you’d think you’d need dozens and dozens of users to test on, and in the past many UX practitioners have done just that. As it turns out, that really isn’t needed. In fact according to a study by the Norman Nelson Group you’re actually wasting your time with big sample sizes. You’re actually far better served by performing multiple small test on 3-5 people. Not only is it cheaper and easier to do, but it’s actually more effective.

Working with GameObjects in Unity 👾

Given I’m currently learning to develop in Unity I thought I’d share a few tips I pick up along the way to becoming proficient with it.

When creating a scene in Unity you’ll work with loads of different GameObjects. Your virtual world is built out of them (Floors, walls, trees everything) and you’ll be manipulating them all the time.

One thing you’ll notice is the more GameObjects you have the more complex it becomes placing things correctly. Trying to line everything up, preventing different objects overlapping, and just generally making things look as they should, can consume a lot of time.

Thankfully there’s a few things you can do to make life a while lot simpler. First is learning to navigate around the environment, second duplicating objects, third vertex snapping.

Navigating the environment

The odds are good if you’re doing VR development in Unity you’ve played at least some 3D person shooter on a PC or Console. If so, you’re in luck because navigating in a 3D unity scene can be exactly like this with a few extras. Click and hold the right mouse button and you’ll be able to look around the environment with your mouse and use the WASD keys to move forward (W), backward (S), strafe left (A), and right (D). A little extra something for moving quickly is selecting a GameObject and pressing the F key to jump to it for manipulation.

Duplicating objects

When creating an environment it’s essential to duplicate GameObjects or groups of objects. To do this is very easy, just select the GameObject and do what you’d do to duplicate and just like text in a text editor, copy and paste. Easy as that you’ll have a duplicate item to move around and position in the scene.

Vertex snapping

For the first few months I was learning I didn’t know about this one and boy does it save some time and frustration. Let’s say you’ve got a section of wall and you’ve duplicated it to make the wall bigger. You move your newly duplicated wall GameObject to line it up with the original and you slide it along just a little, you eye ball it and there’s a small gap. You move it back a little and now it overlaps. This sort of thing can go on and on. Vertex snapping will save you from hours of repetition by allowing you to snap two objects together cleanly.

To do this, select the move tool then select the GameObject you want to move. Now hold down the V key, move your cursor to a vertex, then click and drag it to the vertex of the GameObject you want to snap to. Now release the mouse button and boom, just like that you’ll have a perfectly placed GameObject in line with the first.

Now to be completely honest it can be difficult to get your head around vertex snapping from reading a text description of it. Thankfully a number of people have made excellent YouTube videos showing just how it’s done. Here’s one I found useful:

For more information on vertex snapping and a whole lot more, see the Positioning GameObjects section of the Unity manual.