Hi! My name is Coray Seifert, I’m the Director of Production here at Experiment 7. I’ve been working on VR games in various capacities for the past 4 years, first with Impeller Studios, then with Autodesk’s AR/VR Interactive Group, but most meaningfully with the fine folks here at Experiment 7. Over that time, I’ve made a number of horrific mistakes that haunt my dreams to this day. I’d like to share some of them with you!

If the beer is virtual, are the calories real?

Below you’ll find 7 lessons I learned working on VR strategy games at Experiment 7. I wanted to put this list together so others who are just getting into VR development can avoid some of the same challenges.

Why spend the time to share key learnings with potential competition? The bottom line for our corner of the industry is that the more teams there are making great VR games, the more consumers we’ll see adopting VR platforms, and the better the market will be for all of us. Just like how Tesla shares their best practices with their competition to help drive their industry forward, we hope that creating a marketplace of shared ideas will help the VR game creation space move forward as well.

Why is VR different?

In traditional game development, we have experiences, best practices, and cautionary tales that effectively guide our efforts. Platform migrations have happened in the past and we’ve tweaked our best practices accordingly. What works on PC might not work on console due to input differences, processing power or consumer expectations, so we modify our approach slightly to adapt for the new medium. 

VR, on the other hand, is a complete paradigm shift. Not only do our best practices need to be refreshed, but some of the core tenants of what we believe about game development need to be unlearned. Moving the player’s first person camera may make them sick. 2D planes for VFX can be invalidated due to stereoscopic rendering. UI and UX design has to be completely rethought from the ground up. This is a complete phase shift from the old way of doing things. 

That's no UI object...

In Summary

I find myself annoyed by long-form lists where you have to scroll forever to see if the pillars of the article are worth investing your time in, so here are the 7 lessons, in brief:

If you just came for the pillars, I hope they’re helpful in your adventures. If you’re here for context, let’s dive into the details!

Lesson 1: Double down on engineering

Let’s start at the beginning.

When you’re building your team for your VR project, you’ll want to staff heavier on the engineering side than you would for a traditional game project. Further, it's optimal to populate your team with a greater percentage of experienced developers than normal. 

While more engineers doesn’t perfectly equate to increased velocity, the simple fact is that every problem you face will require new solutions, a risk that can be meaningfully mitigated with people power. Even if you’re using a proven commercial game engine, everything from feature development to optimization takes a long time on VR and involves a significant learning curve. These are new knots to untangle and for the most part, very few people across the industry have meaningful experience in VR.

Here’s how I would recommend adjusting your engineering team size: 

If you’re working with a fixed budget on your game, this may mean scaling down your art headcount, which isn’t great in and of itself. One mitigating factor is that stereoscopic rendering means you're basically rendering everything twice. A game of comparable scope simply has fewer pixels it can push through the renderer.

Accordingly, the content requirements for VR are lower than other platforms. If you think back to past generations of console games and the scope of art created for those games – both in terms of the raw asset density and in terms of the amount of polish per asset – you can get a good sense of where VR is in its current (2017) iteration. 

In an ideal world, I recommend a small VR art team laden with senior artists who enjoy new technology challenges and plenty of technical artists who are passionate about the medium.

The good news on this front is that great engineers are frequently drawn to new technology problems, just as great artists can be drawn to new mediums of expression.  You can harness that excitement to bring fantastic people into your organization.

Lesson 2. Make sure someone on your team has shipped something in VR

It’s one thing to read about the technical limitations of VR or talk to someone who has shipped a game in VR, but don’t talk yourself into thinking you can make it without significant input from someone who released a commercial product on the platform. You need someone who has directly worked on solving the unique problems of the medium. It can be a freelancer, consultant, or advisor, but ideally that person is someone who is a core member of your team. 

The best case is if this person works in the engineering vertical of your company, even more so if your VR expert is the head of your engineering team. This allows that person to translate those experiences working on the platform directly through their team, providing that intrinsic, internalized knowledge of VR-specific challenges to everyone working on the technology that drives your game.

Experiment 7 is lucky in that our Technical Director, Mario Grimani, has been working in VR since the days of duct tape and bailing wire. One of our engineers worked on open source VR solutions. I worked on some of the very early (and very rough around the eyeballs) VR prototypes internally at Autodesk. Those experiences – often in figuring out what doesn’t work on the platform – have been crucial to the success of our team, even more profoundly than in traditional game platform transitions, because of the transformative nature of VR.

Baby steps from the Autodesk days...

Lesson 3. Don’t skimp on preproduction

New tech is exciting and none more so than VR. Which is why it’s vitally important that you take the time during preproduction to plan, prototype and test. Don’t get too excited and run straight into the teeth of your project! 

Stick to your phase gate plan. Build and iterate through your concept, look & feel, and early prototype in preproduction (which will take longer than you expect, especially for your first project). Getting a new asset pipeline for VR set up is no small task - do it early. If you wait until the production phase to finalize your content and feature workflow, you’ll spend your production cycle firefighting and redoing key systems, rather than delivering great features and content.

Make sure that you’re aggressively prototyping at every phase, even with proven mechanics. We made the decision to go with a relatively low-scope chess game for our first title, so we could easily integrate a Chess engine and use Unity store assets to test the concept of table games in VR early. That process, as rudimentary as it was, revealed tons of issues and opportunities in our core design and in our technology expectations. Issues that would have been hugely problematic (or significant missed opportunities) if we had left them to the end of the project.

"Okay, so imagine you've got a table...and it's magic..." - Geoff, probably

Finally, during preproduction, budget more time than you think for infrastructure. You can’t just buy a few machines and desks and be off to the races. Depending on the platforms you’re targeting, the various combinations of hardware and software can take significant time to track down, given the wide range of headsets currently in use (with new ones coming online every quarter). QA infrastructure can be especially difficult to get going on new VR projects given the specific physical device requirements at the scale of a full QA team.

Lesson 4. Respect the minspec

In VR, more than any platform, framerate is more important than fidelity. 

As you may or may not know, framerate in VR has an outsized impact on the overall experience. High framerates (90+ fps) lead to a smooth experience, while lower framerates can lead to a profound sense of discomfort and render your application unusable to a significant portion of your audience. 

No matter how aggressively you scope for memory and processing power, content has a tendency to come in over budget – make sure your asset budget has lots of buffer room; more than you think you need. Things will get broken by new platforms that are dynamic and constantly evolving – make sure you’re accounting for this so that when something does break, it doesn’t completely nuke your game. Users will do horrible, horrible things to their hardware – make sure to account for your end users installing tons of CPU and memory-hogging applications on the target platform. 

If you’re multi-platform, set goals based on your lowest possible performing platforms…and stick to them! This is a non-trivial task, as it requires business, technology, and creative buy-in. Push this to the top of the priority list. 

Lesson 5. Realism is important, but comfort is king

Realistic proportions, movement, and physical relationships are critical to creating a VR experience that makes use of presence. Content that is out of scale with the world around it risks appearing "spooky" and unsettling, leading to subtle but meaningful feelings of cognitive dissonance in your users. Unrealistic or unfamiliar gravity, viscosity, or friction can have the same effect.

Door frames, windows, tables, chairs and other common real-world physical objects in game space are especially susceptible to this phenomenon. For games grounded in reality, there is a pretty simple solution. Measure things and stick to those sizes. This constraint can certainly be a limiting factor, but can also be a creative challenge that leads to dynamic and innovative solutions to problems both complex and mundane.