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'.
IGenericWorldActivityWorker embodies a high-level world activity executor, who owns and manipulates a pool of
IGenericWorldActivityWorkercan begin a
FWorldActivity, which represent a high-level event that can occur in a level.
The goal of
IGenericWorldActivityWorker is to operate from a highly leveraged point of view.
To achieve that, it relinquishes awareness about the actual tangible state of the level (where individual agents are, environment queries, etc.), and bases its entire world view from state-indicating (gameplay) occurrences each Crowd Activity worker explicitly broadcasts or notifies its owner.
World Activity Workers can then calculate their next move, and make a decision (based on the strategy it itself follows).
See WorkerGameplayUpshot (plugin) and WorkerActivityStrategy (included by default).
IGenericWorldActivityWorker executes should compliments its relative responsibility down the world-crowd-agent chain by solely being focused on how each
FWorldActivity is rolled out, without dwelling inside a specific Crowd or Agent Activity implementation.
IGenericWorldActivityWorker does not understand how each
FCrowdActivity is carried out. Likewise,
IGenericCrowdActivityWorker does not understand how each
FAgentActivity is carried out.
IGenericWorldActivityWorker has its own Scoped/Persistent WorldActivityCognition tags, which are just GameplayTags mapped to the "WorldActivityCognition" base category.
ubyte.dev endorses creating GameplayConcepts extending WorldActivityCognition that:
Blueprints should never be able to add/remove unencapsulated Cognition tags. It's only permitted through blueprint-exposed concepts that extend Cognition (e.g. Strategy).