I think I already know this but wanted to ask the community just to be certain. What is the order in which all the blueprints get loaded when you start a game? Here is the order I think it is:
Game Mode
Game State
Player State
Level (and possibly every other BP that is preset into the world?)
HUD
Player Controller
Player Pawn
Another question I have which somewhat relates to this is, I am considering putting reference variable to certain things, like widgets/HUD’s and a few others, inside perhaps the Game State Blueprint so that I can easily access these references by making a simple cast to Game State in the blueprints which require those references. With regards to the widgets/HUD’s I was thinking of actually “Creating” them inside the Game State and keep as references, then Add/Remove them from the BP which I need them in.
So the questions would be, is this a good idea? Why or why not? I would like to not Create so many instances of the same widget if I don’t have too and figured that putting them in a top tier BP as references would be a good/resource saving place to do it. Any guidance would be greatly appreciated.
Funnily enough, I just deleted the same question a few minutes ago (after it was unresolved for a month).
The answer is: it depends.
This is mainly because of the In-Editor multiplayer sessions, which start a game session as soon as the game starts. This leads to stuff being initialized in a different order than when you normally join a multiplayergame (where you usually start an offline game and then join a multiplayer session).
I guess singleplayer is easier, the order is probably always the same there. Just add a print string to the OnLoad of each of those object and see how it turns out
Yeah I can see the MP games being a “depends” but single player should be relatively static I would think. I thought about running the test of Print Strings on each but figured it would be easier to get a true answer.
What about best practices for storing something like widgets in the Game State BP? I know there are no “rules” on it but I understand it is best to follow good programming practices so storing things like widget references in Game State may or may not be a good practice. What do you think?
I would rebut that though with the fact that the HUD is actually static and the same for each player. The only difference between the HUD’s for each player is the values that drive its content. The values to drive would be placed either in each player BP or probably better their individual Player State. Wouldn’t you think?
Actually thinking about it, game state is only loaded once where player state is created and loaded for each player so regardless of the HUD being the same for each it probably would be best to not have 1 instance of that HUD. Everything in player state would then probably be the best spot for a HUD reference.
Well, it’s not really true that you have just one HUD for everyone. Everyone has an instance of a gui (which probably is the same class for everyone), but it’s not replicated. Everyone has his own local instance. PlayerState and GameState on the other hand are replicated objects, and I strongly suggest separating local and replicated data.
GameInstance on the other hand exists over the whole runtime of a game and is (per default) not replicated. I consider it to be your local backyard and I guess thats a good place for it.
Yeah thanks for the discussion. After reading and thinking further and talking with you I realize that all the widgets should be instantiated in player controller since it is not replicated on every machine. Player controller is just as easy to get a reference to as is Game State or Player State so not a huge deal there. Still no answer to the load order so looks like I may need to start a blank project and run a “Print Screen” in each BP and check the Output Log for load order.
Now this is strange… I ran the “Print Screen” test in all concerning BP’s Begin Play node to see in which order they executed and the results were a little surprising. Here is the order they reported for me:
Player Controller
HUD
Game Mode
Game State
Player State
Level
Each BP physically placed into the level as they appear in the world outliner
I did this from blank project so didn’t want to take the time to make a player character.
I was rather surprised that the Player Controller loaded first, or at least reported first. I tried the test several times with the same results. I would have assumed that Game Mode would be first due to the fact that the Game Mode defines which blueprints are used for each of those instances. I know Game Mode is defined in the default.ini and therefore is loaded behind the scenes but I would have still figured it to load and report first.
That means that if Player Controller does a cast or calls a function from one of the lower reporting blueprints from Event Begin Play then those cast’s and/or functions won’t cast or work as expected because they haven’t been loaded yet… Interesting. I may test this last hypothesis next just to see if I am right.
Well I’ve tested this several ways and it seems my testing is sort of inconclusive. I tried to cast and get a variable from various blueprints to various blueprints and all functioned properly from within Begin Play. I got controller to grab and display variable values from Game Mode, Game State and Player State successfully. I then had Game Mode grab and display a variable value from the player controller successfully.
This then leads me to believe that each of the “important” blueprints, as I listed above, are actually loaded behind the scenes prior to any Event Begin Play nodes being called. This makes sense and is good to know that when it comes to the core blueprints as defined in the Game Mode settings, you can draw from one another without fear of the blueprint not being instantiated yet.
Game instance > Game Session (creates a default player controller) > UWorld > Game Mode.
Game Mode creates/loads/spawns the defined Controller, HUD, Game State, Player State etc.
Game Mode also creates Player, spawns Pawn, assigns controller (possess pawn)
