Choosing the Right Software Tools for Our Road Trip into VR
The car is packed, the passengers are loaded, and the snack rations have been properly distributed. The sky is clear and the road is calling. Now, it’s time to make the most important decision of the road trip: Which GPS app should we use to arrive at our destination?
Road trips are probably one of the most exhausting activities I’ve ever experienced, yet I always seem to drop everything and call shotgun whenever I get a chance. For the modern road trip, there is a quintessential question before shifting the car into gear: What GPS app will we use?
On the surface, all GPS apps work the same. They all get you from Point A to Point B. Once the destination is input, you then have to create a mental list of pros and cons for each route option presented. Do we need to get there in a hurry? Do we want to get off the beaten path? Do we want spend $20.00 in extra gas to avoid spending $1.50 on toll roads?
If we compare VR software development to a road trip, the deciding factor for identifying which route to take is based solely on efficiency. In other words, which development path will be the most efficient to take us where we wish to go?
We knew taking on a virtual reality project would be challenging, and we expected a lot of long days and sleepless nights behind the wheel—er keyboard. However, just like a well-planned road trip, we knew we could reach an amazing destination by exploring both familiar and new roads.
In the VR world, two primary tools dictate your route options: Unity and Unreal Engine. Between these two options, we have more experience with Unity’s environment and workflow (and, we have high hopes it won’t lead us aimlessly astray in a series of left turns).
Within Unity there are three different programming languages. Like your GPS apps, each will get you to the same destination, but they all may require a completely different route to get there.
Route 1: Next Gas = 100 Miles
Route 2: Lock the Doors and Stay in Your Car
Unity’s second option is a language called Boo. Boo is the route option that takes an hour longer and winds through 50 extra miles of scary back roads at night (must be why it’s called Boo–scary stuff, indeed). Our team does not have any experience on this route, and it generally isn’t supported by lots of ideas or examples in the tech community. In our road trip metaphor, this route is like an abandoned stretch of a two-lane road on the way to Bates Motel—not a good place to lose your way and ask for help.
Route 3: Every Exit is Like Big Rock Candy Mountain
Unity’s third route is C#, and it passes through a magical land where every highway exit makes your trip better. No matter where you stop, you’ll find a Chick-fil-A that is 0.5 miles to the left—you’ll see it right next to the Starbucks with no line and the giant Loves truck stop with the sign for the world’s cleanest restrooms.
On a more technically accurate note, C# naturally aligned with the intended scale and vision of our VR project. Establishing the proper “fit” upfront ensures that your project does not extend out of the realm of the chosen programming language. C# is also very easy to debug, write, and scale making it one of the most efficient language paths for us to follow.
Additionally, C# has an intuitive event system that we have been waiting to take advantage of as things have continued to progress in the VR world. Our excitement for the event system is similar to the excitement one feels as they approach the exit to Corn Palace in South Dakota (don’t pretend like you haven’t been dying for an excuse to go). At any rate, C#’s event system creates simplicity in the logic for VR user activities such as picking up virtual pieces of a puzzle by firing an event each time a piece is picked up. The event system then allows any other element in the VR application to subscribe and react to the initiating event.
The event system can be complicated to explain, so let’s put it in the context of our road trip metaphor. Let’s imagine that the driver–we’ll call him Ethan–insists that everyone in the car has to clap every time they see a yellow light. Since Ethan is driving, we don’t want him to be distracted by having to tell each person separately to clap every time there is a yellow light. A better approach is to use an event system so that everyone in the car can ‘subscribe’ to the yellow light and clap on his or her own when one is seen. This system reduces the workload, and makes the code much cleaner.
And now…No Sleep Till Brooklyn!
With our VR hardware and programming language nailed down, we’re ready to hit the road towards our next stop. Follow this series of blog posts for a behind-the-scenes look at how we’re exploring the 3D modeling and prototyping that we need for our first VR experience.