Goal

My objective was to design a quest system that is intuitive for designers, flexible enough to handle multiple quest structures, and powerful enough to manage prerequisites, branching start/end points, and rewards.

I wanted:

• The ability to start, progress, and finish quests from multiple in-world points.

• Support for quest prerequisites such as required levels or completion of other quests.

• A reward system to provide a sense of accomplishment.

• A clear separation of logic and data, making it easy for designers to configure quests without coding.

System Overview

This Quest System was designed to be designer-friendly, modular, and highly adaptable to different gameplay needs. It supports quests with flexible start and end points, prerequisite conditions (level requirements or completion of other quests), reward handling, and full integration with both dialogue and UI systems. The system allows designers to create and manage quests without modifying core code, while still giving programmers fine-grained control over quest logic and state transitions.

Architecture

This quest system separates data, runtime state, and world triggers, and connects them with a light, event-driven flow.

• QuestManager (ScriptableObject, controller)
  Central orchestrator. Reads data from QuestInfoSO, creates/updates the active Quest, listens to step completions, enforces prerequisites, and broadcasts state changes to UI and Dialogue.

• QuestInfoSO (ScriptableObject, data)
  Designer-authored assets containing: prerequisites (level/quest), step prefabs, rewards, and state→dialogue mappings. No code edits required to add or tune quests.

• Quest (runtime state)
  One instance per active quest. Tracks QuestState and current step index; asks QuestManager to instantiate the next QuestStep when progressed.

• QuestStep (prefab logic)
  Self-contained step behaviour (e.g., collect, reach area). On completion, reports back to QuestManager, which advances the quest or marks it ready to finish.

• QuestPoint (base) → QuestTriggerPoint / QuestProgressor (world triggers)
  In-scene interaction points.

  • QuestTriggerPoint: starts/finishes a quest at a location.

  • QuestProgressor: advances mid-quest steps.
    Both notify QuestManager when interacted with; they also update dialogue prompts via the current quest state.

• UI System (output)
  Subscribes to QuestManager events to display title, progress, requirements, and rewards.

• Dialogue System (output)
  Uses the quest’s current state and QuestInfoSO mappings to select the correct dialogue lines; can notify QuestManager when conversations start/finish.

Component Breakdown

QuestPoint (Base Class)

• Abstract class used for quest triggers in the scene.

• Handles state change notifications and dialogue updates when quest progress changes.

• Extended by:

  • QuestTriggerPoint – Handles starting/finishing quests.

  • QuestProgressor – Handles progressing quest steps mid-quest.

QuestInfoSO (Scriptable Object)

Designer-authored quest data:

• Identity: Title & auto-synced ID (OnValidate).

• Prerequisites: Player level, completed quests.

• Steps: Array of step prefabs to spawn in sequence.

• Dialogue: State-based dialogue IDs for start/end points.

• Rewards: Gold, XP (or extend to items).

Quest (Runtime Instance)

• Holds current QuestState and active step index.

• Instantiates the current QuestStep into the world.

• Advances to the next step or signals CAN_FINISH when steps end.

QuestStep (Prefab Component)

• Encapsulates individual step logic (e.g., collect items, reach location).

• Calls back to QuestManager upon completion.

Result

• Fully modular & designer-friendly – Designers can create and modify quests without programming.

• Supports branching logic – Quests can have multiple start/finish points.

• Dynamic prerequisite checks – Ensures quest flow feels natural and respects progression rules.

• Extensible step system – Adding new quest types requires no changes to the core system.

Key Takeaways

• Data-Driven with ScriptableObjects – Separating quest data from logic allowed designers to work independently of programmers, enabling rapid iteration without code changes.

• Modular & Maintainable – Clear separation between quest data, runtime logic, and world triggers ensures the system is easy to extend with new quest types, triggers, or requirements without rewriting the core.

• Event-Driven Decoupling – Dialogue, animations, and UI updates respond to quest state changes through events, removing hard dependencies between systems.

• Flexible Quest Flow – Supports variable start and end points, making the system equally suited for main story arcs, branching narratives, and side quests.

• Integrated Player Feedback – Direct connections between quest states, dialogue, and UI ensure players receive clear, context-sensitive updates and guidance.

• Designed for Growth – Built with scalability in mind, the architecture can expand to handle more complex quest logic, branching conditions, and new gameplay systems without losing clarity.

QuestManager (Scriptable Object Controller)

• Singleton-style SO (loaded from Resources).

• Maintains the quest map; performs state transitions
  (REQUIREMENTS_NOT_MET → CAN_START → IN_PROGRESS → CAN_FINISH → FINISHED).

• Validates prerequisites (level & prior quests).

• Spawns steps, grants rewards, and raises events for UI/Dialogue.

Dialogues for Quest Points