Project Lead at Allods Team Dmitry Lisichkin told us about porting a technically complicated MMO to Nintendo Switch and discussed limitations that their team faced.
Introduction
My name’s Dmitry Lisichkin, Project Lead at Allods Team – one of MY.GAMES studios. I’ve been working in the Skyforge development team for 9 years.
After the release of the game on PS4 and Xbox One, we saw that the game is in high demand on consoles and we decided to experiment with releasing it on a portable console. This was a very ambitious goal because Skyforge is a big and technically complicated MMO game and there were serious concerns that it would simply not be possible to port the game to this platform. Therefore, we have divided this task into several subtasks:
- The first is to create a more or less working version as quickly as possible, which will run on the console, in order to reduce the risks if we fail to achieve an acceptable level of performance.
- The next step is to get a fully working version. To do this, it was necessary to port the image renderer and the interface.
- Then start optimizing memory and performance: we wanted to achieve a stable 25-30 frames per second at 720p resolution.
- At the last stage, we wanted to integrate the platform's features: support the touch screen, store integration, friends list, and debug handling.
Optimization
We used NvnGraphicsDebugger, LowLevelGraphicsDebugger to debug and optimize graphics. HeapInspector – for memory optimization, it works well enough, but it is quite slow.
We use our own engine for Skyforge development. The biggest challenge when porting a game was resource constraints: CPU, RAM, and video memory, so we went through a long and very challenging process of optimizing the game for the platform which has some challenging limitations for such big projects like Skyforge. While porting on Switch is challenging, especially for such massive projects as MMO, it is not impossible. By identifying the areas where you expect to have challenges, especially in terms of resourcing, you can save yourself from unhappy surprises later on. But you must ensure you lean into the platform’s strengths as well. A strong portable mode, for example, will help your game stand out among other ports.
In the very first build, we did not have the render implemented yet, but the input, sound, and game logic were processed. This version ran fine at 25-30 FPS. This stage was necessary in order to assess our risks: there is no point in investing many months in porting rendering if the CPU performance of the undocked version won’t get us above 10 FPS. Obviously, playing and testing without rendering is quite complicated, so we used a client logged from a PC to the same server to see ‘through its eyes’ what the player was doing on the Switch test version to make sure everything was working correctly.
Luckily, we already had a set of simplified VFX that are used on weak PCs, so we didn't need to create an additional set. However, it was quite difficult to achieve a stable 25 FPS. However, getting the game to run smoothly wasn't easy. The most difficult thing was to optimize what had already been optimized several times before, because such work was carried out first before the game was released on PC, and then before launching on PS4 and Xbox One. At some point, the ideas start to run out.
Tweaking Visual Parameters
Unfortunately, to achieve the desired results, we had to reduce the size of textures, detail, and remove some effects that made the image more attractive and deep but required a lot of resources (3D clouds, GOD Rays, Distance of Field).
For example, we simplified the level of details for the sky, and, unfortunately, the picture after that became noticeably simpler. To fix this, I had to tweak the engine a bit, and then manually adjust the fog and lighting for some maps. A nice bonus of all this work was to improve the picture on the PC version of the game with low graphics settings.
Limitations and Spent Time
The main limitations are CPU performance and memory capacity. The Nintendo Switch has only three CPU cores. In the early stages of development, one of them was completely occupied with audio processing. Of course, this is irrational use of resources, so we changed the audio compression algorithm itself. The problem with the processor was solved, but a new one appeared – now the sound could take up to 9 GB of memory. As a result, we use a hybrid scheme. The old codec with good compression and high CPU load works where there is not a large number of characters, monsters, and battles in the frame, such as in-game dialogues. The new one is enabled when the game needs CPU cores more than free memory. This allowed us to maintain a balance between the load on the system and the occupied space.
There were also difficulties with RAM. The console has a little more than 3 GB available, including video memory – for modern games, this is a very small capacity. Even on 32-bit systems, you can afford more at the expense of separate video memory. We have done a lot of work to optimize the memory consumption to reduce the risk of game crashes when loading even large maps. Now the memory should be enough to spare.
Regarding the game's interface, we were lucky because it adapts well to different resolutions, we only slightly improved it by enlarging the main elements and supported the use of the touchscreen.
We released the game about 11 months after the start of work, but the most active development was for 9 months. Most of the time we spent optimizing the game and stabilizing the version.