While this framework doesn’t necessarily mandate a certain implementation pattern, it’s still written with a strong preconceived philosophy of how things (pure virtual functions) should be dealt with internally. That’s separately included inside a section labeled 'Recommended'.
From a high-level perspective,
IGenericCrowdActivityWorker is a native-only interface embodying a crowd controller, capable of beginning/ending Agent Activities on the agents it manipulates.
IGenericCrowdActivityWorker can begin/end an
FCrowdActivity, which represent a high-level task only crowds can perform.
Crowd activities encapsulate a sequence of agent activities.
The logic it executes compliments its relative responsibility down the world-crowd-agent chain by solely being focused on how each crowd activity is carried out, without being aware of its higher strategic purpose.
IGenericWorldActivityWorker is responsible for each crowd activity, and may strategically spawn crowds for a certain purpose only it knows. It's seated in the most leveraged position.
IGenericWorldActivityWorker does not understand how each
FCrowdActivity is carried out. Likewise,
IGenericCrowdActivityWorker does not understand how each
FAgentActivity is carried out.
IGenericCrowdActivityWorker has its own Scoped/Persistent CrowdActivityCognition tags, which are just GameplayTags mapped to the "AgentActivityCognition" base category.
ubyte.dev endorses creating GameplayConcepts extending CrowdActivityCognition that:
Blueprints should never be able to add/remove unencapsulated CrowdActivityCognition tags. It's only permitted through blueprint-exposed concepts that extend CrowdActivityCognition (e.g. CrowdActivityStrategy).