Cleaning Up Clustertruck

tinyBuild did the console port for Landfall Games’ ClusterTruck; a game game that depends on one or two hundred RigidBodys, MeshColliders and RayCasts behaving correctly at 60fps in HD. The game is out on Steam and runs great, so why spend time optimizing? Because if you don’t, you’ll be cutting off console, phone and tablet, school computers, laptops, streaming boxes, VR headsets, and any machine smaller or cheaper than a gaming PC. If you’re aiming for a long-term career, you cannot need to learn to maintain a clean project.

Getting Started With Optimization

Learn how to debug and profile your game while it’s running. Free software like Unity has some great profiling and debugging tools built in. How does your game run in a menu compared to active gameplay? Does the CPU spike when loading a level? Identify which of your scripts are the real monsters. Don’t stop when your game runs well, stop when it runs well on a notebook laptop.


We all want a system that’s firing on all cylinders non-stop, but that’s just not realistic on most projects. Familiarize yourself with the concept of Level-Of-Detail models. Does a truck tire half a kilometer away needs as much of your computer’s resources as one that’s a meter away? What about a model that’s moving quickly, or off to the side, or behind you? How accurate do the physics need to be in the room next-door, and do you need to calculate sounds happening 30 meters behind you?

We tackled the trucks first, because there could be up to 60 of them per level. So if optimizing one asset shaves off 0.3 milliseconds, optimizing the truck could shave off sixty times that. When I noticed that each truck had 6 wheels and each wheel had 340 polygons, our GPU could be rendering one hundred thousand fewer polygons with some optimization.

Don’t Check, Just Know

It’s very CPU-intensive to check if my player has a “player” script attached every update, or to check if my level is tagged as a level, or to load a sound effect from my game library. Collect that data in an array once (or not at all!) and then refer to that array when you need information. This way, the machine already knows the things you’ve declared, and doesn’t have to ask, or check, or load, or wait during gameplay.

Avoid Creating and Destroying

A tiny load-up stutter on a gaming machine could be a huge 5-seconds pause on an old laptop. Consider generating a game piece, with models and colliders and scripts, as an intensive action. Especially when you’re loading a level with 50 pieces at once, or more. Ask yourself what you can load one second later.

Better than that- look up the concept of an object pool. Keep an array of 10 explosions ready, and cycle them in during gameplay instead of constantly destroying and creating new ones. Keep your player object ready in the game between levels, instead of creating a new one each time. Keeping your game pieces managed, and less individual, makes for a game that’s much easier to work on. If you need to cap your sound effects to a lower maximum for some machine in 2018- you’ll be very ready for it if you created a manager from the start.

Tom Brien (tinyBuild)
Tom Brien (tinyBuild)
Hello I'm Tom at tinyBuild, I handle all creative decisions in publishing and promoting our games, and I'm responsible for the artwork, design and sometimes even coding on games we develop in-house!

Related articles