Akzeptanz von Tangible User Interfaces im AR Gaming

Fachbereich 4: Informatik
Akzeptanz von Tangible User
Interfaces im AR Gaming
Bachelorarbeit
zur Erlangung des Grades eines Bachelor of Science (B.Sc.)
im Studiengang Computervisualistik
vorgelegt von
Anna Katharina Hebborn
Erstgutachter:
Prof. Dr.-Ing. Stefan Müller
(Institut für Computervisualistik, AG Computergraphik)
Zweitgutachter:
Dipl.-Inform. Martin Schumann
(Institut für Computervisualistik, AG Computergraphik)
Koblenz, im Juni 2011
Erklärung
Ich versichere, dass ich die vorliegende Arbeit selbständig verfasst und
keine anderen als die angegebenen Quellen und Hilfsmittel benutzt habe.
Ja
Nein
Mit der Einstellung der Arbeit in die Bibliothek bin ich einverstanden.
Der Veröffentlichung dieser Arbeit im Internet stimme ich zu.
.................................................................................
(Ort, Datum)
(Unterschrift)
i
Zusammenfassung
Diese Arbeit beschreibt die Konzeption, Implementierung und Evaluierung eines Tangible Augmented Reality Spiels. Die Kombination von
Augmented Reality und Tangible User Interfaces erweitert nicht nur die
reale Umgebung, sondern macht virtuelle Komponenten greifbar. Der
Spieler kann virtuelle Spielfiguren direkt und intuitiv steuern. Auf dieser
Basis wird die Fragestellung, inwiefern der Einsatz von Tangible User
Interfaces im AR Gaming weitere Möglichkeiten schafft, näher erläutert.
Abstract
This thesis describes the design, implementation and evaluation of a Tangible Augmented Reality Game. The combination of Augmented Reality
and Tangible User Interfaces is expanding not only the real environment
but also makes virtual components within reach available as a real tangible
object. The player can control virtual characters directly and intuitively. On
this basis, the question of how far the use of tangible user interfaces in AR
gaming creates further opportunities will be addressed.
ii
Inhaltsverzeichnis
1
Einleitung
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3 Inhalt dieser Arbeit . . . . . . . . . . . . . . . . . . . . . . . .
2
Grundlagen
2.1 Begrifflichkeiten und Stand der Technik . . . . . . .
2.1.1 Augmented Reality . . . . . . . . . . . . . . .
2.1.2 Tracking, Markertracking und Registrierung
2.1.3 Augmented Reality und Interaktion . . . . .
2.1.4 Tangible User Interface . . . . . . . . . . . . .
2.2 Bibliotheken . . . . . . . . . . . . . . . . . . . . . . .
2.2.1 OpenCV . . . . . . . . . . . . . . . . . . . . .
2.2.2 videoInput Library . . . . . . . . . . . . . . .
2.2.3 ARToolKitPlus . . . . . . . . . . . . . . . . .
2.2.4 Blender . . . . . . . . . . . . . . . . . . . . . .
2.2.5 OGRE und OgreAL . . . . . . . . . . . . . . .
1
1
1
1
.
.
.
.
.
.
.
.
.
.
.
3
3
3
3
6
7
7
8
8
8
12
12
3
Tangible Augmented Reality im Bereich Gaming
3.1 Piplex – Pingus Plasticine Expierence . . . . . . . . . . . . .
3.2 Muntermacher – Denken und Bewegen . . . . . . . . . . . .
3.3 ARTierchen – Augmented Reality in touch . . . . . . . . . .
14
14
15
16
4
Konzeption des Spiels
4.1 Ziele und Anforderungen . . . . . . . . . . . . . . .
4.2 Die Grundidee des Spiels . . . . . . . . . . . . . . .
4.3 Das Spiel – FredsWorld . . . . . . . . . . . . . . . . .
4.3.1 Das Spielprinzip . . . . . . . . . . . . . . . .
4.3.2 Das Holzlabyrinth – Tangible User Interface
4.3.3 Die Spielfigur und weitere Spielelemente . .
5
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
17
17
18
18
18
19
20
Implementierung
5.1 3D Modellierung . . . . . . . . . . . . . . . . . . . . . . . .
5.2 Tracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.1 Kameraanbindung und Darstellung . . . . . . . . .
5.2.2 Erweiterung von ARToolKitPlus . . . . . . . . . . .
5.2.3 Integration und Initialisierung von ARToolKitPlus .
5.2.4 Tracking Button . . . . . . . . . . . . . . . . . . . . .
5.3 Verdeckungen . . . . . . . . . . . . . . . . . . . . . . . . . .
5.4 Detektion und Initialisierung der Wände . . . . . . . . . .
5.5 Initialisierung der Spielelemente . . . . . . . . . . . . . . .
5.6 Steuerung – Tangible Control . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
22
22
23
23
24
25
27
28
29
30
31
iii
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5.7
5.8
5.9
5.10
Kollisionserkennung . . . . . .
Virtuelle Spielkomponenten . .
Sound . . . . . . . . . . . . . . .
Overlays und Benutzerführung
.
.
.
.
34
36
38
38
6
Benutzertests
6.1 Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2 Planung und Durchführung . . . . . . . . . . . . . . . . . . .
6.3 Auswertung . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
40
40
41
7
Ergebnisse
7.1 3D Modelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.2 Das TUI – Spielwelt . . . . . . . . . . . . . . . . . . . . . . . .
7.3 Das Spiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
46
46
47
8
Ausblick
8.1 Optimierungsansätze und Erweiterungen . . . . . . . . . . .
8.2 Fortführung des Spielkonzepts . . . . . . . . . . . . . . . . .
8.3 Weitere Benutzertests . . . . . . . . . . . . . . . . . . . . . . .
49
49
50
50
9
Fazit
51
Anhang
54
A Materialdateien
54
B Benutzertest
55
C Tangible User Interface – Bauplan
61
D Screenshots
62
iv
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Abbildungsverzeichnis
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
Markertracking – Verschiedene Markerarten. . . . . . .
ARToolKitPlus – Runtime Tracking Pipeline . . . . . . .
ARToolKitPlus – Merkmalsdetektion . . . . . . . . . . .
ARToolKitPlus – Identifizierung Rechtecke . . . . . . .
ARToolKitPlus – Rektifizierung . . . . . . . . . . . . . .
ARToolKitPlus – Zusammenhang Koordinatensysteme.
Tangible Augemnted Reality – Piplex . . . . . . . . . .
Tangible Augemnted Reality – Muntermacher . . . . .
Tangible Augemnted Reality – ARTierchen . . . . . . .
Konzeptskizze. . . . . . . . . . . . . . . . . . . . . . . .
Konzeptskizze – Tangible User Interface. . . . . . . . .
Konzeptskizze – Spielfigur Fred. . . . . . . . . . . . . .
Konzeptskizze – Würmchen. . . . . . . . . . . . . . . .
Grundlegender Ablauf . . . . . . . . . . . . . . . . . . .
Tracking – Border Marker. . . . . . . . . . . . . . . . . .
Tracking – Border Marker Rotation. . . . . . . . . . . . .
Tracking Button – Region of Interest. . . . . . . . . . . .
Verdeckung – Modell . . . . . . . . . . . . . . . . . . . .
Detektion und Initialisierung der Wände. . . . . . . . .
Detektion und Initialisierung der Wände – Ergebnis. . .
Initialisierung der Spielelemente . . . . . . . . . . . . .
Steuerung – 8 Laufrichtungen von Fred. . . . . . . . . .
Steuerung – Berechnung der Laufrichtung. . . . . . . .
Axis Aligned Bounding Box – Fred. . . . . . . . . . . . .
Axis Aligned Bounding Box – Kollisionstest. . . . . . .
Overlay – Einführung in den Spielbau. . . . . . . . . . .
Benutzertests – Übersicht Probandengruppe. . . . . . .
Benutzertests – Interface. . . . . . . . . . . . . . . . . . .
Benutzertests – Auswertung Spiel. . . . . . . . . . . . .
Benutzertests – Auswertung Allgemein. . . . . . . . . .
Ergebnisse – 3D Modell Fred. . . . . . . . . . . . . . . .
Ergebnisse – 3D Modell Wurm. . . . . . . . . . . . . . .
Ergebnisse – TUI. . . . . . . . . . . . . . . . . . . . . . .
Ergebnisse – Spiel. . . . . . . . . . . . . . . . . . . . . .
Benutzertest – Fragebogen. . . . . . . . . . . . . . . . .
Auswertung – Alle Probanden. . . . . . . . . . . . . . .
Auswertung – Probanden 10-20 Jahre. . . . . . . . . . .
Auswertung – Probanden 21-40 Jahre. . . . . . . . . . .
Auswertung – Probanden 41-60 Jahre. . . . . . . . . . .
Tangible User Interface – Bauplan. . . . . . . . . . . . .
Screenshots. . . . . . . . . . . . . . . . . . . . . . . . . .
Screenshots – Ausschnitt Overlays. . . . . . . . . . . . .
v
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5
9
10
10
11
12
15
15
16
19
20
21
21
22
24
26
27
28
29
30
31
32
33
34
35
39
42
43
44
45
46
46
47
48
55
56
57
58
59
61
62
63
1
1.1
Einleitung
Motivation
Bislang bilden in gebräuchlichen Computerspielen Bildschirm und gewöhnliche Eingabemittel den Zugang zur virtuellen Welt. Abgegrenzt von
der virtuellen Umgebung versuchen wir virtuelle Objekte zu greifen. Die
Kombination von Augmented Reality und Tangible User Interfaces bildet
die Möglichkeit diese Grenze zwischen Realität und Virtualität zu durchbrechen.
Vor allem im Bereich des Augmented Reality Gaming äußert sich der
Wunsch nach grenzenloser Kombination virtueller und realer Welten. Zunächst stellt sich die Aufgabe der realistischen Integration virtueller Objekte in die reale Umgebung des Spielers. Virtuelle Objekte sollen nicht nur
korrekt in der realen Welt dargestellt werden, sondern mit der realen Welt
in Interaktion treten. Das Spiel soll ein Bestandteil der realen Umgebung
des Spielers werden. Tangible User Interfaces (TUI) befördern hierzu die
Interaktion in den dreidimensionalen Raum. Die gegenständliche Schnittstelle ermöglicht eine vertraute Interaktionsform. So kann der Spieler mit
Hilfe materieller Gegenstände virtuelle Objekte manipulieren. Die virtuelle
und reale Welt verschmelzen. Darüber hinaus blieb bislang die Interaktion
im Augmented Reality Bereich aufgrund der hohen Anforderungen an die
technische Umsetzung meist auf der Strecke.
Grundlegend stellt sich somit die Herausforderung die Grenzen üblicher
Computerspiele durch die visuelle Erweiterung und eine besonders intuitive Form der Interaktion zu überwinden.
1.2
Zielsetzung
Die Zielsetzung dieser Arbeit ist die Konzeption und Entwicklung eines
Tangible Augmented Reality Spiels. Neben dem Entwurf und der Implementierung eines geeigneten Spielkonzepts sowie der Integration der virtuellen Spielumgebung in die natürliche Umgebung stellt sich die Aufgabe
der Konzeption und Entwicklung eines getrackten Tangible User Interfaces. Des Weiteren sollen die entstandenen Ergebnisse anhand eines Benutzertests evaluiert werden. Die Auswertung der Benutzertests soll unter anderem die Einschätzung erlauben, ob Tangible User Interfaces genügend
Potenzial bereitstellen die Lücke zwischen realer und virtueller Welt zu
schließen.
1.3
Inhalt dieser Arbeit
Im nächsten Kapitel werden die Grundlagen, die zum wesentlichen Verständnis der Arbeit dienen, erläutert. Das Kapitel 3 gewährt uns einen Einblick in bestehende Konzepte, die für diese Arbeit den nötigen Reiz gaben.
1
Daraufhin folgt im Kapitel 4 der Entwurf des Spiels. Im 5 Kapitel wird
daraufhin näher auf die Umsetzung des Spielkonzepts eingegangen. Zur
Evaluation der Ergebnisse wurden Benutzertests durchgeführt. Die Durchführung sowie die Auswertung der Benutzertests sind Gegenstand des Kapitels 6.
Anschließend wird das entstandene Spiel kurz präsentiert und ein kleiner
Ausblick gegeben.
2
2
Grundlagen
In diesem Kapitel werden zunächst grundlegende Begrifflichkeiten geklärt.
Darüber hinaus wird ein Einblick ins Forschungsgebiet der Augmented
Reality sowie Tangible User Interfaces geschaffen. Zusätzlich wird ein kleiner Überblick über die Bibliotheken gegeben, die bei der späteren Umsetzung von Bedeutung sind.
2.1
Begrifflichkeiten und Stand der Technik
Im Folgenden werden Begriffe kurz definiert und ausschließlich die relevanten Themen und Probleme, die uns unter anderem bei der Entwicklung
begegnen werden, dargestellt.
2.1.1
Augmented Reality
Der Grundgedanke bei Augmented Reality Anwendungen ist virtuelle Informationen mit dem realen Sichtfeld des Betrachters oder einer Kamera zu überlagern. Die visuelle Einblendung unterstützt den Betrachter in
der Interaktion mit der realen Umgebung oder mit realen Objekten (vgl.
[Mül10b]). Im Idealfall verschmelzen reale und künstliche Welt zu einer
Einheit (vgl. [Hor04, S. 12]). Dabei wird die reale Welt durch virtuelle Objekte in Abhängigkeit vom aktuellen Blickpunkt und Position des Betrachters überblendet. Augmented Reality zeigt eine große Vielfalt im Anwendungsbereich. Unter anderem findet man Ansätze in der Medizin, Tourismus, Navigation, Wartung, Montage und Spielen. Eine kommerzielle Entwicklung ist bislang nicht deutlich geworden. Anwendungen in diesem
Gebiet kommen meist infolge von Problematiken, die die technische Umsetzung betreffen, nicht über den Forschungsstatus hinaus. Dennoch zeigt
sich ein kleiner Anstieg in der Unterhaltungsindustrie. In diesem Bereich
finden sich vor allem immer mehr AR Systeme, welche unter anderem auf
dem so genannten Markertracking (Abschnitt 5.2) basieren.
Bei der Entwicklung einer AR-Anwendung stellen sich im Allgemeinen
drei grundlegende Aufgaben: Darstellung, Tracking und Interaktion (vgl.
[Tön10, S. 4]). Zur Darstellung dienen zum Beispiel mobile Geräte oder spezifische Displays wie HMDs (Head-Mounted Display). Der wichtigste und
zugleich schwierigste Teilbereich hingegen liegt im Trackingvorgang. Dieser wird in Abschnitt 2.1.2 näher erläutert. Mit der Interaktion im Bereich
Augmented Reality befasst sich Abschnitt 2.1.3.
2.1.2
Tracking, Markertracking und Registrierung
Tracking und Registrierung Bei der Entwicklung einer AR-Anwendung
nimmt der Trackingvorgang eine fundamentale Stellung ein. Es stellt sich
3
immer wieder die Herausforderung die Position und Orientierung von
Objekten im Raum zu bestimmen. Dies bildet die Grundvoraussetzung,
um virtuelle Komponenten mit der realen Umgebung in Einklang zu bringen. Nur durch die exakte Bestimmung vom Blickpunkt des Betrachters
beziehungsweise der Kamera kann eindeutig bestimmt werden, wann, wo
und in welcher Perspektive virtuelle Objekte eingeblendet werden sollen
(vgl. [Mül10b]). Bewegt sich der Betrachter zum Beispiel im Raum, sind
virtuelle Elemente entsprechend in ihrer Größe, Position und Orientierung
anzupassen.
Der Vorgang, der einen räumlichen Bezug zwischen virtuellen Objekten zu
der realen Umgebung schafft und im engen Zusammenhang zum Tracking
steht, wird als Registrierung (engl. registration) bezeichnet (vgl. [Azu95, S.
18]). Fehlerhafte Registrierung wie zum Beispiel falsche Perspektive kann
zu Wahrnehmungsproblemen und zur Minderung des Immersionsgefühls
führen. Das so genannte Registrierungsproblem (registration problem),
welches uns in der Umsetzung noch begegnen wird, trägt somit derzeit
immer noch dazu bei, dass viele Augmented Reality Anwendung nicht
akzeptiert werden (vgl. [Azu95, BR05]).
Neben der dreidimensionalen Ausrichtung sind visuelle Korrelation der
realen Umgebung, wie Schatten oder Verdeckungen, aber auch physikalische Gesetzmäßigkeiten, die durch Bewegung virtueller Objekte oder
Kollision mit der realen Umgebung auftreten, auf die Augmented Reality
Szenerie zu übertragen (vgl. [BWRT96, S. 1]). Dies vermeidet Verwirrung
und stärkt den Eindruck der Koexistenz beider Welten.
Markertracking Markerbasiertes Tracking gehört zu den optischen
Trackingverfahren und ermöglicht die Ergänzung von einem realen Videobild mittels Einblendung von visuellen Gegenständen. Die Kernidee liegt
darin, einen Marker, dessen Eigenschaften wie Form und Größe bekannt
sind, als Orientierungspunkt in der realen Welt zu platzieren beziehungsweise an dem zu trackenden Objekt anzubringen. Das Tracking der Marker, im Wesentlichen eine Merkmalsextraktion, ermöglicht die Bestimmung
von Position und Orientierung und somit die korrekte Einblendung von
virtuellen Objekten. Mit Hilfe von einem Kamera-Tracking-System wird
diesbezüglich die relative Lage zwischen Marker und Kamera ermittelt.
Während des gesamten Trackingvorgangs wird dem Begriff des Findens eine besondere Bedeutung zugewiesen. Das Tracking wird hier eher im Sinne von finden statt verfolgen verstanden (vgl. [Mül10b]). Im Vordergrund
steht dementsprechend die Detektion des Markers und infolgedessen die
Berechnung der Position und Orientierung der Kamera.
4
Markertracking – Allgemeiner Markeraufbau Marker sind in den meisten Fällen Quadrate mit einem schwarzen Rahmen. Im Zentrum befindet
sich je nach System endweder eine Bitkodierung oder ein beliebiges asymmetrisches Muster. Das Innere dient zum einen zur vollständigen Identifikation und zum anderen, um die Drehung um die vertikale Achse des
Markers zu bestimmen.
Abbildung 1: Markertracking – Verschiedene Markerarten. Links: bekannter ARToolKit Marker [ARTa], Rechts: ID-Marker [ARTb]
Markertracking – Allgemeiner Tracking Ablauf Im Allgemeinen kann
der Trackingprozess durch die drei Kernschritte: Bildaufnahme, Detektion der Marker und die Bestimmung der extrinsischen beziehungsweise
äußeren Kameraparameter (Position und Pose) beschrieben werden. Die
Trackingdaten, die bestenfalls die exakten extrinsischen Parameter der Kamera beinhalten, ermöglichen die lagegerechte Integration von virtuellen
Objekten in die reale Umgebung.
Als Eingabe dient in der Regel ein Videodatenstream. Im aufgenommenen Videobild erfolgt mit Hilfe von bildverarbeitenden Methoden die Detektion der Marker. In den meisten Fällen wird diesbezüglich, folgend an
einen Bildvorverarbeitungsprozess, ein Binärbild auf Rechteckformen untersucht. Sind die Rahmenkanten des Markers gefunden, folgt die Identifizierung der Eckpunkte. Im nächsten Schritt wird durch ein MatchingVerfahren, das je nach Trackinssystem variiert, festgestellt, ob es sich in
der Tat um einen Marker handelt. Darüber hinaus wird der Marker anhand seiner ID eindeutig identifiziert. Die Position und Ausrichtung der
Kamera kann daraufhin in Relation zum Marker berechnet werden (vgl.
[Mül10b]). Infolgedessen ist das Fundament für das kombinierte Bild aus
Realität und Virtualität geschaffen. Ergibt sich eine Änderung in der Position oder Orientierung des Markers wird ein Korrekturschritt verwendet um
den virtuellen gebundenen Gegenstand wieder in Deckung mit der Realität
zu bringen (vgl. [Mül10b]).
5
Markertracking – Stärken und Schwächen Ein deutlicher Schwachpunkt des Markertrackings liegt darin, dass sich der Marker für einen erfolgreichen Trackingvorgang im Sichtfeld der Kamera befinden muss und
somit auch für unbeteiligte Personen sichtbar ist. Das Resultat ist ein geringer High-Tech-Faktor. Des Weiteren reagieren viele Markertrackingsysteme häufig anfällig auf Beleuchtungschwankungen oder auch Schattenwürfe. Dennoch beweist sich Markertracking durch belanglosen Technologieaufwand, einfache Anwendung und geringe Kosten. Hinzukommend
werden im Gegensatz zu den meisten anderen Trackingverfahren keine
physischen Verbindungen wie zum Beispiel Kabel benötigt. Dadurch wird
eine hohe Mobilität erreicht – das System ist relativ einfach und schnell im
Freien einsetzbar. Zudem liefern andere optische Trackingverfahren meist
nur eine Identifizierung (ID). Markerbasiertes Tracking hingegen liefert
eine Identifikation und Orientierung beziehungsweise Kamera-Pose (vgl.
[Mül10b]). Grundlegend ist der Entschluss zur Verwendung von Markertracking aufgrund der simplen Handhabung, dem geringen Aufwand und
der Echtzeitfähigkeit gefallen.
2.1.3
Augmented Reality und Interaktion
Meist tritt die Interaktion bei der Entwicklung einer Augmented Reality
Anwendung in den Hintergrund. In vielen Fällen wird der technischen
Umsetzung, die zum Beispiel das Tracking und die Registrierung umfasst,
höhere Aufmerksamkeit geschenkt. Dementsprechend beschränkt sich ein
Großteil der Systeme auf das passive Betrachten von virtuellen Informationen in der realen Umgebung (vgl. [BKP08]). Die Eingabe und Interaktion
gestaltet sich generell in den meisten AR Systemen schwierig. Konventionelle Eingabemittel wie Maus und Tastatur sind gar nicht oder nur bedingt
geeignet. Die 2D-Eingabe über Tastatur oder Maus muss zum Beispiel bei
der Rotation eines Gegenstands in eine 3D-Eingabe transformiert werden
(vgl. [Tön10, S. 96]). Möchte man die Freiheit geben, Objekte einfach mit der
Hand zu bewegen und die Illusion der vollkommenen Kombination realer
und virtueller Welt bewahren, sind andere Interaktionskonzepte gefragt.
Gesucht werden Möglichkeiten, die die Interaktion in den dreidimensionalen Raum zu verschieben.
Im Hinblick auf diese Arbeit wird das Konzept der Tangible User Interfaces, die eine natürliche Interaktion im dreidimensionalen Raum ermöglichen, in Abschnitt 2.1.4 näher erläutert. Neben TUIs bieten markerbasierte
Techniken die geforderte Interaktionsmöglichkeit. Diese Konzepte basieren
im weitesten Sinne auf einem ähnlichen Gedanken und werden gelegentlich auch als solche bezeichnet. Marker können zum Beispiel verwendet
werden, um virtuelle Objekte im Raum zu platzieren oder eine Knopffunktion zu übernehmen. Die assoziierte Funktion kann durch eine Verdeckung
des Markers – der Marker wird für eine gewisse Zeit nicht getrackt – aus6
gelöst werden. Neben der Positionierung kann an bestimmte Gesten, wie
Schütteln oder Drehen, eine Eingabe in das System gebunden werden. Jedoch muss dem Benutzer hierzu die jeweilige Geste und deren Bedeutung
bekannt sein. Ansonsten werden entsprechende Hinweise benötigt. Wie im
folgenden Kapitel verdeutlicht wird, gehen Tangible User Interfaces einen
Schritt weiter (vgl. [Tön10, S. 98]).
2.1.4
Tangible User Interface
Tangible User Interfaces (TUIs) kann man als gegenständliche beziehungsweise materielle Schnittstellen auffassen. Der Kerngedanke der Forschung
ist reale Objekte aus dem täglichen Umfeld des Menschen zu nutzen, um
digitale Daten haptisch erfassbar zu machen. Gewohnte Umgangsformen
werden somit auf die Mensch-Computer-Interaktion übertragen.
Das Aufkommen von Tangible User Interfaces ist eng mit der Entwicklung von Augmented Reality verknüpft. Grundsätzlich verfolgen beide
Forschungszweige die Idee Computer und Software mit unserer Umwelt
zu verschmelzen. Das gemeinsame Ziel ist es, die den Menschen umgebende reale Welt durch virtuelle Komponenten und Fähigkeiten zu bereichern.
Dennoch muss hier zwischen Augmented Reality und Tangible User Interfaces ganz klar unterschieden werden. TUIs bieten uns ein spezifisches
Konzept zur Gestaltung von Schnittstellen, können aber durchaus ein Bestandteil von AR Anwendungen sein. Umgekehrt stellt AR die nötigen
technischen Hilfsmittel zur Entwicklung und Umsetzung von TUIs bereit
(vgl. [Hor04, S. 9ff.]).
Die Ausgangsmotivation im Hinblick darauf bildet die wachsende Unzufriedenheit mit der Steuerung des Computers mit Maus und Tastatur, die
den Menschen auf Augen und Finger reduziert. Die Fähigkeiten des Menschen sich in der realen Welt zu bewegen und zu agieren, welche stark ausgeprägt sind, bleiben vollkommen unbeachtet (vgl. [Hor04, S. 9ff.]). Beim
TUI Konzept hingegen soll die den Menschen umgebene Welt selbst zum
Interface werden. Interaktionsformen sollen auf den Fertigkeiten des Menschen aufbauen. Dementsprechend werden virtuelle Objekte mit physikalischen Alltagsgegenständen gekoppelt (vgl. [IU97]).
Ishii und Ullmer [IU97] definierten hierzu den Begriff "Tangible Bits". Digitale Daten (Bits) sollen greifbar werden um die Lücke zwischen virtueller
und realer Umgebung zu schließen (vgl. [IU97, S. 2]).
2.2
Bibliotheken
Im folgenden Abschnitt werden die für die Umsetzung relevanten Bibliotheken vorgestellt und prägnante Aspekte, die ausschlaggebend für die
spätere Umsetzung sind, näher erläutert.
7
2.2.1
OpenCV
OpenCV1 (Open Source Computer Vision) bildet eine freie zugängliche
Programmbibliothek, welche zahlreiche Algorithmen und Funktionen für
den Bereich Computer Vision umfasst. Sie ist für die Programmiersprachen
C und C++ geschrieben und steht unter den Bedingungen der BSD-Lizenz2
für kommerzielle sowie nicht kommerzielle Anwendungen zur Verfügung.
OpenCV ist mit einem starken Fokus auf die Echtzeitfähigkeit gestaltet
worden. Ein wesentliches Ziel von OpenCV ist es, eine einfache Lösung
und Basisstrukturen zur Umsetzung von Anwendung im Bereich Computer Vision bereitzustellen. Die Library umfasst über 500 Funktionen (vgl.
[BK08, S. 1]).
Die Stärke der Bibliothek zeigt sich dementsprechend durch die Echtzeitfähigkeit der Algorithmen sowie den Funktionsumfang. Die Bibliothek stellt
vor allem grundlegende Funktionalität der Bildverarbeitung bereit, die bei
der Umsetzung von Nutzen ist.
2.2.2
videoInput Library
videoInput3 ist eine freie C++ Bibliothek zur reinen Kameraanbindung. Im
Gegensatz zu OpenCV bietet sie eine bessere Kontrolle bei der Einstellung
der Kameraparameter. Sämtliche kameraspezifische Einstellungen können
direkt im Quellcode oder über ein separates Fenster erfolgen. Darüberhinaus beweist sich die Library durch ihre hohe Geschwindigkeit.
2.2.3
ARToolKitPlus
ARToolKitPlus4 ist eine Open Source C++ Softwarebibiliothek, die unter
der GPL-Lizenzierung 5 steht und auf der Erkennung von optischen Markern basiert. ARToolkitPlus gilt als Weiterentwicklung von ARToolkit und
ist als Nebenprodukt des „Handheld AR projects“der Studierstube an der
Technischen Universität Graz entstanden. Im Kern handelt es sich um ein
sogenanntes Kamera-Tracking-System, das aus Kamerabildern die relative
Lage zwischen der Kamera und Marker ermittelt und dadurch das korrekte
Einblenden von virtuellen Objekten in das Kamerabild ermöglicht.
ARToolKit und ARToolKiPlus im Vergleich Im Gegensatz zu ARToolKit beschränkt sich ARToolKitPlus auf die grundlegenden Trackingalgorithmen, die vom Vorgänger teils übernommen und erweitert wurden. Es
1
http://opencv.willowgarage.com/wiki/, Stand 15.04.2011
http://www.opensource.org/licenses/bsd-license.php, Stand 15.04.2011
3
ttp://studierstube.icg.tu-graz.ac.at/handheld_ar/artoolkitplus.
php, Stand 20.04.2011
4
http://muonics.net/school/spring05/videoInput/, Stand 18.04.2011
5
http://www.gnu.org/licenses/gpl.html, Stand 18.04.2011
2
8
wird weder eine Videoanbindung noch eine Darstellungskomponente bereit gestellt. ARToolkitPlus richtet sich somit an erfahrene Programmierer
und ist prinzipell nicht für den Einstieg in Sachen Markertracking gedacht
(vgl. [ARTb]).
Die Verwendung von bitkodierten Markern und ein robustes Trackingverfahren liefern zuverlässigere Ergebnisse als der Vorgänger ARToolKit. Das aufwendige, rechenintensive und teils ungenaue PatternMatchingverfahren, dass das Bitmap-Muster des Markers mit abgespeicherten vergleicht, wurde durch das Auslesen einer Bit-ID ersetzt. ARToolKitPlus liefert 4096 vorgefertigte Marker, die intern bereits einer Zuordnung unterliegen. Lästiges Anlernen von Markern, wie es bei ARToolKit
der Fall ist, bleibt aus. Die ID wird durch eine 9 Bit-Zahl in einem 6x6
Muster repräsentiert. Zur Umsetzung des ID-Detektionsalgorithmus lieferte ARTag die nötige Inspiriation. Das robuste Trackingverfahren wird
durch automatisches Thresholding und den Ausgleich des radialen Helligkeitsabfalls erreicht. Die dynamische Adaption des Schwellwerts zeigt
sich durch bessere Resistenzeigenschaften gegenüber Beleuchtungsänderungen. Des Weiteren wird die Detektion des Markers durch den Ausgleich
des radialen Helligkeitsabfall im gesamten Bildbereich möglich. Darüber
hinaus kann die Breite des Markerrahmens variieren (vgl. [ARTb]). Dem
Entwicklern bleiben mehr Freiheiten und ein Tracking auf größeren Distanzen wird möglich.
Trackingablauf – Runtime Tracking Pipeline Die Runtime Tracking Pipeline nach Wagner [Wag07] wird von jedem neu verfügbaren Kamerabild
durchlaufen. Wurden ein oder mehrere Marker im Bild identifiziert, so ist
das Ergebnis eine Liste von Trackingdaten, die die Posen der jeweiligen
Marker beinhalten (vgl. [Wag07, S. 41]). Wie in der Abbildung 2 deutlich
wird, werden fünf Basisschritte bis zum Erhalt der Trackingdaten benötigt.
Abbildung 2: ARToolKitPlus – Runtime Tracking Pipeline [Wag07]
9
Merkmalsdetektion – Fiducial Detection Zur Extraktion der Kontur erfolgt zunächst ein Thresholding. Das Binärbild wird daraufhin zeilenweise von rechts nach links durchlaufen. Findet sich eine Sequenz mit einem
Wechsel zwischen gesetzten und ungesetzten Pixel wird die entsprechende Kante abgelaufen. Ist der Startpunkt wieder erreicht handelt es sich
um einen potenziellen Marker. Bereits besuchte Pixel werden dabei markiert, sodass die jeweiligen Kanten nicht mehrfach abgelaufen werden (vgl.
[Wag07, S. 42]).
Abbildung 3: Merkmalsdetektion in ARToolKitPlus. Links: Ursprungsbild; Mitte:
Binärbild, Rechts: Drei geschlossene Polygone als Rechteckkandidaten. [Wag07]
Identifizierung von Rechtecken – Rectangle Fitting Beim Rectangle Fitting sind die vorliegenden Konturen auf ihre Rechteckform zu untersuchen. Hierbei wird unter der Annahme vorgegangen, dass ein Rechteck
vier, meist gerade Linien hat, die sich in vier Eckpunkten schneiden. Um
die Eckpunkte zu ermitteln, wird ein Eckpunkt, der einen maximalen Abstandswert zu einem anderen beliebigen Konturpunkt aufweist, als erster
Eckpunkt definiert. Daraufhin wird der Massepunkt aller Konturpunkte
ermittelt und eine Linie zwischen dem ersten Eckpunkt und diesem Punkt
gezogen. Beide anderen Eckpunkte sind nun dadurch definiert, das sie den
größten Abstand zur ermittelten Linie darstellen. Dies wird anhand einer
Linie zwischen den letzten beiden berechneten Punkten wiederholt, um
den letzten Eckpunkt zu berechnen (vgl. [Wag07, S. 42-43]).
Abbildung 4: Beispiel: Identifizierung von Rechtecken. [Wag07]
Identifizierung des Markers – Pattern Checking Im folgenden Schritt
wird es notwendig zu überprüfen, ob die ermittelten Rechtecke gültige
10
Marker darstellen. Hierzu erfolgt zunächst die Rektifizierung des Markerbildes. Die Verzerrung des Markers wird durch die lineare Transformation
der Markerkoordinaten in Bildkoordinaten korrigiert. Diese Transformation bezeichnet man als Homographie. Die Homographie Matrix wird durch
die vier Punktkorrespondenzen, die die gefundenen Eckpunkte präsentieren, ermittelt. Im nächsten Schritt unterscheidet ARToolKitPlus zwischen
vier verschiedenen Pattern Checking Methoden (vgl. [Wag07, S. 44ff.]). In
dieser Arbeit ist vor allem der übliche ID-Marker von Bedeutung. Bei dem
Verfahren für ID-basierte Marker kann direkt ein Bitcode aus dem rektifizierten Pattern gewonnen und die entsprechende ID ermittelt werden (vgl.
[Wag07, S. 45]).
Abbildung 5: Rektifizierung des Markerinneren. Links: Definierte Innenraum anhand der Eckpunkte, Mitte: Abstatungsraster für die Rektifizierung,
Rechts: Rektifizierter Innenraum. [Wag07]
Bestimmung der extrinsischen Kameraparameter – Lens Undistortion
and Pose Estimation Bei Bestimmung der Position und Ausrichtung der
Kamera spielen drei verschiedene Koordinatensysteme eine Rolle: Das
Markerkoordinatensystem, das Bildschirmkoordinatensystem und das Kamerakoordinatensystem (vgl. [Car]). Die unterschiedlichen Koordinatensysteme werden in Abbildung 6 auf Seite 12 dargestellt. Gesucht wird die
Transformation des Markerkoordinatensystem in das Kamerakoordinatensystem. Um an dieser Stelle eine eindeutige Lösung zu erhalten sind mindestens vier Korrespondenzpunkte notwendig (vgl. [Mül10b]). ARToolKitPlus nutzt wie die meisten Systeme die bekannten Eckkoordinaten des
Markers. Diese sind am einfachsten zu ermitteln und liefern eine gewisse Präzision, da die Punkte der Ecken die größten Abstände untereinander aufweisen (vgl. [Mül10b]). Aufgrund des vorangegangenen LensUndistortion-Schrittes werden Verzerrungen der Kamera anhand der intrinsischen Kameramatrix korrekt berücksichtigt. Die intrinsische Kameramatrix kann einmalig durch eine Kalibrierung ermittelt werden (vgl.
[Wag07]). Dementsprechend kann mit Hilfe von den bekannten Eckpunkten des Markers, die jeweils im Markerkoordinatensystem als auch im Bildschirmkoordinatensystem vorliegen, sowie der intrinsischen Kameramatrix die Matrix zur gesuchten Transformation berechnet werden.
11
Abbildung 6: Zusammenhang Koordinatensysteme. [Car]
2.2.4
Blender
Blender6 ist eine Open Source 3D-Grafik Software, die unter der
GPL-Lizenz für alle gängigen Betriebssysteme erhältlich ist. Als 3D
Modellierungs- und Animationswerkzeug bietet Blender die Möglichkeit
dreidimensionale Szenen und Objekte zu erstellen, zu texturieren, zu animieren und zu rendern. In dieser Arbeit wird die Blender Version 2.49 verwendet. Blender 2.49 ermöglicht die Einbindung des Blender 2.5 Exporters7
und somit den Export zu OGRE, das für die Darstellung verwendet wird.
2.2.5
OGRE und OgreAL
ORGE 3D8 (Object-Oriented Graphics Rendering Engine) ist eine in C++
geschriebene Open-Source-Engine zur grafischen 3D Darstellung. Die szenenorientierte und flexible 3D Engine steht unter der MIT-Lizenz9 und unterstützt die gängigen Betriebssysteme wie Windows, Linux und Mac OS
X. Mit einem klar objektorientierten Aufbau, einem ausführlich dokumentierten Beispielframework und einer großen Community bietet OGRE gute
Einstiegsmöglichkeiten.
OGRE verfolgt in erster Linie ein Szenegraphenkonzept. Hierzu werden
6
http://www.blender.org/, Stand 20.04.2011
http://www.ogre3d.org/tikiwiki/Blender+Exporter, Stand 28.04.2011
8
http://www.ogre3d.org/, Stand 20.04.2011
9
http://www.opensource.org/licenses/mit-license.php, Stand 20.04.2011
7
12
alle erzeugten Objekte in eine objektorientierte Struktur, die den logischen
Aufbau und die räumliche Anordnung der darzustellenden Szene beschreibt, angefügt. Dabei bildet die Klasse Ogre::Root das Wurzelelement
und den Einstiegspunkt in das Programm. Die Engine beschränkt sich lediglich auf die Grafikdarstellung von 3D Szenen. Funktionen wie Kollisionserkennung, Physiksimulation oder Sound können somit nur durch die
Anbindung von weiteren Bibliotheken bereit gestellt werden. Angesichts
dessen wird zusätzlich OgreAL10 verwendet. OgreAL ist ein Wrapper von
OpenAL und erlaubt eine nahtlose Integration von Audiodaten in die Ogre Applikation. Die plattformunabhängige 3D Audio API OpenAL ermöglicht die Erzeugung von 3D Sound und findet in Computerspielen und anderen Audioanwendungen Verwendung. OgreAL unterstützt die Wiedergabe der Audioformate wav und ogg und ist kompatible mit OpenAL 1.1.
Der Wrapper erlaubt den Zugriff auf sämtliche Kernfunktionalitäten von
OpenAL (vgl. [Ogr]).
10
http://www.ogre3d.org/tikiwiki/OgreAL, Stand 20.04.2011
13
3
Tangible Augmented Reality im Bereich Gaming
Tangible Augmented Reality (TAR) beschreibt die Kombination von Tangible User Interface und Augmented Reality. TAR sichert eine nahtlose Interaktion zwischen realen und virtuellen Welten. Es wird eine Auswahl
an natürlichen Interaktionsmöglichkeiten geboten, welche in gängigen AR
Schnittstellen schwer zu finden sind (vgl. [BKP08]). Besonders Spiele profitieren von der direkten dreidimensionalen Interaktionsform. Die Bedienung wird vereinfacht und der Realismus wird erhöht (vgl. [US03]). Um
einen Einblick in die Tangible User Interfaces im AR Gaming zu erhalten
und zur Ideenfindung, werden im Folgenden drei unterschiedliche TARKonzepte vorgestellt.
3.1
Piplex – Pingus Plasticine Expierence
Pipilex steht für Pingus Plasticine Expierence und stellt einen Prototyp
für ein Kinderspiel dar. Das Spielprinzip basiert auf dem bekannten Spiel
„Lemmings“. Geschöpfe – Pinguine – gehen nur geradeaus bis sie auf ein
Hindernis treffen oder in den Abgrund stürzen. Der Spieler erhält die Aufgabe eine Gruppe von Pinguinen vom Start ins Ziel zu führen und währenddessen Hindernisse zu umgehen (vgl. [BLC+ 10]).
Das Spiel verwendet ein für diese Arbeit interessantes und darüber hinaus außergewöhnliches Interaktionskonzept, denn die Schnittstelle bildet
gewöhnliche Knetmasse in unterschiedlichen Farben. Um den Pinguinen
eine neue Richtung zu geben kann die Masse nach Belieben geformt und in
der Spielumgebung platziert werden. Dies wird in Abbildung 7 auf Seite 15
rechts verdeutlicht. Darüber hinaus kann der Benutzer vor dem Beginn des
Spiels, die Spielumgebung frei aus Papier gestalten. Dazu erhält der Spieler
verschieden bedruckte Papierbögen, aus denen er sich zum Beispiel Wasser
oder Stege ausschneiden und im Spielbereich platzieren kann (siehe Abbildung 7 auf Seite 15 links). Die Kernidee ist dem User ein gemeinschaftlichorientiertes Spiel zu bieten. Die Benutzer sollen die Möglichkeit erhalten
ihre eigne Spielumgebung zu schaffen und durch die Modellierung von
verformbarem Material mit virtuellen Komponenten in Interaktion treten.
Um die gemeinschaftliche Spielwelt zu ermöglichen, wird das Spielfeld
von einer Kamera von oben aufgenommen, virtuell erweitert und durch
ein Rückprojektor auf eine Leinwand projiziert. Zu Beginn wird nur die
Spielwelt mit bildverarbeitenden Methoden initialisiert. Im weiteren Spielverlauf wird im Kamerabild die Position und Form der Knetmasse detektiert und die Spielwelt entsprechend aktualisiert (vgl. [BLC+ 10]).
14
Abbildung 7: Piplex – Links: Material zur Gestaltung der eigenen Spielwelt,
Rechts: Interaktion mit virtuellen Pinguinen. [BLC+ 10]
3.2
Muntermacher – Denken und Bewegen
Das Spiel Muntermacher wurde im Rahmen einer Diplomarbeit beim
Fraunhofer Institut prototypisch entwickelt. Das grundlegende Ziel des
Spiels ist ältere Menschen auf spielerische Weise zu mehr sportlichen Aktivitäten zu begeistern. Das Konzept setzt auf eines der wichtigsten Bedürfnisse: den Erhalt geistiger Fertigkeiten. Das Eingabegerät stellt ein Gymmnastikband mit zwei Kraftbällen dar, wie in Abbildung 8 gezeigt wird. Im
Spiel werden verschiedene Denksportbereiche abgedeckt, die die geistigen
und sportlichen Fähigkeiten von Senioren unterstützen und bewahren sollen (vgl. [Tam]).
Abbildung 8: Muntermacher – Das aktive Denkspiel für Senioren.[Tam]
15
3.3
ARTierchen – Augmented Reality in touch
ARTierchen ist ein interaktives Spiel, dessen Entwicklung 2004 am Lehrstuhl für Interaktive Systeme und Interaktionsdesign der Abteilung für Informatik an der Universität Duisburg-Essen begann. Das Spielprinzip orientiert sich am 1996 entwickelten Tamagotchi. Der Spieler erhält die Aufgabe sich um das Wohlbefinden der Protagonisten, welche als Tierchen bezeichnet wird und eine Giraffe darstellt, zu kümmern. Es muss für ausreichende Ernährung und Abwechslung gesorgt werden. Unter anderem
ist das Tierchen vor Gefahren wie eine fleischfressende Pflanze zu schützen. Der Spieler interagiert mit der Spielfigur durch eine handelsübliche
Fliegenklatsche. Das entwickelte TUI wird als Advanced Felixible Pointing
Device (AFPD) bezeichnet und ist auf Vorder- und Rückseite mit Markern
versehen. Durch die verschiedenen Marker erhält der Spieler die Möglichkeit auf unterschiedliche Weise mit der Protagonistin zu interagieren. Dabei wird grundlegend zwischen Laufmarker und Aktionsmarker unterschieden. Durch den Laufmarker kann die Giraffe an einen anderen Ort geführt
werden. Der Aktionsmarker dient zum Beispiel für Streicheleinheiten und
Fütterung. Die entsprechende Interaktion wird durch das tippen auf die
Spielfläche erreicht (vgl. [SWM+ 06]).
Abbildung 9: ARTierchen – Augmented Reality in touch. [ARTc]
16
4
Konzeption des Spiels
In diesem Kapitel werden zunächst Ziele und Anforderungen definiert,
die bei der Konzeption eines passenden Spiels hilfreich sind. Des Weiteren
wird die grundlegende Spielidee dargestellt, die jedoch bei der späteren
Umsetzung gegebenenfalls in Details beziehungsweise in den Spielkomponenten modifiziert wird.
4.1
Ziele und Anforderungen
Die Zielvorstellung ist ein Spielkonzept zu entwerfen, das zugleich die
Vorzüge und Stärken von Tangible User Interfaces sowie Augmented Reality vereint. Neben dem Entwurf eines geeigneten Interfaces ist dementsprechend ein ansprechendes und passendes Spiel zu gestalten. Gemäß
des Grundsatzes „Ein gutes Spiel ist leicht zu erlernen und schwer zu
meistern.“[MDB03, S. 30] soll der Spieler leicht ins Spielgeschehen einsteigen können und ebenso dran bleiben. Gesucht wird ein Konzept, das die
Einstiegsbarriere minimiert und den Benutzer motiviert sowie langanhaltend begeistert. Die grundlegende Spielwelt soll in der realen Umgebung
entstehen und durch virtuelle Spielkomponenten erweitert werden. Der
Spieler soll durch die Manipulation der realen materiellen Spielwelt Einfluss auf die virtuelle Welt nehmen. Der Kerngedanke der Tangible User Interfaces ist greifbare und bekannte Objekte mit digitalen Eigenschaften zu
erweitern, ohne vertraute Merkmale zu verlieren (vgl. [Hor04, S. 10]). Dieser Gedanke soll entsprechend umgesetzt werden. Eine gelungene Kombination aus digitalen und wirklichen Bestandteilen soll entstehen. Dementsprechend steht die Entwicklung eines extrem simplen Benutzerinterfaces,
welches durch ein entsprechendes Spielprinzip zu einem harmonischen
Gesamtkonzept abgerundet werden soll, im Vordergrund. Die Anforderungen an das TUI sind einfach: Intuitiv, leicht verständlich und unkompliziert. Das Ziel ist vor allem dem Spieler seine Handlungsmöglichkeiten
einfach und eingängig zu präsentieren. Dementsprechend muss ein Spielkonzept entworfen werden, dass diese Einfachheit bewahrt. Dabei könnte
zum Beispiel der Rückgriff auf ein bekanntes Spielprinzip zusätzlich helfen, die Eingewöhnungsphase zu verkürzen. Dennoch darf der Spaß am
Spiel nicht in den Hintergrund treten. Frust und Langweile sind unbedingt zu vermeiden. Das bedeutet die Begeisterung des Spielers durch Abwechslung, Erfolge, Belohnungen und angepasste Spielbalance zu behalten. Neue Herausforderungen und ein Anstieg des Schwierigkeitsgrades
schaffen im Spiel eine gewisse Vielfalt – bieten dem Spieler etwas Neues.
Die Steigerung der Schwierigkeit ist dabei so zu gestalten, dass der Spieler
nicht überfordert aber auch nicht unterfordert wird. „Eine Herausforderung ist gut – ein bisschen Frust ist gut – aber es darf nicht so schwer sein,
dass nur absolute Experten eine Chance haben, lebend zum anderen Ende
17
des Levels zu gelangen.“[Bat02, S. 96] Des Weiteren soll grundsätzlich gelten: Jede erbrachte Leistung des Spielers muss belohnt werden. Der Mehrwert vom TAR-System soll genutzt werden, indem der Nutzer bei Erfolg
oder Misserfolg eine entsprechende audiovisuelle Rückmeldung erhält.
Das Spielerlebnis wird erweitert beziehungsweise verstärkt. Ebenso von
Bedeutung ist die konsistente Spielbalance. Das Gleichgewicht kann zum
Beispiel durch technische Probleme, wie Programmierfehler oder Ausfallen des Trackingsystems, gestört werden. Ergebnis ist Frustration und Demotivation beim Spieler. Dementsprechend ist diesen erhöhte Aufmerksamkeit zu schenken.
4.2
Die Grundidee des Spiels
Der Grundmotivation ist eine simple, haptisch wahrnehmbare Benutzerschnittstelle mit einem entsprechenden Spielkonzept zu schaffen. Diesem
Wunsch gerecht zu werden, ist die Wahl des Genres auf eine Kombination aus Geschicklichkeitsspiel und Jump‘n‘Run gefallen. Die Schnittstelle
soll das Balancevermögen sowie motorisches Feingefühl des Spielers beanspruchen. Diesbezüglich ist das Spielprinzip denkbar einfach: Neige die
Spielwelt und bring die Spielfigur in Bewegung. Durch das Kippen des
Spielbretts läuft der kleine Protagonist Fred in die jeweilige Richtung. Die
grundsätzliche Aufgabe des Spielers ist, Fred alle Kugeln einsammeln zu
lassen. Jedoch warten in FredsWorld einige Hindernisse (Abbildung 10 auf
Seite 19).
Die Basis der Spielsteuerung liefert das altbekannte Holzkugellabyrinth.
Dabei muss eine Kugel durch ein Labyrinth vorbei an Löchern und anderen Hindernisse ins Ziel manövriert werden. Das vertraute KugellabyrinthPrinzip wird durch den Wechsel der Spielfigur und die Erweiterung durch
lustige virtuelle Komponenten zu einem spannenden und abwechslungsreichen Erlebnis.
4.3
4.3.1
Das Spiel – FredsWorld
Das Spielprinzip
Der Spieler hat folglich die Aufgabe, Fred alle Kugeln, die in der Spielwelt verteilt sind, einsammeln zu lassen. Währenddessen lauern einige Gefahren auf Fred. Würmer, die sich frei im Spielfeld bewegen, fressen Fred
und kosten ihn ein Leben. Darüber hinaus verstecken sich in FredsWorld
Wurmlöcher, die Fred nützlich aber auch gefährlich werden können. Fred
kann sich vor Würmern retten, denn er verschwindet im Wurmloch und
taucht am anderen Ende des Lochs wieder auf. Aber Achtung: Schwarze
Löcher, die nur zeitweise erscheinen, verschlucken Fred und nehmen ihm
ein Leben. Zusätzlich lassen Powerups Fred zum Beispiel für eine kurze
18
Abbildung 10: Konzeptskizze.
Zeit durch Wände gehen oder er erhält durch weitere kleine Freds unverwundbare Helfer. Sind alle Kugeln eingesammelt ist das Level geschafft
und das nächste beginnt. Doch ganz so einfach ist es nicht, ist die Zeit abgelaufen oder alle Leben aufgebraucht heißt es: Game over.
4.3.2
Das Holzlabyrinth – Tangible User Interface
Das Herzstück des Spiels ist das Tangible User Interface. Es besteht aus
einem einfachen quadratischen Holzkasten mit zwei Griffen. Der Holzkasten fungiert mit einem grundlegenden Labyrinth als Spielwelt, die durch
das Platzieren von den unterschiedlichen Steckwänden variabel erweitert
werden soll. Der Spieler erhält die Möglichkeit seine Spielwelt individuell
aufzustocken und kann sich zum Beispiel durch das Bauen schmaler Wege selbst neue Herausforderungen kreieren. Zu diesem Zweck stehen dem
Benutzer mehrere Größen von Steckwänden zur Verfügung (Abbildung 11
auf Seite 20). Das Motto lautet: Schaffe deine eigene Spielwelt. Der Grundgedanke bei diesem Konzept ist die Langzeitmotivation des Spielers zu fördern. Um den Schwierigkeitsgrad des Levels zu erhöhen beziehungsweise
in das nächste Level zu gelangen, könnte man den Spieler zum Beispiel
dazu auffordern noch eine weitere Steckwand zu platzieren und eventuell die Geschwindigkeit der Spielfigur steigern. Dadurch wird der Bau der
eigenen Spielwelt selbst ein Teil des Spiels. Virtuelle und reale Welt verschmelzen zu einer Einheit. Ferner wird der Bau durch die realen Wände
19
zur Leichtigkeit. Die Steuerung ist gleichermaßen simpel. Durch das Kippen und Neigen des TUIs wird die Laufrichtung der Spielfigur entsprechend beeinflusst. Diese vertraute Interaktionsform verschafft dem Spiel
Abbildung 11: Konzeptskizze – Tangible User Interface.
die gewünschte Zugänglichkeit. Wodurch auch unerfahrene Spieler nach
wenigen Sekunden intuitiv wissen, wie sie die Figur durch die Spielwelt
lotsen. Zuzüglich soll das TUI am Rand ein Symbol bereit stellen, das eine Knopffunktion übernimmt. Beim Verdecken mit dem Daumen, soll die
dahinter steckende Funktion ausgelöst werden. Dadurch wird die gesamte
Eingabe beziehungsweise Steuerung vom TUI übernommen. Der Rückgriff
auf konventionelle Eingabemittel soll vollkommen verschwinden.
4.3.3
Die Spielfigur und weitere Spielelemente
Bedingt durch die feste Perspektive und Position der Kamera, die überhalb
des Spiels liegt, wird der Protagonist Fred zum einen keinesfalls frontal
von der Seite sichtbar und zum anderen nur sehr klein dargestellt. Eine
detailreiche Erscheinung ist dementsprechend überflüssig. Gesucht wird
eine abstrakte Figur, dessen Körper deutlich geformt ist. Die Grundzüge
sollen nur angedeutet werden. Lediglich der Bewegungsablauf soll deutlich werden. Darüber hinaus wird die Beschränkung auf die visuelle Erscheinung ausreichen, da die Figur nicht mit einer Entstehungsgeschichte oder fiktiven Charaktereigenschaften ausgestattet werden soll. Während
des gesamten Spielverlaufs wird der Benutzer weder Informationen bezüglich des Charakters erhalten noch etwas über seine Vergangenheit erfahren.
Um jedoch den Benutzer zu motivieren und die Spielatmosphäre aufzulo20
ckern, kann Fred zum Beispiel ein wenig unbeholfen wirken. Es soll eine
Figur entstehen mit der sich jedermann identifizieren kann. Abbildung 12
skizziert zwei mögliche Umsetzungen der Spielfigur. Zugleich ist bei der
Abbildung 12: Konzeptskizze – Spielfigur Fred.
Wahl sowie der Gestaltung weiterer Spielelemente, den Sammelpunkten
oder der Powerups, die Perspektive und die Größe der Darstellung zu berücksichtigen. Auch hier gilt: Weniger ist mehr. Die Würmer, die sich frei
im Labyrinth bewegen und Fred mit Genuss verspeisen, sind ebenso zu
abstrahieren. In Abbildung 13 wird eine mögliche Gestalt dargestellt.
Abbildung 13: Konzeptskizze – Würmchen.
21
5
Implementierung
Im Folgenden werden die zentralen Aspekte zur Realisierung des Spielkonzepts erläutert. Zunächst wird die technische Umsetzung, die erst die
Entstehung der eigenen Spielwelt sowie die Interaktion mit dieser ermöglicht, betrachtet. Des Weiteren wird die Realisierung des eigentlichen Spiels
näher dargestellt.
Die Entstehung der benutzervariablen Spielwelt kann durch zwei Kernaufgaben, die Detektion und Intialisierung der Wände sowie die dynamische Initialsierung der Spielelemente, beschrieben werden. Die schematische Darstellung in Abbildung 14 verdeutlicht den groben Spielablauf. Hat
der Spieler seine Spielwelt gestaltet erfolgt die Erkennung und Intialisierung der Wände. Im Anschluss folgt die Initialisierung der Spielemente
und das eigentliche Spiel startet. Während diesen Abläufen wird in einem
parallelen Prozess das Tracking, Buttontracking sowie die Kameraanbindung realisiert. Das Fundament für das Spiel ist auf diese Weise geschaffen
und Interaktion mit der virtuellen Welt wird möglich. Auf dieser Basis wird
die Steuerung der virtuellen Welt, Kollisionserkennung und lustige virtuelle Spielkomponenten realisiert. Darüber hinaus ist die Behandlung von
Verdeckungen sowie die Erstellung von 3D Modellen essenziell, um das
Gesamtkonzept abzurunden.
Bau der
Spielwelt
Detektion/
Initialisierung
Wände
Kameraanbindung
Spielende
Spiel
Initialisierung
Spielelemente
Tracking
Spielwelt
Tracking
Button
nächstes Level
Abbildung 14: Grundlegender Ablauf
5.1
3D Modellierung
Eine wichtige Aufgabe zur Umsetzung des Spielkonzepts ist die 3D Modellierung der einzelnen Spielkomponenten. Dazu waren sämtliche Spielelemente zu modellieren und texturieren. Darunter zählen die Kugeln, Wurmlöcher und Sterne. Zusätzlich zu animieren, waren die beiden beweglichen
Objekte.
22
Diesbezüglich wurden die grundlegenden 3D Modelle in Blender erstellt
und mittels UV-Mapping texturiert. Durch UV-Mapping wird eine 2D- Textur auf ein Modell projiziert. Es wird möglich, die jeweilige Textur im Spielverlauf einfach auszutauschen. Das sorgt für das entsprechende Feedback,
wenn Fred zum Beispiel durch einen Powerup – einen Stern – für eine gewisse Zeit wächst und vom Gejagten selbst zum Jäger wird. Fred wechselt
dafür in die Farbe des Sterns. Der Spieler weiß somit genau, wann die Verwandlung beginnt beziehungsweise endet und kann entsprechend reagieren.
Die Skelettanimation, die von Ogre unterstützt wird, erweckt bewegliche
Objekte wie Fred oder den Wurm zum Leben. Der Grundkörper wird
durch ein Skelett erweitert und durch die Keyframemethode passend animiert. Dabei werden Schlüsselbilder mit verschiedenen Rotationen und
Translationen der Knochen (engl. bones) definiert zwischen denen Blender interpoliert.
Zur Verwendung in Ogre wurden alle Modelle durch den OgreExporter
entsprechend konvertiert.
5.2
Tracking
Das Tracking stellt eine der größten Herausforderungen zur Umsetzung
des Spielkonzepts dar. Erfolgt das Tracking nicht in Echtzeit oder wird der
sogenannte Jitter Effekt – virtuelle Objekte sind noch in Bewegung obwohl
die reale Umgebung starr ist – erkennbar, wird die Benutzerinteraktionsfähigkeit deutlich gemindert. Ziel war es ein stabiles Tracking zu realisieren,
welches das grundlegende Spielkonzept unterstützt.
5.2.1
Kameraanbindung und Darstellung
Für das Tracking wird als Eingabe ein Videodatenstream benötigt. Im Hinblick darauf wurde zur Kameraanbindung zunächst OpenCV verwendet.
Die fehlende Konfigurierbarkeit der Kameraeinstellungen wie automatischer Autofokus und Weißabgleich hatte ein schlechtes Trackingergebnis
zur Folge. OpenCV bietet diesbezüglich nur im geringen Maße Einstellungsmöglichkeiten. Darüber hinaus wurde bei OpenCV die Einstellung
der Bildauflösung beim Capturing nicht übernommen. Die Lösung fand
sich dann in der videoInput Library.
Mit Hilfe der videoInput Library wird stets das aktuelle Kamerabild mit
der Auflösung 640x480 in RGB abgefangen. Ist ein neues Bild verfügbar
wird dies ausgelesen und an den Tracker übergeben. Das Bild wird als
Iplimage, das Bilddatenformat von OpenCV, gespeichert und kann vom
ButtonTracker, der im Abschnitt 5.2.4 beschrieben wird, sowie von Ogre verwendet werden. Zur Darstellung des aktuellen Kamerabildes in der
Ogre Szene wurde ein Rechteck erstellt, welches die gesamte Szene über23
deckt und stets als erstes gerendert wird. Ändert sich das Kamerabild wird
entsprechend das Material des Rechtecks aktualisiert. Weitere Information
hierzu finden sich im OgreWiki 11 .
Um sämtliche Funktionen, die nicht im direkten Zusammenhang mit dem
Kamerabild stehen, parallel ablaufen zulassen, wurde die Kamera und
das gesamte Tracking mit Hilfe der Boost Bibliothek 12 in einen separaten
Thread ausgelagert.
5.2.2
Erweiterung von ARToolKitPlus
Ziel der Erweiterung von ARToolKitPlus ist einen unauffälligen, platzsparenden, auf den zu trackenden Holzkasten angepassenten Marker zu entwerfen. Zu diesem Zweck wird der ID-Marker von ARToolKitPlus grundlegend modifiziert. Die Marker-ID wird auf den Rand des Markers beschränkt beziehungsweise umgelagert. Das Tracking benötigt infolgedessen nur einen äußeren Rahmen, der aus einer ID und der Markerrumrandung besteht – die Mitte des Markers bleibt unbeachtet. Prinzipell kann
demzufolge alles in den Holzkasten hineingelegt werden ohne, dass das
Tracking beeinträchtigt wird.
Dementsprechend wurde neben den ID-Marker, BCH-Markern sowie den
üblichen ARToolKit Markern eine weitere Markerart, die im weiteren Verlauf als Border Marker bezeichnet wird, integriert. Der Border Marker besteht aus zwei aufeinander passenden von ARToolKitPlus vordefinierten
IDs (Abbildung 15). Die Verwendung von zwei IDs vereinfacht vor allem
das Auslesen und ermöglicht den Rückgriff auf die Basisfunktionen von
ARToolKitPlus.
Abbildung 15: Tracking – Border Marker – Links erste ID, Rechts zweite ID.
11
http://www.ogre3d.org/tikiwiki/Displaying+2D+Backgrounds,
02.05.2011
12
http://www.boost.org/, Stand 15.05.2011
24
Stand
Im Allgemeinen bestimmt der Markeraufbau beziehungsweise die Markerkodierung die Art und Weise wie das Pattern des Markerinneren auszulesen ist. Ergebnis des sogenannten Pattern-Matching, das im Abschnitt 2.2.3
beschrieben wird, ist die Identifizierung des Markers sowie die entsprechende Rotation. Dementsprechend ist ein weiteres Verfahren zu implementieren, das die Behandlung der Border Marker im Pattern-Checking Teil
übernimmt.
Zunächst wird das 18x18 RGB Pattern, dass der Methode übergeben wird,
in ein 18x18 Grauwertbild konvertiert. Daraufhin folgt ein Thresholding
und folglich die Erstellung des ID-Pattern Bitfeldes. Ist das automatische
Thresholding vom jeweiligen Tracker aktiviert, wird der dynamisch generierte Schwellwert von ARToolKitPlus verwendet. Ansonsten wird ein vom
Benutzer definierter und konstanter Wert genutzt.
Im Wesentlichen unterscheidet sich die Erstellung des Bitfeldes im Gegensatz zu den gebräuchlichen ID-Markern darin, dass lediglich die ersten und
letzten 18 Pixel ausgelesen beziehungsweise binarisiert werden. Das entstandene 36 Bitfeld entspricht dem ID-Marker Bitfeld und kann demnach
grundlegend auf die selbe Weise behandelt werden. Infolgedessen wird zur
Ermittlung der ID und dessen Wahrscheinlichkeit, die einen Wert zwischen
0.0 und 1.0 darstellt, die bereits definierte Methode der ID-Marker verwendet.
Im Folgenden wird das Bitbild zusätzlich um 180◦ gedreht und gleichermaßen dessen ID sowie Wahrscheinlichkeit berechnet. Im nächsten Schritt
werden die Wahrscheinlichkeiten der beiden Rotationen (0◦ und 180◦ ) verglichen und lediglich die höhere weiterhin in Betracht gezogen.
Handelt es sich um die erste ID (Abbildung 15 auf Seite 24, Links) kann
die Rotation direkt übernommen werden. Bei der zweiten ID (Abbildung
15 auf Seite 24, Rechts) hingegen, muss die Rotation noch um 90◦ erhöht
werden. Das bedeutet 0◦ entsprechen einer 90◦ Rotation und die 180◦ einer
270◦ Rotation des Markers (Abbildung 16 auf Seite 26). Ist der nun abgelegte Konfidenzfaktor, also der höchste Wahrscheinlichkeitswert, größerer
als 0.9 gilt die Marke als erkannt und ARToolKitPlus kann die ID, die Markerrotation sowie den entsprechenden Konfidenzfaktor weiter verwerten.
Die eigentliche Grundidee: Einen dezenten vor allem platzsparenden Marker zu schaffen, gab den nötigen Implus nicht genutzte Bits des Markerpattern zur Detektion der Wände (Abschnitt 5.4) zu verwenden.
5.2.3
Integration und Initialisierung von ARToolKitPlus
Zur Realisierung des eigentlichen Trackingvorgangs wurde eine Instanz
der Klasse SingleTracker von ARToolKitPlus erstellt, da lediglich ein
Marker pro Bild erkannt werden soll. Beim Instanzieren eines Trackers
wird zum einen die Bitmustergröße, die in diesem Fall 18x18 beträgt, und
zum anderen die Bildkantenlängen festgelegt. Des Weiteren wird der Mar25
180°
180°
Abbildung 16: Tracking – Oben erste ID 0◦ Rotation, Unten zweite ID, Identifizierung bei 180◦ dadurch 270◦ Markerrotation
kermode auf Border Marker, die im Abschnitt 5.2.2 näher erläutert werden,
gesetzt. Im Folgenden sind noch die entsprechenden Einstellungen wie
zum Beispiel die Markergröße und Rahmenbreite zu definieren. Die Markergröße beträgt 360 mm und die Kantenbreite, die in Relation zur Markergröße angegeben wird, entsprechen ebenso wie die Kästchen des 18x18
Bitmusters genau ein Zwanzigstel der Markerkante. Des Weiteren wird der
SingleTracker anhand der Kamerakalibrierungsdatei sowie der Angabe der Near- und Farplane für die Projektionsmatrix initialisiert. Bei der
Kalibrierungsdatei handelt es sich um die mitgelieferte Standarddatei. Das
Ergebnis hat gezeigt, dass eine Kalibrierung der Kamera in unserem Fall
nicht nötig ist. Daraufhin wird die Projektionsmatrix anhand des ARToolKitPlus ermittelt und in Ogre gesetzt. Um ein robustes Trackingresultat zu
erhalten wird das Autothresholding aktiviert und die Poseberechnung auf
RPP (Robust Planar Pose) eingestellt. Der Robust Planar Pose Algorithmus
vermeidet den so genannten Jitter Effekt (vgl. [ARTb]).
Wird nun dem Tracker das aktuelle Kamerabild übergeben beginnt dieser
mit der Detektion des Markers wie in Abschnitt 2.2.3 beschrieben. Bei erfolgreicher Detektion wird die Modelviewmatrix ermittelt und die extrinsischen Kameraparameter zur Transformation können ausgelesen werden.
Generell besteht die 4x4 Matrix, die die relative Lage des Markers zur Kamera beschreibt, aus einer Rotations- und Translationskomponente (siehe
26
Transformationsmatrix 1). Zur Verwendung in Ogre wird die Orientierung
in einem Quaternion und die Translation in einem 3D Vektor abgelegt. Bei
der Konvertierung ist darauf zu achten, dass die von ARToolKitPlus berechnete Modelviewmatrix spaltenweise definiert ist.


  
R11 R12 R13 Tx
Xm
Xc
 Yc  R21 R22 R23 Ty   Ym 


 =
 Zc  R31 R32 R33 Tz   Zm 
0
0
0
1
1
1
5.2.4
(1)
Tracking Button
Eines der grundlegenden Ziele ist es, konventionelle Eingabemittel wie
Maus oder Tastatur vollkommen verschwinden zu lassen. Die Spielsteuerung soll einzig allein mit dem TUI erfolgen. Zu diesem Zweck ist am Rand
des TUIs noch ein blauer Kreis angebracht, der eine Art Knopffunktion bereitstellt. Durch Verdeckung wird die entsprechende Funktion, wie zum
Beispiel das Starten des Spiels, ausgelöst.
Der Kerngedanke ist nur den Bildbereich indem sich der Button befindet
auf Farbgegebenheiten zu untersuchen. Dazu werden stets die aktuellen
Eckpunkte des Markers, die ARToolKitPlus liefert, verwendet. Da sämtliche Längenverhältnisse zwischen den Eckpunkten und Knopf bekannt
sind, kann anhand des Strahlensatzes der Mittelpunkt des Kreises berechnet werden. Mit Hilfe der ROI-Funktion (Region of Interest) von OpenCV
wird daraufhin der passende Bildbereich eingegrenzt (Abbildung 17). Dabei muss sicher gestellt werden, dass der gewünschte Bereich innerhalb des
Bildes liegt. Die Größe des Bildbereichs bleibt konstant, da der Abstand
zwischen realer Spielwelt und damit der Button und Kamera nur geringfügig ändert. Im Bildausschnitt werden nun die Pixel, welche mit geringen
Bild
ROI
Bildausschnitt
Abbildung 17: Tracking Button – Region of Interest.
27
Varianzen dem Farbwert vom Blau entsprechen, gezählt. Ist die Anzahl
kleiner als ein Viertel der gesamten Pixelanzahl, gilt der Knopf prinzipell
als gedrückt. Um versehentliche Auslösungen zu vermeiden, muss die Verdeckung eine gewisse Dauer anhalten.
5.3
Verdeckungen
Neben dem Tracking ist Realisierung von Verdeckungen zur Umsetzung
des Konzepts bedeutend, um den gewünschten Eindruck – beide Welten in
einer Einheit – zu schaffen. Die Behandlung von Verdeckungen wird zwingend notwendig, um den 3D Eindruck zu bewahren. Wird die Sicht auf ein
virtuelles Objekt von einem natürlichen Gegenstand behindert, ist dies auf
die Augmented Reality Szene zu übertragen. Die Realisierung von Verdeckungen wird anhand des modellbasierten Verfahren gelöst. Das Verfahren
sieht ein Modell der Realität vor, welches in seiner Größe, Ausrichtung und
Position den realen Objekten entspricht. Das geometrische Modell wird deckungsgleich zum realen Gegenstück in Kamerakoordinaten angeordnet
und übernimmt die Eigenschaften des Originals in der virtuellen Welt (vgl.
[BBR+ 95, S. 8-9]).
Das Verfahren ist für die Umsetzung des Spielkonzepts bestens geeignet,
da die Realität, die wesentliche Spielwelt, bloß aus einem Kasten und Wänden in verschiedenen Längen besteht. Aufgrund dessen wurde ein Modell als Pendant des grundlegenden Holzkastens erstellt (Abbildung 18).
Zur Repräsentation der Wände wurde lediglich ein Modell erstellt, das
Abbildung 18: Verdeckung – Links reale Spielwelt, Rechts virtuelles Modell.
durch Zusammensetzen dynamische Wandlängen ermöglicht (Abbildung
18, rechts). Um die Wahrnehmung einer Verdeckung durch das reale Objekt zu erhalten, ist das Materialskript (siehe Anhang A) dementsprechend
definiert, dass das jeweilige Modell lediglich in den Z-Buffer geschrieben
wird, ohne das es in den Framebuffer gezeichnet beziehungsweise in den
Colorbuffer geschrieben wird. Im Renderpass der Materialdatei der Geometrie wird im Hinblick darauf das Attribute colour_write ausgestellt.
28
Dadurch werden ausschließlich die Tiefeninformationen des Modells in die
virtuelle Realität übernommen. Anhand der aktuellen Trackingdaten, die
im vorgehenden Abschnitt 5.2 näher erläutert wurden, können die Modelle
während des gesamten Spiels stets exakt auf ihren realen Gegenpart gelegt
werden.
Zur Umsetzung der Kollisionserkennung (Abschnitt 5.7) kann dadurch auf
konventionelle Verfahren aus dem Bereich Computergrafik zurückgriffen
werden.
5.4
Detektion und Initialisierung der Wände
Zur Detektion der Wände wird, wie bereits erwähnt, das entzerrte Markerpattern, das uns ARToolKitPlus liefert, verwendet. Wurde der Marker im
Videobild gefunden, folgt ein Thresholding des Graustufenbildes anhand
eines fest definierten Schwellwerts. Das Schwellwertverfahren beschränkt
sich lediglich auf die 16x16 Pixel im Inneren des Patterns. Das Ergebnis ist
ein 16x16 großes Binärbild, das der Wandunterteilung der Spielwelt entspricht (Abbildung 19). Die Berechnung und Speicherung des Bitfeldes erfolgt zu Beginn des Spiels einmalig mit der entsprechenden Rotation und
kann daraufhin für die Initialisierung der Wände verwendet werden. Vor
Abbildung 19: Detektion und Initialisierung der Wände – Links Spielfeldunterteilung in 16x16 Felder, Rechts 16x16 Binärbild.
der letztendlichen Erstellung und Positionierung der Wände muss das Binärbild noch gemäß der gespeicherten Rotation gedreht werden, damit die
Wände die richtige Position erhalten. Hierzu wird das Bit-Pattern entsprechend der Drehung gegebenenfalls mehrfach um 90◦ dreht. Daraufhin wird
das Bitfeld ausgelsen. Zunächst wird im Hinblick darauf über die Zeilen
iterriert. Ist ein Bit gesetzt, hat also folglich den Wert 0, wird ein Objekt der
Klasse Wall angelegt. Folgt ein weiteres gesetztes Bit in der selben Zeile
wird die Wall-Instanz um ein Feld erweitert. Folgt kein weiteres gesetz29
tes Bit und besetzt die Wand mehr als ein Feld kann die jeweilige Instanz
initialisiert werden. Das Objekt setzt diesbezüglich die 3D Modelle an die
richtige Position, erstellt die korrespondierende Bounding Box und registriert sich beim Kollisionsmanager, der im Abschnitt 5.7 erläutert. Hierbei
wird auf einer Kopie des Bitfelds gearbeitet. Auf diese Weise kann das Bitfeld entsprechend modifiziert werden, um eine Doppelbelegung der Wände zu vermeiden. Sind alle Zeilen durchlaufen, folgt auf die selbe Weise die
Initialisierung der vertikalen Wände. Das bedeutet, der selbe Vorgang folgt
für die Spalten. Jedoch werden hier auch Wände, die nur Feld besetzen,
gesetzt. Zwar stehen nur Wände, die zwei Felder belegen, zur Verfügung,
aber in besonderen Fällen würde sonst ein Teil der Wand fehlen (Abbildung
20).
Abbildung 20: Detektion und Initialisierung der Wände – Ergebnis der Initialisierung.
5.5
Initialisierung der Spielelemente
Nach der erfolgreichen Initialisierung der Wände stellt sich die Aufgabe
sämtliche Spielelemente im Spielfeld zu verteilen. Die Objekte müssen vor
jedem Spielbeginn dynamisch generiert werden. Diesbezüglich werden im
ersten Schritt die möglichen Positionen anhand des Patterns unter Beachtung der gesetzten Wände berechnet. Eine Position belegt hierbei genau
vier Felder (Abbildung 21 auf Seite 31, gelb hervorgehoben). Dabei ist zu
beachten, dass die Startposition der Spielfigur Fred nicht von einer Spielkomponente belegt wird (Abbildung 21 auf Seite 31, blau hervorgehoben).
Die ermittelten freien Plätze werden in einem Standard-Vektor gespeichert
und stehen somit während dem gesamten Spielverlaufs zur Verfügung.
Dies ist notwendig, um zum Beispiel einen Levelübergang zu realisieren.
Sind alle verfügbaren Wände durch den Benutzer gesetzt, sind 36 Felder
30
Abbildung 21: Initialisierung der Spielelemente – Gelb, Belegung einer Position –
Blau, Startposition von Fred.
belegt. Dadurch stehen nach Abzug der Startposition von Fred 54 Positionen für die Spielkomponenten zur Verfügung. Die Spielelemente wie zum
Beispiel die Kugeln, Würmer und Wurmlöcher können demnach bedenkenlos per Zufall positioniert werden. Besetzte Positionen werden dabei
aus dem Vektor gelöscht, um eine Doppelbelegung zu vermeiden. Sind alle Spielkomponenten initialisiert, erfolgt anhand einer Kopie des Vektors
ein Refresh der ermittelten Plätze. Bei der Positionierung der Wurmlöcher
wird zusätzlich darauf geachtet, dass ein Mindestabstand zwischen zwei
assoziierten Löchern besteht.
5.6
Steuerung – Tangible Control
Das Grundprinzip in FredsWorld lautet: Neige die Spielwelt und bring
Fred in Bewegung. Zur Realisierung stellen sich somit zwei grundlegende
Aufgaben. Zum einen sind alle Spielelemente entsprechend der aktuellen
Pose (Position und Orientierung) auszurichten, zum anderen muss Fred
sich gemäß der Neigung in Bewegung setzen.
Die erste Aufgabe löst sich durch Anwendung der Trackingdaten, basierend auf dem Szenengraphenprinzip, recht einfach. Diesbezüglich wird
ein Wurzelknoten für die gesamte Spielwelt definiert. Die gesamte Szene
beziehungsweise die Spielelemente werden diesem Knoten untergeordnet.
Eine Transformation auf dem Wurzelelement transformiert alle untergeordneten Kindknoten entsprechend. Folglich werden die Trackingdaten,
die Position und Orientierung, lediglich auf das Wurzelelement angewendet. Dabei bleibt die virtuelle Kamera im Ursprung des Weltkoordinatensystems und das Wurzelelment, welches den leeren Holzkasten repräsentiert, wird in Relation zur Kamera positioniert und orientiert. Das lokale
31
Koordinatensystem der Spielwelt wird im weiteren Verlauf als FredsWorld
bezeichnet.
Die Pose des virtuellen Spielbretts korrespondiert nun mit dem realen
Spielfeld. Diese Gegebenheit gestaltet die zweite Aufgabe – Fred in die
richtige Richtung laufen zu lassen – ebenso leicht. Die Kernidee ist es,
die Neigungsrichtung des Spielbretts durch Ausrichtung des Up-Vektors
(y-Achse) des lokalen Koordinatensystem FredsWorld zu bestimmen (Abbildung 23 auf Seite 33). Die Berechnung der Laufrichtung von Fred wird
durch die Beschränkung auf acht Richtungen zusätzlich vereinfacht (Abbildung 22). Zur Berechnung der Laufrichtung beziehungsweise dem Rich-
Abbildung 22: Steuerung – 8 Laufrichtungen von Fred.
tungsvektor von Fred wird der Winkel zwischen Up-Vektor und den globalen Achsen näher betrachtet. Ist zum Beispiel der Winkel zwischen dem
Vektor und der x-Achse des Weltkoorinatensystems größer als 90◦ , ist das
Brett nach rechts geneigt und der Richtungsvektor wird in der entsprechenden Komponente gesetzt. Fred würde nach rechts laufen. Gilt dies ebenso
für den Winkel mit der globalen y-Achse, zeigt der berechnete Richtungsvektor in die obere rechte Ecke.
Durch die Berechnung kann dem Spieler eine gewisse Kontrolle gegeben
werden. Fred soll erst los laufen sobald ein gewisser Neigungswinkel erreicht ist. Des Weiteren wird der Winkel zwischen Up-Vektor sowie der
zum Spielbrett senkrecht stehenden Achse des Weltkoordinatensystems ermittelt, um die Berechnung einer Beschleunigung zu ermöglichen.
Generell steht zur Umsetzung des Spielkonzepts die Benutzerfreundlichkeit vor der physikalischen Korrektheit. Sämtliche Berechnungen werden
aufgrund dessen lediglich physikalischen Gesetzmäßigkeiten angenähert.
Dies gilt auch für den Beschleunigungswert. Der Wert ergibt sich aus einer
Abtastung des Neigungswinkels. Dieser wird mit einem konkreten Wert
abgelaufen und der Beschleunigungswert entsprechend mit einer Konstan32
-z w
yfw
zfw
yfw
xfw
-x w
x fw
Abbildung 23: Steuerung – Berechnung der Laufrichtung.
te erhöht. Ist der Richtungsvektor d~ und die Beschleunigung acc ermittelt,
kann anhand der alten Position ~r und der konstanten Geschwindigkeit v
die neue Position berechnet werden. Die aktuelle Geschwindigkeit vcurr ergibt sich aus der konstanten Geschwindigkeit v und der Beschleunigung
acc .
vcurr = v + acc
(2)
rneu
~ = ~r + d~ ∗ (vcurr ∗ t)
(3)
Die Multiplikation der Geschwindigkeit mit dem Wert t, der die aktuelle
Zeit zwischen zwei Bildern beschreibt (engl. time since last frame), wird
notwendig um die Bewegung unabhängig von den variierenden Frames
per Second (fps) zu erhalten. Dies gilt ebenso für die entsprechende Bewegungsanimation des Objekts. Diesbezüglich wird ein Bewegungsfaktor
f berechnet, der die Geschwindigkeit des Animationsablaufs an die aktuellen Geschwindigkeit des Objekts vcurr sowie der vergangenen Zeit zwischen zwei Bildern t anpasst.
f = vcurr ∗ t
(4)
Im Folgenden ist die Orientierung zu aktualisieren. Gesucht wird das Quaternion, das die Rotation zwischen aktuellen und neuen Richtungsvektor
beschreibt. Der aktuelle Richtungsvektor wird aus dem Quaternion, das
die aktuelle Orientierung beschreibt, gewonnen. Dazu muss das Quaternion lediglich mit der entsprechenden Bezugsachse, der y-Achse des Koordinatensystems FredsWorld, multipliziert werden. Nach der Normalisierung
des gewonnen Vektors wird das Quaternion, das die Drehung von einem
zum anderen Vektor beschreibt, ermittelt. Nun ist noch eine 180◦ Drehung
abzufangen, da sonst durch Ogre eine beliebige Achse zur Rotation verwendet wird, um eine Division durch Null zu vermeiden. Hierzu wird anhand des Skalarprodukts der beiden normalisierten Vektoren festgestellt,
33
ob es sich um eine 180◦ Drehung handelt. Ist dies der Fall wird einfach
um 180◦ um die y-Achse rotiert. Liegt keine 180◦ Rotation vor, erfolgt die
relative Drehung des Objekts anhand des ermittelten Quaternions. Mehr
Informationen dazu finden sich im OgreWiki 13 .
5.7
Kollisionserkennung
Die Kollisionserkennung ist ein wesentlicher Bestandteil zur Umsetzung
des Spielkonzepts. Neben der Kollision mit virtuellen Spielkomponenten
ist die Kollision mit realen Elementen – den Wänden – zu realisieren, um
den Eindruck der Interaktion beider Welten zu verwirklichen.
Zur Realisierung der Erkennung einer Kollision werden alle virtuellen als
auch realen Spielelemente von einer so genannten Axis Aligned Bounding
Box (AABB) umschlossen. AABBs sind Bounding Boxen, die an den Achsen
des Weltkoordinatensystems ausgerichtet sind. Im Allgemeinen wird das
zu umschließende Objekt weniger genau approximiert, da in vielen Fällen zu viel Freiraum mit einbezogen wird (vgl. [Zer02, S. 200]). In unserer
Spielwelt hingegen sind die meisten Kollisionsobjekte Wände, die immer
achsenparallel verlaufen und somit exakt durch eine AABB repräsentiert
werden können. Andere Spielkomponente wie zum Beispiel die Spielfigur
Fred werden jedoch nur angenähert. Die Genauigkeit geht hier auf Kosten
der Geschwindigkeit. AABBs bieten den großen Vorteil der leichten Berechnung. Einerseits gilt dies für die Erstellung der Bounding Box um das Modell, aber andererseits gilt dies auch für den Kollisionstest. Somit sind diese im Gegensatz zu anderen Bounding Boxen ausgesprochen schnell (vgl.
[Zer02, S. 200]). Um eine Neuberechnung der Bounding Box bei Änderung
der Orientierung von beweglichen Objekten wie Fred zu vermeiden, werden diese mit einer quadratischen Box umschlossen (Abbildung 24). Darüber hinaus kann somit die diagonale Laufrichtung realisiert werden.
Abbildung 24: Axis Aligned Bounding Box – Fred.
In FredsWorld spielt sich sämtliche Bewegung von Objekten ausschließlich
im 2D-Raum ab. Das bedeutet zum Beispiel, dass sich Fred nur in der x13
http://www.ogre3d.org/tikiwiki/Intermediate+Tutorial+
1&structure=Tutorials, Stand 10.05.2011
34
und z-Ebene des Koordinatensystems der Spielwelt bewegt. Die Kollisionserkennung kann somit lediglich auf zwei Dimensionen reduziert werden.
Zur Feststellung einer Kollision zwischen zwei Objekten werden die jeweiligen minimalen und maximalen z-Werte und x-Werte der Bounding Boxen
verglichen. Bei einer Überlappung auf beiden Koordinatenachsen schneiden sich die beiden Boxen und die Objekte sind kollidiert (vgl. [Mül10a]).
zfw
x fw
Abbildung 25: Axis Aligned Bounding Box – Kollisionstest.
Zur Umsetzung des Konzepts wurde eine Klasse CollisionHandler erstellt. Diese Klasse erhält die Aufgabe sämtliche Kollisionsobjekte zu verwalten und den paarweisen Kollisionstest durchzuführen. Durch die globale Instanzierung kann sich jedes Kollisionsobjekt aus einem beliebigen
Programmabschnitt bei dem Kollisionsmanager anmelden. Hierzu wurde
eine Klasse CollisionObject implementiert von der alle Klassen, die in
die Kollisionserkennung mit einbezogen werden, ableiten. Die Klasse stellt
zum einen sicher das jedes Objekt eine AABB enthält. Zum anderen wird
eine Methode bereitgestellt, die zurückgibt ob das Objekt gerade aktiv ist
oder nicht. Dadurch können Spielelemente während des Spielverlaufs deaktiviert und aktiviert werden. Das ist zum Beispiel wichtig, wenn Fred
durch einen Powerup kurz durch Wände gehen kann.
Zusätzlich leitet die abstrakte Klasse MovableCollisionObject von
CollisionObject ab, von der die beweglichen Objekte – Wurm und
Fred – erben. Diese Klasse enthält zusätzlich noch die rein virtuelle Methode collisionHandling(CollisionObject *object), die vom Kollisionsmanger bei einer Kollision aufgerufen wird. Dabei wird eine Referenz auf die Instanz, mit dem das bewegliche Kollisionsobjekt kollidiert
ist, übergeben und die entsprechende Kollisionbehandlung ausgeführt.
35
5.8
Virtuelle Spielkomponenten
Um dem Ziel, ein erlebnis- und abwechslungsreiches Spiel zu gestalten,
gerecht zu werden, finden sich im Spiel lustige virtuelle Komponenten wie
die Wurmlöcher oder Powerups wieder. Ferner sorgt die Steigerung des
Schwierigkeitsgrads sowie wechselnde Powerups für die passende Unterhaltung.
Wurm Gibt es einen Protagonist in einem Spiel, dürfen die Antagonisten
natürlich nicht fehlen. Ein Wurm bewegt sich unabhängig von der aktuellen Neigung frei im Spielfeld.
Grundsätzlich verhält sich der Wurm ebenso wie sein Rivale. Jedoch kann
der Spieler zum einen die Laufrichtung des Wurms nicht durch das Kippen des Spielbretts beeinflussen. Zum anderen kann sich der Wurm statt in
acht nur in vier Richtungen bewegen. Die diagonale Laufrichtung fällt somit weg. Zu Spielbeginn erhält der Wurm eine Zufallsrichtung. Wie in Abschnitt 5.6 schon deutlich geworden ist, wird das Objekt hierzu entlang seines Richtungsvektors in Abhängigkeit von einer konstanten Geschwindigkeit und der Zeit zwischen zwei Frames verschoben. Kollidiert der Wurm
mit einer Wand, wird eine neue Zufallsrichtung bestimmt und die Orientierung entsprechend aktualisiert. Da die Berechnung der Orientierung von
Fred als auch vom Wurm verwendet wird, befindet sich die entsprechende
Methode in der Klasse MovableCollisionObjekt.
Schwarzer Wurm Neben einfachen Würmern tauchen im gesamten
Spielverlauf immer wieder schwarze Würmer auf, die für Fred noch gefährlicher werden können, denn sie bewegen sich um einiges schneller.
Die Klasse BlackWorm spezialisiert hierzu die Klasse Worm. Generell verhält sich der schwarze Wurm somit äquivalent zum üblichen Wurm. Jedoch
enthält die Klasse BlackWorm eine weitere Methode die den Farbwechsel und die Geschwindigkeitsänderung übernimmt. Diese Methode wird
nach dem Ablauf einer Zufallszeit aufgerufen. Dabei wurde darauf geachtet, dass bei der Bestimmung der Zeit ein gewisses Intervall eingehalten
wird. Damit wird gewährleistet, dass die Transformation einerseits nicht in
zu geringen Zeitabständen erfolgt – der Effekt würde sich durch ein kurzes
Aufflackern der schwarzen Textur äußern. Andererseits darf die Transformation nicht zu lange anhalten, damit der Schwierigkeitsgrad nicht wesentlich erhöht wird.
Wurmloch Einerseits bietet das Wurmloch für Fred eine Hilfestellung. Er
kann sich vor Würmern retten. Verschwindet Fred in einem Loch taucht er
am anderen Ende wieder auf. Andererseits kann ihm das Wurmloch auch
zum Verhängnis werden, denn manchmal gestaltet sich der Weg zur verlo-
36
renen Kugel ein wenig schwieriger.
Jedes Wurmloch wird im Hinblick darauf mit einem entsprechenden
Wurmloch gleicher Farbe assoziiert. Der Spieler weiß also wo er landet
und kann entsprechend planen wie er das Wurmloch am besten für sich
nutzt. Da auch die Würmer durch ein solches Loch an einen anderen Ort
gelangen, wurde die Kollisionsbehandlung generalisiert. Trifft ein Wurm
oder Fred auf ein Wurmloch, wird die ensprechende Instanz vom Kollisionsmanager benachrichtigt. Das Objekt dreht sich zum Mittelpunkt des
Wurmlochs und es wird eine Animation abgespielt. Dabei erhielten beide
Geometrien eine Animation WormholeIn und WormholeOut. Fred hüpft
und der Wurm kriecht in das Loch. Ist die Animation abgelaufen wird zunächst die Position des Objekts auf den assoziierten Wurmloch gesetzt und
die Animation WormholeOut abgespielt.
Powerups Ingesamt enthält das Spiel vier verschiedene Powerups, die
durch einen Stern in verschiedenen Farben repräsentiert werden. Der lila
gefärbte Stern lässt Fred schrumpfen und somit schnell und wendig werden. Das Objekt wird dazu auf eine bestimmte Größe skaliert und die Textur in die entsprechende Farbe geändert. Jedes Powerup hält eine konstante Zeit an. Ist die Zeit abgelaufen wird die Rücktransformation – Fred wird
wieder zum Original – notwendig. Ist Fred gerade lila muss er wieder seine
Normalgröße erreichen. Folglich gestaltet sich die Vergrößerung problematischer, es muss gewartet werden bis Fred ausreichend Platz hat. Erst daraufhin kann skaliert und die Originaltextur gesetzt werden. Neben dem
lila gefärbten Stern lässt der gelbe Stern Fred durch Wände gehen. Währenddessen wird Fred unverwundbar. Hierzu werden die Wände lediglich
für Fred deaktiviert. Zum Symbol der Unverwundbarkeit erhält Fred zu
der gelben Farbe eine Art Schein beziehungsweise Schutzkugel. Der pinke
Stern verleiht Fred viele kleine unverwundbare Helfer. Die kleinen Freds
werden durch den Rückgriff auf die freien Positionen aus Abschnitt 5.5
per Zufall in der Spielwelt verteilt und agieren auf gleiche Weise wie Fred.
Genauer betrachtet bedeutet das, dass die kleinen Freds eine Generalisierung von Fred darstellen. Ist die Zeit des Powerups vorüber, verblassen die
kleinen Freds bis sie vollkommen verschwunden sind. Dies wird durch die
Veränderung des Alphawerts der Textur realisiert. Der schwarze Stern lässt
Fred riesig werden. Fred kann für kurze Zeit Würmer fressen.
Levelgestaltung Um einen steigenden Schwierigkeitsgrad bei einem Levelübergang zu erhalten wird die Laufgeschwindigkeit um einen konstanten Wert erhöht. Es wird schwieriger Fred zu steuern und Hindernisse zu
umgehen. Neben der Geschwindigkeitsänderung wird in jedem Level ein
anderes Powerup zur Hilfestellung gegeben. Den Spieler erwartet immer
etwas Neues.
37
5.9
Sound
In FredsWorld – eine Spielwelt die das altbekannte Kugellabyrinth und digitale Elemente vereint – ist ein akustisches Feedback unentbehrlich. Der
Gesamteindruck einer Einheit wird gestärkt und das Spielkonzept gänzlich
abgerundet. Anhand der Bibliothek OgreAL, die in Abschnitt 2.2.5 näher
beschrieben ist, wird für die entsprechende Rückmeldung gesorgt. Kollidiert Fred mit einem Wurm, Kugel oder Wurmloch wird ein kurzer Sound
abgespielt, welcher der jeweiligen Gegebenheit entspricht. Dem Spieler
wird somit nochmal verdeutlicht, was gerade passiert ist. Die Auswahl ist
dabei auf übliche Sounds aus dem Bereich Konsolen- und Computerspielen
gefallen. Dabei wurde darauf geachtet, dass die Sounds die Situation prägnant zum Ausdruck bringen. Auch schon ein einfaches „bling“erreicht die
gewünschte Wirkung. Neben der Realisierung von Tönen für die Spielfigur
wurde der Button um einen passenden Sound erweitert. Der Spieler erhält
hierdurch Feedback, ob der Knopf ausgelöst wurde.
5.10
Overlays und Benutzerführung
Während des gesamten Spielverlaufs soll der Spieler Erklärungen sowie Informationen zum Spiel und aktuellen Spielstatus erhalten. Hierfür werden
Overlays verwendet. Overlays bieten die Möglichkeit eine 2D-Ebene über
die gesamte Szene zu legen. Die Ebene wird als letztes gerendert und befindet sich entsprechend immer im Vordergrund. Im Allgemeinen eignen sich
Overlays gut für nicht interaktive Elemente. Da ohnehin nur Information
dargestellt und keine gebräuchlichen GUI-Komponenten benötigt werden,
bieten sich einfache 2D-Overlays an.
Das Spiel beinhaltet zwei Intros, die durch animierte Texturen der jeweiligen Overlays realisiert sind. Das erste Intro läuft zu Beginn des Spiels in
einer Endlosschleife bis der Button ausgelöst wird. Der Benutzer erhält Informationen sowie die Aufgabe zum Bau der eigenen Spielwelt. Die Erstellung von animierten Texturen gestaltet sich in Ogre recht einfach. Diesbezüglich ist das entsprechende Materialskript zu ändern. In der Texture Unit
(dt. Textureinheit) wird hierzu unter Angabe des Attributs anim_texture
auf mehrere Textur verwiesen. Neben der Angabe der jeweiligen Textur ist
die Anzahl der Frames sowie die Dauer der Animation festzulegen. In der
Abbildung 26 auf Seite 39 ist beispielhaft der Ablauf der Einleitung dargestellt. Das Skript findet sich im Anhang A. Das zweite Intro, dass das
Spielprinzip kurz und prägnant verdeutlicht, ist nach dem gleichen Prinzip umgesetzt. Im Gegensatz zum ersten Intro, das in einer Endlosschleife
läuft, sind die Frames manuell zu setzen, um den Start und das Ende der
Animation zu definieren. Ein Overlay zur Einführung in das Spiel wird
über die gesamte Szene aufgespannt. Damit der Nutzer dennoch weiß, ob
er noch im Bild ist, um den Knopf auszulösen, wird das Kamerabild noch-
38
Abbildung 26: Overlays und Benutzerführung – Overlay. Einführung in den
Spielbau.
mal auf ein separates Overlay gelegt. Das Bildelement erhält dabei einen
niedrigeren Z-Wert, um nach dem ursprünglichen Overlay gerendert zu
werden. Neben der Einführung in das Spiel wird durch Overlays vor allem
der aktuelle Status – Leben und Zeit – während des Spielverlaufs angezeigt.
Verliert Fred ein Leben wird die Textur der entsprechenden Anzeige aktualisiert. Bei der vorletzten Textur handelt es sich um eine animierte Textur.
Der Spieler wird darauf hingewiesen, dass er nur noch ein Leben hat. Das
Herz beginnt zu pochen. Neben der Anzeige der Leben wird die aktuelle
Zeit angezeigt. Dazu wurde eine Uhr animiert und ein Textfeld integriert,
welches die aktuelle Spielzeit in Minuten und Sekunden darstellt. Bei der
Erstellung der Overlays wurde darauf geachtet, dass sich die Größe sowie
Position in Relation zur Bildschirmauflösung verhält.
39
6
Benutzertests
In diesem Abschnitt wird das Spiel mit Hilfe von Benutzertests untersucht.
Die Basis zur Durchführung bildet die Definition einer Zielsetzung, um den
Test zielorientiert zu gestalten. Die Planung und Durchführung hilft dabei,
den Testablauf entsprechend zu gestalten und eine angemessene Auswahl
an Probanden und Bedingungen zu treffen.
6.1
Zielsetzung
Die Durchführung und Auswertung von Benutzertests soll dazu verhelfen Aufschluss zu erhalten, inwiefern das umgesetzte Spiel auf Basis eines
Tangible User Interfaces die Bedienung vereinfacht und das Spielerlebnis
steigert. Das besondere Augenmerk liegt darauf, wie das entwickelte TUI
für die virtuelle Spielwelt zur intuitiven Handhabung, Verständlichkeit,
Minderung der Einstiegsbarriere für unerfahrene Spieler und dem Spaß
am Spiel beiträgt.
Des Weiteren sollen anhand der resultierenden Ergebnisse Rückschlüsse
auf die Akzeptanz von Tangible User Interfaces im Bereich AR Gaming
geschlossen werden. Bieten TUIs tatsächlich das Potenzial gewöhnliche Interaktionskonzepte im Spielbereich zu verdrängen? Wird der Umgang mit
virtuellen Elementen im dreidimensionalen Raum wirklich einfacher und
intuitiver? Kann die Lücke zwischen realer und virtueller Welt geschlossen
werden?
6.2
Planung und Durchführung
Der Benutzertest besteht insgesamt aus zwei Bausteinen. Verschiedene
Steuerungsmöglichkeiten mittels TUI und Tastatur sollen Klarheit schaffen, wie die etwas andere Interaktionsform wahrgenommen wird. Welche
Variante ist intuitiver, wird besser verstanden und erhöht den Spielspaß?
Welche Technik minimiert die Einstiegsbarriere? Dementsprechend sollen
Probanden aus unterschiedlichen Altersgruppen mit unterschiedlichen Erfahrungen im Bereich Computerspiele beide Steuerungsvarianten ausprobieren. Ein Fragebogen soll daraufhin die Empfindungen der Probanden
erfassen.
Der Fragebogen mit insgesamt 10 Fragen lässt sich neben den Angaben zur
Person in drei Bereiche unterteilen. Die Personenangaben beinhalten Alter,
Geschlecht und eine Selbsteinschätzung der Computerspielerfahrung. Anhand unterschiedlicher Erfahrungen der Testpersonen soll ermittelt werden, in welchem Umfang sich Altwissen auf den Umgang mit dem TUI
und dem gesamten Spiel auswirkt. Die drei weiteren Abschnitte beschäftigen sich mit spezifischeren Fragestellungen. Hierzu wurden Hypothesen
formuliert, denen der Proband in unterschiedlichen Abstufungen vollkom40
men oder gar nicht zustimmen kann. Der erste Teil behandelt hauptsächlich die Frage, wie die Steuerung mit dem Interface im Gegensatz zum konventionellen Eingabegerät wahrgenommen wird. Wird zum Beispiel der
Spielspaß durch die Steuerung mit dem Spielbrett erhöht oder stellt der Bau
der eigenen Spielwelt ein Steigerung des Spaß- und Motivationsfaktors dar.
Der zweite Abschnitt umfasst lediglich drei Hypothesen und geht auf die
Verständlichkeit, den Spaß und die gesetzten Anforderung an den Spieler
in Bezug auf das gesamte Spielkonzept ein. Die letzten beiden Fragen sollen dabei helfen zu bewerten, wie sich das Konzept auf die Langzeitmotivation auswirkt und ob die Testpersonen sich Spiele mit ähnlichem Interaktionskonzept wünschen. Des Weiteren erhält der Proband die Möglichkeit,
Verbesserungsvorschläge und Anregungen zu geben. Der komplette Fragebogen befindet sich im Anhang B. Bei der Durchführung der Tests soll
der Proband zunächst neben den Intros keine weiteren Hilfestellung erhalten. Diese sollen erst gegeben werden wenn der Benutzer Schwierigkeiten
bekommt oder direkt nachfragt. Die Beobachtung der Testperson soll zusätzlich Aufschluss darüber gegeben ob das Spiel und TUI selbsterklärend
ist. Die Spielzeit ist variabel, jeder Proband soll die Möglichkeit erhalten
so lange zu spielen, wie er möchte. Die Testpersonen sollen keinesfalls gezwungen werden das Spiel eine gewisse Dauer zu spielen.
6.3
Auswertung
Die Durchführung der Benutzertests wurde an 26 Personen aus verschiedenen Tätigkeitsbereichen und Altersgruppen durchgeführt. Dabei wird
unter der Annahme vorgegangen, dass die meisten Testpersonen geringfügige bis gar keine Erfahrungen in Augmented Reality Umgebungen sowie
mit Tangible User Interfaces haben. Währenddessen wurde darauf geachtet
das Personen die mit dem Bereich näher in Kontakt stehen zum Beispiel CV
Studenten oder Absolventen im geringen Maße gesondert betrachtet werden. Anhand ihres Vorwissens könnten sie das Spiel gegebenfalls anders
wahrnehmen beziehungsweise beurteilen. Dennoch sollen diese Personen
mit in die Tests einbezogen werden, denn auch sie müssen sich mit der
Steuerung vertraut machen. Die beiden Tabellen (Abbildung 27 auf Seite
42) zeigen einen groben Überblick über die Auswahl der Probandengruppe. Im Folgenden werden nun die Ergebnisse aller Probanden aufgezeigt.
Die Auswertung hat gezeigt, dass lediglich geringe Variationen zwischen
den Altersgruppen und Erfahrungseinteilung besteht. Auf Auffälligkeiten
zwischen den einzelnen Gruppen wird gesondert eingegangen. Zur Darstellung der Auswertung werden Säulendiagramme, wie in Abbildung 28
auf Seite 43, verwendet. Auf der y-Achse wird die Anzahl der Testpersonen und auf der x-Achse die gestellten Hypothesen aufgezeichnet. Die
verschiedenen Farben in unterschiedlichen Farbtönen symbolisieren die
sechs Abstufungen, die dem Probanden zur Auswahl standen. Der Voll41
Abbildung 27: Benutzertests – Übersicht Probandengruppe.
farbton Grün beschreibt dabei das der Nutzer der Hypothese vollkommen
zu stimmt, Blau das er gar nicht zustimmt. Dadurch wird in jedem Fall
deutlich in welche Richtung der Nutzer eher tendiert.
Das Interface In Abbildung 28 auf Seite 43 wird die Auswertung des ersten Abschnitts, der sich überwiegend mit der grundlegenden Steuerung
beschäftigt, dargestellt.
Hypothesen
1. Die Steuerung mit dem Spielbrett erhöht den Spaß am Spiel.
2. Die Steuerung mit dem Spielbrett ist eingängig und
selbsterklärend.
3. Der Schwierigkeitsgrad wird durch die Steuerung mit dem
Spielbrett erhöht.
4. Der Bau mit der eigenen Spielwelt steigert zusätzlich den Spaßund Motivationsfaktor.
5. Ich würde die konventionelle Steuerung (Tastatur) bevorzugen.
Anhand der ersten Hypothese wird ganz klar deutlich, dass die Vielzahl
der Probanden die Steuerung mit dem Spielbrett beziehungsweise TUI als
einen zusätzlichen Spaßfaktor empfanden. Die Auswertung der zweiten
Hypothese bekräftigt, dass die Steuerung als intuitiv und leicht verständlich wahrgenommen wurde. Dies ist auch den Beobachtungen hervor getreten. Die Spieler hatten sich alle in relativ kurzer Zeit mit der Steuerung
vertraut gemacht. Zudem wurde die Steuerung mit dem Spielbrett nicht
42
Tabelle1
trifft gar nicht zu
trifft voll zu
10
6
16
5
2
1
4
3
1
4
1
4
4
7
2
9
20
18
13
30
25
Probanden
20
trifft voll zu
15
10
trifft gar nicht
zu
5
0
1
2
3
4
5
Hypothese
Abbildung 28: Benutzertests – Interface.
als eine Erhöhung des Schwierigkeitsgrad wahrgenommen. Eher im Gegenteil. Auch der Bau der eigenen Spielwelt ist im Großen und Ganzen als
zusätzlicher Spaß- und Motivationsfaktor bewertet worden. Der Wunsch
nach konventionellen Eingabe wurde lediglich von Ausnahmefällen geäußert. Auffällig dabei ist, dass diese Personen auch im Alltag mit Computerspielen in Kontakt stehen und dementsprechend bei der Selbsteinschätzung der Spielerfahrung hoch angegeben haben. Aber auch hier bevorzugen sechs von neun erfahrenen Spielern das TUI.
Das Spiel Der zweite Abschnitt des Fragebogens, der das Spiel allgemein
betrachtet, wird in Abbildung 29 dargestellt.
Hypothesen
1. Das Spiel hat mir Spaß gemacht.
2. Das Spielprinzip ist mir auf Anhieb klar geworden.
3. Das Spiel hat mich gefordert, aber nicht überfordert.
Es wird deutlich, dass die Mehrheit bis auf einen Ausnahmefall Spaß am
Spiel zeigte. Das Spielprinzip ist der Großzahl umgehend klar geworden.
Besonders in diesem Bereich trat die Altersgruppe 41-60 Jahren in den Vordergrund. Alle drei Probanden hat keineswegs Probleme oder Schwierigkeiten das wesentliche Spielprinzip zu verstehen. Auf Nachfrage bei den jeweiligen Testpersonen wurde deutlich, dass alle Erfahrungen mit dem altbekannten Holzkugellabyrinth haben. Worauf sich das Ergebnis vielleicht
Seite 1
43
Tabelle2
trifft gar nicht zu
trifft voll zu
1
1
1
1
2
4
7
9
12
18
14
8
30
25
Probanden
20
trifft voll zu
15
10
trifft gar nicht
zu
5
0
1
2
3
Hypothese
Abbildung 29: Benutzertests – Auswertung Spiel.
zurückführen lässt. Die Spieler konnten ihr Altwissen klar einsetzen. Des
Weiteren wurden die gestellten Herausforderungen im Spiel als überwiegend positiv empfunden.
Allgemein Die Auswertung des letzten Abschnitts des Fragebogens wird
in Abbildung 30 auf Seite 45 gezeigt.
Hypothesen
1. Ich kann mir vorstellen das Spiel mehrmals zu spielen.
2. Ich würde mir mehr Spiele wünschen, die ein ähnliches
Interaktionskonzept verfolgen.
Die Bewertung der ersten Hypothese durch die Probanden zeigt, dass das
Spiel ganz klar Potenzial hat, die Langzeitmotivation zu verstärken. Auch
Beobachtungen der Testpersonen haben gezeigt, dass viele Spieler gerne
eine zweite Runde spielten und sich dabei neue interessante teils aber auch
einfachere Spielwelt zusammen setzten. Manche Personen entwickelten
hierbei einen richtigen Ehrgeiz. Darüber hinaus wünschen die Probanden
sich größtenteils ähnliche Interaktionskonzepte in Spielen.
Verbesserungsvorschläge und Anregungen Die Verbesserungsvorschläge und Anregungen betrafen im Großen und Ganzen das Spiel selbst. Viele
Probanden äußerten den Wunsch nach weiteren Level, unterschiedlichen
Gegnern und einer Rangliste mit Screenshots der gebauten Spielwelt.
Oftmals kritisiert wurde, dass die Powerups nicht erklärt werden. Der
Seite 2
44
Tabelle3
trifft gar nicht zu
trifft voll zu
1
2
2
1
11
9
13
13
30
25
Probanden
20
trifft voll zu
15
10
trifft gar nicht
zu
5
0
1
2
Hypothese
Abbildung 30: Benutzertests – Auswertung Allgemein.
grundlegende Gedanke war es, den Spieler immer wieder mit etwas Neuem zu konfrontieren und so Spannung zu schaffen, Neugier zu wecken
und die Langzeitmotivation zu fördern. Auch die Beobachtungen haben
gezeigt, dass viele Spieler die Powerups zunächst nicht nutzten, da sie
nicht wussten was passiert.
Die Musik wurde teils als witzig aber auch nervig empfunden. Die
größte Unzufriedenheit wurde in Bezug auf den Button geäußert. Das
ist darauf zurückzuführen, dass in manchen Fällen der Button nur träge
funktionierte. Der Platz auf dem Fragebogen wurde aber auch genutzt,
um positives Feedback zu geben. Dabei fielen Stichpunkte wie: „intuitiv“,„tolles Konzept“,„gutes Design“und „Intro einfach und gut“. Die
gesamten Kommentare und Anmerkungen gegebenenfalls zusammengefasst befinden sich in einer Liste im Anhang B.
Insgesamt ist aufgefallen, dass die Probanden positiv und mit Neugier an das Spiel heran getreten sind. Während des Spiels wurde deutlich,
dass eine gewisse Konzentration und Geduld bestehen muss, um das Spiel
zu bewältigen. Dies ergaben vor allem Gespräche mit den Probanden nach
dem Ablauf des Tests.
45
Seite 3
7
Ergebnisse
In diesem Abschnitt werden kurz die Ergebnisse der Umsetzung präsentiert. Neben dem TUI und dem gesamten Spiel werden die entstanden 3D
Modelle dargestellt.
7.1
3D Modelle
Neben dem Modell für die Spielfigur sind weitere Geometrien für lustige virtuelle Spielkomponenten erstellt worden. Der Grundkörper des Protagonisten Freds (Abbildung 31) wurde durch zwei verschiedene Animationen erweitert. Zum einen die Laufbewegung mit der sich Fred in der
Abbildung 31: Ergebnisse – 3D Modell Fred.
Spielwelt bewegt. Zum anderen das Hüpfen in ein Wurmloch sowie das
Klettern heraus. Ebenso erhielt der Körper des Wurms zwei passende Animationen (Abbildung 32). Darüber hinaus sind weitere Modelle wie Sterne,
Kugeln und Wurmlöcher entstanden. Alle Modelle erhielten verschiedenfarbige Texturen, um eine bunte Welt entstehen zulassen.
Abbildung 32: Ergebnisse – 3D Modell Wurm.
7.2
Das TUI – Spielwelt
Das TUI besteht aus einem einfachen Holzkasten mit zwei Griffen und Bausteinen in drei verschiedenen Größen. Die einzelnen Komponenten wurde
46
weiß lackiert (matt) und mit einer selbstklebenden Velourfolie zur Realisierung des Trackings und Wanderkennung bestückt (Abbildung 33). Das
Material der Folie absorbiert einfallendes Licht und vermeidet Glanzlichter, die gegebenenfalls den Trackingvorgang wesentlich beeinflussen könnten. Der Bauplan mit sämtlichen Maßen befindet sich im Anhang C. Eines
der Ziele die klassische Bedienung zu verdrängen wurde zusätzlich durch
die blaue Folie, die die Knopffunktion übernimmt, realisiert. Zur Umsetzung des Konzepts wurde mit einer stationären Kamera und Monitor gearbeitet. Die Kamera ist an einer umgebauten Schreibtischlampe befestigt,
wodurch die Aufsicht auf die Spielwelt ermöglicht wird (Abbildung 33).
Das grundlegende Konzept sah es vor, dass der Spieler im Stehen das TUI
vor sich hält. Jedoch ist deutlich geworden, dass dies für die meisten Spieler
eine zu immense körperliche Belastung bedeutet, deshalb wurde das TUI
um ein Luftkissen erweitert. Der Spieler kann bequem das Spielbrett in die
richtige Richtung neigen. Des Weiteren bleibt der Benutzer aufgrund des-
Abbildung 33: Ergebnisse – TUI.
sen mit dem TUI beziehungsweise Marker eher innerhalb des Bildbereichs
und eine stärkere Neigung des Spielbretts bleibt aus. Würde das Brett mehr
als 90◦ gekippt werden würde das Tracking ausfallen. Insgesamt ist unter
anderem durch die Verwendung der Velourfolie und geringe Entfernung
von Kamera und Marker ein stabiles und robustes Tracking entstanden.
Lediglich das Tracking des Knopfes bietet Platz für Verbesserungen. Des
Weiteren ist die Verdeckung virtueller Komponenten durch reale Wände
und Kollision mit diesen durchaus präzise genug, um den Eindruck der
Vereinigung beider Welten zu stärken (siehe Screenshots Anhang D).
7.3
Das Spiel
Das Gesamtergebnis ist ein lustiges und buntes Spiel, welches das altbekannte Kugellabyribthprinzip mit Leben füllt (Abbildung 34 auf Seite 48).
47
Es ist eine Kombination aus Geschicklichkeits, Jump‘n‘Run und Geduldsspiel entstanden, das die Konzentration und Koordination fördert. Der Bau
der Spielwelt erhöht den Spaßfaktor und für bietet Potenzial die Langzeitmotivation zu fördern. Das TUI sorgt für die intuitive Handhabung und
lässt einen unerfahrenen Spieler schnell ins Spielgeschehen einsteigen. Die
Untersuchung des Spiels anhand von Benutzertests hat zudem verdeutlicht, dass das Spiel nicht bloß auf eine spezifische Zielgruppe beschränkt
ist, sondern eine breite Masse erreicht. Weitere Screenshots des Spiels befinden sich im Anhang D.
Abbildung 34: Ergebnisse – Spiel.
48
8
Ausblick
Im Folgenden werden kurz Ideen, Verbesserungsvorschläge und mögliche
Optimierungen, die das Spielkonzept sowie die technische Umsetzung betreffen, dargestellt.
8.1
Optimierungsansätze und Erweiterungen
Das Tracking sowie die Detektion der Wände des Spielfeldes haben sich
als robust dargestellt und benötigen dementsprechend keine Optimierung.
Die hier aufgezeigten Optimierungsansätze beziehen sich hauptsächlich
auf die Umsetzung des Knopfes sowie die Erweiterung durch die Detektion geschlossener Wände und die Erstellung einer Rangliste.
Eingabe Spielstatus – Knopfdruck
Die wichtigste Optimierung betrifft die Eingabe durch den Knopfdruck, da
das Tracking beziehungsweise Auslösen in manchen Fällen nicht den Erwartungen der Benutzer entsprach. Zudem wurde während der Testphase
deutlich, das einige Probanden den Knopf nicht als solchen empfunden haben. Entweder man verfeinert das Trackingkonzept und vermittelt durch
eine Aus- oder Einbuchtung eine bessere Haptik oder ersetzt die Eingabe
durch ein wie in den Grundlagen vorgestelltes markerbasiertes Verfahren.
Das Wackeln oder eine bestimmte Rotation der gesamten Spielwelt könnte
die Knopffunktion ersetzen und würde ein zusätzliches Highlight darstellen. Dennoch müsste hierbei darauf geachtet werden, dass die Geste eindeutig ist, um versehentliches Auslösen zu vermeiden.
Detektion geschlossener Wände
Des Weiteren wäre eine Erkennung geschlossener Wände sinnvoll. Baut
der Spieler beispielsweise eine Spielwelt, die in zwei Teilbereiche zerlegt
ist, geht das Spielkonzept gegebenenfalls nicht auf. Der Spieler hätte nicht
mehr die Möglichkeit alle Bereiche der Spielwelt zu erreichen und die dahinter verborgenen Kugeln einzusammeln. Bei Erkennung einer geschlossenen Region, könnte das Spiel zum Beispiel um entsprechend positionierte Portale erweitert werden.
Highscore
Um die Motivation weiter voran zu treiben, könnte das Spiel um eine
Rangliste erweitert werden. Die Liste müsste dabei ein Bild der gebauten
Spielwelt und die entsprechend gebrauchte Zeit beinhalten. Weitere Spieler
hätten somit die Gelegenheit die Spielwelt nachzubauen und einen neuen
Rekord aufzustellen.
49
8.2
Fortführung des Spielkonzepts
In der Evaluation ist der Wunsch nach mehr Leveln und anderen Spielkomponenten deutlich geworden. Als weiteres Powerup könnte Fred sich zum
Beispiel zu einer Kugel formen oder eine Sprungfeder erhalten. Weitere
Gegener oder Komponenten könnten zum Beispiel durch rollende Fässer,
hüpfende Heuschrecken oder Schiebewände realisiert werden.
8.3
Weitere Benutzertests
Die bisher erfolgten Benutzertests haben zwar gezeigt, dass durchaus Potenzial zur Langzeitmotivation besteht, aber dies beruht im Wesentlichen
auf den Einschätzungen der Probanden. Weitere Benutzertests könnten zusätzlich bestätigen, dass das Konzept zur Langzeitmotivation wirklich aufgeht. Vor allem betrifft dies den Bau der Spielwelt. Beim ersten Spielen
sind dem Benutzer die Auswirkungen des Baus nicht wirklich klar. Erst
beim zweiten Durchlauf kann der Benutzer eine zielorientierte Spielwelt
aufbauen. Die Motivation zum zweiten Spielen ist dadurch gegeben. Dies
wird auch durch die Auswertung der Benutzertests bekräftigt. Aber wie
sieht es beim vierten oder fünften mal aus? Eine Langzeitstudie würde hier
Aufschluss geben.
50
9
Fazit
Die Vermutung, dass Tangible User Interfaces das Potenzial des Bereichs
AR Gaming erweitern, kann durch die durchgeführten Benutzertests und
Beobachtung gefestigt werden. Es wird eine intuitive Interaktionsmöglichkeit geschaffen, die zusätzlich den Eindruck paralleler Welten stärkt. Virtualität geht allmählich über in Realität. Die Idee konventionelle Eingabemittel wie Tastatur oder Maus durch alltägliche Gegenstände zu ersetzen
geht vollkommen auf. Besonders unerfahrene Spieler erhalten die Möglichkeit leicht ins Spielgeschehen einzusteigen.
Die Mischung aus visueller Erweiterung und haptischer Erfassbarkeit steigert durch die Ansprache verschiedener Sinneskanäle das Spielerlebnis
maßgeblich. Hinzukommend weckt die etwas andere dennoch vertraute
Interaktionsform Neugier und Interesse.
51
Literatur
[ARTa]
ARToolKit.
http://www.hitl.washington.edu/
artoolkit/, Abruf: 20.04.2011
[ARTb]
ARToolKitPlus. http://studierstube.icg.tugraz.at/
handheld_ar/artoolkitplus.php, Abruf: 18.04.2011
[ARTc]
Projekt
ARTierchen.
http://artierchen.
knuddelgiraffe.de/, Abruf: 26.05.2011
[Azu95]
A ZUMA, R.: A survey of augmented reality. 1995
[Bat02]
B ATES, Bob: Game Design.
9783815504338
[BBR+ 95]
B REEN, David E. ; B REEN, David E. ; R OSE, Eric ; R OSE, Eric
; W HITAKER, Ross T.: Interactive Occlusion and Collision of Real
and Virtual Objects in Augmented Reality. 1995
[BK08]
B RADSKI, Gary ; K AEHLER, Adrian: Learning OpenCV: Computer Vision with the OpenCV Library. 1. O’Reilly Media, 2008. –
ISBN 9780596516130
[BKP08]
B ILLINGHURST, Mark ; K ATO, Hirokazu ; P OUPYREV, Ivan:
Tangible augmented reality. In: ACM SIGGRAPH ASIA 2008
courses. New York, NY, USA : ACM, 2008 (SIGGRAPH Asia
’08), 7:1–7:10
[BLC+ 10]
B LANCO, José M. ; L ANDRY, Pascal ; C., Sebastián M. ; M AZ Emanuela ; PARÉS, Narcís: PIPLEX: tangible experience
in an augmented reality video game. In: IDC, 2010, S. 274–277
Sybex Verlag, 2002. –
ISBN
ZONE,
[BR05]
B IMBER, Oliver ; R ASKAR, Ramesh: Spatial Augmented Reality:
Merging Real and Virtual Worlds. Natick, MA, USA : A. K. Peters,
Ltd., 2005. – ISBN 1568812302
[BWRT96] B REEN, David E. ; W HITAKER, Ross T. ; R OSE, Eric ; T UCERYAN , Mihran: Interactive Occlusion and Automatic Object Placement for Augmented Reality. In: Computer Graphics Forum 15
(1996), Nr. 3, S. 11–22
[Car]
CarreraCV.
http://www.mi.hs-rm.de/~schwan/
Projects/CG/CarreraCV/doku/, Abruf: 20.04.2011
[Hor04]
H ORNECKER, E.: Tangible User Interfaces als kooperationsunterstützendes Medium, University of Bremen. Dept. of Computing,
PhD-Thesis, Juli 2004
52
[IU97]
I SHII, Hiroshi ; U LLMER, Brygg: Tangible Bits: Towards Seamless
Interfaces between People, Bits and Atoms. 1997
[MDB03]
M ÜHLBACHER, Daniel ; D OBROVKA, Peter ; B RAUER, Jörg:
Computerspiele - Design und Programmierung. 2. Aufl. mitp, 2003.
– ISBN 9783826609206
[Mül10a]
M ÜLLER, Stefan: Vorlesungsfolien Animation und Simulation.
2010 http://www.uni-koblenz-landau.de/koblenz/
fb4/institute/icv/agmueller/lehre/archiv
[Mül10b]
M ÜLLER, Stefan: Vorlesungsfolien Virtuelle Realität und Augmented Reality. 2010 http://www.uni-koblenz-landau.
de/koblenz/fb4/institute/icv/agmueller/lehre/
ws0910/arvr/arvr
[Ogr]
Ogre Wiki – Support and community documentation. http://
www.ogre3d.org/tikiwiki/, Abruf: 30.04.2011
[SWM+ 06] S TROBEL, Armin ; W OLSING, Ansgar ; M OHR, Christina ; L OTZE, Rouven ; L ANG , Eike M. ; Z IEGLER , Jürgen: ARTierchen
– Augmented Reality in touch. In: Mensch & Computer 2006:
Mensch und Computer im StrukturWandel. München : Oldenbourg Verlag, 2006, S. 425–430
[Tam]
TAMANINI, Christian: Muntermacher. http://ctamanini.
de/projekte.html, Abruf: 03.05.2011
[Tön10]
T ÖNNIS, Marcus: Augmented Reality: Einblicke in die Erweiterte
Realität (Informatik Im Fokus). 1., st Edition. Springer, Berlin,
2010. – ISBN 9783642141782
[US03]
U LBRICHT, Christiane ; S CHMALSTIEG, Dieter: Tangible Augmented Reality for Computer Games. In: Proceedings of the
Third IASTED International Conference on Visualization, Imaging
and Image Processing ACTA Press, ACTA Press, 2003. – ISBN
0889863822, S. 950–954
[Wag07]
WAGNER, Daniel: Handheld Augmented Reality, Graz University of Technology, Institute for Computer Graphics and Vision,
Diss., 2007
[Zer02]
Z ERBST, Stefan: 3D Spieleprogrammierung mit DirectX in C/C++.
Band 2. Hardcover-Ausgabe. Books on Demand GmbH, 2002. –
ISBN 9783831138791
53
Anhang
A
Materialdateien
Materialskript zur Realisierung von Verdeckungen
Listing 1: Materialskript
1
2
3
4
5
6
7
8
9
material labyrinth{
receive_shadows on
technique{
pass{
lighting off
colour_write off
}
}
}
Materialskript Overlay
Listing 2: Materialskript
1
2
3
4
5
6
7
8
9
10
material Introduction/IntroGameWorld{
technique{
pass {
lighting off
scene_blend alpha_blend
texture_unit{
anim_texture Intro_FredsWorld.png
15 30
}
}
}
54
B
Benutzertest
Fragebogen
Angaben zur Person
Alter <20
Geschlecht
21-30
weiblich 31-40
41-60
männlich
>60
Selbsteinschätzung der Spielerfahrung in Computerspielen
gering
Das Interface
Stimme...
Die Steuerung mit dem Spielbrett erhöht den Spaß am Spiel.
mittel
gar nicht
zu
Die Steuerung mit dem Spielbrett ist eingängig und
selbsterklärend.
Der Schwierigkeitsgrad wird durch die Steuerung mit dem
Spielbrett erhöht.
Der Bau der eigenen Spielwelt steigert zusätzlich den Spaßund Motivationsfaktor.
Ich würde die konventionelle Steuerung (Maus, Tastatur)
bevorzugen.
Das Spiel
Das Spiel hat mir Spaß gemacht.
Das Spielprinzip ist mir auf Anhieb klar geworden.
Das Spiel hat mich gefordert, aber nicht überfordert.
Allgemein
Ich kann mir vorstellen das Spiel mehrmals zu spielen.
Ich würde mir mehr Spiele wünschen, die ein ähnliches
Interaktionskonzept verfolgen.
Verbesserungsvorschläge und Anregungen
Abbildung 35: Benutzertest – Fragebogen.
55
hoch
voll zu
Auswertung
Das Interface
trifft gar
nicht zu
10
6
16
5
trifft voll
zu
2
1
4
3
1
4
1
4
4
7
2
9
Das Spiel
trifft gar
nicht zu
20
18
13
trifft voll
zu
1
1
1
1
2
4
7
9
12
Allgemein
trifft gar
nicht zu
18
14
8
trifft voll
zu
1
2
2
1
11
9
13
13
Abbildung 36: Auswertung – Alle Probanden.
56
Das Interface
trifft gar
nicht zu
trifft voll
zu
1
2
2
1
1
3
1
1
1
2
4
3
3
Das Spiel
trifft gar
nicht zu
trifft voll
zu
1
2
1
Allgemein
trifft gar
nicht zu
5
4
2
trifft voll
zu
1
3
1
2
3
Abbildung 37: Auswertung – Probanden 10-20 Jahre.
57
Das Interface
trifft gar
nicht zu
trifft voll
zu
1
6
5
11
4
3
1
3
3
1
3
5
1
9
Das Spiel
trifft gar
nicht zu
14
13
7
trifft voll
zu
1
1
1
2
4
7
8
10
Allgemein
trifft gar
nicht zu
10
7
3
trifft voll
zu
2
1
1
7
8
9
8
Abbildung 38: Auswertung – Probanden 21-40 Jahre.
58
Das Interface
trifft gar
nicht zu
trifft voll
zu
1
1
2
2
2
1
3
2
1
Das Spiel
trifft gar
nicht zu
trifft voll
zu
3
3
3
Allgemein
trifft gar
nicht zu
trifft voll
zu
1
1
2
2
Abbildung 39: Auswertung – Probanden 41-60 Jahre.
59
Verbesserungsvorschläge und Anregungen
• bei Tastatursteuerung mehrere Tasten gleichzeitig
• sehr gute Umsetzung eines TAR Games
• Geschwindigkeit sollte nicht zu hoch sein
• Fred ist Klasse!
• Beschleunigung von Fred fühlt sich manchmal komisch an
• Tastatursteuerung: Evtl. unintuitive „Neutral“–Perspektive (Perspektive entspr. nicht dem Spielbrett)
• Auswirkungen des Selbstbauens waren am Anfang nicht ganz klar
(das beeinflusst aber maßgeblich den Schwierigkeitsgrad) – gut für
die Langzeitmotivation
• Rangliste (Screenshots), Highscore (Motivation steigern)
• Schwierigkeitsgrad erhöhen
• mehr Level, Spiel etwas schnell vorbei, unterschiedliche Gegner
• Design gut!
• Intro einfach und gut, Schöne Intros
• intuitiv
• verbesserte Detektion des Drückens des Buttons
• tolles Konzept
• kurze Erläuterung der Powerups in der Startsequenz
• größere Darstellung der Spieloberfläche für bessere Erkennbarkeit
der Objekte
• Sound sehr witzig, der Sound wird schnell nervig, Musik fehlt
• Könnte man auch Portale in die Außenwände bauen?
60
C
Tangible User Interface – Bauplan
Abbildung 40: Tangible User Interface – Bauplan.
61
D
Screenshots
Abbildung 41: Screenshots.
62
Abbildung 42: Screenshots – Ausschnitt Overlays.
63