Recommendation
Use a Function Library for stateless utilities, a Subsystem for one managed service at a defined engine lifetime, and a Component for state owned by individual Actors.
Compare the options
Function Library
Choose when
- The operation is stateless.
- The function does not belong to a gameplay object instance.
- Several systems need the same utility.
Tradeoffs
- Static functions have no managed instance state.
- There is no automatic initialize or deinitialize lifecycle.
- Blueprint
- Create a Blueprint Function Library.
- C++
- Derive from UBlueprintFunctionLibrary and expose static UFUNCTIONs.
Subsystem
Choose when
- One automatically created service is needed per engine lifetime owner.
- The service should initialize and deinitialize with that owner.
Tradeoffs
- Broad access can hide dependencies.
- The selected lifetime must match the stored state.
- Blueprint
- Use the typed Get <Subsystem> node for its owner.
- C++
- Derive from the matching USubsystem class and retrieve it through its owner.
Actor Component
Choose when
- Each owning Actor needs separate state.
- The behavior needs owner events, activation, replication, or ticking.
Tradeoffs
- Every owner has its own instance.
- The Component follows the owner lifecycle.
- Blueprint
- Add the Actor Component to each Actor that needs the behavior.
- C++
- Derive the behavior from UActorComponent.
Requirements
All three options are built into the Engine.
Example
Put vector conversion helpers in a Function Library, a matchmaking coordinator in a Game Instance Subsystem, and health state in an Actor Component.