well, i can read this question in two ways:
- “Gameplay” systems, that is systems that isn’t tied to particular actor while not quite fitting into gamemode or gameinstance, like time-of-the-day system or some item-drop-manager.
Those are goes into Subsystems. note: this doc is lacking: UWorldSubsystem is also a thing and is missing from doc
If you ever question yourself “should i make a singleton for this”, in UE the answer is always “definitely use ue’s subsystems instead”
- Generic utility functions, that mostly consist of a single function, not assembling into a particular system, and have no need to store any data, like custom LineOfSight check,
IsAlive(unit),GetAllUnits()or custom math likeIsPointOnScreen().
I’m having those stored as a static functions in a single class derived from UBlueprintFunctionLibrary. Well, it’s mostly a bloated junkyard of a 3k lines in sum now, but it does its work well enough.
Can also be structured into a several classes, but i find using the single generic UUtils easier than several different UKismetRenderingLibrary, UGameplayStatics, UKismetSystemLibrary, etc. Though this ones have a good reason to be separated, it doesn’t makes things easier.
Also, you does want to derive it’s from UObject(i mean UBlueprintFunctionLibrary), so you can easily expose your utilities to blueprints
Another few notes:
Generally this sounds like a candidate to be implemented like an Actor’s Component
On the other side, this exact task, unless you wan’t to make something custom, in 3d game is usually handled by Animation’s root motion (if your motion for specific animation is static. If it’s dynamic, like charging to enemy, it’s another thing)