Der Produktionsprozess in der Spieleentwicklung und mögliche

Transcription

Der Produktionsprozess in der Spieleentwicklung und eine mögliche Optimierung durch den
Einsat z von Design Pattern
Markus Raab - Diplomarbeit
eingereicht am Fachhochschul - Studiengang Medientechnik und -design in Hagenberg im Juni 2002
© Copyright Markus Raab 2002
Alle Rechte vorbehalten
1. Begutachter: Dr. Michael Haller
Eidesstattliche Erklärung
Ich erkläre hiermit an Eides statt, dass ich die vorliegende Arbeit
selbständig und ohne fremde Hilfe verfasst, andere als die angegebenen
Quellen und Hilfsmittel nicht benutzt und die aus anderen Quellen
entnommenen Stellen als solche gekennzeichnet habe.
Hagenberg, Juni 2002
Markus Raab
iii
Vorwort
Dieses Vorwortes möchte ich nützen, um mich besonders bei meinem
Betreuer an der Fachhochschule Hagenberg, DI Dr. Michael Haller für die
ausgezeichnete Betreuung und hilfreiche Unterstützung bei meiner Diplomarbeit zu bedanken.
Ein weiterer Dank gilt meinen Eltern, die mich während meiner bisherigen Schul- und Studienzeit stets unterstützt und mir diese Ausbildung
ermöglicht haben.
Weiters möchte ich mich auch bei meiner Freundin Astrid, meinem Bruder
Andreas und allen Freunden für die ständig aufmunternden Worte und
der psychologischen Unterstützung bedanken.
iv
Kurzfassung
Der Produktionsprozess in der Spieleentwicklung hat sich seit den
Anfängen der Computerspieleindustrie stark gewandelt. Die Teamzusammensetzungen und die Entwicklungsmethoden benden sich im stetigen
Wandel, um mit der rasanten Entwicklung der Technik Schritt halten
zu können. Durch die hohen Anforderungen, welche durch kurze Entwicklungszeiten und den trotzdem geforderten, perfekten Ergebnissen,
an den Entwicklungsteams lasten, muss ständig nach neuen Technologien gesucht werden, um die Produktionsprozess zu optimieren. Vor
allem die Suche nach allgemein gültigen und anwendbaren Methoden,
welche unabhängig von den verschiedenen Spielgenres und Plattformen
auf denen entwickelt wird, eine Steigerung der Efzienz und der Strukturiertheit der Entwicklungen gewährleisten, ist ein wichtiger Faktor, um
eine Optimierung zu erreichen.
Eine dieser Technologien ist der Einsatz von Design Pattern, welche schon
längere Zeit und mit Erfolg, in der herkömmlichen Softwareindustrie eingesetzt und teilweise auf die Spieleentwicklung adaptiert werden. Doch die
Findung, Dokumentation und Sammlung von neuen, spielespezischen
Design Patterns, muss noch viel intensiver vorangetrieben werden, um
aus einem umfangreichen Katalog verschiedenster Pattern auszuwählen
und diese auch sinnvoll einsetzen zu können. Ob und wie der Einsatz von
verschiedenen Design Pattern den Produktionsprozess beeinussen oder
optimieren könnte, soll im Zuge dieser Arbeit erörtert werden.
v
Abstract
Since the beginning of the Computer Game Industry, the production process in game design has changed enormously. The team structure and
design methods have to change constantly to keep up with the rapid evolution of technique.
Because of the high demands, which are a result of the short development
period and the perfect demanded results of the products, the industry has
to search all the time for new technologies to optimise the production process and to develop satisfying products.
One of the most important things is the search for generally valid and
applicable methods, which are regardless from the specic game genre and
the operating system on which the game will be developed, to increase the
efciency and structure of the developments.
One of these technologies is the usage of Design Patterns. Most of these
Patterns are used in the traditional software industry for a long time and
are adapted successfully by the game designers. But the detection and
documentation of new, game specic Design Patterns are still at the beginnings. The ways how these Design Patterns can affect and optimise the
production process in game design are treated in this thesis.
vi
Inhaltsverzeichnis
Eidesstattliche Erklärung..........................................................................ii
Vorwort.....................................................................................................iv
Kurzfassung..............................................................................................v
Abstract....................................................................................................vi
Inhaltsverzeichnis.....................................................................................vii
Abbildungsverzeichnis...............................................................................ix
1 Einleitung
1
1.1
Motivation
1
1.2
Zielsetzung
2
2 Das Entwicklungsteam
4
2.1 Entwicklung der Spielebranche und Auswirkung auf das
Entwicklungsteam
4
2.2 Denition der unterschiedlichen Entwickler und Abteilungen 6
2.2.1 Management Abteilung
7
2.2.2 Programmierabteilung
9
2.2.3 Graphikabteilung
10
2.2.4 Musikabteilung
10
2.2.5 Support- und Qualitätssicherungsabteilung
11
2.3 Kommunikation im Entwicklungsteam
12
2.3.1 Wodurch entstehen Kommunikationsprobleme
12
2.3.2 Von einer Gruppe zum Team
14
3 Der Produktionsprozess in der Spieleentwicklung
16
3.1 Ablauf des Produktionsprozesses
16
3.1.1 Die Idee vs. Konvertierung und Lizenz
16
3.1.2 Die Designphase
18
3.1.3 Die Pre-Produktion
19
vii
I nhaltsv e rz e ichnis
3.1.4 Die Produktion
20
3.1.5 Die Post-Produktion
20
3.2 Qualitätssicherungsmaßnahmen
21
3.2.1 Meilensteine und Checkpoints
22
3.2.2 Wie läuft Qualitätssicherung ab
22
3.3 Unterschiede im Produktionsprozess durch unterschiedliche
Plattformen
26
3.3.1 Unterschiede zwischen PC und PC
26
3.3.2 Unterschiede zwischen PC und Konsole
26
3.3.3 Unterschiede zwischen Konsole und Konsole
27
4 Softwarekonzepte
29
4.1 Wiederverwendung in der Spieleentwicklung
29
4.1.1 Denition von Patterns
30
4.1.2 Das Pattern Template
31
4.1.3 Kategorien von Patterns
31
4.1.4 Darstellung von Pattern
32
4.2 Design Pattern im Einsatz
33
4.2.1 Das Template Patterns
33
4.2.2 Das Iterator Patterns
36
4.2.3 Das MVC-Konzept und Observer Pattern
39
4.2.4 Das Factory Patterns
43
4.2.5 Das Platzhalter Patterns
47
5 Vergleich mit dem Prototypen
51
5.1 Beschreibung des Prototypen
51
5.2 Optimierung des Prototypen durch den Einsatz von Design
Pattern
53
5.2.1 Einsatz des Template Patterns
53
5.2.2 Einsatz des Iterator Patterns
55
5.2.3 Einsatz des MVC-Konzepts und des Observer
Patterns
57
5.2.4 Einsatz des Factory Patterns
59
5.2.5 Einsatz des Platzhalter Patterns
61
6 Weiterentwicklung der Computerspiele
62
7 Resümee
66
Literaturverzeichnis
68
Anhang 1: Spielebeschreibung des Prototypen
77
Anhang 2: Inhaltsverzeichnis der CD-ROM
79
viii
Abildungsverzeichnis
2.1.: Amstrad CPC 464, gebaut 1984
2.2.: Deer Hunter von Wizard Works
2.3.: Abteilungen einer Spielerma
2.4.: Kreislauf zur Fehlerbehebung im Code
2.5.: Kommunikation zwischen den Entwicklungsteams
3.1.: Die verschiedenen Phasen der Spieleentwicklung
3.2.: Einzelne Stufen bei der Erstellung eines Design Dokuments
3.3.: Mögliche Produktionsverläufe
3.4.: Verschiedene Phasen der Qualitätskontrolle
3.5.: Vergleich PC und Konsole
4.1.: Einteilung der Pattern in drei Kategorien
4.2.: Beispiel für Wiederverwendung gleicher Module
4.3.: Das Spiel Xenon2. Entwickelt von der Firma Bitmap Brothers, 1992
4.4.: Das Spiel Bananoid von William Rieder,1989
4.5.: Klassenstruktur eines Template Patterns
4.6.: Pseudocode des Template Patterns
4.7. :Durchlaufen einer Liste mit Elementen gleichen Typs
4.8.: Klassenstruktur eines Iterator Patterns
4.9.: Pseudocode eines Iterator Patterns in Java
4.10.: Einfaches Schiffe versenken
4.11.: Einfach Ablaufstruktur des MVC-Konzeptes
4.12.: Kommunikationsablauf im MVC-System
4.13.: Observer Pattern im praktischen Einsatz
4.14.: Das Strategiespiel Dune2
4.15.: Command & Conquer zeigt ebenfalls zwei unterschiedliche Ansichten
4.16.: Need for Speed 5 mit verschiedenen Ansichten
ix
Abbildu ngsv e rz e ichnis
4.17.: Screenshot von Aquanoid
4.18.: Pseudocode zeigt praktische Anwendung des Factory Patterns
4.19.: Verschiedene int-Werte stehen für die speziellen Token
4.20.: Aufteilung der Spielbereiche bei Dune2
4.21.: Darstellung möglicher Bereichsaufteilung
4.22.: Vergleich zwei verschiedener Cockpits und selber Strecke bei Stunts
4.23.: Aufteilung der Spielansicht bei Stunts
4.24.: Ablaufdiagramm bei der Wahl der Strecke und des Autos
5.1.: Menü und Hilfeanzeige des Prototypen
5.2.: Das dritte Level des Flashspiels
5.3.: Klassenstruktur des Template Patterns im Bezug auf den Prototypen
5.4.: Screenshot des ersten Levels des Prototypen
5.5.: Verknüpfung zwischen Index und Buchstaben
5.6.: Pseudocode für eine Iterator-Anwendung
5.7.: Beispiel für HUDs beim Prototypen
5.8.: MVC Darstellung bezogen auf den Prototypen
5.9.: Level 4 des Flashspiels
5.10.: Aufteilung des Prototypen in gleichbleibende Teilbereiche
6.1.: Spacewar
6.2.: Pong
6.3.: Moore’s Gesetz
6.4.: 3D Brille - Shutter Glasses
6.5.: Modell eines Caves
6.6.: Datenhandschuh
x
Kapite l
1
Einleitung
1.1 Motivation
Den Anwendern von Spielesoftware ist immer nur das Endergebnis, das
Spiel selbst, ersichtlich. Wie viel Arbeit, Technik und Forschung wirklich
dahinter steckt, um ein erfolgreiches Spiel auf den Markt zu bringen,
kann kaum jemand wirklich beurteilen. Durch das ständige Verlangen
der Konsumenten nach noch mehr und noch besseren Spielen, hat sich
die Spielebranche längst von unabhängigen und zwanglosen Entwicklungsteams, zu leistungsorientierten, unter Erfolgsdruck stehenden Spieleschmieden gewandelt. Um die vorgegebenen Projektziele möglichst efzient
und kostengünstig realisieren zu können, müssen Methoden aus anderen
Softwarebereichen adaptiert und neue Wege gefunden werden, um den
Entwicklungsprozess zu optimieren. In vielen Fällen können Konzepte und
Systeme aus anderen Softwaresparten oder Industriezweigen, wie z.b. der
Filmindustrie, angewandt werden, welche aber trotzdem oftmals erst der
Spielebranche angepasst werden müssen. Durch die knapp bemessene
Entwicklungszeit, welche zum Beispiel durch Lizenzverträge bei Spieleprojekten immer wieder auftritt, kann nicht ständig die Zeit zur Suche
nach den efzientesten Lösungsstrategien für ein Problem und deren
Aufzeichnung aufgewandt werden. So kann es vorkommen, dass ein
ähnliches Problem wieder neu gelöst werden muss, da keine Informationen
mehr über dessen letztmaligen Lösungsweg vorhanden sind.
Die Verwendung von Design Pattern, einem allgemeinen Konzept zur
Beschreibung wiederkehrender Probleme und deren Lösungen, wie es
in den folgenden Kapiteln beschrieben wird, könnte der Spieleentwicklung wertvolle Zeit sparen und wiederkehrende Konikte und Problemsituationen lösen.
1
Einle itu ng
2
1.2 Zielsetzung
In dieser Diplomarbeit soll anhand von Beispielen, Vergleichen und eigenen
Erfahrungen, der Prozess der Spieleentwicklung genauer betrachtet,
analysiert und evaluiert werden. Weiters soll der Frage nachgegangen
werden, ob durch den Einsatz von Design Pattern, der Entwicklungsprozess gegebenenfalls optimiert und/oder vereinfacht werden kann.
Die Design Pattern werden als beispielhafte Anwendung auf einen Prototypen, ein Flashspiel, welches im Verlauf des Praktikums am Fraunhofer
Anwendungszentrum für Computergraphik in Frankfurt realisiert wurde,
angewandt.
Die Informationen für die jeweiligen Kapitel wurden einerseits aus
einschlägiger Literatur bezogen, andererseits von renommierten Spielermen (z.B.: Firma Neo in Wien), um aus erster Hand zu erfahren, wie
diese Unternehmen an den Entwicklungsprozess herangehen und abwickeln.
Kapitel zwei beschäftigt sich mit der allgemeinen Rollenverteilung innerhalb eines Produktionsteams bei einer Spieleentwicklung. Dies dient als
Grundlage für das Verständnis des darauf folgenden Kapitels. Es soll
gezeigt werden, wie viele verschiedene Personen und Abteilungen in einer
Entwicklungsrma nötig sind, um ein erfolgreiches Produkt so efzient als
möglich zu erstellen, und wie eine reibungslose Kommunikation zwischen
den Beteiligten, trotz unterschiedlichster Abteilungen und Wissensgebiete
der Mitarbeiter, gewährleistet werden kann.
Das dritte Kapitel beschreibt den generellen Entwicklungsprozess. In
welche Abschnitte er sich aufteilt, die zeitliche Abfolge und welche Arbeitsschritte die jeweiligen Produktionsstufen enthalten. Es soll hierbei auf
grundlegende Fragen eingegangen werden, wie dieser Prozess von der
Ideenndung, bis hin zum verkaufsreifen Produkt, vonstatten geht. Der
Qualitätssicherung ist ein eigenes Unterkapitel gewidmet, da es ein
wichtiger Bestandteil der Entwicklungsphase ist und sich grundsätzlich
über die gesamte Produktionsdauer erstreckt. Am Ende dieses Kapitels wird
weiters ein Vergleich zwischen PC und Konsolen gezogen, da sich diese im
Entwicklungsprozess stark unterscheiden.
Kapitel vier untersucht eine mögliche Optimierung des Entwicklungs-
2
Einle itu ng
2
prozesses durch den Einsatz von Design Pattern. Hierfür werden bekannte
Pattern aus der herkömmlichen Softwareindustrie verwendet, um diese
auf die Möglichkeit des Einsatzes in der Spieleentwicklung zu überprüfen.
Diese gefundenen Design Pattern sollen anschließend in Kapitel fünf auf
das Flashspiel adaptiert werden, um somit eine mögliche Optimierung der
Implementierungsstruktur und Entwicklungsablauf aufzuzeigen. Anhand
der Erfahrung durch diese schon bekannten Pattern, soll ebenfalls versucht werden, neue Pattern, speziell für die Spieleentwicklung zu nden
und anzuwenden.
3
Kapitel
2
Das Entwicklungsteam
Die Teamgliederung hängt stark von der Unternehmensgröße und
-philosophie ab. In den folgenden Punkten wird eine Teamstruktur
deniert, welche mit kleinen Änderungen und Abweichungen beinahe in
jeder Spieleentwicklungsrma vorzunden ist. Der größte Teil der hier
verwendeten Literatur bezieht sich auf die amerikanische Spieleindustrie,
da Amerika noch immer den Vorreiter in Sachen Computerspieleentwicklung darstellt. Daher ist es auch sehr schwierig, eine allgemein gültige
Regel über die Zusammensetzung von Entwicklungsteams in der Spieleindustrie aufzustellen.
2.1 Entwicklung der Spielebranche und Auswirkung
auf das Entwicklungsteam
Durch den raschen Fortschritt der Technik hat auch die Spieleindustrie
in den letzten 40 Jahren eine rasante Entwicklung vollzogen. Die ersten
Computerspiele wurden von enthusiastischen Amateuren programmiert,
welche für ZX Spectrum, Commodore C64 oder Amstrad CPC 464, siehe
Abbildung 2.1, entwickelten. Durch die geringen Speicherkapazitäten und
den schlechten Grakausgaben war die Spieleentwicklung anfänglich
leider nur sehr beschränkt möglich. Für die Entwickler stellte es kein
großes Problem dar, ein Spiel in “relativ” kurzer Zeit im Alleingang umzusetzen. [Rollings & Morris 2000]. Diese waren somit Programmierer,
Künstler und Verleger in einer Person [Sikora 2002c]. Heutzutage würde
es ebenfalls kein Problem darstellen, seine Spielideen bis hin zum fertigen
Produkt, als Lone Wolf1 zu realisieren. Aber es darf nicht davon ausge-
1 Spieleentwickler, welcher alle Arbeiten selbst erledigt (Programierung, Grak,..)
4
Das Entw ick lu ngste am
2
und
sich
auch
kommerziell
erfolgreich
behaupten
können. Dafür sind
die
Anforderungen
der Konsumenten an
Spielabhandlung und
Grak in der heutigen
Zeit einfach zu hoch
[Gruber 2001b].
Dies soll jedoch nicht
bedeuten, dass erfolgreiche Spiele nur mit
Abb. 2.1 Amstrad CPC 464, gebaut 1984 [Amstrad 2002]
großem nanziellen
und personellen Aufwand entwickelt werden können. Zum Beispiel war
Deer Hunter von , in Abbildung 2.2 dargestellt, eines der am billigsten
produzierten und gleichzeitig eines der verkaufsstärksten Spiele des Jahres
1998. Durch eine innovative Spielidee, einer clevern Vermarktung und
vergleichsweise günstigen Preisen, gingen alleine in den USA mehr als eine
Million Exemplare dieser Jagdsimulation über den Ladentisch [Saltzmann
2000].
Durch die stetig wachsenden Ansprüche und die damit verbundenen Techniken zur Realisierung, wurden immer mehr Leute notwendig, um das
gewünschte Produkt erfolgreich
zu entwickeln. Neue Arbeitsbereiche wurden geboren, um
alle Anforderungen und Techniken realisieren zu können.
Die kleinen “Ein-Mann-Unternehmen” wuchsen zu größeren,
erfolgreicheren aber auch problematischeren Entwicklungsteams [Falstein & Fox 1997].
Abb. 2.2 Deer Hunter von Wizard Works
5
2
Doch diese Wandlung hatte noch weitere markante Veränderungen zufolge:
- Dem Management wurde eine viel wichtigere Rolle zugeschrieben als bisher.
- Ein Spiel zu entwickeln wurde sukzessive teurer, was die Quantität der Spiele
beschränkte, jedoch die Qualität steigerte.
- Da die Spiele nicht nur mehr von einer einzelnen Person produziert wurden, hatten
sie auch nicht bloß den Touch des Einzelnen. Ein gesamtes Entwicklungsteam verleiht den Spielen nun Aussehen und Flair.
- Die Position des Entwicklers (eng.: Designer) und des Programmierers hat sich
in zwei separate Arbeitsbereiche aufgeteilt. Dies muss aber nicht unbedingt bedeuten, dass es nur Vorteile bringt, komplexe Arbeitsbereiche auf mehrere einzelne
Personen aufzuteilen [Rouse 2001]. Probleme solcher Arbeitsbereichsteilung
werden im Punkt 2.3 näher betrachtet.
2.2. Definition der
und Abteilungen
unterschiedlichen
Entwickler
“At least count, it takes about 217 people to design, produce and market
a killer game”
Miller Freeman, Computer Game Developer Conference [Gruber 2001a].
“Yeah, he is right. It takes about 20 to do a game, 10 to market, publish
and sell it, and 187 to stand around, collect salaries and bitch about the
stock dropping”
Mark Shander, Reaktion auf die obige Aussage [Gruber 2001a].
Wie schon anfangs erwähnt, ist es nicht einfach, eine allgemein gültige
Formel für die Zusammensetzung eines Entwicklungsteams zu denieren.
So können folgende Punkte wohl kaum auf ein kleines Unternehmen
projiziert werden. Bei kleineren Spieleschmieden werden oftmals verschiedene Positionen von ein und derselben Person besetzt.
Man darf auch nicht vergessen, dass sich mitteleuropäische Spielermen
noch immer nicht auf derselben Entwicklungsstufe benden wie amerikanische Unternehmen. Europa nähert sich diesem Standard jedoch mit
großen Schritten, wie so manche Erfolgsprodukte aus Europa in Übersee
6
2
zeigen. Ein gutes Beispiel dafür bietet die Spieleentwicklungsrma NEO
in Wien mit der überaus erfolgreichen Konvertierung des PC Spieles Max
Payne2 auf die XBox [NEO 2002; ORF 2002]. Einen groben Überblick über
die verschiedenen Abteilungen bietet Abbildung 2.3.
MANAGEMENT
PROGRAMMIERUNG
GRAPHIK
MUSIK
QUALITÄTSKONTROLLE UND SERVICE
Abb. 2.3 Abteilungen einer Spielerma
2.2.1. Management Abteilung
Software-Entwickler (eng.: Software Planner)
Das Design Dokument ist das Fundament für die Arbeit des SoftwareEntwicklers. Er ist verantwortlich für die Aufspaltung des Game Designs
in funktionelle und technische Anforderungen (z.B. Planung der Game
Engine, Grak Engine, etc.). Diese Gliederung dient zur Ressourcen- und
Zeitplanung für das gesamte Projekt. Tauchen Fragen oder Probleme
betreffend dem Design Dokument auf, werden diese gemeinsam mit dem
Spielegestalter und/oder dem Technischen-Leiter behandelt.
Technischer-Leiter (eng.: Lead Architect)
Dieser deniert die modularen Strukturen eines Spieles und arbeitet
eng mit dem Chefprogrammierer zusammen. Er kontrolliert den Code,
welchen er vom Chefprogrammierer bekommt, auf seine Richtigkeit und
Funktionalität. Zusammen mit dem QS-Leiter sucht er nach Unge-
2 Max Payne wurde von der nnischen Firma Remedy, mit Unterstützung von
3DRealms, entwickelt.
7
2
reimtheiten, sogenannten Snags, in der Implementierung. Diese werden
erneut dem Chefprogrammierer mitgeteilt, welcher sie zur Behebung an
die jeweiligen Programmierer aufteilt. Dieser Kreislauf wird in Abbildung
2.4 dargestellt.
QS-LEITER
TECHNISCHER
LEITER
Quell
Code
Kontrolle
CHEF
PROGRAMMIERER
QUELLCODE
OK
ja
nein
bug fixing
snags
Abb. 2.3 Abteilungen einer Spielerma
Der Technische-Leiter beteiligt sich normalerweise ebenfalls an der Programmierung. Doch durch die vielen Implementierungsüberprüfungen die
er durchführen muss, den sogenannten Codereviews, hat er meist nur
wenig Zeit, selbst Sourcecode zu generieren.
Projektmanager (eng.: Project Manager)
Der Projektmanager kommuniziert nicht direkt mit den einzelnen Programmierern oder Grakern, sondern kontaktiert diese nur über die einzelnen
Leiter der Teams. Das dient vor allem dazu, kein konfuses Durcheinander
in den Teams zu erzeugen, und es wird verhindert, dass etwaige Entscheidungen ohne dem Teamleiter getroffen werden. Er agiert grundsätzlich
als Schnittstelle zwischen den Projektteams, dem Management und dem
Marketing.
Spielegestalter (eng.: Game Designer)
Viele Arbeiten in der Spielentwicklung werden dem Spielegestalter zugeschrieben. Überwiegend ist er jedoch mit viel Schreibarbeit belastet. Er
8
2
erstellt das Design Dokument (näheres im Punkt 3) und ist für die Spiellogik, die Dialoge, die Spielabhandlung, eigentlich für das gesamte Look
and Feel des Spiels verantwortlich. Deshalb ist es wichtig, dass er viel
Programmierverständnis, aber auch ausgeprägte grasche Fähigkeiten
aufweist, da er beides zur effektiven Umsetzung des Design Dokumentes
benötigt. Dieses Allgemeinwissen ist ihm auch in den dauernden
Gesprächen und Diskussionen mit den anderen Teamleitern von großem
Nutzen. Wie schon erwähnt, ist der Spielegestalter der Chef über das Game
Design Dokument und ist deshalb der Einzige, welcher Veränderungen an
dem Dokument vornehmen darf. Er kontrolliert, durch Meetings mit den
jeweiligen Teamleitern, den geradlinigen und dokumentgetreuen Ablauf
des Produktionsprozesses.
2.2.2. Programmierabteilung
Chefprogrammierer (eng.: Lead Programmer)
Dieser weist die meiste Erfahrung und Programmierfähigkeit in der Programmierabteilung auf. Bei großen und komplexen Projekten ist der Chefprogrammierer oftmals mehr damit beschäftig zu organisieren und zu
managen, als zu programmieren. Mit dem Software-Entwickler diskutiert
er die codespezischen Implementierungsprobleme und teilt die vorgegebenen Module des Technischen-Leiters in funktionale Teile auf, welche
er unter den Programmierern verteilt. Durch Meetings mit dem Projektmanager, versucht er das Projekt auf dem richtigen Kurs zu halten.
Programmierer (eng.: Programmer)
Jeder Programmierer arbeitet meistens an einem eigenständigen Abschnitt
des Spieles (z.B. Steuerung oder Highscore, etc.). Unter den einzelnen
Programmierern muss eine rege Kommunikation herrschen, damit
Überschneidungen oder auftretende Probleme so schnell wie möglich
erkannt und gelöst werden können. Natürlich ist hier auch der Chefprogrammierer gefordert, um die Vorgaben des Technischen-Leiters und des
Software-Entwicklers gezielt und gut strukturiert an die einzelnen Programmierer zu verteilen.
9
2
2.2.3. Graphikabteilung
Gestalterische-Leiter (eng.: Lead Artist)
Es ist durchaus möglich, im Gegensatz zu den anderen Positionen, dass
der Gestalterische-Leiter an mehreren Projekten gleichzeitig arbeitet. Bei
der Spielerma NEO in Wien, konzentrieren sich die Graker und Künstler
jedoch immer nur auf das gerade aktuelle Projekt [NEO 2002].
Er verbringt die meiste Zeit mit Zeichnen und Gestalten von Entwürfen
und Skizzen. Er steht im dauernden Kontakt zum Chefprogrammierer und
dem Spielegestalter, um sicher zu gehen, dass seine Entwürfe auch den
technischen Möglichkeiten gerecht werden und den Vorgaben des Design
Dokuments entsprechen.
Künstler (eng.: Artist)
Hier ist es ähnlich wie bei den Programmierern. Der Künstler bekommt seine
Aufgaben vom Gestalterischen-Leiter zugeteilt und steht im dauernden
Kontakt zu den anderen Teamkollegen. Auch er kann gegebenenfalls bei
mehreren Projekten gleichzeitig beschäftigt sein.
2.2.4. Musikabteilung
Komponist (eng.: Composer)
Der Komponist entwickelt keine eigenen Musikstücke, sondern überprüft
die fertigen Produkte des Musikers und teilt dem Effekt-Techniker mit, wie
er diese weiter zu behandeln hat. Er spricht sich mit dem Spielegestalter
ab, welche Musikstücke benötigt werden und welche Stimmung sie vermitteln sollen. Mit dem Chefprogrammierer bestimmt er die technischen
Anforderungen der Musikles (z.B. Format, Bitfrequenz, etc). Wenn viel
interaktive Musik (d.h. Tempo- oder Stimmungsveränderungen während
des Spiels) benötigt wird, muss der Komponist enger mit der Programmierabteilung zusammenarbeiten, um die Musikles dem jeweiligen Spielverlauf anzupassen.
10
2
Musiker (eng.: Musician)
Dieser bekommt seine Aufträge direkt vom Komponist. Er erstellt ganze
Lieder, Musikles, etc.
Effekt Techniker (eng.: Sound Effect Technician)
Der Effekt-Techniker produziert Effekte wie Gewehrschüsse, Fußschritte,
Umgebungsgeräusche, etc. und bearbeitet oftmals die Musikles des
Musikers, damit sie den Vorschriften des Design Dokuments entsprechen.
Viele dieser Musikles werden in Bibliotheken aufbewahrt, um gegebenenfalls wiederverwendet zu werden.
In kleineren Unternehmen kann man diese drei Rollen ohne Probleme zu
einer einzigen zusammenfassen.
2.2.5. Support- und Qualitätssicherungsabteilung
QS-Leiter (eng.: Lead QA)
Dieser erstellt Testpläne, um Fehler in den einzelnen Modulen3 zu nden
und reicht diese Pläne an den QS-Techniker weiter. Die Auswertungen
der Testpläne werden an den Projektmanager weitergeleitet, welcher die
entsprechenden Abteilungen zur Fehlerbehebung informiert.
QS-Techniker (eng.: QA Technician, Playtester)
Der QS-Techniker muss in ewig langen Spielsessions versuchen, Fehler
im Spielablauf zu nden und diese auf Kommando erneut erzeugen. Dies
ist unbedingt notwendig, damit ein Debugger der Programmierabteilung
zur genauen Fehlerortung im Quellcode integriert werden kann. Aber
auch Ungereimtheiten bei Gestaltung und Spiellogik sollen vom QS-Techniker erkannt werden. Die so eruierten Fehler werden in den dafür vorgesehenen Testplänen vermerkt. Natürlich muss jede beliebige Fassung des
Spieles (egal ob englisch, deutsch, etc.) eigenständig getestet werden.
3 Module können alle möglichen Entwicklungen während der Produktionsphase sein,
die zur Realisierung des Spieles notwendig sind. Zum Beispiel 3D-Objekte, Quellcode,
Musikles, Textles,....
11
2
Servicetechniker (eng.: Support Technician)
Die Servicetechniker sind für die restlichen Arbeiten im Unternehmen verantwortlich. Sie betreuen Netzwerke und Datenbanken, können aber auch
für Spezialfälle wie zum Beispiel Motion Capturing eingesetzt werden.
Folgende Literatur wurde zur Erstellung des Kapitel 2.2 verwendet [NEO
2002; Sikora 2001d; Rollings & Morris 2000; Gruber 2001].
2.3. Kommunikation im Entwicklungsteam
“When you get a group of egocentric and intelligent people in the same
room together, there is usually only one predictable result: trouble.”
Andrew Rollings [Rollings 2000; Rollings & Morris 2000]
Befasst man sich näher mit der Teaminteraktion in der heutigen Softwareindustrie, wird schnell ersichtlich, dass diese in der Spielentwicklung viel komplexer ablaufen muss, um einen reibungslosen Produktionsprozess zu gewährleisten. Die verschiedenen Abteilungen müssen viel enger
zusammenarbeiten, mehr miteinander kommunizieren und die Probleme
und Anliegen anderer auch wirklich verstehen [Sanchez & Dalmau 2001].
Eine einfache Darstellung der Kommunikation zwischen den Teams ist in
Abbildung 2.5 zu sehen.
2.3.1 Wodurch entstehen Kommunikationsprobleme
Jedes Spiel muss einen gewissen Kick, ein jugendliches Flair aufweisen,
um sich im ewigen Kampf um Verkaufszahlen und Akzeptanz bei den
Anwendern behaupten zu können. Computerspiele haben einen wichtigen
und gesicherten Platz in der heutigen Gesellschaft eingenommen. Die einstmaligen “Amateurprogrammierer” haben sich von einsamen, unbekannten Garagenhackern, zu erfolgreichen und beneideten Spielentwickler gemausert.
Werden in dieser Branche neue Kräfte in einem Unternehmen gesucht, dann
12
2
wohl kaum alteingesessene Design- oder Programmiergurus, sondern
junge, dynamische, am Nerv der Zeit wirkende Entwickler, welche den
Trend der Computerspiele nur zu gut kennen, besser gesagt erkennen
[Rollings & Morris 2000; Falstein & Fox 1997]. Viele dieser jungen Genies
sind, durchaus berechtigt, sehr von ihrer Persönlichkeit und ihren Leistungen überzeugt. Darum ist es oft so schwierig, diese Individualisten in
ein Team zu integrieren, wo Erfahrungsaustausch, Mitarbeiterakzeptanz
und Gemeinschaftssinn die wichtigsten Faktoren einer harmonischen
Zusammenarbeit darstellen [Falstein & Fox 1997]
Artist 1
..
Artist X
Lead Artist
Progr. 1
..
Progr. X
Lead Progr.
Musiker
QA Tech.
Sound Effekt
Techniker
Support Tech.
Composer
Marketing
Projekt
Manager
Game
Designer
Lead QA
Lead
Architekt
Software
Planer
Legende:
Projekt Manager gilt als allgemeine Schnittstelle für die gesamten Abteilungen
Kommunikation zur Behebung von snags im Code
Kontrolle der Design-Dokument-Vorschriften durch Meetings und Besprechungen
In der Managementabteilung herrscht stetig rege Kommunikation untereinander
Die einzelnen Teamleader sind die Kontaktperson nach außen
Absprache für korrekten und reibungslosen Projektverlauf
Abb. 2.5 Kommunikation zwischen den Entwicklungsteams
13
2
Da kein Entwickler heutzutage mehr alleine verantwortlich ist für Entwurf,
Programmierung, Grak und Vermarktung (siehe Punkt 2.1) und die
einzelnen Entwicklungsbereiche voneinander getrennt werden, kann es
unter den, oftmals mit fachspezischem Wissen gesegneten Mitarbeitern
der jeweiligen Abteilungen, zu Verständnisproblemen in Gesprächen und
Diskussionen untereinander kommen. Aber das Wissen über die Arbeitsweisen und Probleme der anderen Entwicklungsbereiche und deren Interaktion miteinander, ist ein grundlegender Stützpfeiler für ein erfolgreiches Produkt. Vor allem in der Spieleindustrie ist diese Interaktion noch
mehr erforderlich als in anderen Softwarebereichen [Sanchez & Dalmau
2001]. Einige verschiedene Typen von Spielentwicklern und deren Verhaltensproblematik in Teams, sind im Buch Game, Architecture and Design
von Andrew Rollings ausgezeichnet beschrieben [Rollings & Morris 2000].
2.3.2. Von einer Gruppe zum Team
Viele Faktoren müssen berücksichtigt werden, wenn ein innovatives Team
von Entwicklern gut zusammenarbeiten und verständlich zwischen den
verschiedenen Abteilungen kommunizieren soll. Für den reibungsfreien
Ablauf in der Gruppe ist größtenteils der Leiter jedes Teams verantwortlich. Natürlich muss schon auf unternehmensweiter Ebene ein ausgereiftes Managementsystem seinen Dienst leisten, aber jeder Einzelne
kann und muss seinen Anteil zum gelungenen Informationsuss untereinander beitragen. Folgende Punkte können viel zu einem gelungenen
Kommunikationsverhalten innerhalb des Unternehmens beitragen.
- Eine gute Kommunikation und Informationsverteilung auf unternehmensweiter Ebene ist die Grundvoraussetzung für den gleichen Wissensstandard eines jeden Mitarbeiters. NEO setzt für jede Abteilung eine
Art Tagebuch, rmeninterne Webpage ein, in dem jeder freien Zugang und
Änderungsmöglichkeit hat. Treten interne Fehler oder Probleme jeglicher
Art auf, so können diese diskutiert und gegebenenfalls behoben werden.
Durch diesen allgemeinen Zugang zu den Informationen und Problemen
können meist sehr schnell Lösungen gefunden werden, und der Infor-
14
2
mationen und Problemen können meist sehr schnell Lösungen gefunden
werden und der Informationsstandard der Mitarbeiter wird auf etwa
gleichem Level gehalten [NEO 2002].
Weiterst können regelmäßig angesetzte Meetings, auch wenn sie nur von
kurzer Dauer sind, viel zum Informationsuss und Wissensaustausch beitragen.
- Die Meinung und Ansichten jedes einzelnen Mitarbeiters muss von jedem
seiner Kollegen voll und ganz akzeptiert werden. Gerade in der Spielebranche, wo viele exzellente Graker und Programmierer gemeinsam
arbeiten, kann es leicht zu Spannungen zwischen den einzelnen Mitarbeitern kommen.
- Falls es trotzdem zu Konikten kommt, sollte man versuchen jene
nicht auf persönlicher Ebene zu klären, sondern immer sachlich
und rmenbezogen zu bleiben. Außerdem kann ein vorher deniertes
Koniktlösungssystem viel Stress und Sorge ersparen.
- Wie schon kurz angesprochen, sollte immer eine Person im Team als
Schnittstelle nach außen festgelegt werden (meist der Teamleader) [Rouse
2001]. Da die jeweiligen Pichten und Aufgaben x festgelegt werden,
kann man durch eine klar denierte Hierarchie, den Kommunikationsablauf klar und leicht durchschaubar halten [Falstein & Fox 1997].
15
Kapite l
3
Der Produktionsprozess
3.1 Ablauf des Produktionsprozesses
Jede Spieleschmiede hat ihre eigenen Vorstellungen und Praktiken wie sie
ein Spiel, von der Idee bis zum verkaufsreifen Produkt, umsetzen. Größere
Unterschiede im Produktionsablauf sind eigentlich nur bei Entwicklungen
für verschiedene Plattformen erkennbar (siehe Punkt 3.3). Jedoch sind in
jedem Unternehmen grundlegend die selben Entwicklungsphasen vorzunden. Differenzen lassen sich vor allem bei den Bezeichnungen und durch
spezischere Abweichungen in den einzelnen Produktionsabschnitten
erkennen. In Abbildung 3.1 werden die fünf wichtigsten Punkte im Produktionsverlauf dargestellt. Natürlich sind die jeweiligen Phasen nicht so
strikt getrennt wie hier abgebildet, sondern überlappen sich teilweise und
laufen kurze Zeit parallel. Zur Übersicht und Orientierung genügt diese
Darstellung aber allemal [Lamaree 2002; Rollings & Morris 2000; NEO
2002].
IDEE
DESIGNPHASE
PRE-PRODUKTION
PRODUKTION
POST-PRODUKTION
QUALITÄTSSICHERUNG
Abb. 3.1 Die verschiedenen Phasen der Spieleentwicklung
3.1.1 DIE IDEE VS. KONVERTIERUNG UND LIZENZ
In den Spieleentwicklungsrmen werden nicht nur ständig neue Ideen
16
De r Pro du k tio nsp ro z e ss
2
für erfolgreiche Spiele geboren und umgesetzt, sondern viele Unternehmen
werden mit der Konvertierung eines bereits bestehenden Spieles auf ein
anderes System4 oder der Umsetzung einer bestehenden Lizenz beauftragt
(z.B.: aus einem James Bond Film soll ein PC-Spiel entstehen,...).
Bei Konvertierungen entfällt natürlich die Phase der Ideenndung. Die
Spielhandlung und der Spielablauf sind bereits vorgegeben. Jedoch hat
z.B. jede Konsole ihre eigenen Vorschriften und Hardwarespezikationen
welche einzuhalten sind (vgl. Kapitel 3.2.2). Die Unterschiede zwischen
den einzelnen Systemen, werden im Kapitel 3.3.3 genauer erläutert.
Bei der Umsetzung bekannter Lizenzen steckt schon einiges mehr an
Arbeit in der Entwicklung. Es muss zwar ein Designdokument, wenn auch
nicht so aufwändig wie bei eigenen Ideen, angefertigt werden, die meisten
graphischen Spielmodule (z.B.: Charaktere, Hintergründe, 3D-Objekte,...)
sind jedoch durch die Lizenz bereits vorgegeben. Vor allem die Graker
sind deshalb in ihrer Kreativität stark eingeschränkt, da sie keine neuen
Kreationen erstellen müssen, sondern nur nach Vorlage gestalten. Meist
sind auch schon vorgegebene Spielabläufe deniert, an welche man sich
als Entwickler halten muss (z.B.: Indiana Jones 3 von Lucas Art). Ein weiterer Nachteil ist der meist straffe Zeitplan der bei einer Lizenzumsetzung
einzuhalten ist und das sich daraus ergebende Vorurteil, dass lizenzierte
Produkte immer von schlechterer Qualität sind. Da aber viel Geld für den
Verleger auf dem Spiel steht, kann er sich keine unzuverlässigen Partner
für die Umsetzung seiner Lizenz suchen. Deshalb wird viel Vertrauen in
das Unternehmen gesetzt, was wiederum Achtung und Prestige für die
Entwickler bringt [Saltzmann 2000].
Am meisten Herausforderung und Motivation bringt jedoch die Umsetzung neuer, eigener Ideen. Aber gute Ideen müssen zuerst einmal geboren
und ausgebrütet werden, bevor man versuchen kann daraus einen Kassenschlager zu produzieren. Selbst in der allerersten Phase, der Ideenndung, können schon einige Fehler begangen werden, um den erfolgreichen Produktionsverlauf von vornherein zum Scheitern zu verurteilen.
Die Idee muss vorerst im Gedächtnis heranwachsen und reifen. Erst nach
einigen Tagen oder Wochen, wenn gedanklich die vielen Fakten und Elemente des Spieles zusammengetragen und durchgedacht sind, kann begonnen werden, eine sogenannte Featurelist zusammenzustellen. Diese besteht
4 Zum Beispiel die Konvertierung des Spieles Max Payne vom PC auf die XBox durch
die Firma NEO in Wien
17
2
aus ungeordneten Niederschriften von Ideen und Vorstellungen das
Spiel betreffend. Mit einem Design Dokument hat dies allerdings noch
nichts zu tun. Erst nach dem sogenannten Test der Zeit5 soll mit der
Designphase des Spiels begonnen werden [Laramee 2002; Sikora 2002a].
3.1.2 Die Designphase
Hat die Idee den Test der Zeit standgehalten, kann nun begonnen werden,
eine Kurzfassung des Design Dokumentes zu erstellen. Dieses wird auch
Design Treatment genannt und ist der erste von drei Abschnitten, siehe
Abbildung 3.2, in der Designphase. Es soll nur einige Seiten umfassen
und die wichtigsten Punkte des Spiels denieren. Da es auch dazu dient,
Kurzes Design Dokument
„DESIGN TREATMENT“
Grobfassung des DD
„PRELIMINARY DOCUMENT“
Endfassung des DD
„FINAL GAME DESIGN
DOCUMENT“
Abb. 3.2 Einzelne Stufen bei der Erstellung eines Design Dokuments
dem Verleger die Idee zu präsentieren, müssen hier noch keine genauen
technischen Anforderungen deniert werden. NEO in Wien muss dieses
Kurzdokument nach Amerika zu Take26 schicken. Dort wird die Idee auf
die Möglichkeit (Originalität, Marktverlangen,....) der Umsetzung geprüft.
Dieser Abschnitt der Designphase wird bei NEO Pitchshifting-Phase genannt.
Ist Take2 mit dem Kurzdokument zufrieden, kann mit der Grobfassung
des Design Dokumentes - Preliminary Design Document (PDD) - begonnen
werden [NEO 2002]. Diese Niederschrift kann auch als eine organisierte
Liste von Features gesehen werden [Lamaree 2002]. Es sollen technische
Spezikationen, die Hintergrundstory, Animationen, Filme, Charaktere,
etc. schon ziemlich genau beschrieben und deniert werden. Dieses Dokument soll dazu dienen, die Anforderungen so gezielt wie möglich festzuhalten. Im Kreise der Abteilungsleiter wird diese Grobfassung diskutiert
und auf die Realisierbarkeit geprüft. Wenn nötig, werden Veränderungen
oder Verfeinerungen vorgenommen und erneut gemeinsam veriziert.
5 Für einige Wochen sollte man die gesamten Notizen und Fakten beiseite räumen und
so wenig als möglich überhaupt über das Spiel, die Idee nachdenken. Erst am Ende
dieser Zeit, wenn man erneut seine Notizen durchblättert und noch immer begeistert
davon ist, soll man sich die Mühe machen und das Projekt fortsetzen [Sikora 2002a].
6 Take2 ist ein weltweiter Verleger, Entwickler und Händler von Konsolen- und Computerspielen mit Sitz in New York. Seit einem Jahr ist NEO eine hundertprozentige
Tochtergesellschaft von Take2.
18
2
Erst wenn diese Grobfassung von jedem Beteiligten eine positive Zusage
bekommt, wird mit dem Final Game Design Document, kurz GDD, begonnen.
Das GDD soll zwar soviel Information wie möglich enthalten, es muss
jedoch stets auch auf eine klare und logische Struktur im Dokument
geachtet werden. Je nach Spielgenre und Komplexität des Spieles, hat
ein GDD im Durchschnitt 100 bis 300 Seiten. Zu den gesamten Fakten
des Preliminary Design Documents sollen hier eine noch detailliertere Beschreibung der einzelnen Module und Produktionsbereiche angefügt
werden. Vor allem das Zusammenwirken der einzelnen denierten Module
im PDD und der sich daraus ergebende Spielablauf soll festgehalten
werden. Das nale Design Dokument muss als Grundlage für alle Fragen
und Probleme während der Produktionsphase dienen. Ist das GDD endlich
fertig gestellt, erreicht man den sogenannten Point Of No Return. Bis hier
hin kann man ein Projekt noch abbrechen, ohne eine Unmenge an Zeit
und Geld verschwendet zu haben.
3.1.3 Die Pre-Produktion
Bevor nun endgültig mit der Produktion und Implementierung begonnen
werden kann, müssen noch einige Produktspezikationen festgelegt werden,
um eine klare und reibungslose Produktionsphase zu gewährleisten. Es
werden alle notwendigen Arbeiten des Teams aufgelistet und in sinnvolle
Arbeitsmodule unterteilt. Diese sind zum Beispiel die Erstellung von
Soundeffekten, 3D-Modellen, Texturen, Algorithmen für Game Engine, etc.
Ebenfalls entsteht in dieser Phase ein detaillierter Projektplan mit den Verantwortlichkeiten der Teammitglieder, Festlegung der Meilensteine und
einem Budgetplan [Lamaree 2002]. Werden im Spiel Filmsequenzen oder
längere Animationen verwendet, werden in dieser Phase die Storybords
dafür erstellt.
19
2
3.1.4 Die Produktion
Als Grundlage für die Produktion dient das nale Game Design Dokument. Dieses soll in der Produktionsphase nicht mehr verändert werden.
Oftmals tauchen jedoch während der Entwicklung neue Ideen auf, welche
dem Spiel mehr Spaß und Pep verleihen könnten. Das Einfügen dieser
nachträglich gewünschten Elemente wird in der Fachsprache als Feature
Creep bezeichnet [Sikora 2002b; Rollings & Morris 2000; Sikora 2002d].
Da sie in der Designphase nicht eingeplant wurden, entwickeln sich diese
Features meistens zu sehr kosten- und zeitintensiven Erweiterungen. So
weit als möglich sollten die Probleme durch Feature Creeps schon in der
Design Phase behoben werden. Außerdem kommt es meist gar nicht auf
einzelne, nachträgliche eingebaute Elemente oder Effekte an. Wenn eine
Spielidee gut ist, dann kann man auf nachträglich eingefügte Features
ohnehin verzichten. Wären diese aber unerlässlich für den Erfolg des
Produktes, wird wohl das gesamte Projekt von vornherein eine schlechte
Idee oder Fehlplanung gewesen sein [NEO 2002].
Um den reibungslosen und erfolgreichen Entwicklungsablauf in der
Produktion zu gewährleisten, sind die ständige Qualitätskontrolle und der
Einsatz von wirkungsvollen Meilensteinen und Checkpoints unerlässlich.
Mehr zu diesem Thema aber im Punkt 3.2.
3.1.5 Die Post-Produktion
Bevor das fertige Produkt dem Verleger überreicht werden kann, muss
sicher gestellt werden, dass alles perfekt und sauber läuft. Die letzten
Snags und Fehler sollten in dieser Zeit behoben werden. Da diese Phase
wegen Terminverzögerungen und kurzfristigen Problemen meist von Stress
gezeichnet ist, wird sie in der Spieleindustrie auch Crunch Time genannt.
Am besten wäre, wenn das Produkt schon am Ende der Produktionsphase
fertig wird und diese Zeit nun zum “Aufpolieren” des Spiels verwendet
werden könnte. Leider ist dies nur sehr selten der Fall. Wie viel Zeit nun
tatsächlich für die Restarbeiten übrig bleibt und wie viel an Mehrarbeit für
die Entwickler noch zu bewältigen ist, hängt stark von der anfänglichen,
20
2
professionellen und gelungenen Zeit- und Ressourcenplanung und dem
Gesamtmanagement des Projektes ab [Sikora 2002d].
3.2 Qualitätssicherungsmaßnahmen
3.2.1 Meilensteine & Checkpoints
“Just as mountaineers are warned not to eat yellow snow, you have been
warned not to tolerate fuzzy milestones”
[Rollings & Morris 2000]
Jedermann arbeitet lieber ohne ständigen Termindruck oder einzuhaltende
Abgabefristen. Meilensteine (MS) und Checkpoints (CP) sollen allerdings
nicht als Druckmittel der Vorgesetzten gesehen werden, sondern als Wegweiser für einen erfolgreichen, efzienten und möglichst geradlinigen
Produktionsverlauf (Siehe Abb. 3.3).
Projektstart
CP
MS
Projektende
Geradliniger, erfolgreicher
Entwicklungsverlauf
Fehlerhafter, zielloser Entwicklungsverlauf ohne CP und MS
Abb. 3.3 Mögliche Produktionsverläufe
Die Denition von Meilensteinen und Checkpoints muss vorher gründlich
analysiert und kalkuliert werden. Oftmals werden sie einfach nach dem
Prinzip pick a date and hope for the best oder nach eigenen Wunschvorstellungen der Verleger gewählt [Rollings & Morris 2000]. Nicht nur
dass durch solch unprofessionelles Handeln der gesamte Entwicklungs-
21
2
ablauf gefährdet ist, auch die Motivation der beteiligten Entwickler sinkt
durch diese verschwommenen und undurchsichtigen Zielsetzungen rapide.
Es kommt noch hinzu, dass die Abstände der Festsetzung oftmals zu
eng oder zu weit angelegt werden. Beides dient kaum zur Steigerung der
Produktivität sondern setzt entweder die jeweiligen Entwickler zu stark
unter Druck oder verleiht zu einem unabsichtlichen Abgleiten von der
geradlinigen Bahn zum Ziel. Ein guter Mittelwert der Abstände zwischen
Meilensteinen ist ein bis zwei Monate und bei Checkpoints zwischen vier
und zehn Tagen. Ein weiterer schwerwiegender Fehler ist eine ungenaue
Denition der jeweiligen MS oder CP. Wird dieser Punkt anfangs nur
unklar oder unzureichend deniert, können die Beteiligten können bei der
Abnahme des Meilensteins verschiedene Ansichten und Erwartungen des
Ergebnisses haben. Damit kann es sehr leicht zu Missverständnissen und
Streitigkeiten im Team kommen. Ein gut denierter Meilenstein darf keine
Fragen offen lassen. Er muss so klar und präzise festgelegt werden, dass er
als Ergebnis nur “0” oder “1” zulässt - geschafft oder nicht geschafft. Fallbeispiel 3.1 zeigt ein einfaches Beispiel für Zweideutigkeiten bei Zieldenitionen.
Da die Meilensteine meist auch dem Verleger als Kontrolle vorgelegt
werden, sollen diese wenn möglich immer so angesetzt werden, dass der
Fortschritt der Entwicklung auch ohne Fachkenntnisse sichtbar ist und
einen guten Eindruck hinterlässt. Im Gegensatz dazu, dienen die Checkpoints nur dem Entwicklungsteam, um den Produktionsverlauf nach Plan
durchzuführen. [Pedersen 2001; Sikora 2001d; NEO 2002]
3.2.2 Wie läuft die Qualitätssicherung ab
Grundlegend gibt es zwei Ursachen, warum ein Spiel am Ende der Entwicklung noch immer mit zahlreichen Fehlern übersäht ist. Entweder
wurde die Zeit bis zum Abgabetermin des Spieles zu knapp und der Verleger brachte das Spiel trotzdem Termingerecht auf den Markt, oder das
Testen wurde unprofessionell und minderwertig durchgeführt [Rollings
& Morris 2000]. Wird ein Spiel auf den Markt geworfen, welches vorher
unzureichend oder schlecht getestet wurde, verliert es trotz vielleicht guter
22
2
Fallbeispiel 3.1 [Rollings & Morris 2000]
Ausgangspunkt ist ein Blatt Papier mit 5
Punkten (rechts).
Definition des Meilensteins durch den
Auftraggeber: „Verbinden Sie Punkt A mit
Punkt B.“
B
A
E
D
C
B
A
E
D
C
Mitarbeiter XY wird mit der Lösung dieses
Problems beauftragt und erhält folgendes
Ergebnis (links).
Dieses Ergebnis ist natürlich OK und auch
logisch. Die kürzeste Verbindung
zwischen zwei Punkten ist eine Gerade.
Der Auftraggeber hat sich das
Ergebnis aber leider ganz
anders vorgestellt (rechts).
Beide haben recht, aber die Bilder
zeigen komplett andere Ergebnisse.
B
A
E
D
C
Schuld an dieser misslichen Lage ist der anfangs ungenau definierte
Meilenstein. Um das vom Auftraggeber gewünschte Ergebnis zu erhalten,
hätte dieser präzisere Angaben machen müssen, wobei es kein Wenn und
Aber bei der Lösung des Problems geben darf.
Folgende Aufgabenstellung wäre als Definition angebracht gewesen.
1. Notwendiges Utensil ist ein blauer Stift mit Strichdicke 2,25pt.
2. Verbinden Sie Punkt A mit Punkt E
3. Verbinden Sie Punkt E mit Punkt D
4. Verbinden Sie Punkt D mit Punkt C
5. Verbinden Sie Punkt C mit Punkt B
Achtung: Keine direkte Verbindung zwischen Punkt A und Punkt B !!
Die Vorgehensweise zum Erreichen des Meilenstein hätte keine Fragen
offen gelassen und das Ergebnis wäre perfekt.
23
2
Spielidee und gelungener Spielhandlung, schnell das Vertrauen und die
Akzeptanz der Spieler. Bei PC-Spielen kann man sich im Zeitalter des
Internets noch mit zum Download verfügbaren Patches7 abhelfen. Da man
bei Entwicklungen für den Konsolenmarkt diese Form der Fehlerbehebung
leider nicht anwenden kann, muss die Qualitätssicherung und die Testphase umso genauer durchgeführt werden.
Obwohl die meisten Ungereimtheiten bereits in der Designphase eliminiert werden sollten, schleichen sich während der Produktion immer
wieder Fehler ein, welche so schnell wie möglich behoben werden sollten.
Je später man einen Fehler bemerkt, desto größer ist der zeitliche und
nanzielle Aufwand ihn zu beseitigen.
Die gesamte Phase der Qualitätssicherung kann man grundlegend in drei
Teile, siehe Abbildung 3.4, gliedern.
„SYSTEMTESTING“
QUALITÄTSSICHERUNG QA
„QUALITYASSURANCE“
„PLAYTESTING“
Abb. 3.4 Verschiedene Phasen der Qualitätskontrolle
- Systemtesting
Es werden hierbei unterschiedliche Testfälle angewendet, um die jeweiligen Codemodule und deren Integration in das Gesamtprojekt zu kontrollieren. Diese reichen von den einfachsten Selbsttests der Programmierer,
über die Verwendung von Testscripts, welche alle Features und Funktionen eines Moduls testet, bis hin zur Funktionalität des gerade fertigen
Moduls nach der Integration in das Gesamtprojekt. Eine detaillierte Beschreibung der einzelnen Testfälle ndet sich im Buch von Andrew Rollings
und Dave Morries - Game Architecture und Design [Rollings & Morris
2000].
- Qualitätssicherung
Die vielen Snags und Fehler im Code, sollten in diesem Testabschnitt
eigentlich durch den Systemtest bereits behoben sein. Es wird hier das
Augenmerk auf die Ästhetik, das Look and Feel des Spieles gelegt. Die
einzelnen fertiggestellten Spielabschnitte und Module werden hier getestet
und die Anforderungen an Graphik und Design mit dem Final Game
7 Patches sind verfügbare Programmteile, welche nach dem Ausführen automatisch
den vorliegenden Fehler im Spiel beheben.
24
2
Design Document verglichen. Wie schon im Punkt 2.2.5 beschrieben, ist
es unumgänglich, dass der Tester aufgetretene Fehler nicht nur zufällig
ndet, sondern akribisch danach sucht und sie auch erneut immer wieder
hervorrufen kann. Dies gilt vor allem für den folgenden Punkt.
- Playtesting
Natürlich muss das gesamte Spiel am Ende der Entwicklung auf Spielbarkeit und Spiellogik getestet werden. Die Spieletester in dieser Phase
sind den ganzen Tag nur mit Spielen beschäftigt. Da alle Versionen des
Spieles (verschiedene Sprachen und Systeme) getestet werden müssen,
muss der Spieletester viel Ausdauer und Ruhe aufweisen, um nach tagelangen Spielesessions noch immer die Konzentration aufzuweisen, nach
Ungereimtheiten im Spiel zu suchen und sie auch zu nden. Fehler in
dieser Phase können Steuerungsprobleme, Verständnisprobleme der Spielaufgaben, Logik des Spielverlaufs, usw. sein.
Die Ablaufreihenfolge dieser drei verschiedenen Testarten ist eigentlich
wie in Abb. 3.4 dargestellt. Jedoch kommt es auch hier zu Überlappungen
und parallelen Testarbeiten, je nachdem welche Teile fertig und wie
sinnvoll und aussagekräftig die Testläufe sind. In jeder dieser Phasen wird
ein Fehlerbericht, auch Error-Report genannt, verfasst, in welchem die aufgetretenen Fehler angeführt werden. Diese werden dem Projektmanager
mitgeteilt, welcher die jeweilig zuständigen Abteilungen zur Behebung
des Fehlers informiert. Bei NEO in Wien wird zur Verwaltung der Fehler
eine eigene Fehlerdatenbank geführt. Dort werden alle, jemals entdeckten
Fehler eingetragen. Bei Konsolenspielen werden externe Tester hinzugezogen, welche die vielen Konsolenvorschriften (z.B. TCR8 bei XBox und
TAC8 bei Play Station 2) überprüfen [NEO 2002].
Auch bei PC-Produktionen werden oftmals, zusätzlich zu den eigenen,
externe Spieletester angestellt. Diese gehen ohne Vorkenntnisse und Vorurteile in die Testphase und können somit weitere Fehler leichter
nden als Firmeninterne. Solche externen Tester sind zum Beispiel auch
Studenten, welche einfach als Spieletester fungieren. Deren Meinungen
und Kritiken können schon viel über die endgültige Zielgruppe aussagen
[McCuskey 2000; Sikora 2001c].
8 TAC und TCR sind denierte Vorschriften der Konsolenhersteller, um die
Funktionen und Spezikationen der Konsolen festzulegen und das Verhalten des
Spiels, möglichen Handlungsweisen des Anwenders anzupassen. Beispiel dafür ist
das Verhalten des Spiels beim Ziehen des Kontrollerstecker oder dem Entfernen des
Speicherchips während des Speichervorganges.
25
2
3.3 Unterschiede im Produktionsprozess durch unterschiedliche Plattformen
3.3.1 Unterschiede zwischen Pc und Pc
Zwar sind beinahe alle PCs der potentiellen Spieleanwender verschieden
konguriert und weisen unterschiedliche Hardware auf, jedoch werden
die Spiele meistens auf den neuesten Rechnern entwickelt und wenn das
fertige Produkt ein Jahr später auf den Markt kommt, ist dieser Hardwarestandard bereits im Heimbereich vertreten [NEO 2002]. Außerdem
wird nicht bei jedem Spiel an die Leistungsgrenzen der PCs gegangen. PCSpiele sollen vor allem einer breiten Masse zugänglich sein und dies ist
nur möglich, wenn man auch ältere, leistungsschwächere PCs mit älteren
Hardwarebestandteilen miteinbezieht. Die meiste Arbeit für die Entwickler
steckt in den Anpassungen für die Lauffähigkeit des Spiels auf den unterschiedlichen Plattformen und in der Vielzahl an verschiedenen Treibern
für PCs.
3.3.2 Unterschiede zwischen Pc und Konsole
Wie wir in der Abbildung 3.5 sehen, gibt es einige markante Unterschiede
bei der Entwicklung für das jeweilige System. Die offensichtlichsten Probleme durch die unterschiedliche Hardware liegen bei den Ausgabegeräten
und an den begrenzten Speicherkapazitäten bei den Konsolen. Eine
Schwierigkeit stellen die Fernsehgeräte als Ausgabemedium für die Spiele
dar. Da keine einheitliche Normung bei den Fernsehern Gültigkeit hat,
kann es zu unliebsamen Bildbereichsverlusten kommen (z.B. kann es
bei kleinen Fernsehern vorkommen, dass das Logo der Fernsehanstalt
nur mehr teilweise sichtbar ist). Diesen möglichen Bildverlust muss man
schon vorher einplanen und darf keine wichtigen Spielelemente in diesem
Bereich platzieren. Durch die eingeschränkte Farbdarstellung der Fernseher im Vergleich zu den PC-Monitoren, tritt ein gewisser Farbverlust auf,
der ebenfalls schon in der Entwicklungsphase bedacht werden muss [NEO
2002].
26
2
PRO
CONTRA
Rasante technologische
Entwicklung
Zeitraubende Spieleentwicklung
wegen unterschiedlicher Hardware
- Komponenten, Systeme und
Treiber
Beschränkte Anzahl von
Graphikschnittstellen (Open GL,
DirectX)
Die gleiche Hardware für jede
Konsole
Großer, weltweiter Absatzmarkt
Wenig Konkurrenz
PC
Viele Konkurrenten, da jeder mit
einem PC auch ein PC-Spiel
entwickeln könnte
Teure Entwickler-Kits und
Werkzeuge
KONSOLE Viele Einschränkungen
Langwierige Testphasen
Portieren auf neue Hardware sehr
zeitaufwändig
Abb. 3.5 Vergleich PC und Konsole [Saltzmann 2000].
Leider verfügen Konsolen über vergleichsweise wenig Speicherplatz, was
oftmals viele Ideen und Vorstellungen schon in der Designphase zum
Scheitern verurteilt, da sie wegen Speichermangel nicht realisierbar sind.
(Vergleich: GameCube hat gesamt 24 MB Speicher - neue Graphikkarten
(GeForce) für PC haben bereits 64 MB [NEO 2002; GameCube 2002;
nVIDIA 2002]).
Eine leichte Annäherung zwischen Konsolen und PCs sind aber zum
Beispiel durch die neue XBox schon ersichtlich. Die XBox verfügt bereits
über einen DirectX-Support, welcher bei der Entwicklung von PC-Spielen
praktisch schon Industriestandard ist [XBoxFAQ 2002]. Diese und weitere
Spezikationen sind in den jeweiligen konsolenabhängigen Vorschriften
(siehe Punkt 3.2.2), welche unbedingt von den Entwicklern einzuhalten
sind, deniert. Sich an diese Vorgaben zu halten, kann einerseits das Entwickeln erleichtern, da man sich auf die jeweiligen Angaben 100%ig verlassen kann, aber wiederum die Freiheiten der Entwickler einschränken.
3.3.3 Unterschiede zwischen Konsole und Konsole
Auch Konsolen haben natürlich unterschiedliche Hardwarespezikationen,
27
2
aber diese sind wenigstens bei den einzelnen Konsolentypen identisch.
Weitere Unterschiede liegen in den vorher genannten Vorschriften welche
für die jeweilige Konsole zutreffen müssen. Markante Differenzen bei
selbigen Spiel auf verschiedenen Konsolen, werden in den unterschiedlichen Steuerungsvarianten und Kameraführungen bemerkbar. Vor allem
wenn die einzelnen Konvertierungen von verschiedenen Unternehmen
durchgeführt wurden, kann sich jedes Unternehmen durch eine noch
bessere Implementierungslösung hervorheben. Als gutes Beispiel ist hier
die Konvertierung von Max Payne auf die XBox zu nennen [NEO 2002,
MaxPayneInt. 2001]. Die Art, wie ein Spiel durch die Steuerung kontrolliert und dem Anwender durch gelungene Kameraführung näher gebracht
wird, ist für den Spielspaß und -erfolg wesentlich verantwortlich. Daher
kann es auch durchaus große Unterschiede machen, ob man sich das
Spiel für Play Station 2 oder XBox kauft. Weitere Informationen über die
jeweiligen Systemspezikationen einzelner Konsolentypen nden sich auf
folgenden Homepages [XBox 2002; Nintendo 2002; PS2 2002].
28
Kapitel
4
Softwarekonzepte
4.1 Wiederverwendung in der Spieleentwicklung
Wie schon in den vorderen Kapitel erwähnt, spielen Abgabefristen und
Terminnot gerade in der Spieleentwicklung, im Vergleich zur herkömmlichen
Softwareindustrie, eine viel wesentlichere Rolle. Es müssen so bald wie
möglich vorzeigbare Ergebnisse geliefert werden, um den Markt mit immer
neueren und besseren Spielen zu versorgen. Dadurch leiden oftmals
die grundlegenden Designstrukturen der gesamten Entwicklung, da es
schlussendlich nur wichtig ist, dass dem Anwender das Spiel gefällt,
egal wie man dieses Ziel erreicht hat [Rollings & Morris 2000]. Andrew
Rollings vergleicht diese Entwicklung in seinem Buch, Game Architecture
und Design, mit der Erscheinung eines Schwans “Über der Wasseroberäche
sieht man die Schönheit und Eleganz, aber darunter muss er ständig wild
paddeln um nicht unterzugehen.”
Probleme durch schlechte Struktur und Architektur der Implementierungen werden vor allem bei der späterer Fehlersuche oder den laufenden
Implementierungsänderungen ersichtlich. Viele Softwarekonzepte, welche
in der herkömmlichen Softwareindustrie bereits Standard sind, werden
immer häuger in der Spieleentwicklung angewendet, um die Entwicklungsphasen zu optimieren und mögliche Probleme erst gar nicht
aufkommen zu lassen. Eines dieser Konzepte ist der Einsatz von Design
Pattern, um den genannten Problemen entgegen zu steuern. Dieser Idee liegt
die Dokumentation von Erfahrungen und bewährten Praktiken zugrunde,
die bei der Gestaltung von Softwaresystemen gemacht werden. Diese Dokumentation von Lösungen immer wiederkehrender Probleme verhindert,
dass Erfahrungen die zu diesen Lösungen geführt haben, bei jedem Ent-
29
S o f tw are k o nz e p te
wicklungsprozess wiederholt gemacht werden müssen [Leßmann 2001].
Ein Problem bei der Verwendung von Design Patterns ist die allgemeine
Verständlichkeit und gleiche Bezeichnung der Patterns. Viele dieser
Muster sind bereits aus der herkömmlichen Softwareindustrie bekannt
und können in der Spieleentwicklung übernommen werden. Jedoch ist
man ständig auf der Suche nach neuen, spezischeren Patterns, welche
für die Spieleentwicklung eingesetzt werden können, um deren speziellen
Anforderungen gerecht zu werden. Auf der gamasutra-Homepage, eine der
größten Spieleentwickler-Plattform, wird seit zwei Jahren versucht, eine
Datenbank für Spiele Design Patterns anzulegen und diese allen interessierten Entwicklern zugänglich zu machen, um so auch einen gewissen
“Patternstandard” etablieren zu können [Hecker & Simpson 2000].
4.1.1 Definition von Patterns
Der Ausdruck Pattern hat sich in den letzten Jahren zu einem beliebten
Modewort entwickelt. In allen Bereich des alltäglichen Lebens trifft man
auf Patterns, egal ob es sich um das Muster auf Orientteppichen handelt
oder um die Denitionen menschlicher Persönlichkeitsmuster
[PatternQuiz 2002].
Die allgemeine Denition eines Patterns in der Softwareindustrie nach
Christopher Alexander, lautet:
“Each pattern describes a problem which occurs over and over again in our
enviroment, and then describes the core of the solution to that problem, in
such a way that you can use this solution a million times over, without ever
doing it the same way twice” [Alexander 1977].
Ganz einfach ausgedrückt deniert sich ein Pattern als eine generische
Beschreibung für ein, in vielen ähnlichen Varianten wiederkehrendes
Problem, welches in einem bestimmten Zusammenhang auftritt und der
Denition einer allgemeinen Lösung dafür. Es soll so, eine detaillierte
Lösung für jedes spezielle Problem abgeleitet werden können [Alexander
1977; Leßmann 2001].
30
4.1.2 Das Pattern Template
Um einen entsprechenden Standard für die Denition von Patterns zu
etablieren, wurden vier grundlegende Punkte als Beschreibung für ein
Pattern Template festgelegt [Kreimeier 2002].
Der Name
Der Name für das entsprechende Pattern muss aussagekräftig und für
jedermann verständlich gewählt werden. Die Funktionsweise des Patterns
soll schon durch den Namen klar sein.
“Finding good names has been one of the hardest parts of developing our
catalogue” [Gamma et al. 1994].
Das Problem
Beschreibt das Problem, welches wiederkehrend in einem gegebenen
Zusammenhang auftritt. Die Beschreibung des Problems soll zusätzlich
die Anforderungen welche die Lösung erfüllen muss, Gegebenheiten, Probleme welche berücksichtig werden müssen und die wünschenswerten
Eigenschaften der Lösung enthalten [Askit 1998].
Die Lösung
Eine Beschreibung des Zusammenwirkens von Eigenheiten und Mechanismen, damit das Problem gelöst werden kann. Dies ist aber keine genaue
Beschreibung oder konkrete Implementierung, sondern nur eine abstrakte
Struktur welche die Lösung umschreibt [Kreimeier 2002].
Die Konsequenz
Alle Lösungen haben auch weitere Konsequenzen oder Probleme zur Folge.
Diese sollen, wenn möglich, angeführt werden [Kreimeier 2002].
4.1.3 Kategorien von Patterns
Patterns sind je nach ihrer Abstraktionsstufe, kurz Abst., grundsätzlich in
drei verschiedene Kategorien (Ebenen), siehe Abbildung 4.1, einzuteilen.
31
Architektonische Pattern
Abst. 3
Design Pattern
Abst. 2
Idiome
Abst. 1
Abb. 4.1 Einteilung der Pattern in drei Kategorien
Idiome
Benden sich auf der untersten Abstraktionsstufe und werden daher auch
als Low-Level Pattern bezeichnet. Diese Muster zeigen, wie einzelne Eigenschaften einer Programmiersprache genutzt werden können. Idiome sind
deshalb programmiersprachenabhängig [Leßmann 2001].
Design Pattern
Diese bilden die mittlere Stufe der Abstraktion und sind im Gegensatz zu
den Idiomen grundsätzlich von der Implementierungssprache unabhängig.
Sie stellen ein Schema für die Verfeinerung von Subsystemen oder Komponenten eines Softwaresystems oder der Beziehung unter ihnen zur
Verfügung [Askit 1998].
Architektonische Pattern
Diese Pattern drücken ein fundamentales Organisationsschema für Softwaresysteme aus. Sie dienen zur Gestaltung der Systemarchitektur. Als
Beispiel hierfür dient das M-V-C Konzept, welches in Punkt 4.2 noch
genauer vorgestellt wird [Askit 1998; Leßmann 2001].
4.1.4 Darstellung der Pattern
Für die Darstellung der Strukturen, der im folgenden Kapitel beschriebenen Pattern, wird eine Form der Object Modelling Technique (OMT),
als Beispiel siehe Abbildung 4.5, verwendet. Diese Methode hat sich bereits
32
als Industriestandard etabliert. Da die Design Patterns grundsätzlich
unabhängig von der Implementierungssprache sind, ist es prinzipiell egal,
welche Programmiersprache man für die Erstellung von Pseudocodebeispielen verwendet. Im Kapitel 4.2 und Kapitel 5 wird Java verwendet.
4.2 Design Pattern im Einsatz in der Spieleentwicklung
4.2.1 Das Template Pattern
Oftmals verwendet man bereits in der Implementierung Patterns, ohne sich
bewusst zu sein, dass es sich um welche handelt. Das Template Pattern
ist eines jener, welche Entwickler jeden Tag verwenden ohne den Gedanken
daran zu verschwenden, wie und warum sie es einsetzen. Es handelt
sich dabei lediglich um eine abstrakte Klasse, welche verwendet wird,
um die Anforderungen in weiterer Folge zu spezialisieren. Durch die Vererbung werden die vorher festgelegten Rahmenbedingungen mit speziellen
Funktionen ergänzt. Dadurch kann viel Zeit und Programmieraufwand
gespart werden, da nur die sich ändernden Programmteile implementiert
werden müssen und bei gleichbleibenden Teilen auf die abstrakte Klasse
zurückgegriffen werden kann. Als einfaches Beispiel für eine Wiederverwendung bestehender Module soll Abbildung 4.2. dienen.
Abb. 4.2 Beispiel für Wiederverwendung gleicher Module
33
Die Karosserie des Autos ist bei jedem Modell, entspricht der abstrakten
Klasse, gleich. Will man jedoch das Auto auf spezielle Situationen vorbereiten und mit anderen Reifen ausstatten, tauscht man nicht das gesamte
Fahrzeug, sondern nur die vier Räder aus.
In Computerspielen fallen immer wieder Objekte auf, welche oftmals
gleiche oder ähnliche Eigenschaften und Strukturen aufweisen. Zum
Beispiel die Bewegung der Gegner bei klassischen Shoot’m up Spielen wie
Xenon2 in Abbildung 4.3.
Die Gegner haben zwar
unterschiedliches Aussehen, aber die grundlegenden Bewegungsabläufe, sind identisch
Abb. 4.3 Das Spiel Xenon2. Entwickelt von der Firma Bitmap Brothers, 1992
Aber auch bei allen anderen Arten von Spielgenres tauchen allgemeine
Grundstrukturen auf, welche man mit der Verwendung des Template
Patterns, vereinfachen und verbessern könnte. Ein weiteres Beispiel
hierfür ist das Geschicklichkeitsspiel Bananoid, dargestellt in Abbildung
4.4, mit den unterschiedlichen Spielsteinen.
Die einzelnen Spielsteine weisen
gleiches Verhalten bei Treffer
auf - Ball prallt entsprechend
ab. Einige der Steine beinhalten jedoch weitere, zusätzliche Eigenschaften.
Abb.4.4 Das Spiel Bananoid von William Rieder, 1989
34
Die in der Abbildung 4.5 dargestellte Klassenstruktur, zeigt die zwei verschiedenen, abgeleiteten Klassen, “ConcreteClass1” und “ConcreteClass2”
der abstrakten Basisklasse “AbstractClass”. Diese abgeleiteten Klassen
implementieren die verschiedenen abstrakten Methoden jeweils unterschiedlich. Die in der Basisklasse implementierte Methode “Template
Method” ist jedoch in allen abgeleiteten Klassen gleich. Der darauffolgende
Pseudocode in Abbildung 4.6, soll eine mögliche Implementierung dieses
Patterns in Java veranschaulichen.
AbstractClass
TemplateMethod()
anyMethod1()
anyMethod2()
ConcreteClass1
ConcreteClass2
anyMethod1()
anyMethod2()
anyMethod1()
anyMethod2()
Abb.4.5 Klassenstruktur eines Template Patterns
abstract class AbstractClass {
public AbstractClass() {
TemplateMethod()
}
abstract anyMethod1();
abstract anyMethod2();
private void TemplateMethod(){
//this method is always the
//do something
//same in all derived classes
}
}
class ConcreteClass1 extends AbstractClass {
………
………
//any code for the anyMethod1() and anyMethod2()
}
class ConcreteClass2 extends AbstractClass {
………
………
//another code for the anyMethod1() and anyMethod2()
}
Abb.4.6 Pseudocode des Template Patterns
35
4.2.2 Das Iterator Pattern
Diese Pattern ermöglicht ein efzientes und schrittweises Durchlaufen von
Listen von Elementen, welche meist gleichen Typs sind. Als Beispiel siehe
Abbildung 4.7.
Elemente vom Typ string
„Ich“
„Du“
„Er“
„Sie“
„Es“
„Wir“
„Ihr“
„Sie“
Abb. 4.7 Durchlaufen einer Liste mit Elementen gleichen Typs
Solche Listen werden in der Fachsprache als Collection-Objekte bezeichnet.
Einfache Beispiele hierfür sind Arrays, Listen, Stacks, usw. [Krüger 2000].
Mittels des Iterator Patterns ist es möglich, auf die einzelnen Elemente einer
solchen Datenstruktur zuzugreifen und sie beliebig zu verwenden. Das
folgende Klassendiagramm (Abb.4.8) soll Einblick in die Funktionsweise
des Iterators geben.
Collection
getElements()
getKeys()
erzeugt
Iterator
hasNext()
next()
Element
liefert
Abb. 4.7 Durchlaufen einer Liste mit Elementen gleichen Typs
Wie aus dieser Abbildung ersichtlich ist, enthält der Iterator die zwei unterschiedlichen Methoden “hasNext()” und “next()”. “hasNext()” überprüft,
ob das nächste Element vorhanden ist und noch nicht besucht wurde.
Die Methode “next()” liefert jeweils das nächste unbesuchte Element im
36
Collection Objekt. Die Collection-Klasse selbst enthält Methoden wie
“getKeys()” und “getAllElements()”, um gewisse Teilmengen von dem
Collection Objekt durch den Iterator anfordern zu können [Krüger 2000].
Folgender Pseudocode, Abbildung 4.9, soll die Implementierung eines
Iterator Patterns, mit dem in Abbildung 4.7 dargestellten string-Array als
Collection Objekt, in Java zeigen.
interface StringIterator {
public boolean hasNext();
public String next();
}
class StringArray {
String[] data;
public StringArray() {
data = {“Ich”, “Du”, “Er”, “Sie”, “Es”, “Wir”, “Ihr”, “Sie”};
}
public StringIterator getElements() {
return new StringIterator() {
int index = 0;
public boolean hasNext() {
return index < data.length; //as long as the index is equal to the number
}
//of strings in the array
public String next() {
return data[index++];
//every call of next() -> index = index+1;
}
};
}
}
public class IteratorExample {
public static void main(String[] args) {
StringArray strar = new StringArray();
StringIterator it = strar.getElements(); //get the Elements from the array and
while (it.hasNext()) {
//pass through the elements
System.out.println(it.next());
//output
}
}
}
Abb. 4.9 Pseudocode eines Iterators in Java. In Anlehnung an Krüger [Krüger 2000]
Als mögliches Beispiel und sehr einfache Anwendung des Iterator Patterns,
wird das wohlbekannte Spiel “Schiffe versenken”, Abbildung 4.10, genannt. Hierbei muss der Gegenspieler seine eigenen Schiffe auf seinem
Schlachtfeld positionieren und versuchen, die gegnerischen Schiffe, welche
ebenfalls auf einem, dem Spieler unsichtbaren Spielfeld, positioniert
wurden, zu treffen.
37
Alle Koordinatenpaare, diese entsprechen den Positionen der Schiffe,
werden in einem Collection Objekt abgelegt. Wird durch den Spieler ein
Schuss abgefeuert, das heißt, es wird ein Koordinatenpaar angegeben, so
durchläuft der Iterator das Collection Objekt und vergleicht die Position der
Schiffe mit der des abgefeuerten Schusses. So kann sehr einfach bestimmt
werden, ob der Schuss ein Treffer war oder das Ziel verfehlt hat.
Abb.4.10 Einfaches Schiffe versenken [Battleship 2002]
Natürlich ist die Verwendung eines Iterator Patterns nicht allein auf ein
schrittweises Vorwärtsdurchlaufen beschränkt. Genau so gut könnte man
auch einen Rückwärtsiterator denieren. Durch einfache Manipulationen
des Quellcodes lassen sich eine Menge weiterer Anwendungsmöglichkeiten
nden, wie das System des Iterator Patterns in der Spieleentwicklung
sinnvoll eingesetzt werden kann. Eine weitere Einsatzmöglichkeit wird im
Kapitel 4.2.4 im Zusammenhang mit dem Factory Pattern gezeigt.
38
4.2.3 Das Mvc Konzept und Observer Pattern
Das Model-View-Controller Konzept, kurz MVC, teilt das Gesamtsystem
in die drei genannten Teile auf (siehe Abb. 4.11). Durch diese Aufteilung
erreicht man eine viel
Benutzer
größere Unabhängigkeit
verwendet
und
Strukturiertheit
stellt dar
zwischen den einzelnen
Komponenten. Aufgrund
View
Controller
dieser Separation des
Quellcodes der einzelnen
Teile, können diese sehr
einfach und rasch ausgeaktualisiert
manipuliert
Modell
tauscht und die Flexibilität
COMPUTERSPIEL
des Gesamtsystems stark
erhöht
werden.
Ein
Abb.4.11 Einfache Ablaufstruktur des MVC-Konzeptes
weiterer großer Vorteil liegt
in der Möglichkeit der gleichzeitigen Darstellung mehrerer unterschiedlicher Views durch das Model. Viele Spiele benötigen bereits
zwei oder mehrere Ansichten gleichzeitig (z.B.: Flugsimulator: Cockpitsicht und Radardarstellung) um die Spielbarkeit zu fördern. Natürlich
ist die obige Abbildung nur eine Symboldarstellung der einzelnen
Systeme. Diese kommunizieren untereinander auch bidirektional und
nicht nur in eine Richtung. Abbildung 4.12 zeigt die allgemeine Kommunikation der drei Einzelsysteme untereinander.
View
Stellt alle nötigen Daten und Informationen am Ausgabegerät dar. Erhält
vom Modell die neuen Informationen und aktualisiert damit die Anzeigen.
Controller
Bekommt Daten durch Eingabegeräte des Anwenders um damit das Modell
zu manipulieren. Diese Eingabegeräte können zum Beispiel Tastatur,
Maus, Joystick oder ähnliches sein.
39
Modell
View
Controller
Wertänderung des Modells wird an die View gesendet.
Erlaubt den Aufruf von Methoden des Modells (z.B. Modifikationen,.)
Das Feedback zwischen Controller und Viewer sorgt für eine
schnelle Reaktion des Views auf Controlleränderungen
Eingaben beeinflussen das Modell
Abb.4.12 Kommunikationsablauf im MVC-System [Helman 1998]
Model
Stellt den funktionalen Teil der Anwendung zur Verfügung. Darin werden
die Daten und Werte des Spiels berechnet. Falls es neue Informationen
für die bei dem Modell registrierten Views gibt, werde diese vom Modell
benachrichtigt [Krüger 2000; Amrhein 2002].
Ein wichtiger Bestandteil des MVC-Konzepts ist das sogenannte ObserverPattern. Dieses dient als Benachrichtigungsmechanismus des Modells,
um die View über Änderungen zu informieren [Krüger 2000]. Dieses Pattern erlaubt eine “eins-zu-viele” Abhängigkeit zwischen Objekten. Wenn
das überwachte Objekt (Observable) seinen Zustand ändert, werden alle
weiteren Objekte davon benachrichtigt, welche sich vorher an dieses
angemeldet haben und so zum überwachenden Objekt (Observer)
wurden [Rollings & Morris 2000; Amrhein 2002]. Als Veranschaulichung,
Abbildung 4.13, dient hier das zuerst angesprochene Beispiel mit
dem Flugsimulator. Um mehr Informationen und tiefern Einblick in
die Funktionsweise des Observer Patterns zu bekommen (Klassen-
40
diagramm, Quellcode), dient folgende Literatur [Krüger 2000; Rollings &
Morris 2000; Lam 1998; Baldwin 1998].
Radardarstellung
Sicht aus
Cockpit
Weitere
mögliche
Ansichten
Observer
Aktualisation
und
Rückmeldung
Berechnung der
Flugbahn
....
....
Observable
Abb. 4.13 Observer Pattern im praktischen Einsatz
In der Spieleentwicklung trifft man sehr oft auf den Einsatz des Observer
Patterns, da dieses “eins-zu-viele” Kommunikationsproblem in vielen
Bereichen Anwendung ndet. Einige Beispiele der möglichen Verwendung
des Observer Patterns als Bestandteil des MVC-Patterns in Computerspielen, werden nun angeführt.
Bei den bekannten Strategiespielen Command & Conquer, oder dem etwas
ältern Dune2 wird zusätzlich zur Hauptansicht auf das Spielfeld, eine
Ansicht des Gesamtspielfeldes gezeigt. Siehe Abbildung 4.14 und 4.15.
Hier sind die beiden
verschiedenen
Ansichten
dargestellt.
Beide müssen gleichzeitig Änderungen des
Spielverlaufs (Fahrzeugbewegung,
Gebäudebau,..) darstellen.
Abb.4.14 Das Strategiespiel Dune2
41
Abb.4.15 Command & Conquer zeigt ebenfalls zwei unterschiedliche Ansichten
Doch auch in anderen Spielegenres werden verschiedene Ansichten
eingestetzt, um die Spielbarkeit zu erleichtern. Abbildung 4.16. zeigt das
Rennspiel Need for Speed 5. Bei Rennsimulationen wird oftmals eine
zusätzliche Streckensicht eingeblendet. Auch der Rückspiegel stellt eine
eigene Ansicht dar, welche ebenfalls ständig aktualisiert werden muss.
Rückspiegel
Hauptsicht
Streckensicht
Abb.4.16 Need for Speed 5 mit verschiedenen Ansichten
42
4.2.4 Das Factory Pattern
Folgend, wird eine von zwei verschiedenen Varianten einer Factory behandelt. Die eine Variante ist die sogenannte Factory-Methode und die
zweite wird Factory-Klasse genannt. Grundlegend erfüllen beide die selbe
Aufgabe einer Factory. Diese ist ein Hilfsmittel zum Erzeugen von Objekten,
ohne dabei explizit den new-Operator zu verwenden. Die Factory wird
eingesetzt, wenn die Objekte schwer zu konstruieren oder umfangreich zu
kongurieren sind, oder wenn zum Beispiel erst die Daten aus einem
Netzwerk oder einer Datenbank entnommen werden müssen, um das
entgültige Objekt erzeugen zu können. Den Klassen welche das Objekt
erzeugen, ist normalerweise nicht bekannt, welches Objekt sie nun genau
erstellen. Die Factory stellt einen Auswahlalgorithmus zur Verfügung,
welcher entscheidet, wie das Objekt schlussendlich aussieht [Krüger 2000;
Wiesner 2001]. Will man im Laufe der Entwicklung weitere Objekte erzeugen, muss man nun nur noch die Factory verändern.
Der Unterschied zwischen der Factory-Methode und der Factory-Klasse ist
eigentlich schon durch den Namen erklärt. Bei der Factory-Klasse sorgt
nicht nur eine Methode innerhalb der eigenen Klasse für die Instanzzierung
neuer Objekte, sondern eine eigenständige Klasse. Dies bringt unter
anderem den Vorteil, dass man bei Bedarf ganz einfach die gesamte
Factory austauschen könnte.
Um die Anwendung des Factory Patterns in der Spieleentwicklung zu
zeigen, wird weitergehend die Factory-Methode verwendet. Das Prinzip der
Factory, ist bei Factory-Methode und Factory-Klasse sowieso identisch.
Der wichtigste Schritt bei der Erstellung einer Factory-Methode ist der
Schritt vom Konstruktor zur Methode. Folgende zwei Quellcodeabschnitte
sollen dies veranschaulichen.
//Konstruktor
public SpaceShip (int x) {
int ShipType = x;
}
//Factory Methode
static SpaceShip createType(int x) {
return new SpaceShip(x);
}
43
public class SpaceShip {
private SpaceShip() { //to prevent a manual use of the constructor
}
}
public static SpaceShip createTyp(int value) {
//Template Method
SpaceShip ss = null;
if(condition1) {
//Code, create SpaceShip of typ 1
}
else if(condition2) {
// Code, create SpaceShip of typ 2
}
return ss;
}
Als mögliches Anwendungsbeispiel aus der Spieleindustrie wird auf die
Geschicklichkeitspiele Bananoid, siehe auch Punkt 4.2.1, und Aquanoid,
siehe Abbildung 4.17, hingewiesen. Die Erzeugung der Spielsteine könnte
mit einer Factory Methode realisiert werden. Obwohl die Anwendung der
Factory Methode an diesem Beispiel, wegen der Einfachkeit der Erstellung der einzelnen Spielsteine, vielleicht nicht die beste Lösung ist, trägt
sie jedoch zum einfachen Verstehen dieses Patterns bei und wird vorallem für die Anwendung beim Prototypen, Kapitel 5.1.4, eine wichtige Rolle
spielen.
Die verschieden farbigen Spielsteine können verschiedenes Verhalten aufweisen.
Deshalb
der
Entscheidungsalgorithmus,
nach welchen die Steine
erzeug werden.
Abb.4.17 Screenshot von Aquanoid
Wie in der Abbildung 4.17 ersichtlich, sind am Aufbau des Levels einige
unterschiedliche Spielsteine, sogenannte Tokens, beteiligt. Diese können
44
unterschiedliche Eigenschaften aufweisen. So müssen manche Steine
öfters getroffen werden um zu verschwinden, beeinussen das Flugverhalten des Balles oder verändern das Spielpaddle.
Eine mögliche Implementierungslösung, angelehnt an Abbildung 4.17,
könnte wie in Abbildung 4.18 dargestellt, aussehen.
public class Token {
…
…
…
public static Token createToken(int typ) {
Token Ttyp = null;
}
}
//Template Method
if(typ == 1) {
//Code to create red token (normal)
}
else if(typ == 2) {
// create dark blue token (hit two times)
}
else if(typ == 3) {
// create dark blue token (hit three times)
}
else if(typ == 4) {
// create yellow token (ball gets faster)
}
return Ttyp;
Abb.4.18 Pseudocode zeigt praktische Anwendung des Factory Patterns
Will man die Level- und Spielsteinkomplexität erhöhen und weitere unterschiedliche Spielsteine hinzufügen, muss in diesem Fall nur mehr die
Factory Methode um die gewünschten if-Anweisungen erweitert werden.
Ein weitere Vorteil liegt in der einfachen Erstellung der einzelnen Levels.
Die Tokens benden sich alle in einem zweidimensionalen Feld. Jede
Position in dem Feld kann durch einen Spielstein besetzt werden. Dieser
wird in dem Feld durch einen int-Wert dargestellt, wobei eine Null für
keinen Spielstein steht. Abbildung 4.19 veranschaulicht diese Leveldarstellung. Werden diese int-Werte in ein 2 dimensionales Array geschrieben,
kann mittels eines Iterators, siehe dazu Kapitel 4.2.2, das Array durchlaufen und bei den entsprechenden int-Werten der dazugehörige Token in
der Factory Methode erzeugt werden.
45
0
0
1
0
1
0
1
0
0
1
1
1
2
2
2
1
1
1
1
2
2
3
3
3
2
2
1
Abb.4.19 Verschiedene int-Werte stehen für die speziellen Tokens
Wie schon anfangs erwähnt, wird ein Factory Pattern vor allem auch
dann eingesetzt, wenn das zu erzeugende Objekt schwer zu konstruieren
ist oder die notwendigen Informationen erst aus einem Netzwerk oder
Datenbank entnommen werden müssen. Durch die vermehrte Nutzung
des Internets für Computerspiele, trifft man immer häuger auf das Problem der verteilten Information im Netz und den daraus entstehenden
Vorteilen.
Um Speicherplatz und andere Hardwareressourcen bei Verwendung von
Spielen zu sparen, muss am Rechner nur ein Bruchteil des Spieles installiert
sein und der restliche Teil wird je nach Spielerwunsch oder Spielablauf
durch das Internet bezogen. Die so zusammengestellten Objekte sind zum
Beispiel einzelne Räume, Szenarien, Charaktere oder auch Spielabläufe
und könnten durch eine Factory Methode oder Factory Klasse erzeugt
werden, da sie durch ihre Zusammenstellung aus verschiedensten Datenbanken, einen sehr komplexen Erzeugungsvorgang aufweisen. Durch diese
Nutzung des Internets und des hier sinnvollen Einsatzes des Factory
Patterns, ist eine viel komplexere, abwechslungsreiche und interaktivere
Gestaltung einzelner Levels oder ganzer Spiele möglich.
46
4.2.5 Das Platzhalter Pattern
Das Platzhalter Pattern soll, ähnlich dem MVC-System, vor allem ein
Konzept zur Verbesserung der Struktur und Steigerung der Flexibilität
bei Spieleentwicklungen anbieten. Im Gegensatz zu den vorher erwähnten
Pattern, ist das Platzhalter Pattern derzeit noch in keiner Patternsammlung
erwähnt, oder deniert worden. Deshalb soll zuerst das Pattern Template,
siehe Punkt 4.1.2, dazu dienen, um dieses neue Pattern nach dessen Vorschriften zu denieren.
Der Name:
Platzhalter Pattern (auf englisch: Placeholder Pattern)
Das Problem:
Betrachtet man verschiedene Computerspiele und Spielgenres genauer,
so erkennt man immer wieder gleiche Bereichsaufteilungen im Spiel, in
welchen verschiedene Spielkomponenten platziert sind. In Abbildung 4.14,
dem Spiel Dune2, ist das Spiel grundsätzlich in 4 verschiedenen Teilbereiche aufgeteilt. Diese sind in Abbildung 4.20 skizziert.
A1 – Menüleiste
A1
A2
A3
A4
A2 – Hauptspielfläche
A3 – Gesamtübersicht
A4 – Bearbeitungstools
Abb.4.20 Aufteilung der Spielbereiche bei Dune2
Egal mit welchen Team man in Dune2 spielt, oder in welchen Level man
sich bendet, es tritt immer die selbe Einteilung auf.
Durch die Denition von Teilbereichen wird die Grundstruktur des Spieles
festgelegt. Man kann die einzelnen, vordenierten Bereiche, ähnlich
47
wie bei Frames in HTML, mit beliebigen Inhalt füllen und dadurch die
Darstellungen variieren lassen. Da der Platzhalter als Komponente dient,
durch welchen alle Bereiche des Spiels genau deniert sind, ermöglicht
das Pattern ein schnelles und effektives verändern der Spieloberäche.
Dadurch entsteht zum Beispiel eine einfache und strukturierte Möglichkeit,
viele verschiedene Layouts für das selbe Spiel oder Level zu erzeugen. Vor
allem durch die Nutzung des Internets und die Vielzahl an Ressourcen die
dadurch zur Verfügung stehen, ist es von großem Vorteil, den strukturellen
Aufbau so einfach und logisch als möglich zu gestalten, um eine leichtes
variieren einzelner Komponenten zu ermöglichen.
Die Lösung:
Durch die vorher denierte Vorlage (Schablone), werden einzelne Bereiche für die jeweiligen Spielkomponenten festgelegt. Diese Vorlage wird
als “Platzhalter-Klasse” implementiert und soll Methoden zum Setzen und
Löschen von Spielkomponenten anbieten. Als mögliche Implementierung,
siehe dazu folgenden Quellcode und die dazugehörige Abbildung 4.21.
public class PlaceHolder{
……
……
setArea1(Object1){
…
//code to dene the position of
…
//the Area1 and place the
}
//Deliverd Object there
setArea2(Object2){
…
//same as in Method setArea1
}
…
…
clearArea1(){
…
//code to clear the last Object, set
}
//in the Area1
}
clearArea2() {
…
}
……
//Same as above
48
Das gesamte Spielfeld
Area1 - Entspricht hier der
Anzeige der Spielabhandlung
Area2 - Anzeige der HUDs
Abb.4.21 Darstellung möglicher Bereichsaufteilung
Die Konsequenz:
Durch diese Vorlage ist jedoch die Gestaltung der Levels entsprechend
eingeschränkt. Daher sollte dem Entwickler schon vorher klar sein, wie die
Levels aussehen werden und welche Funktionalität sie beinhalten sollen.
Dementsprechend muss er vorher schon die benötigten Bereiche genau
denieren.
Eine Anwendung dieses Patterns soll die Abbildung 4.22 zeigen. Hierbei
handelt es sich um das Computerspiel Stunt der Firma Distinct Software,
Inc, welches 1990 am Spielemarkt erschienen ist [Stunts 2002].
Abb.4.22 Vergleich zwei verschiedener Cockpits und selber Strecke bei Stunts
Wie hier zu sehen ist, handelt es sich um dieselbe Strecke aber um verschiedene Autos, deshalb ist auch das Cockpit unterschiedlich. Diese
49
Spielansicht könnte man nun in drei Teile, wie in Abbildung 4.23 dargestellt, aufteilen.
Oberer Teil des Cockpits (B1)
Sicht durch
Windschutzscheibe (B2)
Armaturenanzeige und
Lenkrad (B3)
Abb.4.23 Aufteilung der Spielansicht von Stunts
Die Sicht durch die Windschutzscheibe ist je nach Streckenauswahl
unterschiedlich. Genau so wie sich die Wahl des Autos auf die
Ansicht des Cockpits auswirkt. Würde dieses Spiel mit dem Platzhalter
Pattern realisiert, könnte der Ablauf vom Main Menu bis zum Start
wie in Abbildung 4.24 skizziert, aussehen. B1 und B3 sind in dieser
Darstellung zu einem einzigen Teilbereich zusammengefasst worden.
Main Menu
wähle Auto
Porsche
clearCockpit();
setCockpit(Porsche);
Main Menu
Main Menu
wähle Strecke
Start
Strecke10
clearCockpitView();
setCockpitView(Track10);
Abb.4.24 Ablaufdiagramm bei der Wahl der Strecke und des Autos
Ähnlich wie in diesem Beispiel von Stunts, können mehrere Bereiche
deniert werden und so die Flexibilität der Spielgestaltung erhöht werden.
Der große Vorteil liegt darin, das dadurch eine klare und übersichtliche
Struktur erhalten bleibt, da alle einzelnen Spielelemente, über dieses
Pattern deniert sind.
50
Kapite l
5
Vergleich mit dem Prototypen
5.1 Beschreibung des Prototypen
Im Zuge des Berufspraktikums am Fraunhofer Anwendungszentrum für
Computergraphik in Chemie und Pharmazie (kurz AGC) in Frankfurt, entstand ein, in Flash umgesetztes Computerspiel, welches Medizinstudenten
als Lernergänzung und stoffbezogenes Unterhaltungstool dienen soll.
In Anlehnung an das gleichzeitig laufende k-Med Projekt, wurde als Grundelement und Hauptthema des Spieles der Zitratsäurezyklus gewählt [kMed
2001]. Dieser ist ein wichtiger Bestandteil der Biochemie und durch
die vielen fachspezischen Molekülnamen, schwierig zu erlernen und zu
merken.
Das Spiel selbst wurde in vier einzelne Levels aufgeteilt, welche den
Spieler durch verschiedene Spielvarianten bis zum vollständig fertig
erstellten Zitratzyklus führen sollen. Diese Levels sind aufeinander aufbauend gestaltet, um den Spieler langsam zum Ergebnis zu leiten. Um
den Spieleifer zu steigern, werden entsprechend dem Spielverlauf Punkte
vergeben und am Ende ausgewertet. Ebenso spielt die Zeit eine tragende
Rolle um den Stress als weiteren Spielfaktor heranzuziehen.
Jeder Teil (Level, Menu, usw.) wurde vorerst als einzelner Flashlm erstellt
und erst am Ende des Projektes zu einem Gesamten zusammengefügt.
Die Anwendung wurde in Flash 5.0 und in der asheigenen Scriptsprache
ActionScript implementiert.
Die einzelnen Levels des Prototypen sind im Anhang 1 beschrieben. Eine
spielbare Version des Prototypen bendet sich auf der beigelegten CD und
ist problemlos von dieser aus zu starten. In der folgenden Abbildung 5.1,
sind zwei Auszüge aus dem Spiel dargestellt. In nächsten Kapitel 5.2,
51
V e rgle ich m it de m Pro to t y p e n
werden weitere Screenshots des Spiels zur Erklärung des möglichen Einsatzes von Design Pattern abgebildet.
Abb.5.1 Menü- und Hilfeanzeige des Prototypen
52
5.2 Optimierung des Prototypen durch den Einsatz
von Design Pattern
5.2.1 Einsat z des Template Patterns
Im Bezug auf das Flashspiel ndet man zahlreiche Anwendungsfälle, wo
das Template Pattern sinnvoll eingesetzt werden kann. Das dritte Level des
Prototypen besteht aus einem animierten Molekül auf der linken Seite der
Spieläche und einer Anzahl von animierten Türen, siehe Abbildung 5.2,
welche sich ungleichmäßig auf und zu bewegen9. Der Inhalt der Türen ist
mit wahren und falschen Aussagen gefüllt. Die Reaktion bei Mausklicks
auf die Türinhalte ist ebenfalls unterschiedlich. Dies hängt von der Tatsache ab, ob die Aussage, im Bezug auf das Links dargestellte Molekül,
richtig oder falsch ist.
Abb.5.2 Das dritte Level des Flashspiels
Der Animationsvorgang ist in allen Fällen gleich. So könnte man die Türen
mit der entsprechenden Animation als abstrakte Klasse denieren. Zwei
verschiedene Klassen erben von der abstrakten Klasse. Diese sind die
9 Die ungleichmäßige Bewegung wird durch einen unterschiedlichen Startwert der
Türanimation erreicht.
53
richtigen und die falschen Türinhalte (“wrongElement” und “rightElement”).
Der Beginn der Animation und der Inhalt, wird den Klassen als Variablen
mitübergeben. Abbildung.5.3 zeigt die Anwendung der Template Methode
als Klassendarstellung, im Bezug auf den Prototypen.
BasicElement
animation()
reactionOnClick()
wrongElement
rigthElement
reactionOnClick()
reactionOnClick()
doorContent;
animationStart;
doorContent;
animationStart;
Abb.5.3 Klassenstruktur des Template Patterns im Bezug auf den
Prototypen
Einen möglichen Implementierungsansatz zeigt folgender Pseudocode.
abstract class basicElement {
public basicElement() {
animation();
}
abstract reactionOnClick();
private void animation(){
//code for animation
}
}
class wrongElement extends basicElement {//class rigthElement is nearly the same
public wrongElement(doorContent, animationsStart) {
}
public void reactionOnClick() {
//if user clicks on the region inside the door -> do something
}
}
54
5.2.2 Einsatz des Iterator Patterns
Im ersten Level, Abbildung 5.4, muss der Spieler, ähnlich dem Hangman-Spiel, versuchen, verschiedene Substratnamen zu erkennen und zu
benennen.
Abb.5.4 Screenshot des ersten Levels des Prototypen
Der Computer berechnet zufällig das Erscheinen der einzelnen Buchstaben der Wörter. Diese sind einzeln in einem, der Länge des Wortes
entsprechenden, Array (LetterArray) abgelegt. Jeder Buchstabe eines
Wortes ist durch die Position im Array mit einem Index versehen (siehe Abb.
5.5). Der Zufallsgenerator berechnet einen int-Wert (randomValue) und
dieser ist durch die interne Bezeichnung der Arraypositionen (0,1,.....x),
mit einem entsprechenden Buchstaben verknüpft.
f
u
m
a
r
a
t
Einzelne Buchstaben im Array
0
1
2
3
4
5
6
Index: Position im Array
Abb.5.5 Verknüpfung zwischen Index und Buchstaben
55
Leider passiert es, dass der Zufallsgenerator auch wiederholt gleiche Werte
ausgibt. Um dies zu verhindern, werden die bereits generierten Zufallszahlen in einem neuen Array (checkArray) abgelegt, und ein Iterator
wird dazu eingesetzt, dieses Array jedes Mal zu durchlaufen und zu
überprüfen, ob sich die gerade erzeugte Zufallszahl bereits im Array bendet, d.h. der Buchstabe wurde bereits gesetzt. Folgender Pseudocode
in Abbildung 5.6, soll dieses Problem veranschaulichen. Siehe ebenfalls
Punkt 4.2.2.
...
... //read word from le and put the single Letters
... //in a string-array called “LetterArray”
...
Array checkArray = new Array[LetterArray.length()] //the check-array for
//the random-values
int counter=0;
int randomValue=0;
String SplitLetter;
while (counter < LetterArray.length()){
//loop as long as every letter
randomValue = random(LetterArray.length()); //of the word is in the array
if(checkLetters(LetterArray)){
checkArray[counter] = randomValue;
}
}
...
...
//TRUE if random value is new
//put the new value in the
//checkArray
SplitLetter= getLetter(randomValue); //specify the letter on the
//arrayposition
DrawLetter();
//draw letter on the screen
counter++;
...
...
...
public boolean checkLetters(String arrayToCheck){
Iterator it = arrayToCheck.getElements();//get all elements of the stringarray
while(it.hasNext()){
if(it.next =! zufallsZahl){
//if we still have the random-value
return false;
}
}
return true;
//if it is a nonexistent random-value
}
...
...
Abb.5.6 Pseudocode für eine Iterator-Anwendung
56
5.2.3 Einsatz des Mvc-konzepts und Observer Patterns
Der Einsatz des MVC-Konzepts beim Prototypen leitet sich eigentlich
aus einem ashspezischen Problem, dem Platzieren der einzelnen Filmsequenzen auf der Zeitleiste und deren Kommunikation untereinander,
ab. Jedes einzelne Level wurde vorerst als eigenständige Filmsequenz
erstellt und erst am Ende in eine gemeinsame Zeitleiste, zu einer einzelner,
durchgehender Sequenz zusammengefügt. Jedoch mussten die vielen
Parameter des Spieles (Punkte, Leben, Munition,..) mitübergeben werden.
Dies stellte im nachhinein ein größeres Abstimmungsproblem dar, weil
sich einige Werte nicht so einfach von einer Filmsequenz zur anderen
übergeben ließen. Dieses Problem könnte man mit dem geschickten Einsatz des MVC-Patterns wesentlich verbessern. Wie sich dies auf den Prototypen auswirkt, sehen wir anhand der Abbildung 5.7. Die Darstellung
beruht auf der im Punkt 4 vorgestellten, allgemeinen Kommunikation
zwischen den Teilsystemen des MCV-Patterns. Als Observer werden alle
jene Elemente deniert, welche das gesamte Spiel über, in allen Levels
gleich bleiben. Diese Status Informationen werden in der Fachsprache als
HUDs, Heads-Up-Display, bezeichnet [GameDevDict 2002]. Diese HUDs
des Prototypen werden in der Abbildung 5.8 dargestellt.
View:
Munitionsanzeige
View:
Punkteanzeige
Bestätigung
Wertänderung
Model:
Quellcode für die
Erstellung der Levels
HUDs
Eingabewerte
View:
Lebensanzeige
View:
Zeitanzeige
Controller:
Eingabe durch
Tastatur und Maus
Abb.5.8 MVC Darstellung bezogen auf den Prototypen
57
Punkte
Leben
Zeit
Munition
Abb.5.7 Beispiel für HUDs beim Prototypen
Natürlich besteht das anfangs erwähnte Problem durch die einzelnen
Filmsequenzen bei der Programmierung in Java nicht, sondern ist ein
alleiniges Problem bei ashähnlichen Tools. Durch die hilfreiche Trennung
der einzelnen Systeme, lassen sich in der Spieleentwicklung aber schnell,
viele weitere Anwendungsfälle, in mehr oder weniger abgewandelter Form,
nden.
Die Anwendung des Observer Patterns kann ebenfalls mittels den HUDs
demonstriert werden. Bei vielen Anwenderaktionen werden durch falsches
oder richtiges Handeln, Werte für Punkte, Leben, Zeit und Munition gesetzt. Dies könnte durch den Einsatz eines Observer Patterns realisiert
werden. Trifft man im dritten Level, siehe Abbildung 5.2, zum Beispiel eine
richtige Tür, muss der Munitionstand und der Punktestand aktualisiert
werden. Trifft man eine falsche Tür, hat dies Auswirkungen auf die Zeit,
die Munition und oftmals auch auf die Leben.
58
5.2.4 Einsatz des Factory Patterns
Im ersten Teil des vierten Levels, dargestellt in Abbildung 5.9, erscheinen
zufällig Substrate, Enzyme und Energieträger auf der Spieläche. Ähnlich
den Spielsteinen im Geschicklichkeitsspiel Aquanoid, siehe dazu Kapitel
4.2.4, könnte die Erzeugung durch den Einsatz einer Factory Methode verbessert werden.
Abb.5.9 Level 4 des Flashspiels
Die 3 verschiedenen Elemente, (Enzyme, Substrate und Energieträger),
haben ebenfalls unterschiedliche Eigenschaften welche beim Erzeugen
deniert werden müssen. Die Elemente erscheinen zufällig und bewegen
sich auf der Spieläche vor und zurück. Zusätzlich zu den Bewegungsanimationen müssen weitere Eigenschaften deniert werden, um das
Element genau zu spezizieren. Es darf immer nur ein richtiges Element
erscheinen und es kann ihm auch nur ein bestimmter Platz am Spielfeldrand zugeordnet werden. Weiters muss noch die Reaktion bei Mausclick auf das Element (entspricht einem Abschuss des Elementes) deniert
59
werden. Durch diese aufwändigen Kongurationen der einzelnen Spielobjekte, kann zum Einsatz des Factory Patterns gegriffen werden.
Da es auch falsche Enzyme, Substrate und Energieträger geben kann,
muß die Factory Methode dementsprechend erweitert werden. Folgender
Pseudocode zeigt wie dieses Problem als Factory-Methode in Java zu beheben sein könnte.
public class CACElement {
private CACElement() {
}
public static CACElement createCACElement(string element) {
CACElement cacel = null;
if(element == wrongEnzyme) {
//create a wrong enzyme with all specications
}
}
}
else if(element == rightEnzyme) {
//create right enzyme with all specications
}
…
//The same with the other Elements
…
Will man nun zum Beispiel dieses Level erweitern, Hinzufügen von weiteren
falschen Elementen, muss nur eine weitere if-Anweisung zur bestehenden
Factory-Methode hinzugefügt werden.
60
5.2.5 Einsatz des Platzhalter Patterns
Betrachtet man einen Screenshot des Flashspiels, wie z.B. Abbildung
5.7, so lassen sich drei grundlegende Teilbereiche festlegen. Die Anzeige
der HUDs, die Darstellung des Levelfortschritts auf der rechten Seite,
sowie natürlich die eigentliche Spieläche. In Abbildung 5.10 wird diese
Aufteilung skizziert.
C1
C3
C1 – Spielfläche
C2 – Levelanzeige
C3 – Anzeige der HUDs
C2
Abb.5.10 Aufteilung des Prototypen in gleichbleibende Teilbereiche
Vergleicht man die unterschiedlichen 4 Levels, (Abbildung 5.2, 5.4, 5.7
und 5.9) untereinander, wird ersichtlich, dass sich alle Teilbereiche (C1,
C2, C3) jeweils ändern.
Zwar ist der strukturelle Aufbau von Flashanwendungen im Vergleich
zu Javaprogrammen, wie schon beim MVC-Konzept beschrieben, unterschiedlich, aber die Absicht und Möglichkeiten, welche sich durch den
Einsatz des Platzhalter Patterns bieten, ist wohl durch dieses und Kapitel
4.2.5 klar geworden.
Wahrscheinlich müssen immer noch einige weitere Spezikationen und
Veränderungen getroffen werden, um dieses Pattern richtig und efzient
einsetzen zu können. Aber wie bei allen bisherigen Pattern, muss es sich
durch den oftmaligen Einsatz in der Spieleindustrie erst einmal beweisen.
Ob es sich dann durchsetzen kann oder in Vergessenheit gerät, wird sich
erst herausstellen.
61
Kapite l
6
Zukunft der Computerspiele
Schon 1952, kurz nach Einführung der ersten kommerziellen Computer,
wurde, jedoch nur für wissenschaftliche Zwecke, ein Dame-Programm
entwickelt. Doch erst mit der Implementierung von Spacewar 1962, Abbildung 6.1, wurde die Ära der Computerspiele eingeläutet [Ahl 1978].
Den großen Durchbruch und somit der Auslöser der Mainstream-Videospiele, ebnete das in Abbildung 6.2 dargestellte, 1971 konzipierte Computerspiel Pong. Dieses
Spiel gab den Anstoß für
die rasante Entwicklung
der Spielebranche, egal ob
für den Heimbereich oder
die öffentlichen Münzspielautomaten. Mit der
Entwicklung des Com- Abb. 6.1 Abb. 6.1 Spacewar Abb. 6.2 Pong [ClassicGames
2002]
[ClassicGames 2002]
modore C64 (ca. 1982),
konnte jedermann nun selbst zum Programmierer von Computerspielen
werden, und es entstand dadurch eine breite Masse an Spielen und
Genres. Beinahe alle heutigen Spielgenres waren schon auf dem C64
vertreten. Spätere Spiele übertrafen die C64-Spiele nur an feinerer Ausarbeitung, besserer Graphik und besseren Audioeffekten. Die Zeiten wo
jedermann nach Lust und Laune erfolgreich Computerspiele programmieren konnte, sind jedoch vorbei. Obwohl sich die Spieleindustrie seit
deren Beginn rasant entwickelt hat, ist sie noch immer weit hinter ihren
Möglichkeiten zurück. Ihre Entwicklung lässt sich am Besten mit der des
Films vergleichen. Die Technik der Computerspiele bestimmt derzeit noch
weitgehend den Verkaufserfolg, genau so wie damals in den 20iger Jahren,
62
Z u k u nf t de r Co m p u te rsp ie le
2
den der Filme. Durch die Weiterentwicklung der Technik, wurde bei
Filmen plötzlich mehr Wert auf dessen Inhalt gelegt. Selbiges zeichnet sich
nun auch bei den Computerspielen ab [Braben 2002]. Derweilen ist es
noch leicht möglich, eine schlechte Spielhandlung mit perfekter Graphik
aufzubessern, um somit das Produkt noch zu retten. Spielt jedoch die
Rechenleistung keine Rolle mehr, muss der ausschlaggebende Unterschied mehr in der Story, als in der Technik liegen [NEO 2002]. Laut
Moore’s Gesetz10, wird die Rechenleistung, derzeit ohne Aussicht auf ein
Ende, weiter stetig steigen. Abbildung 6.3 zeigt dieses Gesetz und dessen
Auswirkung seit 1970. Laut Intel, wird diese Entwicklung noch mindes-
Abb. 6.3 Moore’s Gesetz [Moore 1965b]
tens weitere 10 Jahre anhalten. Sony erklärte sogar, dass ihnen dieser
Fortschritt zu langsam sei. Die neue PS3 soll ca. 1000 mal leistungsfähiger
sein als die PS2. Sony will allerdings nicht solange warten, bis sich diese
Leistung auf herkömmlichen Weg realisieren lässt [Braben 2002]. Sie
wollen noch keine genauen Aussagen darüber treffen, wie sie dieses Ziel
erreichen können, sondern sprechen bisher nur verschwommen vom Einsatz des sogenannten grid computing11 [Becker 2002].
Ein weiterer Entwicklungsschritt durch höhere Rechenleistung und ausgefeilterer Technik, ist die immer intensivere Vereinigung zwischen dem
10 Moore’s Gesetz (englisch: Moore’s Law, aufgestellt von Gordon Moore 1965) besagt,
dass die Geschwindigkeit aktueller Prozessoren alle 18-24 Monate ungefähr, durch
einen Nachfolger verdoppelt wird [Moore 1965a].
11 grid computing bedeutet, das Verbinden von einer Vielzahl von Computern zu
einem größeren, virtuellen System zur Steigerung der Verarbeitungsgeschwindigkeit
[Shankland 2002].
63
2
Spieler mit dem Spiel selbst werden. Die Spielwelten werden immer
komplexer, die Interaktion umfangreicher und eine realistischere Darstellung der Realität wird durch genauere physikalische Eigenschaften,
besserer Graphik und ausgefeilterer künstlicher Intelligenz (KI) erreicht
[Rollings & Morris 2000]. Demis Hassiabis, Gründer von Elixr Studios,
sieht eine immense Weiterentwicklung der KI-Routinen welche sich
möglicherweise in Hardware-KI-Beschleunigern, ähnlich wie bisher für
Graphikkarten, oder sogar in eigenen Articial Intelligence Operating Systems, bemerkbar machen [Houlihan 2001]. Die Verschmelzung mit dem
Spiel, das Eintauchen in die virtuelle Welt, ist bereits mit vielen Techniken,
wie zum Beispiel 3D Brillen, Abbildung
6.4, Cave-Anwendungen, Abbildung 6.5,
oder Datenhand-Schuhen, Abbildung 6.6,
teilweise möglich [Dertouzos 1999]. Bald
werden diese Systeme von jedem potentiellen Spieler genauso alltäglich genutzt,
wie heutzutage Maus oder Tastatur. Ein
weiterer unaufhaltsamer EntwicklungsAbb.6.4 3D Brille - Shutter Glasses
[Dansdata 2002]
schritt, ist die vermehrte Nutzung des Internets, um mit
vielen Mitspieler
über
Grenzen
hinweg gemeinsam an einem
Spiel teilnehmen
zu können. In
einzelnen Fällen
Abb.6.5 Modell eines Caves
Abb.6.6 Datenhandschuh
wird das Internet
[Indiana 2002]
[York 2002]
bereits genutzt,
um viele Spieler in einem Spielfeld zu versammeln. Vor allem bei RPG12und FPS13-Spielen kommt es bisher vermehrt zum Einsatz. Laut Shu
Yoshide, Vizepräsident der Produktentwicklung von Sony Computer Entertainment America, benden wir uns mit der Ausnutzung der Onlinetechnologie für Computerspiele, im Vergleich, gerade einmal auf der
selben Stufe wie damals, als 3D Technologie nur für Arcade Games,
12 RPG ist die Abkürzung für Roleplaying Game, also Rollenspiele.
13 FPS ist die Abkürzung für First-Person-Shooter z.B. CounterStrike
64
2
Schießspiele und Fahrsimulatoren verwendet wurde. Jedes einzelne Spielgenre könnte durch die Verwendung der Onlinetechnologie revolutioniert
werden. Denn es gibt keine bessere und natürlichere KI, als die der Spieler
selbst [Yoshida 2002].
65
Kapite l
7
Resümee
Durch die ständige Verbesserung und Weiterentwicklung der Computerspiele und deren Technik, müssen ständig Neuerungen und Verbesserungen
im Entwicklungsablauf getätigt werden, um mit dieser Entwicklung schritt
halten zu können.
Im zweiten Kapitel wurde festgestellt, das sich die Entwicklungsteams
seit der vermehrten, kommerziellen Nutzung der Computerspiele, stark
verändert haben. Verschiedene Arbeiten, welche früher von einer einzelnen Person erledigt werden konnten, mussten in separate, genauer
spezizierte Arbeitsbereiche aufgeteilt werden. Durch diese Trennungen
wurde die Kommunikation unter den einzelnen Mitarbeiter teilweise immer
schwieriger, aber das Verständnis für die gegenseitigen Probleme immer
bedeutender. Daher muss ein gutes Management und eine klare Kommunikationshierarchie dafür sorgen, dass eine reibungslose Verständigung
untereinander gewährleistet werden kann.
Der Entwicklungsvorgang bei Computerspielen ist so stark vom Marktverlagen und Lizenzverträgen geprägt, dass die Unternehmen ohne Rücksicht
auf eine klare und strukturierte Entwicklungsarbeit nehmen zu können,
die Produktentwicklung vorantreiben, um am Ende ein zufriedenstellendes
Ergebnis zu erhalten.
Design Pattern können, falls sie für jedermann zugänglich und wohlüberlegt
deniert sind, viel Arbeitsaufwand und Entwicklungsarbeit einsparen, da
sie grundlegende, immer wieder auftretende Strukturen und Probleme in
der Spielebranche beschreiben. Diese können in folge, ohne größeren Zeitaufwand, in weitere Projekte integriert werden. Dadurch steigt vor allem
die Klarheit, Strukturiertheit und Flexibilität des Projektes. Obwohl viele
Pattern bereits in der herkömmlichen Softwareindustrie erfolgreich
66
Re sü m e e
2
eingesetzt werden, geht die Adaption auf die Spielentwicklung eher
langsam voran. Um die Spieleentwicklungen schneller und efzienter
voran treiben zu können, muss eine gewisse Zusammenarbeit aller Entwickler vorherrschen, um die potentiellen Kunden mit immer neueren
und besseren Spielen zu überraschen und die Grenzen des Möglichen
zu erweitern. Gerade beim Einsatz von Design Pattern kann ein großer
Schritt in die Richtung der efzienteren Entwicklung gemacht werden.
Die Sammlung verschiedenster spielespezischer Design Patterns auf der
Webseite von Gamasutra14, ist sicher ein guter Anfang, um eine allgemeine Regelung und Verwendbarkeit von Patterns in der Spieleentwicklung zu gewährleisten und diese auch jedem potentiellen Spieleentwickler zugänglich zu machen.
14 www.gamasutra.com
67
Literaturverzeichnis
[Ahl 1978]
Ahl D.: Basic Computer Games, Sybex Verlag, 1978
[Alexander 1977]
Alexander Ch.: A Pattern Language: Towns, Buildings, Constructions.
Oxford University Press, 1977.
[Amrhein 2002]
Amrhein B.: Design Pattern für Graphische Benutzeroberächen.
URL, http://www.hta-be.bfh.ch/~amrhein/Skripten/Swing/Pattern.pdf,
02. Mai 2002, Kopie auf CD-ROM (Amrhein_MVC.pdf)
[Amstrad 2002]
URL, http://www.homecomputermuseum.de, 04. Juni 2002,
Kopie auf CD-ROM (Amstrad.pdf)
[Askit 1998]
Aksit K.: Architektur-Muster für Software-Systeme - Einführung in das
Thema “Patterns”. URL, http://wwwpaul.informatik.tu-muenchen.de/
seminare/softwareentwicklungWS98/Architekturmuster/,
04. Juni 2002, Kopie auf CD-ROM (PatternEinfuehrung.pdf)
[Baldwin 1998]
Baldwin G. R.: Implementing The Model-View-Controller Paradigm using
Observer and Observable. URL,
http://home.att.net/~baldwin.rick/Advanced/Java200.htm,
02. Mai 2002, Kopie auf CD-ROM (javaMVC.pdf)
68
L ite ratu r v e rz e ichnis
[Bartlett 2001]
Bartlett E.: So you want to be a games designer. URL,
http://www.igda.org, 15. April 2002,
Kopie auf CD-ROM (wantDoBeGamesDesigner.pdf)
[Battleship 2002]
Einfaches JavaScript Computerspiel
URL, http://www.lcss.net/num/games_b.htm, 04 Juni 2002,
Kopie auf CD-ROM (Battleship.pdf)
[Becker 2002]
Becker D.: PlayStation 3 takes to the grid, ZDNet News
URL, http://zdnet.com.com/2100-1105-866388.html, 23. Mai 2002,
Kopie auf CD-ROM (Playstation3.pdf)
[Burwell 2001]
Burwell C.: Calling the Shots, Decision Making for Games.
Game Developer Magazine, S. 38-44, January 2001
[Braben 2002]
Braben D.: Another Five Years from Now: Future Technologies,
Vortrag von David Braben auf der Game Developer Conference 2002
URL, http://www.gdconf.com, 23. Mai. 2002,
Kopie auf CD-ROM (gdconf-Archive.pdf)
[ClassicGames 2002]
URL, http://www.classicgaming.com/museum/pong/, 23.Mai.2002,
Kopie auf CD-ROM (ClassicGaming.pdf)
[Dansdata 2002]
URL, http://www.dansdata.com/v8200d.htm, 23.Mai.2002,
Kopie auf CD-ROM (ShutterGlasses.pdf)
69
[Dertouzos 1999]
Dertouzos M.: What will be. Die Zukunft des Informationszeitalters.
Springer-Verlag Wien New York 1999
[Eckel 2001]
Eckel B.: Thinking in Patterns with Java, Revision 0.6. HTML Version
URL, http://www.mindview.net/Books/TIPatterns, 02. Mai 2002,
Kopie auf CD-ROM (Thinking in Patterns/html/index.html)
[Falstein & Fox 1997]
Falstein N., Fox D.: Collaborating in Game Design. URL,
http://www.gamasutra.com/features/, 26. März 2002
Kopie auf CD-ROM (Collaborating.pdf)
[Freeman 1997]
Freeman T.: Creating a Great Design Document,
URL, http://www.gamasutra.com/features/game_design/091297/
design_doc.htm,
15. April 2002, Kopie auf CD-ROM (greatingGreatDesignDocuments.pdf)
[FutureZone 2002]
ORF-Artikel auf FutureZone: Wiener Game Design für die Xbox.
URL, http://futurezone.orf.at, 18. April 2002
Kopie auf CD-ROM (FutureZoneMaxPayne02.pdf)
[GameCube 2002]
Nintendo GAMECUBE News Page - System Summary
URL, http://members.aol.com/mips36/specs.htm, 17.April 2002,
Kopie auf CD-ROM (GameCube.pdf)
[GameDevDict. 2002]
Internes Wörterbuch von GameDev.net, URL,
http://www.gamedev.net/dict, 02. Mai 2002,
Kopie auf CD-ROM (HUD.pdf)
70
[Gamma et al. 1994]
Gamma E., Helm R., Johnson R., Vlissides J.: Design Patterns: Elements
of Reusable Object-Oriented Software. Adison Wesley Longman, 1994
[Gruber 2001a]
Gruber D.: Working With Other People.
URL, http://www.makegames.com/chapt3.html, 26. März 2002,
Kopie auf CD-ROM (WorkingWithOtherPeople.pdf)
[Gruber 2001b]
Gruber D.: Do You Have What it Takes to Be a Game Developer?
URL, http://www.makegames.com/chapt1.html, 26 März 2002,
Kopie auf CD-ROM (DoYouHaveWhatItTakes.pdf)
[Hecker & Simpson 2000]
Hecker Ch., Simpson B. Z.: Game Programming Patterns and Idioms.
Game Developer Magazine, Sept. 2000
[Helman 1998]
Helman D.: Model-View-Controller,
URL, http://ootips.orp/mvc-pattern.html, 02.Mai 2002,
Kopie auf CD-ROM (ootipsMVC.pdf)
[Houlihan 2001]
Houlihan J.: GDC: Demis Outlines The Future Of Articial Intelligence
In Gaming, URL, http://ww.gamespot.co.uk/printer/stories/news/
0,2160,2094344,00.html, 23. Mai 2002,
Kopie auf CD-ROM (FutureOfAI.pdf)
[Indiana 2002]
URL, http://avl.indiana.edu/facilities/index.shtml, 27.Mai.2002,
Kopie auf CD-ROM (Cave.pdf)
71
[kMed 2001]
Homepage des k-Med Projektes, URL,
http://www.k-med.org, 10. Juni 2002
Kopie auf CD-ROM (kMed.pdf)
[Kreimeier 2002]
Kreimeier B.: The Case For Game Design Patterns
URL, http://www.gamasutra.com/features, 10. Juni 2002
Kopie auf CD-ROM (Kreimeier.pdf)
[Krüger 2000]
Krüger G.: Go To Java 2, Handbuch der Java-Programmierung
HTML Version 2.0, URL, http://www.javabuch.de/download.html,
24. April 2002, Kopie aud CD-RROM (GoToJava2/html/index.html)
[Lam 1998]
Lam St.: Observer Design Pattern. URL,
http://sern.ucalgary.ca/courses/SENG/609.04/W98/lamsh/
observerLib.html, 02. Mai 2002, Kopie auf CD-ROM (Observer.pdf)
[Laramee 2002]
Laramee F. D.: The Game Design Process. URL, www.gamedev.net,
02. April 2002, Kopie auf CD-ROM (GameDesignProcess.pdf)
[Leßmann 2001]
Leßmann J.: Software Patterns und Pattern Languages. Seminararbeit,
Fachbereich Mathematik/Informatik, Universität Paderborn, 2001
Kopie auf CD-ROM (Lessmann.pdf)
[MaxPayneInt. 2001]
GamesWeb - Homepage.: Online Interview mit Markus Wilding. URL,
http://gamesweb.com/pc/specials/interviews/maxpayne-interview.php,
17. April 2002, Kopie auf CD-ROM (MaxPayneInterview.pdf)
72
[McCuskey 2000]
McCuskey M.: LoneWolf Killers. PartII: The Development Phase
URL, http://www.gamedev.net, 02. April 2002
Kopie auf CD-ROM (LoneWolfKillers_Part2.pdf)
[Moore 1965a]
URL, http://www.computerlexikon.com, 23.Mai.2002,
Kopie auf CD-ROM (Computerlexikon.pdf)
[Moore 1965b]
URL, http://www.intel.com/research/silicon/mooreslaw.htm,
23.Mai.2002, Kopie auf CD-ROM (MooresLaw.pdf)
[NEO 2002]
Spielerma NEO in Wien: Interview mit Erik Pojar. 01. März 2002
Kopie auf CD-ROM (InterviewNEO.pdf)
[Nintendo 2002]
Nintendo GameCube - Homepage, URL,
http://www.nintendogamecube.com, 17.April 2002,
Kopie auf CD-ROM (NintendoGameCube.jpg)
[nVIDIA 2002]
nVIDIA Homepage - Rubric Products, URL, http://www.nvidia.com/view
.asp?PAGE=geforce4mx, 17.April 2002, Kopie auf CD-ROM (GeForce.pdf)
[ORF 2002]
ORF-Homepage - Futurezone Forum.
URL, http://futurezone.orf.at, 12. März 2002,
Kopie auf CD-ROM (neo_MaxPayne.pdf)
[PatternQuiz 2002]
Denition von eigenen Persönlichkeitsmustern, URL,
http://members.aol.com/groovydougie/quizzes/pattern.htm,
04 Juni 2002,Kopie auf CD-ROM (PatternQuiz.pdf)
73
[Pedersen 2001]
Pedersen E. R.: Pedersen’s Principles on Game Design and Production
URL, http://www.gamedev.net, 02. April 2002
Kopie auf CD-ROM (PedersensPrinciples.pdf)
[PS2 2002]
Playstation - Homepage, URL, http://www.playstation2.com,
17.April 2002, Kopie auf CD-ROM (ps2.jpg)
[Rollings 2000]
Rollings A.: Zitate. URL, http://www.spieldesign.de/Zitate/zitate.html,
26. März 2002, Kopie auf CD-ROM (Zitat_Rollings.pdf)
[Rollings & Morris 2000]
Rollings A., Morries D.: Game Architecture and Design. Coriolis, 2000
[Rouse 2001]
Rouse R.: What Ever Happened to the Designer/Programmer?
Game Developer Magazine, S. 88, April 2001
[Saltzmann 2000]
Saltzmann M.: Game Design, zweite Ausgabe. Die Geheimnisse der Pros.
X-Games München, 2000
[Sanchez & Dalmau 2001]
Sanchez D., Dalmau C.: The Birth of a New Game Studio, Part One:
Humble Beginnings. URL, http://www.gamasutra.com/features/,
26. März 2002, Kopie auf CD-ROM (humbleBeginnings.pdf)
[Shankland 2002]
Shankland S.: Big Blue, Energy Dept., eye Science Grid, ZDNet News,
URL, http://zdnet.com.com/2100-1103-866631.html, 23.Mai.2002,
Kopie auf CD-ROM (gridComputing.pdf)
74
[Sikora 2002a]
Sikora D.: You Got Game, Part 1: The Idea. URL,
http://www.gamedev.net, 02. April 2002,
Kopie auf CD-ROM (gotGame_Part1.pdf)
[Sikora 2002b]
Sikora D.: You Got Game, Part 2: The Design. URL,
[Sikora 2001c]
Sikora D.: You Got Game, Part 3: The Document. URL,
[Sikora 2001d]
Sikora D.: You Got Game, Part 4: The Development. URL,
http://www.gamedev.net, 26. März 2002,
[Stunts 2002]
Related Game Site for Stunts. URL, http://www.mobygames.com/game/
sites/gameId,329/, 26. April 2002, Kopie auf CD-ROM (Stunts.pdf)
[Wiesner 2001]
Wiesner St.: Factory Pattern. Besonderheiten in der Implementierung
in Java. URL, http://rzserv2.fhnon.de/~lg002556/designpattern/
Factory_Pattern.htm, 02. Mai 2002,
Kopie auf CD-ROM (WiesnerFactory.pdf)
[Wohlgemuth 1999]
Wohlgemuth C.: Behavioral Patterns: Strategy Pattern und Template
Method. URL, http://www.uni-koblenz.de/~wohlg/Prosem3_99.htm,
22. April 2002, Kopie auf CD-ROM (BehavioralPatterns.pdf)
75
[XBox 2002]
XBox - Homepage, URL, http://www.xbox.com, 17.April 2002,
Kopie auf CD-ROM (XBox/xbox.html)
[XBoxFAQ 2002]
AreaXBox - Das Xbox-Online-Magazin.: FAQ.
URL, http://www.areaxbox.de/php/faq.php#9, 17.April 2002,
Kopie auf CD-ROM (XBoxFAQ.pdf)
[York 2002]
Homepage der York University in Toronto, Canada,
URL, http://www.yorku.ca/mack/Bareld.html, 07. Juni 2002,
Kopie auf CD-ROM (DataGlove.pdf)
[Yoshida 2002]
Yoshida, S.: Next Generation Console Development and Production in the
Global Market: Opportunities and Challenges. Vortrag von Shu Yoshida
auf der Game Developer Conference 2002, URL, http://www.gdconf.com,
23. Mai. 2002, Kopie auf CD-ROM (Shu Yoshida.pdf)
76
Anhang1: Spielbeschreibung
Allgemeine Info:
Als Munition stehen jeweils 5 Pillen zur Verfügung. Um Nachzuladen, wird
einfach die STRG (CTRL) - Taste gedrückt. Ist die gesamte Zeit in den
Leveln 1, 3 und 4 abgelaufen, so verliert der Spieler ein Leben. In Level
2 wird ein Leben abgezogen, wenn richtige Substrate mit einer Pille abgeschossen werden.
Level 1: “Mystische Buchstaben”
Im ersten Level werden Substratnamen gesucht. Der Computer beginnt,
Buchstabe für Buchstabe das jeweilige Wort auszufüllen. Je schneller
man die Namen erkennt, desto mehr Zeit bleibt, um das Wort zu
vollenden. Ein Click auf das Substratsymbol links stoppt den Computer
und der Spieler kann das Wort vervollständigen!
Level 2: “Ein verrückter Flug”
Die richtigen Substrate sollte man auffangen und falsche Stoffe abschießen.
Man bekommt dafür Punkte gut geschrieben. Werden falsche Substanzen
gefangen oder gar richtige abgeschossen, wird das mit Zeitaddition und
Abzug eines Lebens bestraft. Hier kann der Spieler mit der LEERTASTE
(SPACE) die Pillen abfeuern. Eine Kontrolle über die zur Verfügung stehende Zeit bietet die Anzeige neben der Uhr.
77
Anhnag 1: S p ie lbe schre ibu ng
2
Level 3: “Irre Synonyme”
Die rechts stehenden Synonyme müssen dem links erscheinenden
Molekül zugeordnet werden. Man muss jedoch beachten, dass sich viele
irreführenden Aussagen unter die Richtigen gemischt haben. Der User hat
in 3 Runden die Möglichkeit, sein Wissen zu überprüfen.
Level 4: “Der CAC”
Das letzte Level setzt sich aus zwei eigenen Sublevels zusammen. Als erstes
soll man die im Zitratzyklus vorkommenden Enzyme und Energieträger auf
die entsprechenden Platzhalter links und oben am Spielfeldrand ziehen.
Um mehr Punkte zu erlangen, kann der Spieler falsche Stoffe abschießen.
Immer wieder versuchen sich andere, falsche Stoffe an das gerade aktive
Teil anzuhängen, wodurch der Schwierigkeitsgrad erhöht wird. Die gesammelten Substrate vom zweiten Level sind in dieser Version des Prototypen bereits gutgeschrieben.
Hat man alle nötigen Stoffe gesammelt, muss der Zitratzyklus nun richtig
zusammengesetzt werden. Die Reihenfolge ist egal, aber es wird natürlich
bestraft (Zeitaddition), versucht man eine Substanz auf einen falschen
Platz im Zitratzyklus zu ziehen.
78
Anhang2: Inhaltsverzeichnis
79

Der Produktionsprozess in der Spieleentwicklung und mögliche

Transcription

Similar documents

Gedanken zu einer Buddhistischen Psychotherapie Teil 1

1 Freeway Betriebsjournal Weihnachts- Ausgabe

Mit Computerspielern ins Spiel kommen - LfM

Adventure,German Goethe-Institut and developer

Reglwerk des DSBC - Deutscher Blasrohr Sport Club

PowerPoint 2013 - Animationen - Justus-Liebig

(werbe)agentur - Glorienschein

Adgames Katalog