Hey all, this is more of a “what sort of practices do you recommend” question more than a “how do I do this” question.
I’m curious how others handle having lots of UI elements in their game that are constantly opening and closing.
Do you load in ALL your UI objects with the scene and then hide/show them as needed? Or do you maybe do runtime instantiation of the UIs from maybe Prefabs or AssetBundles when the user opens them and then destroy when closed?
Would love to hear your thoughts.
Combination of both. Ideally, you’d instantiate on demand rather than have it sit in memory. However, there are some exceptions. I can’t think of any at the moment. But preloading to minimize instantiation time, can be a thing, but typically UI that requires, say, lots of inventory items to load would be better to be loaded in a background process, while just loading the immediately visible UI elements.
Another factor to deal with is managing state between UI windows/dialogs. Typically, you’d have your UI controls update the state of another object that is accessible from other windows/dialogs, so this shouldn’t be a problem, but on first implementation, it’s typically tempting to store state inside the windows/dialogs themselves.
Yet another factor to deal with is whether you want to affect the state of that external object, or wait for a commit by the user to confirm all changes atomically. In this case, you will almost certainly have a separate, light-weight state object on the UI side that gathers all the changes and forces the update when the user presses OK, Accept, Confirm, whatever.
And then yet another factor to deal with is whether or not you want to support an undo/redo stack. This gets really hairy, as you have to respect the scope that you want the undo/redo operations to work in. Does it span all UI windows? Just the currently-focused window?
Handling state and passing that data back and forth between UIs has been a challenge for me. I have something working but it feels wrong and very, very brittle. I don’t suppose you could suggest any reading on the subject?
Nope, I don’t know any off hand. But typically, look for Model-View-Controller (MVC) pattern articles to read. They’re usually very generic though. Or MVP, Model-View-Presenter, which is a variation on MVC, where Presenter is more of just an “interpreter” between the Model and View. This inspires me to write on the subject, specifically for game dev, though, I doubt I’d get around to it in a timely enough manner for your own needs.