Ein von Gameengines unabhängiges User-Interface

Transcrição

Fachbereich 4: Informatik
Ein von Gameengines
unabhängiges
User-Interface-System für PC
Spiele
Diplomarbeit
zur Erlangung des Grades eines Diplom-Informatikers
im Studiengang Computervisualistik
vorgelegt von
Arne Johannes Deutsch
Erstgutachter:
Prof. Dr.-Ing. Stefan Müller
(Institut für Computervisualistik, AG Computergraphik)
Zweitgutachter: Dipl.-Inform. Oliver Abert
(Institut für Computervisualistik, AG Computergraphik)
Koblenz, im März 2006
1
Erklärung
Ich versichere, dass ich die vorliegende Arbeit selbständig verfasst und keine
anderen als die angegebenen Quellen und Hilfsmittel benutzt habe.
Ja
Nein
Mit der Einstellung der Arbeit in die Bibliothek bin ich einverstanden.
Der Veröffentlichung dieser Arbeit im Internet stimme ich zu.
.................................................................................
(Ort, Datum)
(Unterschrift)
(Platzhalter für Aufgabenstellung)
Inhaltsverzeichnis
1 Einleitung
1.1 Motivation .
1.2 Ziele . . . .
1.3 Aufbau . . .
1.4 Zur Sprache
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7
7
7
8
9
2 Standard User Interfaces
10
2.1 Komponenten . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3 Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3 User Interfaces in Computerspielen
3.1 Spielanalysensystematik . . . . . .
3.2 Kartentaktikspiel: Etherlords . . .
3.3 Echtzeitstrategie: Warcraft 3 . . . .
3.4 Ergebnisse . . . . . . . . . . . . . .
3.4.1 Verhalten . . . . . . . . . .
3.4.2 Features . . . . . . . . . . .
3.4.3 Standard Komponenten . .
3.4.4 Erweiterte Komponenten . .
4 Game UI-Framework
4.1 Anforderungen . . . . . . . . . . .
4.1.1 Allgemeine Anforderungen .
4.1.2 Featureanforderungen . . . .
4.1.3 Komponentenanforderungen
4.2 Design . . . . . . . . . . . . . . . .
4.2.1 Komponentenaufbau . . . .
4.2.2 Kommunikation . . . . . . .
4.2.3 Look and Feel . . . . . . . .
4.2.4 Ein- und Ausgaben . . . . .
3
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
24
25
26
30
34
34
35
36
38
.
.
.
.
.
.
.
.
.
40
40
40
42
43
44
45
46
46
47
INHALTSVERZEICHNIS
4.3
4
Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.3.1 Technologien . . . . . . . . . . . . . . . . . . . . . . . 49
4.3.2 Details . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5 Demos
58
5.1 Allgemeines . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.2 Demo 1 - Warcraft 3 . . . . . . . . . . . . . . . . . . . . . . . 61
5.3 Demo 2 - Etherlords . . . . . . . . . . . . . . . . . . . . . . . 62
6 Ausblick
66
6.1 Eigene Mauszeiger . . . . . . . . . . . . . . . . . . . . . . . . 66
6.2 Unabhängigkeit von Programmiersprachen . . . . . . . . . . . 66
6.3 Konfiguration mittels Beschreibungssprache . . . . . . . . . . 67
7 Fazit
68
7.1 Erfüllte Anforderungen . . . . . . . . . . . . . . . . . . . . . . 68
7.2 Kritik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
7.3 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . 73
A Weitere Spielanalysen
A.1 Actionrollenspiel: Sacred . . . . . . . . . . . . . . . . . . . . .
A.2 Aufbausimulation: Die Siedler 5 . . . . . . . . . . . . . . . . .
A.3 Rundenstrategie: Master of Orion 3 . . . . . . . . . . . . . . .
74
75
81
85
B Screenshots der Spiele
89
Abbildungsverzeichnis
2.1
2.2
Aufbau der Komponenten in Swing am Beispiel eines Buttons 19
Beispiel einer Delegate-Installation in Swing . . . . . . . . . . 22
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
Die Architektur des UI-Systems . . . . . . . . . . . . . . . .
Zusammenhänge der wichtigsten Klassen . . . . . . . . . . .
Aufgabendelegation der Klasse UISystem . . . . . . . . . . .
Unabhängigkeit des UI-Systems von anderen Bibliotheken .
Das Interface Component und das View . . . . . . . . . . .
Aufbau eines Buttons im UI-System . . . . . . . . . . . . . .
Events und Listeners des UI-Systems . . . . . . . . . . . . .
Relevante Klassen im Look and Feel System am Beispiel eines
Buttons . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
45
48
50
51
53
54
55
. 57
5.1
5.2
5.3
Verschiedene Mouseover-Effects der Buttons in Demo2 . . . . 62
Demo 1 Screenshots . . . . . . . . . . . . . . . . . . . . . . . . 64
Demo 2 Screenshots . . . . . . . . . . . . . . . . . . . . . . . . 65
B.1
B.2
B.3
B.4
B.5
Sacred Screenshots . . . . . .
Siedler 5 Screenshots . . . . .
Warcraft 3 Screenshots . . . .
Etherlords Screenshots . . . .
Master of Orion 3 Screenshots
5
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
90
91
92
93
94
Tabellenverzeichnis
2.1
2.2
Komponenten in Swing . . . . . . . . . . . . . . . . . . . . . . 11
Features in Swing . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.1
3.2
3.3
3.4
3.5
3.6
Features in Etherlords . . . . . . . . . . . . . .
Komponenten in Etherlords . . . . . . . . . . .
Features in Warcraft 3 . . . . . . . . . . . . . .
Komponenten in Warcraft 3 . . . . . . . . . . .
Zusammenfassung der Features der Spiele . . .
Zusammenfassung der Komponenten der Spiele
4.1
Wichtige Komponenten für Spiele . . . . . . . . . . . . . . . . 43
7.1
Implementierte Komponenten . . . . . . . . . . . . . . . . . . 71
A.1
A.2
A.3
A.4
A.5
A.6
Features in Sacred . . . . . . . . .
Komponenten in Sacred . . . . . .
Features in Siedler 5 . . . . . . . .
Komponenten in Siedler 5 . . . . .
Features in Master of Orion 3 . . .
Komponenten in Master of Orion 3
6
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
28
28
32
32
36
37
76
77
82
82
86
87
Kapitel 1
Einleitung
1.1
Motivation
Es gibt viele verschiedene Oberflächenbibliotheken die man verwenden kann
um Anwendungen zu erstellen. Sie eignen sich für die meisten der üblichen
Anwendungen die man auf dem PC findet. Textverarbeitungen, Tabellenkalkulation, Bildbearbeitungsprogramme, Editoren und Browser sind nur einige Beispiele die erfolgreich Gebrauch von diesen Bibliotheken machen. Sie
vereinfachen das Erstellen dieser Programme ungemein, da ansonsten viele Komponenten wie Buttons, Auswahllisten und Menüs immer wieder neu
implementiert werden müssten.
Es gibt jedoch Anwendungen die nicht von diesen Bibliotheken profitieren, obwohl dies prinzipiell möglich wäre: Computerspiele. Das liegt vor
allem einmal daran, dass Spiele meist auf einer ganz eigenen Metapher der
Benutzeroberfläche basieren. Aber auch in ihnen gibt es sehr häufig viele
Elemente die sich von Spiel zu Spiel ähneln. Wenn man sich die heute üblichen PC-Spiele anschaut, so fällt einem schnell ins Auge, dass praktisch jedes
Komponenten wie Buttons, Auswahllisten usw. enthält. Aber diese werden
meist extra für das Spiel oder für eine Reihe von Spielen erstellt und greifen
nicht auf Bibliotheken zurück. Es stellt sich die Frage ob es nicht möglich
wäre eine solche Bibliothek zu entwickeln.
1.2
Ziele
Das Ziel dieser Arbeit ist es der Möglichkeit nach der Erstellung eines Oberflächensystem (im folgenden kurz UI-System vom englischen User Interface
System) für 3D-PC-Spiele nachzugehen und in der Folge ein solches prototypisch zu entwickeln. Dieses soll sich für die Entwicklung einer breiten Auswahl
7
KAPITEL 1. EINLEITUNG
8
von PC-Spielen eignen und deren Entwicklungsaufwand verringern.
Dabei soll nicht das komplette Interface der Spiele mit dem System erstellt werden. Das ist schon alleine deswegen nicht möglich, weil sich die
Spiele in ihrem Interface in der Gesamtbetrachtung so radikal unterscheiden, dass eine sinnvolle Abstraktion unter Berücksichtigung aller Aspekte
ausgeschlossen ist. Gerade in den 3D-Anteilen des Interfaces sind die Unterschiede sehr ausgeprägt, während sich die 2D-Anteile meist zumindest in
ihrer Grundfunktion ähneln. Daher sollte das zu erstellende UI-System sich
auf diese 2D-Anteile konzentrieren und diese von den 3D-Anteilen trennen.
Es wird also eine Ergänzung zu bestehenden Gameengines darstellen und mit
diesen zusammenarbeiten.
1.3
Aufbau
Um ein UI-System für Spiele zu entwickeln sollte man zuerst einmal einen
Blick auf die vorhandenen Techniken werfen. Dabei gilt es die Frage zu beantworten was für Features und Komponenten vorhandene Frameworks für das
Erstellen von typischen Büroanwendungen üblicherweise zur Verfügung stellen und welche Techniken verwendet werden um diese Features zu realisieren.
Dies werden wir in Kapitel 2 tun.
Der nächste Schritt wird sein, Spiele verschiedener Genres im Hinblick
auf die verwendeten Komponenten, Techniken und Features zu untersuchen.
Diese können dann mit denen vorhandener UI-Systeme verglichen werden,
und daraus dann die Unterschiede der Anforderungen an das neue System
abgeleitet werden. Die Ergebnisse dieser Untersuchungen werden in Kapitel 3
zusammen mit zwei Beispielhaften Untersuchungen vorgestellt, während sich
die restlichen Einzeluntersuchungen in Anhang A befinden.
In Kapitel 4 wird schließlich ein System aufgebaut, welches die Spieleentwicklung mit einem System für die Erzeugung von Bedienoberflächen
unterstützt. Dazu werden zunächst die Anforderungen an ein solches System zusammengetragen, welche sich aus dem Kapitel 3 herleiten. Aus diesen
Anforderungen wird dann das Design entworfen, das dem System zugrunde
liegen wird. Als letztes wird dann eine exemplarische Implementation des
Systems beschrieben, die sich aus dem Design ergibt.
Um die Möglichkeiten des Systems aufzuzeigen, werden in Kapitel 5 einige Demonstrationsprogramme vorgestellt, die während der Entwicklung des
Systems entstanden sind.
Dann werden wir uns in Kapitel 6 überlegen in welche Richtungen man
weiter denken und wie Verbesserungen aussehen könnten und in Kapitel 7
abschließend eine Rückschau auf die Arbeit halten.
KAPITEL 1. EINLEITUNG
1.4
9
Zur Sprache
Diese Arbeit ist in Deutsch geschrieben. Allerdings werden zur Beschreibung
von Oberflächenkomponenten und einigen anderen Konstrukten der Informatik im folgenden die englischen Begriffe benutzt. So wird zum Beispiel nicht
von „Knöpfen“ sondern von „Buttons“, und nicht von „Nehme und lass fallen“
sondern von „Drag and Drop“ die Rede sein. Dies geschied zur Bequemlichkeit
des Lesers und des Autoren gleichermaßen.
Kapitel 2
Standard User Interfaces
Als ersten Schritt hin zu einem Framework für die Oberflächenentwicklung
von Spielen werden wir uns erst einmal ansehen, was ein bestehendes Framework für die allgemeinen Oberflächen gängiger Programme bietet. Wir
werden untersuchen, welche Techniken und Komponenten ein solches Framework zur Verfügung stellt und anhand dieser Informationen werden wir
dann in Kapitel 3 untersuchen können, welche Unterschiede bestehen zwischen den Anforderungen gängiger Büroprogramme und den Anforderungen
von Spielen.
Da es eine schier unglaubliche Anzahl von Frameworks für die Erstellung
von Benutzeroberflächen gibt, ist es unmöglich sie alle hier zu diskutieren
und zu analysieren. Beispiele dafür sind Qt (C++), Windows.Forms (C#)
und SWT/JFace (Java). Daher werden wir uns hier auf eines beschränken.
Wir sollten ein Framework wählen das ausgereift, weit verbreitet und gut
dokumentiert ist. Es sollte alle gängigen Programmtypen unterstützen damit
wir alle Features vorfinden die man in bekannten Programmen findet, denn
nur dann können wir davon ausgehen, das der daraus hergeleitete Standard
auch alle Kernpunkte umfasst.
Ein weiterer Punkt ist für unsere Betrachtung von besonderer Wichtigkeit: Das System sollte soweit wie möglich vom darunter liegenden Fenstersystem unabhängig sein. Das heißt, dass es seine Komponenten selbst implementieren sollte und nicht auf nativen Widgeds basieren darf. Diese Forderung ist deswegen sehr wichtig, da auch die zu entwickelnde Bibliothek nicht
auf native Widgets wird zugreifen können. Schon allein die 3D-Darstellung
der Spiele und deren Fixierung auf hohe Performance verhindert die Verwendung von vorhandenen Standardkomponenten, die ja üblicherweise in einem
Fenster und nicht im Vollbildmodus platziert werden.
Im folgenden werden wir uns das System Swing[LEW+ 03] der Programmiersprache Java ansehen. Sie erfüllt die oben formulierten Anforderungen
10
KAPITEL 2. STANDARD USER INTERFACES
11
und dürfte damit eine gute Grundlage für unser System abgeben.
2.1
Komponenten
Ein UI-System besteht zunächst einmal aus einer Sammlung von wiederverwendbaren Komponenten die zusammengesetzt das Interface eines Programms bilden. Die Komponenten die Swing bietet sind in Tabelle 2.1 aufgeführt.
Komponente
Labels
Images
Buttons
ToggleButtons
CheckBoxes
RadioButtons
ScrollBars
Slider
ProgressBars
ChooseLists
ComboBoxes
Spinners
Komponente
Pannels
Windows
Dialogs
Registers
ScrollPanes
Menus
Kontextmenus
Toolbars
Tables
Trees
Textfields
StyledText
Tabelle 2.1: Komponenten in Swing
Die meisten dieser Komponenten sollten dem Leser bekannt sein, daher
werden im folgenden nur sehr kurze Einzelbeschreibungen der Komponenten gegeben. Für sehr viel detailliertere Informationen siehe zum Beispiel
[LEW+ 03].
Labels Eine wichtige Grundvoraussetzung der meisten Anwendungen besteht darin statische Texte darstellen zu können. Ein Label tut genau das, es
stellt Text dar. Man kann den Text beliebig formatieren indem man ihn mittels HTML dekoriert. So sind verschiedene Textgrößen, Farben und Formen
möglich. Labels reagieren normalerweise nicht auf Aktionen des Benutzers.
In Swing ist ein Label darüber hinaus auch in der Lage Bilder darzustellen.
Images Neben Texten müssen auch Bilder dargestellt werden. Dabei kann
ein Bild sich aus einzelnen Pixelinformationen zusammensetzen die z.B. aus
12
einer PNG-Datei stammen, oder kann auch dynamisch vom Programm erzeugt werden. Images reagieren normalerweise nicht auf Aktionen des Benutzers und werden in Swing ebenfalls durch Labels realisiert.
Buttons Buttons dienen normalerweise lediglich dazu eine Aktion auszulösen, wenn mit der Maus auf sie geklickt wird. Sie haben verschiedene Zustände, je nachdem ob sich die Maus über ihnen befindet oder vielleicht sogar
gerade eine Maustaste gedrückt wird. Diese Zustände haben unterschiedliche
grafische Repräsentationen.
ToggleButton Im Prinzip ein Button der jedoch gedrückt bleibt, wenn
man auf ihn geklickt hat, und nicht automatisch in seinen Ursprungszustand
zurückkehrt. Erst ein zweiter Klick läßt ihn in seinen Ursprungszustand zurückkehren. Auf diese Weise dient er nicht nur dem Auslösen einer Aktion
sondern kann gleichzeitig auch noch einen binären Zustand anzeigen.
Checkboxes Eine Checkbox ist einem ToggleButton sehr ähnlich und unterscheidet sich von diesem lediglich im Erscheinungsbild. Sie dient meist der
Auswahl, ob eine Option aktiviert werden soll oder nicht, löst aber nur in
seltenen Fällen eine Aktion aus.
RadioButtons Ein RadioButton steht niemals alleine für sich, es arbeiten
immer mehrere zusammen. Im Prinzip sind es mehrere Checkboxes von denen
immer nur genau eine aktiviert ist. Wenn man zwischen wenigen verschiedenen Alternativen zu wählen hat, bieten sich RadioButtons an. Für sehr viele
Auswahlpunkte sind sie nicht ganz so geeignet, da sie dann relativ viel Platz
verbrauchen.
ScrollBars ScrollBars bestehen meist aus zwei Buttons die entweder horizontal oder vertikal angeordnet sind, und einer dritten Komponente die per
DnD zwischen ihnen bewegt werden kann. Der Druck auf einen der Buttons
hat zur Folge, dass die dritte Komponente auf ihn zu bewegt wird. Eine
ScrollBar wird normalerweise dazu benutzt, Teile des User Interfaces sichtbar zu machen die vorher verborgen waren und dafür andere unsichtbar zu
machen.
Man findet diese Komponente selten für sich alleine sondern meist in
Verbindung mit anderen wie ComboBoxes oder ScrollPanes.
Slider Um einen Wert innerhalb bestimmter Grenzen zu setzen wird häufig
ein Slider verwendet. Es ist im wesentlichen eine horizontal oder vertikal
13
zwischen zwei Extrema bewegbare Komponente. Der Benutzer bewegt diese
durch eine Drag and Drop Geste mit der Maus.
ProgressBars Wie weit eine länger dauernde Aktion wie das Laden eines
Bildes fortgeschritten ist, wird oft durch eine ProgressBar dargestellt. Es
zeigt einen Fortschritt als Balken an, welcher je nach Fortschritt größer wird.
Er ändert seinen Zustand programmgesteuert und kann nicht vom Benutzer
editiert werden.
ChooseLists Um eine Auswahl zu treffen bieten sich neben den Radiobuttons auch ChooseLists an. Hier sind, meist textuell, mehrere Wahlmöglichkeiten aufgelistet, von denen eine oder, je nach Einstellung, auch mehrere
Elemente gewählt werden können. Wenn mehr Wahlmöglichkeiten zur Verfügung stehen, als die Komponente auf einmal darstellen kann, wird eine
ScrollBar sichtbar, um zu den verschiedenen Möglichkeiten blättern zu können. Damit verbrauchen sie bei großen Auswahlmöglichkeiten nicht so viel
Platz wie viele Check- oder Radiobuttons.
Eine Liste kann aber auch andere Elemente aufnehmen als Texte. So kann
man zwischen Bildern wählen oder auch zwischen komplexeren Elementen.
Comboboxes Eine Combobox ist eine Kombination aus einem Textfield,
einem Button und einer ChooseList. Die Chooselist ist normalerweise unsichtbar und wird nur eingeblendet wenn in das Textfield geschrieben oder
der Button gedrückt wird. Dann wird sie über andere Elemente geblendet
und verschwindet wieder wenn eine Auswahl getroffen wurde. Auf diese Weise kann man aus vielen Alternativen wählen und braucht nur relativ wenig
Platz auf der Oberfläche für die Komponente. Allerdings ist eine Mehrfachauswahl wie bei einer regulären Chooselist so kaum möglich.
Spinners Die Platzsparenste aller Listenkomponenten ist der Spinner. Er
zeigt immer nur genau eine der möglichen Auswahlen an, und zwar den gewählten Eintrag. Mit zwei Buttons wird der Eintrag gegen den nächsten
bzw. den vorigen ausgetauscht. Auch hier können neben Texten auch andere
Einträge gewählt werden wie z.B. Bilder oder Zahlen.
Pannels Pannels dienen im Grunde nur dazu andere Elemente zu gruppieren. Ein Panel selbst hat normalerweise keine graphische Repräsentation
sondern sorgt nur dafür dass die Unterkomponenten dargestellt werden.
14
Windows Ein Window hat eine Titelleiste mit verschiedenen Buttons.
Man kann es mit der Maus auf dem Bildschirm verschieben indem man die
Titelleiste verschiebt, und mit dem Buttons kann es verkleinert, vergrößert
oder geschlossen werden. Es dient der Zusammenfassung anderer Komponenten und als Rahmen für die meisten Programme. Die Funktionalität wird vom
Betriebssystem zur Verfügung gestellt und dieses ist auch für die Darstellung
verantwortlich, Swing bietet aber auch eine rein javabasierte Lösung für Unterfenster an. Ein Window hat auch noch weitere vordefinierte Andockstellen
für Komponenten wie Menüs oder Toolleisten.
Dialogs Eine besondere Art Window sind die Dialogs. Dies sind meist kleine Fenster innerhalb eines Programms die ein Stück der Oberfläche bündeln
damit der Benutzer eine oder mehrere Auswahlen treffen kann. Ein Beispiel
sind die Datei-Öffnen-Dialoge, die verschiedene Komponenten enthalten um
eine Datei zu finden und dann zu öffnen.
Modale Dialoge sind Dialoge, die alle anderen Komponenten der Anwendung blockieren bis sie geschlossen werden, und die bis zu diesem Zeitpunkt
im Vordergrund stehen. Benutzt wird dies, wenn eine Auswahl des Benutzers
zwingend erforderlich ist, bevor das Programm weiter arbeiten kann.
Swing definiert eine ganze Reihe Dialoge für spezifische Aufgaben wie das
Öffnen oder Schließen einer Datei, die in unserem Zusammenhang aber ohne
große Bedeutung sind.
Registers Um Platz zu sparen und die Oberfläche übersichtlicher zu gestalten werden Registers eingesetzt. Ein Register ist ein Container für andere
Komponenten, wobei von mehreren Registerseiten immer nur eine komplett
dargestellt wird, die anderen sind bis auf einen Button verdeckt. Ein Klick
auf den Button holt dann die entsprechende Seite nach vorne und verdeckt
damit alle anderen. Es handelt sich also um die Umsetzung von Karteireitern
in Software.
Scrollpanes Ist ein Panel oder eine andere Komponente zu groß um komplett dargestellt zu werden, werden oft ScrollBars eingeblendet um den Rest
der Komponente sichtbar machen zu können. Diese Funktionalität wird durch
ein Scrollpane zur Verfügung gestellt, welches eine Komponente aufnimmt
und die Leisten dann einblendet, wenn die Komponente zu groß für eine
komplette Darstellung ist.
Menus Menus können eine komplexe Angelegenheit sein. Bei den meisten
Anwendungen findet man ein Menu am oberen Rand. Es gliedert sich in
15
Hauptpunkte welche, wenn angeklickt, Unterpunkte offenbaren. Diese können wiederum Unterpunkte enthalten und so weiter, bis man schließlich an
der untersten Ebene ankommt, deren Punkte dann wie ein Button Aktionen
auslösen. Die Menupunkte werden üblicherweise durch Texte dargestellt und
können weitere Attribute wie zum Beispiel ein Icon (kleines Bild) oder einen
Hinweis auf den Hotkey für die Aktion beinhalten. Auch gibt es rare Fälle
in denen ein Menupunkt nicht nur wie ein Button funktioniert, sondern wie
eine Checkbox.
Kontextmenus Es gibt Menus in verschiedenen Spielarten. Was man sehr
häufig findet ist das so genannte Kontextmenu. Es unterscheidet sich von
anderen Menus dadurch, das es standardmäßig unsichtbar ist. Erst ein (gewöhnlicherweise) Rechtsklick auf eine Komponente bringt ein Kontextmenü
zum Vorschein. Dieses enthält dann Einträge, welche mit der angeklickten
Komponente assoziiert sind.
Toolbars Toolbars sind Container für andere Komponenten, meist für Buttons, man findet aber auch andere kleine Komponenten wie zum Beispiel
Comboboxes in ihnen. Die Toolbars ermöglichen einen schnellen Zugang zu
häufig gebrauchten Befehlen, so dass man sich nicht jedes mal durch die
komplexen Menus arbeiten muss. Heutzutage sind die Toolbars meist konfigurierbar, so dass der Benutzer sie nach Belieben gestalten kann. Auch kann
man sie meist verschieben, so dass sie da liegen wo der Benutzer es am nützlichsten findet.
Tables Tabellen können extrem komplexe und mächtige Komponenten sein.
Sie bestehen grundsätzlich aus einzelnen Spalten. Dabei kann jede einzelne
Spalte ihren eigenen Datentyp enthalten. Es kann also Spalten geben, die
Strings enthalten und solche die mit Bildern arbeiten. Des weiteren hat jede Spalte Informationen über ihre Breite, ihre Überschrift und einiges mehr.
Vor allem kann auch jede Spalte definieren, wie ihre Inhalte gerendert werden
sollen und wie sie zu editieren sind.
Zu einer bestehenden Tabelle können nun Zeilen hinzugefügt werden. Dabei hat jede Zeile genau die Felder die von den einzelnen Spalten definiert
werden. Jede Zelle benutzt die in den Spalten definierten Renderer und Editoren.
Trees Um hierarchische Daten wie zum Beispiel das Dateisystem mit seinen
Ordnern und Dateien anzuzeigen eignen sich Trees. Häufig lassen sich die
16
Einträge ein- und ausklappen um die untergeordneten Elemente zu verbergen
oder anzuzeigen.
Neben der Anzeige von kurzen Texten werden oft auch kleine Symbole
oder sogar noch weitere Komponenten angezeigt. Dafür kann jeder Knotentyp
seinen eigenen Renderer und Editor definieren.
Textfields Eingabefelder stellen Texte dar, allerdings dynamische. Wenn
ein Eingabefeld den Fokus hat, empfängt es Tasterturnachrichten und stellt
einen Cursor dar. Der User kann hier nun ein- oder auch mehrzeiligen Text
eingeben. Es gibt es einfache Eingabefelder und solche die mehrzeiligen formatierten Text darstellen. Bei mehrzeiligen Eingabefeldern erscheint eine
Scrollleiste wenn so viel Text eingegeben wurde, dass nicht alles auf einmal
sichtbar sein kann.
Einige Eingabefelder nehmen auch nur bestimmte Zeichen an (z.B. nur
Zahlen) oder stellen sie anders dar (z.B. als Sterne in einem Passwortfeld).
Styled Text In Swing gibt es auch sehr mächtige Textkomponenten welche
formatierten Text darstellen und auch in der Lage sind Bilder und andere
Komponenten in den Text einzubetten. Damit lassen sich Renderer für Webbrowser genauso herstellen wie etwa ein Textverarbeitungsprogramm. Diese
Flexibilität geht natürlich auch mit einer großen Komplexitität einher.
2.2
Features
Neben den Komponenten aus denen sich ein UI-System zusammen setzt hat
es auch allgemeine Merkmale, die sich vertikal durch alle Komponenten ziehen und damit wesentlich sein grundsätzliches Aussehen und Verhalten bestimmen. Wichtige solche allgemeine Merkmale von Swing werden in Tabelle
2.2 aufgeführt.
Da auch diese Features zum größten Teil bekannt sein sollten, werden sie
nur kurz eingeführt. Für mehr Informationen sei wiederum auf die Literatur
verwiesen.
Tooltips Wenn man in bekannten Programmen mit der Maus einige Zeit
über einer Komponente einige Zeit bewegungslos verharrt, dann erscheint oft
ein kleiner Text, der die Funktion der Komponente beschreibt. Diese kleinen
Hilfstexte nennt man Tooltips.
17
Feature
Tooltips
Hotkeys
Focus
Drag and Drop
Cut and Paste
Undo/Redo
Layout Manager
Look and Feel
Tabelle 2.2: Features in Swing
Hotkeys Verschiedene Komponenten können Ereignisse auslösen wenn man
zum Beispiel mit der Maus auf sie klickt. Aber wenn man alle Aktionen mit
der Maus kontrollieren will, verliert man oft viel Zeit. Um die Arbeit zu beschleunigen definiert man Hotkeys, also Tasten auf der Tastertur, die dann
die selbe Aktion auslösen, als wenn man die Maus benutzt hätte.
Focus Wenn auf der Oberfläche mehrere Buttons vorhanden sind, welcher
wird durch einen Druck auf Return betätigt? Bei mehreren Texteingabefeldern, in welches wird momentan getippt? Kurz, welche Komponente empfängt zu einem gegebenen Zeitpunkt Tastertureingaben? Dies regelt gewöhnlicherweise ein Focussystem, wobei immer nur eine Komponente den Focus
hat und Tastertureingaben empfängt. Dabei ist natürlich zu beachten, dass
einige besondere Eingaben, insbesondere Hotkeys, auch dann eine Aktion
auslösen müssen, wenn die entsprechende Komponente den Focus nicht hat.
Drag and Drop Wenn man mit der Maus ein Icon vom Dateiexplorer
in den Mülleimer verschiebt und daraufhin die zugehörige Datei gelöscht
wird, wenn man einen Text auswählt und ihn an eine andere Stelle im Dokument verschiebt, wenn man ein Bild vom Bildbearbeitungsprogramm in
ein Textdokument verschiebt, dann ist dort die Drag and Drop (DnD) des
unterliegenden Systems am Werk. Generell kann man hiermit innerhalb eines
Programms oder auch zwischen verschiedenen Applikationen Daten mit der
Maus hin und her verschieben.
Cut and Paste Die Möglichkeit einen Text mit der Maus oder der Tastertur zu markieren, dann auszuschneiden und an anderer Stelle wieder einzufügen wird als Cut and Paste bezeichnet. Häufig ist diese Funktionalität auch
18
programmübergreifend zu nutzen, so dass man im einen auschneidet und im
anderen einfügt. Auch andere Ressourcen wie zum Beispiel Bilder lassen sich
so in manchen Programmen transferieren.
Undo/Redo Nicht jede Änderung die man bei seiner Arbeit an einem
Dokument macht entspricht den Erwartungen. Deswegen erwartet man eine Funktionalität um Änderungen rückgängig zu machen und gegebenenfalls
sogar das Rückgängigmachen zu widerrufen. Diese Funktionalität wird Undo/Redo genannt.
Layout Manager Komponenten in einer Anwendung sind auf bestimmte
Weise angeordnet. Es gibt verschiedene Methoden um diese Anordnung festzulegen. Die einfachste ist, jeder Komponente eine Position innerhalb ihrer
Zeichenfläche zuzuordnen und sie dort zu zeichnen. Ein Nachteil der damit
verbunden ist, ist, dass wenn die Fläche zum Beispiel verkleinert wird, das
Element unter Umständen teilweise oder ganz ausserhalb der Fläche liegt
und damit quasi verschwindet. Um das zu verhindern gibt es in modernen
UI-Systemen Layout Manager. Statt einer Komponente eine feste Position
zuzuordnen kann jeder Container einen Layout Manager definieren der für die
Anordnung der Komponenten verantwortlich ist. Ein möglicher Layout Manager würde zum Beispiel alle Komponenten einfach hintereinander darstellen, während ein anderer sie vielleicht tabellenartig anordnen würde. Durch
dieses intelligente Anordnungssystem kann die Oberfläche zum Beispiel auf
Größenänderungen flexibel reagieren.
Look and Feel Eine nicht ganz so häufig anzutreffende Eigenschaft bei
UI-Systemen ist ein dynamisches Look and Feel. Dabei ist das System in der
Lage, sein Aussehen dynamisch zu verändern. So kann ein Button unter Windows anders aussehen als unter Mac OS und damit kann sich das Programm
besser in das darunter liegende System integrieren.
2.3
Architektur
Nun wissen wir, welche Komponenten und Features Swing bietet. Als nächstes gilt es, eine ungefähre Vorstellung davon zu bekommen wie diese Fähigkeiten realisiert werden. Dafür werfen wir einen kurzen Blick auf die Architektur von Swing, um daraus für unser zu entwickelndes System zu lernen.
Um die Diskussion kurz zu halten werden wir die Architektur mit Hilfe von
bekannten Design Patterns[GHJV95, Coo98] beschreiben.
19
Komponentenaufbau Swing baut seine Komponenten nach einer ModelView-Controller Architektur[KP88] auf, um seine Komponenten flexibel und
erweiterbar zu gestalten.
Dabei wird ein leicht vereinfachter Aufbau verwendet, das Model-Delegate
Modell [LEW+ 03](S. 13-16), oder auch Model-View Modell, wie wir es im
Folgenden nennen werden. In diesem wird das View und der Controller in
einer Klasse zusammengefasst, so dass eine Klasse weniger implementiert
werden muss. Dies geschieht aus der Erfahrung, dass View und Controller
so eng mit einander verknüpft sind, dass ein Austausch des einen Teils fast
immer auch einen Austausch des anderen erforderlich macht, eine Trennung
also kaum einen Vorteil bringt.
Button
Wird vom Entwickler instantiiert
und enthält den visuellen Zustand
des Buttons (Position, Größe usw.).
referenziert
ButtonModel
Enthält den internen Zustand
des Buttons, also ob sich die
Maus über ihm befindet, er
gedrückt ist und anderes.
ButtonUI
Nutzt die Zustandsinformationen
des Buttons um diesen darzustellen.
Kann ausgetauscht werden um das
Erscheinungsbild des Buttons zu ändern.
Abbildung 2.1: Aufbau der Komponenten in Swing am Beispiel eines Buttons
Konkret benötig werden für eine Komponente meist drei Klassen. Die erste Klasse ist die eigentliche Komponente. Diese wird später vom Anwendungsentwickler instantiiert. Sie enthält den Zustand der das visuelle Erscheinungsbild der Komponente beschreibt. In dieser Komponentenklasse wird immer
ein UI-Delegate referenziert welches für die Darstellung und die Interaktion
mit dem Benutzer zuständig ist. Es ist normalerweise zustandslos und nutzt
die Informationen aus der Komponentenklasse in einer eigenen Darstellungsroutine. Auf diese Weise kann das Delegate ausgetauscht werden und das
neue Delegate benutzt die Informationen des alten. Durch einen Austausch
dieser Klasse durch eine Kompatible läßt sich das Aussehen der Komponente
radikal verändern. Die dritte Klasse wird ebenfalls von der Komponentenklasse referenziert, es ist das Modell. Dieses enthält den internen Zustand
der Komponente der von der Darstellung unabhängig ist. Auch das Modell
läßt sich austauschen. Es können sogar zwei Komponenten dasselbe Modell
20
benutzen, wodurch zwei Ansichen ein und derselben Daten erzeugt werden.
Eine Änderung an den Daten wirkt sich dann direkt auf beide Komponenten
aus.
Nicht jede Komponente besitzt ein Modell und es gibt auch keine ModellSuperklasse, die Modelle sind zu speziell, als das es irgendwelche Gemeinsamkeiten gäbe. Daher besitzt auch die Superklasse der Komponenten keine
Referenz auf ein Modell, sondern dies wird von den konkreten Komponenten
erledigt.
Abbildung 2.1 verdeutlicht diesen Aufbau anhand eines Buttons in Swing.
Kommunikation Bei der Frage, wie verschiedene Komponenten kommunizieren, greift Swing auf das Observer-Pattern zurück. Dabei kann sich eine
Komponente bei einer anderen registrieren lassen. Diese ruft dann bei allen
registrierten Komponenten eine spezielle Methode auf, sobald ein Ereignis
eintritt. Dieser Methode wird noch ein Event-Objekt mitgegeben, das über
die genaue Art des Ereignisses informiert. Wie die so informierten Objekte
dann auf dieses Ereignis reagieren, liegt bei ihnen.
Unterschieden wird hier zwischen Lowlevel-Ereignissen, das sind zum Beispiel Mausklicks und Tasterturanschläge, und Highlevel-Ereignissen wie zum
Beispiel das Drücken eines Buttons. Die Lowlevel-Ereignisse werden vom Betriebssystem generiert und vom System an die betreffenen Komponenten weitergeleitet, während die Highlevel-Ereignisse von den Komponenten generiert
werden.
Auch das Modell einer Komponente wird über den Observer-Mechanismus
mit der Komponente verbunden, indem sich die Komponente bei dem Modell
als Listener registriert. Durch diese lose Kopplung muss das Modell nichts
über die Komponente wissen. Das ist sehr wichtig, denn nur so ist es möglich,
dasselbe Modell für unterschiedliche Komponenten zu verwenden. Durch diese Wiederverwendbarkeit der Modelle wird die Erweiterbarkeit des Systems
erleichtert. Wenn eine neue Komponente erstellt wird, kann der Entwickler
unter Umständen ein bereits vorhandenes Modell verwenden, was den Entwicklungsaufwand deutlich reduziert.
Look and Feel Ein wesentlicher Aspekt in der Architektur von Swing ist
das austauschbare Look and Feel. Das Ziel ist, dass sich das Aussehen und die
Bedienung des Programms an das System anpasst auf dem es läuft. So soll
sich das Aussehen einer Anwendung ändern, je nachdem ob es unter Windows
oder unter MacOS läuft. Da Swing nicht auf native Widgets zurückgreift um
diese Funktionalität zu erreichten muss Swing das Aussehen und Verhalten
21
des darunter liegenden Systems simulieren1 . Der Komponentenaufbau liefert
für diese Simulierung den Grundbaustein, da sich das Delegate einer Komponente je nach System austauschen läßt, womit sich dessen Aussehen und
Verhalten an das darunter liegende System anpassen lassen.
Natürlich muss das Austauschen der Delegates quasi automatisch ablaufen. Der Entwickler darf nicht dazu gezwungen sein, für jede Komponenteninstanz festzulegen welches Delegate es benutzt. Vielmehr ist es sinnvoll an
einer Stelle im Programm festzulegen, welches Design bzw. welches Look and
Feel verwendet werden soll, und alle Komponenten passen sich dann an dieses
an. Im Diagram 2.2 wird dieser (sehr komplexe) Mechanismus am Beispiel
eines Buttons unter Windows vereinfacht dargestellt.
Am Anfang des Programms wird eine LookAndFeel-Klasse instantiiert.
Diese legt eine UIDefaults-Instanz (im Diagram: def:UIDefaults) an. Im Diagram ist nun zu sehen:
1. Ein Button button1 wird instantiiert.
2. Der Button fragt den UIManager nach einem Delegate.
3. Der UIManager leitet die Anfrage an die UIDefaults weiter.
4. Die UIDefaults fragen den Button nach seiner UIClassID. Das ist eine
ID, die eindeutig festlegt welche Art von Delegate zu der Klasse gehört. Im Beispiel antwortet der Button, dass er ein ButtonUI-Delegate
benötigt.
5. Die UIDefaults bestimmen, welche Klasse zu der entsprechenden ID gehört und erzeugen per Reflexion eine entsprechende Delegate-Instanz
button1ui. Diese ist platformspezifisch, da die Defaults ja vor der Instantiierung von dem gewählten Look and Feel festgelegt wurden.
6. Das Delegate button1ui wird an den ursprünglichen Button button1
zurück gesendet. Dieser installiert ihn bei sich, behält also eine Referenz
um später Anfragen an das Delegate weitersenden zu können.
7. Als letztes meldet sich der Button button1 noch beim Delegate button1ui an, damit dieses Ereignislistener registrieren kann und so auf
Zustandsveränderungen des Buttons reagieren kann.
1
Auf die Vor- und Nachteile diesen Systems soll hier nicht eingegangen werden. Im
Internet wurden und werden über dieses Thema ähnlich hitzige Diskussionen geführt wie
über die Vorteile von Windows gegenüber Linux und umgekehrt.
22
UIManager
button1:Button
def:UIDefaults
WinButtonUI
button1ui:WinButtonUI
<<create>>
getUI(button1)
getUI(button1)
getUIClassID()
ButtonUI:UIClassID
createUI(button1)
<<create>>
button1ui
installUI(button1)
Abbildung 2.2: Beispiel einer Delegate-Installation in Swing
Auf diese Weise muss ein Programmentwickler lediglich am Anfang des
Programmlaufs festlegen, welche Delegateklassen zu welchen IDs gehören,
und kann dann seine Komponenten unabhängig von den verwendeten Delegates instantiieren2 .
Der komplette Austausch der Views aller Komponenten ist zwar der
mächtigste, gleichzeitig aber auch der komplizierteste Mechanismus, den es
in Swing gibt um das Look and Feel der Oberfläche anzupassen. Darüber
hinaus gibt es noch eine weitere Möglichkeit die weniger Arbeit auf Seiten
des Anwendungsentwicklers erfordert.
In den UIDefaults sind nicht nur die Views für die einzelnen Komponenten festgelegt, sondern auch Parameter, die diese nutzen. So legt man in
den UIDefaults fest, welche Schrifttypen die Buttons verwenden, in welchen
Farben die Ränder dargestellt werden und viele andere Eigenschaften der
Komponenten. So kann man in begrenztem Umfang auch ohne die komplette
Neuerstellung der Views die Oberfläche seines Programms anpassen. Dabei
bewegt man sich aber natürlich immer in den Grenzen der vom Komponentenentwickler vorhergesehenen Anpassungsmöglichkeiten.
Grafikausgaben Ein weiterer sehr wichtiger Teil eines UI-Systems besteht
in der Art und Weise in der die Komponenten auf dem Bildschirm dargestellt
2
Der ganze Vorgang ist noch etwas komplizierter als die obere Darstellung dies vermittelt. Das liegt vor allem daran, dass das System sogar erlaubt das Look and Feel während
des Programmlaufs zu verändern. Sogar nachdem alle Komponenten instantiiert wurden
und auf dem Bildschirm sichtbar sind, kann das Look and Feel verändert werden, und alle
Komponenten passen sich an. Da dies aber, wie wir später sehen werden, für uns nicht
besonders wichtig ist, genügt hier diese vereinfachte Darstellung.
23
werden. Das ist deswegen von so hoher Bedeutung, weil die Darstellung ein
sehr Zeitintensiver Vorgang ist und daher optimiert werden sollte.
In Swing besitzt jedes Komponenten-Delegate eine Rendermethode, die
paint-Methode. Diese Methoden werden aber nicht einfach jeden Frame rekursiv aufgerufen, der Aufwand wäre bei weitem zu hoch. Um den Aufwand
zu veringern, besitzt jede Komponente auch eine repaint-Methode, die ein
Rechteck als Parameter übernimmt. Wenn diese Methode aufgerufen wird,
wird nur der Teil der Komponente neu gezeichnet, der durch das Rechteck
angegeben ist.
Um zu bestimmen, welche Bildschirmausschnitte neu gezeichnet werden
müssen und welche nicht, gibt es einen globalen Repaint Manager. Wenn
eine Komponente ein Ereignis empfängt und ihr visuelles Erscheinungsbild
sich ändert, bestimmt sie, welche Bildschirmausschnitte neu gezeichnet werden müssen und welche nicht. Ein Beispiel wäre ein Fenster, das verschoben
wird. Neu gezeichnet werden müssen dann der Ausschnitt, auf den das Fenster verschoben wird, und das Rechteck, den es vorher bedeckt hat. Diese
Rechtecke werden dann dem Repaint Manager übergeben. Dieser verrechnet
alle Änderungen, die er innerhalb eines Frames bekommt, und zeichnet dann
eben diese Regionen neu. Anschließen markiert der Manager die Regionen
und Komponenten als gezeichnet, so dass sie nicht wieder gezeichnet werden
müssen, bis sie ihren Zustand erneut ändern.
Um die Arbeit des Managers weiter zu beschleunigen, besitzt jede Komponente ein spezielles Attribut, welches festlegt ob eine Komponente ihre
komplette Fläche neu zeichnet (wie ein rechteckiger Button) oder nur einen
Teil davon (wie ein runder Button, der die Ecken nicht ausmalt). Dieses Attribut kann der Manager benutzen um die Zeichenvorgänge zu optimieren.
Wenn eine Komponente nämlich ihre Zeichenfläche komplett ausfüllt, müssen
Komponenten, die sich hinter ihr befinden nicht gezeichnet werden.
Es sollten noch zwei Dinge angemerkt werden: als erstes verwendet jede
Komponente Double-Buffering um umschönes Flackern zu verhindern. Aber
sehr viel grundlegender ist, dass der ganze Zeichenvorgang asynchron in mehreren Threads abläuft. Der Repaint Manager läuft in einem eigenen Thread
und die Komponenten müssen ihm melden, wenn sie neu gezeichnet werden
müssen. Es ist also nicht garantiert, dass das Neuzeichnen sofort geschieht,
je nach Auslastung des Systems kann dies noch ein wenig dauern.
Kapitel 3
User Interfaces in
Computerspielen
Computerspiele bringen im Allgemeinen sehr individuelle Benutzeroberflächen mit sich. Es gibt kaum zwei Spiele, die mit gleichartigen Buttons ausgestattet sind, kaum zwei Spiele, die ein irgendwie standardmäßiges Aussehen
haben. Jedes versucht, so individuell wie möglich, so interessant wie irgend
möglich zu sein. Unter anderem dadurch wird verhindert, dass die Entwickler
auf herkömmliche UI-Systeme zurückgreifen können, da mit diesen erstellten
Benutzerinterfaces alle denselben Flair haben, sich in der Benutzung ähneln
und den Eindruck machen, als hätten sie alle einen einzigen Ursprung.
In diesem Kapitel werden nun die Ergebnisse eines Vergleiches der Oberflächen einiger sehr verschiedener Spiele mit denen anderer Programme präsentiert. Die Möglichkeiten der Oberflächen anderer Programme wurden dabei in Kapitel 2 bereits dargelegt durch die Analyse, was ein heutiges UISystem bietet. Dieser Vergleich wird dazu beitragen, die Unterschiede und
Gemeinsamkeiten der Programmgattungen herauszuarbeiten. Das wird wiederum die Grundlage bilden um die Anforderungen an das Framework zu
definieren.
Insgesamt wurden fünf verschiedene Spiele untersucht. In diesem Kapitel
finden sich zwei dieser Analysen, die zeigen, auf welche Weise die Untersuchung durchgeführt wurde. Weitere drei finden sich in Anhang A.
Aufgrund des dynamischen Charakters von Spielen können die Ergebnisse wohl nur dann genau nachvollzogen werden, wenn die Spiele vorliegen.
Von einigen Spielen existieren Demoversionen, die kostenlos heruntergeladen
werden können und mit deren Hilfe man einen Eindruck der Spiele gewinnen kann. Aus diesem Grund sind bei den Einzelanalysen auch immer die
Webadressen der Hersteller aufgeführt.
Die beiden Spiele, deren Analysen sich in diesem Kapitel befinden, wer24
KAPITEL 3. USER INTERFACES IN COMPUTERSPIELEN
25
den auch in Kapitel 5 als Grundlage für die Demonstrationsprogramme des
UI-Systems verwendet, so dass sich dort einige Screenshots befinden. Um
einen ungefähren Eindruck auch der anderen Spiele zu geben finden sich
noch einige Screenshots in Anhang B, wobei diese natürlich die dynamischen
Eigenschaften nicht deutlich machen können.
3.1
Spielanalysensystematik
Eine Analyse der Spiele muss hier stichprobenartig ausfallen und kann nicht
umfassend sein, da alleine die verschiedenen Genres eine lange Liste darstellen. Daher werden wir hier nur eine kleine Auswahl von Spielen untersuchen.
Wir werden uns dabei auf Spiele konzentrieren, die besonders intensiv von der
Maussteuerung und der WIMP1 -Metapher Gebrauch machen, da diese Spiele am stärksten von einem Framework, wie es hier geplant wird, profitieren
würden.
Es wird bei der Auswahl der Spiele darauf Wert gelegt, dass erstens keine
zwei Spiele eines Herstellers gezeigt werden, da dieser unter Umständen ein
eigenes UI-Framework nutzen würde und der Informationsgewinn so gering
wäre. Und zweitens wird darauf Wert gelegt, dass die Spiele aus unterschiedlichen Genres stammen, um eine möglichst hohe Abdeckung der Spielevielfalt
zu erreichen.
Die Analyse wurde nach einem standardmäßigen Muster durchgeführt.
Dieses Muster wurde deswegen verwandt, damit die Einzelanalysen besser
verglichen und leichter Schlussfolgerungen aus ihnen gezogen werden können.
Folgende Schritte werden der Reihe nach durchlaufen:
1. Allgemeines Verhalten des Spieles. Wie reagiert es auf die Veränderung
der Bildschirmauflösung? Gibt es einen Fenstermodus? Was ist mit
Animationen, Sounds und 3D-Effekten?
2. Features im Spiel. Welche der Features aus Abschnitt 2.2 finden sich in
dem Spiel wieder? Welche nicht?
3. Komponenten im Spiel. Hier wird geklärt, welche Komponenten aus
Abschnitt 2.1 sich im Spiel finden, die mit solchen aus anderen Anwendungen größtenteils identisch sind. Weiter wird untersucht, welche
besonderen, vom Standard abweichenden, Komponenten es gibt und
wie diese aussehen, wie sie zu bedienen sind und wie sie sich verhalten.
1
W indow I con M enu P ointer
3.2
26
Kartentaktikspiel: Etherlords
Bei dem Spiel Etherlords handelt
Name
Etherlords
es sich um Taktikspiel, welches auf
Genre
Kartentaktikspiel
ein Kartensystem setzt, um Duelle
Entwickler Nival
zwischen zwei Opponenten auszutraPublisher
Fishtank
gen. Gewisse strategische Komponen- Erschienen 2001
ten kommen durch eine Karte, auf
Homepage www.etherlords.com
der gespielt wird, hinzu. Obwohl das
Spielprinzip relativ einfach ist, hat es ein sehr komplexes Interface, besonders in den Optionsmenus, da sich jeder Spieler seinen eigenen Charakter
mit seinen eigenen Karten erstellen kann, um größtmögliche taktische Spieltiefe zu erzeugen. Im Gegensatz dazu ist das eigentliche Duell mit einem sehr
einfachen Interface zu bedienen.
Neben seinem komplexen Interface wurde es auch wegen seines rundenbasierten Aufbaus, die Spieler handeln nacheinander, ausgewählt. Das Interface
ist also, anders als z.B. bei Warcraft 3 (siehe Abschnitt 3.3), nicht darauf angewiesen, unmittelbaren, superschnellen Zugriff auf alle Funktionen zu bieten, sondern kann sich etwas längere Reaktionszeiten leisten. Interessant ist
es auch durch seine komplexen Menubildschirme.
Verhalten
Etherlords kann nur im Vollbildmodus betrieben werden, in zwei verschiedenen Auflösungen. Die Auflösung beeinträchtigt die Darstellung der einzelnen Komponenten überhaupt nicht, es wird entweder einfach ein Rand um
das Spielfeld freigelassen und die Komponenten erscheinen kleiner. Oder es
werden neue Komponenten mit sekundären Funktionen auf dem freien Raum
eingefügt, so dass die Funktionalität in der höheren Auflösung erweitert wird.
Hintergrundmusik und Geräusche bei Nutzeraktionen sind allgegenwärtig, 3D-Szenen hingegen nur im eigentlichen Spiel, nicht in den Optionsbildschirmen. Das eigentliche Interface ist sehr nahe an dem, was man von
typischen anderen Anwendungen gewohnt ist. In ihrem Verhalten unterscheiden sich Buttons, Auswahllisten und die anderen Komponenten nur marginal
von denen aus anderen Anwendungen. Weder Transparenzen noch auffallende
großflächige Animationen sind vorhanden.
Features
Die Tabelle 3.1 führt die in Etherlords vorhandenen Standardfeatures auf.
27
Tooltips lassen sich mit einem Rechtsklick der Maus einblenden und verschwinden wieder, wenn die Taste losgelassen wird. Diese Tips sind nicht
einfacher Text, sondern formatiert und können auch ein Bild enthalten. Hotkeys sind für einige Elemente definiert.
Komponenten
Alle Elemente sind sehr einheitlich gestaltet, allerdings gibt es einige wenige
Buttons, die aus dem Rahmen fallen, besondere Aufmerksamkeit erhielten
und völlig anders gestaltet sind. Auch gibt es viele animierte Elemente.
Die Tabelle 3.2 führt die in Etherlords vorhandenen Standardkomponenten auf.
Die einzige Fensterart sind
modale Dialoge. Diese sind
allerdings sehr schlicht. So kann
der Benutzer sie weder verschieben noch in irgendeiner
Weise vergrößern oder verkleinern. Sie fassen einfach
Elemente zusammen und verhindern das nicht zum Dialog gehörende Elemente benutzt werden, bis der Dialog
geschlossen wurde.
Fast alle Komponenten in
den Optionsbildschirmen werden in diesen Dialogen eingebettet, nur einige Buttons
machen eine Ausnahme. Die Menudialoge werden teilweise auch in anderen
Spielteilen, zum Beispiel zum Laden von Spielständen, verwendet.
Die verwendeten Buttons unterscheiden sich nur insofern von Standardbuttons, als sie Animationen enthalten können, um den Wechsel von einem
Zustand zum anderen anzuzeigen. Das wird aber bei weitem nicht von allen
Buttons verwendet. Im Spiel gibt es mehrere verschiedene Buttons, die sich in
der Art ihrer Darstellung unterschieden. Die Buttons im Hauptmenu werden
ausschließlich mit Hilfe von Bitmaps dargestellt, während die Rollovereffekte
einiger anderer Buttons programmtechnisch erzeugt werden2 .
2
Das kann hier natürlich nicht bewiesen werden sondern beruht auf der Einschätzung
des Autoren.
Komponente
Tooltips
Hotkeys
Focus
Drag and Drop
Cut and Paste
Undo/Redo
Layout Manager
Look and Feel
Vorhanden
Ja
Ja
Nein
Nein
Nein
Nein
Nein
Ja
Bemerkung
durch rechte Maustaste
vereinzelt
eigenes Look and Feel
Tabelle 3.1: Features in Etherlords
Komponente
Labels
Images
Buttons
ToggleButtons
CheckBoxes
RadioButtons
ScrollBars
Slider
ProgressBars
ChooseLists
ComboBoxes
Spinners
Pannels
Windows
Dialogs
Registers
ScrollPanes
Menus
Kontextmenus
Toolbars
Tables
Trees
Text
StyledText
Vorhanden
Ja
Ja
Ja
Nein
Ja
Ja
Ja
Ja
Ja
Ja
Nein
Ja
Ja
Nein
Ja
Ja
Ja
Nein
Nein
Nein
Ja
Nein
Ja
Nein
Bemerkung
sehr vielfältig und spezielle
sehr einfach
kein editieren, vielfältig
Tabelle 3.2: Komponenten in Etherlords
28
29
Besonders interessant sind die vielfältig verwendeten Spinner. Neben
den bekannten gibt es noch eine Reihe erweiterter. Einige werden als Auswahlelement für Texte oder Bilder
verwendet. Andere zeigen sogar mehr
als nur ein einzelnes Element an, sind
also schon fast Auswahllisten. Allerdings besitzen sie keine Scrollleiste sondern werden allein mit den zwei Buttons des Spinners bedient. Außerdem
gibt es Spinner, die nicht nur für die Auswahl eines Elements zuständig sind,
sondern die tatsächlich dynamisch Buttons aufnehmen, die dann wiederum
Aktionen auslösen können. Ein Teil dieser Funktionalität wird auch von Spinnern aus anderen UI-Systemen abgedeckt, aber hier findet sich eindeutig auch
erweiterte Funktionalität.
Die Übersichtskarte ist eine weitere besondere
Komponente, eingeführt im Overviewscreen. Sie dient
vor allem der Navigation. Ein Klick verändert die
Kameraposition im 3D-Raum. Neben der Spielerposition wird auch noch seine Blickrichtung durch
einen Pfeil dargestellt. Die Karte passt sich veränderungen im Spiel an. So werden noch nicht erforschte Bereiche schwarz dargestellt, während die
bekannten in anderen Farben eingezeichnet werden.
3.3
30
Echtzeitstrategie: Warcraft 3
Die primäre Aufgabe des SpieName
Warcraft 3
lers in Warcraft ist der Aufbau
Genre
Echtzeitstrategie
von Gebäuden, die Produktion
Entwickler Blizzard
von Einheiten und das Steuern
Publisher
Blizzard
derselbigen um den oder die GeErschienen 2003
genspieler zu besiegen. Damit wird
Homepage www.blizzard.com/war3/
an das Benutzerinterface besonders die Anforderung gestellt, dass es schnell und unkompliziert zu bedienen
ist. Es kann alleine oder übers Netzwerk mit mehreren Spielern gespielt werden und ist eines der meist verkauften Spiele überhaupt. Es gibt eine Erweiterung zu dem Spiel, Warcraft 3: Frozen Thron, die bei dieser Untersuchung
auch verwendet wird.
Das Spiel wurde ausgewählt, weil es ein komplexes WIMP-Interface besitzt, welches jedoch nicht für sich alleine steht, sondern mit einer 3D-Umgebung
interagiert. Der Benutzer kann dabei sowohl das 2D- als auch das 3D-Interface
direkt mit der Maus und der Tastertur manipulieren und diese beeinflussen
sich gegenseitig. Insofern ist das Spiel ein gutes Beispiel für den benötigten
Grad der Kommunikationsmöglichkeiten des UI-Systems mit den anderen
Teilen des Programms.
Verhalten
Das Spiel kann ausschließlich im Vollbildmodus betrieben werden. Es reagiert auf eine Veränderung der Bildschirmauflösung, indem die Qualität erhöht wird, nicht aber der verfügbare Platz auf dem Bildschirm. Die einzelnen
Objekte verändern also nicht ihre Positionen und Größen sondern werden
einfach mit mehr Pixeln dargestellt. Während des Spieles können die Texturen in ihrer Qualität, also ihrer Auflösung, verändert werden, was auch zu
einer qualitativen Verbesserung bzw. Verschlechterung der Darstellung der
Oberfläche resultiert.
An allen Stellen des Spieles, auch in den Start- und Optionsbildschirmen,
gibt es dreidimensionale Animationen und eine Hintergrundmusik. Auch sind
an vielen Stellen Soundeffekte eingebaut zum Beispiel beim Drücken eines
Buttons.
Ein weiterer besonderer Punkt, der in den Menus sichtbar wird, sind die
verwendeten Transparenzen, kombiniert mit großflächigen Animationen. Hier
werden ganze „Fenster“, die auch noch halb transparent sind, schnell über den
Bildschirm bewegt.
31
Features
Die Tabelle 3.3 führt die in Warcraft 3 vorhandenen Standardfeatures auf.
Über alle Komponenten hinweg findet man die üblichen Tooltips, die hier
allerdings wiederum grafisch gestaltet sind. Hotkeys werden ebenfalls benutzt
und bei Buttons mit einem Text wird der Hotkey auch farblich hervorgehoben. Ein Fokussystem ist in vollem Umfang ebenfalls enthalten. So kann per
Tabulator in weiten Teilen des Programms der Fokus gesetzt und per Return
einzelne Buttons betätigt werden. Drag and Drop findet man nur in sehr primitiver Form in der Toolleiste, in der Items innerhalb der Leiste verschoben
werden oder in das 3D-Interface gezogen werden können.
Komponenten
Viele der Komponenten gibt es in unterschiedlichen grafischen Ausprägungen, So kann ein Button in den Optionsbildschirmen anders aussehen als
ein Button während des Spielgeschehens. Auch reagieren sie im allgemeinen
nicht nur auf die Maus, sondern sind auch mittels Tastertur zu bedienen.
Die Tabelle 3.4 führt die in Warcraft 3 vorhandenen Standardkomponenten auf.
Dialogs sind in Warcraft 3 nur in sehr
einfacher Form zu finden. Weder verfügen
sie über die Fähigkeit ihre Größe zu ändern, noch kann der Benutzer sie verschieben oder schließen. Auch haben sie keine
Menus oder Toolbars. Sie dienen lediglich
dem Zusammenfassen von anderen Komponenten und können sich programmgesteuert bewegen. So kann ein Fenster bei Druck
eines Buttons aus dem Bildschirm herausschnellen und ein neues eingeblendet werden.
Es gibt aber auch noch eine Unterart
von Fenstern, die in etwa den modalen Dialogen aus bekannten Programmen entsprechen. Auch diese können nicht verschoben oder vergrößert werden, allerdings
deaktivieren sie alle anderen Kontrollelemente, solange sie angezeigt werden.
Es gibt einige besondere Buttonarten, die im Interface verwendet werden. Diese zeichnen sich durch
erweiterte Funktionalität aus. Einige von ihnen können mit einen rechten Mausklick ausgewählt werden, so dass ein zusätzlicher
Komponente
Tooltips
Hotkeys
Focus
Drag and Drop
Cut and Paste
Undo/Redo
Layout Manager
Look and Feel
Vorhanden
Ja
Ja
Ja
Ja
Nein
Nein
Nein
Ja
Bemerkung
nur innerhalb des Spieles
Tabelle 3.3: Features in Warcraft 3
Komponente
Labels
Images
Buttons
ToggleButtons
CheckBoxes
RadioButtons
ScrollBars
Slider
ProgressBars
ChooseLists
ComboBoxes
Spinners
Pannels
Windows
Dialogs
Registers
ScrollPanes
Menus
Kontextmenus
Toolbars
Tables
Trees
Text
StyledText
Vorhanden
Ja
Ja
Ja
Nein
Ja
Nein
Ja
Ja
Ja
Ja
Ja
Nein
Ja
Nein
Ja
Ja
Ja
Nein
Nein
Ja
Ja
Nein
Ja
Nein
Bemerkung
viele spezielle Buttons
sehr einfach
kein verschieben
kein editieren
Tabelle 3.4: Komponenten in Warcraft 3
32
33
Rahmen um sie herum angezeigt wird. Sie behalten jedoch nach dieser Auswahl die Funktionalität, gedrückt zu werden, es ist also nicht dasselbe wie ein
Togglebutton. Sie verhalten sich hier eher so wie eine Kombination aus Button und Checkbox, wobei die Checkboxfunktionalität hier mit der rechten
Maustaste bedient wird.
Einige der Buttons haben noch die zusätzliche Funktion eines
Fortschrittsbalkens. Wenn sie gedrückt wurden, sind sie für eine
gewisse Zeit deaktiviert und erst nach Ablauf dieser Zeit wieder
bereit, Aktionen anzunehmen. Diese Zeit wird auch per Animation dargestellt.
Und einige Buttons schließlich verbinden die oberen beiden Fähigkeiten.
Es gibt eine einfache Form der Toolleiste, eine Art Inventar. Sie kann nur eine feste Anzahl Elemente aufnehmen,
diese können aber per Drag and Drop verschoben werden.
Hier findet auch ein simples Drag and Drop mit der 3DSzene statt, da Gegenstände die sich im 3D-Raum befinden
per DnD in das 2D-Inventar aufgenommen werden können.
Die Leiste selbst ist nicht beweglich und dient im Spiel dazu Gegenstände aufzuheben und zu benutzen. Die einzelnen im Inventar abgelegten Gegenstände erscheinen dort
als Buttons und können dann angeklickt werden um Aktionen auszulösen.
Eine sehr eigenwillige Komponente ist die Zeitanzeige am
oberen Bildschirmrand. Diese stellt die aktuelle Tageszeit im
Spiel mit Hilfe einer sehr langsamen Animation dar und reagiert
nicht auf Benutzereingaben.
Eine Übersichtskarte über das Spielgeschehen stellt nicht nur die Sicht des Spielers dar, sondern kann auch noch über daneben liegende Buttons konfiguriert werden.
So können bestimmte Elemente ein- und ausgeblendet oder auch kleine Markierungen vom
Spieler per Mausklick eingefügt werden. Diese Markierungen sind animiert und verschwinden nach einiger Zeit von selbst wieder.
Die Karte dient gleichzeitig als Steuerinstrument. So kann ein Klick auf
die Karte auch dazu führen, dass das Spielgeschehen von einem anderen
Punkt aus, eben dem Angeklickten, weiterverfolgt wird.
34
Eine kleine Komponente im Interface dient dem Darstellen einer 3D-Animation. Je nachdem welche Aktionen
der Benutzer ausführt, wird hier eine andere Animation angezeigt.
Eine sehr primitive Form der Tabellen wird im Resultscreen verwendet um die Ergebnisse eines Spieles anzuzeigen. Sie dienen dabei nur der Anzeige und sind nicht editierbar. Allerdings lassen sich die Zeilen nach den verschiedenen Spalteneinträgen
sortieren.
Eine letzte besondere Komponente ist eine ganz spezielle Auswahlliste. Sie hat eine
maximale Anzahl von Elementen, so dass
niemals Scrollleisten angezeigt werden müssen. Die angezeigten Items lassen sich nach
Gruppen selektieren. Hier ist das Navigieren zwischen den Elementen mit Tabulator
möglich und eine gezielte Mehrfachauswahl
durch Halten der Shifttaste und Anklicken der Items. Auswahlen wirken sich
direkt auf die Markierungen in der 3D-Umgebung und auf das gesamte Userinterface aus.
3.4
Ergebnisse
In diesem Abschnitt werden die Ergebnisse der Einzelanalysen zusammengefasst wiedergegeben. Diese werden nach drei Punkten gegliedert, welche dem
Muster der Untersuchungssystematik entsprechen. Zuerst werden allgemeine
Verhaltensmerkmale von Spielen angesprochen, dann wird diskutiert welche
Features aus bekannten UI-Systemen benötigt werden, und schließlich wird
darauf eingegangen, welche Standardkomponenten und welche besonderen
Komponenten die Spiele bieten und benötigen.
3.4.1
Verhalten
Die untersuchten Spiele laufen alle im Vollbildmodus. Lediglich ein Spiel
bietet die Möglichkeit in einem Fenster zu laufen, das allerdings nur sehr
eingeschränkt. Das Fenster kann weder verschoben, noch in der Größe verändert werden. So stellen die Spiele sicher, dass sie nur in vordefinierten
Bildschirmauflösungen gespielt werden können. Dadurch sind sie in der Lage
ihre Interfaces auf diese Auflösungen abzustimmen und müssen sich nicht mit
35
den Problemen von veränderten Fenstergrößen und Anordnungen auseinander setzen.
Einige Spiele bieten nur eine oder zwei Auflösungen an, in denen sie gespielt werden können, und darauf abgestimmte Anordnungen von Komponenten. Andere bieten viele verschiedene Auflösungen, verändern die Anordnung
der Komponenten aber nicht. Stattdessen werden die Oberflächen einfach mit
mehr Pixeln dargestellt. Anders als es also aus gängigen Programmen bekannt ist, ändert sich mit der Auflösung nicht die Funktionalität der Spiele,
es gibt nicht mehr Platz, sondern es wird lediglich die Darstellungsqualität
erhöht.
Ein weiterer Unterschied zu den gängigen Büroprogrammen findet man
in der Ausgestaltung der Oberflächenelemente. Es gibt zwar in jedem Spiel
Buttons, die ein irgendwie standardmäßiges Aussehen besitzen, aber immer
wieder findet man auch besonders gestaltete. Auch geht diese Gestaltung
über das hinaus, was bei gängigen Programmen üblich ist. So variieren sie in
Form, Farbe und Textur, aber es gibt auch Animationen. Besonders auffällig
sind dabei die großflächigen Animationen in Warcraft 3. Hier werden sehr
schnell sehr große Teile des Bildschirms verändert und gleichzeitig wird von
Transparenzen Gebrauch gemacht, so dass praktisch der granze Bildschirm
jeden Frame neu gezeichnet werden muss.
In allen untersuchten Spielen wird ausgiebig von Musik und Geräuschen
Gebrauch gemacht. Meist läuft im Hintergrund eine Musik und das Bedienen
der Oberflächenelemente gibt sehr häufig auditives Feedback. Das ist zwar
auch in gängigen Anwendungen zu finden, allerdings nicht in solch ausgeprägter Form.
3.4.2
Features
Tabelle 3.5 fasst die Ergebnisse der Einzelanalysen im Hinblick auf die verwendeten Features in Computerspielen zusammen. Es ist deutlich zu erkennen, dass nahezu alle Spiele Tooltips und Hotkeys nutzen.
Spiele sind nicht wie andere Programme dafür gedacht, eine Aufgabe möglichst optimal zu erledigen. Sie sollen stattdessen Spaß machen und mit Fehlern des Anwenders kann gelebt werden kann, ja Fehler sind geradezu ein
Muss für den Spielspaß. Daher ist eine Undo/Redo Funktionalität nicht erforderlich.
Auch Cut and Paste Funktionalität wird nicht benötigt, da der Spieler
nur sehr selten Text eingeben muss und dann nur einzelne Wörter und keine
langen Texte.
Layout Manager haben vor allem einen Sinn. Wenn ein Fenster verkleinert
oder vergrößert wird, dann sollen sich die Komponenten in diesem Fenster
Feature
Tooltips
Hotkeys
Focus
Drag and Drop
Cut and Paste
Undo/Redo
Layout Manager
Look and Feel
Sac. Sie. War.
Ja
Ja
Ja
Ja
Ja
Ja
Nein Nein
Ja
Ja Nein
Ja
Nein Nein Nein
Nein Nein Nein
Nein Nein Nein
Ja
Ja
Ja
Eth. MoO.
Ja
Nein
Ja
Ja
Nein
Ja
Nein Nein
Nein Nein
Nein Nein
Nein Nein
Ja
Ja
36
Ergebnis
4
5
2
2
0
0
0
5
Tabelle 3.5: Zusammenfassung der Features der Spiele
den neuen Gegebenheiten anpassen. Nun gibt es in Spielen keinen Grund, und
daher in den untersuchten Spielen auch keine Möglichkeit, die Fenstergröße
zu verändern. Das Spiel soll eben nicht mit anderen Programmen interagieren
und der Benutzer soll nicht nebenbei noch andere Programme nutzen können,
daher ist es auch nicht nötig, mehrere Fenster nebeneinander zu betrachten,
und daher findet sich die Funktionalität von ausgefeilten Layout Managern
auch nicht in den Spielen.
Jedes Spiel hat sein ganz eigenes Aussehen, sein eigenes Look and Feel,
allerdings ist dieses nicht dynamisch austauschbar. Das Spiel sieht immer
gleich aus, egal unter welcher Plattform. Insofern wird kein dynamisches Look
and Feel im engeren Sinne benötigt, allerdings kann das von einem darunter
liegenden UI-System erwartet werden, damit es die unterschiedlichen Ausgestaltungen der Spiele möglich macht.
Was gelegentlich genutzt wird, ist eine eingeschränkte Drag and Drop
Funktion. Diese kann zwar nicht mit anderen Programmen interagieren, allerdings verbindet sie des öfteren die 2D-Oberfläche mit der 3D-Welt des
Spieles.
Auch ein Focussystem findet man in einigen Spielen. Dieses ist vor allem
in den Optionsbildschirmen von Bedeutung, im eigentlichen Spielgeschehen
findet man es nicht, dort wird fast immer mit Maus und Hotkeys gearbeitet.
3.4.3
Standard Komponenten
Tabelle 3.6 fasst die Ergebnisse der Einzelanalysen im Hinblick auf die verwendeten Komponenten in Computerspielen zusammen. Dabei gibt es einige
Komponenten die wirklich in jedem untersuchten Spiel vorhanden sind. Dazu
gehören, wenig überraschend, zunächst einmal Labels, Images, Buttons und
Pannels.
Komponente
Labels
Images
Buttons
ToggleButtons
CheckBoxes
RadioButtons
ScrollBars
Slider
ProgressBars
ChooseLists
ComboBoxes
Spinners
Pannels
Windows
Dialogs
Registers
ScrollPanes
Menus
Kontextmenus
Toolbars
Tables
Trees
Textfields
StyledText
Sac. Sie. War.
Ja
Ja
Ja
Ja
Ja
Ja
Ja
Ja
Ja
Nein Nein Nein
Ja
Ja
Ja
Ja
Ja
Nein
Ja
Ja
Ja
Ja
Ja
Ja
Ja
Ja
Ja
Ja
Ja
Ja
Ja Nein
Ja
Nein Nein Nein
Ja
Ja
Ja
Nein Nein Nein
Ja
Ja
Ja
Ja
Ja
Ja
Ja
Ja
Ja
Nein Nein Nein
Nein Nein Nein
Ja
Ja
Ja
Ja Nein
Ja
Nein Nein Nein
Ja
Ja
Ja
Nein Nein Nein
Eth. MoO.
Ja
Ja
Ja
Ja
Ja
Ja
Nein Nein
Ja
Ja
Ja
Ja
Ja
Ja
Ja
Ja
Ja
Nein
Ja
Ja
Nein
Ja
Ja
Ja
Ja
Ja
Nein Nein
Ja
Ja
Ja
Ja
Ja
Ja
Nein
Ja
Nein Nein
Nein Nein
Ja
Ja
Nein
Ja
Ja
Ja
Nein
Ja
37
Ergebnis
5
5
5
0
5
4
5
5
4
5
3
2
5
0
5
5
5
1
0
3
4
1
5
1
Tabelle 3.6: Zusammenfassung der Komponenten der Spiele
Gerade in den Optionsbildschirmen findet man auch sehr häufig CheckBoxes, RadioButtons, Slider, Textfields, ChooseLists, ScrollBars, ScrollPanes
und Registers, die mehr oder weniger das bieten, was man von ihnen gewohnt
ist, natürlich immer im individuellen Design des Spieles.
Ebenfalls sehr häufig werden ProgressBars verwendet, diese aber vor allem in Ladebildschirmen, aber auch im eigentlichen Spielgeschehen. Etwas
seltener, aber immer noch oft, findet man ComboBoxes und Spinner in den
Optionsbildschirmen. Auch Tables sind eine häufige Komponente, allerdings
in einfacherer als der bekannten Form. Sie dienen in allen untersuchten Spielen ausschließlich der Darstellung von Informationen, nicht dem Editieren
derselben.
Die Toolbars kommen zwar auch des öfteren vor, meist aber in sehr indivi-
38
dueller Form. So verfügen sie nicht über die Fähigkeit, verschoben zu werden,
sondern sollen meist lediglich dynamisch andere Komponenten in einem festen Raster zusammenfassen und gelegentlich Drag and Drop-Funktionalität
bieten.
Dialogs findet man zwar auch überall, besonders in modaler Form, allerdings sind diese in der Mächtigkeit nicht mit den bekannten Dialogen zu
vergleichen. Sie können nicht mit der Maus verschoben, vergrößert oder verkleinert werden und verfügen nicht über Menus oder Toolbars. Sie dienen
meist einfach nur dazu einige Komponenten zusammenzufassen und auf eine
Eingabe durch den Anwender zu warten.
Nur vereinzelt finden sich Trees und Menus. Gerade letztere werden ja
in fast allen anderen Programmen massiv genutzt. In den hier untersuchten
Spielen sind sie jedoch wenn, dann nur in sehr rudimentärer Form vorhanden.
Die Trees sind, ähnlich den Tables, nicht direkt editierbar, sondern dienen
nur der Darstellung. Und das einzige gefundene Menu bietet lediglich einige
wenige Auswahlpunkte und keine Untermenus, ist dafür aber animiert.
Was sich wirklich nirgendwo findet sind ToggleButtons, Windows, Kontextmenus und StyledTexts. Bei den ToggleButtons kann man davon ausgehen, dass dies einfach daran liegt, dass überall wo sie eingesetzt werden könnten, CheckBoxes dieselbe Funktionalität bieten, aber leichter verständlich
sind. Dahingegen bieten die anderen drei Komponenten einfach Funktionen,
die in den Spielen nicht benötigt werden. Windows braucht man, wenn man
verschiedene Programme dynamisch und in unterschiedlichen Anordnungen
nebeneinander betrachten will. Komplexe Texteditoren braucht man, wenn
man komplexe Daten editieren will, was nicht Aufgabe von Spielen ist. Und
Kontextmenus sind deswegen nicht wichtig, weil bei Spielen der Kontext einer Aufgabe meist sehr klar definiert ist. Wenn man in einem Spiel an einer
bestimmten Stelle ist, ist meist klar definiert welche Aufgabe man zu erfüllen
hat. Auch bieten Kontextmenus meist keinen Zugang zu Optionen der direkt
genug ist. Da lassen sich besser an anderen Stellen im User Interface Buttons
kontextbezogen einblenden, die dann direkt verwendet werden können.
3.4.4
Erweiterte Komponenten
Interessant sind natürlich auch die Komponenten, die die Spiele einführen,
die man in anderen Programmen gewöhnlicherweise nicht findet. So gibt es
nicht nur Buttons, die einfach eine Aktion auslösen, sondern auch solche, die
zusätzlich andere Funktionen erfüllen. So können einige z.B. einen Zeitverlauf
darstellen. Wenn sie gedrückt werden, sind sie einige Zeit inaktiv, bis der
Timer abgelaufen ist. Andere zeigen nebenbei noch dynamische Zahlenwerte
an.
39
Auch Spinner findet man in modifizierten Formen. So haben manche vier
statt zwei Buttons, die dann einer feineren Steuerung der Werte dienen oder
sie stellen keinen aktuellen Wert dar, sondern bieten, ähnlich einer Auswahlliste, mehrere zur Wahl an.
ChooseLists mit modifizierten Eigenschaften finden sich vor allem in den
Interfaces während des Spielgeschehens. Diese Listen können zum Beispiel
Elemente nach Gruppen aufteilen und erlauben dann per Hotkey oder per
Focus eine schnelle Auswahl aller Elemente dieser Gruppe. Auch werden die
Elemente dieser Listen nicht zwangsweise untereinander angeordnet, sondern
auch mal nebeneinander oder in mehreren Reihen.
Gelegentlich gibt es Inventare. Dies sind Komponenten in denen der Spieler andere Komponenten ablegen und per Drag and Drop verschieben oder
anklicken kann. Diese Inventare bestehen meist aus einzelnen Zellen, die entweder in einem festen Raster angeordnet sind oder an fixen Positionen sitzen.
Es sind also im Prinzip hochspezialisierte Toolleisten.
Interessant sind auch die häufig vorkommenden Uhren. Manchmal nur als
schlichte Textanzeige, manchmal aber auch als komplexe Animation, stellen
diese einen Zeitverlauf dar. Dabei kann es sich im wirkliche Uhrzeit, um
Spielzeit, aber auch um einen ganz anderen Zeitablauf handeln. Im Grunde
handelt es sich also um ProgressBars mit einem zyklischen Verlauf und einer
sehr individuellen Anzeige.
Eine wirklich neue Komponente ist die Karte. Eine solche findet sich tatsächlich in allen untersuchten Spielen, wenn diese auch teilweise sehr unterschiedliche Darstellungsarten wählen. Diese Karte gibt einen Überblick über
das Spielgeschehen und dient häufig auch der Navigation, indem ein Klick in
die Karte das Spielgeschehen im 3D-Fenster zu dem zugehörigen Punkt im
Spiel verlagert. Auch kann eine Karte meist mehrere Ebenen darstellen. So
lassen sich Informationen ein- oder ausblenden oder es gibt eine vergrößerte
Darstellung.
Was sich auch des öfteren findet, sind Komponenten die kleine 3D-Animationen
in das 2D-Interface einblenden. Diese reagieren nicht auf die Eingaben des
Benutzers, sondern werden nur vom Spielverlauf beeinflusst, sind also nur
indirekt zu steuern.
Eine Komponente die man gelegentlich findet, ist eine wie auch immer geartete Statistik. Hier wird ein Graph dargestellt, meist ein Zeitverlauf gegen
einen anderen Wert. Diese Graphen sind nicht direkt vom User beeinflussbar, sondern dienen lediglich der Anzeige, meist um einige Eigenschaften des
Spielverlaufs zu verdeutlichen.
Kapitel 4
Game UI-Framework
In den vorhergehenden Kapiteln haben wir uns damit beschäftigt, was UISysteme für die Entwicklung von allgemeinen Anwendungen heutzutage bieten, was Computerspiele von diesen Features nutzen und was sie darüber
hinaus noch benötigen. Darauf aufbauend werden wir uns nun daran machen, ein UI-System für Spiele zu entwickeln.
Das werden wir in drei Schritten tun. Der erste Schritt wird die Definition der Anforderungen an das System sein, die sich aus den vorhergehenden
Kapiteln herleiten. Diese Anforderungen werden wir dann in ein Design umsetzen das dem endgültigen UI-System zugrunde liegen wird. Abschließend
werden wir dann das Design prototypisch implementieren.
4.1
Anforderungen
Die Anforderungen an das UI-System ergeben sich aus den Analysen der
Spiele. Wir werden die Anforderungen nach Wichtigkeit sortieren, um die
Kernanforderungen herauszuarbeiten und solche sekundärer Natur zu kennzeichnen. Das wird dann später unser Leitfaden bei dem Design und der
tatsächlichen Implementierung des Systems sein und uns am Ende bei der
Bewertung des Systems helfen.
4.1.1
Allgemeine Anforderungen
Die vorangegangenen Untersuchungen haben gezeigt, dass nur zwei wirklich
große Unterschiede zwischen UI-Systemen für allgemeine Büroanwendungen
und einem für Spiele bestehen.
Büroanwendungen versuchen sich in der Bedienung zu ähneln und es dem
Nutzer damit so einfach wie möglich zu machen sich in die Arbeit einzufin40
KAPITEL 4. GAME UI-FRAMEWORK
41
den. Spiele versuchen hingegen immer eine individuelle Note in das Interface
einzubringen und sich eben nicht zu ähnlich zu sein. Der größte Unterschied
besteht also darin, dass ein UI-System für Spiele sehr viel mehr Möglichkeiten
bieten muss die Oberfläche zu individualisieren als eines für Büroanwendungen.
Der zweite grundlegende Unterschied besteht darin, dass ein UI-System
für Spiele nicht davon ausgehen kann, dass es die ganze Oberfläche alleine
erzeugen kann. Ein System für Büroanwendungen kann normalerweise alle
grafischen Elemente, die das Programm benötigt, selbst erzeugen. Eines für
Spiele muss sich in ein anderes System integrieren, nämlich in eines, das
für die Darstellung der 3D Elemente und die komplexen Interaktionen der
anderen Spielelemente zuständig ist.
Alle anderen Unterschiede sind vor allem Schwerpunktsetzungen. Komponenten, die für Büroanwendungen besonders wichtig sind, sind für Spiele
weniger elementar und umgekehrt. Genauso sind nicht alle Features für beide
Programmarten gleichermaßen relevant.
Damit sind die folgenden Punkte die wichtigsten Anforderungen, die an
das System gestellt werden. Jeder dieser Punkte sollte größte Aufmerksamkeit im Design und in der Implementierung erhalten.
Konfigurierbarkeit Jedes Spiel bietet sein ganz eigenes Aussehen, seine
eigenen Grafiken, Designelemente und Sounds. Daher sollten alle Elemente des Frameworks nach Belieben anpassbar sein. Das geht über
das Austauschen von Hintergrundgrafiken hinaus. Wo innerhalb eines
Spinners die Buttons sitzen, ob eine Progressbar als Balken oder radial
dargestellt wird, all dies und mehr muss auf möglichst einfache Art und
Weise konfigurierbar sein.
Erweiterbarkeit Nicht nur die vorhandenen Komponenten müssen leicht
konfigurierbar sein, auch neue Komponenten müssen leicht implementierbar sein. Das ist gerade deswegen wichtig, damit jedes Spiel nicht
nur sein eigenes Aussehen, sondern tatsächlich sein ganz eigenes Flair
bekommen kann.
Unabhängigkeit Ein sehr wichtiger Punkt, der sich daraus ergibt, dass
möglichst viele Spiele unterstützt werden sollen, ist die Unabhängigkeit von anderen Systemen. Hier ist zu betonen, dass nicht nur die
Unabhängigkeit vom Betriebssystem gemeint ist. Die Unabhängigkeit
sollte vielmehr im Hinblick auf verschiedene Gameengines bestehen.
Die Entwicklung einer solchen ist mit erheblichem Aufwand verbunden
und ein UI-System wäre von größtem Nutzen, wenn es sich mit möglichst geringem Aufwand in bestehende Systeme integrieren würde. Da
42
die verschiedenen Spiele verschiedene Bibliotheken zum Beispiel zum
Rendern oder für die Verarbeitung von Benutzereingaben verwenden,
sollte das Framework nicht auf spezielle Systeme aufbauen, sondern die
Möglichkeit bieten, mit verschiedenen Systemen zusammenzuarbeiten.
Multimedialität Alle Komponenten sollten mit vielfältigen multimedialen
Eigenschaften ausgestattet werden können. So soll ein Button nicht
nur ein Bild mit einem Text sein, es soll auch möglich sein eine kleine
Animation als Übergang von einem Zustand in den nächsten anzuzeigen
und Sounds sollen eine auditive Rückmeldung geben. Auch kleine 3DAnimationen innerhalb des 2D-Interfaces sollten anzeigbar sein.
Konsistenz Innerhalb eines Spieles sollten die Elemente den Eindruck machen als wären sie aus einem Guss. Daher sollte es einige globale Möglichkeiten geben, die Komponenten zu gestalten, so dass nicht jede
Komponente einzeln angepasst werden muss. Wiederverwendbare Hintergrundgrafiken und die globale Definition von Schrifttypen sind Beispiele für solche globalen Möglichkeiten.
4.1.2
Featureanforderungen
Nicht von ganz so elementarer Bedeutung, aber doch recht wichtig, sind die
Features, die das System bieten sollte. Diese sind in ihrer Funktionsweise
denen aus anderen UI-Systemen größtenteils sehr ähnlich. Andere Features
die in der Tabelle 2.2 aufgeführt wurden, mögen in einzelnen Spielen auch
wichtig sein, sind aber bei weitem nicht so wichtig wie bei Systemen für
Büroanwendungen.
Automatische Komponentengrößen Alle untersuchten Spiele laufen im
Vollbildmodus oder in einem Fenster, dessen Größe nicht verändert
werden kann. Gleichzeitig kann aber die konkrete Auflösung variieren.
Was konstant bleibt, ist also das Verhältnis von Höhe und Breite der
Zeichenfläche und ebenfalls der Komponenten. Daher sollte das Framework den Vollbildmodus unterstützen und die Komponenten sollten
auch bei variierender Auflösung immer an den selben Positionen und
mit der selben Größe dargestellt werden. Lediglich ihre interne Auflösung sollte angepasst werden.
Hotkeys Es sollten Hotkeys definierbar sein, die die selben Aktionen auslösen, wie zum Beispiel das Drücken eines Buttons. Allerdings muss es
auch möglich sein, diese Hotkeys ohne die Existenz einer Komponente
zu definieren, damit es möglich ist, Aktionen allein mit der Tastertur
durchzuführen, also auch ohne Komponente.
43
Tooltips Jede Komponente sollte Tooltips anzeigen können. Dabei muss definierbar sein, unter welchen Umständen die Tooltips angezeigt werden
und unter welchen Umständen sie wieder verschwinden. Auch müssen
die Tooltips beliebig konfigurierbar sein wie alle anderen Komponenten
auch.
Drag and Drop Für beliebige Komponenten sollten Drag and Drop Funktionalitäten definierbar sein. Dabei muss das DnD lediglich programmintern ablaufen und nicht mit anderen Programmen zusammen funktionieren. Allerdings sollte der Datenaustausch zwischen 3D und 2D
Interface möglich sein.
4.1.3
Komponentenanforderungen
Welche Komponenten das System standardmäßig zur Verfügung stellen sollte, führt die Tabelle 4.1 auf. Die Zahl hinter jeder Komponente gibt ihre
Wichtigkeit für das System an, wobei 3 bedeutet, dass die Komponente sehr
wichtig, 2 das sie wichtig und 1 das sie weniger wichtig ist. Die Wichtigkeit
ergibt sich vor allem aus der Häufigkeit der Benutzung in den untersuchten
Spielen, aber auch aus der Ausgiebigkeit in der die Spiele die Komponenten
nutzten. Daher ist ein Button als wirklich sehr wichtig zu betrachten, da er
in jedem Spiel in großer Zahl vorkommt und die Map nicht ganz so wichtig,
obwohl sie in jedem untersuchten Spiel vorkommt.
Komponente
Labels
Images
Buttons
CheckBoxes
RadioButtons
ScrollBars
Slider
ProgressBars
ChooseLists
ComboBoxes
Clock
Map
3
3
3
3
3
3
3
3
3
2
2
2
Komponente
Spinners
Pannels
Dialogs
Registers
ScrollPanes
Menus
Toolbars
Tables
Trees
Textfields
Inventar
Graph
3
3
2
2
2
1
2
1
1
3
1
1
Tabelle 4.1: Wichtige Komponenten für Spiele
Für Dialogs muss es nur eine sehr rudimentäre Unterstützung geben und
44
auch Menus, Tables und Trees müssen nicht so ausgefeilt sein wie in anderen
Bibliotheken.
Einige Komponenten, die man in Officeanwendungen so nicht findet, sind
ebenfalls aufgeführt. Eine Clock ist dabei eine Zeitanzeige, ein Inventar ein
Bereich in dem der Spieler andere spezielle Komponenten ablegen kann, eine
Map eine Karte, die das Spielgeschehen darstellt, und ein Graph eine Komponente, die einen oder mehrere Graphen zeichnet.
4.2
Design
Das Design des UI-Systems sollte alle wesentlichen Anforderungen aus dem
Abschnitt 4.1 berücksichtigen. Wir werden hier alle grundsätzlichen Designentscheidungen darlegen und diskutieren. Dazu werden wir zunächst einmal eine grundlegende Architektur unseres Frameworks entwerfen. Diese wird
dann den Rahmen für alle weiteren Designentscheidungen festlegen, aus denen sich dann die Implementation ergeben wird.
Da nur wenige tiefgreifende Unterschiede zwischen einem UI-System für
Büroanwendungen und einem für Spiele bestehen, werden wir uns bei dem
Aufbau unseren Systems so weit wie möglich an einem vorhandenen System
orientieren und nur dort Änderungen vornehmen, wo dies wirklich notwendig
ist. Das erspart uns nicht nur eine menge Arbeit, sondern hat auch noch den
Vorteil, dass wir nicht alle Standardkomponenten und Features implementieren müssen, um zu zeigen, dass das Konzept funktioniert. Durch die weitestgehende Verwendung einer bestehenden Architektur wird es uns leichtfallen,
glaubhaft zu machen, dass die nicht implementierten Teile ebenfalls in das
Design passen.
Und spätestens an dieser Stelle merken wir, dass Swing als ein Untersuchungsgegenstand eine gute Wahl war. Ein ganz besonderes Feature, dass tief
in Swing verwurzelt ist, können wir für unser System hervorragend gebrauchen: das dynamische Look and Feel. Swing verwendet es, um die Anwendungen besser in die darunter liegenden Plattformen integrieren zu können,
aber wir können es verwenden, um jedem Spiel sein eigenes Aussehen und
Verhalten zu geben. Vor allem wegen dieses Features werden wir uns an der
Architektur von Swing orientieren so weit dies möglich ist.
Abbildung 4.1 gibt eine informelle Übersicht des Aufbau unseren Systems1 . Das Zustandekommen diesen Aufbaus wird in den folgenden Unterabschnitten erklärt.
1
Die farblichen Hervorhebungen finden sich im folgenden in den Diagrammen wieder
um die Zuordung der einzelnen Klassen zu den Systemen zu vereinfachen.
45
UI-System
Spiel
Look and Feel
System
Spiel meldet
Look and Feel an
Look and Feel
des Spieles
referenziert
Dateien und Views
fordert
View an
erzeugt
Sound+Grafikdateien
Views nutzen
Standartkomponenten
Model
Komponenten
Spielspezifische
Komponenten
und eigene Views
M.
Component
View
referenziert
C.
sendet Sound- und
Grafikausgaben
Interfaces werden
einmal pro externem
System implementiert
Interface
sendet Mausund Tasterturereignisse
Soundsystem
V.
instantiiert,
interagieren durch
Event-Listener
Spiellogik
Externes
Soundsystem
sendet Sound- und
Grafikausgaben
Interface
Inputsystem
Graphiksystem
Externes
Rendersystem
sendet Maus- und
Tasterturereignisse
Abbildung 4.1: Die Architektur des UI-Systems
4.2.1
Komponentenaufbau
Aus den Anforderungen geht hervor, dass unser System konfigurierbar und erweiterbar sein soll. Beide Eigenschaften können wir massiv durch eine MVCArchitektur fördern. Und da wir uns an Swing orientieren wollen, werden wir
die etwas vereinfachte Model-View-Architektur wählen, wir verzichten also
auf einen gesonderten Controller. Grundsätzlich benutzen wir also den selben
Komponentenaufbau, der bereits in Abschnitt 2.3 auf Seite 19 beschrieben
wurde.
Die Erweiterbarkeit wird gefördert, da Teile des Programmcodes für neue
Komponenten wiederverwendet werden können. Besonders die innere Pro-
46
grammlogik, die Modelle der Komponenten, können oft unverändert oder
mit kleinen Erweiterungen übernommen werden.
Die Konfigurierbarkeit erhält durch die Austauschbarkeit der Views erste
Unterstützung, da jedes Spiel die Möglichkeit erhält, seine eigenen Viewklassen zu implementieren. Da dies allerdings recht aufwendig ist, reicht der
MVC-Aufbau alleine noch nicht aus, um eine hohe Konfigurierbarkeit zu gewährleisten. Wir werden noch weitere Möglichkeiten benötigen, die weiter
unten beschrieben werden.
4.2.2
Kommunikation
Auch an der Kommunikation brauchen wir nicht viel zu verändern. Die in
Swing verwendete ist für unsere Bedürfnisse ausreichend. Daher werden wir
uns bei der Kommunikation an das in Abschnitt 2.3 Seite 20 beschriebene
Verfahren, welches Events und Listeners nutzt, halten.
4.2.3
Look and Feel
Wir haben Swing ja gerade wegen seinem flexiblen Look and Feel als Grundlage für unser System gewählt, daher werden wir uns auch hier natürlich nah
an der Architektur von Swing halten. Durch die in Abschnitt 2.3 auf Seite 20
beschriebenen Mechanismen wird die Konfigurierbarkeit unseren Systems gewährleistet. Durch die zwei Ebenen der Anpassbarkeit der Oberflächen kann
jeder Entwickler entscheiden, ob er absolute Kontrolle über das Verhalten
der Oberfläche, einhergehend mit etwas mehr Entwicklungsaufwand, oder ob
ihm eine begrenzte Anpassung genügt, zusammen mit etwas weniger Arbeit.
Entweder er entwickelt seine eigenen Views und verbindet sie mit den vorhandenen Komponenten, oder er nutzt die Parameter um die vorhandenen
seinen Befürfnissen anzupassen.
Unser System wird jedoch ein wenig einfacher sein als das von Swing,
denn wir benötigen ein Feature nicht, welches das Look and Feel von Swing
bietet. Es ist nicht notwendig, dass das Look and Feel eines Spieles zur Laufzeit ausgewechselt wird. Eine Implementierung würde unser System lediglich
komplizierter machen2 .
Durch dieses Look and Feel System wird auch die Konsistenzanforderung
an unser System berücksichtigt. Die Änderungen der UIDefaults betreffen ja
2
Auch unter Swing wird dieses Feature normalerweise nur benutzt um zu zeigen wie
„Cool“ Swing ist. Auch eine Büroanwendung profitiert wenig davon wenn man unter Windows die Möglichkeit hat durch das Drücken eines Buttons das Look and Feel an das von
KDE anzupassen.
47
immer alle Komponenten einer Art, so dass zum Beispiel durch eine Änderung an einer Stelle alle Buttons eine neue Farbe erhalten. Natürlich ist man
mit diesem System nicht gegen schlechte Gestaltungen gefeit, aber dem Entwickler wird die Möglichkeit an die Hand gegeben, seinem Spiel auf einfache
Art und Weise ein konsistentes Aussehen zu verleihen.
4.2.4
Ein- und Ausgaben
An dieser Stelle wird unser System die größten Abweichungen von Swing
besitzen. Ein sehr elementarer Unterschied besteht nämlich darin, dass in
einer Standardanwendung selten weitere Grafikausgaben neben denen des
UI-Systems benötigt werden, in den Spielen hingegen ist dies der Regelfall.
Während also ein UI-System für Büroanwendungen davon ausgehen kann,
die volle Kontrolle über die Ausgaben zu haben, muss sich unser System an
seine Umgebung anpassen. Unser System muss sich an die Arbeitsweise der
daruter liegenden Gameengine anpassen, darf diesem keine Vorschriften über
die Arbeitsweise machen, das wird ja unter dem Stichwort Unabhängigkeit
gefordert. Im Besonderen darf das System nicht die Verwendung mehrerer
Threads voraussetzen, da dies in Spielen unüblich ist3 . Hier müssen wir also
anders als Swing vorgehen: alle unsere Arbeit sollte auch ohne Multithreading
genutzt werden können.
Spiele basieren normalerweise auf einer sogenannten Gameloop. Diese
wird einmal pro Frame durchlaufen und alle Grafikausgaben werden in jedem Durchlauf vorgenommen. Um diese Arbeitsweise zu unterstützen sollte
unser System also die Möglichkeit eines Methodenaufrufs bieten, der alle
vom UI-System verwalteten Elemente zeichnet. Diese kann dann einmal pro
Frame aufgerufen werden. Gleichzeitig kann natürlich auch ein System mit
mehreren Threads diesen Aufruf verwenden um die Ausgaben vorzunehmen.
Auf ähnlich Weise sollte mit den Eingaben verfahren werden. Statt einer eigenen Implementierung von Maus- und Tasterturanbindung an das Betriebssystem, sollte das System die von der Gameengine benutzen, um die
Unabhängigkeit des Sysrems zu stärken. Dies kann dadurch erreicht werden,
dass Methoden erstellt werden, mit denen man Maus und Tasterturereignisse
(und eventuell auch die anderer Eigabegeräte) in das System eintragen kann.
Statt also das Betriebssystem nach Ereignissen zu fragen, vertrauen wir darauf, dass das Spiel in seiner Gameloop alle Veränderungen der Mausposition
und alle Tasterterturanschläge unserem System mitteilt.
3
Durch die Einführung von Multikernprozessoren in Desktoprechnern wird sich dies
vermutlich über kurz oder lang ändern, aber momentan ist es noch nicht so weit
48
4.3
Implementation
In den vorangegangenen Kapiteln haben wir die theoretische Basis unseren
Frameworks entworfen; in diesem Kapitel werden wir nun die prototypische
Implementierung beschreiben. Dazu werden wir zunächst einmal in Abschnitt
4.3.1 die Hilfsmittel aufführen, die wir verwendet haben um das Framework
zu implementieren. Danach werden wir in Abschnitt 4.3.2 die einzelnen Klassen und deren Zusammenspiel erklären.
Eine Übersicht über die Zusammenhänge der 24 wichtigsten Klassen4 sind
in Abbildung 4.2 zu finden. Genau wie Abbildung 4.1 dient auch diese als
Übersicht über das Gesamtsystem und wird in den folgenden Abschnitten
weiter aufgeschlüsselt.
referenziert
UISystem
referenziert
java.util.Hashtable
LWJGLUISystem
Renderer
instantiiert
sendet Ausgabebefehle
LWJGLRenderer
Texture
LookAndFeel
nutzt
referenziert
UIDefaults
LWJGLTexture
befüllt
BasicLookAndFeel
sendet Eingabeereignisse
enthält Komponenten
EventHandler
fordert View an
fragt nach eindeutigem Schlüssel für View
<<interface>>
verteilt Ereignisse an Komponenten
Component
referenziert und instantiiert
<<interface>>
referenziert
View
AbstractComponent
AbstractView
AbstractButton
referenziert
ButtonView
CheckboxView
<<interface>>
Button
BasicButtonView
ButtonModel
Checkbox
BasicCheckboxView
instantiiert
ToggleButtonModel
DefaultButtonModel
instantiiert
Abbildung 4.2: Zusammenhänge der wichtigsten Klassen
4
Von insgesammt 72 Klassen. Es fehlen vor allem verschiedene Komponenten und Spezialisierungen von den gezeigten Klassen sowie die Events und Listener-Interfaces.
4.3.1
49
Technologien
Programmiersprache: Java In welcher Programmiersprache wir den Prototyp Implementieren ist nicht von all zu großer Bedeutung. Es sollte eine gebräuchliche Sprache sein, deren einzige Vorraussetzung es ist, das wir schnell
zu sichtbaren Ergebnissen kommen. Jede höhere Programmiersprache sollte
den Zweck erfüllen, sofern Bibliotheken vorhanden sind, die uns die Arbeit
erleichtern.
Traditionell wird in der Spieleentwicklung seid vielen Jahren C++ benutzt. Dies wäre also ein heißer Kandidat. Aber auch andere, neuere, Sprachen haben grundsätzlich das Potential für die Spieleentwicklung. Heiß diskutiert wird ob C# oder Java schnell genug sind. Diese Diskussion möchten wir hier nicht aufnehmen, sondern lediglich anmerken, dass es brauchbare Grafik- und Soundbibliotheken für Java gibt, und es Hinweise darauf
gibt[Sch04, Ste04], dass Java durchaus für die Entwicklung von Spielen verwendet werden kann. Da der Autor darüber hinaus gerne in Java programmiert und der Meinung ist, damit am schnellsten zu den besten Ergebnissen
zu kommen, werden wir uns für diese Sprache entscheiden.
Bibliotheken: LWJGL Nachdem wir uns auf Java als Programmiersprache festgelegt haben, müssen wir entscheiden auf welchen Bibliotheken wir
aufbauen wollen. Da unser System grundsätzlich von Render-, Sound- und
Eingabebibliotheken unabhängig sein soll, diese also austauschbar sein müssen, ist auch hier die Wahl nicht von grundlegender Wichtigkeit. Eine Bibliothek, die uns sowohl Grafik- als auch Sound- und Eingabemöglichkeiten
für Spiele bereitstellt ist LWJGL, die „Lightweight Java Game Library“. Sie
steht unter der GPL-Lizenz und kann somit für unsere Beispielimplementierung frei von uns verwendet werden.
4.3.2
Details
Systemkern
Den Kern des Systems und gleichzeitig die Schnittstelle zu den Spielen bildet
die Klasse UISystem. Es handelt sich um ein Singleton[GHJV95], das seine
Funktionalität dem Spiel über statische Methoden zur Verfügung stellt, dabei
die meisten Aufgaben aber an andere Klassen delegiert. Folgende Funktionalitäten sind für ein Spiel relevant, dass unser System nutzt:
1. Einfügen und Entfernen von Komponenten zur Oberfläche. Dafür besitzt die Klasse UISystem eine Panel -Komponente, die den gesammten Bildschirm ausfüllt. Alle in das System eingefügten Komponenten
50
werden als Kind-Komponenten dieses Panels eingetragen, womit diese
Arbeit effektiv an die Klasse Component delegiert wird.
2. Setzen von Defaultwerten für Komponenten, die bei der Erzeugung
derselben benutzt werden. Dies wird an eine LookAndFeel -Instanz weitergereicht, von der das UISystem immer genau eine referenziert.
3. Aufforderung an das System alle eingetragenen Komponenten darzustellen. Diese Aufforderung wird an einen Renderer weitergereicht. Auch
von diesem besitzt das UISystem genau einen.
4. Eintragen von Eingabeereignissen wie der aktuellen Mausposition oder
dem Anschlag einer Taste. Dieses wird an den EventHandler weitergeleitet. Dieser bestimmt, welche Komponenten betroffen sind und löst
Ereignisse bei betroffenen Komponenten aus.
Abbildung 4.3 zeigt diese Aufgabendelegation auf. Dabei sollte angemerkt
werden, dass das Soundsystem sich nicht in der Implementierung befindet
und hier nur der konzeptionellen Vollständigkeit halber aufgeführt ist (mehr
dazu in Abschnitt 7.1).
UISystem
+<<static>> getInstance(): UISystem
+getRenderer(): Renderer
+getSoundengine(): Soundengine
+render()
+getDefault(name:String): Object
+setDefault(name:String,value:Object)
+removeDefault(name:String)
+addComponent(c:Component)
+removeComponent(c:Component)
+mouseTo(x:int,y:int)
+mousePress(button:int)
+mouseRelease(button:int)
+keyPress(keyName:String)
+keyRelease(keyName:String)
...()
delegiert Look-and-Feel-Operationen
LookAndFeel
+getDefaults(): UIDefaults
delegiert Renderausgaben
Renderer
+render()
delegiert Soundausgaben
Soundengine
+render()
delegiert Komponentenoperationen
delegiert Inputevents
Panel
EventHandler
Abbildung 4.3: Aufgabendelegation der Klasse UISystem
Systemanbindung
Die Klasse UISystem trägt auch wesentlich zu der Unabhängigkeit des Systems von anderen Bibliotheken bei. Es ist lediglich eine abstrakte Klasse
welche erweitert werden muss, um spezielle Systembibliotheken anzubinden.
51
Dazu definiert sie eine Reihe abstrakter Factorymethoden[GHJV95], die
Instanzen von Systemklassen zurückliefern, die die Aufgaben des Frameworks
ausführen können. Konkret gibt es zwei verschiedene Klassen, die erzeugt
werden müssen. Das eine ist der Renderer, der für die Darstellung der Komponenten verantworlich ist, und eine Hilfsklasse Texture, die Bilddaten systemspezifisch kapselt. In unserem prototypischen Framework gibt es nur eine
einzige Erweiterung, das LWJGLUISystem. Dieses enthält Factorymethoden
welche einen LWJGLRenderer und eine LWJGLTexture erzeugen können.
Das UISystem nutzt diese Methoden intern um die entsprechenden Klassen
zu instantiieren wenn dies nötig ist.
Abbildung 4.4 stellt diese Klassen und die hier relevanten Methoden dar.
UISystem
Renderer
+<<static>> getInstance(): UISystem
+createRenderer(): Renderer
+createTexture(): Texture
...()
+render()
+setColor(c:Color)
+setLineWidth(v:float)
+translate(x:float,y:float)
+drawRect(x:float,y:float,w:float,
h:float)
+drawImage(t:Texture,x:float,
y:float,w:float,h:float)
...()
LWJGLUISystem
+<<static>> create(): UISystem
+createRenderer(): Renderer
+createTexture(): Texture
...()
erzeugt, nutzt
Texture
LWJGLRenderer
+getWidth(): int
+getHeight(): int
+createTexture()
nutzt
erzeugt
LWJGLTexture
+bind()
+createTexture()
+render()
+setColor(c:Color)
+setLineWidth(v:float)
+translate(x:float,y:float)
+drawRect(x:float,y:float,w:float,
h:float)
+drawImage(t:Texture,x:float,
y:float,w:float,h:float)
...()
Abbildung 4.4: Unabhängigkeit des UI-Systems von anderen Bibliotheken
Die Eingabe ist auch ohne Klassenerweiterung systemunabhängig. Wie in
Abbildung 4.3 zu sehen ist, stellt die Klasse UISystem Methoden zum Eintragen von Eingabeereignissen zur Verfügung. Das Spiel ist also selbst dafür
verantwortlich die Ereignisse zu melden und kann dafür beliebige Bibliotheken nutzen.
52
Grafikausgabe
Der Renderer unseren Systems ist austauschbar, wie es ja Abbildung 4.4 zeigt.
Daher hat ein Spiel die Möglichkeit einen eigenen Renderer zu implementieren, wenn ihm keiner der vorhandenen zusagt. In unserem Prototyp gibt es
einen Renderer, eben den LWJGLRenderer. Dieser zeichnet alle Komponenten mit Hilfe von OpenGL-Quads. Das hat den Vorteil, dass auch großflächige
Animationen mit Transparenzen sehr schnell dargestellt werden. Nachteilig
wirkt sich aus, dass alle Komponenten jeden Frame komplett neu gezeichnet werden müssen. Aufgrund der Hardwareunterstützung und der geringen
Anzahl notwendiger Quads, ist das aber wohl nur selten nachteilig.
Operationen, die eine sehr große Anzahl von Quads erzeugen würden, vor
allem die Darstellung von Texten, werden in eine Textur vorgerendert, um
dann mit nur einem Quad jeden Frame gerendert zu werden. Das hat natürlich zur Folge, dass das Ändern eines großen Textblocks relativ aufwändig
wird. Das ist aber nicht weiter schlimm, denn das Bearbeiten von Text gehört
nicht zu den Aufgaben, die Spiele besonders oft ausführen müssen, schon gar
nicht mehrfach pro Frame.
Komponentenaufbau
Wir haben uns in Abschnitt 4.2.1 dafür entschieden, den vereinfachten MVCKomponentenaufbau von Swing zu benutzen.
Die theoretische Beschreibung diesen Modells haben wir bereits auf Seite
19 dargelegt und werden nun zeigen, wie das in der Praxis aussieht. Um die
Funktionsweise so klar wie möglich zu machen, werden wir uns im folgenden
an einer Beispielkomponente orientieren und deren Aufbau Schritt für Schritt
erklären. Alle anderen Komponenten sind im Prinzip nach dem selben Schema aufgebaut, so dass das Beispiel als Anleitung für den Bau einer beliebigen
Komponente betrachtet werden kann. Eine Komponente, die gleichzeitig einfach und doch komplex genug ist um die Grundprinzipien zu zeigen, ist der
Button.
Eine Komponente aus unserem Framework besteht üblicherweise aus drei
Klassen, wobei bei besonders einfachen Komponenten auch gelegentlich eine
davon, das Modell, nicht benötigt wird.
Das Modell eines Buttons nennen wir einfach ein ButtonModel. Dabei
definieren wir dieses lediglich als ein Interface, um es auch in anderen Kontexten verwenden zu können. In unserem Framework verwenden zum Beispiel
Checkboxes ebenfalls ein ButtonModel. Um das Standardverhalten eines Buttons zu implementieren, erstellen wir eine Klasse DefaultButtonModel, welche
das ButtonModel mit der Funktionsweise eines Standardbuttons implemen-
53
<<interface>>
Component
Komfort-Methoden wie:
getX(), getWidth() ...
weitere Listener-Methoden
weitere fireEvent-Methoden
+getName(): String
+getViewClassID(): String
+getParent(): Component
+getView(): View
+isVisible(): boolean
+isEnabled(): boolean
+isMouseOver(): boolean
+isMousePressedOver(): boolean
+getBounds(): Rectangle
+getScreenBounds(): Rectangle
+getVisibleBounds(): Rectangle
+...()
+getForeground(): Color
+getBackground(): Color
+getBackgroundImage(): Icon
+getFont(): Font
+getClientProperty(n:String): Object
+setParent(c:Component)
+setVisible(v:boolean)
+setEnabled(v:boolean)
+setLocation(x:int,y:int)
+setSize(w:int,h:int)
+setBounds(x:int,y:int,w:int,h:int)
+setMouseOver(v:boolean)
+setMousePressedOver(v:boolean)
+setForeground(c:Color)
+setBackground(c:Color)
+setBackgroundImage(i:Icon)
+setFont(f:Font)
+putClientProperty(n:String,v:Object)
+updateBounds()
+paint()
+paintComponent()
+addComponent(c:Component)
+removeComponent(c:Component)
+getComponents(): Components[]
+addMouseListener(l:MouseListener)
+removeMouseListener(l:MouseListener)
+addDNDListener(l:DNDListener)
+...()
+fireMouseEntered(e:MouseEvent)
+fireMouseDraged(e:DNDEvent)
+...()
1
<<interface>>
View
+install(c:Component)
+uninstall(c:Component)
+paintComponents(c:Component)
+paintComponent(c:Component)
Abbildung 4.5: Das Interface Component und das View
tiert. Dieses Modell implementiert das Verhalten des Buttons. So wird hier
beispielsweise die Fähigkeit eines Buttons implementiert, seinen Status zu
ändern, wenn sich die Maus über ihm befindet, dass eine Aktion ausgelöst
wird, wenn auf ihn geklickt wird und einiges mehr.
Als zweites benötigen wir eine Komponentenklasse für den Button, die
das Model verwendet. Um auch hier so viel Code für andere buttonartige
Klassen wiederverwenden zu können wie möglich, erstellen wir eine abstrakte Oberklasse für alle Buttons, die von der Klasse AbstractComponent erbt,
welche wiederum das Interface Component implementiert. Wir nennen sie
AbstractButton. Da diese Klasse ein ButtonModel referenziert, können alle
Klassen, die dieses Model nutzen, auch von dieser Komponente erben. Diese
Klasse ist diejenige, die nach außen hin sichtbar ist. Wenn also der Spieleentwickler einen Button benötigt, instantiiert er diese Klasse. Daher bietet sie
54
<<interface>>
<<interface>>
<<interface>>
<<interface>>
ButtonModel
Component
View
MouseListener
+getActionCommand(): String
+isArmed(): boolean
+isPressed(): boolean
+isRollover(): boolean
+isSelected(): boolean
+setActionCommand(c:String)
+setArmed(v:boolean)
+setEnabled(v:boolean)
+setPressed(v:boolean)
+setRollover(v:boolean)
+setSelected(v:boolean)
+addActionListener(l:ActionL.)
+removeActionListener(l:ActionL.)
+addChangeListener(l:ChangeL.)
+removeChangeListener(l:ChangeL.)
+...()
AbstractComponent
+getView(): View
+setView(v:View)
+...()
<<interface>>
+...()
instantiiert
+...()
AbstractView
+...()
ButtonView
referenziert
AbstractButton
DefaultButtonModel
+...()
+getModel(): ButtonModel
+getMouseButton(): int
+setModel(m:ButtonModel)
+setMouseButton(b:int)
BasicButtonView
+install(c:Component)
+uninstall(c:Component)
+paintComponent(c:Component)
#paintEnabled(b:Button)
#paintPressed(b:Button)
#paintDisabled(b:Button)
#paintRollover(b:Button)
#paintContent(b:Button)
#paintRolloverEffect(b:Button)
#paintFocusEffect(b:Button)
Button
+getViewClassID(): String="ButtonView"
+getText(): String
+getImage(): Icon
+setText(t:String)
+setImage(i:Icon)
Abbildung 4.6: Aufbau eines Buttons im UI-System
auch all die Methoden, die man nach außen hin erwarten würde, also solche
zum Ändern der Größe, zum Verschieben und vieles mehr.
Als Letztes benötigen wir noch ein View für unsere Komponente. Es gibt
eine abstrakte Oberklasse für alle Views (AbstractView ), welche das Interface View implementiert. Das View ist für die Darstellung und für die Benutzereingaben verantwortlich. Es enthält also die Methoden zum Rendern
der Komponente, und solche die Ereignisse annehmen. Um auch vom View so
viel Code wie möglich wiederverwendbar zu machen wird es in zwei Schritten
implementiert. Die Klasse, die direkt vom AbstractView erbt, implementiert
die Ereignisverarbeitung, in unserem Fall durch die Implementation eines
MouseListeners. Von dieser Klasse erbt dann unser endgültiges View das
BasicButtonView. Hier werden die Darstellungsroutinen implementiert.
55
In Abbildung 4.5 sind die wichtigsten Methoden von Component und
die von View dargestellt, während Abbildung 4.6 den Aufbau eines Buttons
darstellt.
Der Aufbau zeigt nicht, auf welche Weise die Komponente und das View
verbunden werden, also woher der Button die Information erhält, welches
View instantiiert werden muss. Dies wird unter dem Stichpunkt Look and
Feel weiter unten erklärt.
<<interface>>
Event
ActionListener
+isConsumed(): boolean
+getWhen(): long
+getSource(): Object
+setConsumed(v:boolean)
+setSource(s:Object)
+setWhen(time:long)
+actionPerformed(e:ActionEvent)
<<interface>>
ChangeListener
+stateChanged(e:ChangeEvent)
ActionEvent
<<interface>>
PropertyChangeListener
+propertyChanged(e:PropertyChangeEvent)
ChangeEvent
<<interface>>
KeyboardListener
PropertyChangeEvent
+keyPressed(e:KeyboardEvent)
+keyReleased(e:KeyboardEvent)
+getPropertyName(): String
+getOldValue(): Object
+getNewValue(): Object
+setPropertyName(n:String)
+setOldValue(v:Object)
+setNewValue(v:Object)
<<interface>>
MouseListener
+mousePressed(e:MouseEvent)
+mouseReleased(e:MouseEvent)
+mouseClicked(e:MouseEvent)
+mouseDoubleClicked(e:MouseEvent)
+mouseEntered(e:MouseEvent)
+mouseLeaved(e:MouseEvent)
InputEvent
KeyboardEvent
<<interface>>
MouseMotionListener
+getKey(): String
+setKey(key:String)
+mouseMoved(e:MouseEvent)
MouseEvent
<<interface>>
DNDListener
+getButton(): int
+setButton(b:int)
DNDEvent
+mouseDraged(e:DNDEvent)
+mouseDroped(e:DNDEvent)
+mouseDragMoved(e:DNDEvent)
+getDragTarget(): Object
+setDragTarget(o:Object)
Abbildung 4.7: Events und Listeners des UI-Systems
56
Kommunikation
Da wir uns für eine Event-Listener-Methode zur Kommunikaion entschieden haben, gestaltet sich der Aufbau recht einfach. Es existieren eine Anzahl Events, welche verschiedene Nachrichten repräsentieren. Dies beginnt
bei Lowlevel-Events, wie zum Beispiel einem KeyboardEvent, welches das
Drücken oder Loslassen einer Taste der Tastertur repräsentiert, und geht bis
zu Highlevel-Events, wie der Information, dass ein Button gedrückt wurde.
Passend zu diesen Events exitieren eine Reihe von Listener-Interfaces.
Wenn eine Klasse ein solches Interface implementiert, kann es sich bei einer
beliebigen Komponente registerieren und wird von dieser informiert, wenn ein
entsprechendes Event ausgelöst wurde. Eine Instanz dieses Events wird dann
über eine Methode, die das Interface fordert, an den Empfänger geliefert, der
dann so reagieren kann, wie er es für notwendig befindet.
Abbildung 4.7 führt alle Events und zugehörigen Interfaces auf.
LookAndFeel
Das flexible Look and Feel ist ein zentrales Feature in unserem System. Da
wir uns entschieden haben, uns hier sehr nahe an das System von Swing
zu halten, beschreibt Abbildung 2.2 auf Seite 22 auch die Installation eines
Views in unserem System. Der ganze Abschnitt 2.3 unter der Überschrift Look
and Feel ist also auch auf unser System anzuwenden. Lediglich die Namen
der Methoden sind nicht identisch. In unserem System ist UI durch View
zu erstetzen, so dass zum Beispiel die Methode createUI in unserem System
createView heißt.
Abbildung 4.8 stellt die Zusammenhänge zwischen den Klassen im System
im Hinblick auf die Funktionsweise des Look and Feels dar. Es wird ein
Ausschnitt auf Abbildung 4.2 gezeigt, um die Funktionsweise des Look and
Feels am Beispiel eines Buttons deutlich zu machen.
57
UISystem
referenziert
LWJGLUISystem
java.util.Hashtable
LookAndFeel
referenziert
UIDefaults
fordert View an
befüllt
BasicLookAndFeel
<<interface>>
<<interface>>
View
Component
referenziert
AbstractView
ButtonView
referenziert und instantiiert
AbstractComponent
AbstractButton
<<interface>>
BasicButtonView
Button
fragt nach eindeutigem Schlüssel für View
referenziert
instantiiert
ButtonModel
DefaultButtonModel
Abbildung 4.8: Relevante Klassen im Look and Feel System am Beispiel eines
Buttons
Kapitel 5
Demos
Um die Funktionalität und Leistungsfähigkeit des Frameworks aufzuzeigen,
wurden zwei Demonstrationsprogramme erstellt. Diese bauen dabei jeweils
einen kleinen Ausschnitt des Interfaces eines der analysierten Spiele nach.
Dabei wird nicht versucht, das genaue Aussehen des Spieles zu imitieren,
sondern die Funktionsweise der Oberfläche. Es ist leicht einzusehen, dass
durch die Verwendungen derselben Grafiken dann auch das gleiche Aussehen
simuliert werden könnte. Das ist hier absichtlich Unterblieben, damit die
Screenshots der Spiele und die Screenshots unserer Demos auf einen Blick zu
unterscheiden sind.
Die Demos werden hier in Form von Screenshots in Zusammenhang mit
Codefragmenten präsentiert und dienen so gleichzeitig auch dem Verständnis,
wie mit dem Framework zu arbeiten ist. Beide Demos zusammen demonstrieren, wie mit dem System unterschiedliche Look and Feels erzeugt werden.
5.1
Allgemeines
Beide Demos teilen sich ein paar Codefragmente, die mit der Anbindung des
UI-Systems zu tun haben. Der erste Schritt in der Benutzung des UI-Systems
besteht in der Initialisierung desselben. Beide verwenden das mitgelieferte
LWJGLUISystem. Folgender Code wird verwendet:
LWJGLUISystem.create(width, height, Mouse.getButtonCount(),
WarcraftLookAndFeel.class);
UISystem ui = LWJGLUISystem.getInstance();
Die erste Anweisung dient dazu das System zu initialisieren. Dabei werden
einige Systemparameter übergeben. Dazu gehören die Bildschirbreite und
58
KAPITEL 5. DEMOS
59
Höhe in Pixeln, die Anzahl der Mausbuttons und die Klasse, die das Look and
Feel des Spieles bestimmt. Auf diese Klasse wird weiter unten eingegangen.
Die zweite Anweisung dient dazu, eine Referenz auf das System zu bekommen um dann mit diesem arbeiten zu können. Alle Interaktionen des
Spieles mit dem UI-System laufen über diese Referenz.
In beiden Spielen gibt es eine Gameloop, die, leicht vereinfacht, folgendes
Aussehen besitzt:
boolean exitGame = false;
while(!exitGame) {
processKeyboard();
processMouse();
logic();
render();
}
In der processKeyboard -Methode werden dem UI-System Keyboardnachrichten übermittelt. Dazu wird für jede Taste ein eindeutiger Bezeichner ermittelt und in das System eingetragen. Die einzelnen Methoden der Klasse
Keyboard sind hierbei Bestandteil der Eingabebibliothek, hier von LWJGL.
Keyboard.poll();
while(Keyboard.next()) {
String keyName = Keyboard.getKeyName(Keyboard.getEventKey());
if(Keyboard.getEventKeyState()) ui.keyPress(keyName);
else ui.keyRelease(keyName);
}
Ähnlich wird in der processMouse-Methode die Maus ausgelesen und Veränderungen an das System gemeldet.
ui.mouseTo((int)(Mouse.getX()), (int)(height-Mouse.getY()-1));
Mouse.poll();
while(Mouse.next()) {
if(Mouse.getEventButton() != -1)
if(Mouse.getEventButtonState())
ui.mousePress(Mouse.getEventButton());
else ui.mouseRelease(Mouse.getEventButton());
else ui.mouseWheel(Mouse.getEventDWheel());
}
KAPITEL 5. DEMOS
60
Die erste Zeile überträgt die aktuelle Mausposition an das System. Hier ist
im aktuellen Fall eine Umrechnung nötig, da die Mausposition von der Klasse
Mouse ausgehend von der unteren linken Ecke des Bildschirms gemeldet wird.
Unser System erwartet allerdings, dass die Position von der oberen linken
Ecke gemessen wird.
In der Schleife wird nun jedes andere Mausereignis, sei es ein Tastendruck
oder das Bewegen des Mausrades, an unser System übermittelt.
Die logic-Methode hat nicht direkt mit unserem System zu tun. Hier
verwaltet das Spiel seine Spielelogik. Aber natürlich kann es hier auch Nachrichten an das UI-System schicken und so auf dieses einwirken.
Die letze Methode, render, bringt schließlich das Spiel auf den Bildschirm.
Alle Inhalte werden hier ausgegeben, die Ausgabe des UI-Systems erfordert
lediglich die folgende Zeile.
ui.render();
Natürlich sollte sie dabei nach allen anderen Ausgaben erfolgen, damit
die Oberflächenkomponenten über anderen Spielelementen erscheinen.
Damit ist die Systemanbindung komplett, und das Spiel kann das UISystem für die Erstellung der Oberfläche nutzen. Dazu muss als erstes ein
Kind der LookAndFeel -Klasse erzeugt werden. Diese kann einen beliebigen
Namen tragen. In den Beispielen sind dies WarcraftLookAndFeel und EtherlordsLookAndFeel. In diesen Klassen werden die Eigenschaften der Komponenten gesetzt. Es folgen ein paar Beispiele.
defaults.put("SpinnerView",
BasicSpinnerView.class);
defaults.put("TabbedPaneView", BasicTabbedPaneView.class);
Hier wird bestimmt, welche View-Klassen für die Darstellung des Spinners
und der TabbedPanes verwendet werden. Würde ein Spiel seine eigenen Views
nutzen wollen, könnte es hier die Klassen registrieren. Der erste Wert ist dabei
immer der Schlüssel nach dem die Komponenten fragen, der zweite Wert der
eigentliche Inhalt.
In den meisten Fällen muss man aber nicht soweit gehen, gleich seine
eigene Klasse zu implementieren. In den Beispielen werden die Standardviews
genutzt, eben die BasicXXXView -Views. Diese werden lediglich konfiguriert,
wie die folgenden Beispiele zeigen:
defaults.put("Button.mouseButton",
new Integer(UIConstants.LEFT));
defaults.put("Button.foreground",
new Color(0.4f, 0.2f, 0.2f));
KAPITEL 5. DEMOS
61
defaults.put("Button.font",
new Font("Sans Serif", Font.BOLD, 24));
defaults.put("Button.enabledIcon",
new ImageIcon("menuButtonNormal.png"));
Hier wird dem System mitgeteilt, dass alle Buttons auf die linke Maustaste zu reagieren haben, eine bestimmte Vordergrundfarbe, einen bestimmten
Schrifttyp und ein bestimmtes Bild für den Hintergrund nutzen sollen. Natürlich hat ein Button noch viele andere Eigenschaften, dies ist nur ein kleiner
Ausschnitt der Möglichkeiten.
Um nun Komponenten zu erzeugen, die das definierte Look and Feel nutzen, muss das Spiel alle benötigten Komponenten instantiieren. Die folgenden
Zeilen zeigen beispielhaft die Instantiierung und die Einfügung in das System.
Window w = new Window("MainWindow", 1010, 100, 600, 700);
Button b = new Button("SinglePlayerButton",
50, 50, 500, 100, "Einzelspieler");
w.addComponent(b);
ui.addComponent(w);
Hier wird zuerst ein Fenster erzeigt, ihm ein Name, eine Position und eine Größe zugewiesen. Dann wird ein Button erzeugt, dieser erhält zusätzlich
noch eine Beschriftung (auch ein Icon wäre hier möglich). Als nächstes wird
der Button dem Fenster hinzugefügt und als letzes das Fenster dem UISystem. Der Aufruf der render -Methode zeichnet von jetzt an auch das Fenster
mit dem Button.
5.2
Demo 1 - Warcraft 3
Die erste Demo baut einen Teil des dynamischen Interfaces des Menüs von
Warcraft 3 nach. Hier ist einer der Unterschiede zwischen den Anforderungen
an unser System und Standardanwendungen zu sehen. Alles bewegt sich und
der Hintergrund schimmert effektvoll durch die Komponenten durch.
In der Demo ist der Hintergrund ein Bild, im Originalspiel handelt es sich
um eine 3D-Szene. Das macht für unser System allerdings keinen Unterschied,
man könnte im Hintergrund auch eine solche laufen lassen und unser System
würde genauso arbeiten wie es jetzt der Fall ist.
Die Screenshots in Abbildung 5.2 auf Seite 64 zeigen die Animationsphasen auf. Durch das flüssige Einscrollen auch eines oder mehrerer großen
transparenten Fenster zeigt sich die Hardwareunterstützung die unser Framework bei der Grafikausgabe nutzt. Gerade solche Effekte sind für die Spiele
wichtig, nicht aber für andere Anwendungen.
KAPITEL 5. DEMOS
62
Sozusagen als Bonus ist in der Anwendung auch ein ToggleButton enthalten, den unser Framework ja eigentlich gar nicht bietet. Hier wurde einfach
einem Button das Modell einer Checkbox zugewiesen und so das Verhalten
eines ToggleButtons erzeugt.
5.3
Demo 2 - Etherlords
Die zweite Demo baut einen Teil des sehr statischen Interfaces des Menüs von
Etherlords nach. Hier wird vor allem deutlich, wie durch das Verwenden des
Look and Feels innerhalb einer Anwendung verschiedenartige Darstellungen
ein und derselben Komponente erzeugt werden können.
Es existieren unterschiedliche Ausprägungen von Buttons. Die einen sind
relativ groß und rein durch Bilder animiert, die anderen sind klein und enthalten Elemente, die Programmtechnisch gezeichnet werden. In diesem Fall
wird, wenn die Maus über den Button bewegt wird, ein Rechteck darüber
gezeichnet.
In der Abbildung 5.1 sind die unterschiedlichen Buttons zu sehen. Oben
ist jeweils der normale Zustand dargestellt, unten der wenn sich die Maus
über dem Button befindet.
Abbildung 5.1: Verschiedene Mouseover-Effects der Buttons in Demo2
Das Wechseln des Aussehens wird erreicht, indem, vor dem Aufruf des
Konstruktors einer Komponente, die Look and Feel Defaultwerte neu gesetzt
werden. Im Beispiel werden folgende Werte vom Spiel gesetzt, bevor die kleinen Buttons erzeugt werden.
UISystem.setDefault("Button.foreground",
new Color(0.7f, 0.6f, 0.5f));
UISystem.setDefault("Button.enabledIcon",
new ImageIcon("smallButtonNormal.png"));
UISystem.setDefault("Button.pressedIcon",
new ImageIcon("smallButtonPressed.png"));
UISystem.setDefault("Button.rolloverEffectIcon",
KAPITEL 5. DEMOS
63
new RectangleIcon((Color)
UISystem.getDefault("Button.foreground")));
UISystem.setDefault("Button.offsetX", new Float(0f));
UISystem.setDefault("Button.offsetY", new Float(0f));
UISystem.removeDefault("Button.rolloverIcon");
In den beiden Screenshots aus Abbildung 5.3 auf Seite 65 sind die zwei
unterschiedlichen Darstellungsweisen der Komponenten zu sehen. An Komponenten werden Buttons, ein Slider, einige Checkboxes, sowie eine Registerseite verwendet.
KAPITEL 5. DEMOS
Abbildung 5.2: Demo 1 Screenshots
64
KAPITEL 5. DEMOS
Abbildung 5.3: Demo 2 Screenshots
65
Kapitel 6
Ausblick
Neben den offensichtlichen Erweiterungen, wie die Implementation der fehlenden Features und Komponenten, gibt es auch noch einige Features, von
denen es sich lohnen würde diese in Zukunft zu untersuchen, bzw. sie in das
System zu integrieren.
6.1
Eigene Mauszeiger
Das System bietet in seiner momentanen Fassung lediglich die Möglichkeit
Systemmauszeiger zu verwenden. Natürlich kann das Spiel selbst diese Zeiger
verändern, es wäre aber wünschenswert, wenn auch das UI-System den Zeiger
verändern könnte, beispielsweise wenn sich der Zeiger über einer Komponente
befindet oder eine spezielle Aktion ausgelöst werden kann.
Eine Konfiguration des Mauszeigerverhaltens könnte ebenfalls über das
Look and Feel laufen. Da aber vermutlich eine Kommunikation mit der Gameengine dafür nötig wird, müsste untersucht werden, auf welche Weise die
Systemanbindung modifiziert werden müsste.
6.2
Unabhängigkeit von Programmiersprachen
Das ganze System ist abhängig von der Programmiersprache, in der es entwickelt wurde, und kann nur mit Gameengines zusammenarbeiten die in derselben Sprache geschrieben sind.
Unter Umständen wäre es möglich, diese Abhängigkeit aufzulösen, wenn
man das System in einer komplett interpretierten Sprache entwickeln würde.
Dazu müssten dann Interfaces zu speziellen Sprachen wie Java oder C++
geschrieben werden, die diese dann mit dem System verbinden. Durch die
Unabhängigkeit des Systems von Renderern und Eingabebibliotheken wird
66
KAPITEL 6. AUSBLICK
67
dies relativ einfach gemacht. So müssten nur relativ kleine Teile des Systems
für jede Sprache einzeln implementiert werden.
Natürlich könnte das empfindliche Performanceverluste bedeuten, was gerade für Spiele nicht unbedingt wünschenswert ist. So müsste eine solche Implementierung besonders auf ihre Laufzeiteigenschaften hin untersucht werden.
6.3
Konfiguration mittels Beschreibungssprache
Das Erstellen ansprechender Oberflächen ist auch mit Hilfe eines Systems
wie dem vorliegenden noch eine anspruchsvolle Aufgabe. Solange für die Erstellung der Oberfläche das Schreiben von Programmcode erforderlich ist,
ist es notwendig, die Programmierer in den Designprozess einzubinden. Es
wäre wünschenswert, die Arbeit von Designern und Programmierern an dieser Stelle weiter zu trennen, so dass die Designer weitestgehend alleine die
Oberfläche erstellen können.
Eine Möglichkeit, diese Entkopplung zu verwirklichen, wäre es, die Oberfläche mittels einer Beschreibungssprache zu beschreiben, und diese dann
vom Programm einlesen zu lassen. Diese Beschreibungen könnten dann auf
einfache Art und Weise mit externen Programmen erstellt werden.
So könnte man SVG und andere XML-Dialekte für diese Aufgabe nutzen,
wie es zum Beispiel in [CLS05] beschrieben wird.
Kapitel 7
Fazit
7.1
Erfüllte Anforderungen
Im Kapitel 4.1 wurden die Anforderungen an unser Framework definiert.
Welche von diesen Anforderungen konnten wir mit unserem Konzept verwirklichen? Welche nur bedingt oder gar nicht? Diesen Fragen werden wir
nun nachgegehen.
Allgemeine Anforderungen
Konfigurierbarkeit
Diese Anforderung wurde komplett erfüllt. Alle Strukturen, die nötig sind um
komplett konfigurierbare Oberflächen zu erstellen, sind geschaffen worden.
Da praktisch alle Konfigurationen an einer einzelnen Stelle im Programm
vorgenommen werden, ist es sehr leicht, diese Anpassungen vorzunehmen.
Die Beispielprogramme belegen dies.
Erweiterbarkeit
Auch diese Anforderung wurde erfüllt. Die MVC-Architektur erlaubt das
Wiederverwenden von Code an vielen Stellen im System. Insbesondere kann
die interne Logik der Komponenten auch bei komplett verschiedener Präsentation beibehalten werden. Das erleichtert das Erweitern an vielen Stellen
enorm.
Unabhängigkeit
Dieser Punkt wurde weitgehend erfüllt. Das System kann mit beliebigen Renderern zusammenarbeiten, indem entsprechende Schnittstellen implementiert
68
KAPITEL 7. FAZIT
69
werden, und die Eingaben werden von außen eingetragen, so dass mit wirklich
jeder Eingabebibliothek gearbeitet werden kann.
Etwas umständlich ist dabei das Anbinden der Tastertur. Dadurch, dass
Keyboardtasten durch einen symbolischen Namen repräsentiert werden, der
von außen an das System herangetragen werden muss, kann die Eingabemethode des Spieles relativ umfangreich ausfallen, da alle Eingaben in den
entsprechenden Namen konvertiert werden müssen. Hier wäre eine elegantere
Methode wünschenswert.
Eine Abhängigkeit besteht noch zur verwendeten Programmiersprache.
Unsere Implementation arbeitet ausschließlich mit Gameengines in Java zusammen. Wenn das System beispielsweise in C++ umgesetzt würde, wäre
es auf Gameengines in dieser Sprache festgelegt. Hier eine wirkliche Unabhängigkeit zu erreichen dürfte sich als schwierig erweisen, mehr dazu im Abschnitt 6.
Multimedialität
Die Multimedialität unseren Systems wurde konzeptionell, nicht aber komplett in der prototypischen Implementierung erreicht. Zwar sind Grafikausgaben und Animationen möglich, wie es die Demonstrationsprogramme zeigen,
allerdings wurden keine Soundausgaben implementiert. Es ist aber leicht einzusehen, dass dies kein konzeptionelles Problem darstellt, da die Implementation des Soundsystems analog zu dem Grafiksystem erfolgen kann. Auch
andere Medien wie zum Beispiel Filmsequenzen dürften über ähnliche Implementierungen leicht möglich sein.
Konsistenz
Diese Anforderung wurde komplett erfüllt. Dadurch, dass die Parameter, die
das Aussehen aller Komponenten bestimmen, an einer einzigen Stelle eingestellt werden, wird es dem Entwickler sehr leicht gemacht, ein konsistentes
Look and Feel innerhalb eines Spieles zu erreichen.
Featureanforderungen
Automatische Komponentengrößen
Dieses Feature wurde komplett implementiert. Alle Größen- und Positionsangaben sind unabhängig von der gewählten Auflösung, die Komponenten
skalieren frei mit dieser.
Allerdings fallen vor allem bei niedrigen Auflösungen unangenehme Aliasingartefakte auf, insbesondere bei der Darstellung von Schriften. Um dieses
KAPITEL 7. FAZIT
70
Manko zu beseitigen, wären zwei Strategien möglich. Als erstes könnte die
Option angeboten werden, Größen- und Positionsangaben auch in absoluten Pixelwerten anzugeben. Wenn dies genutzt würde, würde natürlich die
Darstellung der Komponenten von der Auflösung abhängen. Der Entwickler
könnte dann entscheiden, welche Möglichkeit seinen Ansprüchen am ehesten genügt. Die zweite Möglichkeit wäre, den Artefakten entgegenzuarbeiten.
Zum Beispiel könnten die True-Type-Schriften durch Bitmapschriften ersetzt
werden. Da man diese durch abgestufte Alphawerte weniger anfällig gegen
Aliasing machen kann, könnte man das Aliasing zumindest etwas weniger
Augenfällig machen.
Hotkeys
In der Implementierung sind Hotkeys noch nicht möglich. Da aber die Tastertur korrekt angesteuert werden kann und Komponenten Tasterturnachrichten
empfangen, ist es prinzipiell möglich Komponenten mit Hotkeys auszustatten.
Tooltips
Tooltips wurden nicht implementiert. Eine Implementierung kann sich an die
von Swing halten, da sich unser Framework an den hier relevanten Stellen
nicht von Swing unterscheidet.
Drag and Drop
Drag and Drop wurde nicht vollständig implementiert. Die Grundlagen sind
zwar gelegt, es werden die entsprechenden Events generiert und an die Komponenten verteilt, allerdings existiert nur ein experimenteller Manager, der
weit davon entfernt ist komplett zu sein. Bisher ist also jede Komponente
selbst dafür verantwortlich, adäquat auf die entsprechenden Events zu reagieren.
Eine vollständige Implementierung würde sich in vielen Punkten in der
von Swing unterscheiden. Sie wäre allerdings um einiges einfacher, da sie nicht
mit externen Programmen, zum Beispiel über die Systemablage, kommunizieren bräuchte. Allerdings wäre es nötig, Drag and Drop Events auch von
außerhalb des UI-Systems erzeugen zu können, damit eine Kommunikation
mit der 3D Welt des Spieles möglich wäre.
71
KAPITEL 7. FAZIT
Komponentenanforderungen
Tabelle 7.1 führt auf, welche Standardkomponenten in unserem System verwirklicht wurden und welche nicht. Es ist zu sehen, dass knapp die Hälfte
implementiert wurde. Dabei sind die allerwichtigsten implementiert, es fehlen
aber vor allem komplexe Komponenten wir Tables oder Trees.
Komponente
Labels
Images
Buttons
CheckBoxes
RadioButtons
ScrollBars
Slider
ProgressBars
ChooseLists
ComboBoxes
Impem.
Ja
Ja
Ja
Ja
Nein
Nein
Ja
Nein
Nein
Nein
Komponente
Spinners
Pannels
Dialogs
Registers
ScrollPanes
Menus
Toolbars
Tables
Trees
Textfields
Implem.
Ja
Ja
Ja
Ja
Nein
Nein
Nein
Nein
Nein
Nein
Tabelle 7.1: Implementierte Komponenten
Alle Komponenten sind aber zumindest prinzipiell möglich. Das ist leicht
einzusehen, da ja alle in Swing implementiert sind und sich eine Implementation in unserem Framework an diese halten kann.
Erweiterte Komponenten aus Tabelle 4.1 auf Seite 43, wie eine Map wurden nicht implementiert. Es wurde nicht untersucht, welche Probleme es bei
diesen gäbe. Da sie sich aber nicht grundsätzlich von anderen Komponenten
unterscheiden, spricht zumindest nichts Offensichtliches gegen die Möglichkeit einer Implementierung.
7.2
Kritik
Nachdem wir beschrieben haben, welche der Anforderungen unser Framework
erfüllt, gilt es nun zu klären wie weit wir damit unserer Aufgabenstellung
gerecht werden.
In unserer Aufgabenstellung heißt es:
„Ziel dieser Arbeit ist es, verschiedene Computerspiele auf die
Verwendung von Elementen der WIMP-Metapher zu untersuchen
[...]. Dabei müssen im besonderen die Unterschiede zu anderen
Programmgattungen Berücksichtigung finden, nicht notwendige
KAPITEL 7. FAZIT
72
Elemente weggelassen und dafür andere Anforderungen eingearbeitet werden.“
Hierfür haben wir fünf verschiedene Spiele auf ihr Interface hin untersucht. Wir haben untersucht, welche allgemeinen Anforderungen sie haben,
welche Features sie benötigen und welche Komponenten sie brauchen. Dann
haben wir dies mit den Möglichkeiten eines UI-Systems für Büroprogramme
verglichen und die Unterschiede herausgearbeitet. Diesen Punkt haben wir
damit nach eigener Einschätzung erfüllt.
Weiter heißt es:
„[...] aus diesen Untersuchungen [ist] ein Framework abzuleiten,
welches im Speziellen die Erstellung von Computerspielen beschleunigt, indem die 2D-Anteile der Benutzeroberfläche abstrahiert werden.“
Das entwickelte System erfüllt alle Kernanforderungen weitgehend. Es ist
konfigurierbar, erweiterbar, unabhängig und erlaubt die Erstellung konsistenter Benutzeroberflächen. Die Multimedialität ist vor allem mit fehlendem
Sound zwar noch nicht komplett implementiert, stellt aber kein konzeptionelles Problem dar.
In der gegebenen Zeit war es zwar nicht möglich alle Features und Komponenten zu entwickeln, die man von einem kompletten System erwarten
würde, wir konnten aber deutlich machen, dass die Erstellung der übrigen
Features kein fundamentales Problem darstellt.
Die Demonstrationsprogramme zeigen, dass es mit unserem Framework
sehr einfach ist, die 2D-Teile der Interfaces der Spiele zu erstellen, genauso
einfach, wie es ist mit anderen UI-Systemen die Oberflächen von Büroprogrammen zu erstellen. Gleichzeitig ist das System leicht mit beliebigen Renderern und Eingabebibliotheken zu verbinden und ist so unabhängig von der
verwendeten Gameengine. So ist auch dieser Teil der Aufgabenstellung nach
eigener Einschätzung sehr gut erfüllt worden.
Ein letzter Punkt in unserer Aufgabenstellung lautet:
„Erstellung von kleinen Demonstrationsprogrammen auf Grundlage der analysierten Spiele zum Nachweis der Leistungsfähigkeit
des Frameworks.“
Da in unserem Framework noch viele Features und Komponenten fehlen,
konnten die Demonstrationsprogramme leider nicht die ganze Mächtigkeit
des Frameworks zeigen. Gerade die Ingame-Bildschirme erfordern viele sehr
spezielle Komponenten, die in der gegebenen Zeit leider nicht erstellt werden
KAPITEL 7. FAZIT
73
konnten. Die Demos zeigen so lediglich die Möglichkeiten des Systems in den
Menübildschirmen auf, während sich die Möglichkeiten im Spiel selbst nur
erahnen lassen.
7.3
Zusammenfassung
Wir lernen aus dieser Arbeit einige wichtige Punkte. Generell kommen wir
zu dem Schluss, dass es möglich und sinnvoll ist ein UI-System zu entwerfen,
dass die Entwicklung von Spielen unterstützt.
Wir haben gezeigt welche Features und Komponenten aus bekannten Systemen für Spiele von besonderem Interesse sind, und welche nur eine geringe
Priorität in der Entwicklung besitzen. Auch haben wir einige, exklusiv für
Spiele interessante, Komponenten identifiziert.
Weiter haben wir Möglichkeiten untersucht, und Wege gefunden, um das
System so weit wie möglich von der eigentlichen Gameengine unabhängig
zu machen. Nur dadurch kann ein solches System eine ähnliche Bedeutung
in der Spieleentwicklung erlangen, wie es UI-Systeme in der Anwendungsentwicklung bereits besitzen. Ohne diese Unabhängigkeit muss jede Firma
immer wieder ihre eigenen Systeme für die neueste Engine entwickeln.
Und zum Schluss haben wir, durch die Implementation eines Prototypen,
gezeigt, dass die Entwicklung eines solchen Systems auch praktisch durchführbar ist.
Anhang A
Weitere Spielanalysen
Im Rahmen dieser Arbeit wurden fünf Spiele ausführlich analysiert. Zwei
Untersuchungen sind in Kapitel 3.2 und 3.3 zu finden. Die anderen drei Untersuchungen finden sich in diesem Anhang. Eine Zusammenfassung der Ergebnisse findet sich in Abschnitt 3.4 ab Seite 34.
74
ANHANG A. WEITERE SPIELANALYSEN
A.1
75
Actionrollenspiel: Sacred
In Sacred übernimmt der SpieName
Sacred
ler eine Heldenfigur in einer FanGenre
Actionrollenspiel
tasiewelt. Er besiegt Monster, erEntwickler Take Two Interactive
forscht die Spielwelt und sammelt
Publisher
Ascaron
Erfahrung und Gegenstände. Das
Erschienen 2004
Hauptziel ist die Entwicklung des
Homepage www.sacred-game.com
Charakters und die Erforschung der
Welt. Das Spiel kann sowohl einzeln als auch übers Netz mit anderen zusammen gespielt werden.
Durch die Rollenspielaspekte des Spieles hat die Oberfläche ein ziemlich
ausgefuchstes Inventar und einen ausgeprägten Charakterbildschirm, was die
Untersuchung der Oberfläche lohnenswert macht.
Verhalten
Das Spiel hat zwei Modi: entweder als Fenster oder im Vollbildmodus. Allerdings ist das Fenster nicht verschiebbar und auch seine Größe läßt sich
nicht verändern. Dadurch läuft das Spiel effektiv nur in einer Auflösung und
braucht sich nicht über eine Veränderung derselben zu sorgen.
Im Spiel wird an vielen Stellen von Transparenzen, Animationen und
Sounds Gebrauch gemacht. Viele der Komponenten sind halb durchsichtig
und lösen Sounds aus, wenn sie betätigt werden. Im Hintergrund gibt es
immer zumindest ein Bild, aber manchmal auch aufwändige 3D-Animation.
Features
Die Tabelle A.1 führt die in Sacred vorhandenen Standardfeatures auf.
Hotkeys werden weitläufig benutzt und es gibt formatierte Tooltips, die
an manchen Stellen im Spiel erscheinen, sobald die Maus über einer Komponente ist. Es gibt auch Tooltips im 3D-Bildschirm, die durch eine Taste der
Tastertur sichtbar gemacht werden können. Dabei können Tooltips nicht nur
Text, sondern auch kleine Bilder in beliebiger Anzahl enthalten.
Innerhalb des Spieles wird viel mit Drag and Drop gearbeitet. Zwar kann
das Spiel keine Daten mit anderen Programmen austauschen, wohl aber das
2D-Interface mit der 3D-Umgebung. So kann man innerhalb des Inventars
per DnD Gegenstände verschieben, aber auch die Spielfigur dazu veranlassen,
Gegenstände fallen zu lassen, indem man die Icons der Gegenstände in die
Komponente
Tooltips
Hotkeys
Focus
Drag and Drop
Cut and Paste
Undo/Redo
Layout Manager
Look and Feel
Vorhanden
Ja
Ja
Nein
Ja
Nein
Nein
Nein
Ja
76
Bemerkung
verzögerungsfrei
innerhalb des Spieles
Tabelle A.1: Features in Sacred
3D-Umgebung zieht. Mögliche Drop-Ziele für eine DnD-Operation werden
grafisch hervorgehoben.
Komponenten
In Sacred gibt es viele Buttons, die sich aber meist nur durch das Design, aber
nur in seltenen Fällen durch die Funktionalität unterscheiden. Ansonsten gibt
es nur sparsam platzierte Standardkomponenten.
Die Tabelle A.2 führt die in Sacred vorhandenen Standardkomponenten
auf.
Es gibt einfache Panels, die eine Überschrift besitzen. Dabei ist die Schriftart mit
der anderer Labels identisch, es gibt aber
verschiedene Schriftgrößen und Farben. Verschiebbar, oder in der Größe veränderbar, sind sie nicht.
Auch einfache Dialoge gibt es. Diese bieten neben einem Text, einem Bild und ein
oder zwei Buttons nichts. Sie sind aber modal, so dass Aktionen des Benutzers einfache
Dialoge zwischen dem Spieler und anderen
Charakteren zu ermöglichen.
Eine sehr spezielle Komponente findet man während des Spieles am unteren Bildschirmrand. Sie
dient einerseits dazu, die Tageszeit mit Hilfe einer Animation anzuzeigen, hat also die Funktion
eines zyklischen Fortschrittsbalkens bzw. einer Uhr,
gleichzeitig besitzt sie aber noch zwei Zeiger, die die Richtung angeben in die
Komponente
Labels
Images
Buttons
ToggleButtons
CheckBoxes
RadioButtons
ScrollBars
Slider
ProgressBars
ChooseLists
ComboBoxes
Spinners
Pannels
Windows
Dialogs
Registers
ScrollPanes
Menus
Kontextmenus
Toolbars
Tables
Trees
Text
StyledText
Vorhanden
Ja
Ja
Ja
Nein
Ja
Ja
Ja
Ja
Ja
Ja
Ja
Nein
Ja
Nein
Ja
Ja
Ja
Nein
Nein
Ja
Ja
Nein
Ja
Nein
Bemerkung
einfach
horizontal + vertikal
besondere, DnD aktiv
nicht editierbar
Tabelle A.2: Komponenten in Sacred
77
78
der Spieler sich bewegen muss um eine bestimmte Aufgabe zu erfüllen. Dazu
bewegen sich die Zeiger im Kreis, gesteuert von der aktuellen Position des
Spielers, relativ zum Erfüllungsort der Aufgabe.
Interessant ist auch die Toolleiste des Spielers.
Dieser kann per Drag and Drop Buttons in dieser Leiste platzieren. Diese Buttons können dann
durch den Mausklick oder mit einem Hotkey ausgelöst werden. Dabei ist immer ein Button ausgewählt, so dass auch ein Mausklick in die 3D Szene
die Funktion diesen Buttons auslöst. Die Toolleiste
kann sich im Laufe des Spieles vergrößern, so dass
immer mehr Buttons aufgenommen werden können.
Einige der Buttons bringen zusätzlich noch eine Zeitverzögerung mit, so
dass es einige Zeit dauert, bis sie wieder verwendet werden können, wenn sie
ihre Aktion ausgeführt haben. Das wird auch grafisch dargestellt, so dass sie
die Funktionalität eines Buttons mit der einer ProgressBar vereinen.
Der Spieler verfügt über ein Inventar in dem
Gegenstände aufbewahrt werden, die er sammelt.
Diese Gegenstände werden im Inventar als Bilder
repräsentiert und belegen eine oder mehrere Zellen
des Inventars. Sie können per Drag and Drop innerhalb des Inventars verschoben werden und teilweise
auch in die Toolleiste, wo sie dann als Button erscheinen.
Der Spieler erhält eine genauere Beschreibung
der Gegenstände mit Hilfe eines Tooltips, sobald der
Mauscursor über dem Gegenstand schwebt. Gegenstände aus dem Inventar
können auch in die 3D-Umgebung gezogen werden, was dazu führt, dass die
Spielfigur den Gegenstand an der entsprechenden Stelle ablegt.
An der unteren linken Ecke des Inventars befindet sich ein Button, der
verwendet werden kann um die Gegenstände im Inventar automatisch sortieren zu lassen.
79
Es gibt noch ein zweites Inventar, das darstellt,
welche Gegenstände die Spielfigur trägt. Die Zellen diesen Inventars nehmen nur ganz spezielle Gegenstände auf, und als Ergebnis trägt dann auch
die Figur in der 3D-Umgebung den entsprechenden
Gegenstand. So kann man zum Beispiel nur eine
Rüstung in das dafür vorgesehene Inventarfeld ziehen, und wenn man das tut, trägt die Spielfigur die
Rüstung auch in der 3D-Umgebung.
Ansonsten verhält sich das Charakterinventar wie das gewöhnliche.
Die Karte ist eine weitere neue
Komponente. Sie gliedert sich in zwei
Ebenen. Die erste ist an und für sich
eine gezeichnete, sehr große Karte,
die man mit der Maus hin- und herziehen kann um alle Abschnitte zu
betrachten. Es werden einige zusätzliche Informationen eingeblendet, zum
Beispiel die Spielerposition, die Auftragsorte und die Gebietsgrenzen der
Gebiete, die der Spieler bereits besucht hat. Auch kann der Spieler auf dieser Karte noch eigene Marken setzen.
Wenn der Spieler aber mit der
rechten Maustaste klickt und diese
hält, wird eine Vergrößerung der Karte angezeigt. In dieser Vergrößerung
werden nur die Gebiete angezeigt,
die der Spieler bereits besucht hat,
dafür aber mit sehr vielen Details.
Dieser Teil passt sich dynamisch
dem Spielverlauf an und zeigt noch
mehr Informationen an als die große
Karte. Zum Beispiel findet man hier
Informationen, wo sich bestimmte Gebäude befinden und wie die Titel der
erfüllten und unerfüllten Aufträge lauten.
Wenn man die rechte Maustaste gedrückt
hält und dann die Maus bewegt, wird der sichtbare Auschnitt der Vergrößerung verschoben.
Eine letzte besondere Komponente ist ein
Graph, der bestimmte Informationen über das
Spiel als Diagramm darstellt. Dieses Diagramm
verändert sich im laufe des Spieles und gibt den
Fortschritt des Spielers an, ist aber nicht direkt
manipulierbar.
80
A.2
81
Aufbausimulation: Die Siedler 5
Das Spiel Die Siedler - Das Erbe der
Name
Die Siedler 5
Könige ist der fünfte Teil der Serie. Wie
Genre
Aufbausimulation
in den Vorgängern geht es darum eiEntwickler Blue Byte
ne Stadt aufzubauen und die Siedler in
Publisher
Ubisoft
dieser Stadt arbeiten und leben zu lasErschienen 2004
sen. Der Actionteil ist dabei sehr viel
Homepage www.siedler5.com
weniger ausgeprägt als in den meisten
anderen Spielen. Das Spiel kann auch übers Netzwerk gespielt werden, allerdings steht für die Untersuchung im Rahmen dieser Arbeit lediglich die
Demoversion zur Verfügung, in der dieses Feature nicht vorhanden ist. Da
man aber ansonsten zwei komplette Level mit allen Features spielen kann,
ist diese Version hier durchaus ein lohnenswertes Untersuchungsobjekt.
Das Spiel wurde vor allem aufgrund seines Genres ausgewählt, da Aufbausimulationen im allgemeinen viele verschiedene Möglichkeiten im Interface bieten. Das liegt nicht zuletzt daran, dass der Spieler ein wenig mehr
Zeit zur Navigation im Interface hat als in Actiontiteln, da es primär um den
geschickten Aufbau einer Siedlung geht und nicht nur um die Geschwindigkeit.
Verhalten
Die Siedler kann man nur im Vollbildschirmmodus spielen, hier allerdings
in verschiedenen Auflösungen. Dabei hat eine Veränderung der Auflösung
keinen Effekt auf das Benutzerinterface außer eine Steigerung der Qualität,
also in der Auflösung mit der die Komponenten dargestellt werden. Anders
als in gängigen Büroprogrammen führt eine erhöhte Auflösung nicht zu mehr
Bedienkomfort, sondern erhöht die visuelle Qualität.
Im Hintergrund, auch im Menü, gibt es 3D-Animationen, eine Hintergrundmusik und Sounds, wenn man die Komponenten des Interfaces bedient.
Allerdings sind diese nicht in besonderer Weise animiert.
Features
Die Tabelle A.3 führt die in Siedler 5 vorhandenen Standardfeatures auf.
Es gibt Tooltips, diese erscheinen jedoch nicht an der Mausposition, sondern an vordefinierten Stellen im Interface. Sie erscheinen unverzüglich, wenn
die Maus über einer Komponente mit Tooltip ist. Hotkeys werden überall im
Spiel verwendet.
82
Komponente
Tooltips
Hotkeys
Focus
Drag and Drop
Cut and Paste
Undo/Redo
Layout Manager
Look and Feel
Vorhanden
Ja
Ja
Nein
Nein
Nein
Nein
Nein
Ja
Bemerkung
an vorgegebenen Positionen
Tabelle A.3: Features in Siedler 5
Komponente
Labels
Images
Buttons
ToggleButtons
CheckBoxes
RadioButtons
ScrollBars
Slider
ProgressBars
ChooseLists
ComboBoxes
Spinners
Pannels
Windows
Dialogs
Registers
ScrollPanes
Menus
Kontextmenus
Toolbars
Tables
Trees
Text
StyledText
Vorhanden
Ja
Ja
Ja
Nein
Ja
Ja
Ja
Ja
Ja
Ja
Nein
Nein
Ja
Nein
Ja
Ja
Ja
Nein
Nein
Ja
Nein
Nein
Ja
Nein
Bemerkung
sehr einfach
vielfältig
Tabelle A.4: Komponenten in Siedler 5
83
Komponenten
Buttons werden hier nur selten mit Text, viel häufiger mit kleinen Icons
dargestellt. Sie reichen nicht über das hinaus, was man aus Standardanwendungen gewöhnt ist. Auch andere Komponenten bieten genau das, was man
von ihnen gewohnt ist.
Die Tabelle A.4 führt die in Siedler 5 vorhandenen Standardkomponenten
auf.
Es gibt jedoch auch einige wenige besondere Komponenten.
Eine Übersichtskarte stellt das Spielfeld in verkleinerter Ansicht dar. Dabei lassen sich mit Hilfe kleiner Buttons verschiedene Ansichten erstellen,
die jeweils besondere Eigenschaften der Spielwelt
hervorheben. Außerdem werden die Positionen besonderer Spielereignisse durch kleine Animationen
in der Karte dargestellt und der aktuell sichtbare Kartenausschnitt ebenfalls. Interessant ist auch,
dass die Karte an zwei Positionen im Interface benutzt wird, einmal in einer kleinen Ausführung und
einmal in einer großen. Sie ist also in ihrer Größe veränderbar.
Außerdem kann die Karte zur Navigation benutzt werden, da ein Klick in
das Fenster die 3D-Ansicht des Spieles an die angeklickte Position verschiebt.
Wenn man im Spiel ein Gebäude oder einen Avatar auswählt, dann wird in einer kleinen 3D-Ansicht
am unteren Rand des Bildschirms eine Animation
angezeigt. Es gibt also ein kleines 3D-Fenster neben
dem Hauptbildschirm.
Außer durch die Auswahl eines anderen Objektes in der 3D-Ansicht des Spieles, hat der Spieler
keinen Einfluss auf die Animation.
Eine weitere besondere Komponente ist eine Zeitanzeige am oberen Bildschirmrand. Anhand einer
Animation wird die Jahreszeit angezeigt. Es handelt sich also um so etwas wie einen zyklischen Fortschrittsbalken oder eine
Uhr.
84
Es gibt eine einfache Statistikkomponente. Hier können verschiedene Werte als Graph dargestellt werden. So kann die Entwicklung des
Spielgeschehens nachvollzogen werden. Auch diese Komponente wird
mehrfach verwendet, einmal im Spiel
und einmal zur Abschlussbewertung.
Dabei wird immer nur genau ein Wert gegen die Zeit abgetragen, niemals
mehrere auf einmal.
Im Spiel wird ausgiebig von einfachen
Toolleisten gebrauch gemacht. Diese stellen
üblicherweise eine oder mehrere Reihen von
Buttons dar, die der Benutzer zwar nicht direkt beeinflussen, aber durch die
Auswahl von Objekten im Spiel verändern kann. Die Position ist fix aber der
Inhalt dynamisch. Es gibt auch Leisten ,die an den Seiten sitzen.
Interessant ist, dass die Buttons in diesen Leisten manchmal noch spezielle Extraanzeigen haben. So kann ein Button zum Beispiel noch zwei extra
Zahlen anzeigen, um die absolute und die momentan verfügbare Anzahl einer
bestimmten Einheitenart anzuzeigen.
A.3
85
Rundenstrategie: Master of Orion 3
Der Spieler spielt in Master of
Name
Master of Orion 3
Orion 3 gegen einen oder mehrere
Genre
Rundenstrategie
Gegner und muss versuchen seinem
Entwickler Quicksilver
Volk zur Herrschaft über das UniPublisher
Infogrames
versum zu verhelfen. Er lenkt dabei
Erschienen 2002
die Geschickte seiner Leute aus eiHomepage moo3.quicksilver.com
ner sehr hohen Perspektive. Er entscheidet, an welchen Projekten geforscht wird, welche Planetensysteme von
welchen Schiffen angeflogen werden, wo gesiedelt werden soll und vieles mehr.
Gerade aufgrund dieser enormen Vielfalt, der schier unglaublichen Größe des Interfaces, wurde dieses Spiel ausgewählt. In ihm können sehr viele verschiedene Komponenten, die ein Spiel benötigt, gefunden werden. Die
3D-Anteile des Spieles sind dabei sehr gering und beschränken sich auf die
Spielkarte und einfache 3D-Weltraumschlachten. Fast die gesamte Spielzeit
verbringt der Spieler mit dem Manövrieren durch Menüs und dem Einstellen
von Werten.
Verhalten
Das Spiel läuft nur in genau einer Auflösung im Vollbildmodus. Überall erfährt man auch auditives Feedback, wenn man eine Komponente betätigt
und Hintergrundmusik ist allgegenwärtig. Die Animationen, wenn man von
einem Bildschirm zum nächsten navigiert oder einen Menüpunkt auswählt,
sind sehr ausgefeilt.
Features
Die Tabelle A.5 führt die in Master of Orion 3 vorhandenen Standardfeatures
auf.
An einigen Stellen sind Hotkeys definiert, sehr viel mehr navigiert man
aber mit der Maus. Es gibt ein eingeschränktes Fokussystem, eine Tabulatorfunktion ist aber nicht vorhanden.
Komponenten
Im Unterschied zu den anderen untersuchten Spielen verzichtet dieses größtenteils auf Texturen im 2D-Userinterface. Alle Hervorhebungen und andere
Komponente
Tooltips
Hotkeys
Focus
Drag and Drop
Cut and Paste
Undo/Redo
Layout Manager
Look and Feel
Vorhanden
Nein
Ja
Ja
Nein
Nein
Nein
Nein
Ja
86
Bemerkung
vereinzelt
einfach
Tabelle A.5: Features in Master of Orion 3
Auszeichnungen werden hier mittels Farben und einfachen Formen dargestellt. Von der Gestaltung abgesehen, es gibt Registerseiten in schier endlosen Variationen, werden hier allerdings fast nur Standardelemente benutzt.
Es gibt nur einige wenige Neuheiten. Die Tabelle A.6 führt die in Master of
Orion 3 vorhandenen Standardkomponenten auf.
Die verwendeten Tabellen und Auswahllisten sind sehr mächtig in ihrer
Funktion als Anzeige. Verschiedenste, auch zusammengesetzte, Komponenten
können als Auswahlelemente fungieren.
Spinner sind häufig verwendete Komponenten in MoO3.
Es gibt sie in vielen unterschiedlichen Ausprägungen.
Einige werden verwendet um aus mehreren Texten einen
auszuwählen, andere legen zwar einen Zahlenwert fest,
stellen diesen jedoch mit Hilfe von Balken auf eine ungewöhnliche Weise dar. Ein erweiterter Spinner ermöglicht sogar das Festlegen
einer Uhrzeit, wobei zwei Buttons jeweils für das Verstellen der Stunden und
zwei für die Minuten zuständig sind.
Es gibt modale Dialoge, diese sind allerdings
sehr simpel. Sie lassen sich nicht in der Größe und auch nicht in der Position variieren. Allerdings blockieren sie alle Nutzeraktionen ausserhalb des Dialoges, bis der Dialog geschlossen
wird.
Im Spiel werden sie fast ausschließlich zur
Darstellung von Hinweistexten benutzt und haben ein fest vorgegebenes Design.
Komponente
Labels
Images
Buttons
ToggleButtons
CheckBoxes
RadioButtons
ScrollBars
Slider
ProgressBars
ChooseLists
ComboBoxes
Spinners
Pannels
Windows
Dialogs
Registers
ScrollPanes
Menus
Kontextmenus
Toolbars
Tables
Trees
Text
StyledText
Vorhanden
Ja
Ja
Ja
Nein
Ja
Ja
Ja
Ja
Nein
Ja
Ja
Ja
Ja
Nein
Ja
Ja
Ja
Ja
Nein
Nein
Ja
Ja
Ja
Ja
Bemerkung
sehr vielfältig und spezielle
sehr einfach
sehr vielfältig
keine Untermenus
kein editieren, vielfältig
sehr einfach, nur Text
einfaches HTML
Tabelle A.6: Komponenten in Master of Orion 3
87
88
Ein weiteres und ausgiebig genutztes Element der Oberfläche sind Komponenten, die sich
über andere blenden. Normalerweise existieren
sie in Form eines Buttons oder einer platzsparenden Version, wird aber auf sie geklickt, wird
eine aufklappende Animation gestartet und die
Komponente wird über allen anderen angezeigt.
Wird nun eine andere aufklapbare Komponente geöffnet, schließt sich die erste, wieder mit
einer Animation. Es gibt allerdings auch, ähnlich wie bei normalen Menüs, Unterelemente,
die sich öffnen lassen. Diese schließen sich mit
dem Oberelement, wenn ein weiteres geöffnet
wird. Im Prinzip handelt es sich also tatsächlich um so etwas wie Menüelemente, allerdings ohne einzelne Menüeinträge und stattdessen mit kompletten
Inhalten. Außerdem ist natürlich die Positionierung anders festgelegt.
Die letzte besondere Komponente ist die Sternenkarte. Das gesamte Spielfeld wird hier zweidimensional abgebildet. Auf der linken Seite
kann der Spieler Planeten auswählen, deren Position dann auf der Karte hervorgehoben wird. Hier sind neben den Sternensystemen auch alle anderen wichtigen Elemente, wie zum Beispiel die Flotten der Spieler, verzeichnet.
Elemente können dabei ein- und ausgeblendet werden.
Anhang B
Screenshots der Spiele
89
ANHANG B. SCREENSHOTS DER SPIELE
Abbildung B.1: Sacred Screenshots
90
Abbildung B.2: Siedler 5 Screenshots
91
Abbildung B.3: Warcraft 3 Screenshots
92
Abbildung B.4: Etherlords Screenshots
93
Abbildung B.5: Master of Orion 3 Screenshots
94
Literaturverzeichnis
[CLS05]
Stéphane Chatty, Alexandre Lemport, and Stéphane Sire. Combining SVG and models of interaction to build graphically rich
user experiences. IntuiLab, Prologue 1. La Pyrénéenne, 31672,
Labege Cedex, France, 2005.
[Coo98]
James W. Cooper. The Design Patterns Java Companion.
Addison-Wesley, 1998.
[GHJV95] Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides.
Design Patterns. Elements of Reusable Software. Addison-Wesley,
1995.
[KP88]
Glenn E. Krasner and Stephen T. Pope. A Description of the
Model-ViewController User Interface Paradigm in the Smalltalk80 System. Parc Place Systems, Inc., 1988.
[LEW+ 03] Marc Loy, Robert Eckstein, Dave Wood, James Elliot, and Brian
Cole. Java Swing. O’Reilly, 2nd edition, 2003.
[Sch04]
Thomas Schuster. Entwicklung einer isometrischen GraphikEngine in Java. Universität Koblenz-Landau, August 2004.
[Ste04]
Christian Stein. Entwicklung einer Massive Multiplayer Network
Engine in Java. Universität Koblenz-Landau, Oktober 2004.
95

Ein von Gameengines unabhängiges User-Interface

Transcrição

Documentos relacionados

2K-PU Anti-Graffiti Schutzlack

Konzertprogramm Neuer Chor Stuttgart am 21.07.13

Art.No.: AC-DOC_SoftwareInstallation_g

Back to the Future - Irmie Schüch

einbauanleitung

Einbauanleitung EBA_640727

Einbauanleitung EBA_640735

Avision | AV5400 A3 Duplex Dokumentenscanner - Future-X

Oster-Tanz-Tage in OttobrunnTanzschule Siebenhüner, Tanzen

TS_to_DVD

Installationsanleitung K