VR Puzzler Design Project


This is a brief writeup of my design process for one of the projects in Udacity's VR Developer Nanodegree program I was taking during 2017. The goal was to produce a simple puzzler game while learning about VR design principles, such as ergonomics, and more general user-centered design methods.

Final result

My puzzler consists of a scene where one steps up into an observation tower, and the puzzle is interacted with through gazing at a starry sky. Once completed, the player flies through the 'stars'. The 'Simon Says' puzzle mechanic you see int he video was given as a project template so that the implementation would focus on other design aspects.

Design Process

The first step in the project was to create a persona i.e. an imagined person with certain habits and preferences that the design would aim to engage. My persona was based on an idea of what type of a person would potentially convert from other gaming hobbies into a VR enthusiast. I chose to depict a female IT professional with strategy and board games as a hobby, with disposable income.

I sketched three ideas regarding the general concept. I was initially set on trying out one where the player would be placed in a cockpit but eventually went for the starry sky one because I deemed it less work given the schedule.

I wanted to use custom models and proceeded to use Kenney's Asset Forge to create a castle tower. This went through a number of iterations, especially the top part where the actual game play would take place. The iterations were based on testing builds on device (Android with Gear VR) and aimed for better ergonomics especially in terms of viewing the puzzle orbs.

Once the tower was in place in Unity, I sketched a few UI concepts and started implementing the final one out of those, which lead to the first user testing phase.

Iteration through user testing

I tested the app in two stages of development. The first test build had the starting position implemented with a UI for the user to proceed. I found my UI solution of placing the buttons on the stairs work quite well. Based on my first test with my wife, I raised the button to one step higher. My daughter was my second tester. I asked about the scale of the environment but she was struggling to give meaningful answers. Because my wife did not comment on the scale either, I took it as a positive and did not change things. They liked the skybox I had added and commented positively about the atmosphere.

The second test was with a late build close to submission. The main focus of the test was the orb mechanics. My daughter did not know the memory sequence game and was not able to complete the game. However, my wife did without significant issues. Based on the their feedback, I added an instruction text to the puzzle view and made slight adjustments to the orb layout.

Reflection: Post Mortem

In my game design career, I have become familiar with the notion of looking back at a project through a so-called post mortem where the team identifies 5 things that went right and 5 things that went wrong. For the sake of brevity, I will briefly list three things for both categories:

What went right

- Custom modelling: While I don't think the castle model is nothing spectacular, the process of making it and bringing it into Unity taught me a lot about the particularities of importing assets to the engine, e.g. how I should have broken the model into smaller pieces.

- Internalising Unity processes & tools: I clearly find myself not having to go back to consult instructions on many things I still did with the previous project. Making builds etc comes now routinely and I know what might be the issue if something goes wrong.

- Getting things done: This might be a no-brainer but the degree structure with deadlines is something I clearly need to push me to finish projects. So while I don't feel especially proud of the final result, it is a finished one instead of the multitude of personal projects that have never reached completion due to lack of external deadlines.

What went wrong

- Lighting: in hindsight I spent too much time in trying to get the lighting of the scene right. Clearly, I still need to educate myself on the fundamentals of the different lighting options because this was partly due to not understanding in enough detail their differences.

- Time management: Whereas the previous project took place at a time period when I was less busy with my full-time work and partly on vacation, I was able to plan and prioritise things better. Especially returning from vacation to full-time work with children's schools starting I was very much left at late nights in trying to just get things done, with way less attention to detail and iteration that I would have wanted. My experience helped me to make the call of cutting scope once I realised how my last two weeks would play out.

- Concept: in general I was not as inspired by the puzzler concept as I was with the maze. I have been doing design in different contexts for more than 15 years so I felt I had to align my usual process to what was asked, and the key learning outcome in the degree for me, i.e. learning to develop VR with Unity, was left somewhat on the side. So while I appreciate the design and testing methodologies covered, there were quite familiar to me, and I felt I did not learn as much.

Further development

In the project backlog, I have features and assets having to do with refining the astrological theme. For example, I would have liked for the puzzle sequence to be presented as a constellation of stars with lines linking them in the order of the puzzle sequence. I think with some effort I could implement this, but most likely I will move on to other projects from this.




ArticleAki JärvinenVRComment