As the post title suggests, I’m trying to figure out where it makes sense to create the HUD , Menus, and UMG widgets for a game.
The current scenario is that I want to pop up a message on the screen when the player completes (or fails) a level. Based on the description of the GameMode class, completion / failure looks like it should be determined by the GameMode. Does this mean that the GameMode should monitor for level complete/fail conditions then modify the HUD / pop up messages as needed?
In the level I’m working on now, the level is completed once the player reaches a door at the end. To implement the above design (GameMode being in control), I imagine the following steps would be taken:
The Player Pawn would monitor for collision with the door
When collision happens, it would notify the GameMode. This could be done by either calling a function on the game mode, or setting a flag in the Pawn’s class. Setting the flag would imply that the GameMode would be ticking and looking at that flag - would that be a bad way to do it?
Hopefully these ramblings make a bit of sense … thank you in advance for helping me wrap my brain around these basic design concepts!
I would put the collision in the level blueprint, then calling a new level via “open level”
You can use a gameinstance to pass values between levels for things like storing the current level’s value and updating it to the next level so it knows what its doing and use those values in the ui
GameInstance is a very cool class - I was previously unaware of it - thank you!
In my simple game example, there is no data to pass between levels. All I want to do is display a “good job” message when the player reaches the door. Would the level blueprint be a good place to store this? My concern is that if I have something like 20 levels and I want to change the message, then I would have to make that change in 20 places.
Also, how would we put the collision in the level blueprint? Does that mean that you would have the level blueprint itself monitor for the collision, or would one of the Actors involved in the collision notify the level blueprint?
Well if the door is a blueprint actor I would just make the message appear there and not mess with the level blueprints. My entire game doesn’t use level blueprints at all except for when a player overlaps a kill volume.
And what collision? Collision with the door? Yeah just do it all in the door actors blueprint. Maybe it has to call gamemode to end the game or however you want to handle that.
This way all you have to do is drop the door in any one of your levels for the desired effects.
If it is an overall Menu, with different things i would use the GameInstance and a State System. Take a look at the Multiplayer Shootout. It has a good system for that.
You can also show your ingame HUD with that with a state like “Is playing”. With placing them inside the Instance class, you are sure that you don’t have multiple widgets up.
Make sure to save a widget inside a ref variable and always check if the variable is null. So you really only spawn one widget at a time.
The Multiplayer Shootout project is certainly interesting to look at. If I’m reading it properly, it looks like the UMG widgets are separated so that widgets displayed during game play are stored in the PlayerController, while widgets displayed outside of game play are stored in the GameInstance.
The HUD is updated by the individual widgets ticking - meaning the HUD ticks to update the scoreboard and the ammo widget ticks separately to update the ammo display. The GameInstance widgets are initiated by player input.
Applying this logic to my game example, it looks like the since the “good job” message displays after the level play has finished, the widget should live in the GameInstance. This leaves the question of how to trigger the widget to display. Would it be poor practice to have the PlayerPawn (or the door, as TheFoyer suggests) talk directly to the GameInstance to tell it that the level is over?