hi guys,i have a wonder why I need a HUD.
Here’s how I use it.
create UI in the level blueprint:
I use my HUD as a UI manager to centralize my control over the widgets I display. I don’t add widgets from just anywhere, opening UI goes as a request through the HUD. HUD class is also a dependency for a ton of things, even to display some debugging.
I don’t know anything else, but I think yours is great.
I’m going to try it out to see how you use it. Is it necessary to have multiple HUD classes, such as each level having its own HUD class, rather than just one class managing all the widgets? Switching levels also switches the HUD.
If each level has a HUD. It’s like a game menu, tap on an option to go to the next screen, and that should be the same level. Do you want to switch the HUD? Or do you want to change its widget in the HUD?
I would keep the same HUD normally unless I switch it out for debugging purposes.
Sometimes for a level like the main menu you will be in UI mode all the time and what is on screen will be so simple you can get away with just a default HUD and the main menu UserWidget on it, but usually you make one HUD class for the rest of the game and inject on it what you need. the HUD just implements core functionality. You could always decide what UserWidget classes to spawn inside of it based on what level you are in. For widget it is common you write core functionality once in c++ and let the designer make blueprint widgets based on them where only the design is implemented. then you can simply spawn a widget of design X or Y through the HUD. I let the HUD keep track of what is on screen.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
