Never Again Windows game

Before I could only dream of releasing a game for the console. Even Steam seemed like a distant goal - I used to work in the recording industry, but the news that the powerful Unreal Engine 4 became freeware and anyone could start to make games made me shake off the dust from an incomplete movie director's education and to begin work on a cinematic horror about a girl, suffering from asthma. After 4 years of work, my game Never Again was released on Steam. It was May 2019, and on January 30, 2020, it will be released on the Nintendo Switch. I never planned release for the console, so porting brought me a lot of difficulties.

One can barely call me a programmer; I was able to bring the game to release on PC using only visual scripting - Blueprints, which is not very smart idea for optimization.

I was fascinated by the idea that I made the game on the engine, which is used by huge game studios publishing AAA games. Of course I did not feel guilty for trying to use all the features of UE4 to the maximum, usually with no understanding on how this would affect performance. The only thing that prevented me from unlimited using of engine’s feature is my low-powered GT740. Without this boundary I would bring up such heavy effects to my game that it would be silly to talk about any Nintendo Switch port.

The goal was to achieve a stable 30 fps on the hybrid. To assess how difficult this task will become, I launched Never Again on devkit without any interference with the structure of the game. I let it work, as if it was a PC.

One can barely call me a programmer; I was able to bring the game to release on PC using only visual scripting - Blueprints, which is not very smart idea for optimization.

I was fascinated by the idea that I made the game on the engine, which is used by huge game studios publishing AAA games. Of course I did not feel guilty for trying to use all the features of UE4 to the maximum, usually with no understanding on how this would affect performance. The only thing that prevented me from unlimited using of engine’s feature is my low-powered GT740. Without this boundary I would bring up such heavy effects to my game that it would be silly to talk about any Nintendo Switch port.

The goal was to achieve a stable 30 fps on the hybrid. To assess how difficult this task will become, I launched Never Again on devkit without any interference with the structure of the game. I let it work, as if it was a PC.

If you don't take into account two infinities: assembling the engine and compiling shaders for the entire project, it was possible to launch the game on the console the first time. Launched application gave me with amazing ... 0 fps. It felt like the picture changed once in an hour, but in fact on the CPU it was 6000ms. Optimization appeared before me in the form of a cunning rebus, and its solution turned out to be another task. However, after two weeks of porting 24/7, the first stage stopped to look like something devastating and insoluble.

If you face the same problem, here is the first tip:

Important tip number 1. Completely disable the physics simulation of clothing Apex Cloth.

To understand this and to profile the game on Switch, I had to wind up such crutches, that the NDA does not allow me to talk about. All in all, I finally went a little deeper into profiling in Unreal Engine 4.

Hurrah! Never Again fully runs on Switch, and you can beat the game, but still with great difficulty - fps was between 10 and 15. I had not so many ideas what to do with this ...

I turned off heavy post-processes (Depth of field, Motion Blur (I don’t even understand who really likes this effect)), Ambient Occlusion, etc. I fought very hard for the latter and did not want to turn off, because the picture has changed dramatically for the worse, but for the sake of optimization I had to be patient.

Then it was time to say goodbye to the smooth. I turned it of, but I decided to compensate for his absence by lowering the Resolution Scale in manual mode to 66.66%, and in console mode to 80%. Next step was the adjustment of the screen resolution for console mode. I set it to 1920x1080 (less is not cool), and for portable mode I limited it to 1280x720. I had an incident with resolution that completely reversed my idea of porting, but I’ll tell more about that in the end.

These settings helped to raise fps to 18-24, which, in a sense, is even acceptable for playing, but still not cool. The perfectionist inside me pounded the table with a fist and demanded stability.

It's time to kill the graphics.

The first thing that came to my mind was turning off the grass. The initial location in Never Again is a lighted children's room, where player can see a street through the window. And there are already a bunch of light sources generating a huge amount of shadows. I could not bake them due to circumstances about which you can write a whole separate article. Lighting should remain stationary (semi-dynamic). There are no any other places where player sees the grass so I get rid of it.

Oh, the grass was beautiful...

It looks worse, of course, but I had to sacrifice something for portability

In the screenshots you can see that the last picture is kind of grainy. No, this is not a low resolution screenshot, this is Dithering. Important tip number 2. Forget about Translucent mode. I made transparent materials using the Masked + Dither mode.

Why is this important? It’s very difficult for graphic card to render transparent materials – I needed to make it as easy as possible. There were two options: either remove transparency altogether, or fake it with dithering. The result is not perfect, but quite acceptable:

This, of course, greatly unloads the GPU, but can't say this change caused a rapid jump of fps. However, this is another small pebble in the optimization foundation.

Next, I started profiling the GPU and saw that the lion's share of ms is lighting. And specifically, shadows. This, of course, is obvious, and even more obvious that I needed to do something about it. I decided to take a look on the shadows in the other 3D games on Switch. Outlast graphics seemed to me the most attractive then. I wondered how they dealt with shadows.

Dynamic shadows had very low resolution. This observation removed the burden of responsibility from me and allowed me to do the same thing. At the same stage, it turned out that somewhere in the game capsule shadows were included but weren’t used. Nevertheless, they were still miscalculated by the video card. It took a very little time to find all the skeletal meshes where the capsular shadows were connected, and as a result I raised a few milliseconds on the GPU.

I haven’t set up Cull Distance anywhere since I knew that the engine copes with it well itself: everything that was outside the frame was not rendered. My game is corridor-type, all the action takes place in confined spaces, and I had no need to adjust the rendering range, but when every millisecond is important, I had to adjust the rendering distance to all objects, which took several days. It’s hard to say that the performance gain was enormous, but at this point, fps raised from it's knees confidently approaching the value of 25. It's time to deal with the CPU.

The first thing that came to hand was physical objects. There is a lot of physics in Never Again, which is not good news for Nintendo Switch, because any calculation of physics is a serious task for the processor. In general, physical objects were sufficiently optimized for PCs: when they were lying around idle, they fell into sleep and thereby stopped loading the processor. Such objects include pieces from dolls in a cave, with which I covered the whole floor. The number of such objects had to be reduced in order to reduce the number of their collisions with each other.

I had to get rid of physical objects hanging from the ceiling altogether, because they never fell asleep even on the PC version - they were always in motion. Fortunately, there were few locations in the game with this feature. And here goes the third tip:

Important tip number 3. Use physics in games wisely, or better, don't use it at all.

So we got to the logic. I started developing a game with very low programming skills. I explored the possibilities of Blueprints on the run, and this “style” showed up during the porting. Over the 4 years of development, a lot of fundamental mistakes have accumulated, the correction of which, especially in quests and cutscenes, could make the game impossible to beat. For a couple of years, Never Again was in Early Access on Steam, and all this time I persistently built a shaky tower of crutches, but on Steam, when a user detected a bug, I could instantly release a new build and fix everything, meanwhile with Switch this would not work: each update is carefully checked, and this takes a lot of time to distribute it to players. Therefore, rewriting the code was dangerous. It’s easier to cut off functionality that did not affect the gameplay.

The first thing I needed to pay attention to is how many processes I had on EventTick, whether there is a pile of logic that runs continuously every frame. In general, I used to watch this during the development, but still I missed one place in the game…

Each frame three LineTrace shout out to determine the coordinate under each leg and body of the character to gracefully bend the legs depending on the relief of the surface on which the main character stands (Inverse Kinematics). Here goes an important tip:

Important tip number 4. Use LineTrace with a lot of logic as little as possible.

As soon as I removed IK, 7 ms from the CPU were immediately released, and the game occasionally produced the coveted 30 fps. At this point I was stuck, because there was nothing more to unscrew ... Only one thing left - Forward Shading.

What does it mean? Do you remember, at the beginning of the article I said that I was fighting for the Ambient Occlusion process, which is close to my heart? The fact is that Forward Rendering was invented for VR games. It disables some heavy visual effects and thereby significantly reduces the load on both the GPU and the CPU. Ambient Occlusion, of course, was also disabled. It immediately struck me that with the Ambient Occlusion decals ceased to be displayed. I replaced the decals with texture plains, and it was easy. For Ambient Occlusion, I grieved until the first time I showcased my game on the Nintendo Switch. Players didn’t notice anything strange in the visuals and generally described the port as “beautiful”.

Do you remember that I mentioned a case with a screen resolution? For a long time I could not understand why after switching to Forward Rendering fps raised up in the project, but on console everything fps was still between 25 to 30. The problem turned out to be Device Profiles: I incorrectly indicated the change of permissions for manual mode and console. After the correction, I felt great relief, the statistics showed epic 55 fps in the menu, instead of the stable 30, for which I fought for two weeks.

Here I might have finished, but there are a couple of points to which you need to pay attention. Important tip number 5. Reduce the size of the textures. Large textures are a common mistake that I managed to avoid due to the peculiarities of the game style and a weak computer, but, nevertheless, this mistake can affect many others. I set a limit to myself that the size of textures should not exceed 1024x1024, and most often I used 512x512. Remember: the memory size of the Nintendo Switch is not unlimited. Important tip number 6. Use Blueprint Interfaces.

It is important that your classes are independent of each other. In the case of Blueprints, this is even more important, because all related blueprint classes immediately fall into memory. That’s all for now. I could also tell about the passage of all checks of the build by Nintendo, but this is a completely different story, and it's hidden under the NDA. All Switch owners will be able to see the fruit of my pain, sweat and tears at Nintendo eShop on January 30, 2020.