I have a simple need. I want to create TaskManager which will handle all the logic related to creating Tasks which needs to be done for the player. I have a DataTable with tasks and I want manager to pick up the next one once the existing is completed. What would be the best place to keep this TaskManager?
I thought of having TaskManager blueprint type of Object (don’t need to add it to the world). I want it to be just created in the GameInstance and kept there as a reference. It can do all the task management on it’s own. This will be my solution but I am curious what more experienced people think about it. Where do you keep your manager blueprints and are they just Objects or Actors instantiated in the world?
imho:
make a worldsubsystem. that way you can reload it (world). and access it from wherever (subsystem).
also you have only one in existence.
put the datatable on the game settings (probably a tsoftobjectptr), have the gamemode set it on the subsystem. or self-load it on it.
( if you struggle with the settings, you can put it on the game mode)
Thank you, interesting answer! I haven’t heard about this concept yet. Definitely will do some reading. From what I see it’s only in c++. I only use Blueprints. Is there any alternative approach you could advise which is solely in Blueprints?
im glad you liked it. subsystems are awesome. there are different types of it (game, world, tickable, …).
in bp only i dunno.
there are two least worst options.
create a component and add it to the game manager. then other objects will have to access it through the GM. the lifecycle would be similar to a subsystem. and still you will make sure there’s only 1 of it.
have an actor in the level. usually called “Manager” or smth. then on gamemode get actor of class and save a ref there. other actors access through gamemode (to avoid having to issue a getactorofclass). Problem is you could accidentally add another one, or delete it, or the lifecycle could be a bit of a mess (e.g. the begin plays of other objects might happen before this one). this is useful if you need actor-y stuff (like sounds or objects). though with the component you can have an object reference and then set in the editor.
The benefit of 2 would be if the task manager grows big enough that you want to add other things to it, like components. nested components do not work well in ue (according to my exp up to 5.3 included).
The other benefit is that being in the level is more cleaner what thing is what. instead of hidden components in the gm. though if you have many " subsystems" it might be actually nice to use #1 to have them all grouped neatly in one place.
On both options you could set defaults (eg your datatable) in the editor view (instance default) or in bp edit mode (class default).
On both options i’d centralize accessing the objects through the gm. though in most cases it involves 1 call to getgamemode and 1 cast to your class. cast is costly so i’d cache the result if needed.
i usually prefer #2 since it’s the more flexible and future proof, and i’m disciplined enough to kinda avoid what creates issues. but #1 might be cleaner specially if you have other ppl in your team. and my favorite guideline is K.I.S.S. so id suggest keeping your components simple too, if they grow too big, then they are too big (split them).
Thank you @nande. I went with the second approach as well. I instantiate Manager dynamically from GameMode and safe the reference in it. The chance of it being added again or deleted is then minimal. As you suggested all goes through GameMode.
Previous suggestion with WorldSubsystems is also interesting. Looks very nice and definitely something to look into in the future.
Im happy it helped.
one thing i forgot to mention is that if you go with managers i’d suggest is to not have only one manager for everything. but more 1 manager per feature (e.g. level_manager sound_manager interaction_manager inventory_manager, etc.)