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 problem
Asgard's Wrath 2 was one of the most ambitious VR titles ever made — 60+ hours of main and side story content built on an inherited quest structure that wasn't designed for that scale. 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
What I did
After shipping AW2, I took point on making sure the next project didn't repeat the same late-production pain. A GDC talk from Respawn's Jedi Survivor team describing a similar problem came across my radar, and I recognized it as directly applicable to what we'd experienced. I brought it to engineering as a starting point and drove the design vision for a new narrative system architecture — defining how content would be structured, chunked, and sequenced. In practice this meant working within and around engineering's existing constraints, including an existing puzzle state machine architecture, to find solutions that worked for both sides.
I also pushed for an additional layer to the architecture — a story graph that sat above the individual progression graphs and level scripts, connecting them into a single visualizable spine. The reasoning was threefold: it gave leadership a clear view of how everything connected without needing to dig into individual level logic; it created a reliable handoff point if implementers changed mid-production; and deliberately, it introduced a small amount of overlap between narrative and level designers — requiring them to coordinate on how their content connected at the story graph level. The friction was intentional. I wanted collaboration to be built into the workflow rather than dependent on people remembering to talk to each other.
How I did it
Starting with the Jedi Survivor world state system as a reference point, I mapped existing AW2 content in Figma to simulate how it would be authored in the new system — identifying structural patterns and edge cases before anything was built. Engineering worked concurrently to develop graph tooling.
From there, I collaborated with gameplay engineering to define how graph data would connect to in-game level logic, then we built a mock test level to validate the architecture end-to-end — iterating with narrative engineering until the logic held.
As the test level stabilized, I brought the broader design team in — working directly with level and narrative designers to visualize how their content would need to be structured in the new system and soliciting feedback on the workflow. Once the test level represented a solid first pass, we began applying the system to real content, using both Figma and in-engine implementation to surface new issues and iterate.
The new architecture — progression graph as source of truth, story graph as navigation layer, switchboards as standardized implementation
The results
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 classes of issues no longer required manual intervention. By the time the project entered full production, the team had fully adopted the system.
Onboarding wasn't instant — designers tended to internalize the new content structure once their own levels went through the process rather than in the abstract — but the system held up under real production conditions. A checkpoint shortcut system we developed collaboratively — allowing reviewers to jump to any point on the progression graph and arrive in the correct player state — made playtesting and leadership reviews significantly faster. Engineering owned the implementation; the design requirement came from understanding exactly what the team needed to iterate quickly.