Ein von Gameengines unabhängiges User-Interface-System für PC Spiele
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
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 7
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2 Ziele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3 Aufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.4 Zur Sprache . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2 Standard User Interfaces 10
2.1 Komponenten . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3 Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3 User Interfaces in Computerspielen 24
3.1 Spielanalysensystematik . . . . . . . . . . . . . . . . . . . . . 25
3.2 Kartentaktikspiel: Etherlords . . . . . . . . . . . . . . . . . . 26
3.3 Echtzeitstrategie: Warcraft 3 . . . . . . . . . . . . . . . . . . . 30
3.4 Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.4.1 Verhalten . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.4.2 Features . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.4.3 Standard Komponenten . . . . . . . . . . . . . . . . . 36
3.4.4 Erweiterte Komponenten . . . . . . . . . . . . . . . . . 38
4 Game UI-Framework 40
4.1 Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.1.1 Allgemeine Anforderungen . . . . . . . . . . . . . . . . 40
4.1.2 Featureanforderungen . . . . . . . . . . . . . . . . . . . 42
4.1.3 Komponentenanforderungen . . . . . . . . . . . . . . . 43
4.2 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.2.1 Komponentenaufbau . . . . . . . . . . . . . . . . . . . 45
4.2.2 Kommunikation . . . . . . . . . . . . . . . . . . . . . . 46
4.2.3 Look and Feel . . . . . . . . . . . . . . . . . . . . . . . 46
4.2.4 Ein- und Ausgaben . . . . . . . . . . . . . . . . . . . . 47
3
INHALTSVERZEICHNIS 4
4.3 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 74
A.1 Actionrollenspiel: Sacred . . . . . . . . . . . . . . . . . . . . . 75
A.2 Aufbausimulation: Die Siedler 5 . . . . . . . . . . . . . . . . . 81
A.3 Rundenstrategie: Master of Orion 3 . . . . . . . . . . . . . . . 85
B Screenshots der Spiele 89
Abbildungsverzeichnis
2.1 Aufbau der Komponenten in Swing am Beispiel eines Buttons 19
2.2 Beispiel einer Delegate-Installation in Swing . . . . . . . . . . 22
4.1 Die Architektur des UI-Systems . . . . . . . . . . . . . . . . . 45
4.2 Zusammenhänge der wichtigsten Klassen . . . . . . . . . . . . 48
4.3 Aufgabendelegation der Klasse UISystem . . . . . . . . . . . . 50
4.4 Unabhängigkeit des UI-Systems von anderen Bibliotheken . . 51
4.5 Das Interface Component und das View . . . . . . . . . . . . 53
4.6 Aufbau eines Buttons im UI-System . . . . . . . . . . . . . . . 54
4.7 Events und Listeners des UI-Systems . . . . . . . . . . . . . . 55
4.8 Relevante Klassen im Look and Feel System am Beispiel eines
Buttons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.1 Verschiedene Mouseover-Effects der Buttons in Demo2 . . . . 62
5.2 Demo 1 Screenshots . . . . . . . . . . . . . . . . . . . . . . . . 64
5.3 Demo 2 Screenshots . . . . . . . . . . . . . . . . . . . . . . . . 65
B.1 Sacred Screenshots . . . . . . . . . . . . . . . . . . . . . . . . 90
B.2 Siedler 5 Screenshots . . . . . . . . . . . . . . . . . . . . . . . 91
B.3 Warcraft 3 Screenshots . . . . . . . . . . . . . . . . . . . . . . 92
B.4 Etherlords Screenshots . . . . . . . . . . . . . . . . . . . . . . 93
B.5 Master of Orion 3 Screenshots . . . . . . . . . . . . . . . . . . 94
5
Tabellenverzeichnis
2.1 Komponenten in Swing . . . . . . . . . . . . . . . . . . . . . . 11
2.2 Features in Swing . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.1 Features in Etherlords . . . . . . . . . . . . . . . . . . . . . . 28
3.2 Komponenten in Etherlords . . . . . . . . . . . . . . . . . . . 28
3.3 Features in Warcraft 3 . . . . . . . . . . . . . . . . . . . . . . 32
3.4 Komponenten in Warcraft 3 . . . . . . . . . . . . . . . . . . . 32
3.5 Zusammenfassung der Features der Spiele . . . . . . . . . . . 36
3.6 Zusammenfassung der Komponenten der Spiele . . . . . . . . 37
4.1 Wichtige Komponenten für Spiele . . . . . . . . . . . . . . . . 43
7.1 Implementierte Komponenten . . . . . . . . . . . . . . . . . . 71
A.1 Features in Sacred . . . . . . . . . . . . . . . . . . . . . . . . 76
A.2 Komponenten in Sacred . . . . . . . . . . . . . . . . . . . . . 77
A.3 Features in Siedler 5 . . . . . . . . . . . . . . . . . . . . . . . 82
A.4 Komponenten in Siedler 5 . . . . . . . . . . . . . . . . . . . . 82
A.5 Features in Master of Orion 3 . . . . . . . . . . . . . . . . . . 86
A.6 Komponenten in Master of Orion 3 . . . . . . . . . . . . . . . 87
6
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, Tabellenkal-
kulation, Bildbearbeitungsprogramme, Editoren und Browser sind nur eini-
ge Beispiele die erfolgreich Gebrauch von diesen Bibliotheken machen. Sie
vereinfachen das Erstellen dieser Programme ungemein, da ansonsten vie-
le Komponenten wie Buttons, Auswahllisten und Menüs immer wieder neu
implementiert werden müssten.
Es gibt jedoch Anwendungen die nicht von diesen Bibliotheken profi-
tieren, 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 übli-
chen 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 Ober-
flächensystem (im folgenden kurz UI-System vom englischen User Interface
System) für 3D-PC-Spiele nachzugehen und in der Folge ein solches prototy-
pisch 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 er-
stellt werden. Das ist schon alleine deswegen nicht möglich, weil sich die
Spiele in ihrem Interface in der Gesamtbetrachtung so radikal unterschei-
den, dass eine sinnvolle Abstraktion unter Berücksichtigung aller Aspekte
ausgeschlossen ist. Gerade in den 3D-Anteilen des Interfaces sind die Un-
terschiede 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 beant-
worten was für Features und Komponenten vorhandene Frameworks für das
Erstellen von typischen Büroanwendungen üblicherweise zur Verfügung stel-
len 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 Spie-
leentwicklung mit einem System für die Erzeugung von Bedienoberflächen
unterstützt. Dazu werden zunächst die Anforderungen an ein solches Sys-
tem 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 eini-
ge 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 9 1.4 Zur Sprache Diese Arbeit ist in Deutsch geschrieben. Allerdings werden zur Beschreibung von Oberflächenkomponenten und einigen anderen Konstrukten der Informa- tik 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 Fra-
mework für die allgemeinen Oberflächen gängiger Programme bietet. Wir
werden untersuchen, welche Techniken und Komponenten ein solches Fra-
mework zur Verfügung stellt und anhand dieser Informationen werden wir
dann in Kapitel 3 untersuchen können, welche Unterschiede bestehen zwi-
schen 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 Wichtig-
keit: Das System sollte soweit wie möglich vom darunter liegenden Fenster-
system unabhängig sein. Das heißt, dass es seine Komponenten selbst imple-
mentieren sollte und nicht auf nativen Widgeds basieren darf. Diese Forde-
rung 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 Verwen-
dung 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 Program-
miersprache Java ansehen. Sie erfüllt die oben formulierten Anforderungen
10KAPITEL 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 wieder-
verwendbaren Komponenten die zusammengesetzt das Interface eines Pro-
gramms bilden. Die Komponenten die Swing bietet sind in Tabelle 2.1 auf-
geführt.
Komponente Komponente
Labels Pannels
Images Windows
Buttons Dialogs
ToggleButtons Registers
CheckBoxes ScrollPanes
RadioButtons Menus
ScrollBars Kontextmenus
Slider Toolbars
ProgressBars Tables
ChooseLists Trees
ComboBoxes Textfields
Spinners 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 Komponen-
ten gegeben. Für sehr viel detailliertere Informationen siehe zum Beispiel
[LEW+ 03].
Labels Eine wichtige Grundvoraussetzung der meisten Anwendungen be-
steht 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 mit-
tels 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. ausKAPITEL 2. STANDARD USER INTERFACES 12 einer PNG-Datei stammen, oder kann auch dynamisch vom Programm er- zeugt werden. Images reagieren normalerweise nicht auf Aktionen des Benut- zers und werden in Swing ebenfalls durch Labels realisiert. Buttons Buttons dienen normalerweise lediglich dazu eine Aktion auszu- lösen, wenn mit der Maus auf sie geklickt wird. Sie haben verschiedene Zu- stä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 zu- rü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 un- terscheidet 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 verschiede- nen 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 hori- zontal 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 sicht- bar 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
KAPITEL 2. STANDARD USER INTERFACES 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 Radiobut-
tons auch ChooseLists an. Hier sind, meist textuell, mehrere Wahlmöglich-
keiten aufgelistet, von denen eine oder, je nach Einstellung, auch mehrere
Elemente gewählt werden können. Wenn mehr Wahlmöglichkeiten zur Ver-
fügung stehen, als die Komponente auf einmal darstellen kann, wird eine
ScrollBar sichtbar, um zu den verschiedenen Möglichkeiten blättern zu kön-
nen. 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 un-
sichtbar 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 Wei-
se kann man aus vielen Alternativen wählen und braucht nur relativ wenig
Platz auf der Oberfläche für die Komponente. Allerdings ist eine Mehrfach-
auswahl 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 ge-
wä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 grup-
pieren. Ein Panel selbst hat normalerweise keine graphische Repräsentation
sondern sorgt nur dafür dass die Unterkomponenten dargestellt werden.KAPITEL 2. STANDARD USER INTERFACES 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 Komponen-
ten 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 Un-
terfenster 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 klei-
ne 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 Anwen-
dung 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 ge-
stalten 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 kom-
plett 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 inKAPITEL 2. STANDARD USER INTERFACES 15
Hauptpunkte welche, wenn angeklickt, Unterpunkte offenbaren. Diese kön-
nen 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 (ge-
wö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 But-
tons, 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 konfi-
gurierbar, 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ütz-
lichsten 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 je-
de 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. Da-
bei hat jede Zeile genau die Felder die von den einzelnen Spalten definiert
werden. Jede Zelle benutzt die in den Spalten definierten Renderer und Edi-
toren.
Trees Um hierarchische Daten wie zum Beispiel das Dateisystem mit seinen
Ordnern und Dateien anzuzeigen eignen sich Trees. Häufig lassen sich dieKAPITEL 2. STANDARD USER INTERFACES 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 for-
matierten 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 Web-
browser 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 zie-
hen und damit wesentlich sein grundsätzliches Aussehen und Verhalten be-
stimmen. 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.KAPITEL 2. STANDARD USER INTERFACES 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 be-
schleunigen 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 Texteingabefel-
dern, in welches wird momentan getippt? Kurz, welche Komponente emp-
fängt zu einem gegebenen Zeitpunkt Tastertureingaben? Dies regelt gewöhn-
licherweise 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 Do-
kument 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 Taster-
tur zu markieren, dann auszuschneiden und an anderer Stelle wieder einzufü-
gen wird als Cut and Paste bezeichnet. Häufig ist diese Funktionalität auchKAPITEL 2. STANDARD USER INTERFACES 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 ei- ne Funktionalität um Änderungen rückgängig zu machen und gegebenenfalls sogar das Rückgängigmachen zu widerrufen. Diese Funktionalität wird Un- do/Redo genannt. Layout Manager Komponenten in einer Anwendung sind auf bestimmte Weise angeordnet. Es gibt verschiedene Methoden um diese Anordnung fest- zulegen. 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 Ma- nager würde zum Beispiel alle Komponenten einfach hintereinander darstel- len, 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 Win- dows 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ächs- tes gilt es, eine ungefähre Vorstellung davon zu bekommen wie diese Fähig- keiten realisiert werden. Dafür werfen wir einen kurzen Blick auf die Archi- tektur 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.
KAPITEL 2. STANDARD USER INTERFACES 19
Komponentenaufbau Swing baut seine Komponenten nach einer Model-
View-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.
Wird vom Entwickler instantiiert
Button und enthält den visuellen Zustand
des Buttons (Position, Größe usw.).
referenziert
ButtonModel ButtonUI
Enthält den internen Zustand Nutzt die Zustandsinformationen
des Buttons, also ob sich die des Buttons um diesen darzustellen.
Maus über ihm befindet, er Kann ausgetauscht werden um das
gedrückt ist und anderes. 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 ers-
te Klasse ist die eigentliche Komponente. Diese wird später vom Anwendungs-
entwickler instantiiert. Sie enthält den Zustand der das visuelle Erscheinungs-
bild 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 Darstellungs-
routine. 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 Komponenten-
klasse 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 ModellKAPITEL 2. STANDARD USER INTERFACES 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 Modell-
Superklasse, die Modelle sind zu speziell, als das es irgendwelche Gemein-
samkeiten 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 kommu-
nizieren, 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 Bei-
spiel Mausklicks und Tasterturanschläge, und Highlevel-Ereignissen wie zum
Beispiel das Drücken eines Buttons. Die Lowlevel-Ereignisse werden vom Be-
triebssystem generiert und vom System an die betreffenen Komponenten wei-
tergeleitet, 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 die-
se 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 Ent-
wicklungsaufwand 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 VerhaltenKAPITEL 2. STANDARD USER INTERFACES 21
des darunter liegenden Systems simulieren1 . Der Komponentenaufbau liefert
für diese Simulierung den Grundbaustein, da sich das Delegate einer Kom-
ponente 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 ablau-
fen. Der Entwickler darf nicht dazu gezwungen sein, für jede Komponenten-
instanz 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 Dia-
gram 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 ge-
hört. Im Beispiel antwortet der Button, dass er ein ButtonUI-Delegate
benötigt.
5. Die UIDefaults bestimmen, welche Klasse zu der entsprechenden ID ge-
hört und erzeugen per Reflexion eine entsprechende Delegate-Instanz
button1ui. Diese ist platformspezifisch, da die Defaults ja vor der In-
stantiierung 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 but-
ton1ui 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.KAPITEL 2. STANDARD USER INTERFACES 22
button1:Button UIManager def:UIDefaults WinButtonUI button1ui:WinButtonUI
getUI(button1)
getUI(button1)
getUIClassID()
ButtonUI:UIClassID
createUI(button1)
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 Dele-
gates 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 Kompo-
nenten 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 Komponen-
tenentwickler 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 vermit-
telt. 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.KAPITEL 2. STANDARD USER INTERFACES 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 re-
kursiv 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 wer-
den 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 Fens-
ter 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 Kom-
ponente 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 At-
tribut 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 meh-
reren 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 ausge-
stattet 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 Ober-
flächen einiger sehr verschiedener Spiele mit denen anderer Programme prä-
sentiert. Die Möglichkeiten der Oberflächen anderer Programme wurden da-
bei in Kapitel 2 bereits dargelegt durch die Analyse, was ein heutiges UI-
System bietet. Dieser Vergleich wird dazu beitragen, die Unterschiede und
Gemeinsamkeiten der Programmgattungen herauszuarbeiten. Das wird wie-
derum 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 Untersu-
chung durchgeführt wurde. Weitere drei finden sich in Anhang A.
Aufgrund des dynamischen Charakters von Spielen können die Ergebnis-
se 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 gewin-
nen 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, wer-
24KAPITEL 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 darstel-
len. 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 Spie-
le 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 unterschied-
lichen 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 An-
wendungen 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 ointerKAPITEL 3. USER INTERFACES IN COMPUTERSPIELEN 26
3.2 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 auszutra- Publisher 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, beson-
ders in den Optionsmenus, da sich jeder Spieler seinen eigenen Charakter
mit seinen eigenen Karten erstellen kann, um größtmögliche taktische Spiel-
tiefe 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 rundenba-
sierten Aufbaus, die Spieler handeln nacheinander, ausgewählt. Das Interface
ist also, anders als z.B. bei Warcraft 3 (siehe Abschnitt 3.3), nicht darauf an-
gewiesen, unmittelbaren, superschnellen Zugriff auf alle Funktionen zu bie-
ten, 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 verschie-
denen Auflösungen. Die Auflösung beeinträchtigt die Darstellung der einzel-
nen 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är-
tig, 3D-Szenen hingegen nur im eigentlichen Spiel, nicht in den Options-
bildschirmen. Das eigentliche Interface ist sehr nahe an dem, was man von
typischen anderen Anwendungen gewohnt ist. In ihrem Verhalten unterschei-
den 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.KAPITEL 3. USER INTERFACES IN COMPUTERSPIELEN 27
Tooltips lassen sich mit einem Rechtsklick der Maus einblenden und ver-
schwinden wieder, wenn die Taste losgelassen wird. Diese Tips sind nicht
einfacher Text, sondern formatiert und können auch ein Bild enthalten. Hot-
keys 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 Standardkomponen-
ten auf.
Die einzige Fensterart sind
modale Dialoge. Diese sind
allerdings sehr schlicht. So kann
der Benutzer sie weder ver-
schieben noch in irgendeiner
Weise vergrößern oder ver-
kleinern. Sie fassen einfach
Elemente zusammen und ver-
hindern das nicht zum Dia-
log gehörende Elemente be-
nutzt werden, bis der Dialog
geschlossen wurde.
Fast alle Komponenten in
den Optionsbildschirmen wer-
den in diesen Dialogen ein-
gebettet, 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 Standard-
buttons, 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.KAPITEL 3. USER INTERFACES IN COMPUTERSPIELEN 28
Komponente Vorhanden Bemerkung
Tooltips Ja durch rechte Maustaste
Hotkeys Ja vereinzelt
Focus Nein
Drag and Drop Nein
Cut and Paste Nein
Undo/Redo Nein
Layout Manager Nein
Look and Feel Ja eigenes Look and Feel
Tabelle 3.1: Features in Etherlords
Komponente Vorhanden Bemerkung
Labels Ja
Images Ja
Buttons Ja
ToggleButtons Nein
CheckBoxes Ja
RadioButtons Ja
ScrollBars Ja
Slider Ja
ProgressBars Ja
ChooseLists Ja
ComboBoxes Nein
Spinners Ja sehr vielfältig und spezielle
Pannels Ja
Windows Nein
Dialogs Ja sehr einfach
Registers Ja
ScrollPanes Ja
Menus Nein
Kontextmenus Nein
Toolbars Nein
Tables Ja kein editieren, vielfältig
Trees Nein
Text Ja
StyledText Nein
Tabelle 3.2: Komponenten in EtherlordsKAPITEL 3. USER INTERFACES IN COMPUTERSPIELEN 29
Besonders interessant sind die viel-
fältig verwendeten Spinner. Neben
den bekannten gibt es noch eine Rei-
he erweiterter. Einige werden als Aus-
wahlelement 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 son-
dern 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 Spin-
nern 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 Spieler-
position wird auch noch seine Blickrichtung durch
einen Pfeil dargestellt. Die Karte passt sich ver-
änderungen im Spiel an. So werden noch nicht er-
forschte Bereiche schwarz dargestellt, während die
bekannten in anderen Farben eingezeichnet werden.KAPITEL 3. USER INTERFACES IN COMPUTERSPIELEN 30
3.3 Echtzeitstrategie: Warcraft 3
Die primäre Aufgabe des Spie-
Name 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 Ge-
Erschienen 2003
genspieler zu besiegen. Damit wird
Homepage www.blizzard.com/war3/
an das Benutzerinterface beson-
ders die Anforderung gestellt, dass es schnell und unkompliziert zu bedienen
ist. Es kann alleine oder übers Netzwerk mit mehreren Spielern gespielt wer-
den und ist eines der meist verkauften Spiele überhaupt. Es gibt eine Erwei-
terung 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 be-
sitzt, 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 rea-
giert auf eine Veränderung der Bildschirmauflösung, indem die Qualität er-
hö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 Textu-
ren 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.KAPITEL 3. USER INTERFACES IN COMPUTERSPIELEN 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 hervorgeho-
ben. 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 pri-
mitiver 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ägun-
gen, 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 Standardkomponen-
ten 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 än-
dern, noch kann der Benutzer sie verschie-
ben oder schließen. Auch haben sie keine
Menus oder Toolbars. Sie dienen lediglich
dem Zusammenfassen von anderen Kompo-
nenten und können sich programmgesteu-
ert bewegen. So kann ein Fenster bei Druck
eines Buttons aus dem Bildschirm heraus-
schnellen und ein neues eingeblendet wer-
den.
Es gibt aber auch noch eine Unterart
von Fenstern, die in etwa den modalen Dia-
logen aus bekannten Programmen entspre-
chen. 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 In-
terface verwendet werden. Diese zeichnen sich durch
erweiterte Funktionalität aus. Einige von ihnen kön-
nen mit einen rechten Mausklick ausgewählt werden, so dass ein zusätzlicherSie können auch lesen
