Browserspielentwicklung: Teil 2a - Design

Um das Interesse der Community an neuen Konzepten und Einblicken in die Realisierung von Browserspielen zu stillen, möchte das Spacetale-Entwicklerteam in fünf Erfahrungsberichten das Vorgehen von der ersten Idee bis zum fertigen Spiel vorstellen. Der vorliegende zweite Artikel befasst sich mit den allgemeinen Fragen des Spieldesigns. Einen weiteren Einblick in die Entwicklung von Spacetale gewährte die Präsentation "Echtzeit in Browserspielen". Die Besucher der Browsergame Conference 2006 wählten diese zum besten Vortrag der Veranstaltung.

Unten stehende Tabelle stellt Struktur und Inhalt dieser Serie im Überblick dar. Zunächst muss ein Projekt gut geplant werden. In dieser ersten Phase, die der Einleitungsartikel der Serie beschreibt, werden die Weichen für die zukünftige Arbeit gestellt.

Ohne eine ansprechend verpackte, begeisternde Spielstruktur und ohne eine flüssig laufende technische Umsetzung lockt man allerdings heutzutage keine Spieler mehr hinter dem Ofen hervor. Dieser Artikel stellt die Theorien des Spieldesigns am konkreten Beispiel von Spacetale vor. Der Folgeartikel wird die Ableitungen dieser Überlegungen in ein Technisches Design behandeln.

Die dritte Phase der Entwicklung – die Implementierung – beinhaltet die wesentlichen Schritte zur Realisierung des in Phase 2 erstellten Designkonzepts. Wenn das Spiel fertiggestellt ist, muss dafür gesorgt werden, dass es auch gespielt werden kann und dass die Spieler ihre aufgewendete Zeit bestmöglich genießen. Die vierte und fünfte Phase beschreiben deshalb, worauf geachtet werden muss, wenn ein Spiel schließlich online geht.

Teil 2a – Spieldesign

"Das Spiel ist das einzige, was Männer wirklich ernst nehmen. Deshalb sind Spielregeln älter als alle Gesetze der Welt." (http://www.zitate.de)

Design-Dokumente – Am Anfang ist das Schreiben

Der Sinn eines Design-Dokuments ist unbestritten – doch nur wenige Browserspiele haben eines: Man hat eine Idee für ein Browserspiel, es juckt einem in den Fingern und man will so schnell wie möglich Ergebnisse auf dem Bildschirm sehen.

Jetzt noch wochen- oder gar monatelang Ideen ausformulieren, sich über technische Realisierungsmöglichkeiten Gedanken machen und diese auch noch aufschreiben? Oder lieber schnell eine MySQL-Datenbank aufsetzen, mit PHP loslegen und morgen schon eine einfache Portalseite mit Registrierungs- und Login-Funktion online haben?

Viele wählen sicherlich den zweiten Weg. Doch die meisten dieser Projekte werden wohl niemals das Stadium eines fertigen Browserspiels erreichen.

Welche Vorteile hat also ein Design-Dokument?

• Schwachstellen erkennen
  Die Ausarbeitung und Dokumentation des Spielkonzepts sowie dessen technischer Umsetzung zwingt den Entwickler sich intensiver mit seinen Ideen auseinanderzusetzen. Dies wiederrum führt dazu, daß Schwachstellen frühzeitiger entdeckt werden.
  
  
  
  
  
• Gedankliche Stütze für den Entwickler
  
  Auch wenn man sich zum Zeitpunkt der ersten Überlegung noch absolut sicher ist, keines der liebevollen Details jemals zu vergessen – wenn nur genügend Zeit verstreicht, wird man Schwierigkeiten haben, sich im Detail daran zu erinnern. Sind die Ideen hingegen vollständig in einem Design-Dokument niedergeschrieben, ist man schnell wieder in die Materie eingearbeitet und vor allem: Keine Idee fällt unter den Tisch.
  
  
  
  
• Kommunikationsmedium im Team
  Ist das Projekt nicht nur die Arbeit eines einzelnen Entwicklers – und falls dieser Entwickler nicht zufällig ein wortgewandter Businessinformatikdesigner ohne Hunger und Schlafbedürfnis ist, muss es das sein – müssen alle Teammitglieder über die Ideen und Konzepte informiert sein. Sind die Informationen nur im Kopf eines Einzelnen vorhanden – oder schlimmer noch: in den Köpfen von mehreren Teammitgliedern verteilt – hat das Projekt ein Problem.
  

Wenn man sich nun dazu entschlossen hat ein Design-Dokument zu schreiben, stellt sich noch die Frage wie detailliert man seine Konzepte ausformulieren sollte. Je nach Projekt und Team ist der benötigte Detailgrad unterschiedlich hoch. Man sollte allerdings nur soviel schreiben wie zur Gewährleistung der genannten Aufgaben notwendig ist.

Bei der Entwicklung von Spacetale haben wir uns dazu entschlossen ein Design-Dokument mit dem Spielkonzept und ein Technisches Design-Dokument mit dem Umsetzungskonzept zu schreiben.

Spieldesign – Was die Welt im Innersten zusammenhält

Als Spieldesigner ist man ein Gott in der Welt des Spiels und entscheidet selbst was die Welt im Innersten zusammenhält. Doch bevor man zur Tat schreitet und in sieben Tagen sein Spiel erschafft, sollte man sich Überlegen welche Ziele man überhaupt erreichen will und auf welche Weise die fertige Schöpfung gespielt werden soll.

Spielspaß – Mensch ärgere dich nicht!

Uns war klar: Ein Spiel muss Spaß machen, dieser wird im Allgemeinen mit Hilfe von vier Komponenten erzeugt [Lilleike 2006]:

Ziel → Aufgabe → Erfolg → Belohnung

Damit der Spieler die ihm gestellte Aufgabe lösen kann, müssen Entscheidungssituationen geschaffen werden, die es dem Spieler erlauben, den weiteren Verlauf des Spiels zu beeinflussen. Entscheidungen mit Folgen erzeugen Spannung. Doch was macht eine Entscheidung interessant?

Der Spieler muss in der Lage sein, die Auswirkungen der verschiedenen Alternativen abzuschätzen und zu bewerten. Dabei darf es nicht passieren, dass mehrere Alternativen dieselben Auswirkungen haben oder eine Alternative deutlich besser ist als die anderen [Lilleike 2005].

Spielertypen – Killer, Achiever, Explorer und Socializer

Je nach Spielertyp können die genannten Komponenten auf unterschiedliche Arten Spielspaß erzeugen:

• Erfolg
  Von der Meisterung der Spielsteuerung bis zum Retten der Spielwelt.
  
  
  
  
  
• Interaktion
  Vom kurzen Chat bis zur organisierten Kooperation einer Allianz.
  
  
  
  
  
• Konkurrenz
  Vom sportlichen Ehrgeiz einer Rangliste bis zum totalen Konflikt eines Kriegspiels.
  

Eine detaillierte Analyse von Spielertypen in Online-Spielen und deren bevorzugtem Spielverhalten wurde von Richard A. Bartle bereits 1990 durchgeführt [Bartle 1996].

Der permanente Tod – Sterben oder Nichtsterben, das ist hier die Frage

"Wir können nicht alle Helden sein, weil ja irgendeiner am Bordstein stehen und klatschen muss, wenn sie vorüberschreiten." (William Rogers)

Ein wichtiger Aspekt des Spieldesign ist die Frage, ob und in welchem Ausmaß die Spieler auch negative Konsequenzen erleiden sollen.
Soll also ein Charakter sterben können?

Soll ein Sternenimperium komplett ausgelöscht werden können?

Die Frage nach dem permanenten Tod wird kontrovers diskutiert. Spieler wollen einen Helden spielen und Erfolg haben. Ein (Total-)Verlust ihrer Spielfigur wird viele von ihnen frustrieren und ihren Enthusiasmus für das Spiel ausbremsen. Doch wenn niemand Verluste erleiden kann, werden alle Spieler tretmühlenartig immer nur erfolgreicher. Dadurch können Spieler, welche schon länger dabei sind, praktisch nicht mehr von neuen Spielern eingeholt werden – in klassischen Aufbau-Browserspielen führt dies in der Regel zur Erschaffung immer neuer Spielrunden während die alten Runden langsam absterben.

Community – Die Entdeckung der Gemeinsamkeit

Bekanntschaften zu machen ist für viele Spieler sehr wichtig. 50% der weiblichen und 32% der männlichen Spieler halten es für den wichtigsten Aspekt beim Online-spielen [Yee 2003]. Daher ist es wichtig, dass man im Spielkonzept Kommunikations- und Interaktionsmöglichkeiten sowie entsprechende Anreize berücksichtigt.

Bei den meisten Browserspielen ist dies bereits der Fall. Kommunikation ist mittels Chat, Forum, privater Nachrichten oder Teamspeak möglich – die Spieler bilden Allianzen.

Die Bildung von Spielergemeinschaften kann man durch möglichst flexible Organisationsmöglichkeiten innerhalb der Allianz und speziell für Spielergruppen verfügbare Ziele und Belohnungen unterstützen.

Spielweise – Wenn der Wecker zweimal klingelt

Wenn ein Spieler Beziehungsprobleme bekommt, weil mitten in der Nacht "einfach die beste Zeit ist um einen Angriff zu starten", dann ist das aus unserer Sicht ein schwerer Fehler im Spieldesign.

Viele Browserspiele zwingen ihre Spieler dazu zu bestimmten Zeiten online zu sein, wobei das nicht selten zu Stresssituationen im realen Leben führt.

Je nach Tätigkeit des Spielers im realen Leben, hat er andere Anforderungen an die Spielweise des Browserspiels. Berufstätige haben weniger Freizeit und benötigen ein Spiel, indem man erfolgreich sein kann, wenn man sich maximal ein bis zwei mal täglich einloggt. Bevölkerungsgruppen mit mehr Freizeit, beispielsweise Schüler, Studenten und Arbeitslose, spielen auch gerne mehrmals täglich bzw. einige Stunden am Stück.

Man sollte jedoch möglichst vermeiden, dass Spieler gezwungen sind, zu viel Zeit in das Spiel investieren und es somit zu einer Belastung für deren reales Leben wird. Solche Spieler hören meist nach einer intensiven, aber kurzen Zeit mit dem Spiel auf und freuen sich darüber, endlich wieder ein "normales" Leben führen zu können.

Wir haben uns für ein Spielkonzept entschieden, das den Spielern die Freiheit lässt selbst zu entscheiden, wann sie spielen, und das flexibel genug ist die verschiedenen Spielweisen zu ermöglichen.

Spielmechanik – Deus ex machina

Nachdem man sich über diese grundlegenden Konzepte Gedanken gemacht hat, müssen sie konkretisiert werden.

Die Objekte des Spiels – mit ihren Eigenschaften, Bedingungen und Interaktionsmöglichkeiten – müssen zusammen mit den Regeln, nach denen sich diese Objekte verändern können, erstellt werden. Die Spielziele müssen ausformuliert und Aktions- bzw. Entscheidungsmöglichkeiten müssen festgelegt werden. Dabei sollte man die Grenzen der technischen Machbarkeit kennen und berücksichtigen.

In den Regeln kommen erfahrungsgemäß einige mathematische Formeln vor, die man möglichst detailliert ausformulieren sollte. Von unserer Formeln aus dem Design-Dokument hat es allerdings nur ein Teil unverändert ins Spiel geschafft. Einige wurden modifiziert, andere überhaupt erst kurz vor der Implementierung ausformuliert.

Feature Creep – Keep it Simple, Stupid!

Ein häufig auftretendes Phänomen ist der sogenannte Feature Creep. Damit bezeichnet man das Aufblähen des Spiels mit immer weiteren Features. Man sollte darauf achten, dass ein Spiel nicht zu kompliziert wird – sei es durch zahllose Features, undurchschaubare Zusammenhänge oder eine unverständliche Präsentation.

Auch wir haben des Öfteren zum Rotstift gegriffen und Features gestrichen oder vereinfacht.

Spacetale – Der Sprung von Elite zum Cascadis-Sektor

Inspiriert vom Klassiker Elite haben wir mit der Idee gestartet ein Weltraumhändler-Browserspiel zu erschaffen. Schon frühzeitig legten wir fest, dass Spacetale in Echtzeit ablaufen und der Spieler sich frei in der Spielwelt bewegen können sollte. Außerdem wollten wir neben dem wirtschaftlichen Teil einen Schwerpunkt auf Rollenspielelemente und Raumschiffausbau setzen. Zu guter Letzt wollten wir eine Welt erschaffen, die eine lebendige Atmosphäre erzeugt und nicht nur fades Beiwerk ist.

Ausgehend von diesen Vorgaben stürmten wir unsere Gehirne und sammelten alle Ideen die wir uns für ein solches Spiel vorstellen konnten. Die Anzahl der Features war so gewaltig, daß wir sie in drei Kategorien aufteilten: Alpha-Version, Beta-Version und Ausbaustufen.

Für die Alpha-Version schrieben wir ein 87 Seiten starkes Design- Dokument, in welchem wir den genauen Aufbau der Spielwelt, des Charakter-, Wirtschafts- und Fortbewegungssystems sowie alle Aktionsmöglichkeiten des Spielers detailliert fixierten.

Für die Beta-Version haben wir uns für ein anderes Konzept entschieden. Wir verwenden ein sogenanntes agiles Entwicklungsverfahren [Lilleike 2006], d.h. wir arbeiten die Details der neuen Features erst kurz vor ihrer Umsetzung nacheinander aus. Dies hat den Vorteil, dass die ersten Features schneller fertig gestellt werden und seltener konzeptuelle Anpassen vorgenommen werden müssen, da die Konzeptphase zeitlich näher an der Implementierungsphase liegt. Bevor man dieses Entwicklungsverfahren anwendet, sollte man jedoch bereits ein Gesamtkonzept aller Features erstellt haben.

Wie kann man das Spieldesign technisch umsetzen? Der zweite Teil dieses Artikels beschäftigt sich mit den Grundlagen des technischen Designs.

Literaturempfehlungen

Als (Browser-)Spieleentwickler ist es sinnvoll, auf die Kenntnisse anderer Entwickler zurückzugreifen und von deren Erfahrungen zu profitieren. Auch wir von Spacetale haben diesen Rat beherzigt und einige Bücher undWebseiten zur Hilfe genommen. Die wichtigsten davon – sowie die zitierten Quellen – stellen wir euch hier kurz vor:

• Browserspielmagazine
  Browserspielmagazine wie zum Beispiel Galaxy-News, bieten neben einer Browserspielübersicht auch Foren, in denen wir nützliche Informationen zur Browserspielentwicklung gefunden haben.
  
  
  
  
  
• Gamasutra (Englisch)
  Gamasutra hält eine umfassende Sammlung von Artikeln zur Spieleentwicklung bereit. Die Web- seite richtet sich aber nicht ausschließlich an Browserspielentwickler, sondern vielmehr an Computerspieleentwickler im weiteren Sinn. Grundlegende Informationen zum Thema Design sind jedoch auch für Browserspiele relevant und interessant.
  
  
  
  
  
• Designing Virtual Worlds (Englisch)
  Das Buch von Richard A. Bartle bietet einen umfassenden Überblick über das Design von virtuellen Welten, dadurch ist es sehr interessant für Rollenspiele mit einer virtuellen Spielwelt. Da der Autor sich auf Konzepte konzentriert und bei Beispielen oftmals kleinere textbasierte MUDs auswählt, ist dieses Buch – obwohl primär an die Entwickler von großen grafischen Onlinespielen gerichtet – auch für Entwickler eines Browserspiels interessant.
  
  
  
  
  
• Hearts, Clubs, Diamonds, Spades: Players Who Suit MUDs (Englisch)
  In diesem Artikel stellt Richard A. Bartle seine Analyse der Spielertypen von Online-Rollenspielen vor. Es bietet interessante Einblicke in die Beweggründe von Spielern und was ihnen am Spielen am meisten Spaß macht.
  
  
  
  
  
• The Daedalus Project Vol. 1-1 (Englisch)
  
  In dieser Ausgabe des Daedalus-Projekts stellt der Autor (Nicholas Yee) die Ergebnisse einer Umfrage unter Spielern von Online-Spielen nach Spielspaß und Verhalten im Spiel vor. Die Ergebnisse werden insbesondere in Hinblick auf unterschiedliches Spielverhalten von Männern und Frauen präsentiert.
  
  
  
  
• Das Game Design Dokument als Gattungsbegriff
  In diesem Artikel stellt der Autor (Björn Lilleike) verschiedene Aufgaben und Formen von Design Dokumenten vor. Er zieht dabei Parallelen zwischen dem Design Dokument und Architekturzeichnungen.
  
  
  
  
  
• Was Spieler wollen...
  In diesem Artikel beschäftigt sich Björn Lilleike mit dem Problem des Spieldesigners Spielerwünsche und -verhalten zusammenzuführen. Er zieht dabei Parallelen zwischen Spieldesign und Gestaltungsregeln für Gärten.
  
  
  
  
  
• Massively Multiplayer Game Development I & II (Englisch)
  Die beiden Bücher enthalten eine Sammlung von Artikeln zum Spieldesign, technischem Design, Community-Management und Produktionstechniken. Die Autoren sind Entwickler großer grafischer Online-Spiele und Berichten von ihren Erfahrungen bei der Produktion dieser Spiele.
  
  
  
  
  
• Echtzeit in Browserspielen
  In diesem Vortrag beschäftigt sich Michael Wolf, Projektleiter von Spacetale, mit der technischen Umsetzung von Echtzeit in Browserspielen. Die Präsentation wurde auf der Browsergame Conference 2006 zum besten Vortrag der Veranstaltung gewählt.
  
  
  
  
  
• Browsergame Developers Forum
  Das Forum der Browsergame Developer Conference wurde im September 2005 gestartet. Diese Plattform bedient speziell den Informationsbedarf von Browserspielentwicklern. Seit geraumer Zeit ist dieses Forum sehr ruhig, es gibt allerdings durchaus noch einige lesenswerte Themen im Archiv.