UX/UI Analysis of Horizon: Zero Dawn

This analysis was made as an assignment for school during a UI/UX design course. 


Horizon: Zero Dawn is a single player, third person, open world, action game developed by Guerrilla Games and released for PlayStation 4 in February 2017. The game is set in a post-apocalyptic world hundreds of years in the future where man and machine animals roam the forests and ruins of the old world.

Game features

The main part of the game consists of the player battling enemies, humans or machine animals, and exploring the open world. The main path of the game consists of the player doing a series of story quest. There is also a number of smaller and larger side quest and activities that the player can choose to do.


In combat the player has a wide range of weapons, traps, item and potions that the player can use against the enemy.


The player explores the world and discovers locations, NPCs, quests, etc.

User Interface and User Experience

Main Menu

Figure 1 Main menu

The main menu of Horizon: Zero Dawn is very typical for AAA games and other games of this genre. It displays the title over a beautiful vista over the game’s first area, forecasting for the player what to expect of the first hours of the game. Player menu selections is at the bottom left corner giving more room for the vista were the title is displayed. The selection menu is vertical and selecting an option either starts the game, opens PlayStation 4 OS interface for loading games, or opens another vertical selection menu. This setup is easy to understand and is straightforward. It’s a typical game menu for console games of this genre.  The options are:

  • Continue
  • New Game
  • Load
  • Settings
  • Extras

The settings option opens up the same menu as the options selection in the  options menu in the main game, see below This gives consistency for the overall UI experience in the game.

The first time the player an intro cinematic is played that ends with the view over the vista and the title. From the second time and forward the game opens directly to the title skipping the cinematic.

Opening with a cinematic gives the player a powerful first impression of the game. When the title and menu fades in at the end of the cinematic players are already anticipating the to continue the story by starting a new game.

Skipping the cinematic from the second-time forward speeds up the process to continue playing . Most players just want to see the cinematic once. The player can then start the game and very quickly get into the game. The option to rewatch the intro cinematic is under “Extras” in the menu list.

A guess is also that Guerrilla Games hides some installation of files during the intro cinematic to make players more quickly engage with the story of the game.

Before the cinematic plays there is a short prompt allowing the player to turn on subtitles and change the spoken language. This has two benefits. The first being that it stops the cinematic playing directly when starting the game. There is some installation of the game in the OS before starting the game that takes a couple of minutes. Players have the option to enable the game to start as soon as the installation is complete. If players do this and then do some errand, go to the toilet, surf the web while they wait they risk being elsewhere in their home when the intro cinematic starts. The prompt stops this and allows player to get back to the TV and the game won’t out missing anything.

The second benefit is that the player gets to select the preferred language before playing so they can understand the story. Also players with hearing loss or impairment can turn on subtitles before starting so they also can understand the dialogue.


The HUD of Horizon Zero Dawn is very similar to other games in the same genre.

Figure 2 The in-game HUD

The most important information is located at the corners of the screen.  At the bottom corners the player can see the weapon selection and item selection.

Figure 3 Health bar

At the top left corner, the player’s current health is displayed. These elements take up some space and having them at the corner allows the game to have them displayed but out of the way from the action at the screen. This placement is common for similar games.

Figure 4 Compass

At the top, in the centre, a compass is located with icons that help players find their way around the world and displays locations and waypoints that are close by. It’s located in the centre to allow players to more easily navigate according to it because the character is almost always directly below the centre of the compass. Worth noticing is that in comparison to many other open world games, The compass in the middle keeps the player’s eyes in the middle of the screen and at the game world when navigating. The player doesn’t need to go back and forth from the middle of the screen to one of the corners and keeps the player more engaged with the game world.

The downside is that when a map is needed the player needs to open up the map screen of the in-game menu constantly, checking the map, moving and checking the map again etc. A mini-map would have reduced this need of opening a second screen but also maybe would have reduced the player engagement with the world. The map is at least the default screen when opening the menu, reducing the steps to check the map with quite a lot. The map is almost always just one button press away.

Figure 5 Stealth icon

Directly below the compass is the stealth icon that shows if the player is currently visible and how much noise the player is currently making. This makes it easier for the player to know if they are hidden or visible.

Figure 6 Experience bar

The player’s level and current experience points is displayed in the upper right corner and give information about how close the player is to levelling up.

Figure 7 Objective progression

Directly below the health meter to the left is a context sensitive element that displays the players current mission and the current goal and progression through that mission.  Above the item selection element in the bottom left there is a list of recently picked up items and resources. When a player picks up a resource a text in this area tells the player what it is and the quantity picked up. This is needed since so many resources in game are very similar to each other, for example many flowers in the game look very similar to the point where it’s very hard to know before you pick the flower what type it is.


The HUD in Horizon: Zero Dawn is to a limited degree customizable for the player. The player can from the options menu select if an UI element should be always visible, always hiding or “dynamic”. “Dynamic” means the element is visible or hidden depending on context. For example health, item and weapon elements is hidden when not in battle and shown when the player starts or enters a battle. This is very good because players can themselves select which elements they want to see and therefore select if they want to have all information always, or no information for more immersion, or something in between.

Figure 8 Customizable options of the HUD

There is also an option to which makes the entire HUD visible for a short while if the player touches the touchpad on the DualShock 4 controller. This allows for a good amount of flexibility for the player to hide almost all HUD elements when playing but also quickly have them available with a quick and easy action.

Weapon wheel – selecting weapons

The player can press “R1” to open up a selection wheel where the player with the right stick can select between four preselected weapons and the munition type for those weapons in a circle. The player can also select if they would like to craft more of a specific ammunition type. During this selection, the game is slowed down to almost pause to give players time to decide which weapon to select.

Figure 9 Weapon wheel open

This selection menu gives the player a fast and easy controlled way to quickly switch between weapons or munition types and feels very convenient. However the game includes eight different weapons types and the player may carry more than one each type. The player must in a separate menu (the inventory, see  below) select which four weapons to be displayed in the wheel.

Displaying all weapons in this wheel  would not be an option because it would then be crowded and not usable but the steps the player need to go through to switch one of the four weapons to another is too long. To switch weapon in the weapon wheel the player needs to:

  • Open inventory
  • Navigate to the weapons inventory
  • Select weapon
  • Select spot on the weapon wheel that the weapon should have
  • Exit the inventory
  • Open the weapon wheel
  • Select the weapon

Doing this during combat kills the flow. The player must go through an unnecessary number of steps to switch weapons, an action that you do often in the game (Of course depending on play styles) The inventory also have a separate music track that cuts of the combat music. This adds to the abrupt switch of tone and flow of the combat.

A better way would to have an option to go directly to the weapon selection in the inventory from the weapon wheel cutting the steps necessary to switch weapons. Or have many weapon wheels that the player can switch between to that the player have access to all weapons without going to the inventory.

Selecting Items

In the game the player has one item selected at the time that the player can use by pressing down ion the D-pad. The player can select, or switch, which item is selected for use by pressing left or right on the D-pad to flip in a list of items.

Figure 10 Item selection and usage

The problem with this solution is that the list of items of select from quickly becomes too long. In the end-game the player have more than 14 chooses to select from and flipping between them with the D-pad in the middle of battle to use one item becomes a hazard. The player needs to both concentrate avoiding taking damage and checking if the right item is selected.  Furthermore, the order of the items in the list is determent by the order the player discovers them in the game. This makes the list somewhat random in order. If an item runs out and the player restock the order of the list changes. This makes it very hard to remember the order of items, especially when in combat.

Unlike the Weapon selection players can’t craft item from this menu. If an item runs out the player will need to navigate into the in-game menus craft screen to craft more of that item or buy items at a vendor.  This like the weapon switching this can create a halt of flow of combat when the player goes into a crafting menu to create items in the middle of combat.

A better solution would to have a similar item selection as the weapon wheel where the player can directly select or craft items that is needed. It would speed up item selection and not compromise combat.

In-game menu

The player can by pressing the touch pad on the Dualshock 4 controller open up the in-game menu. The inventory menu consists of six screens that the player can flip through with the L1 and R1 buttons.

  • Skills
  • Inventory
  • Crafting
  • Map
  • Quests
  • Notebook

Some of these screens have sub-menus that the player can select. The screens are either navigated in a list-view or in a grid depending on context.  For example the submenu is navigated in a list, selecting different inventories (Weapons, potions, etc.) that is navigated in a grid-view. The only exception to this is the map, that displays a world map that is navigated more freely.

Figure 11 In-game menu open to the crafting screen

The navigation for this menus are very typical for this sort of game and is very functional. It’s very similar how the UI of console OS  is navigated and is fairly intuitive.

! – Exclamation marks

An exclamation mark is placed close to menu items who have content associated with them that have changed or been added. For example the inventory may have an explanation mark below it if the player have acquired a new type of weapon or outfit. These exclamation marks indicated new information to the player and makes it easy for the player to see where something have been added or changed. The exclamation mark is cleared and removed from the item if the player navigates to it and the added or changed menu item.

Figure 12 An !-mark at the Notebook-section of the in-game menu

These exclamation marks are good to inform players about new information and makes it easy for the player to spot in what slot a new item or in what category a new quest was added, to a certain degree. The only way to clear the exclamation mark is to navigate to the specific menu item that generates it. If the player has not open the menu for a while there may be an abundance of exclamation mark and the player will need to go through a lot items just to clear them away. This may discourage players to clear the exclamation marks and letting them stay but then they risk missing out if new exclamation marks was added to an interesting item. If the player doesn’t clear the exclamation marks and the game keeps adding them, soon almost all items will have an exclamation mark next to them making them useless for the player, echoing the “Syndrome-rule” from the 2004-movie the Incredibles; “If everybody’s super, no one is”.

This could have been easily solved by including an “clear all”-options that clears all the current exclamation marks. This makes it easier for players to clear them and there for increasing the usefulness of them.

Opening the menu

The player opens the menu by pressing the touch pad on the controller. The default menu screen that opens is the map but it can be different depending on different context. The map will open to a screen that is relevant to a recent event in the game.  For example, if the player just got a new quest and opens the menu it will display the quest screen, if the player got a new type of item it will display the inventory screen etc.

This is for the most part very convenient for the player. The player gets something new and wold want to read about it or look it up in the menu the game quickly gives access to that.  Sometimes the player just want to look at the map after completing a quest. If the player then opens the menu it will open to the quest screen. That could be annoying for the player that is used to see the default map. But the benefit to quickly get to see newly added item, quest, etc. outweighs this occasional annoyance.

Sorting of items

In the Inventory screen, all of the players items is displayed in a grid view for the player to browse through. This grid is filled with items in the order they are picked up and the order of them can’t be changed or sorted without the player dropping items in the game world and picking up again in the desired order.

Figure 13 Items in the inventory

The player gets a lot of items in the game and keeping track of all of them becomes hard. An option to sort the items according to item type or usage would have improved the user experience of the inventory greatly.

Options menu

The player can open the options menu by pressing the option button on the controller.  The options menu is very similar to the layout and functionality of the main menu. The menu pause the game and shows like the main menu a list of menu items. This is a typical layout of an options menu for these sorts of games and gives a simple but clear layout for different options.

Figure 14 Options menu


The settings menu is very similar in functionality as the in-game menu. The player navigates between different setting screens by pressing L1 and R1 and select different settings options by going up an down in a list. Some options open up new option screens and the player will need to navigate back from it to switch settings screen.

Photo mode

Photo mode is a tool that allows players to take more creative screenshots of the game with the “share”-functionality of the PlayStation 4. The tool lets player move around the camera while the game is paused, hide UI elements, hide the player, manipulate settings in the game camera like field of view, depth of field, focus distance, tilting among others. It is present in many Sony first-party titles like Infamous: Seconds Son, Last of Us: Remastered and Uncharted 4: A thieves end.

Figure 15 An example of photo mode

It’s a powerful tool for users to play around with if they would like to take more creative and interesting screenshots from the game. This feature allows players to be creative with the game and express themselves in relationship to the game world and the game contents. Its encourage players to share screenshots of the game on social medias. This encourages free viral marketing for the game and general positive exposure.

The only downside could be that players have a powerful tool to analyse the games graphical fidelity and technical benchmark. The players may easier spot graphical bugs or technical flaws with the game that could possible lead to bad publicity for the game.

The developer needs to feel confident both on the graphical art style of the game as well as the technology and graphical fidelity of the game if they should include such a feature. Luckily for Horizon: Zero Dawn Guerrilla Games is known for their technical prowess and the game have very few obvious problems of that nature.

Controls for this features is a bit different than other Sony published titles with similar features. The players have similar options and settings in Horizon: Zero Dawn as in for example Uncharted 4: A thieves end but the layout and control is different.

In Uncharted 4: A thieves end everything is controlled with the analog sticks and the player switches between settings with the D-pad. In Horizon: Zero Dawn the player controls the settings and options with the D-pad and unlike Uncharted the player have always control over the camera angle and position with the analog sticks.

In the future, the publisher Sony could benefit from design guidelines regarding similar features in the games they are publishing so that the controls and settings is similar in each title. This would increase the usages of the features and therefore also the viral exposure to them.


Horizon: Zero Dawn have a quite extensive tutorial in the beginning of the game. The tutorial is interwoven with the games story and begins when the players character is a child. Therefore, almost all player features and abilities are locked. After the completion of the tutorial the character have grown into adult age and unlocked almost all the abilities present in the game.

The instructions of the tutorial are a mix of HUD prompts and in-game dialog. The dialog explains for the player when to do and why and the prompts explains how. The prompt may also contain additional information or explanations.

Figure 16 In-game prompt showing the player how to crouch

The prompts show up in-game and does not paus or interrupt the game or the players control over the character. The prompts stay up until the player have performed the prompted action or interaction. This is good because it keeps the flow of the game up and it allows players to read and learn while they are preforming the required actions.

This is important because some games paus the game with these prompts, requiring the player to press a button to continue playing. These kinds of prompts tend to be skipped without reading because the players want to continue player making them miss or forget curial information. This is for example the case with all Assassin’s Creed games in recent years.

The most common and important actions and abilities, like crouching for example, is explained and prompted multiple times during the tutorial to repeat them for the players to increase that the players remember them. This is good and it is not overdone.

Figure 17 An example of in-game dialog combined with on screen prompt

To interweave story and tutorial is a powerful way to keep player engaged and being interested while dumping a lot of information on them. If the tutorial would be separate players may feel impatient and start playing without learning important and complex mechanics or stop players from playing all together.

However, by making it a part of the story and unskippable the game risk alienating seasoned players that wants to play the game right away. Hopefully the story of the game will keep these players interested during the tutorial without them feeling board or hand-held trough the game.

The game could solve this by allowing players to skip the tutorial and directly jump into the story after it like for example Fallout 3 and 4 and the Elderscrolls V: Skyrim. Those games however features character creation that the player may want to redo several times while Horizon: Zero Dawn have a pre-defined main character. By allowing the players to skip the tutorial the game might risk players skipping valuable content, for example important story bits.


The HUD is introduced to the player one element at the time. When the tutorial starts, the player starts with a screen without any UI element on it. As the player progresses trough the tutorial and unlocks new abilities and features the corresponding UI element is shown. For example, the stealth indicator is added to the UI during the section of the tutorial that explains the games stealth mechanics and how to use them. At the end of the tutorial the player has the complete set of UI elements displayed.

Figure 18 Beginning of tutorial with minimal HUD
Figure 19 Compass element added to HUD

This gradually explains and increases the complexity of the UI for the player allowing them to grow accustom to each element before a new one is introduced. When a feature is explained and the UI element appears the players get an association between the UI element and the features that might over wise get lost of confused if all UI elements was presented at the same time. The players might also otherwise not know where to look when a feature is explained.

Figure 20 Stealth icon added and explained in stealth section of the tutorial

When some of the more complex UI elements is introduced, for example the stealth icon, an onscreen text or prompt appears that explains them. The more common and simple ones that looks like similar element in other games are not explained in such detail, for example the health and experience bars. This relies on players already being familiar with such concept from previous games to get them right away risking confusing new and inexperienced players. However, those features are very common and easy to pick up on when playing without in-depth explanation. Horizon: Zero Dawn is also marketed more towards experienced core players so such problems may be small.

Tutorial videos and missions for Items

When acquiring new weapons in the game the player can watch a short video of how the weapon works. Some weapons in the game are very complex, for example trap weapons, and needs explanations before usage. The videos try to solve this but they are easily missed or overlooked. And would have needed to be more apparent. Also, the screen space of the video is to small and it’s hard to see details of the video. Especially on smaller TVs.

Figure 21 Viewing of tutorial video for a weapon at a vendor

The game also generates tutorial missions for new acquired weapons and items that the player can do to learn more about it. These missions is optional and does not create any in-game prompts or on-screen explanation about the item while using it. The player must read the instruction of the quest in the game menu and then do the task in-game.

Figure 22 Tutorial missions for new weapons and items

A better way would to create prompts or on-screen text for the player in-game while doing the tutorial quest like the tutorial in the beginning of the game. This could be problematic to implement in a satisfying way considering the open world nature of the game.

User journey

To limit the scope This analysis will be a brief over all analysis of the player journey and progression thorough the game staring from the physical box art until the game ends.

Discovery – Before the game

Horizon: Zero Dawn was first pitched internally as a game where “a female protagonist fighting machines on a lush Earth far in the future”[1] and that first pitch have been central in the promotional art and box art for the game throughout the marketing. Promotional art has heavily featured the robot dinosaurs machine enemies in intimidating poses as well as the young female protagonist that the is the players character. Also, heavy featured is the overgrown post-apocalyptic landscape.

Figure 23 Game box-art

The promotional art promises a game with exploration trough the landscapes and engaging combat with the dinosaurs using bow and arrows.  It’s also promises a lush and detail world with the use of strong contrasting and rich colours. The art creates a good image of what the gameplay is like and sets good expectations for potential players.

This creates an anticipation and curiosity for potential players to explore the weird game with robot dinosaurs but also promises engaging gameplay. The marketing for this game have been on point with communicating the strengths of this game and it would be hard to improve upon that.

The game stands out against many others open world games by having the unique features of the robot dinosaurs and the marketing team have used that to their advantage to remarkable success.

Game structure and progress

The game progression could roughly be separated into three sections. The onboarding with intro cinematic, tutorial and the first view missions. The Scaffolding where the player finishes story- and side quests, sectioned off into two arcs and the endgame when the player has finished the game.

Figure 24 Flowchart of game progression


In this section, the game tries to sell itself to the player both introducing the world and the game mechanics.  For an analysis of the tutorial section, see above.


The player progression tough the game can be sorted into two kinds of activities: main quest and side quests.

Main quest progresses the story and must for the most part be done in sequence. There are a few story missions that can be played in any order but those are uncommon. Progressing trough, the game only requires that the player do the main quest.

Side quest, and other activities, can be played anytime and in any order and are optional for the player to finish. The player can choose to do or not do them and they are not required to finishing the game.

Players starts and finishes quest at their own pace deciding themes when and if to start or finish a quest or activity. This encourage exploration and free roaming where the player goes through the game at their own pace. The player decides for themselves when to progress the story and when to do other things.

This gives players a lot of freedom but also makes it harder to pace the story and gameplay. The game can’t create urgency between story missions for example because the player can freely decide when to do them. The game tries to solve this by making each quest its own little arc that the player finishes and making each quest more standalone. This still creates some pacing problems in the story but it’s very hard to solve this in these sorts of open world games.

After the tutorial and the first view mission the game open for the player to explore. This is done in two segments. First the player can freely explore about a third of the total world map while being blocked from exploring the rest. After some story progression, the rest of the world map is unlocked.

All side quest for each segment is unlocked at the beginning of them. The players therefore receive two big chunks of possible content and activities to explore and do, further increasing the pacing problems of the main quests.

Figure 25 Number of players activities in the game as the game progresses.

It’s hard to know exactly player behaviour through a game with such open nature but some player may finish the all side quest and activates before moving on. This creates an uneven distribution of activities as the game progress. A better way would to spread the activation of side quest along the main questline instead of making them available in two distinct chunks. That would have even out the numbers of activities throughout the game more evenly creating a better flow and pacing.


The game end when the player has finished all the main quest of the game. The players get to see an end cutscene that foreshadows more future content in either a sequel or DLC and then the credits of the game. The game then resets itself to just before the players starts the final quest. The player can then, if it hadn’t already, finished all remaining side quest and activities. Besides that, the game has not much to offer in the end game.

Really dedicated player could use the photo mode, mentioned above, to take screenshots of the game but the game does not reward that at all.

Guerrilla Games could have solved this by creating a series of post-game challenges or similar that test the player’s skills that unlocks after the player have finished the game. For example, killing a specific enemy without taking damage, or take down as many enemies as possible during a limited time frame. Similar challenges are already present in the game but does not save high score that the player can compare against and try to beat. Similar activities exist in games like for example Pokémon.

These challenges could update regularly to get players to keep coming back to the game. An example of a game that does this successfully is the episodic Hitman game from 2016.

A “New Game+” mode could also easily be created where the player restarts the game but keeps their level and gear from the previous playthrough but increasing the difficulty of the game. Such mode has been successful in increasing the end game for game like as Bloodborne, Final Fantasy, and the Ratchet and Clank. games

[1] http://kotaku.com/horizon-zero-dawns-lead-writer-says-they-spent-hundreds-1793772842

VR development blog 3 – Making the cut

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”.


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

VR development blog 2 – The physics of doors

I have previously written about my approach on scripting how to pick things up in VR in Unreal Engine 4 for my four week long school project. This time I will write about how I took that approach and applied it to scripting a door with a door handle.

The goal is to create a believable door in VR, with features of a real door. The player must pull down the handle and push or pull to be able to open the door.

To reiterate the previous post, I used physics handles to script so that the player can pick up objects and move them around without losing collision on the object and not getting any bad clipping problems etc. The physics handle “pinches” the object at the location the player hold his hands and then moves following the player’s hand. The handle then drags the object along with it, allowing it to simulate collision and physics along the way.

I’m using the same technique here. When the player interacts with the door a physics handle will pull down the handle and the door.


To simulate the rotation of the door in the hinges and the handle in the latch bolt, I used the Physics constraint component in Unreal.  This component is used, as it says, to constrain physics actors in different ways. The component has support for limiting an object to move both in linear and angular motion. For the door I used only the angular limitation.  I tested this out and got some nice results.

[one_half][/one_half] [one_half_last][/one_half_last]

To get the door handle to keep upright I used a feature in the physics constrain component called motion. That feature applies a force on the constraint object in a specified direction. I applied angular motion on the handle upward against the ground and it was done.


What I did next was to apply the physics handle to the blueprint the same way as before. When the player put his hands  to the door handle the physics handle “pinches” the door handle and moves the handle alongside the player’s hands with the same approach as the previous post.

Fine tuning

I now had the basics of the door down but it still needed some fine tuning to feel right in the game. The first thing is adding script so that the door can’t be opened unless the handle is pulled down, the second thing is creating some feedback to the player that this door can be opened. I solved both these problems with the same solution.

I added a little collision box at the top of the door, slightly to the side. This collision box only collides with the door and prevents it to be fully opened. When the handle is pulled down the box is deactivated and the door can be opened. By placing it slightly to the side of the door I created a little wiggle room for the door to wiggle in while it is closed. This signals to the player that the door is intractable and movable when they grab the handle.


More fine tuning

After this I needed to fine tune the door even more. Lots of parameters like the dampening of the door and the specific angular motion of the handle needed to be calibrated to get the right feeling. Most surprising to me was that the door felt much better when disabling gravity on both the handle and the door. I theorize that  when removing the extra force on the door downwards the physics simulation of the door when pulling or pushing it became less complex and therefore more responsive.

That’s all for now!

Best Regards!

Simon Engqvist

VR development blog 1 – Picking things up

At my school we are currently having a four week VR game project. My group have chosen to make an atmospheric horror escape room game where you play as a kid trying to escape from the monster in the closet. In this  post I’m going to talk about my system and implementation for picking up items and objects in the game and interacting with them. We are using Unreal Engine in this project and hence we are using the Blueprint scripting language for almost all scripting.

In my team we are three designers. I have a lot of experience with coding and programing but my teammates are less inclined to do the heavy lifting in the scripting department. Therefore it was natural that I was selected to be the lead programmer for this project.

The first thing I would like to write about is how I solved the problem of picking things up and interacting with them in VR.

The goals

I would like to have interaction with objects within our game to feel similar to the interaction in Job Simulator.

First approach

The first simple approach to implement picking things up in VR is to attach the actor that you would like to pick up to the motion controls themselves. Then when you move the motion controls you move the actors as well.

The problem with this approach is that it messes up physics quite a bit. The motion controls themselves actually teleport themselves and since the game can’t stop the player to physically move their hands, the game must allow the player to move their hands through and within objects. The attached actor may then clip through other objects within the game. This could break the immersion for the player but also introduce lots of game design problems as well. For example the player can reach into a locked vault and pull stuff out. Also we introduce physics problems as well since the player then can move items within each other which causes all sorts of problems for the physics engine in Unreal.

I needed to find another way.

Second approach

The second approach I decided to try was to fully take advantage of the physics engine in Unreal. Make the engine do all the heavy lifting for me when it comes to collision and physics. When I researched my options I stumbled onto this video  that demonstrates physics handles in Unreal.

Physics handles in Unreal are a way of moving physics objects around, it’s precisely what I need! It works like this: You specify to the physics handle the component you would like to grab and where you would like to grab it. Then the physics handle “pinches” the object and holds it in place. When you move the physics handle it moves the “pinched” object along with it. Fully simulated by the physics engine! I experimented with this for a while and ended up with the following solution for moving items:

  1. Find the location where the player hold their hand on the object
  2. “Pinch” the object with a physics handle at that location
  3. Move the physics handle every frame alongside the motion control
  4. Release the “pinch” when the player drops the object

This resulted in much better feeling interaction with objects. The objects behave really well when colliding with other physical objects and it keeps clipping to a minimum. The implementation may still need some fine tuning but will work for now!

Drawers and more…

I tried the same approach when I tried to implement other objects that the player could interact with. The first of these was a drawer. I used a physics handle to “pull” the drawer along a physical constraint track. This resulted in some smooth drawers!

I think that the combination of physics handles and physical constraints can be a powerful solution for future implementation of for example levers, buttons, strearing wheels etc.

I hope soneone will find this intresting! Next time I will probably write about the interface connecting the hands with the interactable objects.

Best regards!

Simon Engqvist


My name is Simon Engqvist and this is the first entry to my development blog. I’m a game designer and scripter in learning and I attend Future Games program for game design. Before that I worked as a programmer and IT consultant for four years.

Right now at school we are doing the second of three planned game projects. The first one was a two-week project and you can read about the result of my group’s work in my portfolio. For this second project, we just finished two-week pre-production and are going into a four-week production phase.

The theme for the second project is virtual reality, with the Oculus Rift headset and touch controllers using Unreal Engine. It’s a very exciting and challenging theme that will require a lot of everyone in the groups. My group have decided to make an atmospheric horror escape room game where you play as a scared pre-schooler trying to escape from the monster in the closet. These following weeks I will try to post some development diaries with implementation examples and thoughts about the development process of the game. The first post that I will post shortly will be about my system for picking up items and props to use them and interact with them. Please stay tuned.

Best regards!