Singleton pattern in c++
I am trying to implement a singleton pattern in c++ for manager objects. This are objects like a LevelManager that keeps track of all data of all the levels in the world like: name, description, spawnable tiles, images etc all stored in a struct TArray. and an UnlockManager which keeps track of all unlocks in my game. Which item the player has unlocked and which are still locked etc.
I got it to work, but it gives me problems while playing in editor (PIE). Because static variables are carried over between play sessions in the editor.. and somehow, my static instance variables become invalid after the second play.
To make it all work again, I have to restart the editor.. This is very annoying, and I can't seem to find a solution for this.
Does anyone know how to properly implement the singleton pattern for use in UE4? Or know another way to get global accessible classes in c++ ?
asked Jul 28 '18 at 01:04 PM in C++ Programming
I ran into a similar problem in the past. ONE solution is not to use singletons (i.e. try to force general programming patterns into an engine with its own framework and workflow). The way to cleanly integrate single-instance objects into Unreal is to put them either into the GameMode or GameInstance. The former is per-level, while the latter carries over. You have to decide which one is better for your particular use case.
For example: My SaveGameManager is instantiated by the GameInstance, since I can't have it reset whenever the player switches levels. This means that it's created before the first level is loaded and destroyed just before the game quits. I have a class that manages footstep sound mappings (surface to a set of sounds). Since all characters use the same mappings, I only need one instance of it. That one goes into the GameMode and is thus created at the beginning of a level and destroyed once it's left. And for the intended purpose, that's perfectly alright, because that object doesn't need to carry over data across level transitions.
I faced the same situation in Unity and it has been the same thing: Using the framework as intended (in your case: designing your systems around the lifecycle the engine expects objects to have) unfailingly was less work than trying to force the engine to play nice with a system that wasn't designed with the engine's framework in mind. I had to deal with cascading workarounds, because something always broke somewhere. Then I redesigned it around how Unity expects GameObjects to work and guess what? It just worked.
So my recommendation to you would be to reassess the problem at hand. Study the UObject/AActor life-cycles and the gameplay framework. As big as the latter is, chances are Epic has already put something into place where your system would integrate beautifully and headache-free.
Hi Sniper Fan,
I was thinking more about the code in the singleton class.. am i correct in thinking the code you posted was dealing with the singleton in the game instance. But i was hoping for a code example of an actual singleton class.
answered Jun 03 '19 at 05:28 PM
Follow this question
Once you sign in you will be able to subscribe for any updates here