For those who may have been following since before this blog began, you may have seen the Iceglow Gel death sequence that includes the possibility of spawning smaller Mini Iceglow Gels. This was, by and large, a stroke of sheer genius on my part (yeah yeah yeah, just let me have this one). It seemed like a cool idea and has led to some other cool ideas for deaths with other mobs. In fact, each mob has a DeathScript requirement, even if it’s just to, you know… die.
But this has also been a thorn in my side. When an Iceglow dies, there is a major stutter before the new minis are spawned in. I finally decided to toss up the profile to see what was going on, and decided to write this brief post on profiling, because damn, it’s handy!
For those new to Unity or development, the profiler is a pretty common tool used to “debug” the actual running game. It can attach to a development build for better and more accurate profiling, but if you’re simply looking for bottlenecks where the definitive time and resources aren’t as important as discovering the spike, you can also simply attach the profiler to the editor itself.
This was a capture at the time of the resource spike right when the Iceglow dies.
The details of CPU usage show that the >1s spike is caused by the PhysX core baking the mesh for the minis. I was hoping that, since this was running in a coroutine, that it wouldn’t impact the whole of the game. Maybe I’m doing it wrong (or, at least, not the best way). Maybe I can pre-bake those meshes. Maybe I can use simple colliders instead (a cube is far easier to calculate). I’m just delving into this, and I’m not sure what the best solution is yet (stay tuned for updates on that, or follow my plea for help), but for now, the profiler is my handy tool to figure out what calls are b0rking the game.
Easily as important as debugging code, and definitely more important for tuning, I can’t recommend highly enough learning to love your profiler.