So, I just overhauled the UI for my game, and learned some pretty important lessons in game architecture.

Now, I know the first question probably is, Why did you have to overhaul the entire UI system for your game? That is an excellent question! It started with a strange bug I ran into. If you opened the shop in my game, then opened the information menu, the mouse controls on the shop would override the controls on the information menu, despite the menu being displayed in front of the shop. This was a pain and I couldn't for the life of me figure it out. Eventually it hit me. UI elements in Godot are controlled in the order they exist on the tree, not the z value of the elements. So while the information menu was Displayed in front of the shop menu, because it had a higher z-value, the shop UI was higher in the tree, making its controls override the information menu.

Well that was a pain, how do I keep all my menus ordered so that as I add to the game, everything is displayed and controlled correctly? Well, I was doing some research into this and someone said, "It is best practice to not have your Control elements as children of a Node2D..." That stuck with me because ALL of my control elements were children of a Node2D. Or, more accurately, NEARLY ALL of my UI elements were actually a Node2D. And this kinda sucked, because I had so many menus, icons, and progress bars throughout EVERY level of my game. This meant if I wanted to do UI "correctly", I would have to redo almost every piece of UI. So, I figured if I'm gonna do that, I'm gonna do it the right way.

In the game structure, I have a Main node that is the beginning of everything. From there I had ~3 scenes that I would load and deload depending on what was happening. The title screen, the game, and the credits screen. Well, if I am creating a UI Manager, it probably should hold the Title and Credits pages under it. So I started with that, or what I call the System UI. I worked on refactoring those pages, getting them connected correctly, and getting Main to display those pages from the UI Manager rather than inside itself. This wasn't too hard, but it also was probably the simplest to implement. From there, I worked to move the game HUD, information menu, achievements notification, and quest display out from the Game scene and under the UI Manager. This took a little bit to do, but I found out I can add the Manager to the Forge Bus, and because the Game scene is not instantiated until after the game is started, all the in world objects can just reach the UI Manager through the ForgeBus (a singleton I created for "global" variables and what not).

That is basically what I did for the rest of the UI elements too. As I added elements I added different Canvas layers for each UI Type as well. The final layers I ended up with were HUD, Level, Game, and System, displayed in that order from back to front. With this, I can access each different UI type through the Manager, but also manage entire layers if I need. I was also able to create a UI Stack that gets added to as menus get opened. And with that, I just check if the player presses Escape or moves, and I pop the menus from the stack. So, if the player has the shop and information menu opened, they can press Escape once to close the information menu, then again to close the shop. This was super easy to implement with the new system, and would have been a pain to get working with the old way I was doing UI. I'm excited to see how this system grows as new features get added to the game.

This has been updated in the game so if you haven't tried the demo yet, I highly suggest you do. Next update I hope to have the art overhauled and the grindwheel mechanic changed so stay tuned for new additions to the game.