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:

Double down on engineering – More tech needs, less asset budget. Trade artists for engineers. Make sure someone on your team has shipped something in VR – Ideally your tech lead. Don’t Skimp on preproduction – Prototype aggressively, define hardware/QA/pipelines first. Respect the minspec – Pick your platforms, identify your minspec, and stick to it. Realism is important, but comfort is king – Use realistic proportions, but framerate/comfort is priority. Start small – Maintain vision, but start with a fraction of what you’re eventually trying to build. Expect the unexpected – Prepare for rapidly evolving hardware, dev tools and marketplace.

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:

>10 total headcount: 3x

11-50 total headcount: 2x

50+ total headcount: 1.5x

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.