Oleksandr Berezovskyi
/// CTO
Oleksandr Berezovsky is the CTO and one of the key figures at Pingle Studio. Since the early days, he has contributed to nearly every major project the studio has touched, from The Eternal Cylinder to the Five Nights at Freddy’s franchise, helping shape Pingle’s technical excellence across platforms and genres.
Porting a game originally developed for PC to Nintendo Switch required substantial changes across multiple areas of the project. The original game had not been designed around the hardware limitations of lower-powered devices, and some of its existing technical solutions created additional performance and memory challenges on Nintendo Switch.
As the team analyzed the project, it became clear that the scope would require more extensive work than initially anticipated. We communicated the technical findings and proposed solutions to the partner, and the collaboration was subsequently extended twice.
The main challenge was not simply getting the game to run on Nintendo Switch. We also needed to establish a realistic visual target and determine which parts of the original experience could be preserved within the platform’s performance and memory constraints.
Establishing the Visual Target: the “Beautiful Corner”
At the beginning of the project, there was no predefined benchmark for the visual quality of the Nintendo Switch version. Before applying optimization changes across the entire game, we needed to determine what level of quality could realistically be achieved.
To do this, we selected a small section of one location and initially reduced its visual quality to a minimum. From there, we gradually increased the quality while measuring performance on Nintendo Switch.
The team compressed textures, optimized models, identified performance-intensive visual elements, and replaced them with alternatives that provided a similar visual result at a lower performance cost.
Internally, we called this test area the “Beautiful Corner.”
Rather than optimizing the entire project without a clearly defined target, this approach gave us a representative section of the game that demonstrated the balance between visual quality and performance we could achieve on Nintendo Switch.
It also provided a practical benchmark that could be reviewed with the partner. Once the target was agreed upon, the team had a consistent reference for optimization work across the rest of the game.
Reworking Hard References and Memory Usage
One of the most significant technical challenges appeared when the game stopped launching entirely.
After almost a week of investigation, the team decided to isolate the problem by gradually removing content from one of the scenes. Assets and systems were removed step by step until eventually nothing remained in the scene.
Despite being completely empty, the scene was still occupying approximately 2.5 GB of memory.
The source of the problem was an extensive network of hard references.
Loading a particular object could indirectly cause multiple unrelated assets to be loaded into memory. Loading a character, for example, could also bring in location data, audio, doors, and other content that was not required at that moment.
This approach can reduce loading times when sufficient memory is available, but it becomes problematic on hardware with considerably tighter memory constraints.
Our engineering team therefore reworked a substantial part of the game’s hard-reference structure, reducing unnecessary dependencies and giving the game greater control over which assets were loaded into memory at any given moment.
This became one of the largest engineering tasks on the project.
Redesigning Level Loading
Reworking the hard references improved memory usage, but it also exposed another challenge related to level loading.
In the original version, the next location could be loaded into memory before the previous one was removed. This allowed the game to transition smoothly between areas but required both sets of content to remain in memory simultaneously for a period of time.
That approach was too expensive for Nintendo Switch.
After changing the loading logic to reduce memory consumption, noticeable performance spikes began appearing during transitions between locations.
To address this, we introduced loading screens throughout the game, including transitions associated with doors, corridors, and other areas where additional content needed to be loaded.
This allowed the team to restructure loading around the available memory budget while maintaining controlled transitions between locations.
Rebuilding the Lighting Setup
Lighting was another major contributor to the game’s memory usage.
Because much of the game takes place in a dark shopping and entertainment complex, many locations effectively required both illuminated and darkened versions of lighting-related data. As a result, a significant amount of lighting information was being stored and loaded.
Removing one of the lighting scenarios was not an option, as both were required by the game.
Our Technical Art team therefore reworked a substantial part of the lighting setup. Lights were rebaked, dynamic light sources were removed where possible and replaced with static alternatives, and existing lighting and shadow issues were addressed throughout the locations.
The original setup also contained several inefficient lighting configurations. Shadows could appear in incorrect locations or with incorrect shapes, which required additional work beyond the initial optimization task.
Reworking the lighting system reduced its memory footprint and gave the team additional resources that could be redistributed to other parts of the game.
Restoring Visual Quality Within the Memory Budget
Texture optimization followed a similar process.
During the early stages of development, we compressed virtually all textures to reduce memory usage and reach a state where the game could reliably launch on Nintendo Switch.
This was not intended to represent the final visual quality.
As optimization work across hard references, lighting, models, audio, and other systems freed additional memory, we gradually restored higher-quality textures where they had the greatest visual impact.
Instead of reducing quality uniformly across the project, the team could allocate the available resources selectively, preserving more detail in visually important areas while keeping less noticeable elements optimized.
This process allowed us to improve the overall visual result while remaining within the platform’s technical limitations.
Optimizing Wwise and the Audio System
Audio became another important area of performance optimization.
Our Sound Designers, Anton Litvinov and Oleksii Pohorilyi, worked on both existing issues in the audio system and optimization of the game’s Wwise implementation.
Their work reduced the resources required by the audio system while preserving the sound of the original game.
The results also demonstrated how important it is to approach console optimization across the entire project rather than focusing exclusively on rendering, code, or visual assets. Audio systems can have a meaningful impact on performance and should be included in the overall optimization strategy.
Optimizing Animated Screens
Another challenge involved the numerous arcade machines and small animated screens located throughout the game environment.
These screens displayed short animated sequences. When texture quality was reduced during the initial optimization stage, the animations were compressed as well, making some of them difficult to recognize.
Increasing their texture quality directly would have required additional resources, so our Technical Art team developed a different solution.
The number of frames used by these animations was reduced while the quality of the remaining images was increased proportionally. Instead of displaying approximately 20 heavily compressed frames, some of these objects could use around five higher-quality frames.
This preserved the readability of the animations and created a stylized visual result without significantly increasing their resource requirements.
Conclusion
Bringing Five Nights at Freddy’s to Nintendo Switch required far more than a straightforward port. The project evolved into a comprehensive technical rework of the original game, spanning memory management, asset architecture, rendering, lighting, audio, UI, and level streaming.
Rather than applying isolated optimizations, the team focused on building a stable performance foundation first and then progressively reallocating available resources toward visual fidelity. This approach made it possible to preserve the core atmosphere and gameplay experience while adapting the title to the strict constraints of the platform.
A key factor in the project’s success was the ability to define clear technical targets early on and continuously validate them through practical benchmarks, such as the “Beautiful Corner” approach. Combined with close cross-disciplinary collaboration, this allowed the team to make informed trade-offs without compromising the identity of the original game.
The result is a Nintendo Switch version that maintains the essence of the original experience while operating reliably within the hardware’s limitations — achieved through systematic optimization and coordinated engineering effort across all disciplines.
