One of the most exciting things of working with VR games is that everything feels new. Whether you’re a game designer, a 3D artist or a UX expert, if you work with VR you get to feel like a pioneer. But, of course, when you’re a pioneer you often risk getting lost in the wild. Out of the metaphor, this means that if you work in VR you need to deal with a lot of different platforms and a lot of different limitations.

Here at Hatrabbit we are getting ready to launch the mobile VR version of our game Merry Snowballs . The original version of this snowball fight-themed shooter was released one year ago, in a smaller form, on Vive and Oculus. Recently, we decided to convert and expand the game for mobile VR platforms. This article will focus on the specific hurdles and specificity of different mobile VR platforms and how we managed to convert the game for six different configurations in three months without splitting the code base by using branches but, instead, leveraging Unity’s strengths.

Core design philosophy

The most important step in developing a multiplatform game that could be easily converted to mobile platforms was taken, in a sense, already in the concept phase. Even in its first version, Merry Snowballs was a mobile-friendly game because of the limitation we imposed on our design. For example: we wanted to reduce common VR issues such as motion sickness and we wanted a simple but intuitive and compelling gameplay. So we decided early that the game wouldn’t allow player movement and the interaction would be only based on shooting snowballs.

Even the graphics were designed with a similar spirit: the game had to be pleasant and beautiful but small in scope. All of these early decisions made the conversion on mobile platforms much easier. When converting the game, we even realized that we didn’t need to scale down the graphics. The small levels allowed us to keep the original level of detail without much compromise.

Handling controls

Designing controls is probably the most challenging part of VR game development. From a UX point of view, there is still no standardization of controls in VR, mostly because there is simply not enough history to have a set of conventionally accepted controls. On top of that, hardware is not standardized either, so each platform has its own controller and works in a slightly different way. The biggest simplification we did when converting to mobile was to change the way the player shoots snowballs: in the original game you aim and throw snowballs by using the gesture of throwing. In the mobile version, we found that, if the platform has a controller, the best way to aim is by using the gyroscope controls. If the platform doesn't support a controller, or the player doesn't have one, using your gaze to aim and a button to shoot was the most practical and fun way to do it that would work on all platforms. We decided to implement both, and it was less complicated than it sounds.

Code-wise, we decided to tackle the issue of developing to multiple platforms by using platform dependent compilation. This allows us to use very simple logic to display different tutorial messages or to receive inputs from each platform and configuration: Google Cardboard, mobile 360 mode, mobile with controller, Google Daydream and Samsung Gear VR with or without controller.

This approach lets us design around the specific features of each system. For example, in most versions of the game we use a two button system: one button for shooting a snowball and the other to raises your shield. In order to make that work on a one-button system such as Cardboard, we needed to create an ad-hoc solution, so we created a system in which you raise the shield by keeping the button held for a certain number of frames:

Experimenting with ads

Platform dependent compilation turned out to be a useful tool also in another, less predictable way: ads. We wanted to monetize the game in a way that would give the players value without being too obtrusive. A system that would reward players for watching ads seemed like the most logical solution. When integrating ads in our game, we partnered with two companies: Omnivert and Advrty. Omnivert provides native VR advertising, whilst Advrty lets us place ads on in-game billboards, which we feel is a very discreet and interesting way of having ads in game. On the mobile 360 version of the game, we have Unity Ads instead of VR ads. Just like with tutorial message and input, we have different logic for ads depending on the platform so we can use the best ad network for the specific configuration used by the player.

By not branching the code base for each platform and keeping the project unified we managed to convert the game for mobile, Cardboard, Gear and Daydream, with different configurations, in roughly three months.