Abstract
Problem: How do you implement endgame slides — the narrated sequences that show long-term consequences of player choices — in a way that's practical and scalable?
Approach: Tim Cain draws on his experience shipping endgame slides in Fallout, Arcanum, Temple of Elemental Evil, Vampire: The Masquerade – Bloodlines, and The Outer Worlds, describing the technical implementation, the production realities, and the pitfalls.
Findings: Most slide conditions can piggyback on variables the game already tracks (quest states, achievements, NPC status, faction reputation). The real bottleneck is narrative design ownership — designers must own the system end-to-end because missing slides are invisible bugs. Production timing is also brutal: slides depend on finalized content but compete with bug fixing and optimization at the end of development.
Key insight: Plan your slide list incrementally during development by tagging every major choice point as you build it, rather than scrambling at the end — a lesson Cain learned the hard way on Fallout and applied successfully on later titles.
Choice and Consequence (CNC)
Tim Cain's games are known for deep choice and consequence. The volume of branching content means players can never see everything in a single playthrough — killing an NPC locks you out of their dialogue; rescuing someone prevents their death. Endgame slides exist to surface the long-term consequences that players would otherwise never learn about, and to reward replayability by showing how different choices produce different outcomes.
How Slides Are Implemented
Tracking Variables
Slides are driven by a set of tracking variables checked at game end. The key insight is that most of these variables already exist for other purposes:
- Quest completion/failure states — already tracked by the quest system
- Dialogue path variables — stored by narrative designers to remember player choices
- Achievement flags — recorded during gameplay
- NPC alive/dead status — part of the world state
- NPC and faction reaction states — love, hate, vilify, etc.
Only a small number of additional "slide-only" global variables are needed for decisions that aren't captured by existing systems. Cain notes that if you examine a save game's full state data, you'd be surprised how many slides you could generate without adding any new variables at all.
Narrative Design Ownership
Why Designers Must Own the System
Endgame slides are extraordinarily dependent on narrative designers. They are the only people who know all the major decision points throughout the story and can ensure every significant choice is covered.
The Combinatorial Explosion Problem
Even a simple scenario creates surprising complexity. Cain gives this example:
- Kill Person A → Person B becomes ruler → need a slide
- Kill Person B → Person A becomes ruler → need a slide
- Kill neither → who rules? Maybe they co-rule or marry → need a slide
- Kill both → perhaps an uproar in the kingdom → need a slide
That's four slides from a single choice point. Multiply across an entire game and the matrix grows fast. Designers must carefully track overlapping and interdependent events.
The Invisible Bug Problem
A critical issue with endgame slides: missing slides are invisible bugs. If a slide appears when it shouldn't, QA or players can spot it. But if a slide fails to appear, only the narrative designer who wrote it would know it was supposed to be there. Players simply don't know what they're not seeing. This makes designer-driven QA essential — general QA can catch errors and oddities, but only the content owners can verify completeness.
Cain confirms this happened in several of his shipped games — modders later discovered incorrect slide logic where slides either appeared incorrectly or silently failed to trigger.
Production Realities
The End-of-Development Crunch
By necessity, endgame slides come last. You need finalized quests, NPCs, and areas before you can write slides for them — otherwise you risk wasting work on content that gets cut. But the end of development is also dominated by bug fixing and optimization, which always take priority.
The people with the most free time at the end (narrative designers and artists) are exactly who slides need, but programmers and QA — also critical for slides — are at peak workload. This tension means every Cain game has shipped with fewer slides than he wanted.
Art Is Not the Bottleneck
Slide art is relatively cheap to produce. Options include:
- Simple 2D illustrations
- Screenshots from the game (e.g., a thriving town vs. a burning town)
Players care more about what the narrator says than the visual, as long as the image supports the narration. The real cost is always on the narrative design side.
Best Practice: Plan Incrementally
Cain's recommendation for developers planning endgame slides:
- During development, at every choice point, ask: does this have an immediate consequence, or a long-term one?
- If the consequence is long-term, write down what slides you'll need for each outcome of that choice
- At the end of development, review your list — most conditions will map to existing variables
- For the few that don't, go into dialogue or script and set a tracking variable at the decision point
This is the evolution Cain describes across his career:
- Fallout — scrambled to add slides at the end
- Arcanum, Temple of Elemental Evil, Vampire — thought about it ahead of time
- The Outer Worlds — planned for slides from the very beginning
Slides as a Bookend
Cain frames endgame slides as a bookend to the game's opening — a companion piece to how you choose to begin your game. Together, the opening and the ending frame the player's entire journey and give narrative closure to the choices they made along the way.
References
- Tim Cain. YouTube video. https://www.youtube.com/watch?v=zjtctCu6VoI