Abstract
Problem: How should game designers think about and plan for emergent gameplay — player behaviors that arise from game mechanics but weren't explicitly designed?
Approach: Tim Cain draws on his experience designing Fallout and Arcanum, sharing specific examples of emergent gameplay discovered during development and contrasting his systemic approach with the scripted approach he encountered in other RPGs.
Findings: Emergent gameplay naturally arises when designers build low-level, generic systems that interact with each other. Rather than fighting it, designers should embrace it by writing general code, adding generic dialogue responses for unexpected outcomes, and accepting that players will always find solutions no one anticipated.
Key insight: Build systems, not scripts — if your mechanics are low-level and general enough to interact with each other, emergent gameplay will happen on its own, and the designer's job is to react to it gracefully rather than prevent it.
1. Definition
Tim defines emergent gameplay as things a player can do that arise from the mechanics but weren't necessarily part of those mechanics or explicitly planned for by the designers. He traces his love for it back to tabletop RPGs, where it happens organically — players talk their way out of combat encounters, combine abilities in unexpected ways — and he wanted to recreate that feeling in computer RPGs.
2. Not Everyone Loves It
Tim acknowledges that many people on his teams did not like emergent gameplay. It causes unpredictability for:
- Narrative designers who need to write story and dialogue
- Systems designers who need to set flags and plan reactions
- QA who need to test for expected behaviors
Letting players mix up mechanics and do unplanned things makes everyone's job harder. Tim considers this a "good kind of difficulty" — challenging but worth it, because when you add reactivity to emergent behaviors, players love it.
3. The Fallout Pickpocket Story
The most famous example Tim shares: when implementing pickpocketing in Fallout, he reused the bartering UI with a flag. This meant the system worked bidirectionally — players could not only take items from NPCs, but also put items into their inventory.
QA discovered that players could plant live grenades on NPCs, walk away, and watch them explode. The team decided to leave it in and eventually built quests around it (planting incriminating evidence). This is emergent gameplay at its best — discovered before shipping, embraced, and expanded upon.
3.1. Other Fallout Emergents
- Explosives + doors: Once explosives could damage anything with hit points, and doors/locks were given hit points, players could blow open any breakable door. No special-casing needed — it was systemic.
- Speedrunning the water chip: The team never tracked whether you actually obtained the water chip, so speedrunners can skip the entire main quest line and go straight to killing the mutant army and the Master.
4. The Systemic Approach: Arcanum's Design Philosophy
Before writing a single line of design for Arcanum, the team established a principle: provide a rich enough set of low-level mechanics that interact with each other, and emergent gameplay will just happen by itself.
4.1. The Lock Example
Tim illustrates with locks. A well-designed lock system needs only two properties:
- Key ID — what key opens it
- Pick difficulty — how hard it is to lockpick
If the locked object also has hit points, and hit points reaching zero marks it as "open," then any lock on any destructible object can be blown open, beaten open, or otherwise destroyed. No special cases needed.
The key can be placed anywhere — a guard's pocket (pickpocketed), another container (stolen), wherever. The system handles it all generically.
5. What Tim Hates: Scripted One-Offs
Tim contrasts this with what he calls scripted solutions — a specific lock that only opens with a specific nearby screwdriver. He hates these because:
- They teach the player something non-general they can't use anywhere else
- They make players hunt for unique puzzle solutions instead of applying their toolkit of skills
- They betray the player's trust in the game's systems
5.1. The Raise Dead Story
Tim shares a personal frustration with "a very popular RPG in the '90s." He was sent to find an NPC who turned out to be dead. Playing a cleric with a Raise Dead scroll (which stated it worked on anyone dead up to 9 days, and this person had been alive 3 days prior), he tried to resurrect them — "Invalid Target."
The game wasted his scroll, cost him 20 minutes of gameplay on a reload, and violated its own rules. The quest had exactly one solution: bring back the dead body and report failure.
Tim's reaction as a designer: Why did they give me that scroll and then make a quest that doesn't follow its own rules?
6. How to Handle Emergent Gameplay You Can't Predict
Tim's practical advice for covering emergent gameplay you didn't specifically plan for:
- Write generic responses. If a quest NPC sends you to find someone, add a dialogue branch for "what if the player brings them back alive somehow?" Even if you can't imagine how, just write: "Oh my goodness, you rescued him! I don't know how you did it, but here's a reward."
- Don't beat yourself up. If your rule set is rich enough, you literally cannot plan for everything players will do. "Players are clever little devils."
- Layer your reactivity. Write specific lines for things you anticipate, then add general fallback reactions for outcomes you didn't predict.
7. Tim's Summary
Three principles for emergent gameplay:
- Make code low-level and generic — systemic solutions that work everywhere, not scripted one-offs
- React to everything you can — specific lines where possible, general fallbacks where not
- Relax and let players be smart — rather than fighting emergent behavior, embrace it; it's fun to see how players meet your challenges in ways you never imagined
"Bottom line: Tim likes emergent gameplay."
8. References
- Tim Cain. YouTube video. https://www.youtube.com/watch?v=jWEuSV_nbfA