Welcome to part 3 of our Death Carnival optimization series! In part one, we discussed our goal of achieving great frame rates on as many levels of hardware as possible. We then discussed the benchmark results we were able to achieve during the optimization process. This third part will focus on various interesting elements we worked on for optimizations, including improvements to the CPU/GPU, gameplay optimizations, and other changes that our non-dev fans can get excited about. So why are we chasing these optimizations so aggressively? Because every bit of extra performance we find means fewer restrictions on game design going forward. For example, If we can only spawn inr 20 active monsters at any time, then that greatly restricts the kind of crazy battle scenarios we can have in the game. Through our performance tweaks, we have created ways that will allow us to have hundreds of monsters, and thousands of homing projectiles, active without affecting the games performance. Optimization is all about compromising and cutting corners. There are many varieties of visual features we could incorporate into our game, but every single one comes with a certain cost. When determining which features to add we measure 2 things:the performance impact, and the net gain of the visuals. For example, something seemingly straightforward like Environmental Fog can be implemented in multiple different ways. When choosing between options, we ask ourselves questions like whether we want the 70% quality fog that drops performance by 15%, Or the 80% quality fog that drops performance by 35%? One way of handling it is to have both, allowing players to toggle between them based on whether they prefer higher performance or higher graphics quality. While that is very easy to set up, we also want to maintain the general look of the game, even when using lower quality settings. We also want to avoid players gaining a competitive advantage when using certain settings. I know I certainly wouldnt want to feel penalized in PvP for using prettier graphics if my system could handle them easily. CPU Optimization We are currently very well optimized on the CPU side, with most of the CPU left unused. This is very important, as that means we can fit more multiplayer game servers that share a single server CPU. For example, we use kinematic movement for characters instead of using Unity's natural physics engine. This means that every movement has been deliberately coded like you would see for a 2D platforming game like Super Mario, saving a lot of system resources on physics processing. Monsters AI For PvE monsters AI, weve experimented with many approaches over the years. Our goal is to achieve a very high count of active monsters engaging in combat against players at any given time, and we have combined techniques from different game genres to achieve this. The CPU load for AI must be kept low, otherwise it would greatly affect game performance on lower-end hardware and also put more strain on multiplayer servers. For our elite, and mini-boss tier monsters, we use more complex individual AI to give them more personality. While this makes for more interesting interactions with the player, it comes with a higher processing cost. For swarms of monsters that are crawling all over the walls and landscape, we switch to using a hybrid approach depending on how far away they are from their target. By combining these approaches to AI, we can ensure that the monsters behave effectively while not impacting the performance. GPU Target On the low-end of GPU targets, we have included low-end integrated GPUs. By doing this, we are also optimizing the game for mobile devices. What does it mean when we are optimizing for low end GPUs? It means we need to avoid full-screen effect calculations completely on the lowest end as theres far less texture memory to work with. This means that we cannot have any essential gameplay-impacting elements that rely on full-screen visual effects, otherwise it would degrade the quality and consistency level of low-end graphics settings significantly. Previously, we used full-screen visual effects to create debuffs visuals to indicate when players touched something bad. However, we have removed those for the sake of optimization and replaced them with gameplay based debuffs. Since our playtesters felt that these visuals could be confusing at times, this also solved a gameplay issue while improving performance. Bullet System There are generally a few ways to handle bullets in shooter games. Instant-hit weapons, and projectile based weapons are two such examples. Instant-hit weapons are pretty easy to optimize, but projectile based weapons are a bit more varied in terms of how developers like to implement them. For our PvE monster weapons, we wanted to have the flexibility to create incoming attack scenarios that were utterly insane. That means being able to move a lot of bullet objects on-screen without causing a large performance drop. To solve this, we created a system where processing and rendering thousands of homing missiles will cost next to nothing in terms of performance. With this in mind, our players can fully expect some epic boss battles in the future! Beyond Game Engine Were always looking at new features that come out in every Unity patch as every new feature that comes out is a potential opportunity to either boost performance or enhance the graphics. Sometimes, it is neither, but that is part of the fun of being experimental, as you never know what opportunities may arise. For example, lighting is very important to our game since we have plenty of real-time explosions and neon lights. Game engines in general dont particularly handle a high quantity of light sources well because of all the calculations that are needed, especially on mobile phones or the Nintendo Switch hardware. To work around this limitation, we used a screen space solution which creates virtual 2D lights to emulate 3D lights, combined with additional custom modifications to give us an unlimited number of light sources while retaining the sharp look of real time 3D lights. VRAM Limitations This is a big one. Throughout development, weve used many different techniques to create the 3D art assets that are used in levels. From using single shared texture sheets for dozens of objects, to using 4 or 5 separate textures per object. During the last few rounds of optimization, we started work on greatly reducing VRAM usage, since lower-end GPUs only have 1GB or less of VRAM available for rendering textures. Weve tried the minimum resource shared texture approach, and weve tried the high resource high memory. Our next goal is to combine both approaches to create a very low VRAM usage scenario while using custom implementations that will look amazing. Nvidia and AMD We are also planning to use the upscaling technologies from Nvidia and AMD as soon as they become available. On lower-end hardware, simply changing the resolution can greatly impact the frames per second you get. Currently, when lowering your games resolution, the graphics become somewhat blurrier. However, when combined with technology such as Nvidias DLSS and AMDs FidelityFX, these issues are resolved. Both these technologies are in various stages of being implemented into the Unity engine, and we are keeping a close eye on every update so we can implement them as soon as possible. Even now, we are achieving greater performance results when upscaling from a 20-30% lowered resolution. Particle Systems We use particle systems in almost every visual system, and the performance on these can range from great, to slowing down the game to a crawl. During the optimization process we used profiler tools to measure the impact of particle systems, especially on lower end hardware that can not handle a high number of overlapping textures that well. This helps us to catch any performance issues, and solve them as quickly as we can. One way we've optimized our particle systems is by keeping the overdraws to a minimum. We have achieved this by using 3rd party tools to pre-render an animated effect onto a texture sprite sheet, and then projecting it onto a single square, instead of stacking many particles to render it in real-time, which multiplies the performance cost. Testing and Metrics The most important part of efficiently optimizing a game is using the right tools. Unity comes with a whole suite of analysis tools to see what each element will cost to render and process. Outside of Unity, we use powerful tools such as RenderDoc, a powerful performance profiling tool. We also use a super low-end $230 laptop that we use to discover additional performance problems more effectively than looking at analysis tools on higher-end systems. We also have many testers helping out by testing out the various builds across a wide range of hardware to ensure we didnt miss anything during our internal testing. Conclusion The above mentioned systems are just small samples of the many optimizations we have done for Death Carnival. At its core, the process mainly comes down to understanding and measuring the performance impact of each sub-system, and finding ways to improve them. We will continue to work hard on optimizations to make sure that as many levels of hardware as possible can run our game at over 60fps for that awesome responsive arcade feel. See you in the arena!