- Setting up the flat mode
- DeviceProfileSelector issues
- FSR 2.0 upscaling integration
- Developing the VR haptic feedback functionality
- Invisible hands
- Localization optimizing and adding Ukrainian
- VR features setup
- Broken splash screen
- Centering on the left eye
- Fixing the textures group issue
- The conclusion
Bringing your game to VR platforms is one way to make a horror game even scarier. Resident Evil VII, Phasmophobia, and The Forest VR are just a few successful examples of the endless potential of horror games on VR. Our partners from Steel Wool Studios realized it very well, so bringing some of their games from the Five Nights at Freddy’s franchise was just a matter of time.
We at Pingle Studios have already worked with Steel Wool on porting and optimizing Five Nights at Freddy’s: Security Breach on PS4, Xbox One, and also Nintendo Switch, so we happily answered the call to port FNAF: Security Breach to PSVR 2.
In this article, we’ll uncover some of the development challenges we overcame while porting Five Nights at Freddy’s: Help Wanted to PS VR 2.
So, once we got all the required access and builds, the first challenge was to enable our team to work on this game remotely. The build we got already had some VR functionality but could only be launched in the VR mode. So, we decided to set up a stable flat version of the game built to be able to work remotely.
The build we had already contained the majority of the flat mode functionality. The main goal was to add the mode selection functionality during the launching process. So, we researched the required Epic Games and Sony documentation and developed a platform-dependent functionality that specifies the presence or absence of the activated VR helmet and selects the flat or VR mode, depending on it.
That’s how we granted our team the ability to work with the builds remotely with less VR hardware required.
Our technical art team created a collection of settings for the flat and VR modes. The dev team had to implement the launch of the specific profiles, depending on the launch mode.
We found the correct Unreal Engine class for this issue – DeviceProfileSelector. However, we faced an issue with the engine modules’ initiation order: the module responsible for the presence of the activated helmet was initiated much later than the profile selection module.
We modified the engine to achieve the event-based profile selection logic activation (after the initiation of all the required modules). This helped us to set the correct selection and initiation of all the modules in the runtime. Later in the development process, we realized that this modification could help us create an easy functionality for switching between the VR and flat modes during the game’s runtime. By doing so, we made the TRC certification process much easier and created a unique PS VR feature.
To optimize and accelerate the high-quality render picture setup, we needed to integrate the FSR 2.0 upscale module. This module is not adapted for working with PS5 out of the box, and there was little to no information about integrating it on this platform online. So, we allocated a team of render devs to help our UE engineers develop a custom system for integrating this upscaler and making it work on the project.
The PS VR2 was a very fresh device on the market during our porting work. It only had a few titles released and pretty basic documentation. So, setting up the haptic feedback – something we had done dozens of times before – appeared to be a new challenge.
What makes Haptic Feedback on PS VR2 special is the fact that there’s a vibrational hardware engine. The players can feel vibrational actions like pulsating, objects passing by, vibrational signals, etc. FNAF: Help Wanted is a perfect game to have this kind of effect, so we started working on it.
We developed a light and easy-to-use interface to access the haptic methods from the Blueprints and applied it to create haptic vibration effects for the game. The result was mind-blowing – our QA team will never forget the teeth effect of the animatronic bear biting a player’s head!
The VR controllers suddenly become invisible at the start menu on some test and shipping builds. We marked this bug as a high priority and started looking for a solution. We detected that this bug appeared on one of the first test builds.
Firstly, we developed a workaround fix that helped the QA team to keep working on other parts of the game. Secondly, we created another workaround for the start level. After two weeks of research, we found what caused the hands to go invisible – multiple component instances in the VR controller tracking logic – both in code and Blueprints. The system only counted the controllers initiated in the code in the test builds.
We built the correct components architecture, both in code and Blueprints, to track only one pair of controllers, and we finally saw the nads again!
The localization logic was partly ready the moment we started porting. We discussed the ability to add the Ukrainian language to the game, so we performed the refactoring of the existing translations and optimized them to be able to add cultures in the future.
We developed a custom commandlet for the translation refactoring and linking types to remove duplicates. We also optimized the phrases that didn’t require localization, which helped us decrease the number of localization phrases from ~1500 to ~900 without harming the contents.
When we started adding the Ukrainian language, we realized Unreal Engine 4.27 doesn’t have a default functionality to detect the title with Ukrainian localization. We detected the diffs in the platform code in the engine and integrated them into the title, so the game correctly detects the Ukrainian language and loads the correct localization.
We managed to fix some VR-specific issues during this project.
VR gamers saw the Splash Screen with logos during the game’s launch. The problem was – the splash screen only worked for the left eye in the helmet. Also, the image couldn’t be replicated on the second screen.
In order to fix this, we re-designed the existing splash screen and its components. Despite pretty solid changes, the result was satisfying – the splash screen looks correct both in the helmet and on the screen, which is important for TRC passing.
We detected a noticeable displacement to the left on the replicating screen. It’s a critical TRC case, so we started investigating the solution.
After the research with the help of the render dev team, we detected the part of the code that caused the displacement. It was Sony’s plugin with three preset options – left, center, and right – and the left was set by default. A single line of code in the DeviceProfile fixed this issue.
The Tech Art team reported a weird behavior in the title – some values changed in the texture groups but were never applied in the title – it always used the default values. The dev team started the research and found what caused the value change during one action of the step-by-step debugging process. We detected the texture groups in the config file, which migrated from the client’s other project. We couldn’t just remove it – it crashed all the Tech Art parts of the project and configured many basic settings.
Eventually, we came up with a solution – we expanded the available texture groups for the current project, which helped the engine to parse and apply the Tech Art settings.
The experience of developing horror games is always special, but working with VR technologies takes it to the next level. We believe in the perspective of VR games, so we are always happy to accept any VR development and porting challenges. Our experience with game engines (Unreal Engine, Unity), various gaming platforms (PC, PlayStation, Xbox, Switch, mobiles), and various VR hardware – be it the well-known HTC Vive, Oculus Quest, and PS VR or fresh Meta Quest and PS VR 2 – makes us sure that we can solve any surprise VR games has for us.
Drop us a line at our contact page, and let’s discuss the VR perspective for your games!
P.S: you can also check out the Case Study on this project.