User Experience in Tastaturgesteuerten Text-Adventures

Bachelor esis
User Experience in tastaturgesteuerten Text-Adventures
Alexander Kluge (s0518665)

Internationaler Studiengang Medieninformatik
Fachbereich 4, Wirtschaswissenschaen II
Hochschule für Technik und Wirtscha, Berlin
Wissenschaliche Betreuung
Erster Betreuer: Prof. omas Bremer
Zweiter Betreuer: Prof. Dr.-Ing. Carsten Busch
Abschlussarbeit zur Erlangung des akademischen Grades

»Bachelor of Science«
© 2010 Alexander Kluge
Eingereicht am 07.10.2010, Berlin
1
Bachelor esis
User Experience in tastaturgesteuerten Text-Adventures
Abstract: Diese Arbeit untersucht die Nutzerfahrung (User Experience) und

Gebrauchstauglichkeit (Usability) in tastaturgesteuerten Text-Adventures in
der Umgebung von modernen Web-Browsern. Unter der Nutzung aktueller
Web-Technologien wird zur besseren Anschauung ein Text-Adventure in
Zusammenarbeit mit Tommy Krüger und seiner esis »Konzeption und
Untersuchung von text-gesteuerten Adventuregames« prototypisch in Teilen
umgesetzt. Der Schwerpunkt der esis liegt auf der Konzeption des Prototypen.
2
»Before the first person shooter
there was the second person thinker.«
– Jason Scott [Sco 10]
3
Danksagung
Ich möchte mich an dieser Stelle bei Tommy Krüger bedanken, der mit mir während der
Entwicklungszeit viele kreative Stunden und Tage verbrachte. Weiterhin soll den Testpersonen, die
so eifrig und manchmal auch geduldig die Tests über sich ergehen ließen, gedankt werden – auch
wenn sie erst später erfuhren, dass es sich um einen Test und kein normales »Wie findest du das?«
handelte. »Sorry, es war wichtig!«
Ich danke meiner Familie und meinen Freunden für die Unterstützung, vor allem für die Ratschläge
und die stets gut gemeinten Ablenkungsmanöver.
Außerdem soll der gesunden Ernährung und dem mindestens einmal wöchentlich stattfindenden
Fußball gedankt werden – ohne Beides wäre meine Nerven völlig durchgebrannt. Auch sei den
vielen Filmen, der Filmmusik und Musik im Allgemeinen gedankt, die ich im Laufe der
Entwicklung konsumiert habe. Sie half mir, Inspiration zu finden, um vor allem das Drehbuch zu
schreiben.
4
Hinweis
Fachbegriffe und Eigennamen werden beim ersten Aureten kursiv, danach normal gesetzt.
Wichtige Begriffe werden zur besseren Unterscheidbarkeit kursiv oder fett gesetzt. Explizit gemeinte
Begriffe, Zitate und wörtliche Rede werden in französischen Anführungszeichen »« gehalten.
5
Inhaltsverzeichnis
Inhaltsverzeichnis...............................................6
Abbildungsverzeichnis...........................................10
Tabellenverzeichnis.............................................12
Vorwort.........................................................13
1. Einführung...................................................14
1.1. Einleitung...............................................15
1.2. Motivation...............................................16
1.2.1.Herausforderungen....................................16
1.3. Ziel.....................................................17
1.4. Grenzen des Prototypen...................................17
1.5. Kompetenzverteilung......................................17
1.6. Anhang...................................................18
1.7. Herangehensweise.........................................18
2. Was ist User Experience?.....................................20
2.1. Erstes Verständnis.......................................21
2.2. User-Centered Design.....................................22
2.3. Universal Usability......................................22
2.3.1.Klassische Usability.................................22
2.3.2.Accessibility........................................23
2.3.3.Universal Usability..................................23
2.3.4.Universal Design.....................................24
2.4. User Experience..........................................25
2.5. Adventure................................................29
2.5.1.Text-Adventure.......................................30
2.5.2.Interactive Fiction..................................30
3. Ideenfindung.................................................31
3.2. Ideenverschmelzung.......................................32
4. Analyse......................................................33
4.2. Projektmanagement........................................37
4.2.1.Tools................................................37
4.2.2.Zeit und Ressourcen..................................37
6
4.2.3.Iterativer Entwicklungszyklus........................38
4.2.4.Alternative Entwicklungsprozesse.....................38
4.3. Marktsituation...........................................39
4.3.1.Spiele-Auswahl.......................................39
4.3.2.Zielgruppe...........................................43
4.3.3.Typische Merkmale....................................43
4.3.4.Alleinstellungsmerkmale von Ambernstein..............45
4.3.5.SWOT-Analyse von Ambernstein.........................46
4.4. Wahl der Technologie.....................................46
4.4.1.Vorteile nativer Browser-Technologien................47
4.4.2.Nachteile nativer Browser-Technologien...............48
4.4.3.Status Quo – Stand der Technik.......................48
4.4.4.Alternativen.........................................49
4.5. Strategie................................................49
4.5.1.Definition der Anwendung.............................49
4.6. Anforderungen............................................49
4.6.1.Inhaltlich...........................................50
4.6.2.Funktional...........................................50
4.6.3.Technisch............................................53
4.7. Angestrebte Funktionen...................................53
4.7.1.Kernfunktionen.......................................53
4.7.2.Außerordentliche Funktionen..........................53
4.8. Fazit....................................................54
5. Konzept......................................................55
5.1.1.Sieben Schritte......................................56
5.2. Storytelling.............................................57
5.2.1.UX und Storytelling..................................57
5.2.2.Analogie zu Film und Buch............................58
5.2.3.Drehbuch.............................................60
5.2.4.Charaktere...........................................61
5.2.5.Soundtrack...........................................62
5.3. Abstrakte Struktur.......................................63
5.3.1.Informationsarchitektur..............................63
5.3.2.Interaktionsdesign...................................67
7
5.4. Konkrete Struktur........................................69
5.4.1.Interface Design.....................................69
5.4.2.Navigationsdesign....................................79
5.4.3.Informationsdesign...................................81
5.4.4.Wireframes...........................................82
5.5. Spieldesign..............................................83
5.5.1.Elemente.............................................84
5.5.2.Ein Spiel wie ein Film...............................86
5.5.3.Kurzbeschreibung von Ambernstein.....................86
5.5.4.Spielkonzept.........................................86
5.5.5.Spielvorhaben........................................86
6. Umsetzung....................................................88
6.1.1.Entwickler und Nutzer................................87
6.2. Drehbuch.................................................87
6.2.1.Erster Akt...........................................91
6.2.2.Zweiter Akt..........................................92
6.2.3.Dritter Akt..........................................92
6.3. Webseite.................................................92
6.3.1.Technisch............................................92
6.3.2.Visuelles Design.....................................94
6.4. Spiel....................................................96
6.4.1.Technisch............................................96
6.4.2.Visuelles Design.....................................96
6.5. Angewandte Datenstruktur.................................98
6.6. Eingesetzte Software.....................................99
6.7. Nicht umgesetzte Funktionen..............................99
6.8. Probleme und Herausforderungen..........................100
6.8.1.Lösungen für das Neuladen der Webseite..............100
6.8.2.Lösungen für deaktiviertes JavaScript...............101
7. Test.........................................................102
7.1. Herangehensweise........................................103
7.2. Testauswahl.............................................103
7.2.1.Browser-Tests.......................................103
7.2.2.Usability-Tests.....................................104
8
7.2.3.Benutzerbefragung...................................105
7.2.4.»Quick-Experience«..................................105
7.2.5.Forschungsbasierte Richtlinien......................105
7.2.6.Best Practices......................................105
7.2.7.Heuristiken.........................................106
7.3. Durchführung............................................107
7.3.1.Card-Sorting........................................107
7.3.2.Card-Sorting #2.....................................108
7.3.3.Web Usability.......................................108
7.3.4.Game Usability......................................113
8. Konklusion..................................................114
Nachwort.......................................................117
Glossar........................................................118
Literaturverzeichnis...........................................119
Kolophon.......................................................123
Anhang.........................................................124
I. Ambernstein – Die Vision...................................125
II. Technische Anforderungen an die UX.........................136
III.Sitemap (IA und IxD).......................................144
IV. Game Concept...............................................145
V. Game Proposal..............................................148
VI. Soundtrack.................................................150
VII.Style Guide................................................151
VIII.Drehbuch, inkl. Kurztreatment.............................152
IX. Ergebnisse der Usability-Tests.............................201
X. Anleitung zur Ausführung des Prototypen....................209
XI. Quellcode..................................................210
Eigenständigkeitserklärung.....................................230
9
Abbildungsverzeichnis
Abb. 1 – Die genormte Sicht auf Usability und User Experience.................21
Abb. 2 – Die Disziplinen der UX...............................................25
Abb. 3 – Die UX-Honigwabe.....................................................26
Abb. 4 – UX-Modell............................................................26
Abb. 5 – Die wesentlichen Elemente des Experience Design (Auszug).............27
Abb. 6 – Die UX-Hierarchie der Nutzerbedürfnisse (Auszug).....................27
Abb. 7 – Verarbeitung der UX durchs Gehirn....................................28
Abb. 8 – Die Wichtigkeit von UX...............................................29
Abb. 9 – Entwicklungsprozess für UX (UPA).....................................34
Abb. 10 – Usability als Schritt-Schritt-Anleitung.............................35
Abb. 11 – Elemente der UX (Auszug)............................................36
Abb. 12 – Zeitplan............................................................37
Abb. 13 – Iterative Entwicklungssequenz.......................................38
Abb. 14 – Colossal Cave per Java-Applet.......................................43
Abb. 15 – Zork 1 per Java-Applet..............................................43
Abb. 16 – Zork 1 per JavaScript...............................................44
Abb. 17 – Slouching Towards Bedlam............................................44
Abb. 18 – Stone Age Sam per Flash.............................................44
Abb. 19 – Typer Shark per Flash...............................................44
Abb. 20 – Blue Lacuna (Exzerpt) im Browser....................................45
Abb. 21 – Die sieben Handlungsschritte eines Nutzers nach Norman..............57
Abb. 22 – Greifbare UX-Elemente in Film und Webseite..........................59
Abb. 23 – Experience Theme....................................................60
Abb. 24 – Drei-Akt-Struktur eines Films.......................................60
Abb. 25 – Spannungsverlauf eines Films........................................61
Abb. 26 – Kreise der IA/UX....................................................63
Abb. 27 – Hierarchische Informationsstruktur..................................65
Abb. 28 – Sequenzielle und organische Informationsstruktur....................65
Abb. 29 – Ausbau einer hierarchischen Struktur................................65
Abb. 30 – Task Flow eines frühen Wireframes...................................68
Abb. 31 – Frühe Übersicht der UI-Elemente – teilweise mit Funktionsabläufen...69
Abb. 32 – Frühes Wireframe des Web UI Layouts.................................71
Abb. 33 – Web UI mit Footer als Funktionseinheit..............................71
Abb. 34 – Erwartung der Nutzer über den Ort der internen Navigation...........72
Abb. 35 – Erwartung der Nutzer über den Ort weiterer Navigationselemente......72
Abb. 36 – Web UI Elemente.....................................................74
Abb. 37 – Game UI.............................................................75
Abb. 38 – Farbpalette »Accessible«............................................76
10
Abb. 39 – Zweite Farbpalette »Accessible«.....................................76
Abb. 40 – Farbpalette eines Zeitungsartikels..................................76
Abb. 41 – Finale Farbpalette für den Web-Modus................................77
Abb. 42 – Finale Farbpalette für den Spiel-Modus..............................77
Abb. 43 – Elemente des Spiel-Modus............................................78
Abb. 44 – Anordnung der Erklärung zur Steuerung im Spiel-Modus................79
Abb. 45 – Navigationssysteme..................................................80
Abb. 46 – Navigationssysteme am Beispiel von IBM..............................81
Abb. 47 – Frühes Wireframe des Web-Modus......................................82
Abb. 48 – Frühes Wireframe des Spiel-Modus....................................82
Abb. 49 – Konzeptionelles Wireframe des Spiels-Modus..........................83
Abb. 50 – Etappen der Akte auf Zetteln........................................89
Abb. 51 – Strukturmodell des Drehbuchs nach Syd Field.........................90
Abb. 52 – Verlauf der Story in sechs Etappen..................................90
Abb. 53 – Pfad des ersten Akts (Ausschnitt)...................................53
Abb. 54 – Visuelles Design der Webseite.......................................94
Abb. 55 – Die Gestalt-Prinzipien der Nähe, Ähnlichkeit und Kontinuität........95
Abb. 56 – Das Gestalt-Prinzip der »uniformen Verbundenheit«...................96
Abb. 57 – Visuelles Design des Spiels.........................................97
Abb. 58 – Visuelle Verbindung von Game UI und Web UI..........................97
Abb. 59 – Farbpalette »Gentle Waves«..........................................98
Abb. 60 – Visueller Fortschritt im Footer.....................................98
Abb. 61 – Datenstruktur.......................................................99
Abb. 62 – Webseite für Testperson #1.........................................109
Abb. 63 – Webseite für Testperson #2, #3 und #4..............................110
Abb. 64 – Anpassung der Webseite mit Feedback von Testperson #1..............111
Abb. 65 – Anpassung #2 der Webseite mit Feedback von Testperson #1...........112
Abb. 66 – Finale Anpassung der Webseite mit Feedback von Testperson #1.......112
11
Tabellenverzeichnis
Tab. 1 – Kompetenzverteilung..................................................18
Tab. 2 – Colossal Cave und Zork 1 im Vergleich................................41
Tab. 3 – Slouching Towards Bedlam und Blue Lacuna im Vergleich................42
Tab. 4 – Stärken und Schwächen von Ambernstein................................46
Tab. 5 – Chance und Gefahren für Ambernstein..................................46
Tab. 6 – Mythische Muster in Filmen (Matrix, Star Wars).......................58
Tab. 7 – Lösungen für deaktiviertes JavaScript...............................101
Tab. 8 – Heuristiken für Game Usability (Auswahl)............................107
Tab. 9 – Ergebnisse des Usability-Tests......................................107
Tab. 10 – Ergebnisse des Card-Sorting........................................108
12
Vorwort
Nie hätte ich gedacht, dass ich jemals ein Spiel selbst schreiben würde. Es fing alles relativ harmlos
mit einem Artikel aus dem GEE-Magazin [Nee 10a] an, der Tommy Krüger und mich von der Idee
überzeugte, ein kleines eigenes Text-Adventures namens Ambernstein zu schreiben.
Vergleicht man die Idee und Umsetzung von Ambernstein mit einer Pflanze, dann könnte man
sagen, dass mit der Abgabe dieser esis die Pflanze gerade dabei ist, zu entstehen. Gute
Voraussetzungen sind mit der Arbeit von Tommy Krüger und mir gegeben und müssen nun noch
adäquat umgesetzt werden. Die vorliegende Arbeit soll den Entwicklungsprozess des Spiels
beschreiben und die Vorstellungen, die dahinterstecken, erläutern.
Ein Text-Adventure ist trotz seiner Reduktion auf Text als primäres Medium nicht weniger ein
vollwertiges Spiel. Ich habe den Eindruck, der Aufwand für eine story-orientierte und interaktive
Erzählung in Spielform wird gerne belächelt und unterschätzt.
Die esis soll u.a. das Gegenteil beweisen und plausibel darlegen.
13
1
Einführung
Warum ich diese Thesis schreibe.
14
1 Einführung
1.1 Einleitung
Die Spiele der letzten zehn Jahre haben Vieles gemeinsam: Sie werden am PC überwiegend von
Maus und Tastatur gesteuert, an der Spielkonsole per Gamepad oder – wie Nintendo zeigt – auch
per Gestensteuerung mit Hilfe einer per Infrarot und Bluetooth betriebenen Fernbedienung. Spiele-
und Konsolenhersteller 1 setzen dabei im großen Stil auf imposante Grafik, die den Eindruck
vermitteln soll, man sei wirklich dabei. Wie bei Kinofilmen von heute 2 täuschen diese optischen
(und auch akustischen) Eindrücke 3 o über teilweise schwachbrüstige Geschichten und Inhalte
hinweg. [Kos 05, S.176] Aktuelle Spiele wie Heavy Rain 4 (2010) oder auch etwas betagtere Titel wie
Fahrenheit 5 (2005) beweisen, dass die Story für Spiele, die nachhaltig wirken wollen, wichtig ist.
Dabei liegt das Erzählen von Geschichten dem Menschen so nahe. Seit mehreren Jahrhunderten
dient es als Mittel der Unterhaltung. [She 04, S.3] Eine ganz besondere Stellung nehmen dabei Text-
Adventures ein. Durch Text präsentiert wie ein Buch und interaktiv wie ein Spiel, spricht man auch
von einem gespielten Buch. In den 1970er und 1980er Jahren noch populär, erleben sie heutzutage
eine Wiederauferstehung durch das Internet 6 – zum Herunterladen auf den Desktop oder als
Online-Browser-Spiel. Letzteres soll vor allem in dieser esis von Belang sein.
Auch wenn insgesamt das Angebot an (browser-basierten 7 ) Text-Adventures 8 vergleichbar klein ist,
sind sie nach wie vor gefragt 9 und beliebt. Das zeigt die weltweite Entwicklung von Interactive
Fiction (IF) vor allem in den USA, sowie entsprechende Wettbewerbe 10 .
Darüber hinaus lassen individuelle Initiativen beispielsweise von Martin Kool 11 das Herz eines
jeden Nostalgikers höher schlagen.
1 Nintendo sei hier ausgeschlossen

2 Der Trend zum 3D-Kino
3»Im Rausch der Töne und der Bilder sind diese Spiele allerdings mittlerweile untergegangen.« – http://
www.textfire.de/index.htm 04.10.2010
4 http://www.spiegel.de/netzwelt/games/0,1518,680010,00.html, 13.09.2010
5 http://www.spiegel.de/netzwelt/web/0,1518,374336,00.html, 13.09.2010
6 http://www.ehow.com/list_5801287_games-using-keyboard.html, 13.09.2010
7 http://www.google.com/Top/Games/Video_Games/Adventure/Browser_Based/, 13.09.2010
8 http://www.google.com/Top/Games/Video_Games/Adventure/Text_Adventures/, 13.09.2010
9 http://www.gamersglobal.de/meinung/neue-textadventures-bitte, 13.09.2010
10 Der »XYZZY-Award« und die »Interactive Fiction Competition«
11 http://sarien.net, 13.09.2010
15
1 Einführung
Im Rahmen dieser Arbeit soll mit modernen Web-Technologien ein Prototyp für ein eigenes Text-
Adventure erstellt werden. Da es in diesem Genre üblich ist, liegt der Schwerpunkt auf der erzählten
Geschichte.
1.2 Motivation
Die dem Verfasser zu Grunde liegende Motivation rührt vor allem aus dem Interesse an textbasierter
Arbeit 12 und den mit der Zielsetzung verbundenen Herausforderungen.
1.2.1 Herausforderungen
Die sich aus der Erstellung des Spiels ergebenen Herausforderungen sind technologischer,
anatomischer, inhaltlicher und moralischer Natur.
Das Spiel ist technologisch herausfordernd, weil der zu verwendende HTML-Standard HTML5
noch immer recht neu ist und die finalen Spezifikationen des World Wide Web Consortium (W3C)
bzw. der Web Hypertext Application Technology Working Group (WHATWG) noch nicht fertig
sind. Die Frage ist also: Was ist mit aktuellen Browsern und HTML5 jetzt schon möglich 13 , wenn
der HTML-Standard erst 2022 [Krö 10, S.29] bzw. 2012 [Kei 10, S. 7] fertig und abgeschlossen sein
soll? Neben HTML5 werden CSS3 und jQuery für das Aussehen und Verhalten des Spiels verwendet.
Es ist eine anatomische Herausforderung, weil der Autor noch nie selbst ein Spiel erstellt oder daran
mitgewirkt hat. Das Schaffen eines Spiel-Erlebnisses – wenn auch prototypisch-experimentell – ist
absolutes Neuland, deswegen auch umso spannender.
Inhaltlich ist es herausfordernd, weil ein Drehbuch für das Spiel zum ersten Mal verfasst wird. Auch
das selbst gewählte ema dieser Arbeit ist inhaltlich interessant, wurden die Grundlagen doch in
bestimmten Kursen des Studiums gelegt: »Medien- und Wahrnehmungstheorie«, »Grundlagen
interaktiver Medien«, der Kurs »Usability« und »Mensch-Computer-Interaktion«. Im Wesentlichen
bilden diese Kurse die theoretische Grundlage zur Wahl dieses emas und den Enthusiasmus zur
Verfassung dieser Arbeit.
Auch moralisch gesehen ist das Spiel eine Herausforderung, weil zugängliche Webseiten – im Sinne
der Accessibility – nicht zwangsläufig auch gebrauchstauglich sind – im Sinne der Usability. [Hor 05,
12 Web Development und Copywriting

13 http://html5gallery.com/ – http://www.chromeexperiments.com/ 05.10.2010
16
1 Einführung
Preface] Ebenso generieren gebrauchstaugliche Webseiten nicht automatisch eine gute

Nutzererfahrung – im Sinne der User Experience (UX). Es gilt im Rahmen dieser Arbeit, o.g.
Herausforderungen konzeptionelle Lösungsansätze entgegenzubringen.
1.3 Ziel
Ziel dieser Arbeit ist, ein Proof of Concept 14 für ein rein tastaturgesteuertes Text-Adventure (IF) im
Stil der 1970er und 1980er Jahre zu erstellen, das technisch auf HTML5, CSS3 und JavaScript
basiert, besonderen Wert auf Usability und Accessibility legt und nur online im Browser gespielt
wird. Dieses beinhaltet auch die Entwicklung eines ersten explorativen Prototypen. [Ber 09, S. 541
und Flo 84, S.6]
Ziel ist es nicht, den in dieser esis gestellten Anforderungen im Prototypen gerecht zu werden. Sie
stellen Idealvorstellungen dar, die für eine marktreife Web-Anwendung verbindlich sein sollten. Ziel
ist es hingegen, Ansätze der dargelegten Anforderungen zu erfüllen und annäherungsweise
umzusetzen.
1.4 Grenzen des Prototypen

Im Rahmen dieser esis wird kein Anspruch auf Vollständigkeit erhoben. Bei der beschriebenen
Umsetzung handelt es sich um Teil-Implementierungen. Die esis behandelt die UX von rein
tastaturgesteuerten Text-Adventures in Browsern. Dabei wird anhand der aus der Literatur
gewonnenen Erkenntnisse ein User Interface (UI) unter Berücksichtigung von Gesichtspunkten der
UX und Universal Usability prototypisch implementiert. Mit Browser-Spielen sind im Rahmen
dieser Arbeit explizit für den Browser konzipierte Spiele gemeint – also keine Portierungen oder
Einbettungen in den Browser.
1.5 Kompetenzverteilung
Das Spiel entstand in Zusammenarbeit mit Tommy Krüger. Dessen esis bezieht sich auf die
Konzeption und Untersuchung von Text-Adventures. Der Autor dieser esis sieht die UX als einen
integralen Bestandteil bei der Spielkonzeption.
14 engl. Machbarkeitsstudie
17
1 Einführung
Tommy Krüger kümmerte sich im Wesentlichen um die technische Implementierung – die

Funktionalität. Der Autor dieser Arbeit war im Wesentlichen für das User-Centered Design (UCD)
zuständig – also das Erlebnis des Spiels Ambernstein 15 zu erschaffen.
In der folgenden Tabelle 1 sind die einzelnen Kompetenzen aufgelistet:
Tommy Krüger Alexander Kluge
Ideenfindung und Spielentwurf
Entwicklung der Grundstory und Mini-Spiele
Designdokument UI und UX Design
Technisches Designdokument Universal Usability
Implementierung des Spiels als Prototyp Visual Identity und Style Guide
Implementierung der Mini-Spiele als Prototypen Game Proposal und Game Concept
Story (Drehbuch, Figuren, Dramatik, Soundtrack)
Tab. 1, Kompetenzverteilung
Das Game Proposal und Game Concept dienten als Vorarbeit für das Designdokument. Bei der
Visual Identity kam es darauf an, Ambernstein als Marke darzustellen.
1.6 Anhang
Im Anhang dieser Arbeit befinden sich ergänzende Dokumente, die für eine Implementierung des
Spiels herangezogen werden können. Zusätzlich ist dieser Arbeit eine CD »Ambernstein« mit allen
Quelldateien, Implementierungen, Grafiken und Dokumenten beigefügt.
1.7 Herangehensweise
Die esis ist in acht Inhaltsbereiche aufgeteilt:
• Einführung
• Was ist User Experience?
• Ideenfindung
• Analyse
• Konzept
15 http://ambernstein.com 05.10.2010
18
1 Einführung
• Umsetzung
• Test
• Konklusion
Der Schwerpunkt liegt auf den vier Teilen Analyse, Konzept, Umsetzung und Test:
In der Analyse werden die aktuellen Text-Adventures untersucht und die Fähigkeiten von nativen
Browser-Technologien abgewägt. Im zweiten Teil wird auf theoretischer Basis ein explorativer
Prototyp auf Grundlage der in der Analyse gewonnenen Erkenntnissee entworfen. Im dritten Teil
werden die praktischen Ergebnisse aus der Implementierung des zuvor theoretisch beschriebenen
Prototypen erläutert. Außerdem wird gezeigt, als wie praxistauglich er sich erweist.
Die Tests des vierten Teils erfolgten – wenn möglich – unter Einbeziehung von Testpersonen der
entsprechenden Zielgruppe. Außerdem wurden forschungs- und studienbasierte Ergebnisse aus
einschlägiger Literatur zu Rate gezogen.
Alle vier Teile wurden iterativ vollzogen, d.h. während der Entwicklung änderten sich teilweise die
Anforderungen, recht o die Entwürfe und auch der Prototyp selbst.
Das begleitende Projekt Ambernstein wurde in Zusammenarbeit mit Tommy Krüger durchgeführt.
Auf Grund unterschiedlicher Schwerpunkte in der praktischen und theoretischen Arbeit ergaben
sich bei den Projektpartnern teilweise verschiedene Konzeptions- und Entwicklungszyklen.
Hinweis: Da diese esis nur einen Teil des begleitenden Projekts widerspiegelt, bittet der Autor den
geneigten Leser, ergänzende und vertiefende Inhalte der Abschlussarbeit »Konzeption und
Untersuchung von text-gesteuerten Adventuregames« von Tommy Krüger zu entnehmen.
19
2
Was ist User
Experience?
Komplexität von UX.
20
2 Was ist User Experience?
2.1 Erstes Verständnis

Vorweg sei gesagt, dass sich alle in dieser Arbeit genannten Begrifflichkeiten auf den Kontext des
Web beziehen. Dem Autor ist bewusst, dass sich die UX als interdisziplinäres Feld auszeichnet,
indem neben Informatik, auch Aspekte der Psychologie, des Designs, der Kultur, des Marketing und
der Usability u.v.m. wichtig sind.
Grundlage jeglichen Verständnisses für UX ist die Fokussierung auf den Nutzer mit dem Ansatz des
UCD. [Usa o.J.] Ersten Aufschluss über eine Begriffsdefinition von UX liefert die internationale
Norm ISO 9241, die in Europa als EN ISO 9241 und in Deutschland als DIN EN ISO 9241
übernommen wurde und die »Ergonomie der Mensch-System-Interaktion« behandelt.
In deren Abschnitt 210 16 ist sie thematisiert. omas Geis [Gei 10] hat sich in Abbildung 1 der ISO-
Sicht angenommen und verdeutlicht den Bezug zur Usability.
Abb. 1, Die genormte Sicht auf Usability und User Experience
Usability ist demnach eine Teilmenge von UX und bedarf einer weiteren Klärung. In den folgenden
Abschnitten sollen außerdem die Bestandteile von UCD und Universal Usability beleuchtet werden.
Ferner soll auf die Komplexität von UX eingegangen werden.
16 ISO 9241-210: »Prozess zur Gestaltung gebrauchstauglicher interaktiver Systeme«
21
2.2 User-Centered Design

UCD wird teilweise als Synonym zu Usability und UX genannt [Hor 05, Preface], bedeutet aber
letztendlich, dass der Nutzer früh und o in den Entwicklungsprozess eingebunden wird. [Hor 05,
Introduction] Laut Patrick Lynch [Lyn 09, 2.2] beinhaltet UCD folgende nutzerorientierte
Methoden:
• Aufgaben-Analyse
• Fokus-Gruppen
• Nutzertests
Vor allem die Nutzertests dienen dazu, den Nutzer zu verstehen und die Entwürfe je nach Feedback
des Nutzers weiterzuentwickeln. Außerdem soll mit Hilfe von UCD die vom Nutzer gewünschte
Funktionalität bestimmt werden und die Art, wie er sie nutzen wird. Laut Lynch [Lyn 09, 2.2] und
Garrett [Gar 03, S.38] wird iterativ entworfen, getestet und weiterentwickelt.
Ganz anders kann UCD auch als ein Ansatz des Interaction Design gesehen werden, der neben dem
Activity-centered, Systems und Genius Design existiert. [Saf 07, S.30ff.]
2.3 Universal Usability

2.3.1 Klassische Usability
Eindeutige Definitionen für Usability sind nur schwer zu finden. Begriffe wie Bedienbarkeit,
Benutzbarkeit und Benutzerfreundlichkeit versuchen, dem Konstrukt Usability gerecht zu werden.
[Eic 99] Als hilfreich erweist sich erneut die ISO-Norm 9241. Deren eler Teil kümmert sich um die
»Anforderungen an die Gebrauchstauglichkeit«, welcher im englischen Original als »Guidance on
usability« bezeichnet ist. Usability meint also die Gebrauchstauglichkeit.
Gemäß ISO-Norm definiert sie sich als das »Ausmaß, in dem ein Produkt durch bestimmte Benutzer
in einem bestimmten Nutzungskontext genutzt werden kann, um bestimmte Ziele effektiv, effizient und
mit Zufriedenheit zu erreichen.«
Nach Steve Krug ist gute Usability dann gegeben, wenn man den Nutzer nicht denken lassen muss.
[Kru 06, S.10ff.] Er spielt dabei auf die selbst erklärende Funktionsweise einer Webseite an. [Lyn 09,
10.3] Jakob Nielsen sieht in Usability ein Qualitätsmerkmal [Nie 03], das aus fünf Komponenten
besteht: Learnability, Efficiency, Memorability, Errors und Satisfaction.
22
Learnability meint, wie einfach es dem Nutzer gelingt, einfache Aufgaben in einem bislang
unbekannten System zu lösen. Efficiency heißt, wie schnell der Nutzer Aufgaben in einem ihm
bereits bekannten System durchführt. Memorability bedeutet, wie einfach es dem Nutzer fällt nach
einer Zeit der Nichtnutzung, die zuvor gewonnenen Fertigkeiten wieder abzurufen. Errors sagt aus,
wie viele Fehler der Nutzer machen, wie schwerwiegend diese sind und wie einfach sie wieder
rückgängig gemacht werden können. Satisfaction gibt wieder, wie gerne der Nutzer das System
benutzt.
Lynch [Lyn 09, 2.2] sieht die Usability wie Nielsen die Usability als qualitativ. Für ihn ist es aber auch
ein Phänomen, das gemessen und in Zahlen ausgedrückt werden kann (quantitativ). Um eine gute
Usability zu erreichen, erweist sich besagtes UCD als die gängigste Methode.
2.3.2 Accessibility
Gemäß W3C geht es bei Accessibility (Zugänglichkeit) darum, Menschen mit Einschränkungen im
Hören, Bewegen, Sehen und der Kognition 17 die Möglichkeit zu geben, das Web wahrzunehmen, zu
verstehen, sowie darin navigieren und interagieren zu können. [Hen 05] Das Ideal ist dabei, das
Web für jeden Menschen – unabhängig von Hardware, Soware, Sprache, Kultur, Ort, körperlicher
und geistiger Fähigkeit – zugänglich zu machen. [Hen oJ]
Seitens der W3C gibt es eine spezielle Initiative zur Klärung von Gesichtspunkten der Accessibility –
die Web Accessibility Initiative 18 (WAI). Sie sind Sie hauptverantwortlich für die Web Content
Accessibility Guidelines (WCAG), die bereits als WCAG 2.0 in der zweiten Version veröffentlicht
wurden. Interessant im Rahmen dieser Arbeit ist auch die Accessible Rich Internet Application Suite 19
(WAI-ARIA), die sich um interaktive Web-Applikationen mit dynamischen Inhalten kümmert.
Laut Horton [Hor 05] ist man bei der Accessibility primär damit beschäigt, Inhalt und
Funktionalität zugänglich zu machen. Patrick Lynch [Lyn 09, 2.2] definiert sie als kritisches Element
der Universal Usability, die nachfolgend definiert wird.
2.3.3 Universal Usability

Universal Usability basiert genau wie »klassische« Usability auf dem weiten und einschließenden
Blick gen Nutzer [Lyn 09, 2.2], schließt aber Aspekte der Accessibility mit ein.
17 Im weitesten Sinne die Aufnahme, Verarbeitung und Speicherung von Informationen aus der Umwelt
18 http://www.w3.org/WAI/ 05.10.2010
19 http://www.w3.org/WAI/intro/aria 05.10.2010
23
Das heißt: Inhalte und Funktionen werden gebrauchstauglich – im Sinne der o.g. Definition – und
zugänglich gemacht.
Ben Shneiderman prägte den Begriff in Leonardo‘s Laptop (2002) als Mittel, um alle Bürger zu
befähigen, mit Kommunikations- und Informationstechnologie erfolgreich ihre Aufgaben
bewältigen zu können. Dabei sieht er Bürger als Nutzer mit neuen oder alten Computern,
langsamen oder schnellen Netzwerkverbindungen, kleinen oder großen Bildschirmen. Diese sind
jung und alt, Anfänger und Experten, eingeschränkt und uneingeschränkt. Es geht um diejenigen,
welche sich nach Bildung sehnen, eigene Unsicherheiten überwinden wollen und mit verschiedenen
Beschränkungen zurecht kommen müssen. [Shn 03b, S. 14f.]
Universal Usability...
...unterstützt eine breite Palette von Technologien.
...gefällt vielen verschiedenen Nutzern.
...baut eine Brücke zwischen dem was Nutzer wissen und was sie wissen müssen.
Nichtsdestotrotz ist Universal Usability laut Shneiderman eher einen Traum als eine wirklich
umsetzbare Strategie. [Shn 03b, S. 15] Horton schlussfolgert aus den drei Herausforderungen, dass
man drei Bereiche des Webdesigns besonders beachten muss: Funktion, Interface, Inhalt. [Hor 05,
Preface]
Der Vollständigkeit halber soll in diesem Zusammenhang auch der Begriff des Universal Design im
Folgenden erläutert werden.
2.3.4 Universal Design

»Universal Design« wurde vom US-amerikanischen Center for Universal Design and der North
Carolina State University’s College of Design entwickelt. Es besteht aus Prinzipien und Richtlinien,
von denen die folgenden Vier für die Web-Umgebung am besten anwendbar sind:
1. Equitable Use
2. Flexibility in Use
3. Simple and Intuitive Use
4. Perceptible Information
»Equitable Use« meint, dass das Design jedem Nutzer die gleichen Mittel zur Verfügung stellen
sollte. Mit »Flexibility« ist gemeint, dass die Auswahl an Möglichkeiten, das Design zu nutzen,
24
vielfältig sein sollte. Das dritte Prinzip spricht die einfach und intuitive Nutzung des Design an,
indem unnötige Elemente ausgeblendet werden. »Perceptible Information« umfasst Information, die
unterschiedliche wahrnehmbar ist. [LYN 09, 2.3] Die beiden letzten Prinzipien sind mit Norman‘s
Begriff der Affordances vergleichbar, der im späteren Verlauf dieser Arbeit definiert wird.
2.4 User Experience

Zuvor eher nach der ISO-Norm betrachtet, soll nun fernab der ISO-Sicht mit dem Wissen um die
grundsätzlichen Begriffe der UX die folgende Informationsgrafik 20 (Abbildung 2) zeigen, wie
umfangreich das Forschungs- und Arbeitsgebiet der UX bzw. end-user experience [KOS 05, S.160]
wirklich ist.
Abb. 2, Die Disziplinen der UX
20 http://www.kickerstudio.com/blog/2008/12/the-disciplines-of-user-experience/ 04.10.2010
25
Im Rahmen dieser esis wird im späteren Verlauf auf einzelne UX-Disziplinen von Abbildung 2
genauer eingegangen.
Abb. 3, Die UX-Honigwabe Abb. 4, UX-Modell
Um die UX auch qualitativ zu erfassen, eignet sich das Modell von Peter Morville [Mor 04] und
Peter Dobr 21 – siehe Abbildung 3 und 4. Letztere sind vor allem auch dafür geeignet, um die
Verbindung von UX und Usability zu verstehen. Hier herrscht teilweise noch Unklarheit. 22
Eine positive UX ist laut Wabenmodell dann generiert, wenn das benutzte System einen besonderen
Wert für den Benutzer hat - es also valuable ist. Dies ist laut Morville dann gegeben, wenn es
zielgruppenrelevant (useful), gebrauchstauglich (usable), gut auffindbar (z.B. IA), glaubha (z.B.
Social Design, Stanford Guidelines for Web Credibility 23 ), zugänglich (Accessibility) sowie
begehrenswert (z.B. Marke, Image, Identität) ist. Eine vereinfachte Version von Abbildung 3 ist im
Konzeptteil dieser esis als Abbildung 26 zu finden. Sie bezieht sich auch auf die
Informationsarchitektur (IA).
Stephen P. Anderson [AND 09] beschreibt das (User) Experience Design, indem er sagt, dass sich
Alles um Menschen, ihre Aktivitäten und den Kontext ihrer Aktivitäten dreht – siehe Abbildung 5.
21 http://upload.wikimedia.org/wikipedia/de/9/90/User-experience.svg 30.09.2010
22 http://blog.procontext.com/2010/03/usability-und-user-experience-unterscheiden.html – http://
www.uxbooth.com/resources/mark-boulton-on-defining-ux/ – http://www.usabilitynews.com/news/
article4636.asp – http://www.cs.tut.fi/ihte/CHI08_workshop/papers/Bevan_UXEM_CHI08_06April08.pdf
04.10.2010
23 http://credibility.stanford.edu/guidelines/index.html 04.10.2010
26
Abb. 5, Die wesentlichen Elemente des Experience Design (Auszug)
Fasst man UX allgemein zusammen, ist es das Nutzungserlebnis, das auch Freude und Spaß bereiten
soll. Man geht dabei weg vom rein funktionalen (aufgaben-orientierten) Denken zum
Erfahrungserlebnis. Die folgende Informationsgrafik (Abbildung 6) von Anderson zeigt dies sehr
deutlich:
Abb. 6, Die UX-Hierarchie der Nutzerbedürfnisse (Auszug) 24
24 http://www.poetpainter.com/thoughts/article/a-user-experience-hierarchy-of-needs 04.10.2010
27
Das Verarbeiten dieser Erfahrung geschieht nach Norman [Nor 04, S.64ff.] im Menschen dabei auf
drei emotionalen Ebenen (Abbildung 7 [Inc 10a]): Visceral, Behavorial, Reflective.
Abb. 7, Verarbeitung der UX durchs Gehirn
Visceral meint das was vor der bewussten Wahrnehmung stattfindet. Es geht um ersten Eindruck,
die erste Erscheinung, sowie das erste Look and Feel des Produkts.
Behavioral umfasst die Nutzung und das Erlebnis mit dem Produkt, wobei Letzteres die Funktion,
Performance und Usability beinhaltet.
Reflective steht dafür, dass die Auswirkungen von Gedanken und Gefühlen nun bewusst
interpretiert werden. Die Verarbeitung auf diesem Level passiert vor allem auch nach dem
eigentlichen Benutzen – es ist nicht an die jetzige Benutzung gekoppelt. Vielmehr entwickelt es sich
durch die Erinnerung an die Vergangenheit und die Betrachtung der Zukun. [Nor 04, S.36ff.]
Die Folgen positiver und negativer Ausführung von UX wird in dem Poster (Abbildung 8) von
Experience Dynamics [Spi 06] gut dargestellt. Positive UX in Spielen ist eng verbunden mit Spaß, der
laut Koster [KOS 05, S.46], nur ein anderes Wort für Lernen ist.
Inwiefern das die esis begleitende Spiel Spaß und Lernen kombiniert, soll in der nachfolgenden
Definition von »Adventure« gezeigt werden.
28
Abb. 8, Die Wichtigkeit von UX
2.5 Adventure
Da es auch beim Begriff des Adventures viele Varianten gibt, soll an dieser Stelle relative Klarheit
darüber gebracht werden.
Definition #1
Eine erste Definition eines Adventures sieht es als interaktive Geschichte über eine Figur, die von
einem Spieler kontrolliert wird. [Rol 06, S.546] Die Figur besucht ein erforschbares Gebiet, das eine
29
Vielzahl von Puzzles und zu lösenden Problemen beinhaltet. [Rol 06, S.549] Eher selten sieht sich
die Figur mit physischen Herausforderungen konfrontiert. [Rol 06, S.71]
Definition #2
Der zweite Versuch sieht ein Adventure als deterministisches 25 und intellektuelles Problemlösen im
Rahmen einer Geschichte. [Tan 08]
Zusammenfassung
Gemeinsam haben beide Definitionen, dass es im Kontext einer Story gilt, Probleme (Puzzles) zu
lösen. Implizit haben beide Wortlaute auch gemeinsam, dass auf die körperliche
Auseinandersetzung des Protagonisten verzichtet wird.
2.5.1 Text-Adventure
Ein Text-Adventure beinhaltet alle Elemente eines Adventures, nur keine grafische Ausgabe. Text ist
das UI 26 . Neben einem Text-Parser, der die Tastatureingaben versteht und auswertet, muss der
Spieler teilweise kreative Text-Befehle eingeben. Dies führt bei Misserfolg auch zu Frustration und
ist ein möglicher Grund, warum Text-Adventures in Relation zu anderen Genres heutzutage nicht
mehr so beliebt sind. [Sch 08, S.144]
2.5.2 Interactive Fiction

Interactive Fiction (IF) ist der genauere und sehr gängige Begriff für ein Text-Adventure. Er wurde
von der Firma Infocom in‘s Leben gerufen. Sie verkauen die kommerziell erfolgreichsten Text-
Adventures. [Sco 10]
25 Im Gegensatz zu stochastisch (zufällig) ist etwas Vorbestimmtes gemeint

26 http://www.useit.com/alertbox/twitter-iterations.html 04.10.2010
30
3
Ideenfindung
Wie es zu Ambernstein kam.
31
3 Ideenfindung
In freitäglichen Treffen wurden verschiedene Ansätze per Brainstorming skizziert und im Kopf
durchgespielt.
Zunächst wurde mit einer textbasierten Twitter-Applikation geliebäugelt, in der es um Eingaben per
Tastatur gehen sollte. Andererseits sollte auch das spielerische Element eine Rolle spielen, um eine
gewisse Interaktion zu gewährleisten.
Der erste – recht komplexe – Ansatz war der, vom System eingegrenzte Eingaben von angemeldeten
Nutzern in eine Warteschlange aufzunehmen und sie hintereinander zu verarbeiten. Diese Eingaben
bezogen sich auf eine Spielfigur, die dementsprechend agieren sollte. Die Idee wurde recht bald
verworfen, weil das Ergebnis zu willkürlich und unstrukturiert gewesen wäre.
Es stellte sich heraus, dass Struktur und Vorgaben (Constraints) die wichtigsten Kriterien sein
sollten. Ein Spiel ohne Regeln bedeutet Chaos. Der Weg zur finalen Idee war geebnet.
3.2 Ideenverschmelzung
Es wurde sich ein Spiel überlegt, das auf der komplexen Story eines Text-Adventures basiert, in
Teilen aber auch grafisch repräsentiert wird. Gehalten von einem linearen Drehbuch, das auch schon
in eateraufführungen 27 von LucasArts‘ e Secret of Monkey Island verwendet wurde, und einer
dramatischen Geschichte sollte das Abenteuer »Ambernstein« heißen und im Stil eines Text-
Adventures (story-orientiert) entworfen werden.
27 http://www.worldofmi.com/features/miplay/ 04.10.2010
32
4
Analyse
Vorstudien, Projektplan, Marktsituation.
33
4 Analyse
Dieser Abschnitt befasst sich mit Vorstudien, dem Projektplan und der vorbereitenden Analyse.
Vor allem Letzteres legt den theoretischen Grundstein für das darauf folgende Konzept und die
Umsetzung. Ziel dieses Abschnitts ist, die Anforderungen zu definieren und mögliche Grenzen für
ein Text-Adventure zu finden, das auf nativen Browser-Technologien basiert. Darüber hinaus soll
das allgemeine Projektmanagement und die kollaborative Arbeitsweise mit modernen
Webapplikationen nicht unerwähnt bleiben.
Für den mit der Analyse beginnenden Entwicklungsprozess orientierte man sich in Teilen auch an
dem Poster »designing the user experience« der UPA 28 (Abbildung 9).
Abb. 9, Entwicklungsprozess für UX (UPA)
28 http://www.upassoc.org/upa_publications/ux_poster.html 05.10.2010
34
4 Analyse
Außerdem dienlich für den Entwicklungsprozess war die Schritt-für-Schritt-Anleitung 29 des US-
Gesundheitsministeriums (HHS) – in Abbildung 10 zu sehen.
Abb. 10, Usability als Schritt-für-Schritt-Anleitung
Darüber hinaus zeigte sich das Modell der UX-Elemente von Jesse James Garrett [Gar 00] als sehr
hilfreich für die Entwicklung der UX. Es ist komplexer als das IA-Modell von Morville (Abbildung
26), das explizit auf Garrett Bezug nimmt.
Garrett baut sich die UX aus fünf Ebenen zusammen:

1. Oberfläche
2. »Skelett«
3. Struktur
4. Scope (Anwendungsbereich)
5. Strategie
In Abbildung 11 sind sie nochmals grafisch dargestellt. Auch wenn Garrett [Gar 03, S.1] das Modell
nicht als Vorgehensweise bei der Entwicklung sieht, kann man sich an ihm gut grob orientieren.
29 http://usability.gov/methods/process.html 31.08.2010
35
4 Analyse
Abb. 11, Elemente der UX (Auszug)
Besagte Ebenen reichen von abstrakt zu konkret:

• Visuelles Design (das »Look« in Look and Feel 30 )
• Schnittstellen-, Navigations-, und Informationsdesign
• Interaktionsdesign und Informationsarchitektur (IA)
• Inhalte und Funktionen
• Benutzer-Bedürfnisse und Unternehmensziele
Die mittleren drei Ebenen führen zudem eine Unterscheidung vom Verständnis des Web durch:
[Gar 03, S.31]
• Das Web als Soware-Schnittstelle
• Das Web als Hypertext-System
Garret sagt zwar selbst, dass es sich bei seinen Ebenen nur um ein Modell handelt, denn um einen
methodischen Vorgang. [Gar 00] Dennoch zeigen sich in seinem holistischen Modell die
wesentlichen Bestandteile des Vorgangs beim Auau einer Web-Anwendung. Dies ist auch der
Grund warum sich im Rahmen dieser esis auf dieses Modell bezogen wurde.
30»Design is not just what it looks like and feels like. Design is how it works.« Steve Jobs – http://
query.nytimes.com/gst/fullpage.html?res=9C02E7D8113BF933A05752C1A9659C8B63 05.10.2010
36
4 Analyse
4.2 Projektmanagement
Das Projektmanagement wurde über eine Mischung aus Präsenztreffen und Tools des Web 2.0
gelöst.
4.2.1 Tools
Google Docs & Spreadsheet
Ideensammlung, Dokumentation und Zeitplan
Aufgaben-Management im Stil eines Personal Kanban 31
Dropbox
Datei-Management, Dokumentation und Kommunikation
Diigo
Web-Bookmarks in einer Liste kollaborativ sammeln
Google Reader
Ergänzend als Filter für die Bookmarks bei Diigo
Remember e Milk
Aufgaben-Management
Evernote
Notizen
Etherpad
teilweise für die öffentliche Darstellung des Fortschritts der Arbeit
E-Mail / Skype / Persönliche Treffen
essentiell für schnellen und direkten Austausch
4.2.2 Zeit und Ressourcen

Die ersten acht Wochen Die letzten sechs Wochen
•••••••••••••• ••••••••••••••
• Ideenfindung, erste Spielentwürfe • Prototyp implementieren und testen

• Entwicklung der Grundstory, Drehbuch schreiben • Literatur bearbeiten
• Entwicklung der Mini-Games • Thesis schreiben und gegenlesen lassen
• Game und Web Design analysieren und konzipieren
• Literatur sichten
• Thesis strukturieren
Abb. 12, Zeitplan
31 http://imgriff.com/2010/02/12/personal-kanban-to-dos-auf-japanisch/ 05.10.2010
37
4 Analyse
Etwa in der ersten Häle der Bearbeitungszeit trafen wir uns einmal pro Woche (jeden Freitag), um
unsere Arbeit zu synchronisieren. In der restlichen Zeit gingen wir dazu über, jeden zweiten Tag mal
kurz und mal intensiver Kontakt zu haben. Die Treffen geschahen per einstündigen Skype-Sitzungen
oder mehrstündigen Face-to-Face-Treffen. Dies half uns, gegenseitig Druck, positiven Stress und
Motivation aufzubauen. Natürlich gingen die einzelnen Bestandteile ineinander über, sodass wir z.B.
auch in den ersten Wochen schon an unserer esis schrieben bzw. Literatur bearbeiteten.
Das in Abbildung 12 erwähnte Drehbuch liegt im Anhang als erste Rohversion vor. Zur endgültigen
Verwendung müsste es mindestens noch einmal überarbeitet werden.
4.2.3 Iterativer Entwicklungszyklus
Abb. 13, Iterative Entwicklungssequenz
Der während der Arbeit verwendete Zyklus ist angelehnt an zuvor genannte Vorgehensweisen.
Außerdem orientierte man sich an den in Abbildung 13 [Lyn 09, 2.6] dargestellten
Entwicklungsprozess, sowie an dem Vorgehen von Stocks [Sto 09] und Garret [Gar 03].
4.2.4 Alternative Entwicklungsprozesse

Apple bietet in seinem iOs Dev Center 32 einen Ansatz [Hop 09], der etwas holistischer an die
Entwicklung geht und in vier Abschnitte unterteilt ist:
1. Familiarize
2. Conceptualize
3. Realize
4. Finalize
32 http://developer.apple.com/ 05.10.2010
38
4 Analyse
Ähnlich einfach beschreibt es Unger [Ung 09, S.62ff] beschrieben, bei dem es zur Vorgehensweise
im Kern einfach heißt:
1. Define
2. Design
3. Develop
4. Deploy
Alle Schritte erfolgen dabei in Iterationen.
4.3 Marktsituation
Im Folgenden soll in einer kurzen Analyse festgestellt werden, welche Spiele für den Markteintritt
von Ambernstein interessant sein könnten, welche Merkmale sie besitzen und inwiefern sie sich von
Ambernstein unterscheiden.
4.3.1 Spiele-Auswahl
Kriterien
Um nachvollziehen zu können, welche Spiele für die Marktanalyse verwendet wurden, sollen Muss-
Kriterien für die Auswahl genannt werden:
• online im Browser spielbar
• mit Tastatur steuerbar
Außerdem wurden flexible Kann-Kriterien aufgestellt. Diese lauten:

• gewisse Textlastigkeit
• Steinzeit thematisiert
• geringe Grafiknutzung
Die Auswahl
Letztendlich wurde sich für folgende Titel entschieden:
• Adventure / Colossal Cave (1976)
• Zork 1 (1980)
• Slouching Towards Bedlam (2003)
• Blue Lacuna (2009)
• Stone Age Sam (2008)
39
4 Analyse
• Typer Shark (2009)

Teilweise musste von den Muss-Kriterien (z.B. »online im Browser spielbar«) abgewichen werden,
um die Güte des Spiels bzw. das Spiel überhaupt beurteilen zu können.
Adventure
»Adventure« wurde 1975 programmiert und im Folgejahr veröffentlicht. 33 Es gilt als das erste und
wegweisende Adventure, das dem Genre seinen Namen gab. Wegen der starken Orientierung an
einem Höhlengang bezeichnete man es auch als interaktive Karte. Es wurde in einer speziell für Mac
OSX bereitgestellten Version 34 angespielt.
Zork 1
»Zork 1« gilt als das kommerziell erfolgreichste Text-Adventure der Firma Infocom. [Sco 10] Es
wurde unter Mac OSX in der DOSBox 35 als MS-DOS-Version 36 angespielt.
Slouching Towards Bedlam

»Slouching Towards Bedlam« wurde wegen seiner vielen Auszeichnungen und dem Gewinn 37 der
Interactive Fiction Competition im Jahr seines Erscheinens gewählt. Es wurde in Inform 6
geschrieben. Angespielt wurde es im Z5-Format 38 unter Spatterlight 39 für Mac OSX..
Blue Lacuna
»Blue Lacuna« ist deswegen gewählt worden, weil es ebenfalls vielfach ausgezeichnet wurde und
2009 den Gewinn der Interactive Fiction Competition für sich verbuchen kann. Es wurde in Inform 7
geschrieben. Das Spiel wurde in einer Auszugs-Version 40 im Browser angespielt.
Stone Age Sam

»Stone Age Sam« wurden vor allem wegen des Steinzeit-emas gewählt. Es ist ein in Adobe Flash
realisiert. Es wurde trotz reiner Steuerung per Maus im Browser 41 angespielt.
33 http://akira.ruc.dk/~new/tekster/Adventure.pdf 06.10.2010
34 http://www.lobotomo.com/products/Adventure/index.html 05.10.2010
35 http://www.dosbox.com/ 05.10.2010
36 http://www.infocom-if.org/downloads/downloads.html 05.10.2010
37 http://ifcomp.org/comp03/results.html 05.10.2010
38 http://www.peccable.com/if/slouching/ 05.10.2010
39 http://ccxvii.net/spatterlight/ 05.10.2010
40 http://www.lacunastory.com/excerpt/ 05.10.2010
41 http://www.2dplay.com/stoneage-sam/stoneage-sam-play.htm 05.10.2010
40
4 Analyse
Typer Shark
»Typer Shark« wurde wegen des intensiven Tippens per Tastatur gewählt. Der Kern des Spiels
basiert also auf reiner Tastatursteuerung. Das Spiel ist ebenfalls in Flash realisiert und im Browser
gespielt worden.42
Features
Zunächst sollen Colossal Cave und Zork 1 verglichen werden, weil sie am ehesten zusammenpassen
was Umfang und Komplexität angeht. Später werden Slouching Towards Bedlam und Blue Lacuna
mit gleicher Begründung verglichen.
Zork 1
Die Daten für Zork 1 43 aus Tabelle 2 stammen von Jascon Scott [Sco 10], der inoffiziellen Webseite
44 zu Infocom, dem Department of Computer Science der University of Western Ontario, US und dem
Artikel 45 von Matt Barton bei Gamasutra.
Colossal Cave (1975) Zork 1 (1980)
Erstes Text-Adventure Kommerziell erfolgreichstes Text-Adventure
Programmiersprache: FORTRAN Programmiersprache: MDL
Crowther: 79 Orte, 193 Worte 110 Räume, 600 Worte, 60 Objekte
Woods: 140 Orte, 293 Worte, 53 Objekte
Nur ersten vier Buchstaben werden berücksichtigt komplexe Befehle wie »KILL TROLL WITH SWORD«
Inventar
Punktesystem
beinhaltet einen Antagonisten (Dieb)
Tab. 2, Colossal Cave und Zork 1 im Vergleich
Colossal Cave
Für die Daten von Colossal Cave 46 musste sich wegen Mangel an Alternativen und um überhaupt
einen Vergleich mit Zork 1 anstellen zu können, auf Wikipedia berufen werden. Generelle
Informationen fand man zusätzlich auf der Webseite von Rick Adams. 47
42 http://games.yahoo.com/game/typer-shark 05.10.2010
43 http://www.csd.uwo.ca/Infocom/zork1.html 06.10.2010
44 http://www.infocom-if.org/more/glossary.html#mdl 06.10.2010
45 http://www.gamasutra.com/view/feature/1499/the_history_of_zork.php?print=1 06.10.2010
46 http://en.wikipedia.org/wiki/Colossal_Cave_Adventure 06.10.2010
47 http://www.rickadams.org/adventure/ 06.10.2010
41
4 Analyse
Slouching Towards Bedlam

Die Daten zu Slouching Towards Bedlam (Tabelle 3) stammen von Peccable Productions 48 , dem
Artikel von John Bardinelli 49 , dem Review von Paul O‘Brian 50 .
Blue Lacuna
Die Daten für Blue Lacuna (Tabelle 3) stammen von der Webseite des Autors Aaron Reed 51 und
dem Interactive Fiction Wiki 52.
Slouching Towards Bedlam (2003) Blue Lacuna (2009)
Plattform: Inform 6 (Z-machine) Plattform: Inform 7 (Glulx)
2003 XYYZY Awards: 2009 XYZZY Awards:

Bestes Schreiben, Beste NPCs, Bester individueller Bestes Spiel, Beste Story, Bestes Setting, Beste
PC, Beste Nutzung des Mediums Nutzung des Mediums
2003 Interactive Fiction Competition:

Bestes Spiel, Beste Story, Bestes Setting, Bester
individueller NPC
Fünf Enden, drei zeitliche Phasen Dynamische Raumbeschreibungen, abhängig von

Tageszeit, Wetter und Wellengang und dem Wissen
des Spielers (Protagonisten)
Konversation z.B. per ASK <person> ABOUT <topic> Komplexe Charaktere
Zeitreisen per RESTART, RESTORE und UNDO Einsteigerfreundliche Schlüsselwort-Navigation
Kompass-Navigation
Drama-Manager
Zwei Spielmodi: Story- oder Puzzle-Modus
Tab. 3, Slouching Towards Bedlam und Blue Lacuna im Vergleich
Auf eine Gegenüberstellung der beiden Flash-Spiele wird verzichtet, wer deren Tiefgang relativ
überschaubar ist.
Big Player
Neben erwähnter Wichtigkeit von Adventure / Colossal Cave und Zork 1 soll e Hitchhiker's Guide
to the Galaxy (Infocom) erwähnt werden, das sich kommerziell hinter Zork auf Platz zwei der
Verkaufsliste einreihen kann. [Sco 10] Außerdem einflussreich für Aaron Reeds Blue Lacuna war die
48 http://www.peccable.com/if/slouching/ 06.10.2010
49 http://jayisgames.com/archives/2009/06/slouching_towards_bedlam.php 06.10.2010
50 http://spot.colorado.edu/~obrian/03rev3.html#slouch 06.10.2010
51 http://www.lacunastory.com/about.html 06.10.2010
52 http://ifwiki.org/index.php/Blue_Lacuna 06.10.2010
42
4 Analyse
bis zum Erscheinen von e Sims (2002) kommerziell erfolgreichste Reihe »Myst« [Wal 06]. Myst ist
ein stark grafisch orientiertes Adventure. Es gilt als das berühmteste Grafik-Adventure von allen.
[Rol 06, S. 553]
4.3.2 Zielgruppe
Browser-Spiele sprechen i.d.R. Gelegenheitsspieler an. Ambernstein tut das auch. In dem
Zusammenhang spricht man auch von Casual Gamer bzw. Casual Game Player. Diese Zielgruppe
reicht von 25 bis 50 Jahre. [Sch 08, S.101] Da Gelegenheitsspieler nicht lange warten wollen und
recht bequem spielen möchten, soll auch das Charakteristikum der »Faulheit« der Menschen
berücksichtigt werden. [KOS 05, S.130] Weiterführende Informationen zur Behandlung der
Zielgruppe ist im Anhang zu finden – siehe »Ambernstein – Die Vision«.
4.3.3 Typische Merkmale

Bei allen betrachteten Spielen gibt es Gemeinsamkeiten, auch wenn sie sich teilweise besser als
herunter geladene Version spielen und die Online-Version nur einen Bruchteil des Spiels oder eine
nur beschränkte Immersion bietet. Das führt zu den Merkmalen von diesen Spielen. Die Webseite
»hält« das Spiel. Webseite und Spiel bilden keine Einheit. Es ist kein Bezug von Webseite zum Spiel
zu erkennen. Im Folgenden sollen die zuvor ausgewählten Spiele auf dieses Merkmal – also ihre
Erscheinung im Browser – betrachtet werden. Colossal Cave macht dabei als Java-Applet in
Abbildung 14 den Anfang. Durch den braunen Rahmen ist es nur bedingt stimmungsvoll.
Abb. 14, Colossal Cave per Java-Applet 53 Abb. 15, Zork 1 per Java-Applet 54
53 http://www.astrodragon.com/zplet/advent.html 05.10.2010
54 http://www.xs4all.nl/~pot/infocom/zork1.html 05.10.2010
43
4 Analyse
Zork 1 gibt es bereits in verschiedenen Online-Ausführungen: ganz einfach auf einer Webseite mit
weißem Hintergrund und schwarzer Eingabebox (Abbildung 15) oder etwas aufwändiger per
JavaScript (Abbildung 16).
Abb. 16, Zork 1 per JavaScript 55 Abb. 17, Slouching Towards Bedlam 56
Richtig toll ist das Spielerlebnis in Abbildung 16 nicht, wenn man eine Fehlerkonsole neben dem
eigentlichen Spielfenster zu sehen bekommt. Etwas besser macht es Slouching Towards Bedlam
(Abbildung 17), das die Webseite ganz in Schwarz hüllt und damit den Weiß auf Schwarz gefärbten
Text recht immersiv abbildet.
Abb. 18, Stone Age Sam per Flash Abb. 19 Typer Shark per Flash
55 http://zorkonline.net/zengine-0.4.3/ & http://zorkonline.net/ 05.10.2010

56 http://www.digital-eel.com/if/adv56.htm 05.10.2010
44
4 Analyse
Beinahe »typisch« präsentieren sich die beiden Flash-Spiele (Abbildung 18 und 19) als kleine Fenster
in einem Rahmen mit Werbung, Links zu anderen Spielen und Links, die das aktuelle Spiel
Freunden aus sozialen Netzwerken (Facebook, Twitter, etc.) empfehlen sollen.
Abb. 20, Blue Lacuna (Exzerpt) im Browser
In der Vorschau von Blue Lacuna im Browser (Abbildung 20) ist die Verbindung von Spiel besser
gelöst. Da das Spiel mit der IF-Programmierumgebung Inform 7 erstellt wurde, ist ein einfacher
Export in eine HTML-Datei möglich.
Es zeigt sich, dass eine reine Auslegung auf den Browser bei allen Spielen (außer der JavaScript-
Version von Zork 1) nicht vorgesehen ist – die gezeigten Flash-Spiele sind damit auch gemeint, weil
sie auch außerhalb [sic!] des Browsers lauffähig sind. Das liegt bei allen Titeln an der Technologie,
die für die Programmierung genutzt wurde. Die beiden jüngeren IF-Titel nutzten Inform und den
HTML-Export (Portierung), die Flash-Spiele machten Gebrauch von gleichnamiger Technologie, die
in einem HTML-Dokument eingebettet wird.
4.3.4 Alleinstellungsmerkmale von Ambernstein

Spiel- und Webdesign werden ganzheitlich betrachtet. Statt die Webseite nur als Auffangbehälter
oder Container mit Inhalt, nämlich dem Spiel an sich, zu sehen, wurde vom Entwickler darauf Wert
gelegt, dass Webseite und Spiel miteinander interagieren und konsistent daherkommen. Da das Spiel
eine maximale Verfügbarkeit für die Menschen etablieren soll, wurde entschieden, das Spiel explizit
online im Browser anzubieten – programmiert mit nativen Browser-Technologien (HTML, CSS und
JavaScript), die jeder Browser versteht!
45
4 Analyse
Weitere Merkmale zu Ambernstein sind im Abschnitt 4.1 von Tommy Krügers esis zu finden.
4.3.5 SWOT-Analyse von Ambernstein

Als Bilanz aus den Erfahrungen des aktuellen Markts können Stärken und Schwächen, sowie
Möglichkeiten und Gefahren eruiert werden. Man spricht dabei von der SWOT-Analyse[Ung 09, S.
61]: Strengths, Weaknesses, Opportunities, Threads.
Stärken Schwächen
Linearer Verlauf der Story – drehbuchbasiert
Geringe Interaktion – Einwirkung des Spielers ändert

den Spielverlauf nicht
Holistische Betrachtung von Web und Game Design
Web und Game Design interagieren miteinander
Einfacher Einstieg in das Spiel durch geringe

Eingabefrequenz per Tastatur
Dient als Einstieg in die IF für Gelegenheitsspieler
Anregung der Fantasie des Spielers
Dramatik der Story
Tab. 4, Stärken und Schwächen von Ambernstein
Chancen Gefahren
Blue Lacuna als Beispiel für ein potenziell gutes und Zu viel Textausgabe könnte Spieler langweilen und
kurzweiliges Spiel ermüden
Tab. 5, Chancen und Gefahren für Ambernstein
4.4 Wahl der Technologie

Für Ambernstein wurde auf native Browser-Technologie gesetzt: eine Mischung aus HTML5, CSS3
und JavaScript in Karnation von jQuery. Für den dynamischen Auau der Webseite wurde
»serverseitiges« PHP schlank eingesetzt.
HTML5 wurde deswegen gewählt, weil es von sich aus multimedialer und stärker auf Webseiten als
Anwendung gerichtet ist. Die Unterstützung 57 durch gängige Browser ist jetzt schon gegeben.
57 http://html5readiness.com/ 05.10.2010
46
4 Analyse
JavaScript wurde wegen der geplanten Ajax-Nutzung und der nativen Unterstützung in Browsern
gewählt. Es nicht nötig, ein Add-on, Plugin o.ä. zu installieren. Speziell wurde jQuery gewählt, weil
es browser-übergreifend kompatibel und relativ schlank ist (~24 KB). Es unterstützt CSS1 bis 3, und
arbeitet kompakter durch kürzer geschriebenen JavaScript-Code. Außerdem ist die Community im
Web mittlerweile sehr gewaltig und kompetent.
CSS3 ist die neueste Version der Cascading Stylesheets. Sie sind das Standardwerkzeug eines
Webdesigners, wenn es um die visuelle Präsentation der Webseite geht. Keine moderne Webseite
kommt ohne CSS aus.
4.4.1 Vorteile nativer Browser-Technologien

Um die Vorteile nativer Technologien im Browser zu sehen, ist es wichtig zu erkennen, welcher
Technologie-Einsatz noch möglich wäre: Flash von der Firma Adobe oder Silverlight von Microso.
Es wird klar, dass einzelne Firmen mit entsprechenden kommerziellen Interessen dahinterstehen.
Wie Apple-Chef Steve Jobs in seinen »oughts on Flash« richtig sagt 58 , ist Flash 100% proprietär.
Nicht anders ist bei Silverlight. Es sind keine offenen Standards, sie wurden nicht von der
Community geschaffen. Da besagte proprietäre Plugins bisher die fehlende Möglichkeit,
multimediale Elemente wie Video und Audio in Webseiten einzubauen, wettmachten, schickt sich
HTML5 nun an, selbst nativ diese Lücke zu schließen [Kei 10, S. 23] – per <audio> und <video>
Tag.
Patrick J. Lynch, Jakob Nielsen und Craig Hockenberry sprechen sich unterschiedlich explizit für
native Browser-Technologien aus. Laut Lynch 59 verführt Flash dazu, Aufmerksamkeit um jeden
Preis generieren zu wollen. Nielsen betrachtet Flash 2000 60 , 2005 61 und 2006 [Nie 06, 11] als »99%
schlecht« und dessen Einsatz als einen der größten Fehler im Webdesign. Konsequenterweise hat er
deswegen 2002 117 Usability-Richtlinien 62 für Flash-basierte Web-Anwendungen veröffentlicht.
Hockenberry fasst in seinem Artikel »Apps vs. the Web« 63 bei A List Apart im August 2010 u.a.
zusammen, warum es sich lohnen kann, auf Web-Standards zu setzen: Speed, Data Management,
Animation.
58 http://www.apple.com/hotnews/thoughts-on-flash/ 05.10.2010
59 http://www.webstyleguide.com/wsg3/8-typography/7-signal-to-noise-ratio.html 05.10.2010
60 http://www.useit.com/alertbox/20001029.html 05.10.2010
61 http://www.useit.com/alertbox/designmistakes.html 05.10.2010
62 http://www.nngroup.com/reports/flash/RIA-usability.pdf 05.10.2010
63 http://www.alistapart.com/articles/apps-vs-the-web/ 05.10.2010
47
4 Analyse
Er räumt ein, dass JavaScript als interpretierte Programmiersprache zwar langsamer als eine
kompilierte Programmiersprache wie C++ sei, dessen Geschwindigkeit aber kräig zugenommen
habe. Dank HTML5 gibt es laut Peter Kröner [Krö 10, S.154] die Möglichkeit, Daten seiner
Anwendung offline per Application Cache zu speichern oder in einer Web SQL Database 64
abzulegen. Bezüglich CSS3 nennt Hockenberry als Weg Animationen zu bauen, sieht die im Artikel
verglichenen nativen (in Objective-C) programmierten iPhone-Animationen aber weiter vorne.
Alex Kessinger 65 sieht den Vorteil von HTML5 darin, dass HTML-Code bereits bekannt ist und
nach ein wenig Umgewöhnung an die neuen Tags – z.B. <header>, <footer>, <section> – HTML5-
Anwendungen schnell zu schreiben sind.
4.4.2 Nachteile von nativen Browser-Technologien

Um die multimedialen Eigenschaen von HTML5 auskosten zu können, ist nicht nur zunehmend
das <canvas> Element gefragt, sondern auch JavaScript. Das ist deswegen der größte Nachteil, weil
man es im Browser deaktivieren kann. Im Sinne der Accessibility ist dies natürlich gefährlich. Auch
die Indizierung dynamischer durch Ajax-generierter Inhalte durch Suchmaschinen ist einer der
Nachteile solcher Technologien. [Lyn 09, 10.2]
Um der Entwicklung sogenannter Rich Internet Applications (RIA) Herr zu werden, hat die W3C
entsprechende Richtlinien 66 verfasst. Auch Adobe selbst hat sich der Problematik der Accessibility
unter Flash 67 angenommen.
4.4.3 Status Quo – Stand der Technik

So vorteilha native Technologien im Browser auch sind, sieht die Realität für Browser-Spiele anders
aus. Flash-Spiele sind in der Überzahl. Es gibt erste Experimente 68 mit HTML5 und CSS3, die u.a.
an frühe Flash-Animationen erinnern 69 . Nichtsdestotrotz finden sich erste Sammlungen 70 von
HTML5-Spielen – wenn auch teilweise vielversprechend 71 , fallen sie noch übersichtlich aus.
64 http://dev.w3.org/html5/webdatabase/ 05.10.2010
65 http://net.tutsplus.com/tutorials/html-css-techniques/html5-apps-what-why-and-how/ 05.10.2010
66 http://www.w3.org/WAI/intro/aria 05.10.2010
67 http://www.adobe.com/accessibility/products/flash/tutorial/ 05.10.2010
68 http://www.chromeexperiments.com/, http://html5demos.com/ 05.10.2010
69 http://www.optimum7.com/css3-man/animation.html 05.10.2010
70 http://html5games.com/ 05.10.2010
71 http://web.appstorm.net/roundups/browsers/10-html5-games-paving-the-way/ 05.10.2010
48
4 Analyse
4.4.4 Alternativen
Technologische Alternativen sind wie teilweise bereits erwähnt:
• Adobe Flash
• Microso Silverlight
• Java-Applets
4.5 Strategie
Das Dokument »Ambernstein – die Vision« hält die Strategie [Gar 03, S.38] fest. Im Wesentlichen
enthält sie die Ziele der Entwickler und die Bedürfnisse der Nutzer. Gleichzeitig dient es aber auch
als Projekt-Charter [Lyn 09, 1.8] und geht auf das Ökosystem eines Projekts [Ung 09, S.9ff] ein.
Dieser Abschnitt bezieht nur sich in Auszügen auf besagtes Dokument – die komplette Ausführung
ist im Anhang zu finden. Sie zeigt einen ersten Ansatz, da eine vollständige Unternehmensstrategie
den Rahmen dieser Arbeit sprengen würde.
Um eine klare Vorstellung davon zu bekommen, was vom Produkt erwartet wird, formuliert man in
einem Satz das Application Definition Statement [Hop 09], das aussagt, welches Problem das Produkt
löst und für wen es gedacht ist.
4.5.1 Definition der Anwendung

»Ambernstein ist ein leichtgewichtiges, einfach nutzbares, tastaturgesteuertes Browser-Spiel für
nicht mobile 72 Gelegenheitsspieler.«
4.6 Anforderungen
Basierend auf den Ausarbeitungen und Erkenntnissen des vorigen Abschnitts zur Strategie, werden
nun spezifische Anforderungen an die Funktionalität und den Inhalt gestellt, die der Nutzer abrufen
kann. Man spricht dabei von dem Scope und meint damit einen zweckdienlichen Prozess, der ein
gut nutzbares Produkt ergibt. [Gar 03, S. 62] Die Beweggründe für Erstellung des Produkte (das
Warum) ist in der Strategie festgehalten. Dieser Abschnitt kümmert sich darum, was konkret erstellt
wird. [Gar 03, S. 65]
Bei der Anforderungsanalyse beru man sich auf die Erfahrungen aus dem Brainstorming. Der
Vorgang fand bewusst nicht nach dem Prinzip des UCD statt, da ein größtmöglicher
Überraschungsmoment generiert werden sollte. Die Nutzer zu fragen, was sie inhaltlich und
72 im Sinne von: nicht für Browser mobiler Endgeräte entwickelt
49
4 Analyse
funktionell in einem Spiel erwarten, funktioniert nur bedingt. Ambernstein sollte ohne diese Option
auskommen. Um die Testpersonen zu verallgemeinern, entwickelte man einzelne Personas, die
einen bestimmten Typen repräsentieren. Diese lässt man bestimmte Szenarios durchlaufen – siehe
Anhang.
4.6.1 Inhaltlich
Im Stil eines Adventures
Ursprünglich als zweiteiliges Spiel geplant, das einen Action- und Story-Modus innehat, entschied
man sich im Verlauf dazu, beide Modi miteinander zu kombinieren, um ein adäquates Spiel für
Gelegenheitsspieler zu entwerfen. Mit Hilfe eines selbst verfassten Drehbuchs wird die Spielzeit sehr
stark reglementiert und der Verlauf recht linear gehalten, was angesichts der Zielgruppe für sinnvoll
und vernünig gehalten wird. Das Spiel dauert je nach Implementierung etwa 30 bis 60 Minuten.
Content-Management
Getreu dem in der Strategie verfassten Leitsatz, Dinge einfach zu halten, entschied man sich gegen
ein Content-Management-System (CMS). Stattdessen wurde XML genutzt – ein im Web und auch im
Desktop-Bereich sehr gängiges, weil universelles Datenformat.
Im Wesentlichen handelt es sich um die Handhabung von Drehbuchtexten, also die Beschreibungen
von Ort, Zeit und Handlung des allwissenden Erzählers aus dem Off in der dritten Person.
Weiterhin relevant waren die Gedanken und Gefühle der handelnden Person – üblicherweise in
Klammern dargestellt. Darüber hinaus bedeutsam waren Dialoge, sowie Bilder und der Soundtrack
(einschließlich der Sound-Äquivalente zum visuell dargestellten Text – in Rücksichtnahme auf
Aspekte der Accessibility), der der Untermalung der Situation dient.
Der Umfang der nötigen Dateien wird relativ schlank sein – siehe Abschnitt 5.3.
4.6.2 Funktional
Interaktion: Nutzer und UI
Der Begriff des UI legt es bereits nahe, dass die Interaktion zwischen Spieler und Schnittstelle (Spiel)
effektiv verlaufen muss. Für das UI-Design wird sich deshalb auf die wichtigsten Designprinzipien
von Donald A. Norman [Nor 02, Preface] berufen:
• Conceptual models
50
4 Analyse
• Feedback
• Constraints
• Affordances
Conceptual models helfen dem menschlichen Verstand, Dinge und Gegenstände intuitiv in ihrer
Funktion zu verstehen. Das Endgerät dient dabei als Kommunikationsmittel zwischen Designer und
Nutzer. Scheitert dieser Prozess, ist es dem Designer nicht gelungen, sein Produkt selbsterklärend zu
machen. Das sogenannte natürliche Abbilden (natural mapping) ist fehlgeschlagen und der Nutzer
muss sich das Gerät selbst erklären. Nicht selten entstehen dabei Fehler und Frustration.
Feedback ist zwar selbsterklärend, deswegen aber nicht weniger entscheidend. Es meint die
Rückmeldung, die nach dem Durchführen einer Aktion, gezeigt wird.
Constraints bedeutet wörtlich übersetzt »Einschränkungen«. Im Design meint Norman damit, dass
Fehler in der Bedienung vermieden werden sollen, indem die Möglichkeiten zur Nutzung
eingeschränkt werden.
Affordances meint visuelle Mittel, die passende Aktionen wahrnehmbar und unpassende Aktionen
unsichtbar machen.
Interaktion: Web UI und Game UI

Das Web UI reagiert mit verschiedenfarbigen Plättchen, die sich bei einem Wechsel zu einer anderen
Subwelt und dem Wechsel zu einer anderen (besonderen) Situation färben, z.B. bei Flashbacks des
Protagonisten.
Ziel ist es, ein ganzheitliches Browser-Erlebnis zu generieren, bei dem Web und Game UI interaktiv
miteinander umgehen; sprich: Elemente, die normalerweise außerhalb des »Spielfelds« liegen,
werden auf bestimmte Art mit einbezogen. Beispiele dafür sind die Ansätze der Browser-Spiele
Quake Live 73 und Legends of Zork 74 .
Accessibility
Im Folgenden sollen die Anforderungen an die Zugänglichkeit ausformuliert werden:
73 http://www.quakelive.com/
74 http://legendsofzork.com/
51
4 Analyse
1. Ambernstein orientiert sich an den Richtlinien der WCAG 2.0 75 der WAI 76
2. Ambernstein orientiert sich an den Richtlinien der US Section 508 77 .
3. Ambernstein orientiert sich an den Richtlinien der WAI-ARIA 78.
4. Ambernstein orientiert sich an den vier Aspekten der Web Accessibility für den Geschäsbereich:
sozial, technisch, finanziell, rechtlich. 79
5. Ambernstein berücksichtigt folgende Beschränkungen: motorisch, kognitiv, visuell, akustisch.
[Lee 10]
6. Ambernstein berücksichtigt Tests mit einem Screenreader, wird diese aber nur bedingt
implementieren.
Die genannten und folgenden Anforderungen werden im Sinne eines Prototypen teilweise
implementiert. Im Sinne der Spielerfahrung sind die Anforderungen zur Zugänglichkeit immer in
einem Kompromiss zu eruieren. Es ist nicht ausgeschlossen, dass Teilaspekte nicht berücksichtigt
werden können. Die Richtlinien der WCAG 2.0, die vom W3C explizit empfohlen 80 werden, lauten:
• Wahrnehmbar
• Bedienbar
• Verständlich
• Robust
Lesbarkeit, Erkennbarkeit und Immersion

In Spielen, auf entsprechenden Webseiten zum Spiel oder auch direkt in Browser-Spielen ist es nicht
unüblich, dass z.B. in einem mittelalterlichen Spiel auch eine adäquate Schriart benutzt wird. Es ist
teilweise fraglich, ob man diese gut lesen kann. Die Frage, die sich im Rahmen dieser Arbeit stellt, ist
die nach der Immersion – also dem Abtauchen und Eintauchen in ein Spiel. Diese muss in einem
Kompromiss zur Lesbarkeit und Erkennbarkeit von Text gesehen werden. Für Ambernstein setzte
man auf optimale Lesbarkeit und wählte Helvetica – gemäß Experten-Umfrage die »beste Schri
aller Zeiten«. 81
75 http://www.w3.org/Translations/WCAG20-de/
76 http://www.w3.org/WAI/
77 http://www.section508.gov/ & http://www.hhs.gov/web/508/index.html
78 http://www.w3.org/WAI/intro/aria.php
79 http://www.w3.org/WAI/bcase/Overview
80»[...] W3C recommends that new and updated content use WCAG 2.0. The W3C also recommends that Web
accessibility policies reference WCAG 2.0.« – http://www.w3.org/TR/WCAG20/ 05.10.2010
81 gemäß einer internationalen Jury im Januar 2007 – http://100besteschriften.de/
52
4 Analyse
Auf den Kompromiss von Immersion (Groking) [KOS 05, S.28] und Accessibility wird im folgenden
Abschnitt näher eingegangen.
4.6.3 Technisch
Die technischen Anforderungen für Ambernstein sind ausführlich argumentiert und mit
entsprechenden Quellen untermauert. Aufgrund des Umfangs wurden sie ausgelagert in das
separate Dokument »Ambernstein – Technische Anforderungen an die UX« – siehe Anhang.
4.7 Angestrebte Funktionen

4.7.1 Kernfunktionen
Tastatursteuerung
Tastatursteuerung ist das Kernelement eines Text-Adventures. Es ist ein glücklicher Zufall und ein
Ausdruck des modernen Anspruchs von Ambernstein, dass für 2010 die Keypress Navigation als
Trend vorausgesagt wurde. Es gibt bereits einige Beispiele, die erfolgreich z.B. die Cursor-Tasten zur
Navigation benutzen. [Fri 10]
Textdarstellung
Es liegt nahe, in einem Text-Adventure Text darzustellen. Dennoch soll das Kriterium als explizite
Kernfunktion erwähnt sein.
4.7.2 Außerordentliche Funktionen

Gemeint sind Funktionen und Paradigmen, die man bisher in der Form bei einem Text-Adventure
noch nicht gesehen hat 82 . Dazu zählen:
• eine Story, die auf einem filmischen Drehbuch basiert

• eine rein auf den Web-Browser abgestimmte Spiel-Erfahrung
• eine betriebssystemunabhängige Erfahrung
• ein UI, das Web- und Spieldesign ganzheitlich betrachtet
82 gemäß der Recherche des Autors
53
4 Analyse
4.8 Fazit
Kern- und Knackpunkt bei der Entwicklung von Ambernstein ist JavaScript. Für die UX ist es
unerlässlich, weil das Spielerlebnis – insbesondere die Mini-Spiele – ohne aktiviertes Client-Side
JavaScript (CSJS) nicht generiert werden kann. Es ist also ein Dilemma: Einerseits möchte man
höchst zugänglich sein, andererseits soll eine maximale UX geschaffen werden.
Der nun folgende Konzeptteil soll beschreiben, wie eine mögliches Lösung dieses Dilemmas
aussehen kann.
54
5
Konzept
Storytelling, Webdesign, Spieldesign.
55
5 Konzept
Die Ergebnisse aus der Analyse und den Anforderungen zeigen, wie Text-Adventures von heute
aussehen und wie Ambernstein als Text-Adventure mit leichter grafischer Orientierung aussehen
kann. Das Konzept thematisiert nun das Storytelling, sowie das Web- und Spieldesign.
Im Drehbuch wird die Story so geschrieben, dass man Ambernstein zwar geradlinig aber auch mit
gewollten Höhepunkten in der Dramatik erleben kann. Das Spieldesign wird im Wesentlichen in der
esis von Tommy Krüger aufgegriffen und beschreibt die prototypische Implementierung in
JavaScript sowie strukturelle Angelegenheiten. Das Webdesign liegt wiederum im Schwerpunkt des
Autors dieser Arbeit.
Dieser Abschnitt hingegen soll mit generellen Entwurfsüberlegungen beginnen und dann zu ersten
Papier-Prototypen führen, die die Anforderungen der Analyse berücksichtigen. Im besagten
iterativen Prozess werden diese Entwürfe zum ersten UI und Information Design führen.
Anhand begleitender Usability-Tests für das Web Interface sollen Schritt für Schritt mögliche
Unzulänglichkeiten erkannt und verbessert werden, um einen ersten Eindruck vom Spielgefühl zu
bekommen.
5.1.2 Sieben Schritte

Im Hinterkopf behalten sollte man die sieben Schritte der Aktion eines Nutzers: Davon ist ein
Schritt aufs Ziel der Aktion, sind drei auf die Ausführung und wiederum drei auf die Auswertung
der Aktion bezogen: [Nor 02, S.48]
1. Forming the goal

2. Forming the intention
3. Specifying an action
4. Executing the action
5. Perceiving the state of the world
6. Interpreting the state of the world
7. Evaluating the outcome
In Abbildung 21 83 sind besagte Schritte nochmals schematisch abgebildet.
83 http://upload.wikimedia.org/wikipedia/en/6/6e/Seven_Stages_of_Action.JPG 05.10.2010
56
5 Konzept
Abb. 21, Die sieben Handlungsschritte eines Nutzers nach Norman
5.2 Storytelling
Das Spiel sollte sehr story-orientiert entwickelt werden. Deshalb sollte als erster Schritt, das
Drehbuch geschrieben werden. Laut Rouse III ist dies eine der drei validen Startmöglichkeiten für
Spiele. [Rou 05, S45f.]
Dessen bewusst, dass Drehbücher eigentlich für Filme gedacht sind, die linear ablaufen, war es auch
für das Spiel passend, weil die Zielgruppe (Gelegenheitsspieler) nicht zu vielen Hürden begegnen
sollte. Potenziell ist der Text und das relativ viele Lesen eine mögliche Barriere, aufgrund der
Genrewahl aber unabdingbar. Der relativ hohe Textkonsum soll durch ein flüssiges Gameplay 84 und
schnelle Erfolgserlebnisse in Form von Feedback wett gemacht werden.
Da das erste Mal ein Drehbuch verfasst wird, wurde professionelle Unterstützung in Form eines
Handbuchs von Syd Field [Fie 98] zur Hilfe genommen.
5.2.1 UX und Storytelling

Dass nicht nur das Spiel von einer Geschichte profitiert, zeigt Francisco Inchauste, indem er die UX
nutzt, um die scheinbar verloren gegangene menschliche Verbindung mit Storytelling-Methoden
wieder aufzubauen. Für den Zweck der Story bedient man sich den Archetypen, die Carl Gustav
Jung als »Grundpfeiler der Analytischen Psychologie« schuf. [Jun 09] Er vertrat die Vorstellung, dass
84 engl. Spielmechanik; teilweise auch als »Game Play« geschrieben
57
5 Konzept
wir unbewusst die Idee des Helden, Mentors und Quests innehaben. [Inc 10a] Joseph Campbell, der
dieses Modell adaptierte, schildert in e Hero with a ousand Faces (1949) seine Erfahrungen zu
Strukturen von Religion und Mythen. Vergleicht man nun Film-Reihen wie Matrix und ältere
Reihen wie Star Wars, fallen die gleichen (mythischen) Muster auf, die Jung bzw. Campbell
beschrieben:
Campbell Matrix Star Wars
Zwei Welten Realität und Die Matrix Heimatplanet und Todesstern
Der Mentor Morpheus Obi-Wan Kenobi
Das Orakel Das Orakel Yoda
Die Prophezeiung Morpheus findet de Auserwählten Luke stürzt das Imperium
Der gescheiterte Held Cypher (im frühen Script) Biggs
Feindkleidung tragen Neo als Agent Luke und Han Solo als
Stormtrooper
Gestaltwandler Cypher Han Solo
Tier jagen Neo folgt dem weißen Hasen Luke folgt R2
Tab. 6, Mythische Muster in Filmen (Matrix, Star Wars)
Matrix und Star Wars spielen dabei gleichermaßen mit den Gefühlen der Zuschauers. Die Story baut
besagte emotionale Verbindung auf. Ähnlich tut es auch Starbucks, die ihre Filialen in den Städten
dieser Welt als dritten Ort nach dem Zuhause und der Arbeit sehen. Konsequenterweise sehen sie in
ihrem Web-Auritt den vierten Ort. 85 Ambernstein positioniert sich als Spiel mit einfachem Zugang
und einer etwas schrägen, selbstironischen und dennoch dramatischen Story.
Storytelling ist bedingt durch die Entwicklung des Drehbuchs ein Bestandteil dieser Arbeit – siehe
Abschnitt Drehbuch. Interessant wird Storytelling hinsichtlich Design, wenn man es als narratives
Design 86 bezeichnet. Es erleichtert, die UX mit einer einheitlichen »Stimme« zu präsentieren –
ähnlich wie es das Paradigma des konsistenten Designs tut. [Cha 09]
Storytelling ist wichtig, weil es den Sinn und Zweck eines Ortes wiedergibt. 87
5.2.2 Analogie zu Film und Buch
85http://blogs.reuters.com/shop-talk/2010/09/22/starbucks-ceo-says-building-fourth-place-online/
05.10.2010
86 Curt Cloninger, [Inc 10b]
87 Christian Saylor, [Inc 10b]
58
5 Konzept
Als filmisches Element wird für Ambernstein ein Drehbuch benutzt. Es ist die lineare Vorlage.
Ambernstein ist aber ein Text-Adventure, das man auch als gespieltes (interaktives) Buch
bezeichnet. Es sind also drei Elemente vereint: das Drehbuch des Films, die imaginäre
Vorstellungskra eines Buchs, und die Interaktion eines Spiels.
Experience Theme
Als Mittel eine optimale UX zu generieren, rät Cindy Chastain [Cha 09] ein Experience eme zu
schaffen. Wie in Abbildung 22 gezeigt, wird durch ein ganzheitliches ema der Film harmonisiert.
Abb. 22, Greifbare UX-Elemente in Film und Webseite
Es wird deutlich, dass die Story den Film zusammenhält und koordiniert. Dabei ist jede Szene
zweckdienlich, um das Ziel der emotionalen Erfahrung zu schaffen. Eine klassische Webseite kann
mit dieser Koordination nicht aufwarten. Um auch bei der Web-Entwicklung story-orientiert
vorzugehen, ist besagtes Experience eme nötig, das alles zusammenhält. Die anfänglich
wichtigsten Fragen sind:
• Worum geht es bei der Webseite?

• Welche Erfahrung ist die fesselndste und bedeutendste für unsere Nutzer?
59
5 Konzept
Das ema wird dann in einem Experience Brief festgehalten, das den Zweck des emas, die
Umstände aufgrund dessen das ema entstand und die damit vermittelte Strategie (Experience
Strategy).
beinhaltet. Betrachtet man das ema als geografische Landscha, auf der man Ideen kreativ
kultivieren kann und als Kompass, der für die Analyse und Auswertung der Lösungsvorschläge
hinzugezogen wird, hat man ein hilfreiches Werkzeug für den UX-Designprozess und die Strategie
(Abbildung 23) 88 . Dies kommt letztendlich dem Nutzer zugute.
Abb. 23, Experience Theme
Ein Experience eme wurde für Ambernstein nicht angefertigt, da das Dokument »Ambernstein –
Die Vision« wesentliche Inhalte dieses formalen Dokuments enthält – siehe Anhang.
5.2.3 Drehbuch
Für Ambernstein hielt man sich an die typische Drei-Akt-Struktur 89 eines Films (Abbildung 24).
Abb. 24, Drei-Akt-Struktur eines Films
88http://www.slideshare.net/cchastain/experience-themes-an-element-of-story-applied-to-design-1190389, S.
47
89 http://www.musik-therapie.at/PederHill/Structure&Plot.htm
60
5 Konzept
Auch der typische Spannungsverlauf 90 eines Films (Abbildung 25) wurde bei der Entwicklung des
Drehbuchs berücksichtigt.
Abb. 25, Spannungsverlauf eines Films
Traditionelles (lineares) Storytelling wurde u.a. aus folgenden Gründen benutzt: [She 04, S.300]
• Es ist lange erprobt und bewährt.

• Es ist erfolgreich in einer Vielzahl von Medien.
• Es ist dem Autor bekannt und behagt dem Spieler.
• Es garantiert Kontrolle über den Verlauf der Story seitens des Autors.
Weitere Ausführungen zum Drehbuch sind im folgenden Umsetzungsteil dieser esis zu finden.
Die erste Rohversion des Drehbuchs, inklusive eines einseitigen Treatments, ist im Anhang zu
finden.
5.2.4 Charaktere
Figuren
In Ambernstein treten in der jetzigen Version folgenden Figuren in Erscheinung: Relat, Rela,
Rasmandal, Albugal, Haikun, Fennek und Mumbai. Das Drehbuch sieht noch mehr Figuren vor.
90 http://www.musik-therapie.at/PederHill/Structure&Plot.htm 06.10.2010
61
5 Konzept
Eine kurze Beschreibung ist in Tommy Krügers esis zu finden. Eine ausführlichere Beschreibung
vom Protagonisten ist im Anhang zu finden. Mehr Hintergrundwissen zu der Entwicklung von
Charakteren ist in [She 04] zu erfahren.
Archetypen
Bei den geschaffenen Figuren orientierte man sich an den Archetypen von Jung. [Jun 09] Dies tat
auch Vogler [Vog 98, S.79ff.]. Bekannte und nützliche Archetypen sind laut ihm:
• Held
• Mentor
• Schwellenhüter
• Herold
• Gestaltwandler
• Schatten
• Trickster
Nicht jeder Archetyp wird von Ambernstein besetzt. Der Held der Geschichte ist Relat, da man sich
ehesten mit ihm identifizieren wird. [Vog 98, S. 89] Wie Helden heutzutage von Spiele-Entiwcklern
gesehen werden, ist in [Nee 10b] zu sehen. Rasmandal ist der Mentor, weil er den Helden
unterstützt uns ausrüstet. [Vog 98, S.105] Mumbai nimmt die Rolle des Schwellenhüters ein, weil er
vom Helden besiegt werden muss, um die »Pforte zu einer neuen Welt« zu erreichen. [Vog 98, S.
121] Haikun steht für den Herold, weil er den Helden mit einer Herausforderung konfrontiert. [Vog
98, S.127]
Noch strittig ist die Besetzung der Figur der Rela, da sie zwar in Beziehung zu Relat steht,
nichtsdestotrotz aber Züge eines Gestaltwandlers aufweist. [Vog 98, S.133] Fennek zählt mit seinen
Absichten zum Archetypus des Schattens, weil er üblicherweise das Böse repräsentiert. [Vog 98, S.
143] Wenn auch nicht explizit als Figur vertreten, leistet der Erzähler des Dramas das was den
Trickster ausmacht – er bringt das »Publikum beizeiten wieder auf den Boden der Wirklichkeit
zurück« und sorgt für »Entspannung durch Komik. [Vog 98, S.151f.]
5.2.5 Soundtrack
Für Ambernstein wird ein Soundtrack gewählt, der Lieder unter der CC-Lizenz 91 beinhaltet. Musik,
die vom Künstler selbst lizensiert und vermarktet werden kann, entspricht der Strategie von
91 Creative Commons Lizenz – http://creativecommons.org/
62
5 Konzept
Ambernstein. Alternativ ist ein Soundtrack mit Liedern kommerziell vermarkteter Künstler
vorgesehen, da deren Lieder teilweise besser zur Stimmung des Spiels passten oder es auf dem CC-
Markt keine entsprechenden Äquivalente gab. Im Anhang sind erste Tracks zu finden - auf einen
vollständigen Soundtrack wurde auf Grund des Umfangs des Drehbuchs verzichtet.
5.3 Abstrakte Struktur

Bereits während der Analyse wurde nach funktionalen und inhaltlichen Anforderungen unterteilt.
Implizit wurde dabei die Unterscheidung zweier Sichtweisen auf das Web vorgenommen. Laut
Garrett gibt es das Web als Soware-Interface und als Hypertext-System. [Gar 03, S.31]
Im Hypertext-System geht es um die Bereitstellung von Information und welchen Nutzen sie für den
Nutzer hat. Der Produzent dieser Information kann auch als Informationsarchitekt angesehen
werden. [Gar 03, S.86f.]
Im Web als Soware-Interface konzentriert man sich auf die mit der Webseite verbundenen
Aufgaben und deren Lösung. Die Webseite wird als Werkzeug gesehen. Den Produzenten dieser
Aufgaben und Lösungen bezeichnet man auch als Interaktionsdesigner.
Im Folgenden werden diese beiden Sichtweisen explizit eingeführt.
5.3.1 Informationsarchitektur
Die Informationsarchitektur (IA) ist für Ambernstein nicht besonders komplex. Es werden die
interne und öffentliche Architektur unterschieden. Gemäß Peter Morville hängen IA und UX
zusammen. Insofern sind die »Kreise der Informationsarchitektur« in Abbildung 26 auch für die UX
gültig. [Mor 04]
Abb. 26, Kreise der IA/UX
63
5 Konzept
Es ist also festzuhalten, das bei der Informationsarchitektur der Kontext, Inhalt und Nutzer ein
großes Ganzes ergeben. Die in der Analyse beschriebenen inhaltlichen Anforderungen sollen nun
mit Inhalt gefüllt werden:
• Quelltext
• Dateien im Format HTML, CSS, JS und PHP
• Inhalts-Text
• Dateien im Format XML und TXT
• Dokumente
• Dateien im Format PDF (eses)
• Bilder
• Dateien im Format JPG, PNG, GIF
• Sound
• Dateien im Format MP3 und OGG
Der konkrete abschätzbare Umfang der Inhalte soll nun angegeben werden:
Quelltext < 100 KB
Inhalts-Text < 1 MB
Dokumente < 10 MB
Bilder < 10 MB
Sound < 100 MB
Die Handhabung der Dateien erfolgt über einen gesicherten FTP-Zugang, der nur den Entwicklern
vorbehalten ist.
Architektonische Herangehensweisen
Dem Top-Down-Prinzip, bei dem ausgehend von der Strategie die Seiten-Hierarchie aufgebaut wird,
steht das Bottom-Up-Prinzip entgegen, bei dem von den Anforderungen an Inhalt und Funktion
ausgegangen wird. In der Regel findet man mit einer gesunden Mischung aus beiden Sichtweisen die
richtige Architektur. [Gar 03, S.95]
Hierarchie
Die bereits angedeutete hierarchische Struktur meint die Eltern-Kind-Beziehung eines »Baums«.
Jeder »Ast« des Baums wird als »Knoten« bezeichnet. Jeder Kind-Knoten hat zwar einen Eltern-
Knoten, aber nicht immer weitere Kind-Knoten. [Gar 03, S.98ff.] Die Abbildung 27 zeigt diese
hierarchische Struktur. [Pre 04]
64
5 Konzept
Abb. 27, Hierarchische Informationsarchitektur
Weitere denkbare Strukturen sind in Abbildung 28 zu sehen: [Pre 04]

• eine Matrix
• eine Sequenz
• organisch / web-linked (vergleichbar mit einer Mind-Map)
Abb. 28, Sequenzielle und organische Informationsstruktur
Für Ambernstein soll eine hierarchische Struktur aufgebaut werden. Auch wenn nur zwei
Hierarchiestufen vorgesehen sind, ist diese Struktur für den Ausbau weiterer Seiten bestens gerüstet
(Abbildung 29). [Pre 04]
Abb. 29, Ausbau einer hierarchischen Struktur
Organisationsprinzipien
Die Organisation der Inhalte ist ein wesentlicher Bestandteil der Informationsarchitektur. Gemäß
Garrett [Gar 03, S.101] gibt es fünf verschiedene Prinzipien, Inhalte zu organisieren:
65
5 Konzept
• nach Zielgruppen
• nach der Zeit
• nach Orten
• nach Kategorien
• nach gewissen Größen (z.B. Gewicht)
Auch eine alphabetische Organisation kann Sinn machen. Richard Saul Wurman geht in Information
Anxiety (1989) auf ähnliche Formen der Organisation ein. Für Ambernstein wurde die Methode des
Card-Sorting verwandt, um eine intuitive Organisation der Navigation zu gewährleisten. [Lyn 09,
3.2]
Nomenklatur
Verständliche Begriffe auf der Webseite sind wichtig, um die vom Nutzer erwartete Information
auch wirklich zufriedenstellend liefern zu können. Insofern ist für Ambernstein eine starke
Anlehnung an die natürliche Sprache – ohne Fachjargon – vorgesehen. [Gar 03, S.103]
Meta-Daten
Um es gemäß der internen Philosophie auch in der internen Verwaltung nicht allzu kompliziert zu
machen, werden entsprechende »Informationen über Informationen« [Gar 03, S. 105] sehr
übersichtlich verwendet.
Dementsprechend gibt es als Meta-Angaben:

• den Namen der Seite
• das Datum der Erstellung
• das Datum der letzten Änderung
• den Verantwortlichen für die Erstellung und die letzte Änderung
• und ggf. die Versionsnummer
Interne Architektur
Es sollen die Ordner und Dateien, die die Struktur, Inhalte und Funktionen beinhalten, im
Folgenden schematisch aufgezählt werden. Dabei wird generell in drei Bereiche unterschieden: den
Informations-Bereich (»web«), den Interaktions-Bereich (»game«) und den Bereich (»global«), der
Elemente funktionalen Ursprungs für eben genannte Bereiche beinhaltet:
66
5 Konzept
•/
• /global
• /game bzw. /web
• /structure
• /layout
• /content
• /behavior
Öffentliche Architektur
Es soll nun die öffentlich sichtbare Sitemap dargestellt werden:
• Home + Link: Spiel starten

• Ambernstein
• Hintergrund
• Beteiligte
• Motivation
• Mission
• eorie
Eine schematische Ansicht des Architekturdiagramms 92 , die mit dem Visual Vocabulary von Jesse
James Garrett erstellt wurde, ist im Anhang zu finden. Auf eine Suchfunktion wurde verzichtet, weil
der Umfang der Seite dieser Funktion nicht gerecht werden würde. [Lyn 09, 3.3]
Idealerweise sollte das Diagramm die Dateien und Verzeichnisse auf dem Server strukturell ähnlich
widerspiegeln. [Lyn 09, 3.4]
5.3.2 Interaktionsdesign
Das Interaktionsdesign beschreibt das mögliche Nutzerverhalten, definiert wie die Anwendung
dieses Verhalten aufnimmt und darauf reagiert. Die Vorstellung davon, wie eine interaktive
Anwendung reagiert, wird in den konzeptionellen Modellen des Nutzers festgelegt. [Gar 03, S.87ff.]
Das darauf folgende Nutzerverhalten lässt sich in sogenannten Task Flows darstellen. [Ung 09, S.
178]
Task Flow
92 interne Bezeichnung einer Sitemap [Gar 03, S.107]
67
5 Konzept
Eine schematische Ansicht des Task Flows ist im Anhang zu finden. Eine früher Task Flow ist in
Abbildung 30 zu sehen.
Abb. 30, Task Flow eines frühen Wireframes
Konzeptionelle Modelle
Da sich der Nutzer auch Gedanken macht, wie die Seite strukturell aufgebaut ist und wo er
Funktionen erwartet, baut er sich im Unterbewusstsein ein Verständnis dafür auf. Sowohl für die
Informationsarchitektur [Lyn 09, 3.3] als auch für das Interaktionsdesign [Gar 03, S.89] ist es
ratsam, sich an diesen Erwartungen zu orientieren. Werden diese Erwartungen nicht erfüllt, neigt
der Nutzer dazu, Fehler zu machen und frustriert zu werden. [Nor 02, S.xi] Laut Norman sind
konzeptionelle Modelle eine Untergruppe der mentalen Modelle. [Nor 02, S.17]
Fehlerbehandlung
Fehler zu begehen ist menschlich. [Nor 02, S.105] Daher müssen sie in entsprechenden Situationen
verhindert, abgefangen und rückgängig gemacht werden können. [Gar 03, S.92ff.] Das Design der
Anwendung muss also präventiv (pro-aktiv), progressiv (aktiv) und retrospektiv [Shn 03a, S.190]
(reaktiv) mit Fehlern umgehen können. 93
Die Fehlerbehandlung arbeitet wie ein Filter. Was der Präventionsfilter nicht behandelt, übernimmt
der Korrekturfilter. Kann der Fehler nicht unmittelbar korrigiert werden, ist es eigentlich schon zu
spät. Hier hil, den Fehler rückgängig zu machen – die bekannte Undo-Funktion ist gemeint. [Coo
07, S.335]
93 http://www.olev.de/r/reaktiv_usw.htm 05.10.2010
68
5 Konzept
5.4 Konkrete Struktur

Nachdem nur bedingt anschaulich die Struktur der Web-Anwendung dargestellt wurde, soll nun
weniger abstrakt gezeigt werden, wie konkret Ambernstein aussehen kann. Die Anforderung an die
konkrete Struktur ist wie auch zuvor schon, einen Kompromiss zu finden aus maximaler
Zugänglichkeit, Lesbarkeit, Immersion in das Urzeit-ema des Spiels und die tragische Story.
5.4.1 Interface Design

Ambernstein ist eine Mischung aus grafischer Benutzeroberfläche (GUI) 94 und einer der
Kommandozeile ähnlichen Oberfläche (CLI) 95, die aus Text aufgebaut wird (TUI) 96.
Benötigte Elemente
In Abbildung 31 sind die benötigten Elemente für das Interface Design des Spiels aufgelistet:
• Grid (Hintergrund)
• Header (Grafik, Text)
• Footer (Text)
• Navigation (Buttons)
• Informationsflächen (Text)
Abb. 31, Frühe Übersicht der UI-Elemente, teilweise mit Funktionsabläufen
94 GUI: Graphical User Interface

95 CLU: Command-Line Interface
96 TUI: Text User Interface
69
5 Konzept
Die benötigten Element unterscheiden sich beim Informations- und Interaktionsmodus von
Ambernstein. Im Folgenden wird auf die Spezifika beider Layouts eingegangen. Zunächst soll aber
die gemeinsame Menge an benötigen Elementen des User Interface beleuchtet werden.
Header
Der Kopf-Bereich der Webseite wird bei beiden Modi vorhanden sein – im Web-Modus deutlich
präsenter als im Spiel-Modus.
Footer
Der Fuß-Bereich als unterster Teil der Webseite wird im Web-Modus nur als Halter für die
Copyright-Informationen dienen. Im Spiel-Modus ist der Footer als interaktives Element für den
Fortschritt im Spiel zu sehen. Je weiter der Spieler voranschreitet, desto mehr offenbart der grafische
Footer.
Layout
Während im Web-Modus das Gitter-Layout nur angedeutet wird, ist es beim Spiel-Modus klarer
Layout-Bestandteil. Die Andeutung des Gitter-Bereichs wurde während des Usability-Tests von
einer Testperson erkannt. Diese gab zu verstehen, dass dort Inhalt zu erwarten sei.
Informationsbereiche
Vorab und während des Spiels wird der Spieler mit Informationen versorgt. Ob es im Web-Modus
die allgemeinen Informationen zur Entstehung des Spiels sind oder die Informationen, die direkt
während des Spiel serviert werden.
Web UI Layout
Zunächst war vorgesehen, Web UI und Game UI gleichaussehend zu gestalten. Der Nutzer sollte
nicht merken, ob er noch auf der Webseite (zur Informationsbeschaffung über das Spiel) oder schon
im Spiel (dem eigentlichen Text-Adventure) ist. Die Idee war dem Nutzer mitzuteilen, er sei einfach
in »Ambernstein«.
Im Sinne der Konsequenz war vorgesehen, für ein rein tastaturgesteuertes Text-Adventure auch ein
tastaturähnliches Gitter-Layout (Grid) für das Interface zu benutzen – Abbildung 32. Es sollte das
Gefühl stärken, dass bei dieser Webseite die Tastatur wirklich im Vordergrund steht. Die Tasten
waren im Vergleich zu einer echten Tastatur in ihrer Anordnung nachvollziehbar verteilt. Man
könnte sich daran stören, dass in der Mitte das Nummernfeld erscheint. Es sollte der Navigation zu
den einzelnen Seiten dienen.
70
5 Konzept
Abb. 32, Frühes Wireframe des Web UI Layouts
Etwas weiter ging die Skizze der Web UI (Abbildung 33), die die unterschiedliche Funktion des
Footers im Web- und Spiel-Modus mit einbezieht.
Abb. 33, Web UI mit Footer als Funktionseinheit
71
5 Konzept
Konzeptionell war es aber nicht ganz zu Ende gedacht, weil die Navigation zu dominant war und
keinen Raum mehr für Inhalte ließ. Inhalts- und Navigationsdesign müssen natürlich in einem
gesunden Verhältnis zueinander stehen. Die Nutzer gehen nach wie vor nicht wegen toller
Funktionen oder Navigationen auf Webseiten [Gar 03, S.36], sondern wegen der Inhalte. [Ung 09, S.
135f.]
Darüber hinaus ist die Mitte auch nicht der typische Ort an dem Menschen die Navigation erwarten
– Abbildung 34 [Lyn 09, 3.4]. Bernard [Ber 01] bestätigt dies.
Abb. 34, Erwartung der Nutzer über den Ort der internen Navigation
Die Erwartung der Nutzer weiterer für Ambernstein relevanter Links sind der Home-, der Hilfe-
und About-Link, sowie die Links zu externen Seiten. Abbildung 35 verdeutlicht diese Erwartungen.
[Lyn 09, 3.4]
72
5 Konzept
Abb. 35, Erwartung der Nutzer über den Ort weiterer Navigationselemente
Für die esc-Taste war neben dem Abbrechen einer Aktion auch das Zurückgehen auf die Home-Seite
vorgesehen. Laut Studie wäre dieser Platz ideal gewesen. In diesem frühen Layout war noch
vorgesehen, dass die Webseite auf den Informationsseiten nur per Tastatur gesteuert werden sollte.
Die Maussteuerung sollte komplett ausgeschaltet werden. Dass das nicht W3C-konform, ist im
Abschnitt 4.6 nachzulesen.
Spezielle Elemente
Wie bereits bei den benötigten Elemente gesagt, gibt es sowohl für den Web- als auch Spiel-Modus
verschiedene Elemente. Im Web-Modus sind folgende Elemente des Interface Designs (Abbildung
36) relevant:
• Umschalten der Ansicht: Desktop, Mobil, Druck, Nur Text

• Navigations-Links
• Informationen zur Tastatur-Navigation (als Ergebnis des Web Usability-Tests)
• Verändern der Schrigröße
• Verändern des Farbschemas
73
5 Konzept
Abb. 36, Web UI Elemente
Es wird deutlich, dass für das Erstellen des User Interfaces die Disziplinen des Interface, Navigation
und Information Design implizit enthalten sind. [Gar 03, S. 115] An dieser Stelle sollen diese
Begriffe in einer kurzen Definition auseinandergehalten werden.
Navigation Design ist dann wichtig, wenn der Nutzer an bestimmte Plätze gehen will. Um eine
optimale Wegfindung (Wayfinding) des Nutzers zu gewährleisten, muss die darunter liegende
Informationsarchitektur gut ausgebaut sein – siehe Abschnitt 5.3.
Interface Design ist immer dann gemeint, wenn es darum geht, etwas zu tun. Es hängt also mit den
funktionalen Anforderungen und der Struktur des Interaktionsdesigns zusammen.
Information Design spielt eine Rolle, wenn Ideen kommuniziert werden müssen. Da eine Webseite
schwerpunktmäßig der Kommunikation dient, ist die Information entsprechend wichtig. Als
umfassendster Bereich schließt er sowohl Aspekte des Navigationsdesigns (Informationsarchitektur)
als auch die des Interface Design (Interaktionsdesign) ein.
Game UI Layout
Wie für das Web UI gelten auch für das Game UI bestimmte Elemente, die nur dort zu finden sein
werden:
74
5 Konzept
• Ausführliche Hilfe / Informationen zur Tastaturnavigation – hier ist Tastaturnavigation zwingend

im Gegensatz zum Web-Modus
• Eingabefeld als Einstieg in die Tastaturwelt und als Gewöhnung (dient der Immersion)
• Bestätigungsbutton für die Eingabe
• Statistikbereich für Spielfortschritt, Fitness des Protagonisten, Anzahl der Bernsteinstücken,
Anzahl der erreichten Punkte
• Grafikausgabe-Bereich
• Textfeld für die Textausgabe
• Bereich für die Darstellung der Aktionen (Benutzen, Gucken, Reden)
• Bereich für die Darstellung der Steuerung
• Bereich für das Inventar
Abb. 37, Game UI
Look and Feel

Farben
Farben sind wichtig. O überstrapaziert soll die Farbwahl nicht unangenehm ins Auge fallen. Es soll
eine Wirkung aus »angenehm« und »modern« beim Betrachten der Farben entstehen. Weiterhin soll
75
5 Konzept
es besondere Farbakzente (Highlights) geben. Für den Hintergrund soll eine helle Farbe gewählt
werden, die mit einer dunkleren Vordergrundfarbe einen ausreichenden Kontrast bietet. [Gar 03, S.
146] Die Farbwahl ist auch im Sinne der Accessibility zu gewährleisten. 97 Die Farbpaletten in
Abbildung 38, 39 und 40 sind für Ambernstein interessant.
Abb. 38, Farbpalette »Accessible« 98 Abb. 39, Zweite Farbpalette »Accessible« 99
Abb. 40, Farbpalette eines Zeitungsartikels
Die in Abbildung 40 gezeigten Farben der Informationsgrafik eines Zeitungsartikels zur

Höhlenmalerei 100 in der Steinzeit wurden mit Hilfe von PHOTOCOPA 101 herausgefiltert.
97http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-contrast.html#visual-audio-
contrast-contrast-techniques-head 05.10.2010
98 http://de-de.colourlovers.com/palette/1089601/Accessible 05.10.2010
99 http://de-de.colourlovers.com/palette/880191/Accessible 05.10.2010
100 Geheimnis Höhlenmalerei, von Manuela Peitz, Welt Kompakt, 16.08.2010
101 Eine Anwendung von http://colourlovers.com
76
5 Konzept
Genannte Farben wurden als Inspiration genommen und ließen eine Palette aus Beige-Tönen,
Dunkel-Grau und mattem Blau entstehen – siehe Abbildung 41.
Abb. 41, Finale Farbpalette für den Web-Modus
Die Farbpalette dient der Konsistenz in der Wahrnehmung und der Wiederkennung. Teilweise
werden für eine bessere und eindeutigere UX Farbnuancen der Palette verwandt, um z.B. Elemente
zu betonen oder als aktiv zu kennzeichnen. Insofern dient die Palette als Übersicht von Richtwerten.
Beispielsweise wird Grau in seinem Palettenwert #333 102 auch als #000, #444 103 und #666 in
Erscheinung treten. Die oben genannte Farbpalette stellt die Standard-Farbpalette dar. Sie wird beim
erstmaligen Begehen der Webseite zu sehen sein. Die Funktion des Wechselns des Farbschemas
ändert die Farbpalette entsprechend radikal.
Die finalen Farben der Abbildung 41 von links nach rechts sind:
1. Hintergrundfarbe
2. Hintergrundfarbe #2
3. Passive Hervorhebung
4. Aktive Textfarbe – als Kontrast zur Hintergrundfarbe
5. Aktive Text-Hintergrundfarbe – als Kontrast zur Textfarbe
6. Aktive Hervorhebung – als Kontrast zu den ersten drei Beige-Nuancen
Für den Spiel-Modus sollte eine davon abgeleitete Palette erstellt werden. Sie ist in Abbildung 42 zu
sehen.
Abb. 42, Finale Farbpalette für den Spiel-Modus
102 http://twitter.com/zeldman/status/11790694779 05.10.2010

103 http://twitter.com/H_FJ/statuses/11800719859 05.10.2010
77
5 Konzept
Die Farben sind wesentlich kräiger und intensiver. Das liegt daran, dass der Hintergrund diesmal
dunkel ist. Dies generiert beim Spieler eine bessere Immersion ins Spiel und fokussiert (im Sinne der
Accessibility) besser den in Weiß dargestellten Text.
Die finalen Farben der Abbildung 42von links nach rechts sind:
1. Hintergrundfarbe
2. Hintergrundfarbe #2
3. Passive Hervorhebung
4. Aktive Textfarbe – als Kontrast zur Hintergrundfarbe
5. Aktive Textfarbe #2
6. Aktive Hervorhebung – als Kontrast zu den ersten beiden Grau-Nuancen
Formen & Elemente

Wie in den entsprechenden Layouts schon zu sehen war, sind die Formen überwiegend mit leichten
Abrundungen versehen. Im Folgenden soll in Abbildung 43 und 44 ein genauerer Blick auf die
möglichen Elemente und deren Form geworfen werden.
Abb. 43, Elemente des Spiel-Modus
Die Elemente des Spiel-Modus (Abbildung 43) enthalten abrundete »Container«-Bereiche 104 für
Text, Grafik und sowie den Statistikbereich für Piktogramme (Icons), die in handgezeichneter
Digitalversion ins Spiel eingebaut werden.
104 weil sie etwas aufbewahren, z.B. Text oder Grafik
78
5 Konzept
Abb. 44, Anordnung der Erklärung zur Steuerung im Spiel-Modus
In Abbildung 44 wird gezeigt wie die Darstellung der wichtigsten Tastaturkombinationen nach dem
Betätigen der H-Taste für »Hilfe« aussehen kann. Die erste Darstellung ordnet sie um den
Spielbereich herum an. Die zweite Darstellung hingegen überlagert den Spielbereich und dunkelt
ihn mit einer Lightbox 105 ab.
5.4.2 Navigationsdesign
Navigation ist ein ganz bedeutender Bestandteil der Webseite. Es geht nicht nur darum, Links zu
setzen, um den Nutzer von A nach B gehen zu lassen. Steve Krug formuliert Navigation als die
Webseite selbst. Ohne sie gäbe es keine Webseite. [Kru 06, S.59] Garrett sieht drei Aufgaben, die das
Navigationsdesign gleichzeitig erfüllen muss: [Gar 03, S.125f.]
• von A nach B gelangen mit gezielter Platzierung von Links

• Kommunikation der Beziehung von Links
• Kommunikation der Beziehung der aktuellen Seite und dem darin enthaltenen Inhalt
105 eine Technik, den Inhaltsbereich einer Webseite komplett zu überlagen – z.B. bei Bildergalerien.
79
5 Konzept
Damit die vielfältigen Bedürfnisse des Besuchers erfüllt werden können, gibt es auch entsprechend
viele Arten von Navigationssystemen – siehe Abbildung 45: [Pre 04]
• Globale Navigation
• Lokale Navigation
• Hilfsnavigation (supplementary)
• Inline-Navigation (contextual)
• Gefälligkeits-Navigation (courtesy)
Abb. 45, Navigationssysteme
Das folgende Beispiel zeigt die IBM-Webseite 106 auf ihr Navigationsdesign hin untersucht – siehe
Abbildung 46. [Pre 04]
106 http://www.ibm.com/
80
5 Konzept
Abb. 46, Navigationssysteme am Beispiel von IBM
5.4.3 Informationsdesign
Wie bereits erfahren ist das Informationsdesign wesentlich für die Art der Darbietung von
Information zuständig. Dies hat den Zweck, dass der Besucher sie einfacher nutzen und verstehen
kann. [Gar 03, S.131] Das optimale Informationsdesign ist dann gefunden, wenn die gruppierten
und arrangierten Informationselemente der Vorstellung und dem Denken vom Nutzer entsprechen.
Optimales Informationsdesign unterstützt den Nutzer zielführend auf seinem Weg zur Erfüllung
seiner Aufgabe und Ziele. [Gar 03, S.134]
Wayfinding
Im Navigationsdesign bereits angedeutet, spielt die Wegfindung auch im Informationsdesign eine
wichtige Rolle. Es umfasst diejenigen Elemente, die nicht der Navigation dienen, z.B. durch die
Nutzung von Farben, Piktogrammen, Beschriungen 107 und spezieller Typografie. [Gar 03, S.135]
Gemäß Lynch muss das Informationsdesign verschiedene Merkmale des Wayfinding 108
berücksichtigen. [Lyn 09, 4.2] Dazu gehören:
• Orientierung
• Routenplanung
107 Labelling systems

108 nach Kevin Lynch, The Image of the City (1960)
81
5 Konzept
• Kognitives Abbilden (mental mapping)

• Abschluss
Die »Orientierung« meint den aktuellen Standort. Die »Routenplanung« oder Routenentscheidung
bezieht sich auf die Frage, ob man den Weg findet, nach dem man auf der Suche ist. Die sogenannte
»mentale Karte« bezieht sich auf die bereits gesammelten Erfahrungen im Raum und die Prognosen
der weiteren Wegfindung. Mit dem »Abschluss« ist gemeint, dass ein Ort erfolgreich gefunden wird.
5.4.4 Wireframes
Basierend auf dem Wissen über Informations-, Interface- und Navigationsdesign können die
Layouts zu Web UI und Game UI nun als Wireframes weiterentwickelt werden.
Es begann – wie beschrieben – mit der Idee eines konsistenten Grid-Layouts im Stil einer Tastatur.
Abb. 47, Frühes Wireframe des Web-Modus Abb. 48, Frühes Wireframe des Spiel-Modus
In Abbildung 47 ist die Weiterentwicklung der UI des Web-Modus aus Abbildung 32 zu sehen. Es
verdeutlicht umso mehr, dass kein Platz für Inhalte gegeben ist, weil die Navigation zu massiv Platz
einnimmt.
Abbildung 48 demonstriert den gleichen Stil wie Abbildung 47. Es zeigt, wie besagte UI-Konsistenz
von Web UI und Game UI aussehen könnte. Die mittlere Ziffern-Navigation und die Return-Taste
ist dem Inhalt des Spiels (in dem Fall das Cover des Spiels) gewichen.
Die Leertaste diente in Web und Game UI universell als Funktionstaste, um den den Ton an- und
auszuschalten. Auch die esc-Taste blieb erhalten, weil sie das Abbrechen bzw. Beenden einer Aktion
bedeuten sollte. Im Web-Modus sollte ursprünglich mit dem zweifachen Drücken einer Zifferntaste
sichergestellt werden, dass wirklich diese Taste gedrückt wurde und es kein Versehen war – im Sinne
82
5 Konzept
der Fehlerbehandlung aus Abschnitt 5.3. Die esc-Taste war im Spiel-Modus für das Beenden des
Spiels und das Zurückgehen auf den Startbildschirm gedacht.
Abb. 49, Konzeptionelles Wireframe des Spiels-Modus
Das in Abbildung 48 gezeigte Wireframe 109 sah in seiner mit Balsamiq Mockups 110 erstellten Ur-
Version zunächst so aus wie Abbildung 49 illustriert.
5.5 Spieldesign
Zum Verständnis des Spieldesigns sind im Wesentlichen folgende Dokumente aus dem Anhang
erforderlich:
• Game Concept
• Game Proposal
• Designdokument – die »Spielbibel«
• Technisches Designdokument
109 teilweise auch als Mock-Up bezeichnet, meint er einen frühen vorzeigbaren Prototypen
110 http://www.balsamiq.com/products/mockups 05.10.2010
83
5 Konzept
Für die weitergehende Konzeption von Ambernstein wird empfohlen, ergänzend die Bachelorarbeit
von Tommy Krüger hinzuzuziehen – Abschnitt 4 »Spielkonzeption«.
5.5.1 Elemente
Die wesentlichen Elemente des Gameplay (ludemes 111 ) sind [KOS 05, S.118ff.]:
• Rewards
• Preparation
• A sense of space
• A solid core mechanic
• A range of challenges
• A range of abilities required to solve the encounter
• Skill required in using the abilities
• A variable feedback system

• e Mastery Problem must be dealt with
• Failure must have a cost
Weitere Paradigmen lauten: [KOS 05, S.70]

• »Get to the other side«
• »Visit every location«
Die letzten beiden Elemente waren eine der ersten Best Practices für Spiele: In Pac-Man kam es
darauf, die Spielfigur überall hinzubewegen, während man in Frogger auf die wortwörtliche andere
Seite gelangen musste. Ambernstein übernimmt als Adventure-Spiel auf jeden Fall das Paradigma,
jede Ecke der Welt zu erkunden. Das Abenteuer, das der Protagonist erlebt, könnte man im Ganzen
als »Get to the other side« bezeichnen.
Die ersten sieben Elemente von oben nach unten

Weiterhin setzt Ambernstein Rewards ein, indem Bernsteinstücke (sogenannte »Ambies«)
gesammelt werden. Die Preparation 112 passiert, indem der Protagonist – ohne zu viel zu verraten –
von seinem Großvater versorgt wird.
111 nach Ben Cousins

112 engl. Vorbereitung
84
5 Konzept
Der Sinn für den Raum wird durch die textuelle Beschreibung der Umgebung erreicht. Die
Kernmechanik des Spiels lässt sich dadurch beschreiben, dass durch Tastaturnavigation und
allgemein bekannte Minispiele eine durch Text beschriebene Welt erkundet wird.
Die Menge an Herausforderungen ist gemäß Drehbuch recht vielfältig, wenn auch beschränkt auf die
Tastaturnavigation und den Kontext der aktuellen Szene. Dadurch sind die Fähigkeiten zur Lösung
und allgemein die Lösungsmöglichkeiten relativ beschränkt. Die Story soll diese beiden Lücken
füllen.
Von den genannten Elementen sind sieben von neun in Ambernstein vorhanden. Die Fähigkeiten
zur Lösung einer Aufgabe können durch einen höheren Schwierigkeitsgrad in den Minispielen
bedient werden. Die Lösungsmöglichkeiten sind durch den linearen Verlauf des Spiels nach wie vor
nicht zu erweitern. Im besten Fall kann Ambernstein also acht von neun Elemente zufriedenstellend
umsetzen.
Die letzten drei Elemente von oben nach unten

Um nun aus der Spiel-Erfahrung eine Lern-Erfahrung zu machen, muss ein variables Feedback-
System verwendet werden – Ambernstein kommt zunächst mit statischem Feedback aus. Weiterhin
muss das Mastery-Problem betrachtet werden: Erfahrene Spieler 113 dürfen nicht von Siegen über
Anfänger oder von dem Erreichen von einfachen Zielen profitieren. Andersherum darf es
Anfängern nicht unmöglich gemacht werden, das Ziel zu erreichen. Die Erfahrung des Spielers muss
im Spiel – egal ob Single- oder Multi-Player – Auswirkungen haben. Genauso muss Misserfolg
entsprechend kosten.
Auch wenn Ambernstein das Mastery-Problem nicht berücksichtigt, werden zumindest Misserfolge
klar gekennzeichnet. Das Drehbuch sieht hierfür vor, dass Misserfolge mit keiner Erhöhung der
Punktezahl bestra wird – dies geschieht aber wiederum absehbar (weil dem linearen Verlauf des
Drehbuchs folgend).
Ambernstein als Lern-Erfahrung zu bezeichnen, wäre zu viel des Guten. Es zielt mit seiner Strategie
klar auf kurzweilige Unterhaltung ab, die dem Gelegenheitsspieler gefallen soll.
113 Spieler mit einer hohen Levelzahl im Spiel
85
5 Konzept
5.5.2 Ein Spiel wie ein Film

Ambernstein ist durch seine Art als Text-Adventure nicht nur ein gespieltes Buch, sondern auch ein
gespielter Film, denn es entsteht aus einem filmischen Drehbuch und wird getragen von einen
offiziellen Soundtrack.
5.5.3 Kurzbeschreibung von Ambernstein

Ambernstein ist ein rein tastaturgesteuertes Spiel für den Web-Browser, das technisch auf HTML5,
CSS3 und JavaScript basiert und besonderen Wert auf Web Usability und Accessibility legt. Die
klassischen Text-Adventures der 1970er und 1980er Jahre zum Vorbild nehmend, spielt es etwas
stärker grafisch orientiert in der fiktiven prähistorischen Steinzeit, in der Neandertaler und Cro-
Magnon-Menschen parallel existierten (zw. 40.000 und 30.000 vor heute, im Jungpaläolithikum).
Die Story nimmt eine tragende Rolle in Ambernstein ein. Deswegen wurde als Startpunkt die
Verfassung der Story in Angriff genommen – laut Rouse III eine der drei validen Methoden, ein
Spiel zu beginnen. [Rou 05, S.45ff.] Im Dokument »Ambernstein – Die Vision« des Anhangs finden
sich weitere Ausführungen zum Spielverlauf.
5.5.4 Spielkonzept
Für die Erstellung des ersten Spielkonzepts wurde ein entsprechender Artikel von Tim Ryan [Rya
99a] hinzugezogen. Die dort herausgearbeiteten Informationen fanden ihren Weg ins
Designdokument zum Spiel – siehe Anhang. Es besteht formell aus:
• einer Einführung
• Hintergrundinformationen
• einer Beschreibung
• wichtigen Spielmerkmalen
• dem Genre
• den Plattformen, für die es entwickelt wird
• Konzeptstudien
5.5.5 Spielvorhaben
Auch für das Spielvorhaben (Proposal), das als Erweiterung des Spielkonzepts gilt, wurde [Rya 99a]
zu Rate gezogen. Darüber hinaus war [Rya 99b] hilfreich. Das Proposal enthält im Wesentlichen:
86
5 Konzept
• ein überarbeitetes Konzept

• eine Marktanalyse
• eine technische Analyse
• eine rechtliche Analyse
• eine Kosten-/Nutzen-Rechnung
• Artwork
Der technische Teil fand vor allem seinen Platz im technischen Designdokument zum Spiel – siehe
Anhang.
87
6
Umsetzung
Drehbuch, Webseite, Spiel.
88
6 Umsetzung
Wie auch in der Konzeptphase soll dieser Abschnitt das Drehbuch, die Webseite und das Spiel an
sich beleuchten. Dem explorativen Denken folgend wurde sich dafür entschlossen, das Spiel aus der
Sicht eines Entwicklers und aus der Sicht eines Konsumenten zu entwickeln, um die Unterschiede zu
erkennen. Streng genommen gibt es noch die Sicht aus der geschälichen Perspektive. [Ung 09, S.
154]
6.1.1 Entwickler und Nutzer

Nach den Erfahrungen von Richard Rouse III [Rou 05, Kap.11] hinsichtlich einer »Designer‘s story«
und einer »Gamer‘s story« und denen von Raph Koster [Kos 05, S.130, 138, 142], dass Menschen
faul seien, Spieldesigner weniger spielen als Spieler und Spieler Spiele hacken 114 , war klar, das es
offensichtlich eine Diskrepanz zwischen dem Produzenten und dem Konsumenten gibt. Aus
empirischen Interesse lag es nahe, seitens der Entwickler beide Rollen zu besetzen und auszuleben.
Tommy Krüger übernahm die Sicht des Entwicklers. Alexander Kluge übernahm die Sicht des
Konsumenten, als »Advokat der Nutzer«. Da auch die Vision des geschälichen Interesses von
Belang ist, übernahm Kluge auch zu Teilen die Sicht des Unternehmens und Projektmanagers. Dies
sollte sich in den Ergebnissen, besonders bei der UX und dem UI widerspiegeln.
6.2 Drehbuch
Die Ausführungen zur Umsetzung des Drehbuchs zeigen nicht den vollen Inhaltsumfang, um nicht
zu viel von der Story zu offenbaren und die esis nicht als Spoiler 115 zu positionieren. Die
Umsetzung des Drehbuchs geschah viel in Papierform – siehe Abbildung 50.
Abb. 50, Etappen der Akte auf Zetteln
114 dem Spiel einen neuen »Sinn« geben, der nicht in der Absicht des Entwicklers lag
115 eine vor der Veröffentlichung einer Sache offenbarte Information, die deren Konsum verderben kann
89
6 Umsetzung
Abbildung 50 zeigt, dass für jeden Akt eine Menge aus 14 Zetteln angefertigt wurde, die die jeweils
wichtigsten Stationen im Akt in wenigen Worten zusammenfasst. Für den zweiten Akt wurde wegen
der doppelten Länge zweimal 14 Zettel beschrieben. Dem Strukturmodell von Syd Field folgend
wurde die Story in mehreren Schritten in drei Akte aufgebaut (Abbildung 51).
Abb. 51, Strukturmodell des Drehbuchs nach Syd Field
Abb. 52, Verlauf der Story in sechs Etappen
90
6 Umsetzung
Darauf folgte der grobe Verlauf der Story, der in Abbildung 52 zu sehen ist. Es wird darauf
hingewiesen, dass das Wissen um die Etappen der Story in Ambernstein den Spielspaß eindämmen
kann. Insofern wird geraten, die Abbildung nicht zu lange zu betrachten bzw. sie vor dem Spielen
nicht zurück ins Gedächtnis zu holen.
Basierend auf diesem Verlauf entstand der Pfad für den ersten Akt, der in Abbildung 53
ausschnittsweise dargestellt wird.
Abb. 53, Pfad des ersten Akts (Ausschnitt)
Ohne den intensiven (mehrwöchigen) Schöpfungsprozess des Drehbuchschreibens zu sehr vertiefen

zu wollen, sollen die Inhalte der drei Akte und allgemeine Struktur zusammengefasst werden.
Für das Schaffen der Akte war Fields Paradigma sehr dienlich, da es half, die Dramaturgie
aufzubauen – also die »lineare Verbindung von [...] Ereignissen, die zusammenhängen und zu einer
dramatischen Auflösung führen.« [Fie 98, S.48]
6.2.1 Erster Akt

Der erste Akt etabliert die Geschichte, führt die Hauptfiguren ein und macht ihre dramatischen
Absichten klar. Sie ist Grundstein für die folgenden Szenen und Sequenzen. Alles geschieht im
dramatischen Kontext des Setup. [Fie 98, S.40f.]
91
6 Umsetzung
6.2.2 Zweiter Akt

Nachdem der erste Akt mit dem ersten Plot Point 116 endet, wird der etwa doppelt so lange zweite
Akt eingeführt. Geprägt vom dramatischen Kontext der Konfrontation reicht er bis zum zweiten Plot
Point, wo erneut eine Wendung zu erwarten ist. Hier finden sich Hindernisse, Konflikte und
Konfrontationen, die bewältigt werden müssen. [Fie 98, S.43f.]
6.2.3 Dritter Akt

Nach der Wendung durch den zweiten Plot Point, findet die Auflösung der Story – als dramatischer
Kontext – im dritten Akt statt. [Fie 98, S.47]
6.3 Webseite
Um den Kern einer Webseite zu erfassen, definiert man sie als UI – also eine Schnittstelle, die mit
einem Nutzer (Menschen) interagiert. Die Arbeit am UI basiert auf Vorgaben in der Literatur,
User-Testing, praxiserprobten Guidelines und sogenannten Best Practices. [Lyn 09, 2.5]
Best Practices finden sich z.B. bei der Firma Isobar 117 . Als sehr hilfreiche Literatur erwies sich –
neben erwähnter anderer Literatur – auch der Web Style Guide [Lyn 09] von Patrick J. Lynch und
Sarah Horton.
6.3.1 Technisch
Für die Umsetzung von Ambernstein wird unter Windows und Mac OSX entwickelt. Dabei kam
TextMate 118 (Mac) und Aptana Studio119 (Windows) zur Anwendung.
Da die Entwicklung vorrangig in HTML5 und CSS3 entstand, wurden entsprechend fähige Browser
120 für die Arbeit benutzt, die diese Technologien gut unterstützen:
• Chrome 5
• Safari 5
116 Ein Ereignis, das die Handlung vorantreibt, eingreift und ggf. dreht.
117 http://molecularvoices.molecular.com/standards/ 05.10.2010
118 http://macromates.com/ 05.10.2010
119 http://www.aptana.com/ 05.10.2010
120 http://html5readiness.com/ 05.10.2010
92
6 Umsetzung
Interessant ist dabei, dass beide Browsern auf WebKit 121 basieren.
HTML5 Boilerplate
Als Startpunkt für die UI-Entwicklung diente HTML5 Boilerplate. Dieses u.a. von Paul Irish
veröffentlichte Template, dient als Kick-Start eines jeden HTML5-Projekts.
Seine Vorteile sind:

• Browserübergreifende Kompatibilität (inkl. Internet Explorer 6)
• IE-spezifische Klassen, um separate Stylesheet-Dateien zu vermeiden
Außerdem enthält es:

• eine HTML5-Erweiterung 122 des CSS Resets 123 von Eric Meyer
• Modernizr 124
Modernizr dient der Erkennung von HTML5-Elementen und deren Aktivierung. CSS Resets setzen
die Standardinterpretationen der Browser zurück. Das ist nötig, weil Browser das CSS
unterschiedlich interpretieren und entsprechend ausgeben. Mit CSS Resets können CSS-
Definitionen auf einer gemeinsamen Basis geschehen.
Alternativen
Alternativ zu HTML5 Boilerplate ist auch möglich, HTML5 Reset 125 einzusetzen. Es hat einen
ähnlichen Ansatz und setzt auch auf ähnliche Best Practices. Es ist Geschmacksache. Für
Ambernstein empfahl sich HTML5 Boilerplate, weil der Einstieg per Video einfacher war.
jQuery
Wesentlich für die Entwicklung ist auch jQuery – ein Javascript-Framework, dass eine gute Browser-
Unterstützung bietet und kürzeren Code benötigt als natives JavaScript. Weitere Soware und
technische Belange für Ambernstein sind Tommy Krügers esis im Abschnitt »Umsetzung« zu
entnehmen.
121 http://webkit.org/ 05.10.2010

122 http://html5doctor.com/html-5-reset-stylesheet/ 05.10.2010
123 http://meyerweb.com/eric/tools/css/reset/ 05.10.2010
124 http://www.modernizr.com/ 05.10.2010
125 http://html5reset.org/ 05.10.2010
93
6 Umsetzung
6.3.2 Visuelles Design

Die Weiterentwicklung des Konzepts für den Web-Modus ist in Abbildung 54 zu sehen.
Abb. 54, Visuelles Design der Webseite
Wie in Abbildung 54 zu sehen, wurde für Ambernstein eine Auswahl von vier Prinzipien der
Gestalt-Psychologie verwandt. [Lyn09, 7.4] Konkret lauten diese:
• Proximity
• Similarity
• Continuity
• Uniform connectedness
Die Gestalt-Prinzipien bei Ambernstein

»Proximity« meint, dass Elemente, die nahe beieinander liegen, auch miteinander in Relation stehen.
In Ambernstein sind dies von oben nach unten:
• der Bereich »Ansicht wechseln«

• der Hinweis »Navigiere per Tastatur«
• die Überschri samt Beschreibung
94
6 Umsetzung
• die bezifferten Navigationsflächen

• der Bereich für die Änderung von Textgröße und Farbschema
Abb. 55, Die Gestalt-Prinzipien der Nähe, Ähnlichkeit und Kontinuität
Die »Similarity« wird besonders bei den bezifferten Navigationsflächen deutlich. Durch den starken
Kontrast von weißer Hintergrundfarbe und dunkelgrauem Text wird Gleichheit dieser Elemente
sofort deutlich.
Die »Continuity« ist in Ambernstein nur indirekt berücksichtigt worden. Gemeint ist der
Hintergrund, der als Grid [Gar 03, S.148] den dunkleren Hintergrund ausmacht. Die dortigen
Gitterlinien sind streng genommen allerdings nicht – wie gefordert – kontinuierlich. Da das Gitter
nicht primär – wenn überhaupt – aktiv wahrgenommen wird, scheint ein Befolgen dieses Prinzips
für Ambernstein nicht allzu große Konsequenzen zu haben.
Das Prinzip der »Uniform connectedness« meint Elemente, die von anderen Elementen
eingeschlossen werden. In Ambernstein ist dies bei den bezifferten Navigationsflächen zu sehen. Die
Fläche »Spiel starten – 1« umschließt mit seiner Länge bzw. Breite die darunter liegenden in
Dreiergruppen angeordneten uniformen Elemente.
Abbildung 55 fasst die ersten drei Prinzipien grafisch zusammen. In Abbildung 56 wird das vierte
Prinzip schematisch illustriert und wie in Abbildung 55 mit einer kurzen Erklärung versehen.
95
6 Umsetzung
Abb. 56, Das Gestalt-Prinzip der »uniformen Verbundenheit«
6.4 Spiel
6.4.1 Technisch
Für die technische Umsetzung des Spiels soll auf Abschnitt 5 »Umsetzung« der Arbeit von Tommy
Krüger verwiesen werden. Dort wird die Umsetzung des Text-Parsers, sowie die der Mini-Spiele so
detailliert wie nötig erklärt. Unter anderem wird auf die Umsetzung von Sokoban und dem
Bilderrätsel Rebus eingegangen. Darüber hinaus wird die Ajax-Architektur und die Verwendung von
PHP erläutert.
6.4.2 Visuelles Design

Das visuelle Design für den Spiel-‐Modus ist angelehnt an den Web-‐Modus. Abbildung 57 zeigt den
aktuellen Stand des Prototypen in einem einfachen Farbschema. Die für das Spiel gedachte
FarbpaleDe findet in späteren Versionen, die außeruniversitär entwickelt werden,
BerücksichLgung. In der Abbildung soll zu erkennen sein, dass der KopOereich ganz oben
schlanker geworden ist und den Titel »Ambernstein« in anderer Form darstellt als zuvor. Zum
Zwecke des Spielerlebnisses und des Wechsels von InformaLons-‐ in Spiel-‐Modus soll der SchriTzug
ganz klar zeigen, in welchem Bereich (Modus) von Ambernstein man sich gerade befindet.
Die in den vorigen AbschniDen angesprochene Verbindung von Game UI und Web UI wird in
Abbildung 58 dargestellt. Die Verbindung baut sich dadurch auf, dass sonst passive Elemente der
Webseite eine FunkLon bekommen, also: Header 126, Hintergrund und Footer 127. Die Abbildung
126 Kopfbereich einer Webseite ganz oben

127 Fußbereich einer Webseite ganz unten
96
6 Umsetzung
illustriert, dass je nach geografischem Ort und besonderer SituaLon des Protagonisten in der Story
sich besagte Elemente einfärben.
Abb. 57, Visuelles Design des Spiels
Abb. 58, Visuelle Verbindung von Game UI und Web UI
97
6 Umsetzung
Die für die Abbildung 58 verwendete Farbpalette nennt sich »Gentle Waves« 128 . Sie ist in Abbildung
59 dargestellt und steht optisch für die Flusslandscha in der Story.
Abb. 59, Farbpalette »Gentle Waves«
In Abbildung 60 ist der Fortschritt das Spiels zu sehen. Anhang von zu den sechs Subwelten
passenden Icons wird dem Spieler gezeigt, wie weit er im Spiel ist. Dies dient als Hilfsmittel der
Orientierung in zeitlicher Hinsicht und als Motivation, weiterzuspielen.
Abb. 60, Visueller Fortschritt im Footer
6.5 Angewandte Datenstruktur

Die angewandte Datei- und Ordnerstruktur ist relativ einfach gehalten und hält sich in ihren
Grundzügen an die Architektur, die im Konzeptteil der esis festgehalten wurde – siehe Abbildung
61.
128 http://de-de.colourlovers.com/palette/475875/Gentle_Waves 05.10.2010
98
6 Umsetzung
Abb. 61, Datenstruktur
In der esis von Tommy Krüger ist im Abschnitt »Umsetzung« die Struktur ebenfalls erwähnt. Er
geht dabei auf die Struktur, die sich im Ordner »game« der Abbildung 61 befindet, ein.
6.6 Eingesetzte Software

In diesem sechsten Abschnitt der esis wurden genutzte Soware und Frameworks bereits
erwähnt. Tommy Krüger geht in seiner theoretischen Arbeit im Abschnitt 5.4 »Verwendete
Programmiersprachen und Bibliotheken« noch genauer auf den XML-Parser, das Format XML und
die Verbindung mit JavaScript ein.
6.7 Nicht umgesetzte Funktionen

Ziel dieser theoretischen Arbeit mit begleitendem Praxisprojekt war es, einen explorativen
Prototypen zu erstellen, der als Proof-of-Concept dient. Dementsprechend sind die für das
theoretische Verständnis des Spiels nötigen Funktionen und Inhalte umgesetzt worden. Dennoch
soll zunächst gezeigt werden, was im Rahmen der Bachelorarbeit erarbeitet wurde.
Umgesetzt wurden:
• ein Drehbuch, das der halben Länge eines Kinofilms entspricht
• inklusive Soundtrack
• ein Strategiedokument mit der internen Vision des Spiels, sowie den Nutzerzielen
• inklusive einer Visual Identity
• ein Designdokument für das Spiel
• ein UI für den Web-Modus, das in einem iterativen Prozess mit begleitenden Usability-Tests
entwickelt wurde
• erste Entwürfe für das UI des Spiel-Modus
Was nicht umgesetzt wurde, ist in Tommy Krügers esis – Abschnitt 5.7 – nachzulesen.
99
6 Umsetzung
6.8 Probleme und Herausforderungen

Es bestand vor allem die Schwierigkeit, zu klären, ob wir ein Spiel oder eine Webseite bauen. Da wir
vorrangig von einem Browser-Spiel sprachen, einigten wir uns darauf, dass wir ein Spiel bauen, dass
eben im Kontext einer Webseite funktioniert. Webseiten und Spiele sind i.d.R. verschieden.
Andersherum betrachtet könnte man allerdings sagen, dass Webseiten immer mehr zu Web-
Applikationen werden und somit der Grad der Interaktivität – sprich die Domäne der Spiele – steigt.
Insofern ist die Zielsetzung küniger Webseiten interaktive Erfahrungen – wie in Spielen – auf
Webseiten zu generieren. Das Spiel wir zur Webseite, die Webseite zum Spiel.
Außerdem kamen die folgenden Fragen auf:

• Was passiert mit dem Spielstand, wenn der Spieler die Seite neu lädt?
• Was passiert, wenn JavaScript deaktiviert ist?
6.7.1 Lösungen für das Neuladen der Webseite

Um den Spielstand des Spiels nicht zu verlieren, könnte man per Cookie die nötigen Informationen
speichern. Diese würden dann dauerha oder bis zum Time-Out auf dem Rechner des Nutzers
liegen. Alternative wäre die Anbindung an eine Datenbank denkbar, indem der aktuelle Stand der
IP-Adresse des Spielers gespeichert wird – dies wäre noch zeitsensitiver als die Lösung per Cookie,
weil sich die IP i.d.R. beim Normalverbraucher mit jeder neuen Verbindung zum Internet
dynamisch (DHCP) ändert.
Es könnte außerdem über ein System zur Nutzerverwaltung nachgedacht werden. Dabei würde ein
Spieler sich per Nutzername und Passwort anmelden und könnte am gewünschten Spielstand
weiterspielen. Angesichts der Kürze der Spielzeit, müsste über den Sinn eines solchen Systems
nachgedacht werden. Nicht jeder Spieler möchte sich für das Spielen eines Text-Adventures
anmelden. Demnach wäre die Lösung ein optionales Login: Wer seinen Spielstand speichern
möchte, hinterlegt seine Daten. Wer das Spiel in einer Sitzung durchspielt oder beim nächsten
Besuch der Webseite von vorne beginnen möchte, ignoriert diese Option.
Die zuvor beschriebenen Lösungen funktionieren serverseitig bzw. mit einer Mischung aus
serverseitiger (PHP) und clientseitiger (Cookie) Funktion. Die Alternative wäre die rein clientseitige
Lösung, das Neuladen-Funktion eines Browsers z.B. per F5 zu verhindern. Dies funktioniert mit nur
wenigen Zeilen JavaScript 129 und ist ein geringer, wenn auch nicht unumstrittener, Aufwand.
129http://stackoverflow.com/questions/3527041/prevent-any-form-of-page-refresh-using-jquery-javascript
06.10.2010
100
6 Umsetzung
6.7.2 Lösungen für deaktiviertes JavaScript

Da laut W3C-Vorgabe Ambernstein auch ohne aktiviertes JavaScript (CSJS) gespielt werden sollte,
werden sich nun Ansätze überlegt, diese Anforderung zu erfüllen.
Da das Spiel von Eingaben, die per JavaScript empfangen werden, abhängt, müsste man auf native
Mittel wie den Tab-Index setzen. Ein flüssiges Gameplay wäre dann aber nicht mehr garantiert. Wie
im Fazit der Analyse bereits erwähnt, läu ohne CSJS nichts in Ambernstein so wie es von den
Entwicklern gewollt ist.
Statt sich mit diesem Umstand abzufinden, sollen denkbare Lösungen für das Problem betrachtet
werden. Das ist zum einen Server-side JavaScript (SSJS) wie z.B. CommonJS 130 oder zum anderen
eine PHP-basierte Lösung. In beiden Lösungen ist ohne aktiviertes CSJS der Tab-Index oder die
browser-spezifische Tastenkombination für den Accesskey nötig – z.B. unter Mac OSX im Safari-
Browser per Tastenkombination von Ctrl, Alt und der Ziffer des Accesskeys.
Die Tabelle 7 fasst denkbare Lösungsansätze zusammen.
Lösung Anmerkung Fazit
Spiel-Engine mit PHP serverseitig Eingaben im Browser durch den +/– Inhaltsdarbietung möglich /
implementieren Spieler müssen durch JavaScript Interaktion nicht
passieren
– Verstößt gegen die selbst
auferlegte Vorgabe, native
Browser-Technologien zu nutzen
– Löst das Problem nicht
Spiel-Engine mit SSJS serverseitig Eingaben im Browser durch den + Berücksichtigt die selbst
implementieren Spieler müssen durch JavaScript auferlegte Vorgabe, native
passieren Browser-Technologien zu nutzen
+/– Inhaltsdarbietung möglich /

Interaktion nicht
+/– Unterstützung durch den Web

Server muss gewährleistet sein
– Löst das Problem nicht
Spiel-Engine serverseitig Eingaben geschehen nicht im – Keine Interaktions-Möglichkeit

implementiert und -Eingaben Browser durch den Spieler durch den Spieler
serverseitig gesteuert
(ferngesteuert) – Spieler entmündigt und evtl.
frustriert
– Spiel ist wie ein autarker

selbstablaufender Film
Tab. 7, Lösungen für deaktiviertes JavaScript
130 http://www.commonjs.org/
101
7
Test
Heuristiken, Usability, Browser.
102
7 Test
Zum Test der Webseite wurden Usability-Tests durchgeführt, bei dem vier 131 Testpersonen ihre
Gedanken und Handeln laut aussprechen sollten (inking Aloud). Vor dem eigentlichen Test wurde
per Card-Sorting – eine der möglichen benutzerorientierten Methoden [Har 00, S.62] –
herausgefunden, wie die Anordnung der Navigation am Intuitivsten ist. Basierend auf diesen
Erkenntnisse wurden vier 132 Personas erstellt, die für eine bestimmte Nutzergruppe stehen. Das US-
Gesundheitsministeriums (HHS) stellt auf seiner Webseite noch weitere Methoden 133 vor. Einen
guten Einstieg in die Usability liefert auch der »Arbeitsbereich Usability Engineering« der
Universität des Saarlandes. 134
Die Testkandidaten waren 24 und 25 sowie 49 und 50 Jahre alt – ein weiblicher Kandidat und drei
männliche Kandidaten. Die Testumgebung für den Usability-Test war Mac OSX 10.6.4, Safari
Browser in der Version 5.0.2, so wie ein Browser-Viewport von 934 x 720 Pixel.
7.2 Testauswahl
Im Folgenden sollen mögliche Tests gezeigt werden, die für Ambernstein relevant sind und in
Zukun werden. Für die spätere Durchführung der Tests wurde nur ein Teil der hier vorgestellten
Auswahl berücksichtigt, da der zeitliche Aufwand sonst zu groß gewesen wäre.
7.2.1 Browser-Tests
Browser-Tests finden mit den Web-Browsern statt, auf denen später die Webseite dargestellt werden
soll. Dabei richtet man sich nach aktuellen Nutzungstrends und unterstützten Technologien im
Browser selbst.
Screenreader
Eine ganz besondere Form des Browser ist der Screenreader 135 . Er spricht den Inhalt der Webseite
aus, um Menschen mit Sichteinschränkungen des Surfen im Web zu ermöglichen. [Mcb 10, HTML
Presentation]
131 Nielsen empfiehlt fünf Testpersonen [Nie 00]

132 Shneidermann empfiehlt drei bis Personas [Shn 03a, S. 8]
133 http://usability.gov/methods/index.html 05.10.2010
134 http://usability.is.uni-sb.de/ 05.10.2010
135 engl. Bildschirmleseprogramm
103
7 Test
7.2.2 Usability-Tests
Zur Auswertung der Usability unterscheidet man zwei grundsätzliche Verfahren: expertenzentrierte
Methoden (z.B. Heuristische Evaluation) und nutzerzentrierte Methoden (z.B. Usability Testing mit
lautem Denken) [Har 00, S.62]
Thinking Aloud
Lautes Denken meint während der Testphase, dass jedes Handeln und Denken laut ausgesprochen
wird. [Har 00, S.63] In der späteren Durchführung dieser Methode erwies sie sich als sehr
brauchbar und praxistauglich.
Task-Analysis
Task-Analysis meint, dass jede Interaktion vom Nutzer mit der Webseite in dem Kontext einer
Aufgabe geschieht. Bei dieser Analyse werden die Schritte dokumentiert, die für das Lösen der
Aufgaben nötig waren. Dabei hält man Interviews oder beobachtet den Nutzer in seiner »gewohnten
Umgebung«. [Gar 03, S.52] Diese Methode ist stark verbunden mit dem sogenannten Contextual
Inquiry, das eine Menge von Vorgehen beinhaltet, um Menschen im Kontext des alltäglichen Lebens
zu verstehen. [Ung 09, S.92]
Card-Sorting
Beim Card-Sorting werden Testpersonen gebeten, mit bestimmten Titeln beschriete Zettel so zu
sortieren, dass sie für die Person einen Sinn ergeben. [Ung 09, S.93]
Personas
Personas sind Dokumente, die typische Nutzer der Zielgruppe beschreiben. [Ung 09, S.113] In der
Regel umfassen diese Dokumente Namen, Alter, Job, Ort, eine kurze Biographie sowie ein
charakteristisches Zitat. [Lyn 09, 2.5]
Eye-Tracking
Eye-Tracking 136 gilt als eine der einfachsten Usability-Tests, weil es naheliegt, dem Auge zu »folgen«,
um dadurch herauszufinden, wo die größte Aufmerksamkeit beim Nutzen der Webseite liegt. [Gar
03, S.144]
136 http://www.useit.com/eyetracking/ 06.10.2010
104
7 Test
7.2.3 Benutzerbefragung
Neben Interviews und Umfragen [Ung 09, S.92] gibt es den System Usability Scale (SUS), der mit
Hilfe eines Fragebogens die Usability von Systemen bewertet. [Mei 10]
7.2.4 »Quick-Experience«
Die Verbesserung der Usability ist auch von wirtschalichem Interesse. Insofern verwundert es
nicht, dass es Firmen wie eparo 137 gibt, die Kunden der freien Marktwirtscha Usability-Tests
anbieten. Sie nennen ihren Test »Quick Experience«. Vor allem die einfache und schnelle Integration
dieser Methode in laufende Prozesse des Unternehmen wird u.a. als Vorteil herausgestellt.
7.2.5 Forschungsbasierte Richtlinien

Forschungsbasierte Richtlinien können zum Testen der Usability eingesetzt werden, im besten Fall
als Ergänzung zu speziellen Tests der Zielgruppe. Hierzu sind die Richtlinien des US-
Gesundheitsministeriums (HHS) empfehlenswert. [Shn 03a] Sie werden auch von Steve Krug
explizit empfohlen. [Kru 06, S.191]
7.2.6 Best Practices

Erfahrungswerte und tatsächliche Umsetzungen anderer Menschen und Unternehmen des Umfelds
sind auch sehr gut geeignet, um diese für seinen eigenen Projekte oder Kunden anzuwenden. Die
Firma Isobar (vormals Molecular) hat ihre de-facto Code-Standards 138 veröffentlicht, um vor allem
die Teamarbeit zu erleichtern und eine »gleiche Sprache» beim Schreiben von Quell-Code zu
sprechen.
Weniger auf Code abzielend, hat Sarah Horton [Hor 05] eine Anleitung zu Universal Usability
erstellt, die sich ähnlich anschaulich darstellt wie Lynch [Lyn 09]. Als Einstieg in Usability und
Accessibility ist diese Literatur sehr ratsam und empfehlenswert.
Bezüglich der Accessibility gibt es außerdem die von Mark Pilgrim verfasste Anleitung Dive Into
Accessibility 139 (2002) , welche verspricht in 30 Tagen eine Webseite mit höherer Zugänglichkeit zu
haben.
137 http://www.eparo.de/services#usabilitytests 06.10.2010

138 http://molecularvoices.molecular.com/standards/ 06.10.2010
139 http://diveintoaccessibility.org/ 06.10.2010
105
7 Test
7.2.7 Heuristiken
Jakob Nielsen formulierte 2005 zehn Heuristiken, die für die Gebrauchstauglichkeit eines UI wichtig
sind: [Nie 05]
1. Visibility of system status

2. Match between system and the real world
3. User control and freedom
4. Consistency and standards
5. Error prevention
6. Recognition rather than recall
7. Flexibility and efficiency of use
8. Aesthetic and minimalist design
9. Help users recognize, diagnose, and recover from errors
10. Help and documentation
Anhand dieser Daumenregeln kann die bisherige Usability analysiert werden. Zum Nachlesen über
Usability-Heuristiken eignet sich Jens Meierts Blogeintrag 140 sowie [Dan 01].
Spiel-Heuristiken
Melissa A. Federoff stellt in ihrer Studie [Fed 02] recherchierte Heuristiken und Usability-
Richtlinien zur Erstellung und Auswertung von Spaß in Videospielen zusammen und beru sich
dabei auch auf die zehn Heuristiken von Nielsen. [Fed 02, S. 16ff.] Für Ambernstein sind diese
während und nach der Entwicklung interessant und relevant.
Die drei Bereiche, die man hinsichtlich der Game Usability verbessern kann, lauten: [Fed 02, S. 10f.]
• Game Interface
• Game Mechanics
• Game Play
Besagte Heuristiken sollen nun in Bezug die drei Bereiche auszugsweise aufgeführt werden: [Fed 02,
S. 41ff.]
Bereich Heuristiken
Game Interface intuitiv, Konsistenz in visueller Erscheinung, minimale Menüs
140 http://meiert.com/de/publications/articles/20051218/ 05.10.2010
106
7 Test
Bereich Heuristiken
Game Mechanics natürlich, schnelles und einfaches Involvieren ins Spiel
Game Play »easy to learn, hard to master« Nolan Bushnell
Tab. 8 – Heuristiken für Game Usability (Auswahl)
Bezüglich des Gameplay sind Parallelen zu den Elementen in Abschnitt 5.5.1 dieser esis
festzustellen.
Alternative Test-Methoden
• FiveSecondTest 141
• »Silverback« 142
• Eye-Tracking
• AttrakDiff 143
7.3 Durchführung
7.3.1 Card-Sorting
Die Testpersonen wurden gebeten, sieben ungeordnete Zettel 144 so anzuordnen, wie es ihnen
intuitiv erschien. Ihnen war das ema, das Spiel und der Name des Spiels nicht bekannt. Für Card-
Sorting empfiehlt Nielsen zwar mehr als fünf Nutzer [Nie 04] – für den Anteil der Testteils an dieser
Arbeit wurden vier Tester allerdings als genug Aufwand angesehen.
Ergebnisse
25 J. männlich Ambernstein, Beteiligte, Motivation, Theorie lesen, Hintergrund, Spiel starten,
Mission
24 J. männlich Motivation, Theorie lesen, Hintergrund, Spiel starten, Beteiligte, Ambernstein,

Mission
49 J. männlich Mission, Beteiligte, Theorie lesen, Motivation, Ambernstein, Hintergrund, Spiel

starten
50 J. weiblich Ambernstein, Hintergrund, Motivation, Mission, Beteiligte, Theorie lesen, Spiel

starten
Tab. 9, Ergebnisse des Usability-Tests
141 http://fivesecondtest.com/ 05.10.2010

142 http://silverbackapp.com/ 05.10.2010
143 http://www.attrakdiff.de/ 05.10.2010
144 alternativ auch per Web-Software – http://websort.net/ 05.10.2010
107
7 Test
Fazit
Fasst man die Ergebnisse nun zusammen, könnte die Reihenfolge als Kompromiss so aussehen:
1. Ambernstein
2. Beteiligte
3. Motivation
4. Mission
5. eorie lesen
6. Hintergrund
7. Spiel starten
7.3.2 Card-Sorting #2
Für zwei der Kandidaten wurde der Test wiederholt. Sie wussten nach dem Usability-Test nun über
das Spiel Bescheid. Zwischen den einzelnen Test lagen jeweils einige Tage, um die Erinnerung
schwach zu halten.
Ergebnisse
#1: 49 J. männlich Ambernstein, Spiel starten, Beteiligte, Mission, Motivation, Hintergrund,
Theorie dahinter
#2: 50 J. weiblich Ambernstein, Theorie dahinter, Hintergrund, Motivation, Mission, Beteiligte,

Spiel starten
Tab. 10, Ergebnisse des Card-Sorting
Fazit
Es ist wie beim ersten Card-Sorting schwierig, einen Kompromiss zu finden, weil Kandidat #1 bis
auf die erste Position genau entgegensetzt zu Kandidat #2 die Reihenfolge als intuitiv sieht. Sie
beginnen beide »Ambernstein«.
7.3.3 Web Usability

Nach ISO-Definition gelten für Web Usability momentan drei Eigenschaen:
• Effektivität
• Effizienz
• Zufriedenheit
108
7 Test
Zunächst sollte die Webseite, auf der man sich über Ambernstein informieren kann, auf ihre
Usability getestet werden. Den Testpersonen wurde gesagt, dass sie laut sagen sollen, was sie denken,
sehen und was sie intuitiv machen würden und es machen. Es wurde so vorgegangen, dass die
Person – nach persönlicher Befragung der Person und Einschätzung des Testers – mit der geringsten
Erfahrung von der Bedienung des Computers und des Webs zuerst getestet wurde. Dass es ein Test
sei, wurde ihr nicht ausdrücklich zu verstehen gegeben. Weitere Information zu den Ergebnissen
dieses Tests sind im Anhang zu finden. Im Folgenden sollen nur kurze Zusammenfassungen
gegeben werden.
#1: 50 J. weiblich
Vorbemerkung: Die Steuerung per Tastatur auf Webseiten war der Person nicht bekannt.
Abb. 62, Webseite für Testperson #1
Die Testperson bekam die in Abbildung 62 dargestellte Version der Webseite zu sehen. Bei der
Person gab es vor allem Probleme bei der Wahl der richtigen Tasten, z.B. hielt sie die Leertaste für
die Tab-Taste. Nach einem Hinweis des Testers, wurden die Tasten aber erkannt. Die
Gesamtwirkung der Webseite empfand die Person als seriös und wie »Urlaub« aussehend. Das selbst
gezeichnete Eye-Tracking der Testperson verlief ideal!
109
7 Test
#2: 24 J. männlich
Vorbemerkung: Die Steuerung per Tastatur auf Webseiten war der Person bekannt.
Abb. 63, Webseite für Testperson #2, #3 und #4
Die folgenden drei Testpersonen bekamen die in Abbildung 63 dargestellte Version der Webseite zu
sehen. Auch bei dieser Person gab es Probleme beim Erkennen der richtigen Tasten, vor allem »Ctrl«
und »Shi«. Insgesamt empfand die Person die Webseite als gefällig was die Farben anging. Er hat
verstanden was es mit Ambernstein auf sich hat – mit dem Begriff konnte er zuvor beim Card-
Sorting nichts anfangen. Interessant war, dass die Person erkannte, dass der dunkle Bereich für das
Spiel reserviert war. Das gezeichnete Eye-Tracking verlief beinahe ideal – die Person las allerdings
von oben nach unten, statt zu scannen. 145
#3: 25 J. männlich
Vorbemerkung: Die Steuerung per Tastatur auf Webseiten war der Person nicht bekannt.
Die Testperson zeigte erneut Schwächen beim Erkennen der Tab- und Shi-Taste. Die Webseite
gefiel ihr insgesamt nicht so gut. Sie empfand sie als »langweilig«, weil sie nicht wusste, was sie dort
machen könne. Es war zu viel Text dargestellt, der sie laut eigener Aussage »nervte«. Allerdings
erkannte sie, dass es ein Spiel ist und kam dann auch mit der Tab-Navigation zurecht. Das Eye-
Tracking verlief ähnlich wie bei Testperson #3 – den eigenen Augenverlauf zeichnete sie allerdings
auf einer zeitlichen Achse. Außerdem scannte die Person – im Gegensatz zu Person #3 – die
145 http://www.useit.com/alertbox/9710a.html 06.10.2010
110
7 Test
Webseite, ohne auf den Inhalt zu achten. Das Ergebnis aus diesem Test war eins der Wichtigsten,
weil sie guten Aufschluss über das Denken und Verhalten der Zielgruppe gab.
#4: 50 J. männlich
Vorbemerkung: Die Steuerung per Tastatur auf Webseiten war der Person bekannt.
Die Tab-Taste war der Person klar, die Shi-Taste allerdings nicht. Insgesamt war für die Testperson
auch nach längerem Betrachten der Webseite das Fazit »unbekanntes Objekt«. Dennoch bekundete
er explizit Interesse für das was dahinterstecken möge – ohne inking Aloud wäre diese
Information verborgen geblieben. Die Webseite sprach ihn insgesamt »normal« an. Das Eye-
Tracking sah auf der Zeichnung der Testperson wie ein Schneckenhaus aus.
Abb. 64, Anpassung der Webseite mit Feedback von Testperson #1
Maßnahmen
Nach den Erfahrungen der Tests und den ersten Anpassungen nach dem Ergebnis von Person #1,
sollten nun weitere Anpassungen an das UI stattfinden. Die Auswertung der ersten Anpassung fand
wiederum mit Person #1 statt. Sie gab ihr Feedback, was die Basis für die weitere Feinabstimmung
bildetet. In Abbildung 64 und 65 ist die herausgearbeitete Version der Webseite zu sehen.
Testperson #1, #2 und #4 äußerten sich dann zu der Anpassung und befanden es als »einfacher«,
»eindeutiger« und »übersichtlicher«, vor allem in Bezug auf die Navigation. Interessant war
allerdings das Feedback von Person #1, als die Schaltfläche »Spiel starten – 0« nicht Weiß auf Blau,
111
7 Test
sondern Dunkelgrau auf Weiß dargestellt war. Ersteres leitet das Auge laut eigener Aussage der
Person direkt auf die Schaltfläche, Letzteres hingegen lässt den Blick auf den Titel »Ambernstein«
schweifen.
Abb. 65, Anpassung #2 der Webseite mit Feedback von Testperson #1
Abb. 66, Finale Anpassung der Webseite mit Feedback von Testperson #1
112
7 Test
Diese Erkenntnis war wichtig, da zunächst erkannt werden soll, um welches Spiel es sich handelt.
Außerdem wurde die Textfarbe von »Textgröße« und »Farbschema« reinem Weiß angenähert, da die
Texte sonst drohten, nicht erkannt zu werden. Daraus ergab sich die in Abbildung 54 des vorigen
Abschnitts gezeigte Version der Webseite. Sie spiegelt den aktuellen Stand der Entwicklung wieder.
Abbildung 66 illustriert wie die Darstellung dem dem Klicken bzw. Drücken auf »Wie du diese Seite
per Tastatur steuerst:«.
7.3.4 Game Usability

Im Gegensatz zur Web Usability kann man Effektivität und Effizienz nur bedingt in der Game
Usability anwenden. Typischerweise misst man damit die Produktivität von Soware. In einem Spiel
geht es aber o darum, aus der Produktivität zu flüchten. [Fed 02, S. 8]
Nach Raph Koster erfolgt – streng genommen – der beste Test des Spielspaßes, indem auf die
Ausgabe von Grafik, Musik, Sound und Story verzichtet wird. Der Test ist ohne Weiteres für
Ambernstein machbar. Übrig bleiben dann noch die Mini-Games, die ohne Grafik als einfache
Klötzchen oder eben gar nicht dargestellt würden. Wenn Letzteres Spaß macht, dann werden alle
weiteren Elemente dazu dienen, das Spielerlebnis zu fokussieren, zu verfeinern und insgesamt zu
vergrößern.[KOS 05, S.166]
Der zeitliche Rahmen dieser Arbeit ließ keine umfangreichen Tests der Game Usability zu. Insofern,
ist es möglich sich an bekannten Usability-Heuristiken für Spiele [Fed 02, S. 41ff.] zu orientieren.
113
8
Konklusion
Zusammenfassung, Fazit, Ausblick.
114
8 Konklusion
Während der Entwicklung von Ambernstein wurde klar, dass Text-Adventures ihren Platz in Bereich
der Spiel und Historie haben. Erwähnter Artikel über »Wortspiele« [Nee 10a], diverse Webseiten,
Archive und nicht zuletzt die erst im August 2010 erschienene DVD-Dokumentation »GET LAMP«
von Jason Scott [Sco 10] zeigen, dass das Interesse 146 an interaktiver Fiktion, gespielten Büchern
und Spaß an »Fantasie im Kopf« vorhanden ist. Ambernstein wird 2010 wohl nicht den Weg an die
Öffentlichkeit finden, weil es für 2011 geplant ist, dennoch ist das Fundament gebaut und darf nun
»bebaut« werden.
Hinsichtlich der User Experience ist zu sagen, dass dank zeitgemäßer Web-Technologien, Text-
Adventures von dem multimedialen Umfang des HTML5-Standards profitieren können. Nie war es
so einfach, Audio- und Video-Dateien einzubinden. Text-Adventures leben zwar ausschließlich von
Text, eine gesunde Mischung aus Text und »aufwändigeren« Medienarten wäre aber für die relative
große Menge an Gelegenheitsspielern durchaus denkbar. Dass »alte« Spiele in einer modernen Zeit
Fuß fassen können, zeigt die iPad-Version von »Adventure« 147 oder die iPhone-Version von
»Monkey Island«. 148
Text-Adventures haben das Potenzial auf neuen Endgeräten wiederentdeckt zu werden. Es liegt nun
an den Entwicklern, entsprechende die Allgemeinheit ansprechende Spiele zu entwickeln – ob z.B.
als native »App« oder in W3C-konformer Art (HTML, CSS, JavaScript). 149 Genauso wenig wie
Bücher aussterben, wird es auch mit Interactive Fiction in Form eines Text-Spiels sein – Text kann
was Audio und Video nicht können, es ist zeitlich unabhängig zu konsumieren, kann inhaltlich
durchsucht werden und ist deswegen das wohl zugänglichste Medium. Ob Mitchell Stephens mit
seinem »the rise of the image the fall of the word« (1998) Recht hat, darf nach dem Lesen dieser
esis bezweifelt werden.
Gespannt darf man auf neue Entwicklungen im Browser-Bereich sein. Jüngst kündigte Microso
eine neue Version seines »Internet Explorer« 150 an. Außerdem sieht z.B. Google den Browser als
Zentrum des Betriebssystem bzw. als das Betriebssystem (Chrome OS). Das Spiele für dieses
Betriebssystem scheint naheliegend und macht die Entwicklung von Ambernstein umso sinnvoller,
weil technologisch gesehen dem aktuellen Trend entsprechend.
146 http://www.gamersglobal.de/meinung/neue-textadventures-bitte 05.10.2010

147 http://iadventure.antonfleig.com/ 06.10.2010
148 http://www.netzwelt.de/news/83299-monkey-island-2-neuauflage-iphone-ipad.html 06.10.2010
149 http://www.alistapart.com/articles/apps-vs-the-web/ 06.10.2010
150 http://www.beautyoftheweb.com/ 05.10.2010
115
8 Konklusion
Interessant ist auch welche Trends im Webdesign zu erwarten sind. Man hört von gender-specific web
design 151 , dem Einfluss von Printdesign, sowie von ausdrucksstarker Typographie, dem
horizontalism und der keypress navigation 152 (wie in Ambernstein umgesetzt).
Abgesehen von Text-Adventures sind im Browser auch momentan schon wesentlich

rechenintensivere Spiele möglich – Quake Live beweist, dass auch aufwändiges 3D per Browser-
Plugin dargestellt werden kann. Dass auch mit nativen Browser-Technologien etwas möglich ist,
zeige einige HTML5-Webseiten, die sich momentan noch als Experimente 153 darstellen. Interessant
in dem Zusammenhang ist die HTML5-Funktion des Offline-Storage, bei der es effektiv um die
»Beschwerung» des Clients geht - sprich: Daten werden auf den Client-Rechner ausgelagert und
zwischengespeichert. Google arbeitet momentan an einer derartigen HTML5-Lösung. 154 Aktuell
wird die Auslagerung auf den Client schon von Google Docs und als Browser-Plugin Google Gears 155
angeboten. Interessant ist auch ob und inwiefern Multi-reading 156 im Web erfolgreich sein wird –
Web Workers 157 ist zumindest ein erster Ansatz der WHATWG.
Eine Vielzahl der vorgestellten Entwicklungen sind technischer und technologischer Natur. Sie
helfen, umfangreichere und »reichere« Web-Anwendungen zu erstellen und den Browser als den
Zugangspunkt zum Web zu etablieren. Die Entwicklung ist gut und vor allem im Sinne der Usability
und Accessibility. Sind diese beiden Säulen als »Muss« für Web-Anwendungen etabliert, steht mit
Hilfe einer nutzerzentrierten Denke einer optimalen User Experience nicht mehr so viel im Wege.
Web, Browser, Tastatur und Text haben eine Gemeinsamkeit: sie zielen alle darauf ab, zugänglich
und benutzbar zu sein. Vor allem sollen sie aber im Idealfall Spaß bei der Benutzung bringen.
151 http://www.demystifyingusability.com/2010/07/gender-differences-in-web-usability.html 06.10.2010

152 http://www.smashingmagazine.com/2010/05/04/web-design-trends-2010/ 06.10.2010
153 http://www.chromeexperiments.com/ 06.10.2010
154http://www.googlewatchblog.de/2010/04/12/google-docs-offline-wird-am-demnaechst-deaktiviert/
06.10.2010
155 http://gears.google.com/ 06.10.2010
156 das parallele Ausführen von Prozessen (Threads)
157 http://www.whatwg.org/specs/web-workers/current-work/ 06.10.2010
116
Nachwort
Storytelling ist aktueller denn je.
Momentan wird es von der HORNBACH-Baumarkt-AG in dem »grenzenlosen Haus« 158 betrieben.
Dabei wird per TV-Werbung Aufmerksamkeit und Interesse geweckt, indem mit wenig
Impressionen im TV recht konsequent auf die Webseite verwiesen wird. Der zweite Teil des AIDA-
Prinzips wird auf der Webseite selbst durchgeführt, indem ein Mann beim Bau seines eigenen
Hauses gezeigt wird, das vor Funktionen strotzt, die man selten so gesehen hat. Die Funktionen des
Hauses wurden entsprechend kreativ in Szene gesetzt, sodass der Wunsch nach solch einem
Eigenheim groß wird. Subtil wird »Hornbach« eingeblendet, bei dem die Materialien für den Bau
eines solchen Hauses verfügbar sind.
Damit Storytelling auch im Bereich der Spiele vorangetrieben werden kann, gibt es das Werkzeug
Inform. Aaron Reed hat es für Blue Lacuna Inform 7 benutzt und ich bin mir sicher, dass es einige
Menschen geben wird, die ihm nacheifern werden.
Für Ambernstein wäre also eine Inform 7 Version schön sowie eine »Ambernstein App« für das
iPhone. 159 Die Vision Ambernstein wurde in dieser esis ansatzweise gezeigt. Ich bin gespannt, wie
sie sich weiterentwickelt.
In diesem Sinne, ein freundliches »XYZZY«.
158 http://das-grenzenlose-haus.de/ 05.10.2010

159 http://www.phonegap.com/ – http://www.appcelerator.com/ 06.10.2010
117
Glossar
AIDA
AIDA steht für Attention, Interest, Desire, Action und ist vor allem in der Werbebranche ein gerne
eingesetztes Prinzip.
IA
Information Architecture.
IF
IF steht Interactive Fiction und ist die genauere Bezeichnung für Text-Adventures. Sie stammt von
der Firma »Infocom« – ihres Zeichens der kommerziell erfolgreichste Entwickler von interaktive
Fiktion. [Sco 10]
IxD
Interaction Design.
UX
User Experience.
UI
User Interface.
118
Literaturverzeichnis
[And 09] Stephen P. Anderson. e Fundamentals of Experience Design (Web, Artikel), PoetPainter, LLC, 2009, http://
www.poetpainter.com/thoughts/article/ia-summit-2009-the-fundamentals-of-experience-design- zuletzt abgerufen am 15.09.2010
[Ber 01] Michael Bernard, Ashwin Sheshadri. Preliminary Examination of Global Expectations of Users‘ Mental Models for E-Commerce
Web Layouts (Web, Studie), http://psychology.wichita.edu/surl/usabilitynews/62/web_object_international.htm zuletzt abgerufen am
22.09.2010
[Boc 09] Gisela Reineking von Bock. Bernstein: Das Gold der Ostsee (Print, Buch), Callwey Verlag München, 1981
[Cal 08] Ben Caldwell u.a. Keyboard Accessible, Understanding Guideline 2.1 - Understanding WCAG 2.0 (Web, Guideline), 2008,
http://www.w3.org/TR/UNDERSTANDING-WCAG20/keyboard-operation.html zuletzt abgerufen am 20.09.2010
[Cas 10] Earle Castledine, Craig Sharkie, jQuery: Novice to Ninja (Print), SitePoint Pty. Ltd., 2010
[Cha 09] Cindy Chastain. Experience emes: How a storytelling method can help unify teams and create better products (Web,
Artikel) ,Boxes and Arrows, 2009, http://www.boxesandarrows.com/view/experience-themes zuletzt abgerufen am 01.10.2010
[Coo 07] Alan Cooper, Robert Reimann, David Cronin. About Face 3: e Essentials of Interaction Design (Print, Buch), Wiley
Publishing, Inc., 2007
[Dan 01] Nicky Danino, Heuristic Evaluation - a Step By Step Guide, 2001, http://articles.sitepoint.com/article/heuristic-evaluation-
guide zuletzt abgerufen am 25.08.2010
[Ber 09] Mario Bernhart, omas Grechenig, Sowaretechnik: Mit Fallbeispielen aus realen Entwicklungsprojekten, Pearson Education,
2009
[Eic 99] Armin Eichinger. Usability - Definition, Usability, 1999, http://www.uni-regensburg.de/Fakultaeten/phil_Fak_II/Psychologie/

Doktoranden/absolventen/eichinger_armin/u-definition.html zuletzt abgerufen am 12.09.2010
[Fed 02] Melissa Federoff. Heuristics and Usability Guidelines for the Creation and Evaluation of Fun in Video Games (Web, Master
esis), 2002, http://melissafederoff.com/thesis.html zuletzt abgerufen am 25.08.2010
[Fie 98] Syd Field, Das Handbuch zum Drehbuch (Print, Buch), 1998
[Flo 84] Christiane Floyd. A Systematic Look at Prototyping, http://www.piapetersen.dk/rhs/floyd-prototyping.pdf zuletzt abgerufen
am 11.09.2010. - In: R. Budde, K. Kuhlenkamp, L. Mathiassen, H. Züllighoven (Hrsg.): Approaches to Prototyping. Proceedings of the
Working Conference on Prototyping, Springer Verlag, Berlin, Heidelberg, 1984, S. 1-18
[Fri 10] Vitaly Friedman, e Current State of Web Design: Trends 2010 (Web, Artikel), Smashing Magazine, http://
www.smashingmagazine.com/2010/05/04/web-design-trends-2010/ zuletzt abgerufen am 25.08.2010
[Gar 00] Jesse James Garrett. e Elements of User Experience (Web, Informationsgrafik), Eigenproduktion, 2000, http://www.jjg.net/
elements/pdf/elements.pdf zuletzt abgerufen am 12.09.2010
119
[Gar 03] Jesse James Garrett. e Elements of User Experience (Print, Buch), New Riders, 2003
[Gei 10] omas Geis. Usability und User Experience unterscheiden (Web, Artikel), ProContext Consulting GmbH, 2010, http://
blog.procontext.com/2010/03/usability-und-user-experience-unterscheiden.html zuletzt abgerufen am 14.09.2010
[Har 00] Ilse Harms, Werner Schweibenz. Testing Web Usability, (Web, Artikel), IM - Die Fachzeitschri für Information
Management & Consulting (Ausgabe 3/2000), http://usability.is.uni-sb.de/beitrag/testwebu.pdf zuletzt abgerufen am 02.09.2010
[Hen 05] Shawn Lawton Henry u.a. Introduction to Web Accessibility, W3C Web Accessibility Initiative (WAI), 2005, http://
www.w3.org/WAI/intro/accessibility.php zuletzt abgerufen am 14.09.2010
[Hen oJ] Shawn Lawton Henry, Liam McGee. Accessibility, W3C, o.J., http://www.w3.org/standards/webdesign/accessibility zuletzt
abgerufen am 14.09.2010
[Hop 09] Eric Hope, iPhone User Interface Design (iTunes University, Video), Apple Inc., 2009
[Hor 05] Sarah Horton. Access by Design: A Guide to Universal Usability for Web Designers (Web, Buch), New Riders Press, 2005,
http://universalusability.com zuletzt abgerufen am 13.09.2010
[Inc 10a] Francisco Inchauste. Better User Experience With Storytelling – Part One (Web, Artikel), Smashing Magazine, http://
www.smashingmagazine.com/2010/01/29/better-user-experience-using-storytelling-part-one/ zuletzt abgerufen am 26.08.2010
[Inc 10b] Francisco Inchauste. Better User Experience With Storytelling, Part 2 (Web, Artikel), Smashing Magazine, http://
www.smashingmagazine.com/2010/02/11/better-user-experience-through-storytelling-part-2/ zuletzt abgerufen am 26.08.2010
[Jun 09] C.G. Jung, Archetypen (Print, Buch), 2009
[Kei 10] Jeremy Keith. HTML5 for Web Designers (Print, Buch), A Book Apart, 2010
[Kos 05] Raph Koster. A eory of Fun for Game Design (Print, Buch), Paraglyph Press, 2005
[Krö 10] Peter Kröner. HTML5 (Print, Buch), Open Source Press, 2010
[Kru 06] Steve Krug. Don't Make Me ink! A Common Sense Approach to Web Usability, Second Edition (Print, Buch), New Riders,
2006
[Lee 10] Ed Lee. Future Media Standards & Guidelines - Accessible Games Standard v1.0 (Web, BBC Online Standards and Guidelines),
BBC Guidelines, 2010, http://www.bbc.co.uk/guidelines/futuremedia/accessibility/games.shtml zuletzt abgerufen am 07.09.2010
[Luk 10] Jenn Lukas. JavaScript and Web Standards Sitting in a Tree (Web, Präsentation). Happy Cog / SlideShare, 2010 http://
www.slideshare.net/JennLukas/javascript-and-web-standards-sitting-in-a-tree zuletzt abgerufen am 20.09.2010
[Lyn 09] Patrick J. Lynch, Sarah Horton. Web Style Guide, 3rd Edition (Web, Buch), Yale University Press, 2009, http://
www.webstyleguide.com/ zuletzt abgerufen am 08.09.2010
[Mcb 10] Sean McBride, Lindsey Simon. HTML, CSS, and Javascript from the Ground Up (Web, Videos), Google Code University,
http://code.google.com/intl/de-DE/edu/submissions/html-css-javascript/ zuletzt abgerufen am 02.09.2010
120
[Mei 10] Jens O. Meiert. SUS: How to Easily Grad Your Site‘s Usability (Web, Artikel), Jens O. Meierts Blog, 2010
http://meiert.com/en/blog/20091127/sus-how-to-grade/ zuletzt abgerufen am 06.10.2010
[Mor 04] Peter Morville. User Experience Design (Web, Kolumne), Semantic Studios, 2004, http://semanticstudios.com/publications/
semantics/000029.php zuletzt abgerufen am 12.09.2010
[Nee 10a] Christian Neeb, Story: Wortspiele (S. 54, Print, Artikel), GEE Magazin, Ausgabe Mai/Juni 2010
[Nee 10b] Christian Neeb, Wie sind Helden (Web, Artikel), GEE Magazin, 2010, http://www.geemag.de/2010/06/06/wie-sind-helden/?
hetag=GEE%2054 zuletzt abgerufen am 25.08.2010
[Nie 97] Jakob Nielsen, How Users Read on the Web (Web, Kolumne), Jakob Nielsen‘s Alertbox, 1997, http://www.useit.com/alertbox/
9710a.html zuletzt abgerufen am 24.09.2010
[Nie 00] Jakob Nielsen. Why You Only Need to Test with 5 Users (Web, Kolumne), Jakob Nielsen‘s Alertbox, 2000, http://
www.useit.com/alertbox/20000319.html zuletzt abgerufen am 02.09.2010
[Nie 03] Jakob Nielsen. Usability 101: Introduction to Usability (Web, Kolumne), Jakob Nielsen‘s Alertbox, 2003, http://www.useit.com/
alertbox/20030825.html zuletzt abgerufen am 13.09.2010
[Nie 04] Jakob Nielsen. Card Sorting: How Many Users to Test (Juli 2004), useit.com: Jakob Nielsen's Website, http://www.useit.com/
alertbox/20040719.html (Abruf: 20.1.2010).
[Nie 05] Jakob Nielsen, 10 Heuristics for User Interface Design (Web, Essay), useit.com, 2010, http://www.useit.com/papers/heuristic/
heuristic_list.html zuletzt abgerufen am 28.09.2010
[Nie 06] Jakob Nielsen, Hoa Loranger. Prioritizing Web Usability (Print, Buch), New Riders, 2006
[Nor 02] Donald A. Norman, e Design of Everyday ings (Re-Print, Buch), Basic Books, 2002
[Nor 04] Donald A. Norman, Emotional design: why we love (or hate) everyday things (Print, Buch), basic Books, 2004
[Pre 04] Jenny Preece, Information Architecture and Web Navigation (Web, Paper), University of the West of Scotland, 2004, http://
hamilton.bell.ac.uk/btech/hci/hcinotes11.pdf zuletzt abgerufen am 03.10.2010
[Rol 06] Andrew Rollings, Ernest Adams, Fundamentals of Game Design (Print, Buch), Prentice Hall, 2006
[Rou 05] Richard Rouse III. Game Design - eory & Practice (Second Edition, Print, Buch), Wordware Publishing, 2005
[Rya 99a] Tim Ryan, e Anatomy of a Design Document, Part 1: Documentation Guidelines for the Game Concept und Proposal (Web,
Artikel), Gamasutra, 1999, http://www.gamasutra.com/view/feature/3384/the_anatomy_of_a_design_document_.php?print=1 zuletzt
abgerufen am 29.09.2010
[Rya 99b] Tim Ryan, e Anatomy of a Design Document, Part 2: Documentation Guidelines for the Functional and Technical
Specifications (Web, Artikel), Gamasutra, 1999, http://www.gamasutra.com/view/feature/3411/
the_anatomy_of_a_design_document_.php?print=1 zuletzt abgerufen am 29.09.2010
121
[Saf 07] Dan Saffer, Designin for Interaction: Creating Smart Applications and Clever Devices (Print, Buch), New Riders, 2007
[Sch 08] Jesse Schell, e Art of Game Design (Print, Buch), Morgan Kaufmann, 2008
[Sco 10] Jason Scott, GET LAMP - a documentary about adventures in text (DVD), Eigenproduktion, 2010
[She 04] Lee Sheldon, Character Development and Storytelling for Games (Print, Buch), omson Course Technology PTR, 2004
[Shn 03a] Ben Shneiderman u.a. Research-Based Web Design & Usability Guidelines (Print, Buch), U.S. Department of Health and
Human Services, 2003, http://usability.gov/guidelines/index.html zuletzt abgerufen am 06.10.2010
[Shn 03b] Ben Shneiderman. Leonardo's laptop: human needs and the new computing technologies (Print, Buch), MIT Press, 2003
[Spi 06] Frank Spillers. e Importance of User Experience (Web, Diagramm), Experience Dynamics, 2006, http://www.flickr.com/
photos/bryce/106972762/ zuletzt abgerufen am 30.09.2010
[Sto 09] Elliot Jay Stocks. Sexy Webdesign (Print, Buch), dpunkt.verlag, 2009
[Tan 08] David Tanguay, A guide to create the ideal adventure game (Web, Artikel), 2008,
http://www.adventureclassicgaming.com/index.php/site/features/105/ zuletzt abgerufen am 25.08.2010
[Ung 09] Russ Unger, Carolyn Chandler. A Project Guide to UX Design: For user experience designers in the field or in the making
(Print, Buch), New Riders, 2009,
[Usa oJ] o.V. What is User-Centered Design? (Web, Artikel), Usability Professionals‘ Association, o.J. http://
www.usabilityprofessionals.org/usability_resources/about_usability/what_is_ucd.html zuletzt abgerufen am 14.09.2010
[Vog 98] Christopher Vogler, Die Odyssee des Drehbuchschreibers, Zweitausendeins, 1998
[Wal 06] Trey Walker, e Sims overtakes Myst (Web, Artikel), 2002, http://www.gamespot.com/pc/strategy/simslivinlarge/
news_2857556.html zuletzt abgerufen am 25.08.2010
122
Kolophon
Der Fließtext wurde in Minion Pro (Robert Slimbach, 2000) gesetzt. Überschrien, Fußnotentext,
sowie Kopf- und Fußzeilen wurden in Lucida Sans – dem serifenlosen Komplement von Lucida, das
1985 von Kris Holmes und Charles Bigelow geschaffen wurde – gesetzt.
123

User Experience in Tastaturgesteuerten Text-Adventures

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

User Experience in Tastaturgesteuerten Text-Adventures

Uploaded by

Copyright:

Available Formats

Bachelor esis

User Experience in tastaturgesteuerten Text-Adventures

Alexander Kluge (s0518665)

Abschlussarbeit zur Erlangung des akademischen Grades

© 2010 Alexander Kluge

Eingereicht am 07.10.2010, Berlin

User Experience in tastaturgesteuerten Text-Adventures

Abstract: Diese Arbeit untersucht die Nutzerfahrung (User Experience) und

1 Nintendo sei hier ausgeschlossen

12 Web Development und Copywriting

Preface] Ebenso generieren gebrauchstaugliche Webseiten nicht automatisch eine gute

1.4 Grenzen des Prototypen

Tommy Krüger kümmerte sich im Wesentlichen um die technische Implementierung – die

In der folgenden Tabelle 1 sind die einzelnen Kompetenzen aufgelistet:

Tommy Krüger Alexander Kluge

Ideenfindung und Spielentwurf

Entwicklung der Grundstory und Mini-Spiele

Designdokument UI und UX Design

Technisches Designdokument Universal Usability

Story (Drehbuch, Figuren, Dramatik, Soundtrack)

2.1 Erstes Verständnis

Abb. 1, Die genormte Sicht auf Usability und User Experience

16 ISO 9241-210: »Prozess zur Gestaltung gebrauchstauglicher interaktiver Systeme«

2.2 User-Centered Design

2.3 Universal Usability

2.3.3 Universal Usability

2.3.4 Universal Design

2.4 User Experience

Abb. 2, Die Disziplinen der UX

Abb. 3, Die UX-Honigwabe Abb. 4, UX-Modell

Abb. 5, Die wesentlichen Elemente des Experience Design (Auszug)

Abb. 6, Die UX-Hierarchie der Nutzerbedürfnisse (Auszug) 24

Abb. 7, Verarbeitung der UX durchs Gehirn

Abb. 8, Die Wichtigkeit von UX

2.5.2 Interactive Fiction

25 Im Gegensatz zu stochastisch (zufällig) ist etwas Vorbestimmtes gemeint

Abb. 9, Entwicklungsprozess für UX (UPA)

Abb. 10, Usability als Schritt-für-Schritt-Anleitung

Garrett baut sich die UX aus fünf Ebenen zusammen:

Abb. 11, Elemente der UX (Auszug)

Besagte Ebenen reichen von abstrakt zu konkret:

4.2.2 Zeit und Ressourcen

• Ideenfindung, erste Spielentwürfe • Prototyp implementieren und testen

Abb. 12, Zeitplan

4.2.3 Iterativer Entwicklungszyklus

Abb. 13, Iterative Entwicklungssequenz

4.2.4 Alternative Entwicklungsprozesse

Alle Schritte erfolgen dabei in Iterationen.

Außerdem wurden ﬂexible Kann-Kriterien aufgestellt. Diese lauten:

• Typer Shark (2009)

Slouching Towards Bedlam

Stone Age Sam

Colossal Cave (1975) Zork 1 (1980)

Erstes Text-Adventure Kommerziell erfolgreichstes Text-Adventure

Programmiersprache: FORTRAN Programmiersprache: MDL

Crowther: 79 Orte, 193 Worte 110 Räume, 600 Worte, 60 Objekte

Woods: 140 Orte, 293 Worte, 53 Objekte

beinhaltet einen Antagonisten (Dieb)

Tab. 2, Colossal Cave und Zork 1 im Vergleich

Slouching Towards Bedlam

Slouching Towards Bedlam (2003) Blue Lacuna (2009)

Plattform: Inform 6 (Z-machine) Plattform: Inform 7 (Glulx)

2003 XYYZY Awards: 2009 XYZZY Awards: