Hello. Similar to a prior post, I’m interested in a best practice approach to the UI needs for our game. I’ve read through the lengthy list of posts, I’ve been able to play with Unity and learn a bit about the immediate mode approach to GUI rendering.
To that end, I have a couple general questions and a suggestion for how I think I want to approach the UI for our game. The information given to previous posters was helpful in narrowing down the questions for me, just looking to fill in the gaps.
Premise: Building a game that has basic sections of UI screens (splash, main menu, in-game UI hud, typical stuff). The in-game UI hud will have a LOT of windows (inventory, missions, help, character doll, navigation aids, chat, etc.) Those parts seem ok and well traveled.
One additional note is that there will be sub-sections of the game that are very different experiences with their own custom UI; lastly, these sections will be loaded dynamically, and we don’t know until runtime what they are ( as in, the sub-games will adhere to an interface, but not require that the master game know about their internals).
In my initial work with the UI, I had set up each major screen to be its own level. Looking at posts, this seems to be a heavy handed approach and one that might not be the best practice in the long run. SO…
With that in mind, my thinking is:
1.) Create a game object that remains persistent across level loads that is a master UI controller of sorts. This will have a script associated with it that stores information such as the current “UI screen” that is being displayed, and transition code (if i want to dissolve once screen, load another, code for doing that lives in here).
2.) For the various major UI screens, create a game object with attached script that “registers” with the master UI script so that it can be made active/inactive.
3.) For dynamic UI screens, from dynamically loaded levels, have UI scripts embedded in the loaded level that also register with the master UI so that they can be switched to once loaded (and the prior active UI screen made inactive).
Mostly, the key that I want to achieve with this or something better is having a clear, structured UI. I know that any game object in the world can have a GUIText or OnGUI call made, though there will be times when UI elements will not want to be drawn and so I’d like to have a way to track UI state globally.
Is this reasonable? Is there a better way? Using former UI systems, this approach worked well when we had logical “screens” of UI, but Unity’s UI approach is different enough that I figured I’d ask.
Thanks for any insight.