Port Translation
How does porting a VR game look like when I only kept one headset in mind?
If you’re wondering what “Port Translation” or “Porting” is —
Have you ever wondered why some applications are on Windows but not on Mac? Why you can’t just play an Xbox game on the PlayStation?
This is because there are a multitude of operating systems and computing environments that require different programming for an application to work. So while an application is already working or was launched on one computing environment, it might require additional or entirely different code to be present in order to work on another one.
While these applications generally only need certain software changes, it is entirely possible for it to need to meet certain hardware expectations too.
In software engineering, this process of adapting software or hardware to make these applications usable in another environment is called porting. Software is considered portable when it is easier to add changes to it rather than starting over from scratch. Some environments are so drastically different from each other, or the code wasn’t written with enough portability in mind, that it would be quicker and easier for software engineers to start all over — in that case, porting wouldn’t be feasible.
My VR Escape Room
Image taken within first room of locked door.
The VR Headset I Used
The first and only VR headset I have ever owned happens to be the Valve Index, which was created and manufactured by Valve. It goes great with SteamVR, essentially a kind of tool or software made to experience VR content on practically any kind of VR Headset. It makes VR easier to use on PC and is downloaded through Steam.
The Valve Index is a 6-DoF (Degrees of Freedom) headset, rather than being just a 3-DoF headset. This means other than having the 3 translational movement degrees of freedom, it also has another 3 degrees for rotational movement. Like so:
Image found here. Click for more DoF information.
Essentially this means headsets with 6-DoF tracks user movement in the x,y, and z axis. If the user walked around, bent over, reached up, leaned to the side, and so on — then all of these actions would normally be tracked in the targeted VR application. On the other hand, these actions couldn’t be tracked by a 3-DoF VR headset at all.
So although 3-DoF headsets tend to be cheaper, this is why some applications should only run on a 6-DoF VR headset. 3-DoF headsets are better to be used when watching 360-videos or generally with an application that is meant to have the user either sitting or standing and just experiencing what’s going on around them. Applications meant for 6-DoF headsets involve a lot more user interaction, such as Beat Saber.
What If I Ported to Another VR Headset?
One of the most popular VR headset brands is Oculus. It was founded in 2012 and is now currently owned by Facebook.
Oculus Go — 3-DoF
While working on my escape room, I didn’t really account for the differences between 3-DoF and 6-DoF. This means if someone was to use another headset in my application, in this case the Oculus Go, their experience may be altered or impacted in a way I didn’t consider.
For instance, the teleportation method of movement implemented in my escape room would seem to be beneficial for 3-DoF headset users. One would think this means Oculus Go users wouldn’t have to worry about walking around in-game, but it would still be difficult for them to interact with actual objects in the game. This is because items can easily be or become out of reach and sometimes the player can’t teleport any closer.
Plus the fact that Oculus themselves recommend using the Oculus Go while sitting. This poses an issue as the way the player camera’s point of view changes is based off where the user’s current head position is — determined by the y-axis. Since the y-axis can’t be tracked by a 3-DoF headset, the application would have to use the player’s camera’s default y-position … floor level. Meaning, the player wouldn’t even have a view of the room in the first place.
If I was to make this escape room playable on the Oculus Go, I would need to use the Oculus Mobile SDK, which is entirely different from the SDK I used for the Valve Index, OpenVR. The Oculus Mobile SDK uses C/C++ for Android development, compared to my implementation of OpenVR using C# and the Unity interface. As I would have to essentially build from scratch, porting would honestly not even be an okay idea.
The interactions within the VR escape room would have to change as well. The Oculus Go controller cannot track the gripping motion like the Valve Index’s controllers. This is because the Oculus Go controllers only track hand motion, pointing, and clicking — as intended for navigation within VR.
It’s also entirely possible for graphics needing to be changed due to the difference between the Oculus Go’s graphical capabilities versus the Valve Index’s — such as:
- Resolution: 1280 x 1440 vs 1440 x 1600
- Field of View: 101 degrees vs 130 degrees
Additionally, the Oculus Go runs not just on it’s own, but on a completely different processor than the one the Valve Index operates on.
Oculus Quest 2–6-DoF
An entirely much better and more realistic VR headset to port to would actually be the Oculus Quest 2. This Oculus headset is much more reasonable because, like the Valve Index, it has 6-DoF.
Also, while the Quest 2 could run on the same operating system as the Oculus Go, it could also be connected to the same OS as the Valve Index. This leads to the fact that OpenVR can actually be used with an Oculus as it’s main purpose is to help software run on multiple kinds of hardware. OpenVR essentially makes these applications not need to know the specific VR hardware they would normally have to target.
Additionally, I downloaded the SteamVR plug-in off the Unity Assets store. This basically allows me to easily include the controllers for the Quest 2 and map the buttons accordingly. After doing that, this VR Escape Room should be able to run on a Quest 2!
