Optimization tends to be tailored to the specific tasks at hand. Programmers on large projects often build or use out-of-the-box tools called profilers that measure performance in specific areas of the code. Based on the profiler reports, the engineers can see where the majority of processing time is being spent and then consider looking into optimizing the heaviest offenders.

If we’re optimizing the visuals specifically, then it’s a question of what saves the most processing time. The best optimization is often not to render anything at all. If the hardware doesn’t have to render and animate a thing, it saves a lot of processing time. We do this by not rendering models that the player can’t see (e.g. stuff off-camera, stuff behind walls, stuff too far off in the distance, etc.), and also by not rendering the parts of the model that the player can’t see (e.g. if you’re looking at the front of a building, you can’t see the back of the building at the same time without a mirror or something behind it).

That’s only one example of optimizations we make. We load cheaper models and/or textures for things that are far away (LODs), we can reduce the frequency of animation updates for characters in the background or on the peripheral edges of the camera that players aren’t focusing on, and so on. There are as many ways to save processing time as there are ways to spend it. If you have the time and interest, I suggest looking at the #game optimization tag on this blog, since I’ve written at length about various means of optimization in past posts.

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

• Short questions: Ask a Game Dev on Twitter
• Long questions: Ask a Game Dev on Tumblr
• Frequent Questions: The FAQ