The problem is that these notifications are done via calls from C++ to C#, which is costly in itself, and the fact that Unity does a lot of safeguarding behind the scenes. When your component is initialized for the first time, Unity checks if it contains a magic method, and if yes, it adds the component to an internal list of objects that need to be notified when certain engine events happen (Awake, Update, etc.). Not to mention that it’s weird from a coder’s standpoint.Īnother issue is the performance. Unity gives you some degree of control via the script execution order tool, but even that cannot solve all use-cases. It’s not clear and you can never be 100% sure of what gets called when and in what order. In Unity, this is all set in stone and you have almost no control over the flow. In classical game architectures, you write your main loop where you poll for input, update objects, components, systems, and render audiovisuals in the order of your choosing. Especially if you implement some kind of full-state save system with multiple ways of loading scenes (more on that later). Issues start to pop out the moment your game grows in size and complexity though. Yeah, that surely works for the mini-projects their tutorials take place in. So, Unity teaches you to create game objects, slap your components on them, have your components listen for the “magic methods” like Awake, Start, Update, and the like, and the meadows are green and roses are red. Unity is an exceptional tool for creating games, and I love most of what it does for you! Especially now that I know what I know, after 4 years of using it in making Vaporum, I wouldn’t want to change my precious little engine for anything! But that’s exactly the issue - you have no way of knowing in advance that you’ll get slapped plenty of times going the “Unity” way of doing things.

This post is about how to avoid Unity’s coding pitfalls you will inevitably fall into if you follow the official tutorials.ĭon’t take me wrong.

Vaporum max circuits