August 26, 2019
Code & Design
Whew! After an exhausting eleven months putting in two hours a weekday & eight hours a weekend, I finally shipped my solo VR experience, CryptoSpace. Since November of 2018, I’ve moonlighted on this project, marrying my two current interests: VR & cryptocurrency.
The idea itself, a VR blockexplorer, a visual aid to educate on cryptocurrency, had been on my mind for the greater part of 2018; in fact, I’d built a tiny webvr prototype. Confident with JavaScript & web development, I wanted to take a full leap into the burgeoning world of VR development. Unfamiliar with either of the popular game engines & their respective languages, I gave both Unreal Engine & Unity a download; for reasons that merit an entire other article, I ended up going team Unity.
Ironically, the largest lesson I learned during this journey reared its head near the very end of the first build. I spent an entire eight months building with the Oculus SDK & targeting the Oculus store, only to be “key’d” at the very end & have no option but to restart from scratch with the SteamVR 2.0 plugin. Brutal lesson learned. Deciding which store to publish to, Oculus or Steam, is a heavy, impactful decision worth researching extensively at the beginning, since ultimately it affects the entire build.
In my very humble opinion, if you’re an aspiring indie VR developer publishing your first app, you’re better off targeting the Steam store.
Why?
Fortunately & unfortunately, Oculus has snatched the baton & positioned itself as the main gatekeeper for newcomers. With VR still generally untested by the early majority of consumers, a strict, high, standard in gameplay experience makes logical sense as the VR company with the largest market share, for the players.
However, the unfortunate part of Oculus’ cavalier attitude reflects at the developer level, specifically indie developers. Unless you have some serious Unity/Unreal chops or are part of a AAA studio, Oculus is not likely to help out or support your game. In fact, Oculus is notorious for “key-ing” submitted builds with zero feedback. Instead of flat-out rejecting experiences or placing them on the store, Oculus chooses to “accept” VR experiences for a private key program; which means that it’s completely up to you to build the sales infrastructure for selling private keys (one at a time, through a self-served store, etc…). Getting “key’d” with zero feedback is essentially a dead-end, a silent grave where your app dies but at least Oculus can add you to their statistics. If reviewers offered feedback on what to fix on submissions, it’d be one story, but it seems like that’s the exception, not the norm.
If it’s your first build, I recommend aiming for a Steam store release. Position yourself with an opportunity to actually test a market of users & hopefully see some cash so that you can continue building & growing.
In VR land, Implementing any form of user input is still a trial-&-error experience. Input systems are tricky, game-wide, & cascade down from each platform respectively, Facebook with its OculusSDK & Steam with the SteamVR 2.0 plugin. It, therefore, makes sense to carefully plan these modules out ahead of anything else. In general, I found it useful to answer these two questions before diving into a project:
Does the user have virtual hands? Do they need to grab items? How about shoot a gun? Point with a laser? Shoot bow & arrows? That’s the first part of the equation you need to tackle; take inventory of all the input types your game or experience requires.
Second, a common conundrum for programmers in any paradigm: build from scratch or leverage an existing component/module/prefab? VR land is no different, you’ll have to make this decision for each input system. For example, the laser pointer (seen above). A fairly common way of accepting input, both the Oculus SDK & SteamVR plugin offer laser pointer prefabs. Does either of these offer the functionality & flexibility you require? Or are you better off building a laser pointer from scratch? It’s a question only you’ll be able to answer by taking the time to test each option out. Take inventory, list out requirements, & do the research — test the out-of-the-box prefabs before venturing out into the wilderness & building from scratch.
Input systems, like prefabs below, are necessary for every scene in your game or experience, so slow down & double-check the basics. It’s worth doing this right, once, at the beginning.
DRY, don’t repeat yourself — the mantra of the modern programmer. Unity, thankfully, makes this practice practical through the usage of its brilliant prefab system. The official documentation is a superb resource worth reading through.
Again, coming from JavaScript/web development, I was entirely unfamiliar to the built-in, anti-repeat pattern provided by prefabs. In short, the prefab system allows you to create drag-&-drop reusable GameObject assets, all with its custom components, property values & child GameObjects completely in-tact. Strategizing the development of your game / experience with prefabs planned & structured out ahead of time is a simple, yet powerful development pattern that you can’t go wrong with.
Start by asking yourself what large, complicated (meaning including shading, animations, scripts, etc…) asset you’ll likely use in more than one scene. Then, if necessary, create an empty scene & new directory strictly dedicated to the creation & maintenance of a prefab.
To illustrate with an example, in CryptoSpace, the user can step into multiple crypto-worlds; each world contains an interactive blockchain (seen in image above). This blockchain, which is a custom 3D model with multiple animations, components, & child GameObjects, is a perfect target for a prefab:
It’s a running joke that developers love to save a few hours of planning by spending a few weeks programming. Right next to input systems, prefabs are where you can save a disproportionate amount of time. With that in mind, I’ve discovered that planning, specifically planning for Prefabs, is the least you can do before firing up Unity.
Realistic store expectations, accounting for input systems, & planning in terms of prefabs — the three largest lessons this web-developer-turned-indie-VR developer took away from his first deep dive. If it’s your first time working in VR or you’re on the sidelines seriously considering it, I hope these guidelines save you ample time as you trek forward.
I’ll leave you with an additional closing thought: when it comes to VR development, it’s still very much the wild, wild west. Pioneering days. It’s not too late to hop into the spatial computing train, no matter your current level of programming. If nothing else, at least walk away from this article with the affirmation that the barrier-to-entry for new, indie developers is just low enough where it’s worth experimenting; so fire up your head Oculus/Vive/Index & head on over to Unity or Unreal!
