Brettspiel-Prototyp-Leitfaden: Von der Idee zum Spielbaren in 7 Schritten

Ein Prototyp ist kein fertiges Produkt. Seine Aufgabe ist es, Mechaniken so günstig und schnell wie möglich testbar zu machen. Die meisten Erstdesigner verbringen zu viel Zeit damit, ihren Prototyp gut aussehen zu lassen, und nicht genug damit, ihn zum Funktionieren zu bringen. Dieser Leitfaden behandelt, wie man funktionsfähige Prototypen schnell baut, wann man upgradet und was 25 Jahre Neutronium: Parallel Wars-Prototyping über Iterationszyklen und die Kosten des zu frühen Verschönerns gelehrt haben.

Schritt 1 — Der Karteikarten-Prototyp

Der erste Prototyp sollte unter 10 € kosten und in unter 2 Stunden zu bauen sein. Materialien: Karteikarten, Marker, Schere, Tokens aus einem anderen Spiel oder Münzen. Mechaniken auf Karten schreiben. Das Spielfeld auf Papier zeichnen. Münzen als Tokens verwenden. Das Ziel ist nicht, wie ein Spiel auszusehen — das Ziel ist zu testen, ob die Kernentscheidungsschleife interessant genug ist, um zweimal durchgespielt zu werden.

Neutroniums erster Prototyp waren aus Karton geschnittene Hexfelder mit handgezeichneten Segmentlinien. Keine Kunst. Zahlen mit Bleistift geschrieben, die sich in der ersten Sitzung verwischten. Das Hex-Gitter war ungefähr gemessen und einige Kacheln waren leicht unterschiedlich groß. Das alles spielte keine Rolle — die zu testende Frage war, ob das Kontrollieren hexagonaler Gebiete mit geteilten Kanten interessante Entscheidungen erzeugt, und diese Frage konnte mit unpräzisen Kartonkacheln beantwortet werden.

Schritt 2 — Definieren, was getestet wird

Jede Prototypen-Iteration testet eine Sache. Vor dem Bauen klar formulieren: „Ich teste, ob Mechanik X interessante Entscheidungen schafft." Wenn man Gebietsbeanspruchung testet, braucht man keine Kunst. Man braucht keine endgültigen Komponentenzählungen. Man braucht genug Stücke, um 10 Runden durchzuspielen. Die Hypothese vor der Sitzung aufschreiben, nicht danach.

Der häufigste Prototypen-Fehler ist das Durchführen von Sitzungen ohne eine definierte Frage. Das produziert anekdotisches Feedback — „Spieler schienen die Handelsmechanik zu genießen" — statt beantworungsfähiger Daten. Eine beantwortbare Hypothese wäre: „Schafft die Handelsmechanik mehr Entscheidungen pro Zug als die Direktkaufalternative?" Diese Frage kann getestet werden. „Haben Spieler es genossen?" kann nicht mit genug Spezifität getestet werden, um Designänderungen zu leiten.

Wenn Einkommensskalierung getestet wird, braucht man genaue Zahlen auf diesen Komponenten. Alles andere kann roh sein. Präzision sollte proportional zu dem sein, was getestet wird — nicht zu dem, was den Prototyp fertig aussehen lässt.

Schritt 3 — Komponentengenauigkeitsstufen

Zu verstehen, auf welcher Genauigkeitsstufe der Prototyp sein sollte — und nicht vorwärts zu springen — spart Wochen verschwendeter Arbeit. Die meisten Designer überspringen Level 2 vollständig, wo die meiste echte Balance-Arbeit passiert.

Die Level-2-Iteration ist die Phase, bei der hässliche Komponenten ein Merkmal sind, kein Problem. Spieler, die nicht von Kunst abgelenkt werden können, beschäftigen sich direkt mit Mechaniken. Komponentenverwirrung auf Level 2 (Spieler sind unsicher, welche Komponente welche ist) zeigt, dass das Design klarere Differenzierung braucht — nicht bessere Kunst. Die Differenzierung auf Level 2 beheben, bevor in Level-3-Produktionsqualität investiert wird.

Schritt 4 — Hex-Kachel-Prototyping

Neutronium-spezifisch, aber weitgehend auf jedes Spiel mit räumlicher Adjacenz anwendbar. Hexagonale Kacheln erfordern mehr Prototypen-Aufwand als rechteckige Karten, weil Adjacenz räumlich und direktional ist — eine in einem Winkel gelegte Kachel zählt, nicht nur welche Kachel gelegt wurde.

Für Hex-Kachelspiele: auf Karton drucken (mindestens 90 g/m², 120 g/m² bevorzugt für Langlebigkeit), mit einem Hex-Stanzer oder Schablone schneiden und die Kacheln nummerieren, damit sie zur Design-Tabelle passen. Segmente mit Bleistift beschriften — diese Labels werden in den ersten fünf Sitzungen mehr als einmal geändert. Nicht mit Tinte festschreiben, bis dasselbe Kachel-Layout über mindestens drei Sitzungen hinweg ohne Änderung getestet wurde.

Schritt 5 — Das Versionsnummerierungssystem

Jede Prototypenversion beschriften. Wenn etwas geändert wird, die Versionsnummer aktualisieren und aufschreiben, was geändert wurde und warum. Nach 25 Playtests wird man sich nicht mehr daran erinnern, welche Version das Nuclear-Port-Schneeballproblem behoben hat. Man wird sich nicht erinnern, ob die Einkommens-Neubalancierung in Version 2.4 die Lösung war oder ob es die in Version 2.7 eingeführte Port-Zerstörungsmechanik war.

Eine einfache Tabelle verwenden: Versionsnummer, Datum, was geändert wurde, warum die Änderung vorgenommen wurde und das in der nächsten Sitzung beobachtete Ergebnis. Das ist die Grundlage des MEQA-Frameworks — ohne Versionsaufzeichnungen hat das Framework keine historischen Daten, gegen die es argumentieren kann. Die Tabelle braucht 5 Minuten pro Sitzung zum Pflegen und spart Stunden der Rekonstruktion, was wann geändert wurde.

Neutronium: Parallel Wars hat Versionsaufzeichnungen bis zu frühen Iterationen. Die Aufzeichnungen zeigen, dass einige in Version 1.x eingeführte Mechaniken noch in nahezu finaler Form vorhanden sind, und andere, die wesentlich schienen, bis Version 3.0 vollständig entfernt wurden. Die Papierspur ist die Designgeschichte.

Schritt 6 — Wann der Prototyp zu upgraden ist

Upgraden, wenn externe Spieltester mit der Lesbarkeit von Komponenten zu kämpfen haben — wenn die Schrift zu klein ist, Farben zu ähnlich oder Symbole mehrdeutig sind. Niemals upgraden, um die Ästhetik zu verbessern. Upgraden, um die Testbarkeit zu verbessern. Der Unterschied ist wichtig: Wenn man upgradet, weil der Prototyp roh aussieht, ist das kein funktionaler Grund. Wenn man upgradet, weil Spieler Symbole falsch lesen und dadurch falsche Balance-Daten erzeugen, ist das ein funktionaler Grund.

Zeichen, dass ein Level-3-Prototyp benötigt wird: Spieler fragen mehr als einmal pro Sitzung nach dem Unterrichten der Regeln „Was bedeutet dieses Symbol?" Spieler verlieren den Überblick über Komponentenstandorte, weil Stücke unter Spielbedingungen zu ähnlich aussehen. Spieler machen illegale Züge nicht aus Regelverwirrung, sondern aus Komponentenmissidentifikation. Das sind Signalfehler im Prototyp, nicht im Spieldesign.

Prototypenkunst sollte Komponenten unterscheiden, nicht verzieren. Ein rotes und ein blaues Hex mit identischen Symbolen testet Adjacenz-Mechaniken effektiv. Zwei Hex-Kacheln mit unterschiedlichen Hintergrundtexturen und kleinen Symbolen in der Ecke tun das nicht. Differenzierung ist funktional; Dekoration nicht.

Schritt 7 — Digitales Prototyping mit Tabletop Simulator

Tabletop Simulator (TTS) ist ein Steam-Spiel, das das Prototypen und Testen von Brettspielen digital ermöglicht. Seine Vorteile: kein Drucken, kein Schneiden, einfache Komponentenaktualisierungen und die Möglichkeit des Remote-Playtestings über verschiedene Städte oder Länder. Eine Regeltext-Änderung, die das Neudrucken von 60 Karten physisch erfordern würde, dauert in TTS 5 Minuten.

Seine Nachteile sind real: Ergonomietests sind unmöglich, weil man nicht fühlen kann, ob Tokens zu klein für komfortables Handling sind. Komponentenphysikalität kann nicht bewertet werden — ob eine Hex-Kachel befriedigend zu legen ist, ob Karten gut mischen, ob die Tokenanzahl für komfortables Tischmanagement geeignet ist. Für Spiele mit erheblicher physischer Interaktion bleiben physische Prototypen in irgendeiner Phase wesentlich.

Neutronium: Parallel Wars hat ein TTS-Mod für Remote-Testsitzungen. Das ermöglichte das Playtesting mit Gruppen in verschiedenen Städten, ohne physische Prototypenkopien versenden zu müssen. Die TTS-Sitzungen konzentrierten sich auf Regelklarheit und Balance-Tests. Physische Sitzungen konzentrierten sich auf Komponentendesign-Validierung und die Ergonomie von Aufbau und Abbau. Beide waren notwendig; keines konnte das andere ersetzen.

Häufig gestellte Fragen