Some thoughts about designing for VR

Pixelshot Games is a one man indie game studio. This blog post was originally posted on Pixelshot Games Dev Blog where I do my best to share my thoughts and experiences of being a solo game creator.

As the Leap Motion 3DJam is coming to an end, I'm going to take a short break to reflect on the things I learned while making In Space, No One Can Hear You Dance. Josh Rose from Robot Sea Monster Games said in a recent talk that VR is still in its infancy. Like the early days of film making, game developers need to experiment to find what works and what doesn't. These discoveries should be shared so we can all grow together and learn. This blog post is my attempt to follow that advice.

Input Disconnects

Current Oculus Rift HMDs only provides the hardware to put players inside a 3D world. This will change with the up coming release of the consumer version of Oculus Rift. Most of the content for the Oculus has been more of an experience or tech demo rather than a game. This is mostly because games at their core require some sort of player interaction. Leap Motion and Intel RealSense provides a way to reach into a VR world. Standard controllers are another option that's more familiar to gamers. What ever your input method is, you want to avoid doing things that break the players immersion. Once it becomes to difficult to provide basic inputs, player will get frustrated and probably turn your game off.

Since I've been working with Leap Motion, let's focus on that. Grabbing things or touching physical objects in 3D using Leap feels odd because there is no tactical feedback. Simple interactions can be very challenging and just not fun. For example, the video below shows a prototype I was working on. You can see the player (me in this case) has difficultly with pinching and rotating the object. I'm not new to using the Leap by this point, other people I had try this prototype who never used Leap found interacting this way to be impossible. I could lock the object to the players hand when pinching is detected but it creates an odd felling because for a stationary object like this, the players hand will move less in game then in real life.

For In Space, No One Can Hear You Dance, I decided to have the player follow instructions with their hands, swiping  up/down/left/right, based on a screen inside the VR world. The result felt more natural because the interaction was a 1 to 1 match. The game did nothing different then what the player expected. 

Simple Is Fun In VR

Most game developers love games (hopefully all but I have met some that don't play games O.o). When we dream up games, they are often pie in the sky ideas with deep systems and huge scope. Making complex games that are fun in VR is actually pretty hard. Gameplay mechanic's in conventional games are strange and can sometimes make you sick. For the near future, creating simple games (but complete, not just tech demos) is enough for players to enjoy their time in VR. If indies want a chance to make a meaningful impact in this space, we need to think small but polished. People who have never experienced VR find simple games to be fun and exciting. VR has transported us to time when the concept of just playing a video game was an amazing thing. Once we get a solid base of usable VR game mechanics, we can build off of that just like games have in the past. It's hard to have the Call of Duty of VR when we haven't had the Pong of VR.

FPS is very important

Low frame rate in any video game is annoying and can make a game unplayable. Low frame rate in VR game makes you want to throw up and never return. Current VR technology requires the screen to be drawn twice, once for each eye. To avoid the stutter that causes nausea, your game needs to run around 90 frames per second or more at all times. Any drop in fps below that can be enough to make a player sick. Once they get sick, that's it for a few hours or the entire day. 

Since we are drawing the screen twice, the requirement of 90 fps becomes 180 fps when not running in VR mode. Getting this sort of frame rate can be hard if your game has complex scenes with realistic graphics. There are a number of ways to get better performance in your game but the three items below are what I found easiest to implement and gave me the biggest improvements.

BAKED LIGHTING

Use baked lighting instead of real time lighting. This is not an ideal solution but it does provide a significant amount of processing relief. Many game engines provide great tools for baking your lights without much effort. If this is something your game can't live without then you may need to hold off until technology improves. For right now, we are limited by the hardware we have. It's a lot like the early days of video games where the limitations of the available technology could drastically alter the design of a game.

SIMPLE GEOMETRY

Your 3D models should be as simple as possible. If you can't get something to look just right with a lower poly count then you need to think about that objects importance in your game. Can you remove that object or use something else in it's place to get the point across.

GAME LOGIC

Be careful with the code that makes up the logic for your game. In Unity, it's easy to forget that invoking GetComponent(), FindObjectByType() and Instantiate() is very slow. Use simple solutions rather than complex ones to make it easier to tune and troubleshoot. Don't be sloppy and program smart. I know this tip may be sort of a no brainier but I found that taking a critical eye to my game code helped a lot with my overall performance. I had gotten use to being able to make mistakes and not paying so dearly for them.