Gamasutra: The Art & Business of Making Gamesspacer
arrowPress Releases
  • Editor-In-Chief:
    Kris Graft
  • Editor:
    Alex Wawro
  • Contributors:
    Chris Kerr
    Alissa McAloon
    Emma Kidwell
    Bryant Francis
    Katherine Cross
  • Advertising:
    Libby Kruse






If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 

VR Game Development Problems and How We Fixed Them

by Mario Rodriguez on 02/21/17 08:53:00 am   Featured Blogs

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.

 

When thinking about creating a video game, there are multiple questions that pop to your head almost instantly:

  • What engine will we be using?
  • What are the main mechanics of the game?
  • What kind of art style do we want to achieve? etc.

When creating a VR game, these questions come 2nd. First, you have to answer the following and more:

  • (If creating a room scale game) Do we have the space?
  • Will we have enough equipment for the team to test the game on?
  • If we do, how do we prevent problems like losing tracking?
  • What is fun in VR? etc.

These were some of the questions we had to answer when we were creating our first VR game, Mouse Playhouse, even before we thought about what engine or what mechanics we were going to have in the game. I was the producer for Mouse Playhouse, the first VR game created at the SMU Guildhall. 

Before we created the game, we tasked our level designers to play as many VR games as possible in order to understand the hardware. We wanted to capture what was fun in VR while maintaining the scope we had for our project. After we solidified our idea, completed several prototypes and moved on to production. However, we had to worry about several aspects that were different from our previous experience of creating traditional video games. 

 

Space

Our team decided to create a game for the HTC Vive which meant we had to find a space that could fit as many Vives as possible. We managed to secure the largest room at the Guildhall for this project. Once we got this space, we were able to fit four HTC Vives (one for each department:art, level design and programming and one for QA). We also marked each area with gaffer tape so that our room scale was the same every time we had to run the room scale set up on SteamVR. 

 

Simulated VR Experience

Our team was a total of 18 developers and with only four Vives, it meant we had to either be very efficient when using them or take some time to create tools to help our team when others were using the Vives. Our programming department created a tool within Unreal Engine that would simulate the VR experience. They attached two controllers to the camera and used the mouse to simulate movement. This helped our developers play the game without using the Head Mounted Display (HMD). However, assets do look different (scale, textures, etc.) when using the HMD so we still had to test everything with the headset on. Therefore, the department leads had to approve assets while wearing the headset in order to make sure they followed and met our quality standards. 

 

Tracking Issues

The Vive uses base stations to track the headset. When you have 8 base stations in close proximity, they start talking to each other and confusing themselves. We took several attempts to fix this problem but we ultimately found that the best way to get around it was to create physical boundaries between each of the Vive stations. We first used whiteboards to try to remedy the problem but we found that the reflective surfaces didn't really work for us. Then we tried putting blankets on the whiteboards and it seemed to help but now they were too short. We then found a big frame used for photo ops and hung the blankets on it and that seemed to do the trick. So once we solved that problem, we purchased big curtains to create walls for each station and our problems of losing tracking were a thing of the past. 

Curtains as Walls

 

90 FPS

Lastly, in order to have a successful VR game, the game must feel comfortable and not make people sick. This is why VR games must always be at or above 90 Frames Per Second (FPS). This is an issue that is particular for VR and was a huge deal when making our game. So in order to make sure our game followed that rule, our programmers stuck an FPS tracker right under the left controller. Whenever we needed to check the FPS while in VR, we looked down and turned the controller over to see what levels were causing the problem. This became a critical check when we creating new puzzles in the more complicated levels.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

So just as a warning, do not underestimate these problems because they are new to development. Even with our accelerated deadlines, we managed to overcome them and finish the game on time. These new problems are a small shift from traditional game development but I feel have only helped our industry grow. Although VR game development is not completely the same as traditional game development, it was still a fun and rewarding experience for us and I would recommend anyone debating about it to go ahead and try it. 


Related Jobs

NEXON M
NEXON M — Emeryville, California, United States
[11.14.18]

Software Engineer
NEXON M
NEXON M — Emeryville, CA, California, United States
[11.14.18]

Data Engineer
Tender Claws
Tender Claws — Los Angeles, California, United States
[11.14.18]

Senior Unity developer
Wargaming.net
Wargaming.net — Chicago, Illinois, United States
[11.14.18]

Senior UI Engineer





Loading Comments

loader image