Puzzle Dependency Charts

I was pleasantly surprised that Ron Gilbert (one of the creators of classic games like Maniac Mansion and Monkey Island) was going to create a new adventure game based on the same look as Maniac Mansion. He created a Kickstarter project and a development blog. I was really happy with this so I started reading all the blog posts he has written about the design process. That took me to his personal blog which had a ton of more information.

Inside his blog I found an extremely useful post about how he tackles the dependency between puzzles. I always found that to be a big part of the creation of any adventure, or even something like a murder mystery game in real life! He calls this system Puzzle Dependency Charts, and I think it’s a cool way to do this!

I created 2 escape games in the past (Light Asylum Escape series), which can be considered kind of simple adventures. I took the first one as an example to try and apply the concept, since it’s an extremely simple game (I did it more like an introduction to the second one).

How do they work?

So, usually we use charts to represent either relationship between game elements (UML), or to represent flow (Flowcharts or BMPN). In this case the elements of the chart are puzzles. A puzzle can be considered anything that gets you one step closer to solving the game. It can be something like catching a key, or giving something to someone, or cracking a code, etc. It indeed sounds a bit ambiguous but I think there’s space for each person to organize these charts as they see fit and the best way to help the game development.

Ron Gilbert suggests we work backwards, at least for a certain block of puzzles (or chapters). In my case the game is so simple that we can consider it as a whole chapter (in fact, it’s a chapter in a series of 5 games that I was supposed to have finished and I never did).

So let’s start by representing our main and final goal of this game, which is, to leave the room! Which means solving the magic square puzzle on the door to open it. So I decided that I would start my PDC (let’s use an acronym from now on) with that last puzzle.

So, now we’re supposed to think “What do I need to solve that last puzzle?”. In this particular game we need to find 7 tiles (it needs 9 but one is already on the puzzle and another one is already in our inventory, so we’re going to ignore those two). So let’s include that in our PDC.

 

So from now on we can include what we need to get those tiles and the start of the game.

 

The fact that the game was so small created in fact a little bit more complexity in my mind to this task. For example, we have a tile under the bed. We don’t need to do anything special to get it but to look under the bed. Is looking under the bed a “puzzle”? Well, I see it as actions that the player need to do to achieve something. In a more complex game I might have ignored it and just have “Get Tile 7” and “Look Under Bed” both in a single step called “Find Tile 9“. I don’t think these charts are intended to explain a lot on how to solve the puzzle themselves. But since the game is extremely small and escape games are really based on exploring a single space, I think it made sense in this case.

Conclusions

This was my first PDC so I’m still figuring out the best way to make it. And my first example is indeed very small. But even so I can still take a few conclusions from it.

1 – It’s a great way to have an overall view over what needs to be accomplished by the player.

2 – It’s also a great way, as a developer, so track progress on the development of the game.

3 – It’s a great way to understand the flow of the game and to see if there’s some enhancements to be made (removing puzzles, branching, etc).

I will create the PDC for Light Asylum Room 2 in another post and we’ll analyse the structure of that game. I think I will get to the conclusion that the game could have been better designed.