In previous development blogs I wrote about technical solutions to problems that needed to be solved during the development of my four week game project at school. This time I would like to write about the design process during the project from the perspective of one feature of the game, namely the movement of the player. How we designed it in the beginning, how it changed during the project and what finally made it in to the game.

When creating a game, a designer often needs to reassess previous design decisions. Maybe something didn’t work as intended after testing, unknown technical limitation may be discovered or the team may not have time to implement a designed feature. Any number of things may occur that forces the designers to adapt and evolve the game as the development continues. This happened to my team while we developed our VR game “Night Terrors”.

Premise

Night Terrors is a VR puzzle horror game where the player takes the role of a preschooler, afraid of the dark, that wakes up in the middle of the night from nightmares. The player’s goal is to reach the safety of the parents’ bedroom by finding light sources along the way which illuminates the path forward and drives away the monsters hiding in the dark corners of the house.

Screenshot from the final build of the game.

We knew right from the start that our game needed movement of some kind. The core game experience was to explore a child’s playroom turned scary after dark from the eyes of a pre-schooler. The core loop of the game would be to explore the environment and solving puzzles. To solve the problem of inertia and motion sickness when moving in VR we decided that the movement would be teleporting of some kind. What we would need to solve now was

  1. How to explain the teleportation to the player
  2. How it would be controlled and used by the player.

Iteration 1: Throwing the teddy

Concept art by Johannes Palmblad

Concept art by Johannes Palmblad

In our game you would play as a child scared of the dark. We thought that we could build upon this by adding a teddy bear that the player would need to use through the game. That would tie into the theme of the scared child and the nightmare scenario very well. In the first iteration of the teleportation we experimented with making the teddy bear the center of this mechanic.

The child would be too scared to walk freely, afraid of the monster. When a player selected a spot to teleport, the game would then close the players “eyes” and play a running/tapping sound to indicate to the player that the child was running to the spot with his/her eyes closed. The game would then open the player’s eyes at the new location.

We really liked this, it explained why the player “teleported” around instead of free movement and tied into the theme of the game very well. What we needed to solve now was how the player would initiate a teleportation and how to use it.

We decided to use a teddy bear. If the explanation of why the player could not freely move around was the fact that the child was scared, the teddy bear would be a good fit as an aid for teleportation. The player would throw the teddy bear to where the player wanted to go. The teddy bear then made that area safe so that he child could go there. The child threw the teddy bear and then ran to it. It seemed like a good idea…

… until a couple of questions came up. If the teddy bear made the child feel safe, why would he/she throw it away? What would happen if the player threw the teddy bear somewhere the player could not teleport? For example, high up on some unreachable furniture or into a dark space of the room where the monster may lurk? How would we communicate to the player where it was and wasn’t ok to teleport? If the player threw away the teddy to a spot where it wasn’t ok to teleport to, how would teddy return to the player? Also, the physics engine of Unreal made it very hard to throw things with any precision making it hard to hit the space where you would like to go. We needed to rework this in some way.

Nothing in this iteration was implemented. The problems that we discovered came up in discussions and meetings and we decided to iterate further before we started to implement.

Iteration 2: Using the teddy

Concept art by Johannes Palmblad

Concept art by Johannes Palmblad

We still liked the idea of using the teddy to move around so we wanted to keep that. What we decided to cut was the throwing part. The player would now need to pickup and hold the teddy to be able to teleport. When the player held the teleport and pulls the trigger on the controller a teleportation indicator would appear where the player was aiming the teddy. The player could then aim and select a spot to teleport there. The indicator would change colour and other effects to indicate if it was ok to teleport to that spot or not.

This seemed like a good compromise. We kept what we liked about using the teddy and solved most of our problems from before. No problems with physics engine, the player would get clear feedback on where and where not to teleport.  However, other problems quickly arose. We still had the problem of the player throwing away teddy to a dark spot and how to return it to the player. The player could also drop teddy and lose it or simply misplace it and forget it. We didn’t think these problems invalidated our solution and we still liked it very much, so we decided to create a support system that would solve these problems. The player would be able to press a button to get an indicator where the teddy was if the player lost it. The teddy would return if the player threw it into dark spaces of the room. We were confident we could solve any such problems that arose. What ultimately changed our minds completely was when we tested this mechanic in the game.

What we discovered when playtesting was that many players misjudge distances in VR. Especially when the proportion of all assets would be bigger than normal in our game to make the player feel small and childlike. When testers played the game, they would often misjudge distances and sizes of objects. For example, the testers would often teleport too far away from a door at first when trying to open it. The player would teleport to a spot where they thought they could reach door only to discover that it was an inch too far away. They would then need to readjust their position with a new teleportation to be able to open the door. This was particularly common in the beginning of the game with testers inexperienced with VR. As the test went on they got better and better at judging distances but every so often they would need to readjust when performing some task.

When the teleportation was tied to the holding and usage of a specific item this adjustment and repositioning became a hedge problem.  The testers would often pick up the teddy with their dominant hand and teleport. Then they would drop the teddy to try to open a door or something else, and discover that they didn’t reach. Then they would need to find where they dropped the teddy and pick it up only to have this process repeated. Movement and teleportation became something of a hassle and took too much focus and time away from the player solving puzzles and taking in the environments.

In this iteration, we implemented mechanics of the player using the teddy bear to teleport around. We didn’t implement any of the support system that we designed to solve the problems.

Iteration 3: Being close to teddy

We decided to cut that the players would need to hold the teddy to be able to teleport. Instead the player would be able to teleport freely when in close proximity of the teddy. That way we would solve the problem of repositioning but still keeping the mechanic of the safe haven around the teddy.  This iteration didn’t even survive a whole design meeting and here’s why. Many problems quickly came to mind. We now had two system that restricted the player’s movement, the proximity to the teddy and the dark and light areas of the game. This felt weird and created a huge problem of how we would communicate to the players where and why they could and couldn’t teleport. Also, the indicator for the proximity to teddy would need to always be present making the game feel more “game-y” and less immersive.

This iteration didn’t get implemented at all.

Iteration 4: Cutting the teddy

By now you may wonder why we persisted on using the teddy. Why we kept adding bandages to the feature and still kept it. We started wondering that too. The whole point of the feature was to create a bond between the player and the teddy, that the player wanted to have the teddy close at hand. What we had created was a system where the player was annoyed with the teddy. It was a thing that the player needed, but didn’t want. And the teddy had become a source of frustration rather than a source of safety.

Final teleportation

What we ended up doing was cutting the teddy all together. The player can freely teleport without holding it and is only restricted by the light and dark areas of the game. This worked very well and kept the flow of the game going. The player could focus on moving around, explore and solve the puzzles. The teddy is still in the game and the player can still pick it up and carry but it is no longer tied to teleportation or movement.

Kill your teddies, what we learned

What did we learn from this? Don’t be afraid of killing your darlings, or in this case teddies. In hindsight, we may have clung to the idea of a teddy a little bit too long and we should have cut the teddy earlier than we did but we did cut it when it felt necessary. We could also have playtested things earlier as well. Most problems were discovered during playtest and in this case we could have discovered the problems of repositioning even before we implemented the teleportation through teddy. It’s classical lectures in game design, fail early, test often and don’t be afraid of cutting features if they don’t fit.

You have heard this so often but it’s good to experience it first-hand. It also taught me the value of hard deadlines. If we didn’t have any hard deadline, the danger of us continuing to add bandages to features might be very high. The hard part is not recognizing that a feature is a problem; the hard part is when to decide when to cut them and when to solve them. Deadline forces a way of thinking of these problems more critically, and forces you to assess the values of features in a different way than otherwise.

All concept art in this post was made by Johannes Palmblad. His excellent portfolio can be foud here.

Best regards!

Simon Engqvist