SUQS (Steve’s Unreal Quest System) is a free, open-source quest system plugin for Unreal Engine by Steve Streeting (sinbad). It’s data-driven — you define your quests in JSON, load them into DataTables, and the plugin handles progression, completion tracking, and state management.
I want to give a genuine thanks to people like Steve who build and share tools like this. Making a game is already a huge undertaking, and having access to well-made, freely available plugins makes it possible to focus on the actual game instead of reinventing infrastructure. The UE5 community is better because of people who open-source their work.
Why I Chose It
I needed a quest system for The Break of Day, but I didn’t want to build one from scratch. Quest systems are one of those things that seem simple until you’re three weeks in and dealing with edge cases around sequential objectives, save/load, and state rollback.
SUQS does exactly what I needed:
- Quests defined as JSON — no Blueprint spaghetti, easy to version control
- Hierarchical structure: Quest → Objectives → Tasks
- Sequential or parallel task ordering
- Auto-accept quests (start immediately without player action)
- Full C++ and Blueprint support
How Quests Are Defined
Each quest is a JSON file that gets imported into a DataTable. Here’s a simplified version of one of my quests:
{
"Identifier": "LeaveCargoControlRoom",
"bPlayerVisible": true,
"Title": "Leave Cargo Control Room",
"DescriptionWhenActive": "Activate the terminals and leave the area.",
"AutoAccept": true,
"Objectives": [
{
"Identifier": "O_ActivateTerminals",
"Title": "Activate Terminals",
"bSequentialTasks": true,
"Tasks": [
{ "Identifier": "T_ActivateTerminal1", "Title": "Activate Terminal 1", "TargetNumber": 1 },
{ "Identifier": "T_ActivateTerminal2", "Title": "Activate Terminal 2", "TargetNumber": 1 },
{ "Identifier": "T_ActivateTerminal3", "Title": "Activate Terminal 3", "TargetNumber": 1 }
]
},
{
"Identifier": "O_LeaveArea",
"Title": "Leave the Area",
"Tasks": [
{ "Identifier": "T_LeaveArea", "Title": "Leave Cargo Control Room", "TargetNumber": 1 }
]
}
]
}The structure is straightforward — a quest has objectives, objectives have tasks. bSequentialTasks: true means Terminal 2 won’t activate until Terminal 1 is done. Each task has a TargetNumber — how many times it needs to be completed (useful for “collect 5 items” type tasks).
SUQS uses NSLOCTEXT macros in the actual JSON for localization support, so titles and descriptions are ready for translation out of the box.
Integration in The Break of Day
The integration is minimal. I created a USuqsProgression instance in the Game Instance — this is the central object that tracks all quest state:
void UArcShooterGameInstance::Init()
{
Super::Init();
QuestsProgression = NewObject<USuqsProgression>(this, TEXT("SuqsProgression"));
QuestsProgression->InitWithQuestDataTables(ListOfAllQuestsAvailable);
}ListOfAllQuestsAvailable is just an array of DataTables exposed in the editor. Each DataTable points to the JSON quest definitions. When the game starts, SUQS loads everything and is ready to track progress.
From gameplay code, completing a task is a single call — find the progression object, tell it which task just happened, and SUQS handles the rest (marking objectives complete, advancing sequential tasks, completing the quest when all mandatory objectives are done).
Quest-to-Dialogue Bridge
One thing I built on top of SUQS is a bridge between quests and dialogue. The Break of Day uses SUDS (Steve’s Unreal Dialogue System — same author) for NPC conversations. I needed a way to trigger specific dialogue when a quest task completes.
The solution is a data asset — UASQuestsToDialogueDataAsset — that maps (QuestId, TaskId) pairs to SUDS dialogue scripts. When a quest task fires, the game looks up whether there’s a dialogue associated with it and plays it. The data asset includes editor validation that catches duplicate entries before they become runtime bugs.
What Makes SUQS Work Well
The thing I appreciate most is that SUQS stays out of the way. It doesn’t force an architecture on you. It doesn’t need GAS or any specific framework. You store quest definitions in JSON, initialize the progression object, and call into it when things happen in your game. The plugin handles the bookkeeping — which tasks are active, which are complete, whether an objective’s prerequisites are met.
For a solo developer, that’s exactly the right level of abstraction. I don’t need a visual quest editor or a node graph. I need a system that tracks state correctly and lets me define quests in a text file I can diff in git.