Cornfox & Bros. share how to port a mobile game to Switch

The first iteration

Our first Switch iteration was only running at 13 fps. On iOS, our target during development was 30 fps. When Apple Arcade was first announced, it wasn't clear which device would be the oldest (it ended up being the iPhone 6s). Targeting 30 fps allowed us to maintain a high resolution, and most importantly, stable battery life. 

Solutions

There are 33.3 milliseconds available to render one frame at 30 fps, and our preliminary results were, unfortunately, closer to 80 m/s per frame. We were puzzled: the game was already optimized for mobile devices. What did we miss? Quite a lot, as it turns out. Modern Apple mobile devices have a more powerful CPU than the Switch – that allowed us to overlook many cases where resources were not efficiently utilized. I started to profile the game and looked for answers.

The difference between a game on console and one running on mobile is that on mobile, the performance scales based on background applications, battery life, and device temperature. On consoles, when you get a stable performance, you know you can consistently count on it.

I started the optimization by finding any slow Blueprints and ported those to C++. In two days, I managed to shave off 20 m/s from the initial results. These quick outcomes made me think that there must be some other low-hanging fruit we didn't pick up yet. One became apparent rather quickly: some levels had over 5,000 Actors – a number that is way over the recommended amount. While iOS devices can handle that without much of a problem, the Switch can’t without substantial changes.

I looked at how many of these Actors were ticking on each frame, and the number was over 1,000. On top of that, there were also almost 1,500 ticking components. That was our problem. The first thing we had to do was to reduce the number of ticks per frame. Here’s what we found and how we shaved off milliseconds:
 

• Actors that update without doing much at all. For these, we either disabled ticking completely or significantly reduced the tick interval.
• Some Actors were querying overlaps manually. These could be refactored to use Overlap events instead, and only enable ticking just momentarily after the events.
• Actors that do something purely visual, but are not visible to the player. To address this issue, we used frustum, distance, dynamic and static occlusion culling, and then we only updated visible actors. 
• Actors that do something are technically visible but are too far away to be noticeable. For example, in the White City, we have a total of over 300 characters at any given time, but only ten or so are usually in range of the player – those are the only ones that need to be updated.

Unreal Engine offers some ways to optimize these cases; however, it's the team's responsibility to make smart decisions; some require opt-in or custom code. For this specific port, we added and removed some code but also used built-in optimizations; for example, we used animation tickrate.

All of these efforts contribute to a highly-optimized port of Oceanhorn 2: Knights of the Lost Realm, which is coming to Nintendo Switch in Fall 2020. Thanks for reading!