Engine Design issue - Order of GameObject / Components

I (and many others) been bitten by undefined order of gameobjects / components. I know there is the script execution order, but I have the situation today where I have to use the same script in different game objects. And guess what, I need to the gameobjects to be updated in certain order. So I have working around this annoyance for quite some time, but now I have to rant.

Why can’t game object be updated in order in the hierarchy, from parent to child? Current design, it is possible the child script gets called before the parent. It is a pain to setup something more complicated just because of this.

I done a component based engine before. Instead of storing the gameobject/component in a dictionary, just store them as a linked list as they appear in the hierarchy/inspector. It solves a lot of ordering issues, including FindObjects calls to have defined order.

I second that! I ran into the same issue a while ago and had to come up with a not-so-pretty™ workaround.

I’m curious why you were forced to use the same component on different classes of GameObjects. Perhaps you could move the shared logic out of that component, into a Component Utility class, and then separate the component in to two different versions which are facades for the Utility class. Then script execution order can remain in effect.

Except the hierarchy is sorted alphabetically. That would have to change first.

Stay away from initializing things in Awake and Start and use an initialization function that’s called when the object is created (assuming you’re instantiating the object somewhere and its not just in the scene already – if it is, register it with the manager and then let it call the initialization function.) Drive your update loops through a manager which is set to execute 1st by script execution order instead of calling Update in all your scripts. You’ll have complete control over initialization and execution order of scripts.

You could even have a component on your parent object whose only job is to initialize all the child components in the game object’s hierarchy in the order you desire. This would be pretty easy to do if your components share an interface.

Just as an addition to what you said, component execution order within one Game Object isn’t predictable either, especially if you’re mixing languages.

Well, that solution is reimplementing the component system. Especially when it comes threading and batching. It should be done right at engine level.