How can I structure in-game menus?

Question

I'm working on a multiplayer RPG using only C++ and SDL2. I've already made the main menu and a map editor, and I'm preparing to make the actual game. The main menu and map editor were easy to structure, because they had repetitive visuals and concepts -- map-editing tools can be represented as an enumerated list, just like saved-games and settings -- and so I was able to store them in structured vectors, and then when I went to render everything and check for user actions I could just iterate through the lists and hit every visible menu item. My code for those sections is small and neat; I'm proud of it.

Now, in the game, I'm realizing that my HUD is composed of a rather random assortment of types of things that the player can click on. There's a quick-access area for items, another one for spells, another one for the map, another for NPC-buddy commands, etc, and each of those have totally unique popup menus associated with them. Then there's a menu for crafting, a menu for NPC dialog, and several of the items have their own independent menus for interacting with them.

I'm trying to think of the right way to structure all these lists. Storing them in vectors like I did with the menu and stuff seems like it will land me with an unwieldy and asymmetrical set of nested vectors, and it might be complicated to iterate through it. How do good programmers handle this kind of thing? Should I just make an independent section in code for each in-game menu?

Answer 1

I don't think you are too far off making your code more manageable from what you have described. I write in C# so bare with me here.

I personally set up my UI components in containers, these containers not only hold all the associated UI components in a list (buttons, graphics, text etc), but also allows you to manage common capabilities such as position of the container, alpha values and enabling/disabling the UI container.

Each of these containers uses a common "Execute" function which just interates through each item in the container and executes their core code (any updates such as animations etc). The containers themselves are handled through a factory manager which simply keeps track of what containers have been allocated, and I reference them through a unique string name to retrieve the container, and I use unique names to reference the UI Component in the lists.

For each UI Component, I don't embed the game logic in the containers either, I have either in the past used callbacks or events to trigger the related logic.

My thoughts would be also not to make an independent section for each UI group. If you use something like callbacks or events, this abstraction allows you have high reuse of any actions from the UI. You want to auto trigger a UI action, say for a tutorial, you now have complete control of that, you simply calling for example (in C# i override [] operator!)

UIManager.Containers["Spellbar"].["fireball"].Trigger();

Hopefully it gives you some ideas, yes, moving to create containers around your UI to group the components will help with the code. Creating a common approach to your UI then means you it doesn't leach into your game logic.