Zur Zeit habe ich zwei oder drei Spiele in einer Phase, in der sie fürs erste Playtesting bereit gemacht werden müssen.
Hierfür benötigt man nur einen Prototypen. An Grafik muss nur das vorhanden sein, was für das Funktionieren der Spielmechanik nötig ist. Es gibt sogar einige Spiele-Entwickler, die sagen, dass das Spiel in seiner ersten Playtesting-Phase ganz ohne „Theme“, also visuelle Repräsentation des Inhalts, auskommen soll, und nur, wenn es selbst dann Spaß macht, solle man es weiter entwickeln.
Ganz so krass will ich es nicht machen, auch, weil meine Spieletester keine ausgefuchsten Go-Spieler sind, die einfach nur einen abstrakten Wettbewerb wollen, sondern sich meistens sehr für meine Themes interessieren. Wenn ich erzähle, dass ich an einer neuen Spiel-Idee sitze, ist die erste Frage meistens nicht eine nach der geplanten Mechanik, sondern nach dem Theme. „Ein Detektivspiel auf einer tropischen Insel“ (=“Sandfoot Bay“) zu sagen bringt mir meistens viel mehr Interesse ein als „ein Flip-and-Write-Aufbauspiel“ (=“Epsom“).
Auch habe ich festgestellt, dass man einen im Spiel geplanten Spezialwürfel mit Formen drauf (ähnlich wie der von Railroad Ink) natürlich durch einen normalen W6 und eine Übersetzungs-Tabelle ersetzen kann, das Spiel dadurch aber mühseliger und weniger intuitiv wird. Und in dem konkreten Fall war es so, dass dadurch zuviel Tempo rausgenommen wurde, was das Gefühl eines heftigen Unterwasser-Zweikampfes ziemlich gedämpft hat. (Aufgrund dieses frustrierenden Spielgefühls habe ich den Prototypen noch nicht weiterentwickelt und ihm auch noch keinen Arbeitstitel gegeben. Es handelt sich um ein „Roll-and-Write Area Control auf einem hexagonalen Spielfeld“. Gähn… Es handelt sich um eine tropische Unterwasserjagd: eine Spielerin führt die Harpune, die andere ist die Muräne. Besser, oder?!)
Was braucht es also, um ein Spiel erstmalig sinnvoll, erfolgreich und mit Spaß zu testen?
- Einen funktionalen Prototypen. Ich muss das Spiel schon mehrfach allein durchgespielt haben, um zu wissen, dass die Mechanik grundsätzlich funktioniert.
- Eine klare Zielsetzung. Will ich…
- … das Zusammenspiel der verschiedenen Mechanismen überprüfen?
- … beurteilen, mit wie vielen Spielenden das Spiel am besten funktioniert?
- … in Erfahrung bringen, ob meine Testspielenden die Regeln schnell erfassen können?
- Ein kurzes und klares Briefing meines Testpublikums:
- Versucht das Spiel so zu spielen, wie es gespielt werden soll, und nicht auf Teufel komm raus jede Schwachstelle zu finden.
- Konzentriert euch auf das Spiel, wie es ist, nicht, wie es eurer Meinung nach werden sollte.
- Sagt mir nach dem Spiel vor allem, was nicht funktioniert hat, was ihr lieber anders hättet lösen wollen, und in welchen Bereich ich noch mehr Arbeit stecken sollte. Das bringt mir viel mehr als ein vages „Ganz nett“.
- Im Vorfeld formulierte Fragen, die ich meinem Testpublikum im Anschluss stellen kann, wie (in Bezug auf „Sandfoot Bay“ zum Beispiel):
- Erzähl mir, was du über die Welt erfahren hast. Wo spielt die Story? Wann?
- Über welche Figur hast du am meisten erfahren? Und was?
- Was könnte das Verbrechen sein, das aufgeklärt werden muss, und wie ist die Hauptfigur darin involviert?
- Was glaubst du, wie die Geschichte weiter (oder aus-)geht?
- Ein Notizbuch, in dem ich meine Beobachtungen festhalte. Ich habe mir dafür das ➜ Fail Faster Playtesting Journal gekauft, weil es genau auf meine Bedürfnisse als Spiele-Entwicklerin zugeschnitten ist.
Einige dieser Tipps sind durch drei lesenswerte Artikel der ➜ League of Gamemakers, „How to Playtest“, inspiriert:
➜ 1. Set the Stage
➜ 2. Game Wreckers
➜ 3. Being a Good Playtester
Wer sehr viel lesen will, findet tonnenweise Tipps beim ➜ Board Game Design Lab.
Antworten