Summary
The Legend of Zelda: Breath of the Wild (Nintendo EPD, 2017) is an open-world action-adventure game that is widely studied as a model of systemic design: instead of building objects for specific puzzles, Nintendo gave almost everything in the world consistent physical and “chemical” properties and let the player combine them. Its technical director, Takuhiro Dohta, explained at GDC 2017 that the game rests on two engines: a physics engine, “a rule-based movement calculator”, and a chemistry engine, “a rule-based state calculator” (Dohta, Breaking Conventions with The Legend of Zelda: Breath of the Wild, GDC 2017, see source-botw-breaking-conventions-gdc-2017). Director Hidemaro Fujibayashi called the result multiplicative gameplay: player actions, the field and reactive objects multiply together, so a few rules produce a very large space of solutions (Fujibayashi, same talk).
Release facts
| Developer / publisher | Nintendo EPD / Nintendo |
| Director / producer | Hidemaro Fujibayashi / Eiji Aonuma |
| Technical director / art director | Takuhiro Dohta / Satoru Takizawa |
| Release | 3 March 2017, Wii U and Nintendo Switch (a Switch launch title); Nintendo Switch 2 Edition 5 June 2025 |
| Physics middleware | Havok, heavily customised (“game physics”) |
| Sales | 34.06 million on Switch as of 30 June 2026 (Nintendo, Top Selling Title Sales Units); about 1.70 million on Wii U |
| Major awards | Game of the Year at The Game Awards 2017, the D.I.C.E. Awards 2018 and the Game Developers Choice Awards 2018 |
| Sequel | The Legend of Zelda: Tears of the Kingdom (12 May 2023) |
Sources: the GDC 2017 talk for roles and Havok; Nintendo’s investor-relations sales table (checked 2026-10-25) for Switch sales; the English Wikipedia article on the game (checked 2026-10-25) for the remaining dates, awards and Wii U sales.
Why it matters
It breaks the convention of the bespoke puzzle. Fujibayashi listed the Zelda conventions that made earlier games “passive”: events that need a set path, walls you cannot get round because of level design, and puzzle objects “made specifically for those puzzles”, whose solutions were all online anyway. He called that approach “development by addition” and said it would not scale to a huge world (Fujibayashi, Breaking Conventions with The Legend of Zelda: Breath of the Wild, GDC 2017, see source-botw-breaking-conventions-gdc-2017).
It makes the world, not the puzzle, the unit of design. The team filled the world with situations and goals. Each has an intended answer, but the designers wanted players to enjoy “thinking up and trying solutions on their own”, and counted roundabout solutions and shortcuts as “the correct way to play” (Dohta, same talk). This is second-order-design at open-world scale.
It shows that consistency produces curiosity. Dohta’s central observation: “If you unify your game world with a set of consistent physics rules, the player will come up with ideas for all sorts of things they want to try.” Once you see a log float, you want to ride it; once you can lift a metal plate, you want to drop it on an enemy (Dohta, same talk).
The architecture behind the emergence
This is the direct answer to “what architectural decisions made the interactions emergent?“. The points below are what the developers said; the interpretation follows in Implications for students.
1. Split the simulation into movement and state
Dohta reduced an action game to three parts: collision, movement and object state. Collision and movement are physics; state changes are chemistry. Each gets its own rule-based engine, and they connect at a single seam: “given the right situation, elements can also generate energy and impact the physical world” (Dohta, same talk). Thumbsticks reported his example of Link using a leaf to blow a raft along (New, “Breath of the Wild, science, and clever little lies”, Thumbsticks, 2017).
2. The chemistry engine: elements, materials, three rules
| Term | Definition (Dohta) | Examples |
|---|---|---|
| Element | Something without a constant solid form; carries change | Fire, water, ice, electricity, wind |
| Material | A solid thing with a state that elements can change | Trees, rocks, weapons, the player character |
- Elements can change the state of materials. Fire burns the leaves off a tree.
- Elements can change each other’s state. Fire goes out when it meets water.
- Materials cannot change each other’s state. Two solid objects touching do nothing chemically; any effect has to go through an element or through physics.
Electricity and wind are not chemistry in a textbook, “but in the chemistry engine, you bet they are”: apart from rigid-body dynamics, every natural phenomenon is modelled as chemistry, because that keeps the model simple. Dohta stressed that the goal was not to simulate chemistry but to build “a state calculator for all these objects that are connected to one another” (Dohta, same talk). One documented consequence: metal objects attract lightning during thunderstorms (Wikipedia, The Legend of Zelda: Breath of the Wild).
3. The same rules for everyone
Dohta lists “even the player character and weapons” as materials alongside trees and rocks (Dohta, same talk). The player is therefore not a special case: the rules that act on a crate also act on the player and on the things the player carries, which is why metal equipment can draw lightning just as a metal crate can. Arguably, this symmetry between player, enemies and props is what lets a player predict an outcome from one observation and reuse that knowledge everywhere.
4. Physics that lies consistently
Dohta calls game physics “false physics or liar’s physics”: it bends reality for control, responsiveness, performance and design, but keeps enough real-world behaviour to build “trust between the player and the game”. The team used Havok for robust simulation (the brief was that you could roll the starting rock to the final boss) and spent their own effort on the lies: Stasis objects “work hard” to stay still, Magnesis is “something like magnetism”, climbing is a dynamic constraint between Link and any surface (so moving objects and giant enemies are climbable), a felled tree swaps to a log object, and logs float with a made-up buoyancy model (Dohta, same talk).
5. Traversal that removes walls
Fujibayashi’s first experiment was to make every wall climbable, turning boundaries into “another optional path”, then to add gliding so that “once you climb, you can fly to wherever you want”. He called gliding “the crucial ingredient” for freedom, and this pairing of a player action with the whole field was where the idea of multiplication started (Fujibayashi, same talk). Nintendo staff and the press have also described this structure as “open-air” rather than “open world”; that term does not appear in the GDC talk, so treat it as a label rather than a design principle.
6. Prove the idea small, first
Before committing, the team built a 2D, NES-style Zelda prototype with no puzzles: a river, some trees and one rule, “There’s a situation and a goal. Can you reach it?” It was 3D underneath and ran early versions of both engines (Fujibayashi and Dohta, same talk; also Vaz, Zelda Universe, 2017). See prototyping.
Art supports the systems
Art director Satoru Takizawa looked for “art that makes it easy to lie”: readable and responsive, but realistic enough that players can “intuitively suggest possible physics and chemistry game play based on [their] own experiences in the real world”. The highly stylised Wind Waker look told lies that were “too big” for that, which led to the slogan “refreshing and full-flavoured” (Takizawa, same talk).
Multiplicative versus additive design
| Additive (“development by addition”) | Multiplicative | |
|---|---|---|
| Unit of content | A puzzle with objects built for it | A situation and a goal |
| Where interactions live | Inside each puzzle’s script | In global rules every object obeys |
| Cost of a new object | Its own puzzle logic | Its tags and properties |
| Solutions | Usually one, findable online | Many, including unintended ones |
| Player stance | Passive: find the designer’s answer | Active: experiment and improvise |
The table summarises Fujibayashi’s contrast; the column wording is this wiki’s.
Implications for students
The following are interpretations for student projects, not claims made in the talk.
- Design the rules before the content. Write the interaction table (what each element does to each material tag) before building levels. If a level needs a special case, first ask whether a new tag or rule would do the job everywhere.
- Give the player no exemptions. If the player, enemies and props share one
ChemistryBody-style component, every rule the player learns on a crate also works on an enemy, and the reverse. - Keep state separate from motion. Let the physics engine move things and a small state system decide what they are (burning, wet, frozen). Connect them at one or two clear points, such as wind applying force.
- Keep the rule set small and readable. Three rules and five elements are enough to surprise players. Every new rule multiplies the cases you have to playtest; see inherent-vs-emergent-complexity.
- Make properties visible. Takizawa’s art direction is a reminder that systemic play only works if players can read which things are wooden, metal or wet.
- Prototype the system on its own. A grey-box 2D scene with a few tagged objects tests whether the rules are fun before any art exists.
A Unity-scale element and material system
A small 2D version of the three rules fits in three scripts. The rule table below is this wiki’s illustrative example, not Breath of the Wild’s actual data.
| Element arrives at a material | Result |
|---|---|
Fire → Flammable | Burning; after a few seconds Burnt; while burning it passes Fire to neighbours |
Fire → Frozen / Wet | Wet / dried back to Normal |
| Water → anything not burnt | Wet (puts out Burning) |
Ice → Freezable or Wet | Frozen |
Electricity → Conductive or Wet | Electrified briefly, then back to its previous state |
Wind → Light with a Rigidbody2D | pushed (the hand-off to physics) |
| Element meets element (rule 2) | Water on Fire → nothing; Fire on Ice → Water; Ice on Water → Ice |
The whole of rule 1 lives in one static method, so every object obeys it:
public static MaterialState Apply(Element element, MaterialTags tags, MaterialState current)
{
if (current == MaterialState.Burnt) return current; // burnt is final
return element switch
{
Element.Fire when current == MaterialState.Frozen => MaterialState.Wet,
Element.Fire when current == MaterialState.Wet => MaterialState.Normal,
Element.Fire when tags.HasFlag(MaterialTags.Flammable) => MaterialState.Burning,
Element.Water => MaterialState.Wet,
Element.Ice when tags.HasFlag(MaterialTags.Freezable) || current == MaterialState.Wet
=> MaterialState.Frozen,
Element.Electricity when tags.HasFlag(MaterialTags.Conductive) || current == MaterialState.Wet
=> MaterialState.Electrified,
_ => current,
};
}Rule 3 is enforced by the shape of the code: a ChemistryBody never edits another body’s state. A burning body calls Physics2D.OverlapCircle and passes Element.Fire to its neighbours’ ReceiveElement method, so fire spreads through dry grass but a crate resting on a crate does nothing. The same component goes on the player, so the player can catch fire too. An ElementSource trigger (campfire, pond, gust) applies its element to whatever stands in it, and its Expose method applies rule 2 (throw water on the campfire and it goes out).
The full, compiled example (Unity 6, 2D physics; one MonoBehaviour per file, as Unity requires) is in three files: ChemistryRules.cs, ChemistryBody.cs and ElementSource.cs. For the trigger set-up see unity-collider2d-and-triggers, and for forces see unity-rigidbody2d. Hooking visual effects and damage to the StateChanged event follows the observer-pattern; the tags are a [Flags] enum (see csharp-enums).
Other engines. Godot can express the same split with groups or exported flags for material tags and Area2D nodes for element sources. In Unreal, Gameplay Tags are a natural fit for material tags and states. The architecture (tags plus a global rule table plus a narrow physics hand-off) carries over unchanged.
Design concepts illustrated
- emergent-design: property-tagged objects plus global interaction rules
- game-atoms: atoms designed to multiply rather than add
- inherent-vs-emergent-complexity: three rules, a very large possibility space
- systemic-depth-elegance and elegance: depth from a small, consistent rule set
- second-order-design: authoring situations and goals rather than solutions
- player-agency and open-world: climbable walls and gliding as freedom of route
- prototyping: a 2D proof of concept for a systemic hypothesis
- game-feel: physics “lies” chosen for control and responsiveness
Related
source-botw-breaking-conventions-gdc-2017 | emergent-design | game-atoms | inherent-vs-emergent-complexity | systemic-depth-elegance | second-order-design | systems-thinking | interaction-loops | open-world | player-agency | prototyping | minecraft | dwarf-fortress | portal | unity-collider2d-and-triggers | unity-rigidbody2d