Thema: Ron Gilbert's Puzzle Dependency Charts zur Abenteuerentwicklung

[eldaen]

Ein weiser Tanelorni hat in seiner Signatur den Satz "ein Kaufabenteuer ist eine Geschichte, wie sie passiert wäre, wenn man keine Spieler drauf los gelassen hätte" (oder so ähnlich). Ich bin nun die Art von SL, die gerne hypervorbereitet ist und alles detailliert ausgearbeitet hat - um dann letztlich doch besser improvisieren zu können. Worauf ich hinaus will: Auf meiner ewigen Suche nach neuen Techniken zum Abenteuerschreiben bin ich als großer Adventure Fan neulich über den Blog von Ron Gilbert gestolpert. Dort erklärt er, wie er "Puzzle Dependency Charts" benutzt, um im Adventure-Design Flaschenhälse zu vermeiden. Ich finde den Ansatz sehr interessant, und würde gerne mal eure Meinung dazu hören.

Ich ziehe gleich vorweg aber die Thread-Opener Karte und bitte euch, Diskussionen darüber, ob und wie das nun Railroading und somit ethisch korrekt ist oder nicht, in anderen Threads zu führen. Mir geht es nicht darum, mit der Technik kreative Ideen der Spielleiter auszuklammern, sondern schlicht darum im Abenteuerdesign Zusammenhänge und wahrscheinliche Optionen zu antizipieren und den Überblick zu behalten.

Zur besseren Übersichtlichkeit zitiere ich hier den kompletten Blogeintrag von Ron Gilbert, den ihr auch hier finden könnt:
https://grumpygamer.com/puzzle_dependency_charts


---


Puzzle Dependency Charts

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™. You can also see the graphviz file that produced it.

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.


---


Eure Gedanken? Brauchbar? Hilfreich? Tut ihr etwas ähnliches? Wie würdet ihr es angehen, verwenden, optimieren?

[Pyromancer]

Ich halte das für die VÖLLIG falsche Richtung, was interessantes Szenario-Design angeht. Interessant ist nämlich nicht die Frage, wie die Spieler die "Rätsel" lösen können, sondern welche relevanten Entscheidungen die Spieler treffen können.

[Scimi]

Na gut, das ist jetzt eine Technik, um Rätsel in Adventure-Games zu erstellen. Auf welcher Ebene siehst du denn da überhaupt den Einsatz für Tischrollenspiel? Ich nehme mal an, dass deine Runden nicht nur daraus bestehen, dass die Spieler Dinge finden und kombinieren, um neue Inhalte freizuschalten?

[Derjayger]

Ich finde es super. Ich kann die Kritik nur so verstehen: "Ich will Äpfel und keine Bananen!" Weil's anscheinend doch nicht so offensichtlich ist: Damit kann man auch Abläufe darstellen, z.B. was NPCs wann tun oder welche Möglichkeiten man bei einem Hindernis sieht (damit man sicher sein kann, dass es überhaupt eine oder mehrere Lösungen gibt. Man kann trotzdem Spielervorschläge aufgreifen).

Besonders betonenswert scheint mir:
- dass man eben nicht von "vorne nach hinten" ausdenken soll, sondern von "ist mir wichtig nach ist mir unwichtig". Diese Denkweise ist für jede kreative Arbeit nützlich.
- dass man so den Grad an Komplexität und "Railroadigkeit" von etwas darstellen und erkennen kann (ohne unvorhersehbare Ideen einzuberechnen. Also wie bei einem Kaufabenteuer).
- dass man Ideen verzieren bzw. strecken kann, indem man ihnen etwas "vorschaltet"

[eldaen]

Ich halte das für die VÖLLIG falsche Richtung, was interessantes Szenario-Design angeht. Interessant ist nämlich nicht die Frage, wie die Spieler die "Rätsel" lösen können, sondern welche relevanten Entscheidungen die Spieler treffen können.

Ich denke, da hast du einen wichtigen Punkt übersehen:

They do not generally include story beats unless they are critical to solving a puzzle.

Ich hab den mal im Eingangspost etwas hervorgehoben.

Na gut, das ist jetzt eine Technik, um Rätsel in Adventure-Games zu erstellen. Auf welcher Ebene siehst du denn da überhaupt den Einsatz für Tischrollenspiel? Ich nehme mal an, dass deine Runden nicht nur daraus bestehen, dass die Spieler Dinge finden und kombinieren, um neue Inhalte freizuschalten?

Nein, ich sehe das als Ergänzung zu den Story Beats, wenn es darum geht, was konkret getan werden soll/muss bzw. was die logischen Schritte der Charaktere wären.

[Scimi]

Bei GUMSHOE werden auf Szenenebene im Prinzip genau so Szenarien aufgebaut und das funktioniert. Das ist aber eine sehr abstrakte Ebene, die offen lässt, welche konkreten Schritte die Charakte unternehmen.

Deswegen frage ich, auf welcher Ebene du das siehst — innerhalb einer Szene wäre mir sowas wahrscheinlich viel zu durchgeplant.

[eldaen]

Ah, jetzt verstehe ich deine Frage. Nein, innerhalb einer einzelnen Szene würde ich das wohl auch kaum konsequent so einsetzen. Mir geht es eher um das Abstrakte, die Strukturierung der logischen Zusammenhänge innerhalb eines Abenteuers. Das Schema kann man dann natürlich auch bei Szenen verwenden (solange man eben offen und flexibel für den Player Input bleibt), muss man aber ja nicht.

[Scimi]

Konkret bei GUMSHOE besteht das Szenario immer aus einer Ermittlung, bei der in jeder Szene Hinweise zu einer nächsten Szene führen. Das können tatsächliche Orte sein (die Gruppe findet z.B. einen Hinweis auf eine Kneipe, von der sie vorher nichts wusste und kann jetzt da weitersuchen) oder einfach Umstände (die Gruppe konfrontiert einen NSC mit neuen Hinweisen und bekommt eine Reaktion, die vorher nicht zu haben war). Mir hilft es dann, mir das Ganze als Dungeon vorzustellen, mit Szenen anstelle von Räumen und Hinweisen anstelle von Türen.

Aber bei GUMSHOE sind die Charaktere Ermittler, die eine Motivation haben, den Hinweisen hinterherzurennen. In einem freieren Spiel, wo die Rolle der Charaktere nicht so festgelegt ist, finde ich diese Art der Planung eher hinderlich. Wenn die Spieler mehr oder weniger frei bestimmen können, wohin die Reise geht, macht man sich mit solchen festen Abfolgen und Zusammenhängen oft unglücklich.

[Pyromancer]

Die relevante Frage ist nicht: "Wie kommen die Charaktere in den Keller?"
Die relevanten Fragen sind: "Warum ist der Keller abgeschlossen?/Wer hat den Keller abgeschlossen?" und "Warum sollten die Charaktere überhaupt in den Keller wollen?"

[eldaen]

Kann ich doch damit genauso abbilden?

[Pyromancer]

Kann ich doch damit genauso abbilden?

Nö. Bzw. ich seh's nicht, wie man diese Fragen damit genauso abbilden könnte, ohne dass es krampfig wird. Ich lass mich aber eines besseren belehren.

[Antariuk]

Ich sehe das spontan auch keine neue Erkenntnis, bzw. einen Gewinn für die Abenteuerentwicklung. Oder anders: genau das kennt man doch als Flowchart, und benutzt es auch genau so um Flaschenhälse zu vermeiden. Oder überlese ich da etwas (außer dass es kein Flowchart wäre ...)? Mir fallen direkt auch Plot Points oder Jaquay-Dungeons als Varianten dieser Art der Strukturierung ein.

[KhornedBeef]

Von der Möglichkeit mal abgesehen, dass hier parallele Evolution vorliegt und die ganzen Schlaubi-Schlümpfe das schon mit angepassten Flowcharts oder was auch immer für sich machen, ist das doch eine schöne Erklärung vom erfolgreichen Praktiker, oder?

[Megavolt]

Der Ron Gilbert ist übrigens, wer hätte es gedacht, bekennender Pen and Paper - Rollenspieler. Ron Gilbert ist ein Rollenspieler, ich bin ein Rollenspieler, ergo: Ich bin Ron Gilbert. Yay! 

Ich habe damals die Entwicklung von Thimbleweed-Park sehr konzentriert verfolgt, sowas schenke ich mir sonst eigentlich mit einem Achselzucken. Ich finde die Art und Weise, wie er seine Rätsel konstruiert, relativ trivial und unspektakulär. Deutlich interessanter finde ich den oft unglaublich machtvollen Vibe in seinen Spielen und die Tatsache, dass sich Thimbleweed Park offenbar finanziell zwar schon gerechnet hat, aber nicht so, dass er noch ein weiteres solches Spiel nachschieben könnte. Ich hätte eigentlich eine ausschweifende Serie erwartet.

Weiterhin sehnt sich der Ron danach, ein wirklicher Künstler zu sein, und legt auf einer sekundären Ebene sehr viel Wert darauf, vor allem mit den Rahmen und den Formen zu spielen und einen entsprechenden Mehrwert zu produzieren. Da ist er ein bisschen eine tragische Figur, denn man kann seinen Wunsch so deutlich sehen, und irgendwie reißt er die Latte trotzdem jedesmal. (Monkey Island-Jahrmarktsende: Schrott, The Cave: so überkünstelt, dass es ein Gameplay.-Bunker war. Thimbleweed-Park-Ende: Vollschrott)

Der Ron ist ein klasse Entertainer, es lohnt sich, den mal auf YouTube zu stalken, der hat tolle Auftritte. Meine Theorie ist, dass der Ron als Programmierer letztlich doch das Falsche studiert hat, denn hochbegabt ist er sicherlich, aber es fehlen ihm halt irgendwo die geisteswissenschaftlichen Reserven (fällt mir jetzt keine bessere Formulierung ein, ihr wisst, was ich meine). Sein Ruhm begründet sich meiner Meinung nach eher in der Pionierleistung und im konsequent durchgezogenen Autorenkino. Ist ja beides auch wunderbar, ist halt nur nicht das, was er selber will.

[KhornedBeef]

TIL... Monkey Island ist Autorenkino, ergo bin ich Intellektueller