where/when to use GameState

Development Programming & Scripting Blueprint
1

would i use gamestate for all my current game states ?
as in :
gamestate_MainMenu
gamestate_LevelPlay
gamestate_LevelComplete
gamestate_PlayerDeath

?

im curious as say, my player dies, should my gamestate kick in and say “player has died, change the current game state” ?

2

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.

3

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

4

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.

  1. 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)
  2. handle input changes(ie remapping/merge axis values etc) in PlayerController
  3. 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:

  1. PlayerDead, game mode receives event.
  2. game mode update game state, sent event to playercontroller that controls dying pawn, destroy pawn
  3. player controller sents event updates HUD to show game over
  4. once respawn limit lifted and button pressed, controller sents game mode to request new pawn to possess.
  5. 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.

1 Like
5

This should be a sticky note!

6

after maybe 5+ years of using the unreal forums, i finally have a thread which has “sticky note” demand ! how do we make this happen ? lol

@PenguinTD, that’s very concise and excellent information (with the link too) big “thanks” :slight_smile: - going to continue reading throughout the day

i shall try and implement these, and return with any possible follow up questions :stuck_out_tongue:

7

would it be foolish to create 2 controllers ? GameController, UIController ?
Or should it be Controller with different states ?

8

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.