Challenges in porting to Nintendo Switch - How Pingle Studio ported Five Nights at Freddy's: Security Breach

We at Pingle Studio have deep expertise in porting to various platforms. Five Nights at Freddy’s: Security Breach is the 13th game in the FNAF franchise - a popular indie horror game series - and the 9th in the current series.

Nintendo Switch is a Gen8 console available since 2017. The hardware power at launch was limited compared with other Gen8 consoles, but Nintendo never wanted this competition due to the unique niche it took - portable gaming. Nintendo had no competition there until the Steam Deck release and Switch gathered a loyal audience during the no-competition period, ready to pay for games. Nevertheless, Nintendo Switch is an outdated device in terms of hardware.

Five Nights at Freddy's: Security Breach was made with Unreal Engine 4. The engine made by Epic Games is constantly developing, both in terms of quality and hardware requirements, for a smooth performance.

So, in porting this title, we were looking at a mix of a previous-generation platform, a relatively modern engine, and a game that has no optimization because it was originally developed for PC.

One of the first challenges we solved was that 95% of the game was built via Blueprints visual scripting tool in Unreal Engine. Whether UE4 games should be made with C++ code or Blueprints is a popular question. This game is an excellent example of how even popular games can be made via Blueprints.

This kind of game implementation makes adjusting most mechanics and game elements hard. The abilities of C++ are almost limitless, but the abilities of Blueprints are a better fit for prototyping, not for developing and scaling the game. 

The legacy version works at 120fps on PC, but there are some drops to 60fps. But it is okay because the player could hardly notice it due to the measured tempo of the game. The game also used a lot of memory due to some big-size textures, animations, light maps, etc. All these things required a lot of optimization to run the game on Switch.

With that being said, our job was porting this game to a device whose hardware is weaker than modern smartphones. That was a challenge for the development and tech art team. 

So, let’s take a look at some cases.

We had a released PC version, and we realized that bringing it to the portable device would require a lot of simplifications. We needed to balance downgrading the game so it could launch on Switch and decreasing the visuals.  

To solve this, we developed a so-called Beautiful Corner approach. The game has a relatively big game world - the supermarket. It feels like an open world in the Metroidvania game series. 

Our QA team prepared a report for all the locations. We took a fragment of one of the most loaded locations and downgraded the graphics to the absolute minimum to see how the game performed. Then, we increased the quality bit by bit: extending the textures, calculating the AI of NPCs and enemies,  baking the lights, etc. When the picture was good enough for the Client and us, we determined the approximate acceptable quality level and understood what needed to be done to get to it.

Later, we detected that the game lacks memory during the movement between parts of the world’s locations. It’s predictable due to only 4GB of RAM available on Switch, and only 3.2GB of which can be used. For a better comparison, remember when smartphones used to have 4GB RAM - it was the era of the iPhone 6. This amount of RAM is very short, especially for a game that comes from a PC.

There was a time when we couldn’t open a game at all. To solve this, we launched a scene in a game and removed everything we could step by step. We discovered that the game required 2.5GB RAM even to run in an empty space. We discovered that Hard References caused this situation.

Hard References is the UE’s engine concept of linking objects between each other. Unfortunately, UE is not very good at managing objects loading to the game, so we recommend developers control this process. For example, we have an instance of the game, which somehow relates to the main character via five classes of links, and, as a result, all the links, set as Hard references, are being uploaded to the memory during the game loading.

This is how we managed to eliminate unnecessary links: we determined the Hard references locations via UE Asset Viewer and discovered all the connections between game components. As a result, we decreased the main instance class from 2.5GB to 5MB. We successfully optimized the Hard references in this project.

Once we solved the Hard References issue, we discovered many more challenges. Animations, AI, effects and many other elements were broken due to what we did with Hard References, which was inevitable. We started fixing it. The team played the original game on PC and discovered bugs we created. We also watched the Youtube playthroughs. We discovered a part of the FNAF fan community that plays FNAF to break a game to get funny content. For us, it became a good source of existing legacy bugs.

The light became the next issue for us to fix. The game has a lot of light. It’s a horror game with an open-world structure, bug locations, and a lot of neon. It takes a lot of memory, and Switch couldn’t handle it.

The average lightmap size in the game was 1.5-2GB. Remember: we only have 3.2GB available memory to run the whole game on Switch, including all the assets, sounds, and everything else.

The original development team had its own light management tool. The idea was to use the classic Bottleneck practice - upload and download the data so the player wouldn’t notice. Here’s how it happens in the game: the player gets to a long corridor or a room with a cutscene so that the game doesn’t let the player go further during the loading in the background. It wasn’t noticeable on PC, but it’s different for Switch.

We remade the Light Manager completely. The developer’s original idea was the light system that depends on the player’s progress in the game. The trading center should get darker and darker with every stage, deepening the horror atmosphere. We decided to replace asynchrony with the good old loading screens.

At this stage, we had enough memory to improve the game and increase the quality of some beautiful and necessary elements, so we extended some textures and updated the models.

One of the most interesting cases relates to the game level with many arcade machines and TVs. Every machine used to display a separate cartoon fragment, which also required a lot of power for the device. Our Tech Art team did a huge job with flickering and displaying these cartoons. But every machine was also a separate source of sound, which loaded Switch a lot.

We removed the machines sound, and Tech Art team decreased the cartoon's framerate and increased their quality. We had 5 frames instead of 20 but in good quality. The result looks stylized and attractive.

The work of a sound design team was essential for this project. They effectively tuned all the sounds. As a result, the Switch version of the game sounded the same as the PC version but used much less device resources.

To sum up, the biggest challenge was managing the memory. The project made us make a lot of original and creative decisions. As a result, the game build took 8GB instead of 79 GB. Also, the Switch version of the game turned out to be the most stable of all the other platforms' versions, which the original developers highlighted.