Key Features
- Visual quest editor — a dedicated graph editor for
UQuestDefinitionassets: a green Root node (the quest), blue Objective nodes, and gold Reward nodes, connected and compiled back into the quest data - Objective types — Kill, Collect, Interact, Reach Location — driven by gameplay-tag event matching
- Event-driven progression —
NotifyQuestEventfinds active quests with matching event tags, increments objective progress, completes objectives at target count, and completes the quest once all objectives are done - Retroactive objective satisfaction — via
IQuestStateProvider, other systems (inventory, crafting, skills) can expose player state/actions as quest-relevant event tags without depending on the quest system; the validation system queries all registered providers when a quest is accepted so already-satisfied objectives complete immediately - Quest chains —
PrerequisiteQuestsfor quest-to-quest dependencies - Multiplayer replication —
UQuestLogComponentmust live onPlayerState(not the character) for correct replication
Architecture
UQuestLogComponent— attach toPlayerState; owns accept/abandon/track requests and the player’s quest logUQuestDefinition— data asset describing one quest: ID, display name, description, recommended level, objectives, rewards, prerequisitesAQuestGiverNPC— ready-made quest giver actor; also usable viaIQuestGiverInterfaceon any custom actor (GetAvailableQuests,CanOfferQuestToPlayer)IQuestStateProvider— interface for systems to expose retroactive quest-relevant stateIQuestRewardReceiverInterface— implement onPlayerController(or another actor) to receive and apply quest rewards; called server-side only on completionUQuestValidationLibrary— validation helpersUWorldTimeSubsystem— world-time subsystem used by the quest system- Editor module (
UMQSEditor) — the quest graph, its nodes (Root/Objective/Reward), schema, and asset-browser integration; entirely editor-only
Multiplayer
UQuestLogComponent must be on PlayerState for correct replication — not on the character. Client Blueprint calls go through Request* functions (e.g. RequestAcceptQuest, RequestAbandonQuest), not Server* RPCs directly; quest events should be called on the server or auto-forwarded there.
Integration
UMQS has no hard dependency on inventory, crafting, or skill systems — each integrates through one of two seams:- Retroactive state: implement
IQuestStateProvideron your system to expose event tags for already-true player state (e.g.Event.Quest.Craft.StoneAxefor an item the player already crafted) - Rewards: implement
IQuestRewardReceiverInterfaceon yourPlayerControllerto applyFQuestReward(XP, items, currencies, loot rolls) when a quest completes - Progression events: any gameplay system calls
NotifyQuestEventwith a matchingFGameplayTag(e.g.Event.Quest.Kill.Wolf) to advance objectives
