I often get asked about how I use different VR devices, or how someone starting a project should choose a platform for a new project, and the honest truth is that it varies – from project to person to end goal of the overall process. That said, I wanted to take today’s Monday Musing post and share with you a few strategies that I use for planning a project, and choosing a development tool and platform for what I want to build.
As a VR developer evangelist, I have a lot of freedom in choosing the kind of projects that I want to build. Sometimes, I like to throw together small proof-of-concept style applications to test out how frameworks play together. Other times, I just want to dive deeper into a specific area of Unity development, and I’ll polish a few scenes in KittenVR. Some projects have discrete goals (“I want to have a playable app by the end of the weekend”) while others are more open-ended (“I want to get better at environment design”).
For specific projects that I want to build, the idea will generally dictate the platform that I choose. If I want to build something small that I can demo easily, I’ll target Cardboard – the SDK is compatible with my Gear VR, which is the headset I take with me when I travel, and it’s easy to have others replicate the project if I’m planning on doing tutorials for the app. That said, there are a few larger projects that I work on when I’m showcasing the full potential of today’s VR devices, and I’ll build those up to take advantage of the Vive or Rift, too. The tradeoff with using the higher-end platforms is in distribution and ease of demoing, but the benefits are stellar if you have a device people can come to for demoing, or a rig that is fairly portable.
Once I’ve picked a platform that I want to target, choosing the development toolset is a combination of several factors. Unity can build to almost every VR platform out there, and is my go-to if my project has a rich environment. Most AR and VR platforms have plugins or assets that work within the Unity editor, and C# is my preferred scripting language, which makes it a common choice for my projects. However, there are a couple of times that I’ll choose a web framework instead – if I’m prototyping a data heavy project, such as my Excel Visualizer, I find it easier to work within existing JS libraries designed to handle lots of data. If I’m really pressed for time, or if I am teaching a hands-on coding workshop that is less than two hours long, I find that WebVR is the fastest to get up and running (especially if I’m teaching students who don’t have Unity installed already).
Ultimately, though, each project requires some considerations for what you’re trying to accomplish. An application that doesn’t require extensive freedom of movement might benefit from the increased market size of Cardboard. Games that require body tracking will be tough to build for platforms other than the Vive.
The more you build, though, the easier it will be to swap between platforms. WebVR renders wonderfully on desktop and mobile VR, so if your project is data-driven or doesn’t require complex interactions, it can be a good choice for easily changing platforms depending on scenario. Unity’s built-in VR tools and camera plugins make it relatively easy to build an experience for multiple devices. The general considerations that I keep in mind:
- Do I want to be able to demo this regularly? Cardboard
- Is this going to be room scale? Vive
- Controller-based? Rift
The two major differences between desktop or mobile VR devices are around performance and interaction decisions. It’s harder to go from a game that was built for the Rift to Cardboard than it is to do the reverse, but the application will always be best when design decisions account for platform differences right off the bat.
Of course, none of this is set in stone – it’s challenging to find a “one rule fits all” with VR!