How to Build a Quest System in Unreal Engine: Objectives, Progress and Journal
A quest system is a small state machine fed by game events. If you design the data and the events first, the journal UI and the save system almost write themselves.
1. Describe quests as data
A quest is a title, a description and an ordered list of objectives. Store each quest in a Data Asset, and give each objective a type (collect, reach, talk, kill, interact), a target id and a required count. Designers can then add a quest without touching Blueprints or C++.
2. Let the game push events, never poll
Do not check "does the player have 3 herbs?" every frame. Instead, when something happens (item picked up, enemy killed, door opened, trigger entered), send one small event such as "collected, herb, +1" to a quest manager. The manager finds the active objectives that care about that event and advances them. Gameplay Tags make a good event vocabulary because they are cheap to compare and easy to author.
3. Keep the manager in the right place
A Game Instance Subsystem (single player) or a component on the Player State / player controller (multiplayer) survives level changes and respawns. The manager owns the runtime state: which quests are active, completed or failed, and the progress of each objective.
4. Define clear states
Use a small set: Not started, Active, Completed, Failed. Objectives follow the same idea. Write down what unlocks the next objective (all in order, or any order) so quests with parallel goals do not need special cases.
5. The journal is only a view
The journal UI should read from the manager and refresh when it broadcasts "quest updated". Do not store progress in widgets. This also makes it easy to show a tracked quest on the HUD, a map marker, or a notification without duplicating logic.
6. Save progress by id
Save quest ids, state and each objective's count. On load, rebuild the runtime state from the data assets. If you later rename a quest, keep its old id working or write a small migration.
7. Multiplayer
Decide whether quests are per player or shared by the party. In both cases the server should validate events and own progress; clients only receive the result for display. Replicate to the owning client rather than to everyone.
Common mistakes
- Hard-coding quest logic in level Blueprints. It becomes impossible to reuse or test.
- Polling in Tick. It scales badly and hides bugs.
- Storing text in code. Keep names and descriptions in the data asset so they can be localised.
Want a working base?
If you would rather start from a ready-made quest and journal setup, check the related products below and read each listing for what it includes.
