Porting Graveyard Keeper to consoles and mobiles

In this article, I want to talk about our experience of porting our game “Graveyard Keeper” to mobiles and consoles.

Some basic information: Graveyard Keeper was developed by our team (Lazy Bear Games) in Unity and then ported to XBox One / PS4 / Nintendo Switch by our publisher, tinyBuild. The mobile ports (iOS and Android) were made in-house, by us. Also, a few months after the initial game release, we made a DLC “Breaking Dead” which was also ported to all platforms. In addition to this, the game was constantly being patched and improved.

As you can see, the setup containing two dev teams is not an easy one. Mix it up with the project in the phase of dynamic development that needs to be deeply optimized for some platforms and you’ll get a pretty challenging process.

Time to get technical.

Looking at our game you can probably think that it is a simple game to port, as it is 2D with pixel art. And if consoles are powerful enough to process 4K/60fps, the pixel 2D graphics wouldn’t be a problem. Theoretically, that’s true. But practically we used a lot of very complex solutions that were not optimized for consoles and totally unoptimized for mobiles.

Think of HDD speed.

You probably heard that the current gen consoles architecture is very similar to the PC. That’s true, but technically the hardware differs from the PC. First of all, Xbox One and PS4 use hard disk drives while most of modern PCs use SSD or hybrid drives. So, you have to keep in mind the loading times.

Imagine our surprise, when the first build was loading for during almost 5 minutes.

So, we had to rethink the whole loading and asset storage systems. For example, we began storing not the whole game objects on the scene, but only the information about them in simple (fake) objects. And after the loading is complete we started replacing these fake objects with the real ones on the fly.

Think of multi-core.

Also, in our experience writing for the consoles requires using all CPU cores at maximum making the code to work in parallel. By default, Unity games are very dependent on a single core performance. And running the game “as is” could give you very sensitive performance bottleneck when all other cores are idle while the only single core is under load.

We had to move different math and calculations to a different thread running in a parallel to free as much core-#1 power as we can. Basically, that’s a good point to keep in mind if you’re not planning to port to consoles also as it will give you a better performance anyway.

So, next time we will plan everything we can to run in a separate thread/job. Luckily, Unity had improved multi-threading a lot during the last year implementing job system and ECS.

Think of graphics optimization (even for 2D games!).

Another heavy issue for us was the graphics. We had no previous experience optimizing anything for consoles or mobiles. Therefore we were OK to make a tree combined of 20 separate sprites just to make it easier to design. There was no need for such amount of sprites for a single tree in the game itself.

Of course, we needed to merge sprites to reduce the amount of layers. You can see the amount of initial geometry on the scene here:

The rightmost picture shows the “overdraw amount”. That means each time one sprite is drawn over another, the color on that picture becomes brighter. So, you can see that despite the simplicity of the look, there are really a lot of polygons drawn over each other.

Also, all sprites of the game are lit by a complex shader that not only uses the normal-maps, but calculates the pseudo 3D-depth of the picture.

We had to make different versions of visual optimization for different platforms. For example, we had to completely change the lighting shader and its behavior for mobiles.

Think of platform-specific issues.

Also, there is a lot of platform-specific work (especially for consoles). For example, you not only need to support the gamepad, but need to deal with different uncommon situations like when a user plays the game, the gamepad turns off, user connects another controller and logs in to a different profile. And that’s in the middle of the game. There are different large lists of such cases that your game needs to deal with.

Another issue you have to think about is the saving system. Your game had to work with asynchronous saving routines and treat any file corruption could happen.

Patches and DLCs.

As mentioned above, we worked with an external porting team on the side of our publisher and pushing all new content, fixes and patches became a difficult task. You need to plan everything ahead. You can’t just tell the guys to push your last fix to Xbox if they are making a Switch port and everybody is busy with that. 

And keeping in mind that we’re a small team that likes to develop games with a high passion, that doesn’t go well with planning ahead. That’s the reason we couldn’t easily port the first “Breaking Dead” DLC to the Xbox. We didn’t plan it very well. One day we just woke up and decided to make zombies and put them in the first DLC. But guys at tinyBuild were busy deeply optimizing and porting the game to Nintendo Switch. They couldn’t drop that process and begin to port this DLC right away. They needed to finish their port first.

That was the downside of the idea of making a simultaneous release on PC and Xbox. Ideally we should release a PC build, fix all bugs were found and only then start porting it to consoles -- or spend months in isolated QA beforehand, without real player feedback. And only after the port is done, start making a DLC. But we couldn’t afford spending so much time on that. We had to do everything right away.

That’s the reason we couldn’t release the first Breaking Dead DLC for free on other platforms (as it was on the PC). When you develop on multiple platforms, the costs and timelines ramp up pretty quickly. Even porting and releasing a patch eats up a lot of resources.

Releasing titles, DLCs and updates always require passing platform compliance requirements, which means certification by platform holders. The more complicated your game mechanics and the bigger the amount of the APIs you are using the more requirements you will need to surpass. This means that you need to test your content against these requirements before submitting it for certification to make sure that the chances of passing it are good. Otherwise you may encounter a big list of issues to fix and might not pass it (probably you just won’t) within first submission. Additional submissions might also lead to additional costs. But the most risky thing about not passing the certification in time is delaying the announced release dates. 

This is extremely difficult with fast iteration cycles we had on PC. It would be impossible to real-time merge new content into the console builds, as shown in the diagram in the beginning of the article. Having in-house resources will require at least one programmer dedicated to each platform and a proficient QA team that is constantly testing the title being ported and report the issues that fail the requirements so the porting developers can fix them before being found by the certification team on the platform holder side. It requires building the whole porting structure within the studio. And this is not only the resources, but the specific knowledge and skill set involved in it.

Long story short it’s very easy to release DLC on PC and keep on iterating on it in real time, while launching the same content on consoles adds a lot of overhead costs and complexity to the whole process. 

Sviatoslav Cherkasov
lead programmer
at Lazy Bear Games