GameMode - worthless for Blueprint users?

[GamerErrant]

Thanks Rama.

Yea rodstone, that's all you can really use it for currently. But according to Epic documentation (at least as I've interpreted it from the docs and several posts):

GameMode is primarily a state-machine (MatchState) you use to control the flow of the game (game is pre-start so do these things, these conditions are met put the game in this state, game ended do these..).
GameState is a light-weight object used to store gameplay data that is automatically replicated across the network (scores, world-specific states like triggered objective etc).
PlayerController provies the logic for the player interfacing with a Pawn and the game (player hit X button play Y event etc).
PlayerState is a light-weight object used to store player data that is automatically replicated across the network (health, name, location etc).

So basically we're missing all state-machine functionality from GameMode if we're using Blueprint, which is all it's really there for in the first place (aside from being the central place to set GameState/PlayerState classes).

[Rama]

Yea, if it's supposed to be used to control and react to the flow of the game we certainly need access to variables and functions for those! For the time being it looks like I'll be rolling my own BP-only state machine to handle game flow - not the end of the world, but annoying knowing there's a robust built-in system for it (which I can't use, because the rest is done in Blueprint thus inaccessable from C++).

I could see use of nearly all the functions listed in the API, but here are some that jump out at me as must-have (and which I was looking for originally):

• InitGame
• InitNewPlayer
• ResetLevel
• RestartGame
• SetMatchState (and all handlers it fires for each state, as outlined HERE under 'Match State')
• GetMatchState

Those would be great, and if Epic likes my first pull request I can work on the above too, or they might read this thread and do it on their own

I submitted pull request for player restart functionality.

Feel free to chime in if you'd like to see this pull request make into the Engine!

(you must be logged into your Epic-linked github account to access this)
https://github.com/EpicGames/UnrealEngine/pull/568

Rama

[rodstone]

I only use GameMode in the sense that it lets me specify my PlayerController (which specifies my CameraManager) and GameState, which I use to hold things like how much money the player has

I don't know if that's a good use for GameState but I consider GameState to be "the session you're currently playing".

[GamerErrant]

Yea, if it's supposed to be used to control and react to the flow of the game we certainly need access to variables and functions for those! For the time being it looks like I'll be rolling my own BP-only state machine to handle game flow - not the end of the world, but annoying knowing there's a robust built-in system for it (which I can't use, because the rest is done in Blueprint thus inaccessable from C++).

I could see use of nearly all the functions listed in the API, but here are some that jump out at me as must-have (and which I was looking for originally):

• InitGame
• InitNewPlayer
• ResetLevel
• RestartGame
• SetMatchState (and all handlers it fires for each state, as outlined HERE under 'Match State')
• GetMatchState

[Rama]

I agree that most of Game Mode really does need to be exposed to blueprints!

Especially these functions which can really control the flow gameplay!

/** 
 * Return the 'best' player start for this player to start from.
 * @param Player - is the AController for whom we are choosing a playerstart
 * @param IncomingName - specifies the tag of a Playerstart to use
 * @returns Actor chosen as player start (usually a PlayerStart)
 */
virtual class AActor* FindPlayerStart( AController* Player, const FString& IncomingName = TEXT("") );

/** 
* Return the 'best' player start for this player to start from.  
* Default implementation just returns the first PlayerStart found.
* @param Player is the controller for whom we are choosing a playerstart
* @returns AActor chosen as player start (usually a PlayerStart)
 */
virtual class AActor* ChoosePlayerStart( AController* Player );

/** @return true if it's valid to call RestartPlayer. Will call Player->CanRestartPlayer */
virtual bool PlayerCanRestart( APlayerController* Player );

I will submit a pull request to get them exposed, see what Epic says on the matter

~~~

Complimentary Point

On the complimentary side of things, Game mode is actually one of the only class I prefer to always have a blueprint of, because it is so much easier and cleaner to set references to all the various default classes like Character and Player Controller in blueprints!

~~~

Community Input

Everyone feel free to submit what functions and variables you think should be exposed to Blueprints and we can compile some nice feedback for Epic

Rama

[GamerErrant]

So I’ve been digging into the general Unreal framework, and so far as I can tell GameMode is only of any use when working in C++. While you can derive blueprints from it there’s virtually nothing you can actually use them for within Blueprint itself.

• You can’t access MatchState, and no events deriving from the setting of MatchState are exposed to Blueprint.
• Almost all of the variables aren’t exposed to Blueprint.. not even trivial things like NumPlayers.
• Almost all of the functions are virtual and cannot be overridden in Blueprint.

No wonder there are so many confused questions about GameMode usage on the answerhub. Basically its only use outside of C++ is an Actor that’s automatically spawned when a level is loaded.

Is that interpretation correct or am I overlooking something really obvious?