Please Wait
Loading Providence Studios
Please Wait
Loading Providence Studios
Devblog
Phase 4 Steps 3 through 6 landed today. The mission system now has a full lifecycle from start to resolution — and when a mission ends, the result is durable. It persists to save, survives load, and is queryable by dialogue conditions and anything else that needs to know what happened.
Phase 4 Steps 3 through 6 landed today. The mission system now has a full lifecycle from start to resolution — and when a mission ends, the result is durable. It persists to save, survives load, and is queryable by dialogue conditions and anything else that needs to know what happened.
Objectives start inactive and have to be explicitly activated — nothing fires automatically on mission start. Once active, they can be completed or failed, and the system broadcasts the change to anything listening. One flag on the objective definition handles the shortcut case: if an objective is marked as the one that completes the mission, finishing it ends the mission immediately. The full aggregate check fires after every completion — if all required objectives are done, the mission resolves on its own.
Failure has the same logic running the other direction. If a required objective fails, the mission ends as failed. Optional objectives can fail silently — the mission keeps going.
The context layer carries a snapshot of the mission's situation throughout its lifetime. When the mission ends, the resolution record is sealed — which objectives completed or failed, the final status, which branch resolved. That record transfers to the narrative subsystem's mission outcomes map, where it joins the save file and lives permanently alongside the rest of the player's story state.
Dialogue conditions can already gate on mission outcome tags. Now the baseline booleans are there too — did this mission resolve, did it complete, was it a soft fail — so future scenes can respond to what happened even without authored outcome tags.
The objective tracker UI is fully operational. Two new widget C++ bases — one for the tracker container, one for individual objective rows — are wired to the mission subsystem's live delegates. When a mission starts the tracker rebuilds completely. When a single objective changes only that row updates. When the mission ends the tracker clears.
The Blueprint side is complete too. WBP_ObjectiveEntry handles the per-row display: a checkbox driven by objective status, a text label, a description line, an optional badge, and per-status color coding. WBP_ObjectiveTracker manages the live list — finds existing rows and updates them in place, creates new rows for objectives it hasn't seen, and adds each row to a Vertical Box that auto-sizes as objectives come in. BP_ProclaimGameModeBase spawns the tracker on BeginPlay and adds it to the viewport.
The first test mission asset was built and validated end-to-end today. DA_Mission_Test — three objectives, one optional, one that completes the mission on its own — drove the full pipeline in PIE. Title renders from the asset, objectives populate on mission start, individual rows update on status change, the tracker clears when the mission ends. The system is functional.
Share This Post
Send this article to your audience or copy the direct link.
X, Facebook, Reddit, LinkedIn, or copy link
Devblog Updates
Get milestone-focused devblog posts by email. This list is separate from the studio blog and can be managed independently.