I have a game character that when getting clicked on, a bunch of panels open up. I achieve this by having the character call a static event upon clicking it. That way it works for all instances of that character and I can easily add or remove objects that react to it without having to modify the character.
The problem is that those panels still need to subscribe to it. I have 2 ways I use and neither one is awesome:
Make the panels active in the scene so OnEnable gets called, where the listener is added, then disable them in the same frame. Very impractical as I need all those panels to be active on build/testing.
Have a class that does the subscribing. E.g. a serialized field for every panel, in Awake it subscribes the classes to the right events. Ok but not as dynamic.
OnEnable/OnDisable is really the most-popular pattern in Unity for this and it is rock-solid reliable. You can even combine it with a singleton pattern so that your resources fires itself up automagically and only once.
Unfortunately you canât use static constructors for stuff like this because Unity isnât ready for business when those are created, and everything in scripting must be done in Unityâs main thread.
Unity does not really ârunâ code the way youâd expect with your own engine or other run contexts.
All Unity does is âload the first scene,â and after that itâs up to you to put scripts in that scene that take you through all the rest of your game.
The way I handle this type of requirement is to have a separate scene for UI components, world & screen space. All UI elements are linked to or instantiate, and controlled by a singleton UIManager class which handles referencing. Said UI scene is additively loaded prior to all other scenes, so that the singleton UIManager class is available to all subsequently loaded scenes and their entities. Then when the entity is first instantiated or woken up it self registered a callback with the UI Manager for the specific UI entity or instance.
+1 for mentioning additive scene loading⌠it takes a teeny bit of extra thinking and setup but pays HUGE dividends. In fact, I have committed other feverish scribblings about it here:
Itâs super helpful especially when working in a team where the UI dev needs to edit (and check in) UI elements that would otherwise be part of the checked out scene youâre currently adding functionality to. (Unity single scene projects and git/svn donât merge nicely)
Also comes in handy when baking, especially when you have multiple scene chunks that can be baked independently of each other. Iâd hate to have to re-bake an entire level when just one corner of it was changed, and that corner canât be seen by or doesnât affect the other level âchunksâ.
It also comes in super handy with a singleton that manages object references using a GUID, which allows for cross scene editor linking and working around the current inability to assign editor references to objects in another scene.