Advantages of a Game Instance Subsystem class over static class or a UBlueprintFunctionLibrary

[ViaCognita]

Hi!

I’m using Unreal 5.4.4. in a game with C++.

I’ve just started to learn about Game Instance subsystem and I’ve been thinking about the advantages of using it instead a class with static methods.

I have this doubt because I have implemented many mathematical calculations grouped in two classes with all of their methods statics.

What are their advantages?

Or I could use a UBlueprintFunctionLibrary, but I’m going to use these methods only in C++.

Thanks!

[IrSoil]

Well, first and foremost, the subsystem is an instantiated class. That means that it’s more than a set of functions since it can have its own internal state that may affect your “static” functions.

That leads to desing where subsystem should wrap set of functionality for reaching particular well-defined goal, not just for a random mess of everything.

For example, roguelike game may have GI-subsystem “run manager”(assuming run consist of several worlds); and most games can have world-subsystems like “time of the day manager”, “npc manager”, etc.

Overall, subsystems are just UE’s singleton-like implementation with automatically controlled lifetime. (About lifetime: most of the time my subsystems are either GI or World -subsystems. Also have one engine-subsystem, but it’s for quite a particular task).
So, you may read about generic singletons applications.

So, overall:
if your goal is to just stuck together a bunch of unrelated static functions (which is seems to be your current case) - definitely go for UBlueprintFunctionLibrary.

If your “system” is stateless and is not going to have a state in future, then i’d likely also go for UBlueprintFunctionLibrary in this case.

upd:

but I’m going to use these methods only in C++.

And if you not going to use any of the functions in blueprints, then you don’t need expose it to bp via UBlueprintFunctionLibrary, just go for native c++ class with static functions, or even just a namespace.