Crossposted on App Goodies
Game performance is one of the most important aspects of game development (apart from reducing build size). While working on serious projects, the price of the code must be considered as well. (by price I mean whether it’s performance expensive or not).
More importantly, before actually writing the code, a plan must be drawn on the paper: e.g if I want to spawn enemies at random locations then I would produce a plan. Like so:
- Choose a random point
- Check whether that point overlaps with another enemy or player
- If true – choose another point and repeat
- If false – spawn a random enemy and repeat
It gives developers a clear picture on how things work and grants a great opportunity to brainstorm ideas on how to prevent using expensive functions. And here are tips I came up with so far.
Master Object Pooling
That sounds weird because how would you spawn enemies and kill them once they’re dead.
The answer is you don’t.
There is a performance loss when GameObject is being either instantiated or deleted. Instead, reuse them. This technique is called object pooling and is common among mobile developers where hardware has limited features and power.
So next time, instead of destroying a gameobject you could simply hide it and reuse it when needed.
Make a use of Occlusion Culling
Since Unity 5, all pro features are available for free so there is no excuse to use this feature!
What it does is disabling objects an active camera doesn’t see. It also disables objects which are obscured by nearer objects. A very handy feature as it boosts performance to the max!
You can read more on Occlusion Culling in the documentation.
Static Batching allows you to reduce a number of draw calls in your game, which reduces CPU cycles.
In order to mark objects for static batching, they must be marked as “Static”. Note that this could be possible only in objects never move. E.g terrain, buildings etc.
As of right now, static batching works only with mesh and particle systems.
Profiler is a very useful tool for finding out which function causes all that noise in your CPU. It reports you how much time spend in the various areas of your game. It can also report how much time it took to render a particular area, showing you whether it’s too performance extensive or not. If you don’t know why your game slows down and unsure which script is a culprit, use Unity’s built-in profiler. You can even profile your game even if it’s playing on your mobile device, giving you much more accurate results.
Bake whenever you can!
Sure, with new Unity 5 realtime lighting system you’re ready to take your game to the next level of awesome, you still need to optimize it. Like baking it. But bake only where it’s possible. If your game has fixed day time and static buildings around then take this as an opportunity to optimize your game. Baking lighting means that your computer don’t have to make real time calculations on shadowing, thus increasing performance.
You can read more on GI Lighting here.
Use LOD (Level of Detailing) for your models
When you’re far away from a 3D model, it doesn’t need to have next-gen super details, since you can’t simply see them from a long distance. LOD are series of 3D models with various detail levels. As you walk away from an object, a high polygon mesh is replaced by a lower polygon mesh, thus reducing performance cost.
However, this will increase your build size, since you’ll have different level of details for a single model. A solution is to think whether your model needs LOD. For example, player doesn’t need LOD since he is always close to a camera.
Use Texture Packing
Not only it reduces your build size, but it also vastly increases performance on low end hardware. Texture Packing is generally a technique where all textures are combined into one large image.
You can read more about texture packing in my other article.
You don’t need to enforce every single tips written, since some of them may not work with your genre. For example, side scrollers would benefit from Occlusion Culling, but not from LOD Groups since distance between meshes and camera doesn’t change. In other words, my camera doesn’t have to look at meshes at a far distance.
Did you find these tips useful? Have few more to share? Let me know in the comment section down below! I may add more performance tips so constantly check back for more updates.
If you enjoyed this article, then be sure to check out my blog for more!