Choosing the Right Software Tools for Our Road Trip into VR

BY Matthew Lovelady

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.

VR Virtual Reality Languages

Navigating our programming options for a trip into VR Virtual Reality

Route 1: Next Gas = 100 Miles

The first language option is JavaScript. JavaScript is a simple, easy to learn, web standard, and a lot of Unity and VR materials are written in this language. However, the JavaScript route lacks vital assets and capabilities that we would otherwise need for a project as complex as ours. For example, JavaScript lacks a type system to help alleviate trivial errors and also gives us programmers better-defined info about the program. JavaScript also lacks an event-based system, which would be much better appropriated for our needs on a project this complex. In other words, JavaScript is certainly a route that will get you to your destination as fast as possible, but it has only one rest stop along the way–which is fine until you realize you are hauling three kids slurping down venti Pumpkin Spice Lattes, and you still have four hours before you hit grandma’s house. So although this route may be the most simple, preferred route, there is one that better suits your practical needs as a traveler.

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.

Scroll Up
 Previous  All works Next