VR & Port translation
Porting is a process in which a software is adapted to work in a different computing environment from which it was created, it may be another CPU, operating system, or a third-party library. You can say a software is portable when the cost of changing its platform is considerably lower than the cost of coding it from zero; the lower the cost, the most portable the software is.
This process requires an understanding of both the target architecture and the program you want to port, if there are numerous discrepancies between the origin and target, the process would be more complicated and more people will be needed to complete it, this is a reason videogames are difficult to port between PC and console; while consoles are standardized (my Xbox is the same as yours), PCs have multiple distinct configurations from CPU to GPU, they even have hardware consoles don’t have and vice versa (and we are not considering managers and their inability to understand what they are tasking the development team to do).
Now, you may be asking yourself: “How does this affect Virtual Reality (VR)?”; Well, despite being relatively old, VR is a technology that’s been having a lot of focus lately and specially with the tools to develop (like Unreal Engine and Unity Engine) and the hardware to use it (Oculus Quest and Google Cardboard among others) differences are bound to exist making the portability of a software one of the most important points to develop.
In this article we will be focusing on the points to consider when porting into the Oculus Quest (OQ) from Google Cardboard (GC). First, a little bit of history. OQ is a VR headset was released on May 21, 2019 and was developed by Oculus a division of Facebook; it’s an improved version of the VR headset Oculus Go and can run games and apps with any Android based operating system, is also capable of using positional tracking and has six degrees of freedom (6DOF), this headset is considered to be cost effective and convenient but has some downsides with the heavy frame and for the downgrade in quality over PC oriented headsets.
Now suppose you are porting a game from the GC to the OQ, you may be asking yourself: What considerations should I have when making a good port? Are these differences that much of a deal? What are the differences between the controls?
Quick answers:
1. CPU and GPU primarily.
2. Yes.
3. Wait and see.First, you need to take into consideration the nature of your game (or app), if the player will be moving or they’re going through stationary experiences, as the second ones are easier to port from one platform to another. Another issue to consider is the capabilities of the CPU and GPU of the device that according to Schell Games, they had trouble when trying to draw overlapping objects, overdraw they called it, so to solve their problem they had to reduce the particle systems in their game, this affects the visual quality of the product and can draw away customers that focus on that aspect of a game.
Respecting the CPU, another issue Schell Games talked about was the inability of the OQ system to make the draw calls they wanted (their game had about 400–500 draw calls but the system could only handle about 130), which forces any team who have this issue to reduce them or use techniques such as the Atlasing (which is the one Schell games used) to limit the number of things the CPU can draw, as one of the engineers from Schell said “The level isn’t just one peace, there are lots of intricate pieces” so to solve the problem they had to combine different textures into a single one, this could affect some behaviors in those pieces, not to say their graphical quality.
Respecting the controls, Google has 3DOF and Oculus has 6DOF, that means that with both you can move your head to change the rotation of the camera but with Oculus you can also move the position of your character by using their controllers:
You have access to other actions and effects such as being able to see your “hands” in-game and use them to interact with objects in your VR environment, also you can “teleport” (this is change instantaneously the position of your character to avoid motion sickness) at the push of a button; they also make some game actions more intuitive as you use items as you would use them in real life, additionally you could program the buttons behave differently according to the nature of your game. Google Cardboard on the other hand:
Yup, with GC you are limited to only your headset, having no controls is an advantage when you want to make simple experiences but became a problem when you want to make something more elaborate and the first question that comes to mind is “What am I going to do with OQ controllers?” since actions are gaze-based in GC you have to consider the “walking” mechanic when porting to OQ, menu interaction, hand interaction even some mechanics like grabbing items and using items have to be considered when porting.
Finally, we need to talk about the teams in charge of doing the actual porting, the best team you can have, is one that worked on the making of the game; because like gameranx’s video poited out: if you outsource the porting to a 12 persons team for a game that took so many people to complete, you could fill a 17-minute video with just the credits, the results may not be what you expect… So be sure you have not only the right people for the job, but also the right amount of people for the job.
In conclusion, when you want to port your video game (or app) from one system to another, you must first have an outstanding grasp of the characteristics, limitations, inner workings, and differences of both systems (or more if you want to port to N systems); the nature and mechanics of your game and how they will be translated to the new architecture; and finally, the quantity and quality of the teams in charge of porting the games. With these points in mind there shouldn’t be mayor issues when expanding your works to new markets.