The Hidden Lives of Game UI Elements
The answer was “abstraction” and “oversimplification”. I created a “window manager” which is nothing more than a list of windows in the system. When a window starts up, it registers itself in the master window manager list, and then either stays put, or is hidden (or moved to a point off-screen). With the window manager system attached to the Game Data Object — the global, non-destroyed, singleton object that is accessible from everywhere in the game — I can call methods like ActivateGameWindow() and pass in a name as an argument, like “ResearchRentalUI”. If that UI has self-registered and is in the management stack, then the method will find it and turn it on, activate the animation, or do whatever it needs to do in order to activate that element. This messenger systems ensures that I don’t need to have one specific element know about the existence of another specific element, so long as I don’t misspell the name of the UI element I want to send the message to.
I’m not writing this because this is some kind of revolutionary design technique, but rather because what we see on the surface isn’t always what we think we’re looking at. Sometimes things are more complex, and sometimes they’re more simplistic, and sometimes they’re way out in left field.