Case Study — IC6
Narrative System Architecture
Sanzaru Games / Meta · Unannounced title · 2024–present
Role: Senior Designer IC6 · Discipline: Narrative Systems, Technical Design · Tools: UE5, Blueprint, Figma
The brief
I was a level designer on Asgard’s Wrath 2 (AW2) — where I first encountered the narrative pipeline problems that eventually led me to narrative systems design.
AW2 is a 60+ hour VR RPG built on a quest structure that didn't scale with the amount of content planned. During production, I took point on keeping the narrative pipeline functional and absorbed the technical debt so the rest of the design team could keep delivering. This case study is about what I did on the next project to make sure that job didn't need to exist.
The problem
AW2 was built on an inherited quest structure that made it easy for designers to set up objectives, but it wasn’t designed for the scale or amount of planned content. As the narrative evolved during production, reordering quests, modifying objectives, and integrating new content created cascading technical issues: broken save files, orphaned references, and implementation work that had to be redone each time the story changed. The inherited pipeline turned normal narrative iteration into a production liability.
The inherited save structure — and what happened when objectives changed mid-production
Designers also had too much flexibility in how they implemented quest logic — using data tables, in-level quest objects, or Blueprint scripts interchangeably. With no standardized location, soft references broke silently and debugging required checking three different systems.
Three implementation paths, any combination active in the same level — with no single source of truth
The approach
After shipping AW2, I drove the design vision for a new narrative system architecture on the next project to define how content would be structured and sequenced. A GDC talk from Respawn’s Bobby Wilkinson describing a similar problem gave us a starting point. In practice, the design required working within engineering’s existing constraints, including a puzzle state machine architecture, to find solutions that worked for both sides.
To validate the design before anything was built in engine, I mapped existing AW2 content in Figma to simulate the new authoring structure and surface edge cases. Engineering developed graph tooling concurrently. From there I collaborated with gameplay engineering to define how graph data would connect to in-game level logic, and we built a mock test level to iterate with narrative engineering until the logic held.
Mapping AW2 content in Figma to simulate the new authoring structure and surface edge cases before anything was built in engine
I introduced a story graph as the single visualizable spine of the architecture, connecting individual progression graphs and level scripts. It’s visible as the top layer in the diagram below. The reasoning was threefold: it gave designers and leadership a clear view of how everything connected; it created a reliable handoff point if implementers changed mid-production; and deliberately, it required narrative and level designers to coordinate where their content connected at the story graph level. The friction was intentional. I wanted collaboration built into the workflow instead of hoping that people remembered to talk to each other.
The new architecture: progression graph as source of truth, story graph as navigation layer, switchboards as standardized implementation.
As the test level stabilized, I brought the broader design team in, worked directly with level and narrative designers to map how their content would need to be structured, and solicited feedback on the workflow. We then applied the system to real content, using both Figma and in-engine implementation to surface new issues and iterate. A checkpoint shortcut system developed collaboratively with engineering let content creators and reviewers jump to any point on the progression graph and arrive in the correct player state, making iteration and playtesting significantly faster.
The results
Iteration time cut by more than half. No broken save files. No orphaned references. One place to look when something went wrong.
The new system eliminated the broken save files and orphaned references that had plagued AW2 production. A self-fixing feature drawn from the Jedi Survivor architecture meant those types of issues no longer required manual intervention. Onboarding wasn’t instant. Designers didn't fully internalize the new content structure until their own levels went through the process. But as we entered full production, the team had fully adopted the system. The job that had consumed so much of late-stage AW2 production didn't need to exist anymore.
Thanks to the gameplay and narrative engineering teams at Sanzaru for building the graph tooling and other tools that made this system possible.