Using Game Singleton Class

Hi All,

I have a UnitManager class, which is an Actor derived class. I’ve set the GameSingleton class to my UnitManager. Calling GEngine->GameSingleton, returns an instance of the UnitManager. So far so good.

Extending the class to Blueprint started causing issues. Now calling C++ functions from the BP instance does nothing, even though it IS the blueprint version that’s being instantiated.

The only way to execute any functionality is to manually create an instance of the UnitManager (not via GameSingleton). Do you know why this might be happening?

you.

Hi Inex, it isn’t recommended that you use the GameSingleton class anymore. Marc from Epic makes a good case for not using it here. The game singleton class exhibits some odd behaviour when using PIE.

The best practice is to use the UGameInstance class which serves the same purpose, and works without bugs. The game instance class is persistent across level transitions, you can see how it is instantiated in this image.

2 Likes

Thanks Lafolie. This class is too high level for my needs and gets created too early in the game process. What I need is a globally, or at least more easily accessible class which manages properties for a few of my actors. Even GameMode happens too early in the instantiation process.

This has honestly been bothering me for a while. I suppose an alternative would be to hold my data in one of my main classes (game mode, player controller or even the pawn) and create a static class to manage that data, because it needs to be called by a lot of my code.

I’ll update this question if this works out.

Hi, I’m not sure the singleton class can derive from AActor. Mine inherits from UObject and it does work fine althought I don’t call c++ functions from the BP instance. Btw, I followed this tutorial from Rama : A new, community-hosted Unreal Engine Wiki - Announcements - Epic Developer Community Forums. Cheers

Hi again. No problem, but I don’t quite follow you.

The game instance class can be accessed from pretty much anywhere. You can derive your own class from it and store references to things in it. It sounds like an ideal candidate for your problem.

Try: http://api.unrealengine.com/INT/API/Runtime/Engine/Kismet/UGameplayStatics/GetGameInstance/index.html

Are we still advised to avoid the GameSingleton class? The docs here, for Unreal 4.27, in the final section seem to be recommending it.

Asynchronous Asset Loading | Unreal Engine Documentation

At the end of the day, you can use whatever you want. Just be aware of the potential issues for using them; so you can avoid pitfalls and problems during development.

For example, some developers will adamantly state not to use Singletons at all. And I would argue that advice is as useful as those who overuse Singletons. The best path is the one which works for your project. The key is understanding both sides, and the reasons why. Find a balance. Singletons are very useful, but do not overuse them.

So in this case, the GameSingleton can work fine for what you want, but can have problems which might cause headaches later one. In other words, just as Marc described, you may reach a point in your development where everything seems fine, then once you go into a Standalone or Packaged version of your project; things might suddenly break from using it.
If you are aware of these problems early on, you can deal with them and avoid them.
If not, you will have some refactoring ahead of you.

As for that article about Asynchronous Asset Loading; it recommends a Singleton but only mentions GameSingleton as an example.
GameInstance can achieve the same thing.

As for this:

I don’t know what is meant by “too high level,” but trying to find a magical object that gets instantiated at the right time isn’t good practice. This sort of dependency can easily break your project at a later point or worse cause unintended behavior.

It’s important to know the order different systems and objects are instantiated at runtime, so you can guarantee things will work when you need them. In other words, you need to control when you want things to be instantiated.

In this case, you can easily use the GameInstance class and just write an Initialization method to load everything when you need it (when the actual game starts), then be sure to also have a Shutdown method to close it all down.

Or better yet, if it’s only needed during actual gameplay use GameMode. Just be aware, if it’s multiplayer and all players need access to this data, the GameMode only exists on the server.

Basically anything you use will have its problems and benefits. It’s important to be aware of these for whatever case you decide to use. Most often you won’t figure those out until after using it.

1 Like