Building the Right UI/UX for a VR Game: My Experience with Water Bears VR


Hi there, I'm Doyle Daigle II, UI/UX artist & designer. I've had the opportunity to work on some exciting VR projects here at Schell Games. Today I'm here to talk about the UI of Water Bears VR, specifically the player's pipe inventory.

Waterbears pipe inventory

Designing the UI and UX for a VR game is a challenging process. You have to consider many things that you normally wouldn’t, such as the simple fact that the user doesn’t have a “screen,” per se.

If you try attaching a user interface to player’s camera/screen in a non-diegetic approach, aka a HUD, you’ll quickly find that this is quite problematic. The HUD splits your eye focus from the foreground and the background (game environment), and you’ll find that there is something unsettling with a UI that is always ‘stuck in place’ in front of your vision. It is also frustrating to not be able to move the UI to a viewing angle that is comfortable for you. There are a few small ways that a HUD can be used in VR, but that is for a different discussion.

Water Bears was originally a mobile game. As a studio we realized its 3D puzzles would translate quite well to a VR environment, especially with the HTC Vive, which would allow the player to physically walk around the puzzles.


What is your UX?

The mobile version of the game featured an onscreen (non-diegetic) inventory for the player to use and, as I mentioned above, this approach would not work for the VR version of the game.

When designing any interface, first you need to consider the user experience. In our VR version of Water Bears, we wanted the players to physically walk around the puzzles. The UI would need to accommodate this and be portable, so the player could access the UI from any side of the puzzle whether the player was sitting, kneeling or standing.

Htc vive tracking

The Vive tracks the player’s head mount and hand controllers, and with the head (screen) off limits, logically we decided to attach the interface to the player’s hand(s).

Htc vive 2

Prototyping and experimentation

Initially we tried really hard to made the game playable with one hand. We experimented with a radial UI which the player could cycle through using the touch pad.

This seemed like a promising idea at first, but with testing, we realized this had issues. We were using the prototype controllers at the time, and the touch pads were somewhat finicky in their usability. Also, the player couldn’t see their hands, and if the player slid their thumb or accidentally tapped the touch pad, it would jump the cursor to a potentially undesired selection.

With repeated testing, this was quickly becoming an issue, and so we would need another way to solve this. I decided to do some research and see what other developers were doing. Remember, this was in the summer of 2015, before VR platforms were available on the market, VR UI was (and still is) a new and scary world of development.

Palette ui

The Palette UI approach

I came across Tilt Brush, by Google, and I was amazed to see that their game had a very complex UI, which was portable (attached to the player’s hand) but comfortable and easy to use. This system used two hands, your free hand being the hand used to make selections. I felt we could use this ‘palette UI’ idea for Water Bears and pitched it to the team.

After some convincing, I was able to get the team on board to using a two-handed system. We didn’t want to use UI icons/buttons though. This was a physical world, and so we wanted the objects the player was going to interact with also be physical, and so we used 3D pipes as the inventory items that the player could interact with.

WB selection screen

Tightening the UX

There are two components in Water Bears VR that reinforce the user interaction with the 3D pipes on the inventory (and within the game world).

First, we gave your free hand a 3D cursor. We used a simple 3D cube for this. When your cube collided with something interactive, such as the pipes in the inventory, we made it so the cursor couldn’t penetrate the object. Meaning, if you push your controller forward against the object, your cursor will stay wedged against it. This was subtle, but it helped reinforce that this was something you (your cursor) could interact with.

The second component were the “states” of the 3D pipes.

The Highlight State

When the player’s cursor collided with the collision mesh of the pipe, we enabled a hidden pipe mesh which had a bright blue material on it to represent the pipe being ‘highlighted.’ This is common in the 2D world for buttons in a menu, but with 3D objects, we need to actually change the properties of the object to achieve this. The hidden mesh was slightly larger as well, which also helped push the contrast of the highlight state.

Pulling the trigger on the controller grabbed the highlighted pipe, which then disabled the 3D cube cursor.

The “Ghost Pipe”

When the pipe was held, we switched the material of the pipe to a material with a transparent shader. Being able to see through the pipe, gave the player visibility when placing it in the game world. The puzzles can get pretty challenging, and sometimes you have to fit a pipe in a tight spot. We wanted the player to be able to see where they were placing their pipe at all times.

Attached Pipe

We switched the material again to a bright gold material when the pipe snapped to a valid attach point. This let the player know they could place the pipe.

Waterbears gifsmall

Each state of the pipe had a unique visual cue to communicate to its state to the player.

Waterbears gifsmall2

The Small Details

Lastly, there’s one small UX detail I want to cover. When working on the user experience, you have to consider every aspect of it.

When grabbing a pipe from the inventory, we couldn’t have a pipe spawn again right away. Consider if the player grabbed the pipe, but didn’t pull it right away from its inventory location, the new pipe would spawn in and collided with the held one. This would have been problematic, as we didn’t let our pipes collide through objects. Also it would have been awkward for the player. We couldn’t use a timer either, because once again, if the player kept the held pipe there, the pipe would have collided with it. To combat this, we detected when the held pipe left a collision box that we had placed on each pipe spawning point. Once the pipe had been removed from the area, it initiated a countdown timer that spawned a pipe.

This is another subtle piece to the experience, but all of these small elements that the player probably doesn’t even notice, added up to a smooth and comfortable experience.