If you’re reading this, there probably aren’t very many posts yet. But don’t worry, you can be the first! Either create a new post or just reply to this one to say ‘hi’.
The compiler didn’t flag your Init function because what you entered was perfectly valid C++ code. A function does not have to be a class member and can be a stand-alone function. So your long name of a function without the :: init was perfectly valid as far as the compiler was concerned. It would not have been called properly of course but would compile, though with the missing definition your class would not have compiled.
The only difference I see is Constructor is called when the editor is restarted but not Init. Hint for others: click Filters in the output log and uncheck Messages and you will see the log warnings better.
2 Likes
When I restart the editor OR start a game the constructor of the instance is always called.
I think this is because the gameinstance is the core of the running game and without it it can’t function, this explains why the constructor activates as soon as the engine starts.
Also when running a gamewindow it has to be reconstructed for that running instance.
I think that Init() is run when actually “in play” so effects the game instance should have on gameplay, only run while there is “gameplay”.
This is what I think is happening under the hood when I tried to follow the challenge.
1 Like
General question here that I’m not sure if I simply missed in this section… but WHEN do you use a GameInstance? The lesson clearly indicated some of the basics of ‘how’ to implement a game instance (though only really touched on Init vs. constructor, similar to the different between an actor constructor vs. beginplay() call). - but it never went over WHEN and WHY you’d use a GameInstance over something like GameState, etc? Is it simply due to persistence across multiple levels (which could have different overridden GameModes/GameState classes?)
I guess I may have just answered my own question here… but I’d be happy to get a confirmation.
1 Like
Below I’ll paste a link from the documentation. It outlines in what order objects get initialized, and which functions get called at what point. There’s a neat flow diagram contrasting playing from editor and playing a standalone game. (In order to read the flow chart, I had to open it in a new tab and zoom in)
Nice one! Keep up the good work and sharing it with other students.
That’s about right. Really it’s about lifetime.
why we don’t use Super::Init() ?
I maybe just forgot.
When I start the game or restart the editor, I always get the constructor. This is because the constructor is looked at before beginplay or the start of the game.
Ok, a bit late to the party, but I only started the course now and wanted to add something to the discussion…
So like everyone else, I noticed that restarting the editor had the constructor of our GameInstance called, but not init().
It got a bit interesting though when I added logs to the constructors of regular game objects, in this case the platform triggers. Both playing in editor and from cmd (with the editor closed) I noticed that during the building/loading process of the game the Platform constructor is called once (even before the gameinstance in my case), but then after all several lines of code and right after Texture streaming is enabled, the GameInstance constructor is called with the init() right after it, the game STILL hasn’t started yet. Two lines later “Game Initialized” and the “Display: Starting Game” the next line. Game is obviously now starting.
After that, many lines down several PlatformTrigger constructor log messages are displayed, obviously related to the number of triggers in level.
So what does this tell me? The constructor definitely gets called before the game starts, and even gets called during loading/building the game. As for the single PlatformTrigger constructor call… I’m guessing its called during loading for caching reasons, kinda like an object pooler? While the init() doesn’t get called during this time, it’s called immediately before the game itself starts, even before any other constructor in game (aside from gameinstance) is called. So it’s almost like a pre-game BeginPlay(), but on steroids.
This makes sense since you probably want to make sure it’s called before any other function or even constructor, seeing as how GameInstance is responsible for spawning your levels and such.
Pretty spot on analytical skills!