Where to Store Market Orders for NPC Market and NPC Quests for the Quest Log

Yes, I ended up creating the following structure where a central board manager manages and filters all quests and the quest object manages all quest functions like incrementing goals, sending rewards, keeps track of issuer and accepting actor so that the actors themselves never need to have a reference to the quest object.

ACTOR_BOARD_MANAGER - with an array of OBJ_QUESTs, can CRUD quest list and return data to other actors through functions
ACTOR_NPC - with an inventory component, can ask the BOARD_MANAGER to do things
OBJ_QUEST - contains all variables and functions related to an order and event dispatchers that get called (ex. OnOrderFilled) including the issuing and accepting actor, reward etc.
PAWN_PLAYER - can accept orders/quests

ACTOR_NPC has inventory, desires, quirks etc., anything I want to code normally for my game. The ACTOR_NPC tells the ACTOR_BOARD_MANAGER to create an OBJ_QUEST to store whatever it wants on the BOARD_MANAGER actor, which acts like a singleton database in a streaming level (would use GameInstance if I wasn’t using a persistent streaming level), with the SELLER marked in the IssuingActor variable. Seller does not keep track of its own postings, the board manager will return postings with a specific variable filtered.

So, If the PLAYER or any NPC accepts the order, the BOARD just adds their actor to the “AcceptingActor” variable. Then if the player wants all their quests quests in their UI, for example, the Player UI just asks MISSION_BOARD to give it all quests with where AcceptingActor = PAWN_PLAYER and posts the returned data in the UI.

So, If I want to create some arbitrary quest sub-type where the AcceptingActor say needs to add 10 orbs to a florb, I write the Add Orb to Florb function in the Actor, then every time the Orb function is called in the actor it gets the mission board and asks it to increment all quests where QuestType = OrbInFlorb and AcceptingActor = Self. When the quest has incremented 10 times OBJ_QUEST calls OnQuestFulfilled, distributes rewards to the AcceptingActor, takes the inventory from the IssuingActor etc. BOARD_MANAGER is bound to the OnQuestFulfilled dispatch and removes the quest from the array.

This way NPCs, Players etc. never need to know what the quest object is, they just talk to the board manager and ingest the data it sends back as a snapshot. So an NPC on an Orb Florb quest would just know from the board manager that the most valuable thing it could do is search for orbs, while the player can see a list of quests without their player pawn needing to mess with the object itself.

1 Like