Breaking Conventions with The Legend of Zelda: Breath of the Wild

Yes, it's rare, but they have. Game maker's toolkit has one on how they solved their open world problem for BotW: - [link] And at GDC, they talked about their Chemistry engine for BotW: - [this video] - [link] Game historian has some tidbits of how they made certain design decisions for their successful games Mario Kart: - [link] Super Mario World: - [link] Super Mario Bro 3: - [link] GMT, Snowman, and Extra credit does analysis of how Nintendo designs their Mario levels. - [link] - [link] - [link] - [link] - [link] Generally, it follows the ramp up and down of the Hero's journey in storytelling. 1. Introduce a new mechanic in a safe area where it's impossible to die. 2. Increase the challenge with the mechanic by adding variations 3. Ramp up challenge even more by combining with previously learned mechanic 4. Have periods of rest inbetween the challenges.

The Breath of the Wild game design has a concept called the "Chemistry Engine". In that game engines usually have a physics engine to figure out how things interact in a motion sense. The chemistry engine figures out how materials interact in an alchemy sense. It's kinda like a rules-based engine to figure out how different things interact with different other things, so you get surprising interactions between everything in the world, like being able to light arrows on fire, because arrows are a "wood" material. The Youtube link is here: [this video] It seems like most rule-based stuff in games is just hand-coded, as it's relatively simple and doesn't need to be general. When I asked the author of Baba is You, if he implemented a datalog engine for it, he said 'no'. I suspect it's the same for Breath of the Wild. But still, I've often wondered if that sort of chemistry engine would be best implemented in a logic language like Prolog or Datalog, for fast experimentation. Just like how we use SQL to keep the flexibility of our queries, and we end up just shipping that. I'm sure, back in the day, lots of people lamented how slow SQL queries were. The flexibility was useful enough that we ended up pouring man-centuries into making them fast. Now, we think that's just the way you ship things, and (almost) never think, "I can hand-roll imperative code that will be faster than this query".