Singleton pattern in c++

PIE is a simulation of what a build would look like. If the GameInstance was created at editor load and persisted through runs it would not be an accurate representation of build state at all – since in a build, when the game instance is created, it truly persists for the session as a singleton.

Also, there’s nothing that says singletons are necessarily run-once – they just need to be self-constructing with a static reference to the a single instance, usually with a guarantee or run-once strategy. In UE4 they need that run-once guarantee, hence why GameInstance exists at all. Many of the if guards that protect singletons from duplicate instantiation are completely ignored, since as developers we usually have no reason to suspect duplicates and don’t want to waste CPU in bool checks on the hot loop. What’s important about a singleton is that there’s always one instance-- since we change levels a lot, it’s not unheard of to have singleton patterns on objects that only persist for the duration of level. In my Unity game, for example, I have 4 or 5 player interaction singletons that get instantiated and destroyed every time a Local Network Player Controller is created. There are video breakdowns on popular games like Overwatch where this practice is considered commonplace.

In game engines like Unity and Unreal it is difficult to have true singletons with all the strict rules so you almost always use the singleton pattern loosely. For example, because you would be outside the scope of the engine and unable to interact with the APIs. In Unity, we use pseudo-singletons instantiated in Awake() because we’re not even allowed to use constructors in MonoBehaviours. In Unreal, we do something very un-singleton like and instantiate our singletons from the GameInstance.

Lastly – there’s nothing wrong with destroying and reconstructing your singletons! It can be useful for clearing state between sessions of things, or when a user logs out, stuff like that :wink:

Also – your odds of getting help on basic game dev patterns from the Unreal devs is pretty low, you’re gonna have to trust a professional game developer on this one… and a little courtesy goes a long ways, especially when asking for help.

What the? What am I, chopped liver? I never asked you for help.

This is what you said at first: “This is how singletons in virtually all game engines work.”

After I pointed out what you were saying was wrong, you changed it to “we use the singleton pattern loosely.”

Please stop posting in this thread. You haven’t said one thing of value.

I’m sorry, but you’re clearly just starting out and I’m trying to help you.

Singletons have two strict rules: it must have a static reference to an instance of itself and there can only be one instance at a time.

There is a (deprecated) Game Singleton that you can use. If you use GameInstance, then it’s like a Singleton that manages the lifecycle of all Singletons. Only different between that and the classical pattern is that the GameInstantiates the singleton instead of self instantiation.

When you build, the game launches and you get an instance. When you open Unlrea, you get a new instance. When you press PIE, the game launches and you get an instance. If the singleton persisted from editor launch to PIE to the next session to the next, you’d have left over state that would cause problems. At the same time, you need to have a Game Instance singleton available to the editor for other things, so it needs to always exist, but it also needs to be fresh or you risk carrying data between edit sessions.

If you want, you can use Game Singleton, this will work as intended.

I’ve tried helping you. I’m not wrong. You’re a beginner on the forum starting out looking for answers to 101 questions. Don’t be a ■■■■.

Closer to a singleton is probably a subsystem. There’s a good tutorial available here: Using Singleton Design Pattern in Unreal -- Blog

Just note that if you copy that code you have to remove the Abstract and inherit from one of the specific classes like UWorldSubsystem.
For static Blueprint functions you need to pass a UWorld* as a parameter to the function that you can get in your blueprint with a GetWorld node.