Prototyping

"Great designers do not design great games. They usually design really bad games, and then they iterate on them until the games become great." (Ian Schreiber GamedesignConcepts)
=== Allgemeines ===
Der Produktionsprozess von Computerspielen war zunächst relativ linear, das heißt erst nach vollständigem Abschluss der Planungsphase wurde das Spielkonzept an die Programmierer zur Umsetzung/Implementierung übergeben. Nach Abschluss der Umsetzung durch die Programmierer bestand damit zum ersten Mal die Möglichkeit, die Funktionen, Mechanik, Quests etc. so zu testen, wie sie der Spieler schließlich auch vorfinden würde. Grundlegende Änderungen am Spielkonzept waren dann nur noch schwer zu realisieren, da der gesamte Programmcode zu diesem Zeitpunkt bereits fertiggeschrieben war.
Beim Prototyping geht es darum, die Planungs- und die Umsetzungsphase (durch u.a. die Programmierer) von Anfang an zu verzahnen (siehe Abbildung). Dies geschieht durch die möglichst frühe Verfügbarkeit eines spielbaren Prototyps, der in der Folge immer wieder reevaluiert werden kann (=Iterativer Ansatz). Je häufiger dieser Kreislauf aus "Planung -> Prototyp -> Testspielen -> Evaluation -> Planung" vollzogen wird, desto unwahrscheinlicher sind am Schluss böse Überraschungen, weil grundlegende Mängel im Spielkonzept in den Testphasen erkannt werden können. Dabei gilt: Bei besonders neuen und ungewöhnlichen Konzepten sollte viel Zeit in solche Testdurchläufe gesteckt werden, wohingegen sie bei Erweiterungen bereits erprobter Konzepte (z.B. Battlefield-Klon 71409) minimiert werden kann.
Spielentwickler sollten also versuchen, die Anzahl der Probedurchläufe (Planung -> Prototyp -> Testspielen -> Evaluation) zu maximieren. Das wird am effektivsten erreicht, in dem man sich beim erschaffen des Prototyps nicht verkünstelt, d.h. diesen auf das absolut nötigste beschränkt. Dabei kann es auch helfen, nur einzelne Elemente (z.B. Kampfsystem) des Spiels zu prototypen.
=== Paper-Prototyping ===
Das Paper-Prototyping ermöglicht schnelles und günstiges "Trocken-Testen" ohne programmierten Code. Nebenbei ist man mit dieser Methode flexibel und kann Features oder Designelemente die nicht gut gelungen sind schnell und ohne viel Reue verwerfen. Natürlich gibt es auch Charakteristika eines Spiels, die sich erst durch die Funktionen der tatsächlichen Spieleengine, also sozusagen "realtime" erschließen. Als Spieledesigner sollte man aber die Chance des Paper-Prototyping trotzdem ergreifen, insbesondere da man hier gezwungen ist, sich vor allem auf Spielmechanik und Konzept zu konzentrieren. Somit vermeidet man, sich von den "oberflächlichen" Aspekten des Spiels wie Grafik oder Sound/Musik vom wesentlichen, nämlich einem in sich stimmigen und spaßigen Spielkonzept, ablenken zu lassen. 
Beim Weg des Paper-Prototyping sollte man sich zunächst nur auf die allerwichtigsten Regeln/Features beschränken. Nach der Testphase des "Minimal-Sets" sollte pro weitere Testphase immer nur einzelne Objekte/Funktionen hinzugefügt werden. Dieses Vorgehen ist besser als von Anfang an alle möglichen Objekte/Funktionen bereits im Spiel zu haben und dann herauszufinden, was davon gut oder schlecht ist, eben weil dann immer mehrere infrage kommen. Alle Objekte/Funktionen können Probleme mit sich bringen und so ist es besser, eins nach dem anderen hinzuzufügen. Wenn die Spielmechanismen/Objekte/Menüs etc. erstmal feststehen, darf man nicht vergessen, sie wenigstens Stichpunktartig zu dokumentieren.
Beispiel für (sehr aufwändiges) Paper-Prototyping von MMU: auch Musik und Sound können direkt mit getestet werden. 
=== 3D-Prototyping ===
=== Underplanning vs. Overplanning ===
Bei der Entwicklung von Spielen ist es eine Herausforderung, den schmalen Pfad zwischen einer zu akribischen (Overplanning) oder zu lockeren (Underplanning) Planung zu finden. 
Overplanning beinhaltet die Gefahr, dass sich die exakt ausgearbeiteten Skripte und Ideen überhaupt nicht mit der Spielrealität in den viel zu spät einsetzenden ersten Tests decken. Wer von einem bestimmten Verhalten der Spieleden ausgeht, ohne je selbst das jeweilige Level getestet zu haben, kann bitter enttäuscht werden. Außerdem werden je genauer und aufwändiger die vorherige Planung ist, weniger Veränderungen zugelassen, da man bestehendes nicht zu großen Teilen verwerfen möchte.
Underplanning beinhaltet das Problem, dass Entwickelnde unproduktiv sind und keiner im Team weiß, wofür er zuständig ist. Die Motivation sinkt bei allen Beteiligten und es mangelt an konstruktivem Ideenaustausch. Oft wird zu wenig schriftlich oder grafisch festgehalten und ins Blaue Hinein produziert, bis das Team zerfällt oder es nur schleppend zu Ergebnissen kommt.
Jede/r Spielemachende muss mit der Zeit seine eigene Arbeitsweise finden. Für die meisten Teams ist es empfehlenswert, die Arbeitsweise im Vorab zu diskutieren und für Veränderungen offen zu sein. Außerdem empfiehlt es sich ein sinnvolles Verhältnis von Planen, Testen, Optimieren zu finden und diese drei Schritte immer wieder durchzugehen.
Eine Schwierigkeit ist, dass es noch kein "Patentrezept" für Arbeitsabläufe in der Spieleentwicklung gibt. Vielmehr werden Arbeitsweisen anderer Kreativzweige gedankenlos übernommen und nicht auf die Entwicklerteams angepasst. Nicht umsonst gibt es in der Branche vor Allem Berufsbezeichnungen wie director, producers, junior designer etc und Prozessbezeichnungen wie beta version, preproduction etc. Das Entwickeln von Spielen erfordert aber zum Teil ganz andere Prozesse, die noch erforscht werden dürfen.
=== Quellen/Weiterlesen === 
GamedesignConcepts - Gut geschriebene Einführung zum Thema Gamedesign in 20 Lektionen
Game Prototyping - Kurzvortrag (ca 15 Min + Fragen) mit Tips und Tricks zum Game-Prototyping