04 Build

Nach Abschluss des vorigen Abschnitts steht ein fertiger Abenteuerrumpf, ein Skelett da. Das hat erstens nicht allzu lange gedauert und ist zudem eine sehr übersichtliche Arbeitshilfe. Letztlich besteht es lediglich aus eines Stichpunktsammlung.

Ziel dieses Abschnitts ist ein Prototyp, als eine erste funktionierende, ausformulierte Version des Abenteuers. Der Plot ist die Skizze, Build das “Minimum viable product”. Polish glättet dann alles.

Warum machen wir das am Abenteuer insgesamt und nicht gleich für jede einzelne Begegnung? Durch das Ausplotten am Anfang steht eine schlüssige Handlung. Wir haben Logic Bombs eliminiert und eine Timeline, müssen also an dieser Stelle nichts grundlegend mehr umwerfen. Gestalten und verfeinern wir eine Begegnung, die später nicht mehr ins Konzept passt, ist das ziemlich viel vertane Arbeit.

Was genau wir “bauen”, hängt unter anderem von folgenden Faktoren ab:

• System: Wie viel Crunch müssen die Szenen enthalten
• System Mastery: je weniger gut wir das System kennen, desto mehr sollten wir uns dahingehend vorbereiten, ansonsten können wir uns aufs Improvisieren verlassen.
• GM Style: wer prinzipiell mehr improvisiert, muss weniger “bauen”.

Grundlegend: Regeln und Spielmechaniken zu kennen, spart Zeit in der Vorbereitung.

Zur Timeline

#

            Milestone 1      Milestone 2      Milestone 3         Finale
                 |                |                |                |
  1  2  3  4  5  | 1  2  3  4  5  | 1  2  3  4  5  | 1  2  3  4  5  |
----------------------------------------------------------------------------->
        5RD1             5RD2             5RD3             5RD4

Die nötigen Seeds für das Abenteuer, die 5RDs und die einzelnen Räume / Encounters stehen also auf dem Papier und erlauben, solch eine lineare Timeline aufzumalen. Natürlich schaut das ganze in der Praxis anders aus:

+---------------------+
|     Milestone 1     |
+---------------------+

                 +---------------------+
                 |     Milestone 2     |
                 +---------------------+

          +-----------------------------------------+
          |               Milestone 3               |
          +-----------------------------------------+

                                 +---------------------+
                                 |     Milestone 4     |
                                 +---------------------+

Weder müssen es genau drei Milestones sein, noch arbeiten Spieler sie genauso linear ab, wie es in der Timeline steht. Hier gilt: Brich die 3er-Regel, wenn das besser so ist. Johnn empfiehlt trotzdem, lange Serien in mehrere 5RDs aufzubrechen, um eine bessere Kontrolle über die Spannungsbögen zu haben.

Encounter Budget

#

Wenn wir wissen, wie lange wir pro Encounter brauchen, können wir die Länge des Abenteuers planen. Später schauen wir noch an, wie wir die Länge im Spiel anpassen, das Pacing anpassen. Das verändert natürlich die Länge. But: Beware of explorers! Die treiben Abenteuer in die Länge. Übrigens: Macht die Räume nicht offensichtlich, sonst heißt es irgendwann: “Leute, das war jetzt der Setback. Zwei Räume noch!”

Encounter Statblock

#

Für Johnn besteht das Bauen einer Szene aus dem Befüllen des Encounter Statblocks. Den gibt es in zwei Varianten:

• als Thinking Statblock: alles, woran man denken sollte
• und in einer kürzeren Version, wenn man das verinnerlicht hat. Darin findet sich das, was man letztlich aufschreiben sollte.

Die folgenden Abschnitte stellen die einzelnen Komponenten des Thinking Statblock genauer vor:

• Name
• Purpose
• Choice
• Location
• Cast of Characters (möglicherweise kann man absehen, dass die Gruppe getrennt sein wird)
• Dangers
• Treasure & Reward
• Development (mögliche Entwicklungen)
• Overview
• Transitions
• Mechanics

Ganz allgemein empfiehlt Johnn beim Planen einer Szene mit einer Karte anzufangen, eventuell auch mich einer Mindmap, um den Fluss anzustoßen. Er nimmt gerne Dungeon Draft.

Die Buildphase erzeugt das eigentlich Spiel, das – wie an anderer Stelle schon erwähnt – in den Encounters stattfindet. Polish wird sich später um Hintergrund, Metainformationen und all die Details kümmern, die wir jetzt aussparen. Dass diese Schritte jetzt so streng getrennt ablaufen, dient in erster Linie der Verdeutlichung. Später geschieht das parallel, aber so hilft es, Gedanken den richtigen Schritten zuordnen zu können.