Optimization
Diagnosing a level's performance problems and tuning it to run more smoothly
Is the game running very slowly when you try to play your level? Are your players or playtesters complaining about lag, low framerate, or long load times? If so, then maybe it's time to optimize your level to try to make it run more efficiently.

When to optimize

Not too early, and not too late. Haha.
Optimizing too early is called "premature optimization" and it is a waste of time because your project will change drastically, which means you'll have to cut features or change the design. Why optimize something that the player will never even see? Surely you should only optimize something when you're reasonably sure that it will be included in the final version.
But how will you know if something will be in the final version? Probably only when it works well... and sometimes you can make that judgment call only after you try to optimize it. If you wait too late before optimizing, then you'll build up too much "technical debt" and spend valuable time late in the project trying to put out all the fires everywhere. You'll miss your deadline or release window, or in the worst case, doom the entire project.

Planning for optimization

Ideally, optimization is something baked in your project planning and design from the beginning. Before you get too deep into production, you should be able to answer these questions about your game project and/or level:
  • What is the target platform? The average mobile phone in 2020 is like a mid-spec laptop from 2010.
  • How big is the level? A large open world city or RPG continent will need to be built in smaller chunks that are carefully loaded / unloaded during the game; you need to figure out how big each chunk should be, which chunks can connect to others, and blockout the game with this constraint in mind.
  • How dense is the level? A realistic outdoor world might require a lot of expensive overlapping foliage, while a stylized handpainted world might be more sparse and simplified.
  • How open is the level? A narrow indoor level with frequent gates can support dense details cordoned into segments, while a big open outdoor landscape is difficult to divide into segments.
  • What is the camera system? A first person camera can see long sightlines, so dense levels will likely need some kind of occlusion culling. A third person cinematic camera with fixed camera angles means you have strong control with frustum culling, and if a particular camera angle is laggy, then you can simply reposition the camera or turn the camera away.

Performance budget

Video games run on computers with limited resources. Poor framerate or instability arises when your game or level is overusing its budget for one or more of these resource types:
  • All the game files are downloaded into memory on a hard drive or solid state drive. When you boot up the game, it moves needed files into a faster type of short term memory called RAM. If there's lots of files to load into RAM, then load times will be very long; if there's not enough RAM at all, then the game engine will have to pretend some of the non-RAM space is "virtual RAM", which will be even slower to load. In general, if your level uses lots of different detailed models, textures, sounds, or animations, then it might be overrunning its memory budget.
  • The CPU is the main part of your computer that runs the file system, controls, game logic, AI, and audio. If you have too many NPCs who are navigating a big complicated city, then maybe the CPU has to work too hard to simulate all their AI. Or imagine you had thousands of insects in the virtual city, and you were constantly creating / deleting insects every second. If your level features many different simulated objects, then it might be CPU-bound.
  • The GPU (Graphics Processing Unit) is responsible for rendering an image on the screen. It must gather all the visible 2D sprites and 3D models and process them with a special GPU program called a shader. When there's too many objects to draw or when the shader is very complicated, then the GPU takes longer to render the camera view. If your level features visually dense objects, or even thousands of simple objects, then it might be GPU-bound.
When working on a team, much of these performance considerations are beyond the level designer's responsibility. If pathfinding two NPCs brings the game down to 5 FPS, then that optimization is the engine / AI programmer's job and the level designer should say something to them. However, if the level designer is attempting to create a massive battle with dozens of NPCs, and the game was never supposed to support that type of encounter, then obviously the level designer might be more at fault.
Let's assume the level designer is at fault and must optimize their level.

Profiling

A game can run slowly for any number of reasons: memory, CPU, GPU, etc. To figure out what part of a game is responsible for the slowdown, we must measure what the game engine is doing -- this is called profiling.
Never try to optimize on faith or a hunch, because you could be wrong about what's making the game run slowly. Profiling should be the first step of any optimization pass! Fortunately, modern game engines feature a robust suite of easy-to-use profiling tools.

How to profile

GPU profiling

Unless there's a lot complicated gameplay systems or scripting happening, most game levels are usually GPU-bound: there's too much work for the graphics card to perform. When profiling GPU performance, the main stat to watch is the draw call.
Device class
Approximate draw call budget
Old mobile phones, Mobile VR (Oculus Quest)
50-100
Modern mobile phones
100-400
Low spec desktop, VR desktop
500-1000
PS4 / XB1 / Switch
1500
Mid spec desktop
2000
PS5 / Xbox Series X
4000
High spec gamer desktop
5000
You should really optimize your game
10000+
lights, turn off shadows... why shadows are so expensive / extra draw calls
Batching shared materials: texture atlas is a large composite texture made of many smaller textures, usually arranged in a square grid. Much like a 2D spritesheet made of many parts, "packing" many textures into a single larger texture is a useful optimization to reduce draw calls and efficiently use memory. The drawback is that the resulting assets are less flexible to use (UVs correspond to a small area, textures cannot be tiled easily) or might even degrade performance if this manual optimization
distance culling, frustum culling, LODs... but if you have lots of objects, overhead of LOD isn't worth it (Naughty Dog)
occlusion culling
vis portals, manual culling
shader optimization:
  • opaque shaders are almost always better than alpha transparency... modeling out a complex shape is better than alpha mask transparency, the extra polycount is negligible for the draw call or batching anyway
  • what is alpha test + on most hardware, alpha test is much faster than alpha blend... smooth jagged edges with alpha to coverage
  • on some mobile devices, alpha blend is faster than alpha test
  • for foliage, fit geo to the opaque alpha + merge multiple meshes + minimize overlap + use opaque core + avoid using generic object data structure (don't hand place each grass clump)
spawn less AI
Horizon Zero Dawn Uses All Sorts Of Clever Tricks To Look So Good
Kotaku
Why are video games graphics (still) a challenge? Productionizing rendering algorithms
Bart Wronski
Last modified 10mo ago