gamestate survives through level changes, so if anything you want to keep through levels, it’s designed to be used in that.
also, scoreboard related thing can be kept in gamestate as well.
Where level play and level complete could just be 2 gamemode variable.
In your example, usually like this:
your player dies, issues a update from your pawn(ondestroyed event or from the event to calculate damage), usually sends directly to gamemode.
Game mode then updates game states and decides to continue or stop. kill/death can be stored in playerstate as well, it’s matter of preference.
fair enough
ive always found this area of unreal confusing, linking up HUD+Levels with states
where to handle the logic basically
like if i want the screen to fade out/in on level load/end
GameMode ? or GameState ? or should that be in the camera class…? (the only reason i havent but it in a custom camera class, is currently my camera is attached to a the player in the components of my character)
when my player dies im currently firing an event to GameMode so it can handle resetting the level etc… (or i guess re opening it) - id like to hear bring up a GameOver screen but do i handle that in my HUD?
this is where im confused at for example :
HUD
if GameState == “Dead” { DrawGameOver() }
if Player.Health < 0 { DrawGameOver() }
if GameState.bLevelEnded {
// do things
}
i know the answer can be “what is best for you”. but im asking for general opinions and what other people have done, how theyve handled this. i cant decide which is best, or which is the “more” correct way
well, I’d like to tell you there is this simple rules to follow, but guess it’s not going to be simple.
Basically check this diagram(scroll down to the end):
And read the content on that page.
So the not so simple rules would be(for me at least):
0. follow the hierarchy in that diagram, this is like the most important things to keep in mind. when you want to have gamemode do something, send a gamemode event and let game mode handle the rest.
same for all the rest framework classes. the less you try to “get this actor/bp and set its variable from another actor/bp”, the easier it would help you to scale up down the road.
do things in game mode when they affect the flow of games.( ie change game state, repawn player, spawn new waves of zombies, game over, etc)
handle input changes(ie remapping/merge axis values etc) in PlayerController
if there is intercommunication, try use interface instead of castTo and call event. This will reduce blueprint dependency.
make every effort possible to pass base classes(Actor/Pawn) as event/function input
Once your train of thought follow these thoughts, then the rest become easier to grasp.
So your case would be:
PlayerDead, game mode receives event.
game mode update game state, sent event to playercontroller that controls dying pawn, destroy pawn
player controller sents event updates HUD to show game over
once respawn limit lifted and button pressed, controller sents game mode to request new pawn to possess.
once controller possessed new pawn, send event to HUD to resume normal HUD
It will just be everyone firing events to recipients, and they just do their stuff.
Should never do something like all in one place, and everything chained in event tick or EventDrawHUD.
I wouldn’t say it’s foolish, but with UMG under active development, I guess a specific UIController won’t be necessary in the future.
Controller itself shouldn’t involve too much how a pawn moves or anything it tries to control to much.
Like my list, controller is to interpret actual hardware inputs, and possess/unpossess pawns, and maybe send event to update HUD.