Tips For Getting Started With VR

share this page

Just getting started in VR game development? Here are some helpful tips!

In 2017 I was invited to speak at the Game Developer’s Conference about teaching VR game dev along side Jesse Schell, Robin Hunicke, Jichen Zhu, and Ira Fay. At the time I was the Technical Director of the University of Southern California’s Interactive Media and Games Division and had worked on several independent/student VR projects, produced a few 360 vr videos, had taken part in several VR design workshops such as the oculus launchpad program, and had given a few lectures around VR game design. I took this invitation as an opportunity to share my best practices for those just starting with VR game dev. The following is a version of that talk. This tutorial is not meant to be tied to any platform, but instead presents general guidelines for VR development.

VR is an interesting design medium in that you’re essentially overwriting a primary sense, sight, with something completely constructed. This in turn creates a different experience than a classic videogame. While traditional videogames are confined to a 2 dimensional screen, a VR game provides a spherical 360 canvas. This doesn’t mean that VR is a better experience just that it’s different, which means the design process will also differ. If you’re not careful you may find that what you want to create and what your players will experience are two very different things. In order to avoid that experience it’s important to pay attention to these differences, and…

Get a build onto the device quickly

If I’m teaching a class on VR game design, one of the first assignments I give my students is to build a very simple hello world project that runs on the device they’re developing for. Most of the time this means an empty scene with a cube, and a camera that supports head tracking. Something very simple that doesn’t take long to create and that you can easily compile and deploy. This does several things for the students:

  • First, it gets them comfortable with the device, which is important given that this is the target platform you'll be developing on. For some students it may be their first time trying VR, let alone developing for it. Getting students on the device quickly helps them to better understand the platform they’ll be working on and allows them to start thinking bout engaging experiences they might create that take advantage of the platform.
  • Second, It helps to clear up any steps in the pipeline that may cause problems. For example, if you're developing for Gear VR or some other android platform you may forget to change some important variables like the SDK path or company name. Without setting these variables you won't be able to compile, let alone see it on the device. Other problems, like not provisioning your device, or any sort of errors related to hardware are also exposed by attempting to build quickly. Trust me, it's much easier to find and address these problems early in the design process.
  • Finally, and most importantly, it makes the device an important part of development from the start. You will need to test your game on the hardware you're developing on constantly. Might as well get the process down.

Getting on the device quickly also helps to avoid problems with editor-only development. Because VR is overwriting one of our primary senses, sight, we’re more likely to focus on flaws, or things that are “off” in the experience. In the editor, sometimes we have a harder time noticing these flaws. Problems with resolution, lack of texturing, and scale become much more noticeable in VR. Nothing is worse than thinking you’ve made a great level, only to find that the scale is completely off on the device. By continuously loading builds onto your device you’ll be able to spot and correct the problems as you go.

If you don’t have access to hardware at the moment, I would suggest you make your VR game android compatible that way you can run it on any android phone using google cardboard which you can pick up for $10-$20.

Protip: Have a simple noisy texture that you can apply to your object while you greybox. The noisy quality of the texture is important because it helps your eyes focus and amplifies the illusion of depth.

Playtest Playtest Playtest

My next piece of advice is to respect the player by Playtesting, Playtesting, Playtesting! The goal here is to produce an experience for players that doesn’t make them feel terrible, or make them throw up. The transition from everyday life to VR is still a bit jarring. Think about it: Players will have to physically put on a device that blocks out their surroundings to play your game. This may make some players feel vulnerable. They at the mercy of the developers (you) trusting that they’ll do their best to make the experience a pleasant one. The least you can do is try your best not to make them feel nauseous.

Motion sickness is still a big issue when developing VR games, so anything you can do to reduce motion sickness, the better. Some tips I share with my students are:

  • Keep the frame rate north of 60 fps for mobile (this will go up as tech gets better) and 90 fps on desktop.
  • If you have movement in your game, keep the acceleration gradual and constant.
  • Establish points of reference. Purdue recently discovered that putting a virtual nose in the scene seems to have a stabilizing effect which reduces motion sickness by 13%. I’m not saying you have to put a nose in your project, but an object that stays in the same general area, or something big off in the distance, will help players orient themselves.

There is cool active research on reducing motion sickness and increasing player comfort. So keep an eye out for strategies to reduce motion sickness.

Playtest with others

At this point it should be obvious that playtesting is a big deal for VR game dev (any game dev really), but it isn’t enough to playtest by yourself, or even with the same people. Humans are resilient and can adapt to things fairly quickly. The same is true for VR games. You get used to your own VR projects… but others don’t. So something that seems fine to you may make others very uncomfortable. For that reason, user testing with new people, or people who haven’t played your game in a while, is highly recommended. Other than motion sickness something that may not bother you, but will probably bother others, is your game’s UI. I can probably write an entier post on VR UI design, but for now let’s stick to a few rules of thumb. Mainly, your shouldn’t stick things directly onto the player’s head. Instead, try to find ways to have the UI embedded in the world themselves. Of course, there are exceptions to every rule, so ultimately just pay attention to how your playtesters react and make changes accordingly. While you’re playtesting, make sure to listen to their feedback so that you can address any issues they encounter later. If you need help getting feedback from a playtester, you may want to follow the I like, I wish, What if? format.

By following the above guidelines you are much more likely to develop a comfortable VR game. Got some tips for VR? Contact us, connect with us on Facebook, or let us know on Twitter.

Till next time, game on!