![]() ![]() For example, we had to completely change the lighting shader and its behavior for mobiles. We had to make different versions of visual optimization for different platforms. So, you can see that despite the simplicity of the look, there are really a lot of polygons drawn over each other.Īlso, 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. That means each time one sprite is drawn over another, the color on that picture becomes brighter. The rightmost picture shows the “overdraw amount”. You can see the amount of initial geometry on the scene here: ![]() Of course, we needed to merge sprites to reduce the amount of layers. There was no need for such amount of sprites for a single tree in the game itself. Therefore we were OK to make a tree combined of 20 separate sprites just to make it easier to design. We had no previous experience optimizing anything for consoles or mobiles. Think of graphics optimization (even for 2D games!).Īnother heavy issue for us was the graphics. Luckily, Unity had improved multi-threading a lot during the last year implementing job system and ECS. So, next time we will plan everything we can to run in a separate thread/job. 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. 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. 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. By default, Unity games are very dependent on a single core performance. And after the loading is complete we started replacing these fake objects with the real ones on the fly.Īlso, in our experience writing for the consoles requires using all CPU cores at maximum making the code to work in parallel. For example, we began storing not the whole game objects on the scene, but only the information about them in simple (fake) objects. So, we had to rethink the whole loading and asset storage systems. Imagine our surprise, when the first build was loading for during almost 5 minutes. So, you have to keep in mind the loading times. First of all, Xbox One and PS4 use hard disk drives while most of modern PCs use SSD or hybrid drives. That’s true, but technically the hardware differs from the PC. You probably heard that the current gen consoles architecture is very similar to the PC. But practically we used a lot of very complex solutions that were not optimized for consoles and totally unoptimized for mobiles. And if consoles are powerful enough to process 4K/60fps, the pixel 2D graphics wouldn’t be a problem. Looking at our game you can probably think that it is a simple game to port, as it is 2D with pixel art. 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. In addition to this, the game was constantly being patched and improved.Īs you can see, the setup containing two dev teams is not an easy one. ![]() Also, a few months after the initial game release, we made a DLC “Breaking Dead” which was also ported to all platforms. The mobile ports (iOS and Android) were made in-house, by us. 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. ![]()
0 Comments
Leave a Reply. |