With Samsung’s Gear VR now out in the wild, yet more developers will be inspired to get started with mobile VR development. While there are many parallels to regular mobile development, there’s also unfamiliar challenges to tackle. To help new developers get a head start, we asked E McNeil, developer of the Gear VR launch title, Darknet, to share what he’s learned.
For the past year, I’ve been developing a game called Darknet, which just launched on Samsung’s Gear VR headset. That doesn’t make me an expert on mobile VR by any means, but I’ve learned some lessons over the course of development. Now that the Gear VR is out in the wild, I thought I should share them with other devs who might be thinking about joining in the fun.
See Also: Samsung Gear VR Detailed Review: Part One – Design Comparison to Oculus Rift DK2
The Gear VR is a fantastic piece of technology, but there are some challenges you should keep in mind before you get started. First of all, mobile development is hard. You’re dealing with a device that fits in your pocket, and that always entails some limitations. Second, developing for VR is hard. It’s a brand new medium, and with no established conventions to rely on, we’re making it up as we go. Third, developing games is hard. Even when you set all the technical challenges aside, inventing a game that’s actually worth playing is no easy task.
Developing a game for the Gear VR involves tackling all three of these challenges at once. It’s certainly not impossible (witness the level of polish in the Gear VR launch lineup), but you’ll make your life a lot easier if you understand the platform’s limitations and design around them from the start. There’s a lot to consider, but I think you’ll be pretty well-served by keeping three basic imperatives in mind:
1. Make It fast
Gear VR games need to run at 60 frames a second, at 1440p resolution, in stereoscopic 3D, on the Galaxy Note 4. If a game is running slow, it’s much more noticeable in VR than on a 2D monitor.
Luckily, the Note 4 is a pretty powerful phone, and Oculus has done some work to make your life easier. Most notably, the Gear VR SDK implements something called “asynchronous time warp” which helps smooth out the experience and reduce headtracking latency. With asynchronous time warp, you can miss a frame occasionally and nobody will notice. However, you can’t rely on it entirely; as John Carmack, Oculus’ CTO, characterized it, “this is frame rate insurance. This is not magic where you don’t have to worry about performance.”
So my advice is to start worrying about performance before you even begin coding. The official performance guidelines suggest a rough budget of 50-100 draw calls, 50k-100k triangles, and 50k-100k vertices at any given time. Dynamic lighting and shadows, multi-camera setups, and post-process rendering effects are ill-advised. There are some positive notes too: the Gear VR can handle hi-res textures; I was able to use alpha blending to great effect, and the CPU is reasonably powerful, but those features have their limits as well.
When I was porting Darknet to Gear VR, I was able to come up with a few tricks to speed things up, but it would have been easier if I had planned around the mobile performance targets earlier. Make a budget for your geometry, and keep an eye on your draw call count as you build the game. The first crop of Gear VR games tends to feature simple graphics, tightly-contained scenes, and heavy stylization, and most of them still look great. Use that as inspiration.
See Also: Optimizing Games for VR Is About Finding Creative Solutions – Darknet Developer Shares His Insights
Also, keep in mind that your game can never be too fast. On a PC, spending too much time on optimization is a waste of effort. On the Gear VR, more optimization means that you can afford to turn down the clock speed of the CPU or GPU, which means less battery drain and less heat buildup. A game that runs at full throttle can overheat and interrupt the game in a matter of minutes, so if you want to allow for longer play sessions, it’s a good idea to put a little more effort into planning for speed.
2. Make It comfortable
If your game makes people sick, they will not give you a second chance. VR-induced nausea can be pretty horrible, and it will almost always be your fault as the developer. Don’t expect your players to be acclimated to VR. Instead, design for a comfortable experience from the start. The first step to avoiding nausea is ensuring smooth performance, as discussed above, but there’s a lot of other factors that you should keep in mind.
One of the biggest unsolved problems in VR is how to let the player move around the game world. Moving the player’s viewpoint causes a perceptual mismatch between real and perceived motion that can induce nausea. But it gets a lot more complicated than that! Direction, acceleration, and frequency of movement are some of the many factors that you should experiment with. Still, the safest bet is generally going to be a stationary experience. That’s not a hard-and-fast rule. I break it myself! And perhaps there’s great opportunity to be found in the exceptions and special cases. Just keep this issue in mind when planning your game.
Even if the game isn’t moving the camera in any unexpected ways, the player can cause a similar problem. The first generation of the Gear VR does not have positional tracking, the ability to track head movement through 3D space. That means that every time a player leans forward to look at something, the game world will move with their head, instead of their head moving through the game world. Needless to say, people learn to avoid that behavior pretty quickly, but it’s probably a good idea to avoid any features that encourage players to lean forward, look around corners, or otherwise lean about in real life.
You’ll also need to deal with the potential hazards of stereoscopic 3D. Everything in the world has to exist at some depth, and it’s important to avoid depth conflicts in which an item is placed behind another, yet drawn in front. It’s easy to cause uncomfortable double vision and eye strain if you ignore these issues.
I don’t want to make it sound like developing for VR is like walking through a mine field. These issues are the flip side of the medium’s strengths. It can be powerful to play around with stereoscopic 3D effects, or to give the player a little rush of acceleration. Just remember that you can’t go crazy with it, and be mindful of the potential costs.
3. Make It Fun
If you want your players to have fun, make your game fun. I’m aware of how obvious that advice sounds, but I think it’s worth keeping in mind when it comes to VR. Virtual Reality is a novelty for most people, and I suspect that their initial surprise and delight is often mistaken for enjoyment of whatever game is being shown.
Don’t fall into that trap. Don’t lean too hard on the device or the medium for success. The novelty wears off, and if the core conceit of your game is that it’s “like X in VR, but not as good”, then that game will be quickly forgotten.
There’s no need to port the past into VR. What VR really represents is a new frontier to explore. Try to focus on the unique strengths of the medium, rather than the hype (see Keep Talking and Nobody Explodes or A Night At The Roculus for some wonderfully creative examples of Doing It Right.)
Much like the Wii or the iPhone, the Gear VR is going to need new ideas to fulfill its potential, and the more developers keep this in mind, the better. The Gear VR is an impressive device and Oculus’s first foray into consumer-oriented VR. It’s exciting, and I’m looking forward to seeing where it goes!