Ein von Gameengines unabhängiges User-Interface-System für PC Spiele. Diplomarbeit

Transkript

1 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: Zweitgutachter: Prof. Dr.-Ing. Stefan Müller (Institut für Computervisualistik, AG Computergraphik) Dipl.-Inform. Oliver Abert (Institut für Computervisualistik, AG Computergraphik) Koblenz, im März 2006

2 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)

3 (Platzhalter für Aufgabenstellung)

4 Inhaltsverzeichnis 1 Einleitung Motivation Ziele Aufbau Zur Sprache Standard User Interfaces Komponenten Features Architektur User Interfaces in Computerspielen Spielanalysensystematik Kartentaktikspiel: Etherlords Echtzeitstrategie: Warcraft Ergebnisse Verhalten Features Standard Komponenten Erweiterte Komponenten Game UI-Framework Anforderungen Allgemeine Anforderungen Featureanforderungen Komponentenanforderungen Design Komponentenaufbau Kommunikation Look and Feel Ein- und Ausgaben

5 INHALTSVERZEICHNIS Implementation Technologien Details Demos Allgemeines Demo 1 - Warcraft Demo 2 - Etherlords Ausblick Eigene Mauszeiger Unabhängigkeit von Programmiersprachen Konfiguration mittels Beschreibungssprache Fazit Erfüllte Anforderungen Kritik Zusammenfassung A Weitere Spielanalysen 74 A.1 Actionrollenspiel: Sacred A.2 Aufbausimulation: Die Siedler A.3 Rundenstrategie: Master of Orion B Screenshots der Spiele 89

6 Abbildungsverzeichnis 2.1 Aufbau der Komponenten in Swing am Beispiel eines Buttons Beispiel einer Delegate-Installation in Swing 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 Verschiedene Mouseover-Effects der Buttons in Demo Demo 1 Screenshots Demo 2 Screenshots B.1 Sacred Screenshots B.2 Siedler 5 Screenshots B.3 Warcraft 3 Screenshots B.4 Etherlords Screenshots B.5 Master of Orion 3 Screenshots

7 Tabellenverzeichnis 2.1 Komponenten in Swing Features in Swing Features in Etherlords Komponenten in Etherlords Features in Warcraft Komponenten in Warcraft Zusammenfassung der Features der Spiele Zusammenfassung der Komponenten der Spiele Wichtige Komponenten für Spiele Implementierte Komponenten A.1 Features in Sacred A.2 Komponenten in Sacred A.3 Features in Siedler A.4 Komponenten in Siedler A.5 Features in Master of Orion A.6 Komponenten in Master of Orion

8 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

9 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.

10 KAPITEL 1. EINLEITUNG 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.

11 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

12 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 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 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

13 KAPITEL 2. STANDARD USER INTERFACES 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

14 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 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.

15 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 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

16 KAPITEL 2. STANDARD USER INTERFACES 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

17 KAPITEL 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 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.

18 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 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

19 KAPITEL 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 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.

20 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 ), 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 ButtonUI Enthält den internen Zustand des Buttons, also ob sich die Maus über ihm befindet, er gedrückt ist und anderes. 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

21 KAPITEL 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 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

22 KAPITEL 2. STANDARD USER INTERFACES 21 des darunter liegenden Systems simulieren 1. 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.

23 KAPITEL 2. STANDARD USER INTERFACES 22 button1:button UIManager def:uidefaults WinButtonUI button1ui:winbuttonui <<create>> getui(button1) getui(button1) getuiclassid() ButtonUI:UIClassID createui(button1) button1ui <<create>> 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 instantiieren 2. 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.

24 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 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.

25 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 UI- System 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, wer- 24

26 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 WIMP 1 -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 Icon Menu Pointer

27 KAPITEL 3. USER INTERFACES IN COMPUTERSPIELEN Kartentaktikspiel: Etherlords Bei dem Spiel Etherlords handelt es sich um Taktikspiel, welches auf ein Kartensystem setzt, um Duelle zwischen zwei Opponenten auszutragen. Gewisse strategische Komponenten kommen durch eine Karte, auf der gespielt wird, hinzu. Obwohl das Name Etherlords Genre Kartentaktikspiel Entwickler Nival Publisher Fishtank Erschienen 2001 Homepage 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.

28 KAPITEL 3. USER INTERFACES IN COMPUTERSPIELEN 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 werden 2. 2 Das kann hier natürlich nicht bewiesen werden sondern beruht auf der Einschätzung des Autoren.

29 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 Etherlords

30 KAPITEL 3. USER INTERFACES IN COMPUTERSPIELEN 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.

31 KAPITEL 3. USER INTERFACES IN COMPUTERSPIELEN Echtzeitstrategie: Warcraft 3 Name Warcraft 3 Genre Echtzeitstrategie Entwickler Blizzard Publisher Blizzard Erschienen 2003 Homepage Die primäre Aufgabe des Spielers in Warcraft ist der Aufbau von Gebäuden, die Produktion von Einheiten und das Steuern derselbigen um den oder die Gegenspieler zu besiegen. Damit wird 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.

32 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 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

33 KAPITEL 3. USER INTERFACES IN COMPUTERSPIELEN 32 Komponente Vorhanden Bemerkung Tooltips Ja Hotkeys Ja Focus Ja Drag and Drop Ja nur innerhalb des Spieles Cut and Paste Nein Undo/Redo Nein Layout Manager Nein Look and Feel Ja eigenes Look and Feel Tabelle 3.3: Features in Warcraft 3 Komponente Vorhanden Bemerkung Labels Ja Images Ja Buttons Ja viele spezielle Buttons ToggleButtons Nein CheckBoxes Ja RadioButtons Nein ScrollBars Ja Slider Ja ProgressBars Ja ChooseLists Ja ComboBoxes Ja Spinners Nein Pannels Ja Windows Nein Dialogs Ja sehr einfach Registers Ja ScrollPanes Ja Menus Nein Kontextmenus Nein Toolbars Ja kein verschieben Tables Ja kein editieren Trees Nein Text Ja StyledText Nein Tabelle 3.4: Komponenten in Warcraft 3

34 KAPITEL 3. USER INTERFACES IN COMPUTERSPIELEN 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 3D- Szene 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.

35 KAPITEL 3. USER INTERFACES IN COMPUTERSPIELEN 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 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

36 KAPITEL 3. USER INTERFACES IN COMPUTERSPIELEN 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 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

37 KAPITEL 3. USER INTERFACES IN COMPUTERSPIELEN 36 Feature Sac. Sie. War. Eth. MoO. Ergebnis Tooltips Ja Ja Ja Ja Nein 4 Hotkeys Ja Ja Ja Ja Ja 5 Focus Nein Nein Ja Nein Ja 2 Drag and Drop Ja Nein Ja Nein Nein 2 Cut and Paste Nein Nein Nein Nein Nein 0 Undo/Redo Nein Nein Nein Nein Nein 0 Layout Manager Nein Nein Nein Nein Nein 0 Look and Feel Ja Ja Ja Ja Ja 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 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.

38 KAPITEL 3. USER INTERFACES IN COMPUTERSPIELEN 37 Komponente Sac. Sie. War. Eth. MoO. Ergebnis Labels Ja Ja Ja Ja Ja 5 Images Ja Ja Ja Ja Ja 5 Buttons Ja Ja Ja Ja Ja 5 ToggleButtons Nein Nein Nein Nein Nein 0 CheckBoxes Ja Ja Ja Ja Ja 5 RadioButtons Ja Ja Nein Ja Ja 4 ScrollBars Ja Ja Ja Ja Ja 5 Slider Ja Ja Ja Ja Ja 5 ProgressBars Ja Ja Ja Ja Nein 4 ChooseLists Ja Ja Ja Ja Ja 5 ComboBoxes Ja Nein Ja Nein Ja 3 Spinners Nein Nein Nein Ja Ja 2 Pannels Ja Ja Ja Ja Ja 5 Windows Nein Nein Nein Nein Nein 0 Dialogs Ja Ja Ja Ja Ja 5 Registers Ja Ja Ja Ja Ja 5 ScrollPanes Ja Ja Ja Ja Ja 5 Menus Nein Nein Nein Nein Ja 1 Kontextmenus Nein Nein Nein Nein Nein 0 Toolbars Ja Ja Ja Nein Nein 3 Tables Ja Nein Ja Ja Ja 4 Trees Nein Nein Nein Nein Ja 1 Textfields Ja Ja Ja Ja Ja 5 StyledText Nein Nein Nein Nein Ja 1 Tabelle 3.6: Zusammenfassung der Komponenten der Spiele Gerade in den Optionsbildschirmen findet man auch sehr häufig Check- Boxes, 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-

39 KAPITEL 3. USER INTERFACES IN COMPUTERSPIELEN 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 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.

40 KAPITEL 3. USER INTERFACES IN COMPUTERSPIELEN 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.

41 Kapitel 4 Game UI-Framework In den vorhergehenden Kapiteln haben wir uns damit beschäftigt, was UI- Systeme 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 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 einzufin- 40

42 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

43 KAPITEL 4. GAME UI-FRAMEWORK 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 3D- Animationen 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 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.

44 KAPITEL 4. GAME UI-FRAMEWORK 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 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 Komponente Labels 3 Spinners 3 Images 3 Pannels 3 Buttons 3 Dialogs 2 CheckBoxes 3 Registers 2 RadioButtons 3 ScrollPanes 2 ScrollBars 3 Menus 1 Slider 3 Toolbars 2 ProgressBars 3 Tables 1 ChooseLists 3 Trees 1 ComboBoxes 2 Textfields 3 Clock 2 Inventar 1 Map 2 Graph 1 Tabelle 4.1: Wichtige Komponenten für Spiele Für Dialogs muss es nur eine sehr rudimentäre Unterstützung geben und

45 KAPITEL 4. GAME UI-FRAMEWORK 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 Systems 1. 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.

46 KAPITEL 4. GAME UI-FRAMEWORK 45 UI-System Look and Feel System Spiel meldet Look and Feel an Spiel Look and Feel des Spieles fordert View an erzeugt referenziert Dateien und Views Sound+Grafikdateien Views nutzen Standartkomponenten Model Komponenten Spielspezifische Komponenten und eigene Views M. Component referenziert View C. V. sendet Sound- und Grafikausgaben Interfaces werden einmal pro externem System implementiert instantiiert, interagieren durch Event-Listener sendet Mausund Tasterturereignisse Soundsystem Interface Externes Soundsystem Spiellogik sendet Sound- und Grafikausgaben Inputsystem Graphiksystem Interface Externes Rendersystem sendet Maus- und Tasterturereignisse Abbildung 4.1: Die Architektur des UI-Systems Komponentenaufbau Aus den Anforderungen geht hervor, dass unser System konfigurierbar und erweiterbar sein soll. Beide Eigenschaften können wir massiv durch eine MVC- Architektur 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-

47 KAPITEL 4. GAME UI-FRAMEWORK 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 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 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 machen 2. 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.

48 KAPITEL 4. GAME UI-FRAMEWORK 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 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 ist 3. 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

49 KAPITEL 4. GAME UI-FRAMEWORK 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 die Hilfsmittel aufführen, die wir verwendet haben um das Framework zu implementieren. Danach werden wir in Abschnitt die einzelnen Klassen und deren Zusammenspiel erklären. Eine Übersicht über die Zusammenhänge der 24 wichtigsten Klassen 4 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. UISystem referenziert Renderer sendet Ausgabebefehle java.util.hashtable referenziert LWJGLUISystem instantiiert LWJGLRenderer referenziert LookAndFeel Texture nutzt UIDefaults befüllt LWJGLTexture BasicLookAndFeel sendet Eingabeereignisse enthält Komponenten EventHandler fordert View an fragt nach eindeutigem Schlüssel für View <<interface>> Component verteilt Ereignisse an Komponenten referenziert und instantiiert <<interface>> View referenziert AbstractComponent AbstractView AbstractButton referenziert ButtonView CheckboxView Button <<interface>> ButtonModel Checkbox BasicButtonView BasicCheckboxView instantiiert DefaultButtonModel ToggleButtonModel 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.

50 KAPITEL 4. GAME UI-FRAMEWORK 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 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

51 KAPITEL 4. GAME UI-FRAMEWORK 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 Panel delegiert Inputevents 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.

52 KAPITEL 4. GAME UI-FRAMEWORK 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 +<<static>> getinstance(): UISystem +createrenderer(): Renderer +createtexture(): Texture...() Renderer +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 erzeugt +getwidth(): int +getheight(): int +createtexture() LWJGLTexture +bind() +createtexture() nutzt +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.

53 KAPITEL 4. GAME UI-FRAMEWORK 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 dafür entschieden, den vereinfachten MVC- Komponentenaufbau 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-

54 KAPITEL 4. GAME UI-FRAMEWORK 53 Komfort-Methoden wie: getx(), getwidth()... weitere Listener-Methoden weitere fireevent-methoden <<interface>> Component +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

55 KAPITEL 4. GAME UI-FRAMEWORK 54 <<interface>> ButtonModel <<interface>> Component <<interface>> View <<interface>> MouseListener +getactioncommand(): String +isarmed(): boolean +isenabled(): 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) +...() referenziert +...() +...() AbstractView +...() ButtonView <<interface>> DefaultButtonModel +...() instantiiert AbstractButton +getmodel(): ButtonModel +getactioncommand(): String +getmousebutton(): int +isenabled(): boolean +setmodel(m:buttonmodel) +setactioncommand(c:string) +setmousebutton(b:int) Button 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) +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.

56 KAPITEL 4. GAME UI-FRAMEWORK 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. Event +isconsumed(): boolean +getwhen(): long +getsource(): Object +setconsumed(v:boolean) +setsource(s:object) +setwhen(time:long) <<interface>> ActionListener +actionperformed(e:actionevent) <<interface>> ChangeListener +statechanged(e:changeevent) ChangeEvent PropertyChangeEvent +getpropertyname(): String +getoldvalue(): Object +getnewvalue(): Object +setpropertyname(n:string) +setoldvalue(v:object) +setnewvalue(v:object) InputEvent ActionEvent +getactioncommand(): String +setactioncommand(c:string) <<interface>> PropertyChangeListener +propertychanged(e:propertychangeevent) <<interface>> KeyboardListener +keypressed(e:keyboardevent) +keyreleased(e:keyboardevent) <<interface>> MouseListener +mousepressed(e:mouseevent) +mousereleased(e:mouseevent) +mouseclicked(e:mouseevent) +mousedoubleclicked(e:mouseevent) +mouseentered(e:mouseevent) +mouseleaved(e:mouseevent) KeyboardEvent +getkey(): String +setkey(key:string) <<interface>> MouseMotionListener +mousemoved(e:mouseevent) MouseEvent +getbutton(): int +setbutton(b:int) DNDEvent <<interface>> DNDListener +mousedraged(e:dndevent) +mousedroped(e:dndevent) +mousedragmoved(e:dndevent) +getdragtarget(): Object +setdragtarget(o:object) Abbildung 4.7: Events und Listeners des UI-Systems

57 KAPITEL 4. GAME UI-FRAMEWORK 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.

58 KAPITEL 4. GAME UI-FRAMEWORK 57 UISystem java.util.hashtable referenziert LWJGLUISystem LookAndFeel referenziert UIDefaults befüllt BasicLookAndFeel fordert View an <<interface>> View referenziert <<interface>> Component AbstractView AbstractComponent ButtonView AbstractButton referenziert referenziert und instantiiert BasicButtonView Button <<interface>> ButtonModel fragt nach eindeutigem Schlüssel für View instantiiert DefaultButtonModel Abbildung 4.8: Relevante Klassen im Look and Feel System am Beispiel eines Buttons

59 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

60 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()); }

61 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 UI- System 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));

62 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.

63 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",

64 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.

65 KAPITEL 5. DEMOS 64 Abbildung 5.2: Demo 1 Screenshots

66 KAPITEL 5. DEMOS 65 Abbildung 5.3: Demo 2 Screenshots

67 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

68 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.

69 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

70 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

71 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.

72 KAPITEL 7. FAZIT 71 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 Impem. Komponente Implem. Labels Ja Spinners Ja Images Ja Pannels Ja Buttons Ja Dialogs Ja CheckBoxes Ja Registers Ja RadioButtons Nein ScrollPanes Nein ScrollBars Nein Menus Nein Slider Ja Toolbars Nein ProgressBars Nein Tables Nein ChooseLists Nein Trees Nein ComboBoxes Nein Textfields 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

73 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

74 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.

75 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

76 ANHANG A. WEITERE SPIELANALYSEN 75 A.1 Actionrollenspiel: Sacred In Sacred übernimmt der Spieler eine Heldenfigur in einer Fantasiewelt. Er besiegt Monster, erforscht die Spielwelt und sammelt Erfahrung und Gegenstände. Das Hauptziel ist die Entwicklung des Charakters und die Erforschung der Name Sacred Genre Actionrollenspiel Entwickler Take Two Interactive Publisher Ascaron Erschienen 2004 Homepage 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

77 ANHANG A. WEITERE SPIELANALYSEN 76 Komponente Vorhanden Bemerkung Tooltips Ja verzögerungsfrei Hotkeys Ja Focus Nein Drag and Drop Ja innerhalb des Spieles Cut and Paste Nein Undo/Redo Nein Layout Manager Nein Look and Feel Ja eigenes Look and Feel 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

78 ANHANG A. WEITERE SPIELANALYSEN 77 Komponente Vorhanden Bemerkung Labels Ja Images Ja Buttons Ja ToggleButtons Nein CheckBoxes Ja RadioButtons Ja ScrollBars Ja Slider Ja ProgressBars Ja ChooseLists Ja ComboBoxes Ja Spinners Nein Pannels Ja Windows Nein Dialogs Ja einfach Registers Ja horizontal + vertikal ScrollPanes Ja Menus Nein Kontextmenus Nein Toolbars Ja besondere, DnD aktiv Tables Ja nicht editierbar Trees Nein Text Ja StyledText Nein Tabelle A.2: Komponenten in Sacred

79 ANHANG A. WEITERE SPIELANALYSEN 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.

80 ANHANG A. WEITERE SPIELANALYSEN 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.

81 ANHANG A. WEITERE SPIELANALYSEN 80 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.

82 ANHANG A. WEITERE SPIELANALYSEN 81 A.2 Aufbausimulation: Die Siedler 5 Das Spiel Die Siedler - Das Erbe der Könige ist der fünfte Teil der Serie. Wie in den Vorgängern geht es darum eine Stadt aufzubauen und die Siedler in dieser Stadt arbeiten und leben zu lassen. Der Actionteil ist dabei sehr viel weniger ausgeprägt als in den meisten Name Die Siedler 5 Genre Aufbausimulation Entwickler Blue Byte Publisher Ubisoft Erschienen 2004 Homepage 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.

83 ANHANG A. WEITERE SPIELANALYSEN 82 Komponente Vorhanden Bemerkung Tooltips Ja an vorgegebenen Positionen Hotkeys Ja 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 A.3: Features in Siedler 5 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 Nein Pannels Ja Windows Nein Dialogs Ja sehr einfach Registers Ja ScrollPanes Ja Menus Nein Kontextmenus Nein Toolbars Ja vielfältig Tables Nein Trees Nein Text Ja StyledText Nein Tabelle A.4: Komponenten in Siedler 5

84 ANHANG A. WEITERE SPIELANALYSEN 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.

85 ANHANG A. WEITERE SPIELANALYSEN 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.

86 ANHANG A. WEITERE SPIELANALYSEN 85 A.3 Rundenstrategie: Master of Orion 3 Name Master of Orion 3 Genre Rundenstrategie Entwickler Quicksilver Publisher Infogrames Erschienen 2002 Homepage moo3.quicksilver.com Der Spieler spielt in Master of Orion 3 gegen einen oder mehrere Gegner und muss versuchen seinem Volk zur Herrschaft über das Universum zu verhelfen. Er lenkt dabei die Geschickte seiner Leute aus einer 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

87 ANHANG A. WEITERE SPIELANALYSEN 86 Komponente Vorhanden Bemerkung Tooltips Nein Hotkeys Ja vereinzelt Focus Ja einfach Drag and Drop Nein Cut and Paste Nein Undo/Redo Nein Layout Manager Nein Look and Feel Ja eigenes Look and Feel 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.

88 ANHANG A. WEITERE SPIELANALYSEN 87 Komponente Vorhanden Bemerkung Labels Ja Images Ja Buttons Ja ToggleButtons Nein CheckBoxes Ja RadioButtons Ja ScrollBars Ja Slider Ja ProgressBars Nein ChooseLists Ja ComboBoxes Ja Spinners Ja sehr vielfältig und spezielle Pannels Ja Windows Nein Dialogs Ja sehr einfach Registers Ja sehr vielfältig ScrollPanes Ja Menus Ja keine Untermenus Kontextmenus Nein Toolbars Nein Tables Ja kein editieren, vielfältig Trees Ja sehr einfach, nur Text Text Ja StyledText Ja einfaches HTML Tabelle A.6: Komponenten in Master of Orion 3

89 ANHANG A. WEITERE SPIELANALYSEN 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.