In part 1 of 1 in my series of articles on games design, let’s delve into one of the (if not THE) most useful tool for designing adventure games: The Puzzle Dependency Chart. Don’t confuse it with a flow chart, it’s not a flow chart and the subtle distinctions will hopefully become clear, for they are the key to it’s usefulness and raw pulsing design power.
There is some dispute in Lucasfilm Games circles over whether they were called Puzzle Dependency Charts or Puzzle Dependency Graphs, and on any given day I’ll swear with complete conviction that is was Chart, then the next day swear with complete conviction that it was Graph. For this article, I’m going to go with Chart. It’s Sunday.
Gary and I didn’t have Puzzle Dependency Charts for Maniac Mansion, and in a lot of ways it really shows. The game is full of dead end puzzles and the flow is uneven and gets bottlenecked too much.
Puzzle Dependency Charts would have solve most of these problems. I can’t remember when I first came up with the concept, it was probably right before or during the development of The Last Crusade adventure game and both David Fox and Noah Falstein contributed heavy to what they would become. They reached their full potential during Monkey Island where I relied on them for every aspect of the puzzle design.
A Puzzle Dependency Chart is a list of all the puzzles and steps for solving a puzzle in an adventure game. They are presented in the form of a Graph with each node connecting to the puzzle or puzzle steps that are need to get there. They do not generally include story beats unless they are critical to solving a puzzle.
Let’s build one!
I always work backwards when designing an adventure game, not from the very end of the game, but from the end of puzzle chains. I usually start with “The player needs to get into the basement”, not “Where should I hide a key to get into some place I haven’t figured out yet.”
I also like to work from left to right, other people like going top to bottom. My rational for left to right is I like to put them up on my office wall, wrapping the room with the game design.
So… first, we’ll need figure out what you need to get into the basement…
And we then draw a line connecting the two, showing the dependency. “Unlocking the door” is dependent on “Finding the Key”. Again, it’s not flow, it’s dependency.
Now let’s add a new step to the puzzle called “Oil Hinges” on the door and it can happen in parallel to the “Finding the Key” puzzle…
We add two new puzzle nodes, one for the action “Oil Hinges” and it’s dependency “Find Oil Can”. “Unlocking” the door is not dependent on “Oiling” the hinges, so there is no connection. They do connect into “Opening” the basement door since they both need to be done.
At this point, the chart is starting to get interesting and is showing us something important: The non-linearity of the design. There are two puzzles the player can be working on while trying to get the basement door open.
There is nothing (NOTHING!) worse than linear adventure games and these charts are a quick visual way to see where the design gets too linear or too unwieldy with choice (also bad).
Let’s build it back a little more…
When you step back and look at a finished Puzzle Dependency Chart, you should this kind of overall pattern with a lot of little sub-diamond shaped expansion and contraction of puzzles. Solving one puzzle should open up 2 or 3 new ones, and then those collapses down (but not necessarily at the same rate) to a single solution that then opens up more non-linear puzzles.
The game starts out with a simple choice, then the puzzles begin to expand out with more and more for the player to be doing in parallel, then collapse back in.
I tend to design adventures games in “acts”, where each act ends with a bottle neck to the next act. I like doing this because it gives players a sense of completion, and they can also file a bunch of knowledge away and (if need) the inventory can be culled).
Monkey Island would have looked something like this…
I don’t have the Puzzle Dependency Chart for Monkey Island, or I’d post it. I’ve seen some online, but they are more “flowcharts” and not “dependency charts”. I’ve had countless arguments with people over the differences and how dependency charts are not flowcharts, bla bla bla. They’re not. I don’t completely know why, but they are different.
Flowcharts are great if you’re trying to solve a game, dependency charts are great if you’re trying to design a game. That’s the best I can come up with.
Here is a page from my MI design notebook that shows a puzzle in the process of being created using Puzzle Dependency Charts. It’s the only way I know how to design an adventure game. I’d be lost without them.
So, how do you make these charts?
You’ll need some software that automatically rebuilds the charts as you connect nodes. If you try and make these using a flowchart program, you’ll spend forever reordering the boxes and making sure lines don’t cross. It’s a frustrating and time consuming process and it gets in the way of using these as a quick tool for design.
Back at Lucasfilm Games, we used some software meant for project scheduling. I don’t remember the name of it, and I’m sure it’s long gone.
I’ve only modern program that does this well is OmniGraffle, but it only runs on the Mac. I’m sure there are others, but since OmniGraffle does exactly what I need, I haven’t look much deeper. I’m sure there are others.
OmniGraffle is built on top of the unix tool called graphviz. Graphviz is great, but you have to feed everything in as a text file. It’s a nerd level 8 program, but it’s what I used for DeathSpank.
You can take a look at the DeathSpank Puzzle Dependency Chart here, but I warn you, it’s a big image, so get ready to zoom-n-scroll™.
Hopefully this was interesting. I could spend all day long talking about Puzzle Dependency Charts. Yea, I’m a lot of fun on a first date.
More crap that is quickly becoming a fire hazard. Some of my notes from building SCUMM on the C64 for Maniac Mansion.
I’m not sure who’s phone number that is on the last page. I’m afraid to call it.
I’m looking for some good recommendations on modern 2D point-and-click adventure game engines. These should be complete engines, not just advice to use Lua or Pascal (it’s making a comeback). I want to look at the whole engine, not just the scripting language. PC based is required. Mobile is a ok. HTML5 is not necessary. Screw JavaScript. Screw Lua too, but not as hard as JavaScript.
I’m not so much interested in using them, as I’d just like to dissect and deconstruct what the state of the art is today.
P.S. I don’t know why I hate Lua so much. I haven’t really used it other than hacking WoW UI mods, but there is something about the syntax that makes it feel like fingernails on a chalkboard.
P.P.S It’s wonderful that “modern 2d point-and-click” isn’t an oxymoron anymore.
P.P.P.S Big bonus points if you’ve actually used the engine. I do know how to use Google.
P.P.P.P.S I want engines that are made for adventure games, not general purpose game engines.
An email sent to me from LucasArts Marketing/Support letting me know they “finally” found some people who liked the ending to Monkey Island 2.
Even more crap from my Seattle storage unit!
Here is the original pitch document Gary and I used for Maniac Mansion. Gary had done some quick concepts, but we didn’t have a real design, screen shots or any code. This was before I realized coding the whole game in 6502 was nuts and began working on the SCUMM system.
There was no official pitch process or “green lighting” at Lucasfilm Games. The main purpose of this document would have been to pass around to the other members of the games group and get feedback and build excitement.
I don’t remember a point where the game was “OK’d”. It felt that Gary and I just started working on it and assumed we could. It was just the two of us for a long time, so it’s not like we were using up company resources. Eventually David Fox would come on to help with SCUMM scripting.
Three people. The way games were meant to be made.
If this document (and the Monkey Island Design Notes) say anything, it’s how much ideas change from initial concept to finished game. And that’s a good thing. Never be afraid to change your ideas. Refine and edit. If your finished game looks just like your initial idea, then you haven’t pushed and challenged yourself hard enough.
It’s all part of the creative process. Creativity is a messy process. It wants to be messy and it needs to be messy.
More crap from my storage unit.
Print your own today!
While cleaning out my storage unit in Seattle, I came across a treasure trove of original documents and backup disks from the early days of Lucasfilm Games and Humongous Entertainment. I hadn’t been to the unit in over 10 years and had no idea what was waiting for me.
Here is the first batch… get ready for a week of retro… Grumpy Gamer style…
First up…
A early mock-up of the Maniac Mansion UI. Gary had done a lot of art long before we had a running game, hence the near finished screen without the verbs.
A map of the mansion right after Gary and I did a big pass at cutting the design down. Disk space was a bigger concern than production time. We had 320K. That’s right. K.
Gary and I were trying to make sense of the mansion and how the puzzles flowed together. It wouldn’t be until Monkey Island that the “puzzle dependency chart” would solve most of our adventure game design issues.
More design flow and ideas. The entire concept of getting characters to like you never really made it into the final game. Bobby, Joey and Greg would grow up and become Dave, Syd, Wendy, Bernard, etc..
A really early brainstorm of puzzle ideas. NASA O-ring was probably “too soon” and twenty-five years later the dumb waiter would finally make it into The Cave.
I’m still amazed Gary and I didn’t get fired.
Time flies. The gaming and internet institution known as the Grumpy Gamer Blog has been around for just over ten years.
My first story was posted in May of 2004. Two thousand and four. I’ll let that date sink in. Ten years.
The old Grumpy Gamer website was feeling “long in the tooth” and it was starting to bug me that Grumpy Gamer was still using a CRT monitor. He should have been using a flat screen, or more likely, just a mobile phone, or maybe those Google smart contact lens. He would not have been using an Oculus Rift. Don’t get me started.
I coded the original Grumpy Gamer from scratch and it was old and fragile and I dreaded every time I had to make a small change or wanted to add a feature.
A week ago I had an the odd idea of doing a Commodore 64 theme for the entire site, so I began anew. I could have used some off-the-shelf blogging tool or code base, but where’s the fun in that. Born to program.
I’m slowly moving all the old articles over. I started with the ones with the most traffic and am working my way down. I fundamentally changed the markup format, so I can’t just import everything. Plus, there is a lot of crap that doesn’t want to be imported. I still need to decide if I’m going to import all the comments. There are a crap-ton of them.
I’d also like to find a different C64 font. This one has kerning, but it lacks unicode characters, neither of which are truly “authentic”, but, yeah, who cares.
But the honest truth is…
I’ve been in this creative funk since Scurvy Scallywags Android shipped and I find myself meandering from quick prototype to quick prototype. I’ll work on something for a few days and then abandon it because it’s pointless crap. I think I’m up to eight so far.
The most interesting prototype is about being lost in a cavern/cave/dungeon. The environment programmatically builds itself as you explore. There is no entrance and no exit. It is an exercise in the frustration of being lost. You can never find your way out. You just wander and the swearing gets worse and worse as you slowly give up all hope.
I have no sense of direction, so in some ways, maybe it was a little personal in the way I suppose art should be.
I worked on the game for about a week then gave up. Maybe the game was more about being lost than I thought.
Rebuilding Grumpy Gamer was a way to get my brain going again. It was a project with focus and an end. As the saying goes: Just ship something. So I did.
The other saying is: “The Muse visits during the act of creation, not before.”
Create and all will follow. Something to always keep in mind.