Currently, the AGameState actor derived from AGameStateBase provides a lot of useful game framework events when using AGameMode such has handing when a match has started and ended. It would make a lot of sense if these hooks were exposed to Blueprint as if you’re using AGameMode in blueprint and want this functionality, you essentially have to build a second copy of all this logic to handle it. Alternatively, a more drastic and most likely unfeasible option would be to remove this functionality altogether and leave it solely up to developers to build this logic themselves.
Most of this related logic in AGameMode is already exposed to Blueprint and has relevant hooks for catching match state changes. It seems like not exposing this stuff in AGameState is just an oversight.
I would prefer a refactor of GameMode and GameState.
GameMode and GameState were split to AGameMode, AGameModeBase and AGameState,AGameStateBase.
However, AGameModeBase still has functionality for a match-based game (SetState, isMatchStarted ) which is meant to be in AGameMode (Therefore the splitting doesn’t make sense at all).
It would be nice to have ServerTravel exposed to BP, too. For example only AGameMode has a variable “NumTravellingPlayers” which indicates how many players are currently Servertravelling. Which doesn’t make sense to me.
In general, it would be great if Epic would just create a non-trivial Blueprint-only network game. I think this alone would automatically lead to a lot of improvements :-).
I doubt this will happen mostly because trying to only use BP to do anything isn’t using the engine to full effect and Epic aren’t going to waste time doing everything in BP when their gameplay team can likely just step down into C++ to do what BP can’t (or shouldn’t).
I do agree that if Epic would do anything significant in BP only that a lot of improvements to BP would occur. I just really doubt that’d happen.