On top of that, there were also almost 1,500 ticking components. I looked at how many of these Actors were ticking on each frame, and the number was over 1,000. While iOS devices can handle that without much of a problem, the Switch can’t without substantial changes. One became apparent rather quickly: some levels had over 5,000 Actors – a number that is way over the recommended amount. These quick outcomes made me think that there must be some other low-hanging fruit we didn't pick up yet.
In two days, I managed to shave off 20 m/s from the initial results. I started the optimization by finding any slow Blueprints and ported those to C++. On consoles, when you get a stable performance, you know you can consistently count on it. 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. I started to profile the game and looked for answers. 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. What did we miss? Quite a lot, as it turns out. We were puzzled: the game was already optimized for mobile devices. 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. Targeting 30 fps allowed us to maintain a high resolution, and most importantly, stable battery life. When Apple Arcade was first announced, it wasn't clear which device would be the oldest (it ended up being the iPhone 6s). On iOS, our target during development was 30 fps. Our first Switch iteration was only running at 13 fps.