> For the complete documentation index, see [llms.txt](https://malbersanimations.gitbook.io/animal-controller/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://malbersanimations.gitbook.io/animal-controller/malbers-questforge/quest-system.md).

# Quest System

The Quest System is the core gameplay tracking layer of Malbers Quest Forge. It manages the full lifecycle of quests — from availability and activation through to objective tracking, completion, failure, and reward distribution — and connects all of it to your game world through a set of modular, event-driven components.

***

### How It Fits Together

At the heart of the system is the **Quest Manager**, which holds the state of every quest in the game and acts as the authority on what is active, complete, or available. When gameplay events occur — an enemy dies, an item is picked up, a location is reached — they are reported through the **Quest Event Reporter** into the **Quest Event Bus**, which distributes them to all active quest objectives listening for that event type. Objectives evaluate their own completion criteria against the quest's progress data, and the Quest Manager automatically completes quests when all required objectives are satisfied.

Scene-side, a set of **Trigger** components bridge the gap between your world and the quest system. **Quest Trigger** starts, completes, or manipulates quests in response to player actions. **Quest Collectable**, **Quest Interactable**, and **Quest Enemy Reporter** sit alongside your existing Malbers components and report collection, interaction, and kill events automatically without requiring custom code.

Everything is initialised at runtime by **QuestForge Runtime Setup**, which wires shared player and camera references into the system and bootstraps the save state on scene load.

***

### Structure

| Section        | Description                                                                                                           |
| -------------- | --------------------------------------------------------------------------------------------------------------------- |
| **Rewards**    | ScriptableObject-based reward definitions granted automatically on quest completion.                                  |
| **Triggers**   | Scene components that connect world events and player interactions to the quest system.                               |
| **Components** | The core runtime systems — Quest Manager, Event Reporter, Event Bus, and Runtime Setup.                               |
| **Objectives** | Serialized objective types defined on Quest ScriptableObjects — Kill, Collect, Talk To, Go To Location, and Interact. |

***

### Design Principles

* **Data-driven** — Quests and objectives are ScriptableObject assets, not scene objects. They are defined once and referenced everywhere.
* **Event-driven** — No polling. Gameplay events flow through a central bus and are consumed only by objectives that care about them.
* **Decoupled** — Scene components report events without knowing which quests are listening. Quest objectives evaluate progress without knowing what fired the event.
* **Extensible** — New objective types, reward types, and event types can be added by extending the base classes without modifying existing code.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://malbersanimations.gitbook.io/animal-controller/malbers-questforge/quest-system.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.