3 ms·

Isn't avoiding dead ends one of the reasons you use a puzzle dependency chart? http://grumpygamer.com/puzzle_dependency_charts http://grumpygamer.com/puzzle_de

Isn't avoiding dead ends one of the reasons you use a puzzle dependency chart? http://grumpygamer.com/puzzle_dependency_charts http://grumpygamer.com/puzzle_dependency_charts I always think of finite state automata, but these adventure games with all the different inventory and actions can be remarkably hard to model.

Jtsummers 10y ago
That's related, but not the same. The dependency chart isn't showing the set of all possible player actions (though it can grow to that). And then, unless it's implemented formally, as described in the article it's a design tool, and not a formal tool. So you could leave out things (unintentionally). For instance, if you don't model that the player can drop an object after finding it, you can't guarantee that they'll have it when they need it. So, using the original post's game, Alice needs the red key to get to the red room (final goal). Let's say it was in the west room, also with the green key, where Alice begins the game. She grabs the green key, goes east, hands it to Bob who heads west. Now Alice cannot move. This particular game is solvable because Bob can grab the red key and take it to Alice, but not every game permits this recovery action. Supposing it only had the one player character, and the keys were consumable (as happens in some games). She has no way to return. The dependency chart only shows that she can solve the puzzle, not that she can always solve the puzzle (that there exists a path, not for all paths), until it gets a lot more detail than a hand-drawn graph is likely to get.
- zeta0134 10y ago
  This is an excellent thing to think about when designing dungeons or encounters in any game really. I feel the need to call out Mark Brown, who's doing an excellent analysis series on the Legend of Zelda series, breaking down the dependencies in the dungeons throughout that game and walking through some of the issues present within. One of the more notorious dungeons in the series is the Water Temple in Ocarina of Time, which contained a sequence that would allow the player to use a small key for an optional area that, critically, did not refund the small key. This allowed the player to become permanently stuck, unable to advance through the dungeon and complete the game. https://www.youtube.com/watch?v=6LO8Z1DkDqc&index=3&list=PLc38fcMFcV_ul4D6OChdWhsNsYY3NA5B2 https://www.youtube.com/watch?v=6LO8Z1DkDqc&index=3&list=PLc...
  - writeslowly 10y ago
    I tried to find more information on this and the best thing I could find was this blog post claiming that you can't get permanently stuck in the Water Temple (at least, by using keys in the wrong order). It looks like the dungeon is set up with a few carefully designed chokepoints using the water level mechanics to stop players from going too far down the wrong path: http://blog.breakingzelda.com/2013/03/the-water-temple-myth-part-2.html http://blog.breakingzelda.com/2013/03/the-water-temple-myth-... Unfortunately, the author also claims there is an alternate way to ruin your game in the water temple that they'll cover in a follow-up article, but that article doesn't exist.
- probably_wrong 10y ago
  > For instance, if you don't model that the player can drop an object after finding it, you can't guarantee that they'll have it when they need it This was a problem in the original Monkey Island: you could throw some leaflets in a fire, but you needed them in order to convince a local tribe to give you a key.

Jtsummers 10y ago

That's related, but not the same. The dependency chart isn't showing the set of all possible player actions (though it can grow to that). And then, unless it's implemented formally, as described in the article it's a design tool, and not a formal tool. So you could leave out things (unintentionally). For instance, if you don't model that the player can drop an object after finding it, you can't guarantee that they'll have it when they need it. So, using the original post's game, Alice needs the red key to get to the red room (final goal). Let's say it was in the west room, also with the green key, where Alice begins the game. She grabs the green key, goes east, hands it to Bob who heads west. Now Alice cannot move. This particular game is solvable because Bob can grab the red key and take it to Alice, but not every game permits this recovery action. Supposing it only had the one player character, and the keys were consumable (as happens in some games). She has no way to return. The dependency chart only shows that she can solve the puzzle, not that she can always solve the puzzle (that there exists a path, not for all paths), until it gets a lot more detail than a hand-drawn graph is likely to get.

zeta0134 10y ago
This is an excellent thing to think about when designing dungeons or encounters in any game really. I feel the need to call out Mark Brown, who's doing an excellent analysis series on the Legend of Zelda series, breaking down the dependencies in the dungeons throughout that game and walking through some of the issues present within. One of the more notorious dungeons in the series is the Water Temple in Ocarina of Time, which contained a sequence that would allow the player to use a small key for an optional area that, critically, did not refund the small key. This allowed the player to become permanently stuck, unable to advance through the dungeon and complete the game. https://www.youtube.com/watch?v=6LO8Z1DkDqc&index=3&list=PLc38fcMFcV_ul4D6OChdWhsNsYY3NA5B2 https://www.youtube.com/watch?v=6LO8Z1DkDqc&index=3&list=PLc...
- writeslowly 10y ago
  I tried to find more information on this and the best thing I could find was this blog post claiming that you can't get permanently stuck in the Water Temple (at least, by using keys in the wrong order). It looks like the dungeon is set up with a few carefully designed chokepoints using the water level mechanics to stop players from going too far down the wrong path: http://blog.breakingzelda.com/2013/03/the-water-temple-myth-part-2.html http://blog.breakingzelda.com/2013/03/the-water-temple-myth-... Unfortunately, the author also claims there is an alternate way to ruin your game in the water temple that they'll cover in a follow-up article, but that article doesn't exist.
probably_wrong 10y ago
> For instance, if you don't model that the player can drop an object after finding it, you can't guarantee that they'll have it when they need it This was a problem in the original Monkey Island: you could throw some leaflets in a fire, but you needed them in order to convince a local tribe to give you a key.