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.

Preproduction proportions testing

During preproduction, try starting with realistic proportions and aggressively test with white-rooms to avoid having to rework assets down the road. Working from a regimented, realistic base of assets goes a long way towards making the user comfortable in your environment.

All that said, the one guiding principle for VR – especially in these relatively early days of mass market consumer VR – is that comfort is king. It’s imperative to ensure your experience is palatable to your target audience. 

If you’re making a card game for a wide audience, make sure that your framerate is extremely high, your contrast is relatively low, and you’re never accelerating or moving the character outside of motion-tracked head and body movements. If you’re making a hardcore flight simulator with 6 degrees of freedom and non-stop flak explosions, you have a different bar to hit, but core tenants (always high framerates, try to never move the player’s camera unless they’re controlling it, use slower acceleration where appropriate, etc.) are always good to keep top of mind.

Be cognizant that with every increment you push your experience past your target comfort point, you’re losing and alienating another large cohort of users, potentially damaging your reputation and your brand.

Lesson 6. Start small

Find a spark and build from that. There are so many unknowns in VR – especially right at this moment in time – that it requires an entirely new pipeline, process, and technology outlook to bring anything to market, let alone something of notable scope. 

This is VR. You should dream big. However, the best advice I could give at this moment in time is to create a small chunk of that dream with your first VR release. Get that product to the market – to any market – and get into preproduction on your second title with everything you’ve learned. Use that experience to help your team execute more efficiently and at a vastly higher level than the first go round.

This is one thing we nailed at E7. We started off with a relatively small game in Magic Table Chess, moved on to something marginally bigger for our second game, with exponentially larger projects on the horizon. Each step along the way has enabled us to work faster, focus more on experiences than infrastructure, and push our quality bar higher and higher.

Starting to come together...

Lesson 7. Expect the unexpected

This is the agile mantra, but especially so for new, rapidly evolving platforms like VR. It might sound cliché, but the pain is real. These are incredibly dynamic software and hardware products that are constantly evolving in meaningful ways. Platform updates right before VC meetings, cables getting imperceptibly loose and taking someone offline for hours, system background processes triggering and running the game at one frame every other second are all real possibilities that many of you will encounter. 

While there’s little you can do to truly mitigate for these challenges, knowing that something along the way will conspire to foul up your perfectly-planned software project can help you reduce the impact of these issues when they do happen.  

In addition to unexpected critical fails, if you’re working with a commercial game engine or platform back end suite, plan to be rolling over to new versions far more frequently than on traditional platforms. The dynamic nature of these platforms means that new updates address critical issues and can introduce new version mismatches more frequently than stable technology platforms.

In Conclusion
Making games in VR is awesome. I frequently find myself losing myself in our games when I should be doing work, just because the experiences are still so profoundly magical. VR is a new and massively exciting frontier. A stereoscopic wild west.

It all comes together

However, like the American wild west of old, it’s full of danger and adventure. Being cognizant of the perils of the medium can’t help you to avoid these challenges altogether, but hopefully it can help mitigate the impact of them when you hit them.

So, thoughts?

I’d love to hear similar experiences folks have had working on early projects in VR. Horror stories are always great, or if you disagree with anything I’ve said here I’ll keep an oculus out for comments posted to this article.

Yes, I just ended this 2500-word VR article with an eyeball pun. 

This post originally appears on the Experiment 7 Blog.

Coray Seifert is the Director of Production for Experiment 7, a VR strategy game developer based in New York City and San Diego. For more than 15 years, Coray has developed games as a producer, game designer, and writer for organizations like Autodesk, THQ's Kaos Studios, and the US Department of Defense. A Lifetime Member of the International Game Developers Association, Coray was elected to the IGDA’s Board of directors in 2007 at the age of 27; the youngest board member in IGDA history.