Puzzle Dungeon Mobile VR Game
Puzzle Dungeon is a VR game that gives players a “Simon Says” type of puzzle. The atmosphere is a dark and foreboding dungeon. Once the player enters the dungeon they are presented with a series of 5 puzzles, each more difficult in terms of length and speed. If the player fails 5 times, the game is over. Ominous sounds accompany the game and deepen the immersion into the spooky dungeon. My target audience is high school students since as a teacher I have a great user base to test the game on.
When creating and improving this game I was able to learn a lot about the design process. User testing is a huge part of what makes a game or experience work. For any creative process, constructive criticism is important since the end user is either a targeted group or the general public.
Story of the Process
I started with a few sketches of what I was planning on implementing for the layout of the game.
Originally the game was a single puzzle that was randomized and once the player successfully completed it, they would win. Setting that up was a fun challenge and I played around with methods and how to trigger events. I ended up adding difficulty levels so as the player progressed it would be harder.
When making games in Unity and programming in general, sometimes a programmer knows what they want to get accomplished and it can be a relatively simple task. But the execution of the task can take a long time to get working. I found this to be true with several additions to my game. I felt the additions were necessary and even though the game was “done” in terms of having a working puzzle game, I felt that the user tests provided a very good list of suggestions that ultimately helped me polish the experience and make a game that was a lot more engaging than it was initially.
This is the persona of my target audience.
Jack likes to play video games in his spare time and likes a challenge. He has been interested in new gaming experiences and would like to try out mobile VR.
VR Experience: None.
User Testing and Iteration
User Test 1:
For my first user test, I wanted them to tell me about the scale of the experience. How large or small do they feel in the game space? My user had commented that she felt too large when comparing her height in the game to the dungeon door. I carefully re-scaled the room and the camera height to reflect a more realistic experience. Once she felt the scale was correct, I proceeded to create the puzzle system.
User Test 2:
With the same user, I had her try it out once there was a puzzle in place and wanted to know how the experience felt. Did it feel like a game or was something missing? She felt that the experience was way too short and that even though you could play the game several times if you wanted to, it seemed too abrupt to leave the dungeon after each puzzle. I ended up creating a level system that had 5 levels, each with either more orbs lighting up or a faster puzzle along with a dialog box that comes up if you win a level, allowing you to start the next level. I also have a counter that counts failed attempts and after 5 fails the game tells them it’s “GAME OVER” and resets the game.
User Test 3:
After these tests, I had another user tester try it as a more complete game. I wanted to know if a new user felt the game was cohesive and flowed in the way I intended. He told me the dungeon atmosphere was too bright and the lights needed to be dimmer to have it feel like a dungeon. He also mentioned that the orbs were fairly far apart and he felt he had to move his head too much to keep track of all of them.
I dimmed the lights in the game and re-baked the lighting as well as tighten up the spaces between the orbs. This created a more ominous dungeon atmosphere and the tighter orb configuration so the user doesn’t have to move their head around too much.
Breakdown of the Final Version
The user will click start when they are ready to enter the dungeon. Once inside, 5 orbs will light up in a particular pattern. The user must mimic the pattern and click on the orbs in the right order to proceed. If they fail to mimic the pattern, a sound gives them feedback that they failed, and the pattern will be displayed again. If successful, the player will advance to the next level.
If the player is successful and wins the game, they will move out of the dungeon through the back gate and see a dialog box telling them they have won and giving them an option to restart the game.
Using spatial audio with atmospheric sounds, it added to the immersion since the sounds have a radius. The outside sounds were different from the dungeon sounds. I also added sound effects if the player continues to fail which builds tension. To see how a player interacts with the game orbs and advances levels, he following video shows the actual game play.
While a game almost feels like it is never done, and more interactive or immersive elements could be added, I am pleased with the final result. I strongly believe the user testing was one of the most valuable tools to improve a game as it is in development. Documentation is also crucial not only for myself so I can look at my own progress but to any potential employer so they can see how I evolve a concept into a final game. As a scientist I am trained well to document any experiment in a lab notebook, even the most minute details which can be useful in unexpected ways in the future. Puzzle Dungeon was a great learning experience and I believe I obtained the atmosphere and immersion I set out to achieve.