Hi, just a question to the gurus: Where do you create your HUD, usually? I have been doing a couple tutorials and also checked the docs, and people tend to create the HUD in the Map or in the Player Character.
Creating it in the Map does not make sense to me though, since you have to do it for each level then and I don’t have a player character since I work on a strategy game. I was thinking to put it into the Game Mode, since you usually have exactly one game mode that represents the ingame state. Or am I missing a common use case where this could be a problem?
The Map as in the Level Blueprint? Probably the worst place imaginable, ha!
This would depend on what game type / genre / required interactions and, most importantly, whether multiplayer features are needed.
For multiplayer unrelated stuff (since I know precisely diddly squat about MP):
If it’s first / third person, the player character is actually not a bad place to do it, Game Mode will be fine, so will be the Player Controller. For something like an RTS, you could have in the Pawn or the Controller or the Game Mode.
For a puzzle game, you could have it the actor that handles most of the logic although any of the above-mentioned framework classes would probably be better in the long run.
Again, for single player it does not really matter much. Not Level Blueprint, for sure - that’s unless you have a bunch of unique levels that do something truly special. I’d still avoid it.
You can always opt for the venerable HUD::
Comes with extra features not available anywhere else, in case you’re after doing something unorthodox:
Yes, I did several tutorials where they put the HUD in the level blueprint. I guess for the sake of simplicity or whatever, but it does not help when deciding how to tackle this in your project
Thanks for the input, this helps.
One more question: When I have context sensitive HUD information, e.g. specific interactions with a building that is selected by the user. Like a popup with info and a button “Destroy Building”. Would it be recommended to create this new Widget in the blueprint of the building, or tell the game mode to create this widget, which will then communicate to the building?
Best practice would be the Ui completely separate from the function.
In fact, any function that can be called remotely should just use a blueprint interface.
The object will implement the interface however it sees fit.
The UI will send the call off to the function.
Now with that said, if your player directly interact with a building to issue a destroy command, you spawn the UI from the building click.
You can obviously always find the player controller and call a “spawn” method you create.
It’s actually easier in the long run for RTS type games where you can ineract with a billion things.
It forces you to create a “standard” template that gets updated based on what type of building was clicked (passe along to the function in player controller).
So make a standard widget, create a custom event, add an “actor” parameter to it so you can test and change the look/name etc - or, even better parameterize everything and add it as pins to the event.
Image, name, status, whatever else may be relevant. OR even even better, make a Struct with what you need and pin that.
Then when you call the event you can break the pin or create the struct ad-hoc for every base item type that generates the interface when interacted.
[quote=“NEVQ151, post:3, topic:225969”]
“would it be recommended to create this new Widget in the blueprint of the building,”
I always prefer this option and have encapsulated so that they are self-sufficient, this makes it easier to implement, look for bugs, and saves you a lot of work trying to connect blueprints that are not known.
Thanks for all the valuable input guys, it’s appreciated. I will try both options and see what is easier to work with. I am a bit concerned over passing the status of each building into a generic interface, since different buildings could have completely different status structures, so it might be hard to generalize that (?)
Simple tutorials aren’t always the best practice, and they don’t have to be, here they just explain how to create a widget and the instructions to display it. Where is the best place to display it depends on how you have structured your game.
Yes, I understand all that. I watched a bunch of tutorials that all used the Level without any of them mentioning that I could (and should) put the UI in different object types, I am just saying it is confusing to learn the engine when the context is not explained and the tutorials could be improved by discussing it.
Ooo this is a great question! I was thinking maybe as an ActorComponent and then on the Player Controller you have an interface that the ActorComponent can feed on. Just thinking about the future since you could drag and drop it to some extent to other projects. In my case I’m just thinking of a Player HUD though Ex, Bullet Count, Health Bar, Stamina Bar. I’m thinking via C++ of course.
