I’m trying to wrap my brain around what specific functionality a HUD BP has?
From examples I’ve seen ‘Event Receive Draw HUD’ is used for switching displayed widgets, but that can be done elsewhere by just using ‘add to viewport’ etc. It has some other functions under the ‘HUD’ category that I’m not familiar with which could be useful in some cases.
A widget can also grab variables straight from a pawn etc to display those directly without interfaces. Are interfaces still recommended to use, and if so - why?
I’m wondering what the most important reasons are for using this class to communicate between classes are vs skipping this middle man? Organizational reasons mainly?
Organization and automatic initialization I’d think. All player controllers will automatically be assigned the designated HUD, and I’d imagine this makes setting up the player controller a lot simpler while also allowing a lot of reusability (like you could use the HUD in different player controllers or the same player controller could use different HUDs in different game modes).
Yeah maybe those things would be useful… it feels like if you use a HUD class you’ll be sending data around quite a bit more and makes at least smaller games less readable?
I’ve attached an image to try to explain myself better. I’ve seen some tutorials that use enums to set the various screens, but it seems like a few more steps than if you’d just set functionality right on the widgets? In that image I’d need more logic after the enum switch of course as well…
I’m not sure if I’m even using the HUD class correctly here but input would be great.
Well maybe the HUD class isn’t appropriate for menu UI. I haven’t really used UMG yet, but I use the HUD class for placeholder HUD stuff right now, though it wouldn’t be hard to make it look less like a placeholder.
