May 24, 2019
Learn how Drifter Entertainment leveraged elegant optimizations to bring Robo Recall to the Oculus Quest
Despite more modest system specs, Robo Recall: Unplugged plays identically to its Rift counterpart. This means the game still features the same amount of enemies, physics, and spatial audio as the original title. What’s even more impressive is that Drifter Entertainment was able to bring all of this over with just seven people in six months. To shed some light on how the studio was able to accomplish this, we interviewed Technical Director Matt Tonks. In our discussion, the Drifter Entertainment dev outlines challenges the team had to overcome, elaborates on what optimizations netted the biggest performance gains, and shares Quest development tips.
Can you shed some light on how Drifter Entertainment has taken the lead on developing Robo Recall for the Oculus Quest?
Technical Director Matt Tonks: With Quest’s focus being Rift-style gaming, getting Robo Recall on Quest was obviously something Oculus were very keen on seeing happen...Robo Recall is Epic’s game. As you might imagine, I think they were a little shy about letting just anyone work on the port. Luckily, Drifter has strong ties to Epic and decades of collective experience using (and working on) Unreal Engine, which made us the perfect partner to help pave the way and show what is possible on Quest with Unreal Engine.
From a gameplay perspective, how similar is the Quest version of Robo Recall to the Rift version that was shipped by Epic?
Tonks: We are proud to say the gameplay is virtually identical. I think when people first heard the game was coming to Quest, they would assume there would be less enemies, less physics, less mayhem, less everything. I’m here to tell you that is not the case. We bent over backwards to make sure nothing we did would change the feel (or scoring potential) of the original game. The number of enemies is the same, weapons work the same way, and all the awesome physics-based animation features of the original are still there. Originally, we were worried we might have to curtail some of this stuff to make things run at a consistent frame rate. Fortunately, our obsession with keeping gameplay identical paid off, and we didn’t have to make any cuts.
Considering that Robo Recall initially launched on the Oculus Rift, which required a relatively beefy gaming PC, how did the studio manage to get the game working on the Quest’s more modest mobile processor?
Tonks: The short answer is: lots of elbow grease. There is some advantage to knowing ahead of time what the exact capabilities of the device you’re shipping on are. For the most part, we immediately knew what was going to run on Quest and what needed to be trimmed, re-thought, or remade. When you’re making a game for PC, you don’t necessarily have to worry about how the buildings in your level are composed, or how many bits and pieces are on all your characters. So, initially there was a lot of "this thing had 40 components, but we can achieve the same result with three.” I think the effort was equal parts good-old-fashioned optimization of assets, and trimming all the fat off the implementations of all the various gameplay systems. The last piece of the puzzle was tuning the engine to utilize every last scrap of the CPU and GPU that we could.
With lots of toys like slow-motion bullets and throwable weapons, Robo Recall features a lot of physics. Was it a challenge implementing the game’s physics?
Tonks: Once we gave the physics engine its own little corner of the CPU and fixed a handful of minor bugs caused by the move to Android, things mostly “just worked.” Although, there was some effort required to simplify the physical complexity of things in the game to relieve some of the physics burden as well.
Was Drifter Entertainment able to re-use any existing assets or did the studio have to recreate many of them?
Tonks: We reused assets wherever possible, both to cut down on production costs as well as staying true to the original game. Most of the things that move were exported and then heavily optimized with Quest specifications in mind, but we kept a large part of the static assets.
Drifter Entertainment has noted that multiview allowed the studio to squeeze out as much performance out of the Quest’s GPU as possible. Can you elaborate on how it works and how the studio leveraged it?
Tonks: Multiview is a technique designed to offset some of the cost of rendering the game in stereo. To perceive depth, the game is drawn twice, once for each eye. This normally would make rendering each frame cost twice as much time. Multiview is clever way of reusing some of the work involved in rendering one of the eye-views for the other eye-view. By leveraging multiview, we're able to achieve an overall look that more closely matches the original.
Was it challenging to incorporate spatialized audio on top of nailing the graphics given the hardware budget?
Tonks: We were somewhat worried about this initially, but thanks to the awesome work Epic Games Lead Audio Programmer Aaron McLeran and his team at Epic have been doing to optimize the audio system for Fortnite on Android, this ended up being a breeze. The audio system on UE4 has really come a long way.
What has been the biggest performance challenge to optimize around?
Tonks: Probably the two things that we kept spinning on to the very end were drawcalls and shader complexity. If you imagine Bob Ross is painting each frame of the game, and you had to tell him explicitly to draw every happy little tree, you might find that you’re sitting there for a very long time telling him, “Okay, now draw a tree right there, and then there, and then there.” Each of these trees is akin to the commands that get issued to the GPU to draw a particular thing on the screen. The original Robo Recall typically had somewhere around a thousand drawcalls in a particular frame. Quest can only handle about a quarter of that and stay within frame rate. So, we had to spend lots of time going around all the levels in the game and combining meshes, or removing meshes that weren’t visible, or finding other clever ways to reduce how many times we have to make "poor Bob” draw things.
As I mentioned, the other difficult issue was shader complexity. Being optimized for beefy GPUs, the original Robo Recall had a plethora of very expensive shaders throughout the game. We put a lot of time into tracking all these down and replacing them with cheaper materials that approximated the same visual effect without all the complexity.
What optimizations netted the studio the most vital performance gains?
Tonks: If I had to point to one thing that impacted things the most, I’d probably point to the awesome work Drifter Entertainment Art Director and Founder Kenneth Scott did bringing all the character and gun meshes to the platform. Kenneth is no stranger to making awesome visuals that fit in a budget, and that expertise paid off here.
FFR (Fixed Foveated Rendering) helped us get our more expensive scenes over the hump. We ended up going with a dynamic approach that selects how aggressive we want to be with FFR based on the GPU load in the current scene.
Other notable mentions would be leveraging and tweaking the HLOD (Hierarchical Level of Detail) system to unload the GPU for distant objects, setting up precomputed visibility since the Quest does not support hardware occlusion, and liberal use of mesh merging/instancing across the board.
Is it true that the Quest port only took four months? How did a relatively small team accomplish such a challenging task so quickly?
Tonks: Sometimes bigger teams are not always faster. It doesn’t hurt that the folks working on the port are mostly very experienced industry veterans, but ports also just don’t require as much iteration and creative brain power in general.
It took more like six months total. We had the game to a state we considered fully playable in about four months. The remainder of the time was spent ironing out the spikes in performance to get things running at a smooth 72 frames per second to match the refresh rate of the displays on the Quest.
Being one of the first Oculus Quest developers, what have you learned about the headset thus far?
Tonks: Although there has been plenty of skepticism leading up to launch, it’s clear now that the Quest is a genuine gaming device. Excellent tracking combined with hardware that is capable of running compelling VR experiences in a $400 package that requires no cables, installation, or extra hardware is really an amazing thing.
On paper, there have been many mobile GPUs and mobile VR platforms that are capable of running good VR experiences, but in practice, they fall short. Usually due to the device not being designed to run at full-tilt indefinitely. Ultimately, a phone, for instance, would overheat, downclock itself, and that would be the end of your VR fun. I’ve run the Quest at 100 percent for hours on end, and it never overheats, nor does the experience degrade.
Do you have any tips for developers who would like to either port or build games for the Oculus Quest?
Tonks:
- Quest has no cords, no directional limitations, and excellent tracking. Leverage this!
- Do yourself a favor and start thinking in terms of 250 drawcalls early. Start thinking of how you can convey the look you want and stay within those bounds.
- While support wasn't quite ready to ship for Robo Recall, keep an eye on Vulkan. It’s coming down the pike, and it’s definitely worth adopting as it will let you fit more in your scene.
- Don’t reinvent the wheel. UE4 gives you all the tools you need. It’s worth spending the time to figure out how to use them.
Thanks for your time. Where can people learn more about Drifter Entertainment and the game?
Tonks: Sure thing! A great place to find out what we’re up to is at www.driftervr.com.
For more info about Robo Recall: Unplugged, check out www.driftervr.com/roborecall. Also check out our previous VR game Gunheart!