Ein interaktives Tabletop-Spiel auf Basis von Arduino und Virtools

Transcription

Ein interaktives Tabletop-Spiel auf
Basis von Arduino und Virtools
Jakob F. Leitner
DIPLOMARBEIT
05/1/0305/016
eingereicht am
Fachhochschul-Masterstudiengang
Digitale Medien
in Hagenberg
im September 2007
c Copyright 2007 Jakob F. Leitner
Alle Rechte vorbehalten
ii
Erklärung
Hiermit erkläre ich an Eides statt, dass ich die vorliegende Arbeit selbstständig und ohne fremde Hilfe verfasst, andere als die angegebenen Quellen
und Hilfsmittel nicht benutzt und die aus anderen Quellen entnommenen
Stellen als solche gekennzeichnet habe.
Hagenberg, am 5. September 2007
Jakob F. Leitner
iii
Inhaltsverzeichnis
Erklärung
iii
Vorwort
vii
Kurzfassung
viii
Abstract
ix
1 Einleitung
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Interaktivität . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3 Gliederung . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2 Verwandte Arbeiten
2.1 Tabletop Plattformen . . . . . . . . . . .
2.1.1 DiamondTouch . . . . . . . . . . .
2.1.2 TARBoard . . . . . . . . . . . . .
2.1.3 TViews . . . . . . . . . . . . . . .
2.1.4 Entertaible . . . . . . . . . . . . .
2.1.5 STARS . . . . . . . . . . . . . . .
2.1.6 reacTIVision . . . . . . . . . . . .
2.2 Tabletop Applikationen . . . . . . . . . .
2.2.1 False Prophets . . . . . . . . . . .
2.2.2 TViews Table Role-Playing Game
2.2.3 KnightMage . . . . . . . . . . . . .
2.2.4 Hunting the Snark . . . . . . . . .
2.2.5 Read-It . . . . . . . . . . . . . . .
2.2.6 CarettaKids . . . . . . . . . . . . .
2.2.7 Weathergods . . . . . . . . . . . .
2.2.8 monkeyBridge . . . . . . . . . . .
2.2.9 playAnywhere . . . . . . . . . . . .
2.2.10 Augmented Coliseum . . . . . . .
iv
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
1
4
5
7
7
7
8
8
9
9
9
10
10
10
11
11
11
11
12
12
12
13
INHALTSVERZEICHNIS
v
3 Konzept
3.1 Idee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Vorbilder . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.1 The Incredible Machine . . . . . . . . . . . . . . .
3.2.2 Domino . . . . . . . . . . . . . . . . . . . . . . . .
3.3 Spieldesign . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4 Interaktionsdesign . . . . . . . . . . . . . . . . . . . . . .
3.4.1 Interaktion mit dem Spieler . . . . . . . . . . . . .
3.4.2 Die Interaktion mit physischen Spielkomponenten
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
14
14
14
15
18
18
20
20
22
4 Technologische Grundlagen
4.1 Software . . . . . . . . . .
4.1.1 Virtools . . . . . .
4.1.2 vvvv . . . . . . . .
4.2 Hardware . . . . . . . . .
4.2.1 Anoto . . . . . . .
4.2.2 Arduino . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
24
24
24
26
26
27
31
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
34
34
35
35
36
41
45
50
50
52
53
57
64
64
65
66
68
70
73
74
75
76
76
77
78
79
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5 Implementierung
5.1 Spielprinzip . . . . . . . . . . . . . . . . .
5.2 Hardware . . . . . . . . . . . . . . . . . .
5.2.1 Tisch . . . . . . . . . . . . . . . .
5.2.2 Anoto Menüs . . . . . . . . . . . .
5.2.3 Arduino-Sensorbox . . . . . . . . .
5.2.4 Comino-Portale . . . . . . . . . . .
5.3 Software . . . . . . . . . . . . . . . . . . .
5.3.1 Kommunikation mit Arduino . . .
5.3.2 Kommunikation in vvvv . . . . . .
5.3.3 Kommunikation in C++ . . . . . .
5.3.4 Kommunikation in Virtools . . . .
5.4 Umsetzung in Virtools . . . . . . . . . . .
5.4.1 Erste Schritte . . . . . . . . . . . .
5.4.2 Interaktionstechniken . . . . . . .
5.4.3 3D-Modelle . . . . . . . . . . . . .
5.4.4 Arduino-Integration . . . . . . . .
5.4.5 Anoto-Integration . . . . . . . . .
5.4.6 Level Organisation . . . . . . . . .
5.4.7 Integration der Hilfe . . . . . . . .
5.4.8 Unabhängige Virtools-Applikation
5.5 Leveldesign . . . . . . . . . . . . . . . . .
5.5.1 Level 1: . . . . . . . . . . . . . . .
5.5.2 Level 2: . . . . . . . . . . . . . . .
5.5.3 Level 3: . . . . . . . . . . . . . . .
5.6 Interaktionsdesign . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
INHALTSVERZEICHNIS
5.6.1
5.6.2
5.6.3
5.6.4
Aufstellen .
Löschen . .
Umstoßen .
Verschieben
vi
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
79
81
82
82
6 Diskussion
6.1 Eingabe . . . . . . . . . .
6.1.1 Stiftinteraktion . .
6.1.2 Anoto Menüs . . .
6.2 Spiel . . . . . . . . . . . .
6.2.1 Interaktionsdesign
6.2.2 Leveldesign . . . .
6.2.3 Spielziel . . . . . .
6.3 Ausgabe . . . . . . . . . .
6.3.1 Grafische Ausgabe
6.3.2 Kameraperspektive
6.3.3 Comino-Portale . .
6.3.4 Audio . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
84
84
84
86
86
86
87
87
88
88
88
88
90
7 Schlussfolgerungen
91
7.1 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . 91
7.2 Erreichte Ziele . . . . . . . . . . . . . . . . . . . . . . . . . . 91
7.3 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
A Inhalt der CD-ROM
A.1 Diplomarbeit . . . . .
A.2 Übersicht . . . . . . .
A.3 Comino-Applikation .
A.4 Comino-Tools . . . . .
A.5 Maya Dateien . . . . .
A.6 Virtools Dateien . . .
A.7 Visual Studio Dateien
A.8 vvvv Dateien . . . . .
A.9 Bilder und Grafiken .
A.10 Referenzmaterial . . .
Literaturverzeichnis
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
96
96
96
96
97
97
97
97
98
98
98
99
Vorwort
Diese Arbeit ist meinen Eltern gewidmet, die mich in all meinem bisherigen
Tun unterstützt haben und denen ich vieles im Leben verdanke. Ein Dank
auch an Geschwister und Freunde, die mich in meiner Arbeit und im Leben
begleiten und inspirieren und ein großes Danke an meine Freundin für ihre
Geduld und Zuneigung, die sie mir auch in arbeitsreichen Zeiten entgegenbringt. Zu guter Letzt auch ein herzliches Dankeschön an meinen Betreuer,
dem ich viele Erfolge in meinem Studium verdanke und dessen unerschöpfliche Motivation nicht nur für mich eine konstante Quelle neuer Inspirationen
und Interessen ist.
vii
Kurzfassung
Durch die Entwicklung von Tabletop-Systemen, die herkömmliche Tische zu
interaktive Arbeitsflächen umfunktionieren, ist auch für Computerspiele eine
neue Plattform entstanden. Die Möglichkeiten und Grenzen der Plattform
stellen eine Herausforderung an das Design von Spielen, die das Potential
der Systeme ausnützen wollen. Sowohl Spielkonzept als auch Spielinteraktion
sind an die Rahmenbedingungen eines neuen Mediums anzupassen, dessen
Möglichkeiten durch die raschen technologischen Entwicklungen im Bereich
von Tabletop-Systemen und physischen Interfaces noch nicht einmal ausgelotet sind.
Die Diplomschrift befasst sich mit relevanten Teilbereichen der Themengebiete Tabletop-Games, Physical-Computing und Interface-Design. Sie gibt
Einblick in den aktuellen Entwicklungstand der verschiedenen Themen und
fasst eigene Forschungsergebnisse am Beispiel des Tabletop-Spiels Comino
zusammen. In der Arbeit werden Grenzen für Tabletop-Spiele aufgezeigt
und es wird versucht, durch die Dokumentation des umgesetzten Spieles
die Grenzen etwas weiter zu stecken. Bestehende Spiele und Technologien
werden als Ausgangspunkt für die Schilderung eigener Entwicklungen herangezogen. Die Arbeit dokumentiert den gesamten Entstehungsprozess des
Tabletop-Spiels Comino, das das Spiel mit virtuellen und realen Spielelementen auf einer Tabletop-Plattform vereint. Dabei werden sowohl neuartige Interaktionstechniken für die simultane Benutzung durch mehrere Spieler als
auch Techniken für das Zusammenspiel von physischen und virtuellen Spielkomponenten beschrieben. Die Arbeit umfasst sowohl die konzeptionellen
Teilbereiche der Entwicklung der benötigten Schnittstellen als auch die Beschreibung der praktischen Umsetzung in Soft- und Hardware. Des weiteren
finden sich auch eine Diskussion der Ergebnisse basierend auf Spielerkommentaren und ein theoretischer Ausblick für zukünftige Entwicklungen in
der Arbeit.
viii
Abstract
Surface Computing has turned normal tables into interactive workspaces.
Embedded display technology allows users to show multimedia content on
various surfaces. These advancements in technology have also created a new
platform for computer-games. Developers of such games face new challenges
and have to consider the affordances of tabletops in order to take full advantage of the platform. Both game-concept and game-interaction have to be
adapted to fit the users’requirements . The possibilities are growing rapidly
as technology becomes more available and the limits of tabletop-systems
haven’t been reached yet.
The focus of this thesis is the overlapping area of three research topics:
tabletop-games, physical computing and interface design. It gives a brief introduction to the different topics and summarizes the work on the tabletopgame comino. This thesis presents recent research in the field of tabletopapplications and tabletop-platforms, followed by the description and discussion of the implemented tabletop-game Comino. Comino is a tabletop game
which combines both virtual and real game elements in a new way. Both
custom hardware and software components were implemented for this game
to enable new ways of multi-user interaction and interaction between the
virtual and the physical world. In this thesis the development process of
the game is presented, including game concept, interface-design, level design
and discussion of user feedback on the game. Finally, we conclude with an
overview over possible future development of similar tabletop games.
ix
Kapitel 1
Einleitung
1.1
Motivation
Games are played for no other reason than for the experience of
playing them - unlike a software application, in which the experience or enjoyment of the user is a by-product. If the experience
of the interface is not pleasing, players will walk away.
Peter Hall, The Principals of Play [13]
Entwicklungen auf dem Spielkonsolenmarkt zeigen, dass neuartige Eingabemedien als Kaufanreiz mindestens gleichbedeutend mit grafischen Neuerungen sind. Nintendos1 letzter Beitrag zum Konsolenmarkt, die NintendoWii2 , hat sich mit ihren anders gestalteten Kontrollern trotz der geringeren Rechenleistung und Grafikauflösung gegenüber den Konkurrenten auf
dem Markt behaupten können [35]. Die neuartigen Wii-Kontroller erlauben
es, auf originelle Art und Weise mit Spielen zu interagieren und nehmen
Abstand vom einfachen Drücken von Knöpfen. Abbildung 1.1 zeigt bereits
erhältliche und angekündigte Eingabegeräte der Nintendo-Konsole.
Eine Tatsache, die bei Nintendos Wii-Kontroller jedoch oft übersehen
wird, ist die, dass er auch als Ausgabegerät dient. Neben der bereits in vielen Gamepads und Joysticks üblichen Rumble-Funktion3 ist im Kontroller
auch ein kleiner Lautsprecher integriert. So können zusätzliche Geräusche
wiedergeben werden, die direkt beim Spieler passieren, wie das Surren einer Bogensehne oder das Geräusch beim Ausblasen einer Kerze. Dies erhöht
die atmosphärische Dichte des Spiels. Solche Neuerungen auf dem Markt
der Ausgabegeräte versuchen das Erleben von Videospielen mit zusätzlichen
Sinneseindrücken zu bereichern. Ein innovatives Beispiel ist das von Philips4
1
http://www.nintendo.com/home
http://wii.nintendo.com/
3
Vibrieren des Kontrollers, dass von der Applikation aus gesteuert werden kann.
4
http://www.philips.com/global/index.page
2
1
KAPITEL 1. EINLEITUNG
(a)
2
(b)
(c)
Abbildung 1.1: Durch neuartige Interfaces wie dem Wii-Kontroller plus
Nunchuck (a), und dem angekündigten Wii-Zapper (b) und Wii-BalanceBoard (vorläufiger Produktname) (c) unterscheidet sich die Konsole von seic Nintendo)
nen Mitstreitern auf dem Markt. (Abb.: Abbildung 1.2: Mit den zusätzlichen Ausgabegeräten wie Beleuchtungskörpern, Ventilatoren und einem Rumble-Pad für die Tastatur versucht das
c KoninkamBX-System das Spiel- und Filmerlebnis zu bereichern. (Abb.: lijke Philips N.V.)
vorgestellte amBX5 -System. Zusätzlich zu den klassischen Ausgabegeräten
wie Bildschirm und Lautsprechern können über das System etwa Ventilatoren und Hintergrundbeleuchtung gesteuert werden, mit denen Fahrtwind
und Umgebungslicht simuliert werden können [32].
This cutting edge set of peripherals allows gamers to experience
PC games with all their senses. Light, surround sound, air movement and vibration synch with the game and bring it literally
into the room.
Abbildung 1.2 zeigt alle Komponenten des amBX PC gaming peripherals
Premium kits 6 .
Doch nicht nur die Eingabegeräte und Ausgabegeräte für Spiele ändern
sich, auch die Spiele selbst sind durch Veränderungen der zur Verfügung
5
http://www.ambx.com/
http://www.consumer.philips.com/consumer/catalog/product.jsp?language=
en&country=US&catalogType=CONSUMER&productId=SGC5103BD 17 US CONSUMER
6
(a)
3
(b)
Abbildung 1.3: Sowohl Philips Entertaible (a) als auch Microsofts Surface (b) erlauben die gleichzeitige Interaktion von mehrere Benutzern. Auch
reale Gegenstände werden erkannt und können als Eingabegerät verwendet
c Koninklijke Philips N.V., Abb. (b): c Microsoft Corwerden. (Abb. (a): poration)
stehenden Technologien gravierenden Änderungen unterworfen. Neue, aufkommende Plattformen wie der Entertaible [21] von Philips oder das erst
kürzlich vorgestellte Surface7 von Microsoft8 fordern die Kreativität der
Spieleentwickler und bieten gleichzeitig interessante neue Möglichkeiten für
zukünftige Spielkonzepte.
Spieler solcher Tabletop-Spiele genießen beim Spielen die Vorteile von
zwei Welten. Die Verbindung von realen und virtuellen Spielkomponenten
ermöglicht einen einzigartigen Mix aus intuitiver Spielsteuerung und interaktivem Gameplay. Dabei bleibt der soziale Aspekt des gemeinsamen Spiels
von Brettspielen erhalten und fördert so die Kommunikation der Spieler.
Abbildung 1.3 zeigt ein typisches Anwenungsszenario des Entertaibles und
von Surface.
Die angeführten Beispiele aus den Bereichen Eingabegeräte, Ausgabegeräte und Spiele(-Plattformen) dienten als Motivation für die Umsetzung
eines eigenen Spieles, das sich mit den besagten Themenbereichen beschäftigt. Auf Basis eines zum Teil bereits bestehenden Tabletop-Setups sollte
ein interaktives Spiel umgesetzt werden, dessen physische Ein- und Ausgabegeräte eine neue und intuitive Art der Interaktion zwischen Spieler und
Spiel ermöglichen würden. Zusätzlich sollen reale und virtuelle Spielelemente
einander im Spiel beeinflussen können und so einen nahtlosen Übergang zwischen realer und virtueller Spielwelt erlauben.
7
8
http://www.microsoft.com/surface/
http://www.microsoft.com/en/us/default.aspx
4
Verarbeitung
(Spieler)
Eingabe
Ausgabe
real
virtuell
Ausgabe
Eingabe
Verarbeitung
(Spiel)
Abbildung 1.4: Eine grobe Unterteilung der Interaktion zwischen der virtuellen Spielkomponente und der realen Spielkomponente eines Spieles.
1.2
Interaktivität
Da es sich bei dem Begriff Interaktivität“ um einen sehr vielseitig verwen”
deten handelt, wird hier zuerst eine für diese Arbeit gültige Definition des
Begriffes aus [33, S. xx] übernommen.
“Interactive” is a fuzzy term, and often misused for all kinds of
ridiculous purposes. Author and game programmer Chris Crawford has a great definition for it: interaction is “an iterative process of listening, thinking, and speaking between two or more
actors.” Most physical computing projects (and most computer
applications in general) can be broken down into these same
three stages: listening, thinking, and speaking–or, in computer
terms: input, processing, and output.
Bei Interaktion handelt es sich also, etwas vereinfacht gesagt, um einen
iterativen Prozess des Horchens, Denkens und Sprechens zwischen Akteuren.
Auf die Terminologie des Computers übersetzt, der Eingabe, Verarbeitung
und Ausgabe (zwischen Akteuren). Im Fall des implementierten Spiels finden
sich diese drei Phasen in vielen Bereichen der Umsetzung. Dies trifft sowohl
für Teile zu, die in Software implementiert wurden, als für Spielelemente,
die in Hardware umgesetzt wurden.
Diese drei Phasen können auch für eine Unterteilung des gesamten Spieles verwendet werden. Für das vorgeschlagene Spiel werden die drei Phasen
in weiterer Folge Eingabe, Spiel (Spielelogik ) und Ausgabe genannt. Abbildung 1.4 zeigt stark vereinfacht die Interaktion zwischen der virtuellen Spielkomponente des vorgeschlagene Spieles und der realen Spielkomponente des
Spiels.
Die Interaktion des Spielers mit einem System ist Gegenstand vieler Publikationen [30, 38, 43] und Forschungsarbeit wie zum Beispiel der der NUI
Ei Wa
ng hr
ab ne
ea hm
uf u
fo ng
rd d
er er
un
g
5
Ausbleibende Eingabe
des Spielers
real
Pr
o
u
er
rd
ng
Hochfahren des
Programmes
gr
a
m
ffo
au
be
m
st
ar
t
a
ng
Ei
virtuell
Abbildung 1.5: Der Spieler fungiert als Bindeglied zwischen Ausgabe und
Eingabe in der realen Welt. Ohne sein Zutun kann der Kreislauf nicht geschlossen werden.
Group 9 , doch ist es bei Computerspielen üblich, dass der Spieler das einzige
Bindeglied zwischen Ausgabe und Eingabe in der realen Welt ist. Er reagiert
auf eine Ausgabe des Computers und setzt so den nächsten Impuls für das
Spiel. Ohne das Zutun eines Spielers kann dieser Kreislauf in der realen Welt
nicht geschlossen werden. Abbildung 1.5 illustriert dies an einem Beispiel.
Für das geplante Spiel sollte jedoch auch die direkte Interaktion von virtuellen und realen Spielelementen integriert werden. An bestimmten Stellen
im Projekt soll mithilfe spezieller Spielelemente der gezeigte Kreislauf auch
auf alternative, spielerischer Weise geschlossen werden können. Ein virtuelles Ereignis soll ein reales Ereignis anstoßen können, das ein virtuelles
Ereignis anstößt usw. Der Spieler, als Bindeglied in der realen Welt, kann
und soll dabei natürlich nicht durch die Spielelemente ersetzt werden. Der
Aufbau der einzelnen Bestandteile dieser Kettenreaktion, die die Grenze der
virtuellen und realen Welt überwinden kann, soll den Reiz für den Spieler
ausmachen, auch wenn nach dem Start die Kettenreaktion dann ohne sein
Zutun abläuft. Der Spieler löst ein Puzzle, das über die üblichen Grenzen
eines Computerpieles hinaus geht. Die Interaktion zwischen System und Benutzer kann dabei natürlich nicht außer Acht gelassen werden und muss
deshalb ebenso in die Arbeit mit einfließen.
1.3
Gliederung
Die Arbeit dokumentiert die Entstehung des umgesetzten Tabletop-Spieles
Comino von der Entwurf-Phase über die Implementierung bis hin zur Diskussion der Ergebnisse. Zusätzlich werden relevante Referenz-Projekte und
für die Umsetzung relevante Technologien angeführt und erklärt.
Kapitel 2 gibt einen Überblick über verwandte Arbeiten. Dabei werden
9
http://nuigroup.com/
6
sowohl aktuelle Tabletop-Technologien und als auch umgesetzte Spiele und
Applikationen aufgelistet und kurz beschrieben. Dieses Kapitel soll dem Leser eine Überblick über das Umfeld dieser Arbeit geben. In Kapitel 3 wird
auf das Gesamt-Konzept hinter Comino eingegangen. Das Kapitel präsentiert dabei sowohl die Spielidee als auch verschiedene Vorbilder für das umgesetzte Spiel. In weiterer Folge werden konzeptionelle Entscheidungen in
Bezug auf Spiel- und Interaktionsdesign angeführt und mögliche Technologien für deren Umsetzung aufgelistet. Die technologischen Grundlagen für
die verwendete Soft- und Hardware werden im Anschluss in Kapitel 4 angeführt. Dieser Teil der Arbeit ist der technischen Beschreibung der relevanten
Technologien gewidmet und soll es dem Leser ermöglichen, allgemeine Informationen unabhängig von der konkreten Implementierung einzuholen. Zusätzlich findet sich weiterführende Literatur zu den einzelnen Technologien
in diesem Kapitel.
Die konkrete Implementierung von Comino ist in Kapitel 5 beschrieben.
Nach einer kurzen Einführung, die das Spielprinzip zusammenfasst, wird auf
die Implementierung der benötigten Hardware- und Software-Komponenten
eingegangen. Die beiden Abschnitte inkludieren eine Beschreibung des gesamten Setups, aller physischen Spielkomponenten sowie der Kommunikation der Schnittstellen mit dem Steuerrechner. Im darauffolgenden Abschnitt
wird die Umsetzung des Spieles, in mehrere Unterabschnitte aufgegliedert,
wiedergegeben. Das Kapitel beinhaltet des weiteren eine Abschnitt zum Leveldesign des Spieles und schließt mit der Umsetzung des Interaktionsdesigns
des Spieles.
Im darauffolgenden Kapitel 6 werden die Ergebnisse der Umsetzung
anhand von Kommentaren von Testspielern diskutiert. Angeführte Kritikpunkte werden aufgegriffen und Lösungsvorschläge formuliert. Im abschließenden Kapitel 7 werden die Ergebnisse der Arbeit zusammengefasst und
die erreichte Ziele aufgelistet. Dieses Kapitel endet mit einem Ausblick auf
mögliche Erweiterungen des Spieles.
Im Anhang der Arbeit findet sich eine Auflistung der Inhalte der zu dieser
Arbeit beigelegten CD-ROM, die verwendete Online-Quellen, referenziertes
Bildmaterial und implementierte Software beinhaltet.
Kapitel 2
Verwandte Arbeiten
Der praktische Teil dieser Arbeit befasst sich mit der Umsetzung eines
Tabletop-Spieles und der damit verbundenen Entwicklung von speziellen
Benutzerschnittstellen, um mit dem System zu interagieren. Im folgenden
Kapitel sollen Referenz-Plattformen und Projekte aufgelistet werden, die
diese Arbeit inspiriert haben und es soll so für den Leser ein Überblick über
den weitreichenden Themenbereich der Tabletop-Applikationen ermöglicht
werden.
Die angeführten Projekte sind in zwei große Gruppen unterteilt: in Tabletop Plattformen und Tabletop Applikationen. Für zusätzliche Informationen zur Geschichte von Tabletop-Spielen wird an dieser Stelle auf die
Masterarbeit von Huong Thu Nguyen [31, Kap. 2] und die Doktorarbeit von
Alexandra Mazalek [25, Kap. 2, 3] verwiesen.
2.1
Tabletop Plattformen
Im folgenden Abschnitt werden verschiedene Plattformen vorgestellt, die für
die Entwicklung von Tabletop-Spielen eingesetzt werden. Ein Vergleich von
einigen Eigenschaften verschiedener Plattformen findet sich in [10].
2.1.1
DiamondTouch [9]
Die DiamondTouch Plattform wurde von MERL1 entwickelt. Die Plattform
ist in zwei verschiedenen Ausführungen kommerziell erhältlich und erlaubt
die gleichzeitige Positionserkennung (Tracking) von bis zu 4 Personen auf
einer maximalen Fläche von 86 × 65 cm bei der Verwendung der größeren
der beiden Ausführungen. Die Positionserkennung, die auch die Unterscheidung von mehreren Benutzern erlaubt, funktioniert über elektrische Felder.
Die Benutzer sitzen auf speziellen Matten, die bei Kontakt mit der Oberfläche eine elektrische Verbindung mit den im Rahmen des DiamondTouch1
http://www.merl.com/
7
KAPITEL 2. VERWANDTE ARBEITEN
8
Gerätes verbauten Sendern herstellen. Verschiedene Empfänger für jeden
der Benutzer werten die Ergebnisse aus und ordnen sie dem jeweiligen Benutzer zu. Die interpolierte Auflösung der Positionserkennung beträgt 2736
× 2048 Punkte, die mit einer Frequenz von 30 Hz ausgelesen werden können. Die DiamondTouch Technologie erlaubt keine Erkennung von Objekten.
Durch die spezielle Hardware, die im Gerät verbaut ist, ist die Oberfläche
des DiamondTouch nicht transparent und kann deshalb nur in Kombination
mit einer Aufprojektion verwendet werden. Die DiamondTouch Plattform
wurde für den Einsatz in Büros konzipiert, doch wurde die Plattform auch
für eine Reihe von Spielen als Eingabegerät verwendet. Die Plattform ist vor
allem durch die Tatsache interessant, dass sie kommerziell erhältlich ist und
so von einer größeren Zahl von Forschungseinrichtungen und Universitäten
verwendet wird.
2.1.2
TARBoard [19]
TARBoard ist ein Tabletop-System, in dem physische Spielelemente erkannt,
abgefilmt und mit digitalen Inhalten erweitert dargestellt werden können.
TARBoard verwendet dabei ein markerbasiertes optisches Tracking-System.
Im Unterschied zu Projekten wie dem MagicBook [7], in dem die verwendeten Marker leicht durch den Benutzer verdeckt werden können, kommen in
TARBoard zwei Kameras für die Markererkennung zum Einsatz. Das Setup
besteht aus einem Tisch mit Glasplatte, der sowohl von oben als auch von
unten gefilmt wird. Die untere Kamera dient der Erkennung und der Marker, die auf der Unterseite der physischen Spielelemente angebracht werden
müssen, und so von den Spielern nicht verdeckt werden können. Die obere
Kammer nimmt die reale Szene auf, in der die physischen Spielelemente dann
mit digitalen Inhalten überlagert werden. Die Ausgabe des überlagerten Bildes erfolgt üblicherweise auf einem Bildschirm. Die TARBoard Technologie
erlaubt nur die Erkennung von Objekten mit Markern, Finger und nicht
präparierte Alltagsgegenstände werden nicht erkannt.
2.1.3
TViews [27], [25, Kap. 5]
Das TViews System wurde von Grund auf als Plattform für mehrere Applikationen konzipiert und ist für den Einsatz mit einer Reihe von Applikationen, darunter auch Spiele entwickelt. Als Einsatzorte von TViews werden
Wohnzimmer, Schulen oder Gemeinschaftsräume am Arbeitsplatz genannt.
Speziell entwickelte, physische Objekte werden vom System durch eine Kombination von akkustischen- und Infrarot-Sensoren erkannt und können so als
Eingabegerät verwendet werden. Für spezielle Eingaben steht auf den Objekten eine zusätzliche Taste zu Verfügung. Das Setup besteht aus einem
tischähnlichen Aufbau, in dessen Oberfläche ein Flachbildschirm versenkt
ist, der durch eine Glasplatte geschützt wird. Auch der Rest der benötigten
9
Hardware findet innerhalb des Tisches Platz und so präsentiert sich TViews
dem Benutzer als ein in sich geschlossenes und flexibles System. Für die Entwicklung von Applikationen für das System wurde auf Java basierendes Application Programming Interface(API) entwickelt. Das System erlaubt keine
direkte Interaktion durch Alltagsgegenstände und Finger.
2.1.4
Entertaible [21]
Wie auch das TViews System verwendet auch der Philips Entertaible einen
im Gerät versenkten Flachbildschirm für die Darstellung digitaler Inhalte.
Das optische Trackingsystem erlaubt die gleichzeitige Erkennung von bis
zu 40 Interaktionspunkten. Die Technologie verwendet Infrarot-LEDs und
Photodioden, die um den Bildschirm herum im Gerät verbaut sind und ist
aufgrund der Arbeitsweise im Infrarotbereich unabhängig von der Lichtsituation in der Umgebung. Das Tracking-System erlaubt sowohl die Erkennung
von Fingern als auch von Objekten. Für den Entertaible wurden auch spezielle Spielsteine entwickelt, deren optisches Aussehen verändert werden kann.
Diese Spielsteine sind aus transparentem Material gefertigt und transportieren von der Entertaible-Oberfläche ausgesendetes Licht durch das Prinzip
der totalen inneren Reflexion bis zur Deckfläche des Spielsteins. Durch Veränderung des ausgesendeten Lichts verändert sich auch das Aussehen des
Spielsteines. Das Entertaible-System wurde als Spieleplattform konzipiert
und für die Verwendung in Gemeinschafträumen oder Bars entwickelt.
2.1.5
STARS [23]
Die STARS-Plattform kombiniert mehrere Hardware-Komponenten, die im
R
Rahmen des roomwareProjekts
[41] des Frauenhofer Instituts entwickelt
wurden, zu einer Plattform für das Spielen von computergestützten Brettspielen. Bestehend aus mehreren Bildschirmen, die zum Teil für alle Spieler sichtbar sind und zum Teil private Informationen darstellen, ermöglicht
die STARS Plattform komplexe Spielszenarien, die gleichzeitig kompetitiven
und kollaborativen Charakter haben können. Der Spieltisch kombiniert einen
drucksensiblen Plasmabildschirm für die direkte Interaktion mit einer über
dem Tisch montierten Kamera, die verschiedene Spielobjekte auf dem Tisch
erkennen kann. Zusätzlich ist der Tisch mit einem RFID-Leser ausgestattet, der RFID-Tags auf dem Tisch erkennen kann. Sie können zum Beispiel
zum Speichern und Laden von Spielen verwendet werden. Die STARS Plattform integriert auch Lautsprecher für die Wiedergabe von Geräuschen sowie
Kopfhörer für Nachrichten, die nur an einen der Spieler adressiert sind.
2.1.6
reacTIVision [15]
Das Open-Source Framework reacTIVision wurde für die Entwicklung von
Tabletop-Interfaces entwickelt und kann von der offiziellen Projekt-Web-
10
seite2 heruntergeladen werden. reacTIVision besteht aus mehreren SoftwareKomponenten, die für die Erkennung von eigens entwickelten Markern verwendet werden können. Zusätzlich integriert das System Funktionalität für
die Positionserkennung von Fingern. Das Framework ist plattformunabhängig und Beispiel-Implementierungen können für verschiedene Programme
und Programmiersprachen wie C++, Java, Processing oder Flash heruntergeladen werden. Im Gegensatz zu den bisherigen Projekten sieht reacTIVision keine Verwendung von spezifischen Hardwarekomponenten vor. In [15]
finden sich neben einer allgemeinen Einführung in die Software auch detaillierte Anweisungen für den Bau von eigenen Hardware-Setups. reacTIVision
wird zur Zeit aktiv weiterentwickelt und wurde bereits erfolgreich für verschiedene Projekte wie zum Beispiel für reacTable [14] verwendet.
2.2
Tabletop Applikationen
Im folgenden Abschnitt wird eine Übersicht über verschiedene TabletopApplikationen gegeben.
2.2.1
False Prophets [24]
False Prophets wird auf einem Setup bestehend aus gemeinsam genutztem
Spieltisch und mehreren mobilen Endgeräten für die Darstellung von privaten Informationen gespielt. Zwei Teams spielen mit realen Spielfiguren auf
einem veränderbaren, virtuellen Spielplan, den es im Laufe des Spiels zu entdecken gilt. Die Spielfiguren werden durch ein eigens entwickeltes TrackingSystem getrackt.
2.2.2
TViews Table Role-Playing Game [26]
Wie der Name schon vermuten lässt, basiert das TViews Table Role-Playing
Game (TTRPG) auf der in Abschnitt 2.1.3 vorgestellten TViews Plattform.
TTRPG basiert auf dem klassischen Kartenspiel Dungeons and Dragons
und erlaubt drei Spielern die gleichzeitige Teilnahme am Spiel. Ein vierter
Spieler übernimmt die Rolle des Spielleiters und kann über einen externen
Bildschirm verschiedene Aktionen im Spiel steuern. Auch in TTRPG ziehen
die Spieler mit realen Spielfiguren über eine virtuelle Spielfläche und das
Spiel ist ebenfalls rundenbasiert. In TTRPG kann auch die Rotation der
Spielfiguren bestimmt werden, was für die Auswahl verschiedener Optionen
für die jeweilige Spielfigur direkt auf der Spielfläche verwendet wird.
2
http://mtg.upf.edu/reactable/?software
2.2.3
11
KnightMage [22]
KnightMage basiert auf der STARS Plattform (Vergleiche Abschnitt 2.1.5)
und ist ein kollaboratives Spiel für mehrere Spieler und einen Spielleiter,
das auf dem Tisch von STARS gespielt wird. Zusammen müssen die Spieler
in der unwirtlichen Spiellandschaft überleben, können dabei jedoch auch
auf eigene Faust agieren und Schätze ansammeln. Das Inventar eines jeden
Spielers kann über ein mobiles Endgerät eingesehen werden, das private
Informationen darstellt. Allgemeine Funktionen zu den Spielern können über
ein Wand-Display für alle sichtbar dargestellt werden. Noch nicht besuchte
Regionen der virtuellen Spielfläche werden vor den Spielern verborgen und
müssen erst entdeckt werden.
2.2.4
Hunting the Snark [36]
Hunting the Snark ist ein Lernspiel für Kinder, das verschiedenste Technologien wie RFID und Ultraschall-Tracking in mehreren Levels des Spieles
integriert. Ziel des Spieles ist es, möglichst viel über den Snark, ein fiktives,
virtuelles Lebewesen herauszufinden. Die Spieler, üblicherweise Kinder im
Alter zwischen 7 und 10 Jahren verwenden verschiedenste mobile Endgeräte, um Essensgewohnheiten des Snarks herauszufinden, ihn zu füttern und
ihn auf seiner weiteren Reise zu begleiten. Hunting the Snark wird dabei nur
zum Teil auf einem interaktiven Tisch gespielt sondern nutzt einen größeren
Raum als Spielfläche.
2.2.5
Read-It [39]
Read-It ist ebenfalls als Lernspiel für Kinder konzipiert und soll die Spieler beim Lesenlernen unterstützen. Das Projekt verwendet markerbasierte
Erkennung von Objekten, die jedoch im Infrarot-Bereich funktioniert und
so für das menschliche Auge unsichtbare Marker zulässt. Die Spielidee von
Read-It basiert auf dem klassischen Spiel Memory und belohnt das Auffinden von zusammenpassenden Spielkarten durch die Wiedergabe von Audiound Video-Clips. Die virtuellen Spielkarten können dabei mithilfe von realen
Objekten umgedreht werden. Read-It ist als kollaboratives Spiel konzipiert.
2.2.6
CarettaKids [42]
CarrettaKids ist ein Spiel, bei dem sich Kinder spielerisch in der Stadtplanung üben können. Das Setup von CarretaKids besteht aus einer speziell
für das Spiel gebauten Sensoroberfläche, auf die von oben projiziert wird.
Die Sensorfläche besteht aus einem Raster aus 20 x 24 Feldern, unter denen
RFID-Lesegeräte platziert sind. Die Spieler können die Spielsteine, die Gebäude darstellen und mit RFID-Tags ausgestattet sind, auf jedes freies Feld
12
der Spielfläche stellen und sie so in die Stadtsimulation integrieren. Zusätzlich steht jedem Spieler ein mobiles Endgerät zur Verfügung, auf dem eine
virtuelle Repräsentation des Spielplans dargestellt wird. Die Spieler können
hier Pläne für die Weiterentwicklung der Stadt erstellen und sie dann auf
die gemeinsame Spielfläche laden.
2.2.7
Weathergods [3]
Weathergods wurde für die Entertaible-Plattform entwickelt und kann von
vier Spielern rundenbasiert gespielt werden. Jedem der Spieler stehen drei
Spielfiguren zur Verfügung, die verschiedene Aufgaben im Spiel übernehmen. Ziel des Spieles ist es, ausreichend Gold zum Ankauf von Opfergaben
für die Wettergötter zu schaffen. Hierfür kann entweder Kamelmilch verkauft
werden (Spielfigur Kamelreiter), Gold gestohlen werden (Bandit) oder Bodenschätze gehoben werden (Detektor). Die Spielfläche zeigt die möglichen
Spielzüge der Spieler und reagiert auf Spielereignisse durch veränderbare
Texturen der virtuellen Spielfläche.
2.2.8
monkeyBridge [5]
Als technische Grundlage für monkeyBridge wurde das Studierstube Augmented Reality Project [37] verwendet. In monkeyBridge müssen Brücken
für autonom agierende Spielcharaktere gebaut werden. Auf dem Spielfeld,
einem virtuellen Ozean, müssen virtuelle und reale Brückenelemente so platziert werden, dass der Spielcharakter von einen vorgegebenen Startpunkt bis
zum Endpunkt des jeweiligen Levels gelangen kann. Dabei stellen spezielle
reale Gegenstände Hindernisse in der virtuellen Spielewelt dar. Mithilfe eines markerbasierten Eingabesystems muss der Spieler seinen autonom agierenden Charakter sicher um die Hindernisse herumführen und bis ins Ziel
bringen.
2.2.9
playAnywhere [45]
Im Rahmen des playAnywhere Projektes wurde ein Tabletop-Frontprojektions-System entwickelt, das aufgrund der speziellen Hardware auf die Montage von Projektor und Kamera über der Interaktionsfläche verzichten kann.
Das Hardware-Setup besteht aus einem Projektor, der über mehrere integrierte Spiegel auf sehr kurze Distanz projizieren kann, einer InfrarotKamera und einer Infratot-Lichtquelle, die beide am Projektor befestigt
sind. Die für das System entwickelte Software erlaubt die Erkennung von
Berührung der Tischoberfläche, sowie die Positionserkennung von Fingern,
speziellen Markern und die Erkennung und Lokalisierung von Papierseiten.
Zusätzlich wurden durch die Verwendung von optical flow Techniken verschiedene Interaktionsmöglichkeiten mit virtuellen Objekten implementiert.
Die Erweiterung von playAnywhere ist playTogether [46], das zwei solcher
13
Tabletop Systeme miteinander vernetzt und so die Interaktion mit örtlich
entfernten Benutzern erlaubt.
2.2.10
Augmented Coliseum [17]
Augmented Coliseum ermöglicht den Spielern, reale Miniatur-Roboter in einem Duell mit virtuellen Waffen gegeneinander antreten zu lassen. Gespielt
wird auf einer Spielfläche, auf die von oben projiziert wird. Dabei werden die
Bewegungen der Roboter durch spezielle, projizierte Muster gesteuert, die
auf den Robotern durch mehrere Fotodioden ausgelesen werden. Der Roboter folgt der projizierten Grafik, sobald diese auf der Spielfläche verschoben
wird. Der Spieler hat verschiedene offensive und defensive Funktionen, die
rund um den realen Roboter auf die virtuelle Spielfläche projiziert werden.
Die Spieler duellieren sich mit virtuellen Waffen, die vom eigenen Roboter
ausgehend abgefeuert werden können. Wird einer der Roboter zerstört, so
wird dies durch eine virtuelle Explosion angezeigt.
Kapitel 3
Konzept
3.1
Idee
Inspiriert durch verschiedene Projekte, die sich mit kollaborativem Arbeiten und intuitiven Interfaces [9, 21] auseinander setzen, entstand die Idee,
neuartige Interfaces als Brücke zwischen realer und virtueller Welt zu gestalten. Das Projekt sollte dabei in Hinblick auf die Implementierung Freiraum
zum Experimentieren geben und den Arbeitsverlauf weder durch Technologievorgaben noch durch ein restriktives Szenario zu sehr einschränken. Der
Bereich der interaktiven Spiele eröffnet die Möglichkeit mit neuen Interaktionstechniken und Werkzeugen zu experimentieren wie kaum ein anderer.
Dies und die gesammelten Erfahrungen mit Tabletop-Anwendungen sollten
im Projekt kombiniert werden.
Konkret sollte ein Spiel für mehrere Spieler auf einem interaktiven Tisch
entwickelt werden. Physische und virtuelle Gegenstände sowie mehrere Spieler sollten auf dem Spieltisch miteinander interagieren können. Der Schwerpunkt dabei sollte dabei auf einer intuitiven Interaktion der aller Komponenten im System liegen. Das implementierte Spiel trägt den Titel Comino 1
und kombiniert das Spiel mit virtuellen und realen Dominosteinen in einem
kollaborativen Puzzle. Die Spieler setzen von einem Startpunkt aus eine Kettenreaktion in Gang, die sich dann bis zum Endpunkt fortsetzen muss, um
den Level erfolgreich zu beenden. Dabei kann die Kettenreaktion mithilfe
spezieller Interfaces zwischen realer und virtueller Welt wechseln.
3.2
Vorbilder
Der implementierte Prototyp wurde von zwei Spielen stark beeinflusst. Es
handelt sich dabei jeweils um einen bekannten Vertreter aus der virtuellen
und aus der realen Welt. Die richtungsweisende Spielidee in Bezug auf das
1
Wortneuschöpfung aus den Worten Computer“ und Domino“
”
14
KAPITEL 3. KONZEPT
(a)
15
(b)
Abbildung 3.1: Beim Spielen von The Incredible Machine“ müssen ver”
schiedene Gegenstände so kombiniert werden, dass eine levelspezifische Aufgabe gelöst wird (a). Die beiden Screenshots zeigen zwei Levels aus der dritten
Auflage des Spieles. Die Komplexität der Level ist abhängig vom Fortschritt
innerhalb des Spieles und wird von privat agierenden Leveldesignern oft bis
c
an die Grenze der Schaffbarkeit gesteigert (b). (Abb.: Sierra
Entertainment)
Spielprinzip beruht auf dem Computerspielklassiker The Incredible Ma”
chine“, die Spielelemente und die Art der Interaktion sind jedoch an das
Spiel mit Dominosteinen angelehnt.
3.2.1
The Incredible Machine
Diese Serie von virtuellen Logikpuzzles der Spielefirma Sierra“2 nahm 1992
”
ihren Anfang und hat bis heute mindestens fünf Nachfolger hervorgebracht.
Spielprinzip und Leveldesign sind dabei im Wesentlichen unverändert geblieben. Abbildung 3.13 zeigt das Leveldesign von einem der Nachfolgespiele.
The Incredible Machine“ ist ein rundenbasiertes Spiel, in dem der Be”
nutzer mit einer limitierten Anzahl von Alltagsgegenständen verschiedenste
kleine Puzzles zu lösen hat. Die wichtigsten Regeln, die den Spielverlauf vorantreiben, sind vereinfachte Gesetze der Physik. Ein Ball fällt zu Boden, eine
Kerze erlischt bei aufkommendem Wind, ein gasgefüllter Ballon steigt auf.
Die Ziele in den einzelnen Spielrunden variieren genauso wie die verwendeten
Spielelemente. Das Umlegen eines Schalters ist genauso ein mögliches Ziel
wie das Zerplatzen eines Luftballons oder das Zerschlagen eines Aquariums.
Die Spielelemente sind aus der realen Welt übernommen und ermöglichen
es, neue Gegenstände in den Spielverlauf einzubinden, ohne dem Benutzer
deren Eigenschaften oder Funktion lange erklären zu müssen. Dies ermöglicht dem Spieler einen schnellen Einstieg in die Levels, der nicht durch
2
3
http://www.sierra.com/de/home.html
Abb.: http://www.worldvillage.com/wv/gamezone/html/reviews/machine.htm
KAPITEL 3. KONZEPT
16
zeitaufwendiges Lesen von Spielanleitungen geprägt ist. Dies ist eines der
grundlegenden Prinzipien zur Gestaltung eines guten Spielinterfaces [13].
A good game interface will not bombard the user with information at the outset or rely on a complex instruction manual;
it will teach the user everything he or she needs to know on a
need-to-know basis. This convention is so entrenched, in fact,
that gamers trust the system and never read the manuals.
Die Umsetzung in Comino: Auch für Comino war dieses Prinzip ein
Grundlegendes, auch wenn durch die Neuartigkeit der verwendeten Interfaces und des Spielkonzepts das Spiel nicht ganz ohne einführende Erklärungen
auskommt. Dies ist zum Teil auch in der Tatsache begründet, dass vieles im
Spiel aufgrund des Arbeitsaufwandes sehr komprimiert präsentiert werden
musste und der Benutzer innerhalb des Spieles nicht langsam an die einzelnen Themen herangeführt werden kann, wie das in den zahlreichen Levels
von The Incredible Machine“ passieren kann.
”
Ein wesentlicher Unterschied von Comino zum virtuellen Vorbild The
”
Incredible Machine“ ist die Orientierung des Spielraumes. Im Original existiert die virtuelle Welt nur im Aufriss. Der Spieler betrachtet das Spielfeld
von der Seite. Meist sind zu Beginn eines Levels mehrere fix positionierte
Plattformen und Gegenstände vorhanden, die dann vom Benutzer um die
zur Verfügung stehenden Levelbausteine erweitert werden. Die Schwerkraft
ist bei vielen Rätseln die treibende Kraft des Levels.
Dieser Levelaufbau war aber für das angedachte Spiel nicht praktikabel. Sollten reelle und virtuelle Gegenstände miteinander interagieren, so
mussten das virtuelle und das reale Spielfeld möglichst deckungsgleich übereinander liegen, so dass die Illusion einer direkten Interaktion geschaffen
werden konnte. Für eine vertikale Orientierung des virtuellen Spielfeldes
sollte idealerweise auch das reale Spielfeld vertikal angeordnet sein, was das
Positionieren von realen Gegenständen nur mithilfe von zusätzlichen Befestigungshilfsmitteln wie Magneten ermöglicht hätte.
Somit wurde entschieden, als reales Spielfeld eine Tischfläche zu verwenden und auch die virtuelle Spielfläche wurde in die Horizontale gedreht. Die
Benutzer betrachten sowohl das reale als auch das virtuelle Spielfeld von
oben. Nun können reelle Spielkomponenten einfach auf das Spielfeld gestellt
werden, auf dass auch die virtuellen Komponenten projiziert werden. Zusätzlich wird durch eine Ansicht von oben auch verhindert, dass die Betrachtung
des Spielfeldes durch den Benutzer aus einer anderen Position zu einem Problem führen könnte. Bei einer Tabletopanwendung steht des den Benutzern
meist frei, sich rund um den Tisch zu bewegen, was zu Einschränkungen
bei der Darstellung von Objekten auf dem Bildschirm führt. Ein Rennspiel,
bei dem der Fahrer aus dem Cockpit des Vehikels auf die virtuelle Rennstrecke hinaussieht, könnte zum Beispiel nur von einer Tischseite aus richtig
KAPITEL 3. KONZEPT
17
Abbildung 3.2: Können sich die Spieler frei um den Tisch bewegen, so muss
das im Spiel beachtet werden. Sowohl die Steuerung als auch Interface- oder
Textelemente sind schwerer zu erfassen, wenn die Ansicht wie hier auf dem
Kopf steht.
betrachtet werden. Steht der Spieler auf einer der drei anderern Seiten, so
erscheint für ihn das Bild entweder um neunzig Grad gedreht oder es steht
auf dem Kopf. Abbildung 3.2 illustriert dieses Beispiel mit einem Screenshot
aus dem Rennspiel Need for Speed : Carbon“4 .
”
Dies erschwert nicht nur das Erfassen von graphischen Elementen, sondern macht eventuell auch die Spielsteuerung unmöglich. Bei einer Ansicht
des Spielfeldes aus der Vogelperspektive ist die Betrachtungsrichtung für alle
Spieler im Wesentlichen gleich, das Spiel ist unabhängig vom Standort rund
um den Tisch spielbar.
Damit einher gehen aber auch einige Schwierigkeiten für ein Spielprizip
ähnlich dem von The Incredible Machine“. Die Perspektive von oben verhin”
dert das Platzieren von Objekten übereinander, da Spielelemente einander
verdecken und so der Level unübersichtlich und eventuell unspielbar wird.
Zusätzlich ist die Draufsicht eine ungewöhnliche Perspektive auf viele Alltagsgegenstände, was die Wiedererkennung dieser erschwert. Wie jedoch vorher angeführt emöglicht nur ein Erkennen der zur Verfügung stehenden Gegenständen einen flüssiges Spielverlauf ohne aufwendige Erklärungen. Auch
der Einfluss der Schwerkraft auf das Spielgeschehen muß zurückgenommen
werden, da fallende Objekte von oben betrachtet ihre Position nur wenig
verändern und somit solche Ereignisse im Spielverlauf vom Benutzer kaum
4
http://www.ea.com/nfs/carbon/us/
KAPITEL 3. KONZEPT
18
wahrgenommen werden. Eine neue, spielantreibende Kraft war also nötig.
3.2.2
Domino
Es galt also, ein grundlegendes Spielelement zu finden, das leicht verständlich ist und das auf einer horizontalen Spielfläche funktionieren würde. Die
vorgeschlagene Lösung hierfür ist die Verwendung von einer größeren Anzahl von Dominosteinen. Dabei geht es weniger um eine Verwendung der
Dominosteine im klassischen Sinn, bei dem Steine mit gleicher Augenanzahl
aneinandergereiht werden müssen, sondern um das Aufstellen von möglichst
vielen Dominosteinen in einer Reihe. Stößt man nun den Ersten der Steine
um, so fallen idealerweise in einer Kettenreaktion alle anderen Steine ebenfalls um. Durch geschicktes Platzieren von Steinen können so komplexere
Kettenreaktionen ausgelöst werden.
Für die Spieler heißt das nun Folgendes: In Comino müssen Dominosteine
hochkant so positioniert werden, dass sie, einmal angestoßen, den Impuls
von einem designierten Startpunkt bis zum Endpunkt des Levels weiterleiten. Dabei stellt der Computer sicher, dass die Steine hochkant im Level
aufgestellt werden, die richtige Positionierung und Orientierung der Steine
zueinander obliegt jedoch dem Spieler. Als Ergänzung zu den Dominosteinen
können aber auch andere Gegenstände in die Levels verbaut werden, um so
die Komplexität der einzelnen Levels zu erhöhen!
3.3
Spieldesign
Die Spielelemente: Die Verwendung von Dominosteinen als Hauptelement verändern das Spielprinzip von Comino im Vergleich zum Vorbild
The Incredible Machine“ gravierend. Während dort wenige Objekte mit
”
sehr spezifischen Funktionen an genau definierten Stellen auf dem Spielplan
platziert werden müssen, funktioniert Comino nach einem anderen Prinzip.
Der Dominostein ist als einzelnes Element sehr limitiert in seiner Funktion,
erst durch die Verwendung von vielen Steinen kombiniert mit interessanten Spielplänen entstehen abwechslungsreiche Szenarios. Die konkreten Einschränkungen und Herausforderungen an den Spieler sehen wie folgt aus:
Die Benutzer haben für jeden der Levels eine beschränkte Anzahl, im
Fall von Comino 100 virtuelle Steine zur Verfügung, die sie frei auf der
Spielfläche platzieren können. Zu Beginn eines jeden Levels stehen mehr
Steine zur Verfügung, als das zum Lösen der jeweiligen Aufgabe nötig ist.
Im Gegensatz zu den Objekten in The Incredible Machine“ können die Do”
minosteine jedoch verloren gehen, wenn sie an Stellen platziert werden, die
dafür nicht vorgesehen sind. Somit sind die Benutzer trotzdem angehalten,
sparsam mit den verfügbaren Steinen umzugehen, ohne dass eine gewisse
Freiheit beim Aufstellen der Dominos durch eine zu strenge Reglementierung verloren geht. Es besteht immer noch die Möglichkeit, Spielereien wie
KAPITEL 3. KONZEPT
19
zusätzliche Verzweigungen oder Ähnliches einzubauen, wie das beim Spiel
mit echten Dominosteinen meist geschieht.
Das Spielziel: Ein weiterer, sehr wesentlicher Unterschied zu The in”
credible Machine“ ist die Tatsache, dass nicht gegen die Zeit gespielt wird.
Während bei The incredible Machine“ die Puzzles möglichst schnell ge”
löst werden müssen, um viele Punkte zu verdienen, wurde in Comino auf
die Zeitnehmung verzichtet. Dies hat mehrere Gründe: Zum einen ist Comino als kollaboratives und nicht als kompetitives Spiel konzipiert. Es geht
darum, herauszufinden, wie ein Level funktioniert. Das Spiel ist in erster
Linie als Geschicklichkeitspiel konzipiert, das auf die Zusammenarbeit und
die Neugier der Spieler setzt.
Wenn reale Dominosteine in einem Level verwendet werden, verleitet
Zeitdruck dazu, dass die Spieler hastiger hantieren und so steigt die Wahrscheinlichkeit, dass sie Steine vorzeitig umzustoßen. Das kann zur Frustration der Benutzer und im schlimmsten Fall zum Aufgeben der Spieler führen. Wird der Spieler jedoch im Gegenzug belohnt, wenn alle Steine wie
geplant umfallen oder man zum Lösen der Puzzles möglichst wenige Steine
verbraucht, so wird das zu einer stärkeren Motivation der Spieler führen.
Zeitdruck könnte auch dazu führen, dass Spieler versucht werden, zu
betrügen, um eine möglichst hohe Punktezahl zu erreichen. Dies kann bei
der Verwendung von reellen Dominosteine leicht bewerkstelligt und nicht
erkannt oder verhindert werden. Mithilfe des technischen Setups ist es nicht
feststellbar, ob die Spieler tatsächlich alle realen Spielkomponenten ordnungsgemäß aufgestellt haben oder nicht.
Ein weiterer Grund für den verzicht auf das Spiel gegen die Zeit ist der,
dass die benötigte Zeit zum erfolgreichen Beendigen eines Levels natürlich
von der Anzahl der teilnehmenden Spieler abhängt. Die ist aber von Spiel
zu Spiel verschieden und durch das Setup nicht eruierbar, da grundsätzlich
beliebig viele Spieler beim Aufbau der Steine helfen können. Über die verwendete Hardware kann kein Aufschluss darüber gegeben werden, wie viele
Spieler tatsächlich gemeinsam am Tisch interagieren, eine aussagekräftige
Bestenliste ist somit unmöglich.
Technisch ist die Integration einer Zeitnehmung kein Porblem und könnte
durchaus in einer zukünftigen Version von Comino beinhaltet sein.
Die Rollenverteilung: Ein Vorteil, der sich durch die Verwendung eines
einfachen Spielelements wie eines Dominosteines ergibt ist, dass kollaboratives Spielen ohne komplizierte Aufgabenverteilung zwischen den Spielern
möglich ist. Nachdem mehrere Spieler mit einem in jeder Hinsicht gleichwertigen Interface mit dem Tisch interagieren, sind Rivalitäten aufgrund einer
Rollenverteilung zwischen den Spielern von vornherein weitgehend ausgeschlossen. Jeder Spieler hat die gleichen Rechte und Pflichten.
KAPITEL 3. KONZEPT
3.4
20
Interaktionsdesign
Das für das Spiel nötige Interakionsdesign muss in zwei Bereiche unterteilt
werden: die Interaktion des Spieles mit seinen Spielern und die Interaktion
mit den physischen Spielkomponenten.
3.4.1
Interaktion mit dem Spieler
Das Spiel mit realen Dominosteinen stellt vor allem Anforderungen an das
motorische Geschick der Spieler. Die Spieler müssen Stein um Stein aufnehmen, platzieren und genau auszurichten und dabei verhindern, dass Steine
unabsichtlich umgestoßen werden. Auch kompliziertere Handlungen wie das
Stapeln von Dominosteinen und der Bau von Brücken und Türmen ist natürlich möglich. Präzise Bewegungen sind dabei von äußerster Wichtigkeit.
Um all diese Interaktionsmöglichkeiten mit ähnlicher Genauigkeit in der
virtuellen Welt abbilden zu können, wäre für die Eingabe ein komplexes
technisches Setup erforderlich. Der technische Aufwand wäre überdies um
ein Vielfaches höher, wenn es mehreren Spielern gleichzeitig ermöglicht werden sollte, mit dem Spiel zu interagieren. Für Comino stellte sich die Frage,
ob die durch die möglichst direkt übernommene Interaktion gewonnenen
Freiheiten den Mehraufwand an Hardware, Entwicklungszeit und Kosten
rechtfertigen. Auch war anzunehmen, dass ein technisches Setup die Bewegungsfreiheit der Spieler rund um den Tisch beschneiden würde.
Bewegung virtueller Dominosteine: Für Comino wurde deshalb beschlossen, auf eine möglichst direkte Abbildung der Handhabung der reellen
Dominosteine für die Interaktion in der virtuellen Welt zu verzichten und
so den Spielern mehr Freiraum um den Tisch zu lassen. Um die Aufgabe
der Interaktion im virtuellen Raum zu lösen, war einer der ersten Schritte,
die Bewegungen auf einzelne Teile herunterzubrechen. Diese sollten dann
auch mit einem einfacheren technischen Setup umsetzbar sein. Für das Spiel
wurden vier Aktionen isoliert, die es ermöglichen, die für das Spiel relevanten Aktionen mit Dominosteinen in der virtuellen Welt abzubilden. Diese
Aktionen sind:
1. Aufstellen von neuen Dominosteinen (Create)
2. Verschieben von bereits aufgestellten Dominosteinen(Modify)
3. Umstoßen von Dominosteinen(Push)
4. Löschen von Dominosteinen(Delete)
Natürlich gehen durch diese Vereinfachung viele Interaktionsmöglichkeiten verloren, die mit echten Dominosteinen denkbar wären, aber die Vorteile
eines einfachen Interfaces sind für das geplante Spiel ungleich höher. Deshalb
KAPITEL 3. KONZEPT
21
wurde auf die Integration von weiteren Aktionen verzichtet, einer nachträglichen Integration stünde jedoch nichts im Weg.
Zusätzlich wurde die Bewegungsfreiheit der Interaktion von drei Dimensionen auf die Spieloberfläche reduziert. Virtuelle Dominosteine können also
nicht frei im dreidimensionalen Raum bewegt und platziert werden, sondern
nur entlang einer Oberflächengeometrie, die die jeweilige Untergrundoberfläche im Level repräsentiert. Somit konnten die notwendigen Freiheitsgrade
für das Eingabegerät auf zwei Dimensionen reduziert werden. Akzeptiert
man diese Lösung, so sind statt einer technisch sehr aufwendigen Schnittstelle nunmehr zwei unkomplizierte nötig, um die Interaktion auf dem Tisch
zu realisieren.
Moduswechsel: Das erste System muss es dem Spieler ermöglichen, zwischen den vier verschiedenen Modi Create, Modify, Push und Delete zu wechseln. Dies kann in Software genauso realisiert werden wie mithilfe zusätzlicher Hardware. Eine mögliche Implementierung in Software wäre dabei ein
virtuelles grafisches Userinterface mit Schaltflächen für die einzelnen Modi.
Eine Alternative wäre die Verwendung von Gestenerkennung, wo verschiedenen Aktionen verschiedene Gesten zugeteilt sind. Eine alternative Lösung
mit zusätzlicher Hardware wäre zum Beispiel die Verwendung einer herkömmlichen Tastatur. Auf Tastendruck wechselt der Benutzer zwischen den
einzelnen Aktionen. Denkbar wäre auch die Verwendung von Gamepads oder
speziell für das Spiel entwickelte Hardware. Die Möglichkeiten hier sind vielfältig.
Zeigegerät: Das zweite System muss als Zeigegerät funktionieren und es
dem Spieler ermöglichen, dem Spiel die Position der Aktion auf dem Tisch
mitzuteilen. Auch hierfür sind verschiedenste Technologien als Eingabegeräte denkbar. Als einfachste und naheliegendste Möglichkeit ist hier die Verwendung einer normalen Maus zu nennen, mit der ein Benutzer einen Cursor
steuert und so die Position der Interaktion definiert. Verschiedenste Alternativen inkludieren die Verwendung von MERLs5 Diamond Touch [9] zur
Positionserkennung von Fingern auf dem Tisch verwendet werden. Auch optische Systeme wie das reacTIVision Framework [15] oder magnetische Lösungen wie der Einsatz eines Flock of Birds 6 zur Positionserkennung würden
funktionieren.
Wenn daran festgehalten werden soll, dass mehrere Spieler gleichzeitig
mit dem Spiel interagieren sollen, bleiben nur mehr einige wenige Technologien übrig, die für mehrere Benutzer eine robuste und dabei in ihrer Bewegungsfreiheit wenig beschneidende Interaktion sicherstellen. In Abschnitt
5.2 wird die für Comino ausgesuchte Technologie vorgestellt.
5
6
http://www.merl.com/
http://www.ascension-tech.com/products/flockofbirds.php
KAPITEL 3. KONZEPT
3.4.2
22
Die Interaktion mit physischen Spielkomponenten
Ein Großteil der in Kapitel 2 vorgestellten Projekte beschäftigt sich mit
der Umsetzung von neuartigen Eingabegeräten für Tabletop-Applikationen.
Projekte, die spezielle Ausgabegeräte in Tabletop-Applikationen integrieren, sind jedoch bedeutend seltener, da die Umsetzung dieser Schnittstellen
spezielle Hardware erfordert. Für die Umsetzung solcher Interfaces, die unter dem Themenbereich des physical computing“ zusammengefasst werden,
”
stehen Entwicklern verschiedenste Möglichkeiten zur Verfügung. Alle Möglichkeiten haben jedoch gemeinsam, dass für die Ausgabegeräte aktive Bauelemente verwendet werden müssen. Aktiv meint in diesem Zusammenhang,
dass Komponenten (elektrische) Energie benötigen, um zu funktionieren.
Aktive Tische: Je nach Art des Tabletop-Projektes können die aktiven
Bauelemente direkt im Tisch integriert werden. Dies hat den Vorteil, dass
die Verkabelung vom Spieler versteckt werden kann. Zusätzliche physische
Interaktionsobjekte müssen dann meist nicht mehr mit aktiven Bauteilen
ausgestattet werden. Beispiele hierfür wären das Projekt PICO7 , in dem
durch Elektromagnete im Tisch kleine magnetische Objekte auf der Tischoberfläche bewegt werden können. Ein zweites Projekt, das eine direkte Veränderung der physischen Beschaffenheit der Oberfläche zulässt, ist Hyposurface8 . Solche Shape-Displays erlauben die Interaktion mit allen auf der
Oberfläche befindlichen Gegenständen. Informationen über Shape-Displays
findet sich in [34].
Für Comino kam die Integration von aktiven Bauteilen in den Tisch nicht
in Frage, da Comino auf ein bestehendes Hardware-Setup aufsetzen sollte
und ein Umbau des Tisches den Projektumfang gesprengt hätte.
Aktive Spielkomponenten: Für Comino wurde deshalb entschieden, die
Spielkomponenten selbst als aktive Bauteile umzusetzen. Dies hat den Vorteil, dass die Integration in den Tisch nicht nötig ist und die Komponenten
in ihrer Funktionalität, Wartung und Verwendung mehr Flexibilität bieten.
Als Nachteil muss jedoch genannt werden, dass die Komponenten mit dem
Steuerrechner verbunden sein müssen und dass die Stromversorgung der aktiven Bauteile sichergestellt sein muss.
Eine Lösung für die Umsetzung von eigenen Computer-Schnittstellen ist
die Verwendung von fertigen Mikro-Kontrollern. Je nach Ausführung können
die Systeme entweder wie ein Baukasten einfach zusammengesteckt werden
oder müssen von Grund auf selbst verkabelt werden. Je nach Vorwissen und
Art des Projektes stellen verschiedene Lösungen die größte Chance auf Erfolg in Aussicht. Eine ausführliche Übersicht über verschiedene Alternativen
7
8
http://www.jamespatten.com/pico/
http://www.hyposurface.org/
KAPITEL 3. KONZEPT
23
findet sich in [6, Kap. 2], eine kompaktere Übersicht im Abschnitt Related
”
Work“ in [28].
Mikrokontroller-Systeme: Mikrokontroller-Systeme können in drei Kategorien unterteilt werden: Highlevel-, Lowlevel- und Midlevel-Systeme.
Highlevel -Systeme zeichnen sich dadurch aus, dass sie möglichst einfach
zu verwenden sind. Vorgefertigte, geschlossene Sensorschaltungen mit dem
Mikrokontroller verbunden werden. Der Mikrokontroller ist meist über USB
mit einem Computer verbunden und liefert die Sensordaten an diesen weiter. Mithilfe von mitgelieferten APIs können die ausgelesenen Werte dann
in der Software weiterverwendet werden und über den Mikrokontroller verschiedene Ausgabegeräte wie LEDs, Servomotoren oder LCD-Bildschirme
angesteuert werden. Der Benutzer braucht kaum elektronisches Vorwissen
und die Risiken der Zerstörung der Hardware bei der Entwicklung sind gering. Doch die Flexibilität dieser Systeme ist stark eingeschränkt. Meist sind
diese Systeme nicht für die Anbindung von eigenen Sensoren geeignet, können nicht ohne angeschlossenen Rechner betrieben werden und sind auch
verhältnismäßig teuer. Ein Beispiel für ein solches Highlevel Systeme ist die
Phidgets-Plattform [12].
Dem gegenüber stehen Lowlevel -Lösungen, bei denen von der Sensorschaltung, Stromversogung bis zum Mikrokontroller und der Verbindung
zum Computer alles selbst umgesetzt werden muss. Die Umsetzung der
Schaltungen sowie die Programmierung der Mikroprozessoren setzt meist
großes Vorwissen voraus, doch Flexibilität und Preis9 dieser Lösung sind
ungeschlagen. Für Beginner ist diese Lösung aufgrund des großen Einarbeitungsbedarfes jedoch meist nicht praktikabel. Nachdem hier alle Komponenten selbst zusammengestellt werden, kann nicht auf bereits bestehende
Systeme verwiesen werden. Informationen für die eigene Umsetzung solcher
Systeme finden sich in [33].
Als Zwischenlösung finden sich Midlevel -Systeme, bei denen der Mikrokontroller bereits mit der für den Betrieb nötigen Elektronik wie Stromversorgung und Quarz in einem Modul kombiniert ist. Dennoch steht es dem
Benutzer frei, den Kontroller selbst zu programmieren und eigene Bauteile
für die Sensorschaltungen zu verwenden. Mit der größeren Freiheit steigen
natürlich auch die Anforderungen an das Vorwissen des Benutzers sowie das
Risiko für die verwendete Hardware, die leicht durch falsche Schaltungen zerstört werden kann. Die in Comino verwendete Arduino-Hardware [28] kann
dieser Kategorie zugewiesen werden und wird detailliert in Abschnitt 4.2.2
beschrieben.
9
Aufgrund der zusätzlichen Hardware und Software für die Programmierung meist gilt
dies erst bei größeren Mengen.
Kapitel 4
Technologische Grundlagen
Aus den in Kapitel 3 angestellten Überlegungen zum Spiel und den Interaktionstechniken lassen sich nun verschiedenste Erfordernisse an eine konkrete
Umsetzung des Konzeptes ableiten. Im Wesentlichen lassen sich die technischen Anforderungen in zwei große Gruppen einteilen, die softwareseitige
Umsetzung des Spieles und die Wahl der richtigen Technologien für die Umsetzung der physikalischen Schnittstellen.
Die folgenden Ausführungen sind vor allem als Vorbereitung auf das Implementierungskapitel (Siehe Kapitel 5) gedacht, in dem konkret die Arbeit
mit den jeweiligen Technologien im Vordergrund stehen wird. Die folgenden
Ausführungen können die jeweiligen Themenbereiche nur streifen und stellen
keinen Anspruch auf Vollständigkeit. Deshalb wird schon an dieser Stelle auf
die im Text referenzierte, weiterführende Literatur hingewiesen, mit der sich
der interessierte Leser über das zusammengestellte Material hinaus weiter
informieren kann.
4.1
Software
4.1.1
Virtools
Im Gegensatz zu den klassischen Varianten von The Incredible Machine“
”
sollte die neue Umsetzung in 3D erfolgen. Das Spielkonzept erforderte zusätzlich die Einbindung einer Physiksimulation und die Integration von eigener Software für die Kommunikation mit der verwendeten Hardware. Als
Entwicklungsumgebung wurde Virtools 41 gewählt, das die gestellten Anforderungen erfüllt. Mit einer auf Havoc Physics2 basierenden Physik-Bibliothek3 kann Virtools 4 um die nötigen Physik-Simulations-Funktionen erweitert werden. Die Kommunikation mit den Hardwarekomponenten erfolgte
1
http://www.virtools.com/solutions/products/virtools 4.asp
http://www.havok.com/content/view/17/30/
3
http://www.virtools.com/solutions/products/virtools-physics-library.asp
2
24
KAPITEL 4. TECHNOLOGISCHE GRUNDLAGEN
(a)
25
(b)
(c)
Abbildung 4.1: Die Abbildung zeigt einen Screenshot des Virtools Interfaces. Links oben befindet sich die 3D-Layout-Ansicht, das sowohl als Anzeigeals auch als Editier-Fenster für das 3D-Layout des Projektes dient. Das Fenster rechts zeigt verfügbare Building-Blocks für die Programmierung, das
Fenster unten zeigt den Level Manager, der alle Komponenten eines Projektes verwaltet.
über eigens erstellte Building-Blocks, die unter Verwendung der Virtools
SDK in C++ implementiert wurden.
Abbildung 4.1 zeigt die grafische Benutzeroberfläche von Virtools 4. Das
Programm bietet Möglichkeiten zur Erstellung, Verwaltung und Veröffentlichung von interaktiven 3D Applikationen. Virtools stellt dabei eine grafische
Benutzeroberfläche für die Programmierung der Applikationen zur Verfügung. Verschiedenste Programm-Bausteine, sogenannte Building-Blocks werden miteinander verknüpft und zu Graphen zusammengefasst, um zur gewünschten Programmlogik zu kommen. Das Programm kann dabei auf verschiedene Virtools Skripts aufgeteilt werden. Weitere Informationen zum
Einsatz, der Verwendung und möglichen Erweiterungen von Virtools 4 finden sich in [8] und [11] sowie auf der offiziellen Webseite.4 Abbildung 4.2
zeigt verschiedene Möglichkeiten des Zusammenfassens von Funktionalität,
die sowohl übersichtlicheres Arbeiten garantieren, als auch eine effizientere
Abarbeitung der Funktionen.
4
http://www.virtools.com/
26
Abbildung 4.2: In Virtools werden Builiding Blocks miteinander verknüpft,
um die Programmlogik zu implementieren. Große Programmteile können
in Scripts gekapselt werden, kleine in Graphen. Die Abbildung zeigt ein
Skript(a), dass mehrere geschachtelte Graphen (b) enthält, die wiederum
einzelne Building-Blocks(c) beinhalten.
4.1.2
vvvv
Als Experimentier- und Testplattform wurde vvvv 5 verwendet. Von den
Entwicklern als multipurpose toolkit“6 bezeichnet bietet vvvv eine Viel”
zahl an Möglichkeiten für Entwickler von interaktiven Applikationen. Das
Programm ist ein toolkit für die Verarbeitung von Echtzeit Video, die Einsatzbereiche liegen bei der Kommunikation mit physischen Interfaces, der
Visualisierung von Echtzeit 3D-Grafik und mit Shader-Unterstützung sowie Video- und Audioinstallationen mit gleichzeitiger Interaktion mehrerer
Benutzer. Ein weiterer Schwerpunkt ist die Verwaltung von MultimediaInstallationen, die auf mehreren Computern gleichzeitig laufen.
Während der Entwicklung von Comino wurde vvvv zum Testen der Kommunikation mit dem verwendeten Hardware Kontroller Arduino verwendet.
In vvvv wird wie auch in Virtools grafisch programmiert. Dabei bezeichnen
nodes die einzelnen Bausteine, die in vvvv zu patches verknüpft werden.
Auch vvvv erlaubt es, Teile eines patches zu kapseln. Diese Gruppen von
nodes werden dann als subpatches bezeichnet. Abbildung 4.3 zeigt ein Beispiel eines solchen subpatches.
4.2
Hardware
Die mögliche Hardware für die Umsetzung der physikalischen Schnittstellen
war implizit durch den engen Zeitrahmen, das Budget und das themenrelevante Vorwissen eingeschränkt. Die Anforderungen für die verwendeten
Technologien waren demnach geringer Preis, große Vielseitigkeit bei einfa5
Verwendete Version: vvvv 33beta12“, Download: http://vvvv.org/tiki-download file.
”
php?fileId=981
6
http://vvvv.org/tiki-index.php
27
Abbildung 4.3: Der Screenshot aus vvvv zeigt einen Subpatch aus einem
vvvv-Projekt.
cher Verwendung und eine umfangreiche Dokumentation. Auch der Einsatz
von mehreren Komponenten gleichzeitig war von Bedeutung, da das Konzept auf mehrere Benutzer ausgelegt war.
In den folgenden Abschnitten wird auf die gewählte Hardware eingegangen, die für die Implementierung der Benutzerschnittstellen von Comino
verwendet wurde.
4.2.1
Anoto
Wie in Abschnitt 3.4.1 schon erwähnt sind für den Benutzer zwei Schnittstellen für die Interaktion mit den virtuellen Dominosteinen nötig. Die erste
Schnittstelle soll es dem Benutzer ermöglichen, zwischen den einzelnen Aktionen im Spiel zu wechseln, das zweite Interface dient als Zeigegerät für die
Interaktion auf der Spielfläche.
Die Verwendung von digitalen Stiften, die auf Anoto 7 -Technologie basieren, ermöglichte es, beide Schnittstellen unter Verwendung nur eines Hardware-Devices umzusetzen. Die Stifte werden in weiterer Folge als AnotoStifte bezeichnet. Das Umschalten zwischen den verschiedenen Funktionen
7
http://www.anoto.com/
28
im Spiel wurde dabei mit speziellen physischen Menüs bewerkstelligt, die mit
Anoto-Stiften bedient werden können. Gleichzeitig funktionieren die Stifte
auch direkt als Zeigegeräte auf der Tischoberfläche und erlauben es so mehreren Benutzern, direkt auf der realen Spielfläche mit der virtuellen Welt zu
interagieren.
Das Konzept eines digitalen Stiftes wurde 1996 von Christer Fåhræus
im Rahmen seiner Doktorarbeit vorgestellt, um dann in den darauf folgenden Jahren in Form eines ersten, funktionierenden Prototypen umgesetzt
zu werden [1]. Die Anoto-Gruppe, vormals C Technologies“, erkannte das
”
Potential der Idee und startete 1998 mit der Vermarktung des ersten kommerziellen digitalen Stiftes, der C-Pen“ in Schweden. 1999 beginnt die in”
ternationale Vermarktung des Produktes. In Kooperation mit Sony (2002)8 ,
Logitech (2002)9 , Nokia (2003)10 und Hitachi Maxell (2003)11 werden die erste, zweite, dritte bzw. vierte Generation von digitalen Stiften basierend auf
Anoto-Technologie auf den Markt gebracht. Seit 2006 fokussiert Anoto auf
den Vertrieb von intelligenten Formularen plus Stiften für Großkunden unter anderem aus den Bereichen Logistik, Bildungswesen, öffentlicher Dienst,
Gesundheits- und Bankwesen12 .
Die beiden wesentlichen Bestandteile der Anoto-Technologie sind der digitale Stift sowie Papier, das mit einem speziellen Punktmuster, sogenanntem Anoto-Pattern bedruckt ist.
Anoto-Pattern: Das Anoto-Pattern ist ein Punktmuster, das zweidimensionale Koordinaten codiert und das von den Anoto-Stiften ausgelesen werden kann. Für die Bestimmung der absoluten Position (vergleiche auch Abbildung 4.4) wird eine Einheit von sechs mal sechs Punkten benötigt. Die
Verschiebung der einzelnen Punkte zueinander erlaubt es, wie in einem Barcode, Daten zu speichern. Für die Erstellung dieses Punktmusters wird ein
von Anoto entwickelter und patentierter Algorithmus verwendet, der eine
theoretische Gesamtfläche von 60.000.000 km2 einzigartigen Patterns erstellen kann. Diese Fläche ist in verschiedene Regionen unterteilt, denen bei
Bedarf verschiedene Funktionalität zugewiesen werden kann. So veranlassen gewisse Regionen des Patterns den Anoto-Stift, die gelesenen Daten zu
Speichern während andere Regionen das sofortige Senden aller Daten veranlassen.
Um Anoto-Pattern für eigene Projekte drucken und verwenden zu können, müssen von Anoto kostenpflichtige Patternlizenzen angefordert werden.
Lesbares Anoto-Pattern muss mit 600 dpi und mit Tinte gedruckt werden,
8
http://www.sonyericsson.com/spg.jsp?cc=global&lc=en&ver=4001&template=pp4 1
1&zone=pp&lm=pp4 1&pid=9753
9
http://www.logitech.com/index.cfm/mice pointers/digital pen/&cl=us,en
10
http://europe.nokia.com/link?cid=EDITORIAL 173765
11
http://www.maxell.co.jp/e/products/industrial/digitalpen/index.html
12
http://www.anoto.com/allcases
1.5 mm
29
0.3 mm
Abbildung 4.4: Die Abbildung zeigt eine schematische Darstellung des
Aufbaus des Anoto-Patterns. Wird der Stift über eine mit Anoto-Pattern
bedruckte Oberfläche bewegt (a), nimmt die im Stift integrierte Kamera 50
bis 100 Bilder pro Sekunde auf und gibt sie zur Verarbeitung an den Bildverarbeitungsprozessor weiter. Sechs mal sechs Punkte (b) werden benötigt, um
die Pattern-ID und die absolute Position zu berechnen. Diese befinden sich
auf einer Fläche von 1,5 mal 1,5 Millimeter. Denkt man sich ein Hilfsraster
(in der Abbildung grau dargestellt) mit einem Abstand von 0,3 Millimetern
über die Anoto-Punkte, so können die einzelnen Punkte sich oben, unten,
recht oder links vom gedachten Raster befinden (c).
die Licht mit einer Wellenlänge im Infrarotbereich (800nm bis 950nm) absorbiert. Tinte, die im besagten Infrarotbereich ausreichend Licht reflektiert,
wird von der optischen Einheit des Stiftes nicht erkannt. Somit können für
den Stift unsichtbare Grafiken über das Pattern gedruckt werden, um gewisse
Bereiche mit spezieller Funktionalität optisch hervorzuheben. Dies kann verwendet werden, um grafische Benutzer-Interfaces auf Papier zu erstellen, die
dann mit Anoto-Stiften bedient werden können. Abbildung 4.5 zeigt einige
Anwendungsbeispiele für solche Benutzer-Interfaces auf Papier.
In Abschnitt 5.2.2 wird konkret auf die Umsetzung von eigenen ausgedruckten Menüs eingegangen, die in Comino verwendet wurden. Mithilfe
dieser Interfaces ist es möglich, verschiedene Aktionen in Comino auszulösen.
Anoto-Stift: Anoto-Stifte funktionieren als Lesegeräte für das oben beschriebene Punktmuster und können die Position des Stiftes auf dem Pattern zu berechnen und die Koordinaten für die weitere Verwendung speichern oder an einen über Bluetooth13 verbundenen Computer senden. Die
folgenden Ausführungen und Grafiken beziehen sich auf das für die Implementierung verwendete Modell von Hitachi Maxell, die grundlegende Funktionsweise ist für alle auf Anoto-Technologie basierenden Stifte ähnlich. Der
Stift wird der Einfachheit halber auch weiterhin als Anoto-Stift bezeichnet.
Abbildung 4.6 zeigt die wesentlichen Bestandteile eines Anoto-Stifts. Wie
in Abschnitt 4.2.1 erwähnt funktioniert die Erkennung des Punktmusters im
13
http://www.bluetooth.com/bluetooth/
(a)
30
(b)
Abbildung 4.5: Bei Verwendung von Tinte, die das Anoto Pattern nicht
überdeckt, können verschiedenste Benutzerinterfaces auf das Papier gedruckt
werden, ohne dass die Erkennung gestört wird(a). Diese grafischen Userinterfaces werden dann mithilfe eines Anotostifts bedient(b).
Halteöse
Vibrator
Batterie-LED
Verbindungs-LED
Power-LED
wiederaufladbare
Lithium-Ionen-Batterie
Bluetooth-Prozessor
Leuchtdioden
Speicherchip (1 MB)
BildbearbeitungsProzessor
Mine
optische Einheit
Infrarot-Leuchtdiode
optischer Filter
Drucksensor
Hauptprozessor
Abbildung 4.6: Schematische Darstellung des Maxell-Stiftes mit den wichtigsten Komponenten.
Infrarotbereich.
Die optische Einheit des Stiftes, bestehend aus Filter, Kamera und Diode,
arbeitet demnach im für das menschliche Auge nicht sichtbaren Bereich. Die
Diode emittiert das für das Tracking nötige Licht und ermöglicht so eine
Verwendung des Stiftes auch bei sehr dunklen Lichtverhältnissen. Mit einer
Aufnahmerate von 50 bis 100 Bildern pro Sekunde stellt die Kamera sicher,
dass auch schnelle Bewegungen des Stiftes noch erkannt werden.
Die von der Kamera aufgenommenen Daten werden bereits innerhalb
des Stiftes verarbeitet. Die Bildverarbeitung passiert in einem eigenen Pro-
31
zessor, der die Kennnummer des Patterns (Pattern-ID) und das Koordinatenpaar auf dem Pattern ermittelt. Der maximale Fehler14 dabei beträgt
1mm. Zusätzlich wird für jedes Koordinatenpaar durch den hinter der Mine
platzierten Drucksensor auch die Druckstärke ermittelt. Zwei weitere Werte
werden für die einzelnen Punkte ermittelt. Der Stift versieht jeden Punkt
mit einem Zeitstempel und mit der Kennnummer des Stiftes (Pen-ID), die
es ermöglicht, verschiedenen Punkte verschiedenen Stiften zuzuordnen. Die
vom Stift aufgenommenen Daten werden entweder in den internen Speicher
geschrieben oder in Echtzeit an einen verbundenen Computer übertragen.
Anoto-Stifte besitzen üblicherweise mehrere LEDs, die dem Benutzer
Rückmeldungen zum aktuellen Zustand des Stiftes geben können. Die wichtigste Art, mit dem Benutzer zu kommunizieren ist jedoch der eingebaute
Vibrator, der bei verschiedensten Anlässen aktiviert wird. Einer dieser Auslöser ist das Auftreten eines Fehlers beim Auslesen des Patterns. Dies kann
mehrere Gründe haben: Eine Möglichkeit ist, dass das Pattern an der aktuellen Stelle nicht richtig gedruckt wurde. Sowohl Auflösung als auch Punktgrösse können hier den Ausschlag geben. Eine anderer, häufiger Auslöser ist
eine falsche Haltung des Stiftes. Sowohl ein zu steiler Winkel zum Pattern
als auch ein zu flacher Winkel können dazu führen, dass das Pattern nicht
mehr korrekt ausgelesen werden kann.
4.2.2
Arduino
Neben der Interaktion des Spielers mit dem System musste auch eine Interaktion von physischen und virtuellen Spielelementen in Comino umgesetzt
werden. Diese Interaktion sollte durch Schnittstellen erreicht werden, die
zum einen schnell und kostengünstig umzusetzen sind und dabei Spielraum
für Experimente zulassen.
Für Comino wurde ein Arduino15 -Hardware-Kontroller (in weiterer Folge
Arduino-Board oder Arduino-Kontroller genannt) verwendet. Arduino ist
eine Plattform, die sich der Erstellung physischer, interaktiver Objekte widmet. Die Arduino-Plattform wird als Open-Source-Projekt entwickelt und
besteht sowohl aus Hardware als auch aus Software. Die benötigte Hardware kann nach frei verfügbaren Plänen entweder selbst zusammengebaut
werden oder vormontiert gekauft werden. Eine Liste von Bezugsquellen für
die Hardware ist auf der offiziellen Arduino-Webseite zu finden16 . Es können
je nach Verwendungszweck verschiedene Arduino-Boards bezogen werden.
Erhältlich ist neben einer USB Ausführung auch eine verkleinerte Variante
ohne die USB-Schnittstelle sowie ein Kontroller mit Bluetooth-Antenne für
die kabellose Verbindung mit einem Computer17 . Die Webseite dient als Aus14
http://www.maxell.co.jp/e/products/industrial/digitalpen/faqs.html
http://www.arduino.cc/
16
http://www.arduino.cc/en/Main/Buy
17
http://www.arduino.cc/en/Main/Hardware
15
digitale Ein-/Ausgänge
Masse
3 2 2 0 9 8
1 1 1 1
7 6 5 4 3 2 1 0
Digital
4 3 2 1
ResetKnopf
4700
Arduino NG
1002
2501
2210
www.arduino.cc
1
X3
2210
0551-A
FT232RL
37AJ
N001
Quartz
6b
47
25V
6b
47
25V
D1
Kondensatoren
Schutzdiode
S1
ICSP
PJ65
GSTM
Stecker für externe
Stromversorgung
U4
ISPStecker
0604I
Empfänger-LED
TX
RX S16B00H6
ATMEGA8 - 16PU
Sender-LED
1001
PWR SEL
1
EXT USB
1001
StromversorgungsSelektor
Power-LED
TX
RX
AREF
GND
M.Banzi
D.Cuartielles
T.Igoe
G.Martino
D.Mellis
X4
USB-Verbindungsstecker
Test-LED (Pin 13)
4700
Seriell zu USB
Konverter-Chip
32
5V Gnd 9V
Masse
+5V-Ausgang
Analog in
0 1 2 3 4 5
Mikrokontroller
analoge Eingänge
+9V-Eingang
Abbildung 4.7: Schematische Darstellung des Arduino-Kontrollers
tauschplattform für Dokumentations- und Beispielmaterial der Entwicklerund Fangemeinde und ist der perfekte Startpunkt für jeden angehenden
Arduino-Entwickler und eine wertvolle Informationsquelle für alle Entwickler aus dem Bereich des Physical Computing“.
”
Das Arduino Projekt startete im akademischen Bereich und ist hier auch
weiterhin stark vertreten. Vor allem wegen des geringen Preises von ungefähr
30 Euro ist es eine gute Wahl für Workshops und Kurse an höheren Schulen
und Universitäten. Aufgrund der ausführlichen Dokumentation ist es aber
auch ohne Probleme möglich, sich autodidakt das nötige Wissen für die
Arbeit mit Arduino anzueignen.
Abbildung 4.7 zeigt eine schematische Darstellung des Arduino-Kontrollers mit den wichtigsten Komponenten. Es handelt sich dabei um die USB
Variante des Arduino-Boards. Die nachfolgenden Erklärungen beziehen sich
ebenfalls auf die USB-Version von Arduino. Eine detailierte Einführung und
weitere Informationen zum Thema physical computing“ finden sich in [4]
”
und in [33].
Arduino kann je nach Anwendungsszenario autonom oder mit einem
Computer verwendet werden. Für den Kontroller können mithilfe der auf
der Webseite erhältlichen Arduino-Software18 eigene Programme geschrie18
http://www.arduino.cc/en/Main/Software
33
ben werden und diese dann über USB auf das Board geladen werden. Das
vom Benutzer hochgeladene Programm legt unter anderem auch fest, ob das
Arduino-Board für die weitere Verwendung mit dem Computer verbunden
bleiben muss oder ob es autonom arbeiten kann.
Dem Entwickler stehen bei der USB-Version von Arduino folgende Einund Ausgänge zur Verfügung.
• 14 digitale Pins (0-13), die in der Software zwischen Ein- und Ausgang
umgeschaltet werden können.
• 6 analoge Pins (0-5), die nur als Eingänge verwendet werden können
und die anliegende Spannung (0 bis 5 Volt) mit 10 bit quantisieren .19
• 3 pulse width modulation“20 (PWM) Pins, wobei es sich strengge”
nommen hierbei um keine eigenen Pins handelt, sondern um einen
speziellen Modus der digitalen Pins 9, 10 und 11. Diese drei Pins können im auf dem Kontroller laufenden Programm in den PWM-Modus
geschaltet werden.
An die Ein- und Ausgabe Pins lassen sich nun verschiedenste elektronische Bauteile wie Sensoren oder LEDs anschließen, die vom auf dem ArduinoBoard laufenden Programm verarbeitet werden.
19
Details zum Analog-Digital Wandler sind unter http://www.atmel.com/dyn/resources/
prod documents/doc2486.pdf auf den Seiten 196 - 209 zu finden
20
Pulsbreiten Modulation: Verfahren, bei dem durch abwechselndes Anlegen von Spannung (HIGH) und keiner Spannung (LOW) analoge Spannungswerte zwischen 0 und der
HIGH-Spannung simuliert werden können. Vergleiche auch [4, S. 39–40] und [18, S. 19–21]
Kapitel 5
Implementierung
5.1
Spielprinzip
Comino ist ein Spiel für mehrere Spieler, das gemeinsam an einem Tisch
gespielt werden kann. Die wichtigsten Komponenten des Spieles sind Dominosteine, die von den Spielern auf der Spielfläche platziert werden müssen.
Dabei sollen die Dominosteine hochkant in einer Reihe aufgestellt werden,
dass der erste Stein, sobald er angestoßen wird, den zweiten und dieser wiederum den dritten Stein zu Fall bringt, bis alle Steine umgefallen sind. In
Comino müssen ein Startstein und ein Zielstein miteinander verbunden werden, um einen Level erfolgreich zu absolvieren.
Gespielt wird Comino auf einem Rückprojektionstisch mit einer speziellen Tischoberfläche. Diese Oberfläche erlaubt die gleichzeitige Lokalisierung
von mehreren digitalen Stiften direkt auf der Oberfläche. Mithilfe dieser
Stifte können die Spieler virtuelle Dominosteine auf dem projizierten Spielplan platzieren, die dann vom Projektor dargestellt werden. Der virtuelle
Untergrund bestimmt dabei, wo mit den Stiften Dominosteine platziert werden können und wo die virtuellen Steine nicht platziert werden können. Ist
es unmöglich, den Start- und Zielstein eines Levels nur mit virtuellen Steinen
zu verbinden, so können die Spieler in die reale Welt ausweichen.
Spezielle physische Spielkomponenten erlauben es den Spielern, den physikalischen Impuls, der die Dominosteine zum umkippen bewegt, vom virtuellen Spielbrett auf das reale Spielbrett zu übertragen und retour. Diese
Schnittstellen, in weiterer Folge Comino-Portale genannt, ermöglichen es
also, dass ein virtueller Stein einen echten Dominostein umkippen kann und
umgekehrt. Findet sich also in einem Level ein für die virtuellen Steine unüberwindbares Hindernis, so können die Benutzer statt den virtuellen Dominosteinen reelle Steine verwenden, um Start und Ziel miteinander zu verbinden.
34
KAPITEL 5. IMPLEMENTIERUNG
Anoto Stifte
35
Rückprojektionsoberfläche
Rückprojektionsoberfläche
Ventilatoren
Projektor
Projektor
Computer
Wartungsklappen
Spiegel
ProjektorLichtkegel
Spiegel
Kabelöffnung
(a)
(b)
Abbildung 5.1: Schematische Darstellung der wichtigsten Komponenten
des Rückprojektionstisches (a) und des Projektionswegs innerhalb des Tisches (b).
5.2
5.2.1
Hardware
Tisch
Als Comino Spielfläche wurde ein Rückprojektionstisch verwendet, der in
seiner Grundversion für das Augmented-Reality-Spiel Neon Racer“ [20] ge”
baut wurde. Der Tisch wurde jedoch für die Verwendung mit Anoto Stiften
adaptiert. Abbildung 5.1 zeigt die wichtigsten Komponenten des Rückprojektionstisches für Comino sowie den Lichtkegel des Projektors innerhalb des
Tisches. Der Tisch bietet ausreichend Platz, die gesamte benötigte Hardware
im Innenraum zu verstauen. Der im Tisch montierte Projektor projiziert auf
einen Spiegel, der das Bild auf die Tischoberfläche reflektiert. Dieser Aufbau erlaubt eine maximale Projektionsfläche von 83 × 110 cm bei einer
Gesamthöhe von 89 Zentimetern.
Der wesentliche Unterschied zum ursprünglichen Rückprojektionstisch
ist die abgeänderte Tischoberfläche, die sowohl für Rückprojektion als auch
als Tracking-Oberfläche für die Anoto-Stifte geeignet sein muss. Für ein
optimales Tracking-Ergebnis der Anoto Stifte spielen viele Faktoren eine
Rolle. Abbildung 5.2 zeigt die wichtigsten in einem schematischen Querschnitt durch eine Tracking-Oberfläche.
Der konkrete Aufbau der Tischoberfläche ist in Abbildung 5.3 dargestellt. Die Gesamtdicke der Oberfläche im Test-Setup beträgt 8 mm. Bei
dieser Dicke ist die Projektionsfläche exakt in der Tischplatte versenkt und
ergibt so eine glatte Spielfläche. Die Oberfläche selbst besteht aus drei verschiedenen Materialien. Die unterste Schicht bildet eine 5 mm starke, transparente Glasplatte, die als ebene Unterlage für das Anoto-Pattern dient. Sie
verstärkt die Tischoberfläche und verhindert ein Durchhängen der Projektionsfolie. An die Glasplatte bestehen sonst keine speziellen Anforderungen.
(e)
(d)
36
(a)
(f)
(b)
(c)
Abbildung 5.2: Die Abbildung zeigt sechs Faktoren, die auf das Anoto
Tracking Einfluß haben: Die Handhabung des Stiftes (a), die Beschaffenheit
der Oberfläche (b) und Unterlage(c), die des Materials mit Anoto-Pattern
(d), die Abnützung der Oberfläche durch die Mine (e) sowie verschiedene
optische Einflussgrößen (f), die das Tracking beeinflussen.
Oben befindet sich eine 3 mm dicke Scheibe, die zum Schutz der ProjektiR Scheibe1
onsfolie dient. Für diese Scheibe wurde eine gehärtete Plexiglas
verwendet, da diese Scheibe selbst bei längerer Verwendung der Anoto-Stifte
nur sehr wenig zerkratzt und so weitgehend fehlerfreies Tracking auf längere
Zeit sichergestellt ist. Auch diese Scheibe muss natürlich transparent sein,
um sowohl Projektion als auch Tracking zu ermöglichen. Die mit AnotoPattern bedruckte Projektionsfolie wird zwischen den beiden Scheiben fixiert
und dient sowohl als Projektionsfläche als auch als Tracking-Oberfläche. Um
als Rückprojektionsfolie zu funktionieren, muss das Material ein möglichst
homogen ausgeleuchtetes Bild ermöglichen. Wichtig ist dabei, dass weder
zu viel Licht absorbiert wird, noch dass ein starker Hotspot auf der Oberfläche sichtbar ist. Das Material muss bedruckbar sein, wobei idealerweise
der Druck nicht verwischbar sein sollte. Zusätzlich müssen die Materialeigenschaften sicherstellen, dass das Projektorlicht das Tracking der Stifte
nicht stört. Als Projektionsfolie wurde HP Colorlucent Backlit Film“2 ver”
wendet, die alle Anforderungen zufriedenstellend erfüllt.
5.2.2
Anoto Menüs
Für Comino wurden verschiedene physische Menüs und Interfaces umgesetzt, die mit den Anoto-Stiften bedient werden können. Sie dienen zum
Steuern von verschiedene Funktionen im Spiel. Im Wesentlichen bestehen
1
http://www.interlux.at/produkte.php/pgPath/13 17 100 105/page/
vollplatten-extrudiert-xtp.html
2
http://h30267.www3.hp.com/country/us/en/designjet/supplies/vls32-2103---.html?
pageseq=920731
37
(d)
(a)
(c)
(e)
(b)
(f)
Abbildung 5.3: Die für das Anoto-Tracking benötigten Bestandteile im
Tisch: Durch eine 3mm dicke, kratzfeste Kunststoffplatte (a) geschützt dient
eine spezielle Folie (b), die mit Anoto-Pattern bedruckt ist, gleichzeitig als
Projektions- und Tracking-Fläche. Darunter liegt eine 5mm dicke Glasplatte
(c). Sie verstärkt die Oberfläche und verhindert ein Durchhängen der Projektionsfolie. Die drei Komponenten (a), (b) und (c) wurden für das Foto aus
ihrer Umrahmung gehoben. Die beiden Ladestationen (e) dienen zum Aufladen der Stifte (d) bei Nichtgebrauch. Sowohl die Ladestationen als auch die
Projektionsfläche sind in den Holzrahmen (f) versenkt.
alle diese Menüs aus Papier, das mit Anoto-Pattern bedruckt ist und auf
dem zusätzlich ein grafisches Userinterface gedruckt wurde. Das bedruckte
Papier kann in weiterer Folge auf die gewünschte Größe und Form zugeschnitten und auf verschiedene Oberflächen geklebt werden. Im folgenden
Abschnitt wird kurz auf die Herstellung von solchen druckbaren Interfaces
am Beispiel des Hauptmenüs von Comino erklärt.
Das Hauptmenü von Comino erlaubt es den Benutzern, zwischen den
verschiedenen Interaktions-Möglichkeiten der Stifte zu wechseln. Zusätzlich
können verschiedene Aktionen im Level ausgelöst werden. So kann auf dem
Hauptmenü die Levelsimulation gestartet werden, der Level kann in den
Anfangszustand zurückversetzt werden und es eröffnet die Möglichkeit, sich
einen Hilfedialog zu jedem Level anzeigen zu lassen.
Wie schon in Abschnitt 4.2.1 erwähnt, muss beim Überdrucken des Patterns darauf geachtet werden, dass im Infrarotbereich das Pattern immer
noch klar ersichtlich ist. Da die Verwendung von schwarzer Tinte beim
Drucken mit handelsüblichen Tintenstrahl- und Laserdruckern dies oft nicht
gewährleistet ist, kann hier beim Vierfarbdruck auf spezielle schwarze Tinte
38
zurückgegriffen werden [2].
Anoto substitute black is black ink that is not seen by the pen.
Therefore Anoto substitute black can be used on top of the pattern without disturbing the functionality. If you wish to print
anything in a four-color process on top of the pattern, then the Kchannel in CMYK must be printed with Anoto substitute black.
Diese Tinte ist jedoch für den Privatgebrauch schwer erhältlich, was in
der Praxis dazu führt, dass Vierfarbdruck nur mit Einschränkungen möglich
ist. Eine funktionierende Möglichkeit besteht darin, möglichst nur grafische
Interfaces zu drucken, die überhaupt kein oder nur wenig Schwarz verwenden. Da zum Auslösen eines Buttons theoretisch nur ein einziger Punkt
erkannt werden muss, kann toleriert werden, dass das Tracking nicht überall
einwandfrei funktioniert. Solange der Stift einen Punkt erkennen kann, wird
das Interface trotzdem funktionieren. Somit kann zum Beispiel Schwarz zum
Drucken von Text auf Buttons verwendet werden, ohne die Funktionalität
stark zu beeinträchtigen. Der Stift wird jedoch zu vibrieren beginnen sofern das Pattern nicht erkannt werden kann, was den Benutzer verwirren
könnte. Sollen auf dem gedruckten Menü nicht nur Buttons, sondern auch
ein- oder zweidimensionale Regler Platz finden, so sollte in jedem Fall die gesamte Fläche vom Stift lesbar sein. In diesem Fall empfiehlt sich eine andere
Möglichkeit, die auch für die Erstellung der physischen Menüs für Comino
verwendet wurde.
Beim Druck von Grafiken auf einem Drucker für den Heimgebrauch ist
es üblich, dass der Druckertreiber noch gewisse Änderungen an den Grafiken vornimmt. Eine davon ist das Ersetzen von Farbanteilen bei dunklen,
zusammengemischten Farbflächen durch schwarze Tinte. Dies passiert auch,
wenn die CMYK-Farbe in der Grafiksoftware keinen Schwarzanteil hat. Dies
ist üblicherweise durchaus wünschenswert, da so bei gleich aussehendem
Druckergebnis die meist teurere Farbpatrone geschont wird. Für den Druck
von grafischen Interfaces über Anoto-Pattern ist diese Funktion jedoch nicht
wünschenswert, da das Resultat nicht funktioniert. Dieses Problem lässt sich
jedoch umgehen. Im folgenden Teil wird beschrieben, wie durch einen einfachen Trick flächige schwarze Interfaces gedruckt werden können, ohne dass
das Anoto-Tracking davon beeinträchtigt wird.
Alle für das Projekt benötigten Vektorgrafiken wurden in Adobe Freehand MX3 erstellt. Analog zur Vorgehensweise kann natürlich jedes andere
Grafikprogramm verwendet werden. Natürlich unterscheiden sich die programmspezifischen Befehle, die grundlegende Vorgehensweise ist aber gleich.
Abbildung 5.4 zeigt die erstellte Vektorgrafik für das Hauptmenü. Bei der
Erstellung wurde darauf geachtet, dass nur CMYK Farben verwendet wur3
http://www.adobe.com/products/freehand/
39
Abbildung 5.4: Das Design des Hauptmenüs von Comino.
den, deren K-Wert auf 0 gesetzt war. Dunkle Farben sind nur aus den drei
Farbkomponenten Cyan, Magenta und Yellow zusammengesetzt.
Ist die Grafik fertiggestellt, werden im nächsten Schritt die drei Farbkanäle händisch separiert. Hierfür sollte die Grafik innerhalb des druckbaren Bereiches auf einer eigenen Seite platziert werden. Danach empfiehlt es
sich, für jeden Farbkanal eine Kopie der Seite mit der Grafik anzulegen. Das
Original sollte als Referenz erhalten bleiben. Dabei ist darauf zu achten,
dass die Grafik auf den Seiten an exakt der selben Stelle platziert ist. Danach wird die Grafik auf jeder der Seiten auf einen Farbkanal reduziert. Dies
funktioniert in Freehand über das Color Control“ Menü (Siehe Abbildung
”
5.5) und wirkt sich auf alle im Vorfeld markierten Objekte aus!
Abbildung 5.6 zeigt die Grafiken nach dem Reduzieren auf jeweils einen
Farbkanal. Das Interface ist nun für den Druck vorbereitet. Das Mischen der
Farben, das normalerweise in einem Druckdurchlauf passiert, erfolgt nun in
drei seperaten Druckdurchläufen, bei denen immer auf dieselbe Seite Papier gedruckt wird. Nacheinander wird auf dasselbe Blatt Papier jede der
drei farbreduzierten Grafiken gedruckt. Dabei sollten für jeden Durchgang
die gleichen Druckeinstellungen verwendet werden, um ein farbechtes Ergebnis zu erhalten. Für manche Drucker empfiehlt es sich, das Ergebnis mithilfe der Treibereinstellungen noch farbzukorrigieren. Hierfür wird jedoch
nur eine empirische Anpassung vorgeschlagen, da die erhaltenen Ergebnisse
stark von Drucker und verwendeter Grafik abhängen und deshalb keine generellen Aussagen getroffen werden können. Zum Abschluss muss noch mit
schwarzer Tinte das Pattern über das Interface gedruckt werden und die ein-
40
Abbildung 5.5: In Freehand MX ist Funktion zum Verändern der Farbverhältnisse einer Grafik im Menü Xtras->Colors->Color Control zu finden.
(a)
(b)
(c)
Abbildung 5.6: Die Abbildung zeigt die Kopien des Hauptmenüdesigns,
die mithilfe des Color Control-Menüs auf den Cyan- (a), den Magenta- (b)
und Yellowfrabanteil (c) reduziert wurden. In der unteren Reihe finden sich
die Menüeinstellungen für das jeweils darüber gezeigte Ergebnis.
zelnen sensitiven Bereiche des Interfaces kalibriert werden. Der Druck der
einzelnen Durchgänge kann dabei in eine beliebigen Reihenfolge erfolgen!
Ist das Interface kalibriert, so kann es zurechtgeschnitten und in verschiedene Bauteile integriert werden. Abbildung 5.7 zeigt das fertig ausgeschnittene Hauptmenü von Comino. Zum Schutz vor Zerkratzen wurde das
bedruckte Papier zwischen zwei Acryl-Scheiben fixiert.
(a)
41
(b)
Abbildung 5.7: Die Abbildung zeigt die Verwendung eines physischen
Menüs in Comino. Der Stift kann sowohl zum Bedienen des Menüs (a) als
auch als Eingeabegerät direkt auf dem Tisch (b) verwendet werden
5.2.3
Arduino-Sensorbox
Für die Erstellung und das Testen der benötigten elektronischen Schaltungen
wurde eine Steckplatine4 verwendet. Mit der Steckplatine können Schaltungen ohne zu Löten erstellt werden. Abbildung 5.8 zeigt einen Testaufbau
einer Infrarotschranke sowie mehrere LEDs, die zum Testen der Kommunikation mit dem Arduino-Kontroller verwendet wurden.
Für die Verwendung im Spiel sollte die Verkabelung der physischen Spielkomponenten und des Arduino-Kontrollers jedoch vom Benutzer weitgehend
verborgen werden, um einer komplizierten Handhabung und falschen Schaltungen entgegenzuwirken. Trotzdem sollte das verwendete Arduino Board
auch weiterhin flexibel eingesetzt werden können, um mit zukünftigen Erweiterungen und Projekten kompatibel zu sein. Um diesen Anforderungen
gerecht zu werden, wurde der Arduino-Kontroller in ein Plastikgehäuse verbaut und für die Verwendung mit standardisierten Steckverbindungen verkabelt. Dabei sollten möglichst viele der Ein- und Ausgänge des Kontrollers
nach dem Verbauen in das Gehäuse (in die Sensorbox) weiterhin verfügbar
sein. Abbildung 5.9 zeigt schematisch den Aufbau der Sensorbox. Bei allen
folgenden Abbildungen repräsentieren die dargestellten Farben die reellen
Farben der verwendeten Kabel der konkreten Umsetzung und keine Pinbelegungen. Die Pinbelegungen der Buchsen finden sich im unteren Teil von
Abbildung 5.9.
Als Steckverbindungen für die Sensorbox wurden vier 4-polige Mini-DIN5
Stecker und vier Chinch6 (RCA) Stecker verwendet. Weiters wurde für die
4
http://www1.at.conrad.com/scripts/wgate/zcop at/˜====?˜template=PCAT AREA
S BROWSE&direkt aufriss area=SHOP AREA 14739
5
http://de.wikipedia.org/wiki/Mini-DIN
6
http://de.wikipedia.org/wiki/Cinch
42
Abbildung 5.8: Die abgebildete Testschaltung zeigt im Vordergrund
eine Infrarot-Lichtschranke sowie einige LEDs. Die dargestellten Bauteile
sind über eine Steckplatine mit dem im Hintergrund sichtbaren ArduinoKontroller verbunden und dienten in der Anfangsphase des Projektes als
Testschaltungen für die Kommunikation mit Arduino.
Stromversorgung von externen Schaltungen ein Hohlstecker7 mit einer Augangsspannung von +5 Volt vorgesehen. Zusätzlich finden sich auf der Sensorbox die USB Buchse des Arduino-Boards sowie ein LED, das über den
digitalen Pin Nummer 13 des Arduino-Kontrollers ein und ausgeschaltet
werden kann.
Abbildung 5.10 zeigt die Sensorbox in geöffnetem Zustand. Die Buchsen
sind in zwei Reihen übereinander verbaut. Die USB-Buchse des ArduinoBoards ist auf der gegenüberliegenden Seite platziert.
Um in weiterer Folge eindeutige Anleitungen für das Anstecken der verschiedenen Spielkomponenten geben zu können, wurden verschiedene Farben
für die Buchsen verwendet. So sind Verwechslungen beim Anstecken weitgehend ausgeschlossen. Zur besseren Übersicht und zum Vergleich mit dem
Foto der geöffneten Sensorbox sind in Abbildung 5.11 und Abbildung 5.12
die beiden Buchsen-Typen getrennt voneinander dargestellt.
Um direkt im Spiel die Funktionalität der Sensorbox und der Komponenten überprüfen zu können, wurde für die Sensorbox ein eigenes Menü entworfen, das mit Anoto-Stiften bedient werden kann. Mithilfe dieses Menüs
ist es möglich, den Zustand aller Ausgänge der Sensorbox zu setzen und
so gleichzeitig die Kommunikation mit Arduino und die Funktionsweise al7
http://de.wikipedia.org/wiki/Hohlstecker
Ein-/Ausgänge Sensorbox
43
Ein-/Ausgänge Arduino
DIN Buchsen
Beschreibung
Kabel
Farbe
M
RCA Buchsen
as
+5 se
V
Power
+5V Ausgang
Masse
+5V
Mini-DIN* Weiß 1
Masse
+5V
Digital I/O
Digital I/O
PWM
Mini-DIN Weiß 2
Masse
+5V
Digital I/O
Digital I/O
PWM
Mini-DIN Schwarz 1
Masse
+5V
Digital I/O
Analog I
Mini-DIN Schwarz 2
Masse
+5V
Digital I/O
Analog I
RCA** Blau
Masse
PWM
RCA Rot
Masse
Digital I/O
RCA Grün
Masse
Digital I/O
RCA Orange
Masse
Digital I/O
LED
Masse
Daten
* 4 polig
Pinbelegung RCA:
Signal
Analoge
Eingänge
(Analog I)
0 1 2 3 4 5
Digitale Ein-/Ausgänge
(Digital I/O)
PWM
1 1 1 1
2 3 4 5 6 7 8 9 0 1 2 3
Hohlstecker
USB
LED
** RCA ist die internationale Steckerbezeichnung für Cinch
Hohlstecker:
Mini-DIN:
Masse
Signal
+5V
Signal
Masse
+5V
Masse
Abbildung 5.9: Schematische Darstellung der Sensorbox. Die waagrechten
Linien zeigt die Verkabelung von den Buchsen zu den Arduino-Pins, die durch
senkrechte Linien repräsentiert sind. Am linken und rechten Rand finden sich
schematische Abbildungen der verbauten Buchsen. Im unteren Teil findet sich
die Pinbelegung der verwendeten Buchsen.
44
Abbildung 5.10: Die Sensorbox ohne Abdeckung. Die vier Cinch Buchsen
liegen über den vier Mini-DIN Buchsen. Der Hohlstecker und das LED sind
der Sensorbox in dieser Abbildung noch nicht hinzugefügt.
LED
Sensorbox
Lochrasterplatine
RCA Blau
RCA Rot
RCA Grün
RCA Orange
+5V-Ausgang
Arduino-Kontroller
Abbildung 5.11: Die Verkabelung der vier RCA Buchsen der Sensorbox.
Um leicht verständliche Anleitungen für das Anstecken von Spielkomponenten geben zu können, wurden verschiedenfarbige Buchsen verwendet.
45
Mini-DIN Schwarz 2
Mini-DIN Schwarz 1
Mini-DIN Weiß 2
Mini-DIN Weiß 1
Abbildung 5.12: Die Verkabelung der vier Mini-DIN Buchsen der Sensorbox. Die beiden weißen Buchsen sind jeweils mit einem digitalen Pin
mit PWM-Funktion verbunden und können so Servos ansteuern. Die beiden schwarzen Buchsen sind für den Einsatz mit Sensoren gedacht und sind
jeweils mit einem analogen Eingang des Arduino-Boards verbunden.
(a)
(b)
Abbildung 5.13: Die Abbildung zeigt das für die Sensorbox implementierte
Menü (a), das direkt auf dem Gehäuse angebracht ist. Mithilfe eines AnotoStifts (b) können über dieses Menü alle Ausgänge der Sensorbox gesetzt
werden.
ler angeschlossenen physischen Komponenten testen. Abbildung 5.13 zeigt
die Sensorbox mit dem Menü. Durch einfaches Berühren der vordefinierten Bereiche werden in Comino die jeweiligen Ausgänge am Arduino-Board
aktiviert oder deaktiviert.
5.2.4
Comino-Portale
Um die virtuellen Spielsteine mit den reellen interagieren lassen zu können
wurden zwei physische Portale für Comino entwickelt, die diese Interaktion
erlauben. Die Aufgabe der physischen Spielelemente war namensgebend für
die beiden Portale. Das Portal, das den physikalischen Impuls von der realen
in die virtuelle Welt weiterleitet, wird in Folge R2V (Real-To-Virtual ), das
andere Portal mit V2R (Virtual-To-Real ) bezeichnet. Zusätzlich wurde noch
(V2R)
(R2V)
46
(2X5L)
Abbildung 5.14: Die drei für Comino entwickelten physischen Spielkomponenten. Das erste Portal (V2R) erlaubt den Übergang von der virtuellen
Spielfläche auf die reale, Portal Nummer zwei (R2V) erlaubt den Übergang
in die andere Richtung. Die dritte physische Schnittstelle (2X5L) dient als
Anzeige für spezielle Spielereignisse.
eine dritte physische Spielkomponente, ein Lauflicht, gebaut. Das Lauflicht
kann als Anzeige für spezielle Spielereignisse verwendet werden. In weiterer
Folge wird für die Bezeichnung des Lauflichts auch die Abkürzung 2X5L
verwendet. Abbildung 5.14 zeigt die drei phyischen Spielkomponenten.
Bei allen drei Spielelementen handelt es sich um Ausgabegeräte, da jede
der drei Komponenten über LEDs verfügt, die vom Computer aus angesteuert werden können. Das R2V-Portal ist zusätzlich auch noch Eingabegerät,
da es auf Änderungen in der realen Welt reagieren kann und diese für den
Computer sichtbar macht. Das V2R-Portal verfügt über eine zusätzliche
Ausgabefunktion, die das Umstoßen von Dominosteinen ermöglicht.
Funktionsweise der Portale
Die Portale sind für den Einsatz mit der in Abschnitt 5.2.3 beschriebenen
Sensorbox umgesetzt und sind dafür mit passenden Steckverbindungen ausgestattet. Jedes der beiden Portale verfügt über eine 4-polige Mini-DIN
Buchse. Mit einem passenden Kabel (S-Video) kann das Portal an einer
vordefinierten Buchse an der Sensorbox angesteckt werden.
R2V: Der Übergang von der realen in die virtuelle Welt ist der technisch
leichter zu realisierende, da keine physikalische Kraft erzeugt werden muss.
Es reicht, den realen physikalischen Impuls zu detektieren, was in Comino
mithilfe einer Infrarot-Lichtschranke8 umgesetzt wurde. Im Portal ist auf
8
Bausatz Infrarot-Lichtschranke“ von Electronicum Austria http://www.electronicum.
”
at/index.htm?top bausatz/index top.htm˜anzeige
47
steuerbares LED
Kontroll-LED
Dominostein
Infrarot-LED Infrarot Lichtstrahl
Infrarot Fotodiode
Abbildung 5.15: Schematische Darstellung des R2V-Portals mit den wichtigsten Elementen. Die Abbildung zeigt die Ausmaße des Portals in Relation
zu den verwendeten Domino Steinen, die im Torbogen leicht Platz finden.
einer Seite des Torbogens eine Infrarot-Diode verbaut, auf der genau gegenüberliegenden Stelle des Torbogens liegt eine Infrarot-Fotodiode. Abbildung
5.15 zeigt die wichtigsten Bestandteile des Portals.
Wird das Portal mit der Sensorbox verbunden, so sendet die InfrarotDiode Licht aus, das von der Fotodiode detektiert wird. Wird genügend
Licht erkannt, schaltet die Fotodiode einen Transistor durch und es leuchtet
zur Kontrolle ein LED am Portal auf. Ist das Portal richtig angeschlossen,
so liegt zu diesem Zeitpunkt beim entsprechenden Eingang des ArduinoKontrollers Spannung an. Der analoge Eingang steht auf einem Wert, der
über 1000 liegt. Wird die Sichtverbindung jedoch unterbrochen, etwa durch
einen umgefallenen Dominostein, so reicht das Licht nicht mehr aus, den
Transistor durchzuschalten. Die Kontrolllampe erlischt und am ArduinoEingang liegt nun ein Wert kleiner 50 an. Will man nun einen Spielimpuls
von der realen Welt in die virtuelle übertragen, so reicht es, die realen Dominosteine entsprechend zu platzieren. Abbildung 5.16 illustriert den Vorgang, der zum Durchbrechen der Lichtschranke führt. Dies wird durch den
Arduino-Kontroller detektiert, in Virtools ausgewertet und führt im weiterer
Folge im Spiel zu einem virtuellen Impuls, der virtuelle Dominosteine zum
Umkippen bringt.
V2R: Der technisch aufwendigere Übergang ist der von der virtuellen Welt
in die reale. In diesem Fall muss eine mechanische Kraft ausgelöst werden, die
(a)
(b)
48
(c)
Abbildung 5.16: Sind die realen Dominosteine richtig platziert (a), so
bewirkt ein Umstoßen der aufgestellten Dominosteine (b), dass die Lichtschranke durch den liegengebliebenen Dominostein durchbrochen wird (c).
Diese Information wird am verbundenen Arduino-Eingang ausgelesen, an
Virtools weitergeleitet und kann in Folge verschiedenste Aktionen im Spiel
auslösen.
reelle Dominosteine zu Fall bringen kann. Die Umsetzung dieses Interfaces
erfolgte mit einem Servomotors9 , der über einen Schwenkarm Dominosteine
umwerfen kann. Mit der richtigen Buchse der Sensorbox verbunden, kann die
Stellung des Servomotors über den PWM-Ausgang des Arduino-Kontrollers
verändert werden. Wie auch beim zweiten Portal befindet sich auch auf
diesem eine Kontroll-LED. Befindet sich das Portal in der Ausgangsstellung
mit herabgesenktem Schwenkarm, so leuchtet das Kontroll-LED. Das LED
erlischt, wenn der Schwenkarm nach hinten bewegt wird. Abbildung 5.17
zeigt die Komponenten des V2R-Portals.
Auch bei dieser Schnittstelle spielt natürlich das richtige Platzieren der
realen Dominosteine eine wesentliche Rolle. Die Kettenreaktion wird in diesem Fall von einem Ereignis in der virtuellen Welt ausgelöst. Dieses bewirkt,
dass der Schwenkarm sich rasch nach hinten bewegt und dabei darunter platzierte Dominosteine umstößt. Der Bereich, in dem der Schwenkarm Dominosteine umstoßen kann, erstreckt sich über mehr als zwei Drittel des gesamten
Torbogens, was das richtige Platzieren einfach gestaltet. In Comino wird der
Schwenkarm automatisch nach kurzer Zeit wieder in die Startposition bewegt. Abbildung 5.18 zeigt die Funktionsweise der V2R-Schnittstelle.
Interaktive Oberfläche
Um die Interaktivität der beiden Portale noch zu erhöhen, wurden sowohl die
Seiten- als auch die Deckfläche mit Papier beklebt, das mit Anoto-Pattern
bedruckt ist. Somit wird die gesamte physische Schnittstelle zur zusätzlichen
Interaktionsfläche für Anoto-Stifte. Über dieses spezielle Interface kann nun
auf verschiedenste Einstellungen im Spiel Einfluss genommen werden. Als
erste Umsetzung in Comino werden über die sensitiven Oberflächen ver9
Acoms AS-12
49
steuerbares LED
Kontroll-LED
Dominostein
Servo
Schwenkarm
Abbildung 5.17: Mithilfe eines Servomotors, an dem ein Schwenkarm befestigt ist, kann die V2R-Schnittstelle mechanische Impulse an reale Dominosteine weitergeben.
(a)
(b)
(c)
Abbildung 5.18: Auch bei diesem Portal ist die richtige Platzierung der
Dominosteine von großer Bedeutung (a). Ausgelöst durch ein virtuelles Ereignis bewegt sich der Schwenkarm (b) nach hinten und stößt so darunter
aufgestellte Dominosteine um (c).
schiedene Parameter von Partikel-Systemen gesetzt, die im Spiel rund um
die Portale projiziert werden. Abbildung 5.19 zeigt die Interaktion mit dem
Stift sowie die veränderbaren Parameter im Spiel.
Dem Benutzer kann zusätzlich zu den projizierten Rückmeldungen auch
direkt durch das Portal Feedback gegeben werden. In Comino müssen die
Benutzer die beiden Portale erst aktivieren, bevor sie im Spiel verwendet
werden können. Dies geschieht mit den Anoto-Stiften direkt auf dem Interface. Durch das Bewegen des Stiftes auf der Seitenfläche kann der Benutzer
die Farbe des zum Portal gehörigen Partikel-Systems verändern. Der Deckel
(a)
50
(b)
Abbildung 5.19: Die sensitive Oberfläche der Türme erlaubt die direkte
Interaktion mit objektrelevanten Parametern im Spiel (a). In Comino kann
über die intelligente Oberfläche das um den Turm projizierte Partikel-System
verändert werden. Sowohl Farbe als auch Richtung der Partikel können mit
den Anoto-Stiften direkt manipuliert werden. Der Screenshot (b) zeigt die
drei Partikel-Systeme (grün, orange und pink) deutlich.
dient als Interaktionsfläche zum Verändern der Richtung. Für jede der Seitenflächen und Deckflächen wurde demnach unterschiedliches Anoto-Pattern
verwendet. Sind die vom Spiel gestellten Anforderungen an Farbe und Richtung des Partikel-Systems erfüllt, so leuchtet auf dem Portal ein zweites LED
auf. Jedes Portal besitzt ein solches LED, das unabhängig von der restlichen
Funktionalität des Portals einund ausgeschaltet werden kann. Abbildung
5.20 veranschaulicht diese Funktionalität.
5.3
Software
Wie auch schon in Abschnitt 4.2.2 beschrieben, kann Arduino autonom von
einem Computer Sensordaten auslesen, interpretieren und mit verschiedenen
Ausgabegeräten darauf reagieren. Für Comino hingegen sollte der ArduinoKontroller direkt mit einem Computer verbunden sein, da das Spiel direkt
mit den Comino-Portalen kommunizieren muss. Somit musste eine Kommunikation umgesetzt werden, die einen flexiblen und schnellen Datenaustausch
zwischen Arduino und Virtools erlaubt. Die Recherche lieferte bereits fertige Implementierungen für verschiedene Entwicklungsumgebungen und Programmiersprachen wie zum Beispiel C, Processing, Max/MSP/Jitter, vvvv
und Phyton.
5.3.1
Kommunikation mit Arduino
Simple Message System: Auch für die Art der Kommunikation gab es
einige fertige Lösungen, die für die Verwendung im Spiel in Betracht gezogen
(a)
51
(b)
Abbildung 5.20: Dem Benutzer können zusätzlich zum projizierten Feedback auch direkt auf dem physischen Spielelement Rückmeldungen zur Interaktion gegeben werden. So bleibt das zweite LED auf dem Portal so lange
dunkel (a), bis der Spieler die notwendigen Aktionen gesetzt hat. Das leuchtende LED (b) zeigt nun an, dass das Portal aktiviert wurde. Im Hintergrund
kann man einen weiteren Spieler bei der Interaktion mit dem zweiten Portal
erkennen.
werden konnten. Die erste angedachte Lösung war die Verwendung einer ASCII basierten Bibliothek, für die es schon Anbindung an andere Programme
gibt. Das Simple Message System 10 wurde für Arduino ab Version 0004 entwickelt und erlaubt es dem Benutzer, Listen von Integers und Characters an
Arduino zu schicken oder von Arduino zu empfangen und zu verarbeiten. Ursprünglich entwickelt für Programme wie Max/Msp oder Pd sollte das Simple Message System für die Anforderungen von Comino angepasst werden.
Der Ansatz der Kommunikation mit dem Simple Message System wurde aber
nicht weiter verfolgt, da ASCII basierende Protokolle einen großen Nachteil
haben. Die Kommunikation mit dem Arduino-Board erfolgt über eine serielle Schnittstelle, was zu Folge hat, dass, um eine schnelle Kommunikation
sicherzustellen, die Übertragung der Daten möglichst schnell und effizient
erfolgen muss. Werden die Nachrichten in ASCII codiert, so ist die Anzahl
an benötigten Bytes um ein Vielfaches höher als bei einem Protokoll, das
Nachrichten auf Bit-Ebene codiert.
Firmata: Die Lösung für mehr Effizienz bei der Datenübertragung war die
Verwendung des Firmata-Protokolls von Hans-Christoph Steiner11 . Firmata
adressiert einige der Probleme von ASCII basierten Protokollen [40].
There are a number of simple, ASCII-based protocols out there
which are generally pretty easy to implement and understand.
10
11
http://www.arduino.cc/playground/Code/SimpleMessageSystem
http://www.arduino.cc/playground/Interfacing/Firmata
52
The problem is that they are very verbose, and the Arduino is
limited to serial rates, so a maximum of 115,200 bits/second. One
example is the Simple Message System for Arduino. It is easy to
read and implement. But it needs 4 bytes to set one digital pin,
56 bytes to set all digital pins. Firmata needs 3 bytes to set one
digital pin or all digital pins.
Firmata, das erst wenige Wochen vor Arbeitsbeginn an der ArduinoKommunikation für Comino veröffentlicht wurde, erlaubt es, die wichtigsten
Funktionen des Arduino-Boards von einem Steuerrechner aus zu kontrollieren. Während bisher für die Verwendung des Arduino-Boards ein maßgeschneidertes Programm auf den Kontroller geladen wurde, erlaubt Firmata
es, die gesamte Programmlogik auf dem Steuercomputer zu implementieren.
Auf dem Arduino-Kontroller läuft nur ein Programm, das entsprechend der
empfangenen Nachrichten den Modus der digitalen Pins ändert und die Einund Ausgänge der Boards liest beziehungsweise schreibt [40].
Basically, this firmware establishes a protocol for talking to the
Arduino from the host software. It allows you to switch pins
from input/output/pwm, and it allows you to read and write, of
course.
In der Entwicklung heißt das für den Benutzer also, dass er sich um die
Verarbeitung auf dem Arduino-Kontroller nicht mehr kümmern muß. Der
Arduino-Kontroller wird zum reinen Ein- und Ausgabegerät, die Verarbeitung kann direkt auf dem Steuerrechner erfolgen.
Das Firmata-Protokoll liegt mittlerweile in überarbeiteten, nicht rückwärtskompatiblen Versionen vor, die Integration der Firmata-Kommunikation in Comino erfolgte jedoch noch mit Version 1.0. Firmata is open source
und die aktuelle Version kann vom Firmata Sourceforge.net Repository12
heruntergeladen werden. Firmata bildet die Grundlage für alle weiteren Anstrengungen, eine flexible und schnelle Kommunikation von Arduino und
Virtools zu implementieren. In den folgenden Abschnitten wird in chronologischer Reihenfolge die Umsetzung dieser Kommunikation beschrieben.
5.3.2
Kommunikation in vvvv
Um die Funktionsweise von Firmata schon im Vorfeld testen zu können,
wurde auf eine bestehende Umsetzung der Kommunikation mit Firmata in
vvvv zurückgegriffen. Die vvvv Umsetzung ist auf der vvvv Webseite13 verfügbar. Der bestehende Firmata vvvv-Patch wurde während der Testphase
12
http://pure-data.cvs.sourceforge.net/pure-data/externals/hardware/arduino/Pd
firmware/Pd firmware.pde?view=markup
13
http://vvvv.org/tiki-index.php?page=arduino05
53
mehrmals abgeändert und schlussendlich gänzlich neu implementiert, um
einige Mängel auszubessern und den Patch an die eigenen Anforderungen
anzupassen.
Die eigene Implementierung diente fortan als Testplattform für die Kommunikation mit Arduino und wurde auch als Designreferenz für die Umsetzung in C++ verwendet. Da in vvvv Änderungen am Programm direkt
sichtbar sind, ohne neu kompilieren zu müssen, ist es die perfekte Testumgebung für Projekte, die eine Menge an Feinabstimmung erfordern und bei
denen Benutzereingaben oft verändert werden müssen.
Mit dem umgesetzten vvvv-Patch war es einfach, die Kommunikation
mit Arduino umfassend zu testen. Eventuelle Probleme und Fehlerquellen,
die später in der C++ Implementierung mit weitaus größerem Zeitaufwand
zu finden gewesen wären, konnten so schon im Vorfeld identifiziert und ausgemerzt werden. Abbildung 5.21 zeigt einen Screenshot des vvvv-Patches.
Der grundlegende Aufbau wurde auch als Referenz für die Umsetzung in
C++ verwendet.
5.3.3
Kommunikation in C++
Basierend auf den Erfahrungen mit Firmata und vvvv wurde als nächster
Schritt die Umsetzung der Kommunikation in C++ begonnen. Die C++ Implementierung der Kommunikation mit Arduino über das Firmata-Protokoll
erfolgte in mehreren, zeitlich getrennten Schritten. Durch die parallele Implementierung in Virtools entstanden immer wieder neue Anforderungen
an die Kommunikation, die dann in Folge eingearbeitet wurden. Grundlage
für die Implementierung in C++ ist die Kommunikation über die serielle
Schnittstelle der JazzUp Library 14 von Jürgen Zauner.
Als erster Schritt wurde eine Applikation umgesetzt, mit der es möglich war, direkt im Quellcode den Modus und Status von Arduino-Pins zu
setzen und zu lesen. Die an den Eingängen ausgelesenen Werte wurden auf
die Windows-Konsole ausgegeben. Als Abbildung des aktuellen Zustands
des Arduino-Boards finden sich in der C++ Implementierung Variablen, die
den Modus und Zustand aller Ein- und Ausgänge auf dem Board repräsentieren. Im Folgenden werden diese Variablen mit dem Begriff Pin-Variablen“
”
referenziert. Codebeispiel 5.1 zeigt die nötigen Variablen in der C++ Implementierung.
Die Variablen analogPins und digitalPins speichern den aktuellen
Status der analogen beziehungsweise digitalen Pins auf dem Arduino-Kontroller. Die Pin-Variable analogReportingCount speichert die Anzahl der
aktiven Eingänge auf dem Kontroller, digitalReportingFlag speichert den
Aktivierungszustand aller digitalen Eingänge. Dies entspricht im Wesentlichen den Werten, die über Firmata auf dem Arduino-Board beeinflusst
14
http://sourceforge.net/projects/jazzup/
Abbildung 5.21: Der Screenshot zeigt den Haupt-Patch der FirmataKommunikation in vvvv. Optisch getrennt durch den vertikalen Balken in
der Mitte beinhaltet der Patch sowohl das Einlesen der Eingänge als auch
das Schreiben der Ausgänge des Arduino-Kontrollers. Oben im Patch sind
die Variablen für Ausgänge des Arduino-Kontrollers angelegt, im unteren Teil
die Eingänge. Die vvvv-Umsetzung diente als Testplattform für die Kommunikation mit Arduino.
54
55
Codebeispiel 5.1: Die Variablen zum Speichern aller wichtigen Zustände
des Arduino-Boards in der C++ Implementierung
# define A R D U I N O _ N R _ O F _ D I G I T A L _ P I N S 14
# define A R D U I N O _ N R _ O F _ A N A L O G _ P I N S 6
int
int
int
int
digitalPins [ A R D U I N O _ N R _ O F _ D I G I T A L _ P I N S ][3];
analogPins [ A R D U I N O _ N R _ O F _ A N A L O G _ P I N S ];
di git al Rep or tin gFl ag [2];
an alo gR epo rt ing Cou nt [2];
werden können.
Die Entwicklung der Kommunikation mit C++ ist im folgenden Teil in
sechs Implementierungsversionen bis zur finalen Implementierung beschrieben. Die einzelnen Abschnitte geben eine kurze Übersicht über gestellte Anforderungen und dafür vorgeschlagene Lösungen bis hin zur fertigen Version.
Sie kommentieren die Arbeit und listen die relevanten Änderungen in chronologischer Reihenfolge auf.
Version 1: Erste lauffähige Version
Das erste lauffähige Programm implementierte das Firmata-Protokoll nach
dem Vorbild der vvvv Implementierung in C++. Erste Tests zeigten jedoch,
dass die erste Umsetzung des Auslesens der Eingänge auf dem ArduinoKontroller die Framerate des Programms dramatisch senkte. In dieser Version wurde bei Bedarf das Auslesen der Eingänge direkt auf dem Board
aktiviert und danach wieder deaktiviert. In der aktiven Phase lieferte das
Board jedoch nicht nur einen einzelnen Wert, sondern Firmata schickte während der gesamten aktiven Zeit die aktuellen Daten an den Rechner. Dabei
füllte sich der Buffer der seriellen Schnittstelle. Nachdem ein Wert verarbeitet wurde, mussten die restlichen Daten aus dem Buffer ausgelesen und
verworfen werden, um unvollständigen Datensätzen und einem Überlaufen
des Buffers vorzubeugen. Diese Vorgehensweise erwies sich aber als zu zeitaufwendig, um in jedem Durchlauf des Programms ausgeführt werden zu
können und wurde deshalb in Version 2 des Programmes überarbeitet.
Version 2: Überarbeitung des Auslesens der Arduino Eingänge
Wie schon im vorigen Abschnitt erwähnt, schickt Firmata die ausgelesenen
Werte in einem durchgehenden Datenstrom und nicht in Datenpaketen. In
der ersten Version wurde für jeden einzelnen Wert die Übertragung aktiviert
und deaktiviert. Dies wurde dahingehend abgeändert, dass das Auslesen der
Arduino-Eingänge nur mehr für längere Zeitabschnitte aktiviert und deak-
56
tiviert wurde. Während der aktiven Zeitabschnitte werden die übermittelten Daten jeden Schleifendurchlauf vom Buffer ausgelesen und die aktuellen
Werte in dafür vorgesehene Pin-Variablen geschrieben. Diese Funktionalität wurde in eine eigene Funktion gekapselt. Bei Bedarf werden die aktuellen Werte nun nicht mehr direkt vom Board, sondern aus den entsprechenden Pin-Variablen ausgelesen. Das Auslesen und Verwerfen der überflüssigen
Werte aus dem Buffer ist durch diesen Ansatz obsolet, da durch kontinuierliches Abarbeiten des Buffers die oben angeführten Probleme nicht auftreten.
Version 3: Abkapseln der Kommunikation von der Übertragungstechnologie
Um das Programm übersichtlicher zu gestalten, wurden im Zuge des nächsten Überarbeitungsschritts alle Firmata-spezifischen Programmteile von denen der verwendeten Übertragungstechnologie getrennt. Konkret wurde die
Verarbeitung von der Übertragung der Daten über die serielle Schnittstelle
getrennt und in verschiedene Funktionen gekapselt. Die Kommunikation
über das Firmata-Protokoll kann so schnell und einfach auf eine andere
Kommunikationstechnologie umgestellt werden! Denkbare Alternativen wären die Kommunikation via TCP oder Bluetooth. Im Fall von Bluetooth
gibt es bereits ein Arduino-Board15 , das diese Art der Kommunikation unterstützt, im Fall von TCP ist die entsprechende Hardware in Arbeit16 .
Version 4: Asynchrones Setzen der Pins
Die parallele Implementierung der Virtools Building-Blocks (vergleiche auch
Abschnitt: 5.3.4) erfordert eine zusätzliche Trennung zwischen dem Setzen
der Pin-Variablen und dem eigentlichen Senden derselben Information an das
Board. Um dies zu bewerkstelligen, wurden zusätzliche Mechanismen eingeführt, die es erlauben, die Pin-Variablen schon im Voraus im Programm zu
setzen, aber erst zu einem späteren Zeitpunkt mit dem Board zu synchronisieren. Somit können in Virtools schon im Vorfeld Werte auf dem ArduinoBoard gesetzt werden, die aber erst nach dem Starten der Anwendung mit
dem Board synchronisiert werden. Dies erlaubt es auch, Befehle geblockt an
Arduino zu schicken.
Version 5: Eigener Thread für das Einlesen der Daten
In der fünften Version der Kommunikation mit dem Arduino-Board wurde
das Auslesen der Werte an der seriellen Schnittstelle neuerlich überarbeitet.
Das bisherige Aufrufen der Lesefunktion in der Hauptschleife des Programmes hatte zur Folge, dass bei einer zu langsamen Ausführung der Buffer der
15
16
http://www.arduino.cc/en/Main/ArduinoBoardBluetooth
http://tinker.it/now/2007/06/06/the-arduino-ethernet-board/
57
seriellen Schnittstelle überlaufen konnte. Deshalb wurde das Auslesen der
Eingänge im Programm in einen eigenen Thread ausgelagert. Nach dem Initialisieren der Kommunikation mit Arduino wird der Thread gestartet und
übernimmt fortan parallel zum Hauptprogramm das Auslesen der Werte.
Als direkte Folge dieser Umstellung können bei dieser Lösung sehr rasche
Änderungen an den Eingängen verloren gehen, da der auslesende Thread die
Pin-Variablen einfach überschreibt, unabhängig davon, ob diese jemals ausgelesen wurden oder nicht. Dieses Problem kann in der Praxis für die Verwendung in Comino jedoch vernachlässigt werden, da es sich dabei üblicherweise
um Änderungen von einer Dauer kleiner der Framerate des Hauptprogrammes, also üblicherweise kleiner 1/50 Sekunde handeln muss. Spielrelevante
Änderungen mit dieser Zeitspanne treten in Comino im Normalfall nicht auf.
Version 6: Überarbeitung des Verbindungsaufbaus
Für die letzte beschriebene Änderung an der C++ Implementierung war
wieder eine Anforderung des Virtools-Building-Blocks der Ausgangspunkt.
Für Virtools sollte es möglich sein, den COM-Port der seriellen Schnittstelle
auch nach dem Initialisieren der Kommunikation zu ändern. Somit wurde
Programmfunktionalität hinzugefügt, die es erlaubt, während der laufenden Virtoolsanwendung die Kommunikation mit dem Arduino-Kontroller zu
schließen und mit neuen übergebenen Werten wieder zu etablieren. Zusätzlich wurde im Zuge dieser Umbauten auch das Synchronisieren der PinVariablen in einen eigenen Thread ausgelagert.
5.3.4
Kommunikation in Virtools
Virtools Erweiterungen
Parallel zur Programmierung der Konsolen-Anwendung in C++ wurde auch
mit der Integration von eigener Funktionalität in Virtools begonnen. Erweiterungen für Virtools können mit dem mitgelieferten Software-DevelopmentKit (SDK) entwickelt werden. Eigene Programmfunktionalität wird dabei
als neuer Building-Block (BB) umgesetzt. Für die Erstellung von eigenen
Building-Blocks stellt Virtools einen Microsoft Visual Studio 17 Assistenten
zu Verfügung, der ein vorkonfiguriertes Visual Studio Projekt erstellt und
bereits die zu erweiternden Funktionen anlegt.
Der folgende Abschnitt fasst die wichtigsten Informationen zu den implementierten Building-Blocks zusammen, gibt jedoch keine allgemeine Anleitung für die Erstellung eigener Building-Blocks. Informationen zum Erstellen von eigenen Building-Blocks finden sich in der auf der Virtools CD
mitgelieferten Dokumentation des SDKs [44] und werden hier nicht weiter
behandelt.
17
http://msdn2.microsoft.com/en-us/vstudio/default.aspx
58
Codebeispiel 5.2: Die vier Funktionen sind wesentlich für die Umsetzung
eigener Building-Blocks
/* Fill */
CKObj ectDecl aration
* FillMyBBDecl ();
/* Create */
CKERROR CreateMyBBProto ( CKBehav iorProt otype **);
/* Execute */
int Execute ( const CKBehaviorContext & BehContext );
/* Callback */
int CallBack ( const CKBehaviorContext & BehContext );
In Codebeispiel 5.2 sind vier Funktionen aufgelistet, die für die weitere Beschreibung der Realisierung der Building-Blocks wichtig sind. Ihre
Bedeutung wird kurz allgemein erläutert und dann bei der danach folgenden Beschreibung der eigenen Building-Blocks ergänzt. Die Benennung der
Funktionen unterliegt gewissen Nameskonventionen, die sich aus dem Namen
des Building-Blocks, in diesem Fall MyBB“, und Erweiterungen ergibt. In
”
weiterer Folge werden stellvertretend für den Funktionsnamen die im Code
auskommentierten, vorangestellten Bezeichnungen Fill, Create, Execute und
Callback verwendet. Im Anschluss daran finden sich die Beschreibungen der
zwei implementierten Building-Blocks.
Fill: In der Fill-Funktion werden allgemeine Informationen zum BuildingBlock angegeben, die für die Verwaltung vom Building-Block verwendet werden. Dies inkludiert Informationen, die rein für die interne Verwendung in
Virtools nötig sind, wie zum Beispiel eine eindeutige Identifikationsnummer, aber auch Informationen für Benutzer wie eine Kurzbeschreibung des
Building-Blocks.
Create: In der Create-Funktion des Building-Blocks wird spezifiziert, welche Behavior Ein- und Ausgänge der Building-Block haben wird und welche
Parameter Ein- und Ausgänge angelegt werden sollen. Hier wird festgelegt,
ob der Benutzer den BB später verändern kann, ob spezielle Einstellungen
vorgenommen werden können oder ob die Anzahl der Ein- oder Ausgänge
des BB veränderbar sind. In dieser Funktion wird des Weiteren auch die
Execute- und die Callback-Funktion des Building-Blocks festgelegt.
59
Execute: Die Execute-Funktion beinhaltet die eigentliche Funktionalität
des Building-Blocks. Hier wird für jeden Eingang eine Programmroutine
festgelegt, die Parameter einlesen, verarbeiten und wieder ausgeben kann.
Je nachdem welcher Eingang aktiviert wurde, können so verschiedenen Funktionen in einem Building-Block gekapselt werden und bei Bedarf gezielt
aktiviert werden. Nach dem Verarbeitungsschritt können dann einer oder
mehrere Ausgänge des Building-Blocks aktiviert werden.
Callback: Die Callback-Funktion wird beim Auftreten von speziellen Ereignissen, für die der Building-Block in der Create Funktion angemeldet
werden muss, aufgerufen. Beispiele für solche Ereignisse sind das Hinzufügen des BB zu einem Skript, das Starten des Levels oder das Löschen des
BBs. In der Callback-Funktion befinden sich alle Programmteile, die mit der
internen Verwaltung der Variablen und Recourcen des BBs zu tun haben.
Arduino-BB
In diesem Abschnitt wird die konkrete Umsetzung des Building-Blocks für
die Kommunikation mit Arduino, im weiteren Verlauf Arduino-BB genannt,
erläutert. Der Arduino-BB verpackt die in Abschnitt 5.3.3 beschriebene
C++ Implementierung des Firmata-Protokolls in einer dynamic link li”
brary“ (DLL), die beim Start von Virtools geladen wird. Alle Funktionen der
C++ sind direkt in Virtools verfügbar. Wird ein Virtools Projekt, das einen
Arduino-BB beinhaltet, so stellt dieser eine Verbindung mit dem ArduinoBoard her und erlaubt es nunmehr, benutzergesteuert Ausgänge am ArduinoBoard zu setzen und Eingänge einzulesen. Abbildung 5.22 zeigt die grafische
Ansicht des Arduino-BB in einem Beispiel-Skript in Virtools.
Bei den von 1.)“ bis 8.)“ durchnummerierten hellgrauen Blöcken han”
”
delt es sich um Hilfsobjekte, die bei der Beschreibung der Funktionsweise
helfen sollen. Die Funktionsweise des Arduino-BB wird anhand des BeispielSkripts in Absatz 5.3.4 erklärt. Der Ablauf des Beispiels geschieht in der
Reihenfolge der durchnummerierten Blöcke und inkludiert alle Funktionen
des Arduino-BBs. Die Eingänge des Arduino-BBs können natürlich in anderen Skripten nach eigenem Bedarf und zu beliebigen Zeitpunkten aktiviert
werden.
Der Arduino-BB ist bis zum Start des Virtools Projektes inaktiv. Die
Aktivierung erfolgt erst nach dem Starten und der BB ist ab diesem Zeitpunkt einsatzbereit. Sollten Änderungen für die serielle Kommunikation nötig sein, so kann der BB während der laufenden Anwendung neugestartet
werden. Dies wird im folgenden Beispiel gemacht, ist aber nicht in jedem
Fall zwingend notwendig.
Beispielverwendung: Der Block mit der Bezeichnung 1.) (Block 1) wird
in diesem Beispiel als Erster nach der Aktivierung des Skripts durchlau-
60
Abbildung 5.22: Der Arduino Building-Block in einem Beispiel-Skript. Die
Parametereingänge an der Oberseite dienen zum Setzen von Werten, die Parameterausgänge an der Unterseite zum Auslesen von Werten vom Arduino
Board. Links befinden sich die drei Behavior-Eingänge, deren Aktivierung
verschiedene Aktionen des Arduino-BB auslöst und die nach dem Verarbeitungsschritt den jeweils gegenüberliegenden Behavior-Ausgang aktivieren.
fen. Er aktiviert den obersten der drei Behavior-Eingänge des Arduino-BBs.
Es handelt sich dabei um den Reset-Eingang, der die Kommunikation neu
initialisiert. Die Verbindung über die serielle Schnittstelle wird mit den aktuellen Werten für COM-Port und BAUD-Rate neu gestartet. Dafür ist es
notwendig, die beiden Threads zum Auslesen und Synchronisieren der Einbeziehungsweise Ausgänge des Arduino-Boards vorher zu beenden und ebenfalls neu zu starten. Nach dem der Reset-Vorgang abgeschlossen ist, wird der
aktuelle Zustand aller Eingangsparameter mit dem Arduino-Board synchronisiert und der gegenüberliegende Ausgang aktiviert. Der Arduino-BB ist
nun wieder bereit für die Verwendung.
Im Beispiel-Skript wird das Signal nun durch die Blöcke 2 und 3 an die
Eingänge des Arduino-BBs zurück. Nach der Verarbeitung von Block 4 aktiviert dieser den Update-Eingang des Arduino-BBs. Die Update-Funktion
liest die aktuellen Werte aller aktiven Eingänge aus den entsprechenden Pin-
61
Variablen aus und schreibt sie in die Ausgabe-Parameter des Virtools Building Blocks. In der Abbildung sind die Ausgabe Parameter, durch blaue Linien verbunden, unter dem Building-Block sichtbar. Die eingelesenen Werte
stehen nun für die weitere Verarbeitung zur Verfügung. Ist der UpdateSchritt abgeschlossen, so wird der zugehörige Ausgang aktiviert, der durch
Block 5 den Signalfluss nun aufspaltet. Zum Ersten wird Block 3 reaktiviert
und so eine Rückkopplung gestartet, die ab jetzt jeden Skript-Durchlauf den
Update-Eingang aktiviert und die aktuellen Werte der Arduino-Ausgänge
ausliest.
Zum Zweiten wird Block 6 aktiviert, der ebenfalls das Signal zu den
Eingängen das Arduino-BBs zurückführt. Durch Block 7 wird der Synchronize-Eingang aktiviert. Die Synchronize-Funktion liest alle Parameter Eingänge des Arduino-BBs aus und synchronisiert die Werte mit den Arduino
Ausgängen. Somit können LEDs einund ausgeschaltet oder Servomotoren bewegt werden. Nach Beendigung des Schrittes wird Block 8 durch den
Synchronize-Ausgang aktiviert. Das Beispiel-Skript hat nun alle Stationen
durchlaufen.
Die folgende Auflistung der drei Behavior-Eingänge und der Kurzbeschreibungen (in Klammer) der jeweiligen Funktionen, dient als Übersicht
über die Funktionsweise des Arduino-BBs.
• Reset-Eingang (Neustart von serieller Kommunikation und Threads)
• Update-Eingang (Einlesen der Arduino-Eingänge; Setzen der Parameter-Ausgänge des BBs)
• Synchronize-Eingang (Einlesen der Parameter-Eingänge des BBs; Setzen der Arduino-Ausgänge)
Alle für die Kommunikation relevanten Einstellungen kann der Benutzer
über den Einstellungsdialog des Arduino-BBs festlegen. So kann zum Beispiel definiert werden, welche der digitalen Pin als Eingänge benötigt werden
und welche Ausgang sein sollen. Es kann festgelegt werden, wie viele der
analogen Eingänge aktiviert sind und ob die digitalen Eingänge Werte aktiv
sind oder nicht. Alle benötigten Parameter Eingänge und Ausgänge werden gemäß den vorgenommenen Einstellungen automatisch am Arduino-BB
sichtbar gemacht oder versteckt. Abbildung 5.23 zeigt den Einstellungsdialog
des Arduino-BBs, der in Abbildung 5.22 sichtbar ist.
Anoto-BB
Der zweite Building Block (Anoto-BB) wurde für die direkte Integration
der Anoto-Stifte in Virtools implementiert. Aufgesetzt wurde bei der Entwicklung auf bereits bestehende Software, die im Rahmen des Office Of
”
Tomorrow“18 Projekts entwickelt wurde. Im Wesentlichen handelt es sich
18
http://www.officeoftomorrow.org/
62
Abbildung 5.23: Screenshot des Einstellungsdialogs des Arduino-BBs. Er
ermöglicht die Einstellung aller für die Kommunikation mit Arduino relevanten Parameter.
bei der Umsetzung um die Adaption eines UDP-Empfängers, der alle wichtigen Stiftdaten empfängt und der für die Verwendung in Virtools in einen
Building-Block gekapselt wurde. Der Anoto-BB funktioniert nur in Kombination mit einem bereits verfügbaren UPD-Sender (Anoto-Sender), der für
die Verwendung mit Comino nicht verändert werden musste.
Abbildung 5.24 zeigt die grafische Ansicht des Anoto-BBs in Virtools.
Der Anoto-BB ist in der Grafik ebenfalls in ein Beispiel-Skript integriert. Die
mit den Parametereingängen verbundenen Variablen oberhalb des AnotoBBs bezeichnen die Identifikationsnummeren (IDs) der verwendeten Stifte.
Stimmt eine der benutzerdefinierten Stift-IDs mit einer der Stift-IDs eines empfangenen Datenpaketes überein, so werden die Werte gespeichert.
63
Abbildung 5.24: Der Anoto-Building-Block in einem Beispiel-Skript.
Kommt das empfangene Datenpaket von einem Stift, der nicht angegeben
ist, so wird das Datenpaket verworfen. Die intern gespeicherten Stiftwerte
werden bei der Aktivierung vom Anoto-BB in die Parameter-Ausgänge geschrieben und sie sind somit innerhalb von Virtools weiter verwendbar.
Beispielverwendung: Im Gegensatz zum Arduino-BB wird die Verbindung mit dem Anoto-Sender schon beim Öffnen des Virtools-Projektes initialisiert und nicht erst beim Start. Dies hat den Vorteil, dass auch ohne
laufende Anwendung die Funktion des Stiftes sowie die Kalibrierung der
Anoto-Menüs getestet werden kann. Auch vor dem Start des Virtools-Skripts
kann der Stift bereits Werte liefern, die ähnlich wie die Werte des ArduinoBoards in eine Hilfsdatenstruktur abgespeichert werden. Beim Start des
Virtools-Skripts wird also, nachdem Block 1 abgearbeitet wurde, der Update-Eingang des Anoto-BB aktiviert. In der Update-Funktion werden die
aktuellen Stiftwerte aus der Hilfsdatenstruktur ausgelesen und damit die
Parameterausgänge entsprechend gesetzt. Nach dem Setzen der Parameter
aller aktivierten Stifte wird der Update-Ausgang aktiviert, der wiederum
weitere Funktionalität, in diesem Fall Block 2, aktivieren kann. Im BeispielSkript reaktiviert Block 2 den Anoto-BB im nächsten Durchlauf wieder, was
zu einem kontinuierlichen Auslesen der aktuellen Stiftwerte führt.
64
Abbildung 5.25: Screenshot des Einstellungsdialogs des Anoto-BuildingBlocks. Hier kann der Benutzer die Anzahl der Stifte festlegen und sich zusätzliche Informationen auf der Virtools-Konsole ausgeben lassen.
Wie auch der Arduino-BB bietet auch der Anoto-BB dem Benutzer gewisse Einstellungen. Abbildung 5.25 zeigt den Einstellungsdialog des AnotoBBs. Er erlaubt dem Benutzer, die Anzahl der verfügbaren Stifte festzulegen.
Die maximale Anzahl liegt derzeit bei vier Stiften, was der Anzahl der Stifte
in Comino entspricht. Es ist jedoch möglich, ohne größeren Aufwand, bei
Bedarf die Anzahl der Stifte zu erhöhen. Dies muss natürlich im Sourcecode des Anoto-BB geschehen. Des weiteren kann über den Einstellungsdialog auch eine textuelle Ausgabe aller empfangener Anoto-Stift Werte auf
die Virtools-Konsole aktiviert werden. Diese Ausgabe funktioniert auch im
nicht gestarteten Zustand des Projektes und erlaubt das Testen der Stiftkommunikation sowie das Auslesen von verschiedenen Regionen auf einem
Anoto-Interface. Abbildung 5.26 zeigt die Virtools-Konsole mit einer Reihe
von Stift-Datensätzen bestehend aus einem Koordinatenpaar, der Druckstärke, der aktuellen Region auf dem Papier und der jeweiligen Stift-ID.
5.4
Umsetzung in Virtools
Im folgenden Abschnitt werden die wichtigsten Teile der Umsetzung von
Comino in Virtools beschrieben. Der Abschnitt ist in Abschnitte unterteilt,
die die Implementierungsphasen chronologisch wiedergeben. Größere Teilbereiche der Umsetzung, deren Realisierung sich über längere Zeit erstreckte
und die sich mit anderen Teilen überschneiden, werden zum Zeitpunkt des
Arbeitsbeginns an dem jeweiligen Teilbereich in die Reihung eingegliedert.
5.4.1
Erste Schritte
Nach einer zweiwöchentlichen Einarbeitungsphase in Virtools, in der schwerpunktmäßig die von Virtools mitgelieferten Tutorials durchgenommen wurden, wurde mit der Arbeit an Comino begonnen. Abbildung 5.27 zeigt den
Entwicklungsstand des Spieles nach drei Tagen. Die gezeigte Version beeinhaltete bereits Mausinteraktion, Physiksimulation und diverse grafische
Effekte wie Texturen, Schatten und Spiegelungen. Mit gedrückter linker
Maustaste lassen sich in dieser Version auf der Grundfläche Dominosteine
platzieren. Physikalische Interaktion konnte bereits erzwungen werden, wenn
65
Abbildung 5.26: Ausgaben des Anoto-BBs auf der Konsole. Auch während das Projekt nicht gestartet ist, kann der Benutzer hier Informationen
zum Stift und seiner aktuelle Position auf dem Anoto-Pattern in Erfahrung
bringen, sofern diese Funktion im Einstellungsdialog des Anoto-BBs aktiviert
ist.
zwei Dominosteine einander überschneidend platziert wurden. Die Physiksimulation lässt die Überscheidung nicht zu und katapultiert die beiden Steine
je nach Überschneidung mehr oder weniger stark auseinander. Da die Umsetzung in Virtools auch grafisch ansprechend sein sollte, wurde bereits in
einer sehr frühen Entwicklungsphase mit der Integration von grafischen Effekten begonnen, die zum Teil auch in der finalen Version von Comino noch
zum Einsatz kommen.
5.4.2
Interaktionstechniken
Auch das Grundprinzip des Aufstellens der Dominosteine ist im ersten Prototypen bereits enthalten. Das Design der Interaktion der Spieler mit Comino war eine der zeitaufwendigsten Aufgaben und durchlief viele Änderungen bis zur finalen Version des Spieles. Die Erweiterung der Benutzerinteraktion war bereits der zweite Teilbereich von Comino, der in Angriff genommen
wurde und auch einer der letzten Bereiche, der fertiggestellt wurde. Während
das Erstellen und Umstoßen zu Testzwecken bereits zu Beginn implementiert
wurde, wurden die Interaktionsmodi Löschen und Verschieben erst nach der
Integration des Anoto-Stiftes implementiert. Erst nach den ersten Tests des
Spiels mit mehreren Benutzern wurden mit den erhaltenen Rückmeldungen
die finalen Interaktionstechniken festgelegt und in Comino integriert. Details
zur fertigen Interaktion mit den Dominosteinen finden sich in Abschnitt 3.4.
66
Abbildung 5.27: Der Screenshot zeigt den Entwicklungsstand nach zwei
Wochen. Der Prototyp beeinhaltet bereits Mausinteraktion, Physiksimulation und Grafikeffekte wie Spiegelungen und Schatten.
5.4.3
3D-Modelle
Um die grafische Komplexität der Level zu erhöhen, wurden im nächsten
Schritt eigene 3D-Modelle erstellt und in Virtools importiert. Abbildung 5.28
zeigt einen ersten Test eines selbst erstellten Levels. Neben der Modelle für
den zweiten und dritten Level wurden Dominoblöcke sowie die drei Portale
modelliert und texturiert. Die drei finalen Comino Levels sind in Abschnitt
5.5 noch detailierter beschrieben.
In Abbildung 5.29 sind am Beispiel eines Dominosteines die einzelnen
Schritte bis zum fertigen Modell aufgelistet. Die realen Dominosteine wurden vermessen und als Materialreferenz abfotografiert. Aus den Referenzfotos wurden in Adobe Photoshop19 dann Texturen erstellt, die auf die in
Autodesk Maya20 erstellten, stark vereinfachten Modelle des Dominosteins
aufgetragen wurde. Mithilfe des Virtools Exporters21 für Maya wurden die
texturierten Modelle dann in einem für Virtools lesbaren Format gespeichert
und in Comino integriert.
Im Zuge der Integration von eigenen Levels wurden auch verschiedene
Ansätze für die Physiksimulation getestet. In Virtools kann für die Physiksimulation eines Objektes die eigentliche 3D-Geometrie des Objektes verwendet werden, eine das Objekt umschließende konvexe Hülle oder nur eine
das gesamte Objekt beinhaltende Kugel. Als zusätzliche Alternative können
auch eine oder mehrere Ersatzgeometrien, die im Level nicht sichtbar sein
19
http://www.adobe.com/products/photoshop/index.html
http://usa.autodesk.com/adsk/servlet/index?siteID=123112&id=7635018
21
http://www.virtools.com/support/downloadList.asp (Zugang nur mit Registrierung)
20
67
Abbildung 5.28: Um die Level vielfältiger gestalten zu können wurden
eigene 3D-Modelle erstellt und in Virtools importiert.
(a)
(b)
(c)
(d)
Abbildung 5.29: Die in Comino verwendenten virtuellen Domino Steine
wurden den ebenfalls in Spiel integrierten realen Dominosteinen nachempfunden. Aus Referenzfotos (a) der Dominosteine wurde eine Textur erstellt
(b), die dann auf ein Modell (c) aufgebracht wurde. Das Modell samt Textur
wurde dann in Virtools importiert (d).
müssen, verwendet werden. Vor allem bei komplexen Objekten empfiehlt es
sich, statt der eigentlichen Geometrie eine Ersatzgeometrie zu verwenden, da
sonst die aufwendigere Kollisionsberechnung die Simulation verlangsamen
kann. Für die importierten Geometrien wurden einige Test durchgeführt,
um die Geschwindigkeit der Simulation zu vergleichen. Abbildung 5.30 zeigt
die getesteten Alternativen. Für das gezeigte Objekt war in den Test kein
wesentlicher Geschwindgkeitsunterschied bemerkbar, was dazu führte, dass
die Geometrie selbst für die Physikberechnung verwendet wurde. Im dritten
Level jedoch war das Untergrundobjekt nicht für die Physiksimulation geeignet, was dazu führte, dass Ersatzgeometrien erstellt und verwendet wurden.
(a)
(b)
68
(c)
Abbildung 5.30: Für die Physiksimulation von Objekten (a) kann unter
anderem die eigentliche Geometrie (b) oder eines oder mehrere Ersatzobjekte
(c) verwendet werden.
White 2 Output
White 2 PWM
Black 1 Output
Black 1 Input
Abbildung 5.31: Die mittleren beiden Mini-Din Buchsen verbinden die
Comino-Portale mit der Sensorbox. Diese ist über USB mit dem Computer
verbunden. Im Arduino-BB werden die Werte ausgelesen und in die entsprechenden Variablen geschrieben.
5.4.4
Arduino-Integration
Die Intergration des Arduino-BBs und das Testen desselben war einer der
nächsten großen Entwicklungsschritte. Da der Arduino-Kontroller für das
Spiel in die Sensorbox verbaut wurde (Vergleiche 5.2.3), wurden auch die
Variablen in Virtools entsprechend der Anschlüsse der Sensorbox benannt.
Die Comino-Portale benötigen nur zwei der acht Anschlüsse der Sensorbox.
Das R2V-Portal, das als Ein- und Ausgabegerät funktioniert, wird an die
innere der beiden schwarze Buchsen (Vergleiche Abbildung 5.31) angeschlossen. Das V2R-Portal, bei dem es sich um ein Ausgabegerät handelt, wird an
der inneren weißen Buchse an die Sensorbox angeschlossen.
Über die Variable Black 1 Output kann die Ausgabe-LED von R2V
einund ausgeschaltet werden, die Variable Black 1 Input speichert den
aktuellen Wert, den die Lichtschranke im Portal liefert. White 2 Output
steuert die LED von V2R und White 2 PWM den eingebauten Servomotor,
der für das Umstoßen von realen Dominosteinen verwendet wird.
Die Integration des Arduino-BBs und der Portale in Comino wird anhand
eines illustrierten Beispiels erklärt. In Abbildung 5.32 ist ein Beispielszenario
dargestellt, in dem von der realen auf die virtuelle und wieder zurück auf
die reale Spielfläche gewechselt wird. Der Wechsel kann natürlich auch in
R2V-Portal
69
V2R-Portal
Realer
Dominostein
Tischoberfläche
Virtueller
R2V-Domino
Virtueller Dominostein
Virtueller
V2R-Domino
Abbildung 5.32: Eine schematische Ansicht des Beispielszenarios, das die
Integration der beiden Portale im Spiel illustriert. Jedes der beiden realen
Portale wird in der virtuellen Welt durch einen speziellen Portal-Dominostein
repräsentiert. Über diesen Stein erfolgt die Interaktion der Portale mit den
virtuellen Dominosteinen.
umgekehrter Reihenfolge erfolgen. Die Abbildung zeigt sowohl reelle als auch
virtuelle Dominosteine in einer schematischen Seitenansicht. Die virtuellen
Dominosteine sind strichliert umrahmt und sind unter der Tischoberfläche
dargestellt, um eine klare Unterscheidung von den realen Dominosteinen
gewährleisten zu können. Jedes der beiden Portale ist in der virtuellen Welt
mit einem speziellen Dominostein verbunden, die an vordefinierten Stellen
im Level aufgestellt sind und deren Position vom Spieler nicht verändert
werden kann. Die Position dieser Portal-Dominosteine indiziert auch die
Position der Portale auf der Tischoberfläche, die von den Spielern genau
über den projizierten Portal-Steinen platziert werden sollten.
In diesem Beispiel wird die Kettenreaktion mit den realen Spielsteinen
gestartet. Zu Beginn ist die Infrarot-Lichtschranke des R2V-Portals nicht unterbrochen, die anliegende Spannung am Arduino-Kontroller liefert für den
Eingang einen Wert, der über 90022 liegt. Dieser Wert wird an Virtools 60
Mal pro Sekunde übertragen und in die Variable Black 1 Input geschrieben. Kommt ein realer Dominostein in der Lichtschranke zum Liegen, so
wird die Sichtverbindung unterbrochen. Am Eingang liegt jetzt ein Wert an,
der unter 20 liegt. Der Wert wird an Virtools übertragen, wo jeder Wert der
Variable Black 1 Input, der kleiner als 50 ist, einen virtuellen Physikimpuls auslöst. Der Impuls wird an den Portal-Dominostein des R2V-Portals
gegeben und bringt diesen zu Fall. Abbildung 5.33 (a) stellt den Übergang
noch einmal grafisch dar.
Das Umstoßen des ersten virtuellen Steins löst nun eine Kettenreaktion
bei den virtuellen Dominosteinen aus, die sich bis zum Portal-Dominostein
des V2R-Portals fortsetzt. Für diesen speziellen Dominostein wird in Virtools laufend überprüft, ob er noch aufrecht steht, oder ob er umgefallen ist.
22
Der analog-digital Wandler des Arduino-Kontroller liefert Werte zwischen 0 und 1023.
70
Lichtschranke
unterbrochen
Virtueller Impuls
an R2V-Domino
(a)
Reeller Impuls
an Dominosteine
V2R-Domino
umgefallen
(b)
Abbildung 5.33: Ein Unterbrechen der Lichtschranke löst einen virtuellen
Impuls aus, der den ersten virtuellen Portal-Dominostein umstößt (a). Die
daraufhin ausgelöste Kettenreaktion bringt den zweiten Portal-Dominostein
zu Fall, was wiederum die Rückwärtsbewegung des Schwenkarms (b) des
Portals auslöst.
Konkret wird dabei überprüft, ob die Y-Komponente23 des normalisierten
Up-Vektors des Domino Steins einen gewissen Wert unterschreitet. Ist dies
der Fall, wird in einer Schleife der Wert der Variable White 2 PWM schrittweise von 1 auf 0 reduziert. Zusätzlich wird der neue Wert jeden Schleifendurchlauf mit dem Arduino-Kontroller synchronisiert. Dies führt dazu,
dass der Schwenkarm sich nach hinten bewegt, und dabei virtuelle Dominosteine umstößt. Nach einer absichtlichen Verzögerung von zwei Sekunden
wird der Schwenkarm dann in seine Ausgangsposition zurückgefahren. Abbildung 5.33 (b) illustriert den Übergang von der virtuellen Spielfläche auf
die reale.
5.4.5
Anoto-Integration
Bisher war die Interaktion mit Comino ausschließlich über die Portale und
mit der Maus möglich. Als Haupteingabegerät sollten jedoch mehrere AnotoStifte dienen, denen die Tischfläche als Eingabeoberfläche dient. Deshalb
wurde als nächster Schritt die Maus durch einen Anoto-Stift ersetzt. Bei
23
Y-Achse ist in Virtools die vertikale Achse, also normal stehend zur Spielfläche von
Comino.
71
Abbildung 5.34: Die Tastenbelegung der Maus in Comino. Die Anzahl der
auslösbaren Aktionen ist durch die Anzahl der Tasten beschränkt.
der Verwendung einer Maus, kann das Wechseln zwischen verschiedenen
Aktionen durch das Gedrückthalten von verschiedenen Tasten geschehen.
Abbildung 5.34 zeigt die Tastenbelegung der Maus im Spiel.
Bei der Verwendung von Anoto-Stiften muss dieses Wechseln zwischen
den verschiedenen Interaktionsmodis mithilfe des Anoto Menüs erfolgen.
Dies verlangsamt zwar das Umschalten zwischen den einzelnen Aktionen,
hat aber den Vorteil, dass man nicht wie bei der Maus durch die limitierte
Anzahl der verfügbaren Tasten auf wenige Aktionen beschränkt ist. Somit
können im Anoto Menü auch weitere Menüpunkte untergebracht werden,
die ansonsten über die Tastatur ausgelöst werden müssten. Der Umstieg von
Maus auf Stift erforderte intern eine Neustrukturierung der gesamten Verwaltung der Eingabegeräte. Um nach der Umstellung auf die Anoto-Stifte die
Maus auch weiterhin verwenden zu können, wurde versucht, eine einheitliche
Kapselung für alle Eingabegeräte umzusetzen. Es wurden vier EingabegerätVariablen festgelegt, die die relevanten Informationen eines Eingabegeräts
speichern. Die besagten Variablen sind:
• Aktion
• Zustand
• Position
• Druck
Die Aktion bezeichnet den zuletzt ausgewählten Interaktionsmodus, die
für das jeweilige Eingabegerät gewählt wurde. In Comino sind Werte für
alle verfügbaren Aktionen vordefiniert, wie zum Beispiel für das Aufstellen, Löschen, Verschieben oder Umstoßen von Dominosteinen. Der Wechsel
zwischen den verschiedenen Aktionen erfolgt bei den Stiften mithilfe der
Anoto-Menüs, bei der Maus durch das Gedrückthalten verschiedener Tasten.
Der Zustand beschreibt, ob das Eingabegerät gerade aktiv ist oder nicht.
Für die Maus heißt das, ob gerade eine der Tasten gedrückt wird, für den
72
Abbildung 5.35: Im Eingabe-Skript werden die empfangenen Werte aller Eingabegeräte für die weiter Verwendung aufbereitet und danach in die
Eingabegerät-Variablen geschrieben. Die Abbildung zeigt die Funktionsgraphen für die Anoto-Stifte, die Maus und die Tastatur.
Stift, ob er momentan über Anoto-Papier bewegt wird. Für den Wert der
Variable Druck wird beim Stift die jeweilige Druckstärke ausgelesen, der entsprechende Wert bei der Maus wird aus der Rotationsgeschwindigkeit des
Mausrades errechnet. Die Position speichert üblicherweise Bildschirmkoordinaten, im Fall der Anoto-Stifte kann es sich bei den gespeicherten Werten
aber auch um eine Position auf einem der gedruckten Anoto-Menüs handeln.
Je nach Typ des Eingabegeräts werden die Variablen unterschiedlich
ausgelesen und gesetzt, die weitere Verarbeitung ist dann jedoch für jedes
Eingabegerät identisch . Nach dem Auslesen und der Erstverarbeitung der
Werte der Eingabegeräte wird in Comino also nicht mehr zwischen MausInteraktion und Stift-Interaktion unterschieden. Abbildung 5.35 zeigt einen
Teil des Eingabe-Skripts, in dem die Eingabegerät-Variablen gesetzt werden.
Die weitere Verarbeitung der von den Eingabegeräten kommenden Werte
passiert im Interaktions-Skript (Vergleiche Abbildung 5.36). Das Interaktions-Skript definiert, wie mit den einzelnen Komponenten in Comino interagiert werden kann. Jede Mögliche Interaktion mit einem Dominostein ist in
diesem Skript definiert. Das Interaktions-Skript existiert für jedes Eingabegerät genau einmal und verarbeitet die Eingabegerät-Variablen des jeweiligen Eingabegerätes, die im Eingabe-Skript gesetzt werden.
73
Abbildung 5.36: Die Abbildung zeigt das Interaktionsskript in fünffacher
Ausführung. Für jedes verwendbare Eingabegerät muss eine Kopie dieses
Skriptes existieren, das ausschließlich die Werte dieses Eingabegerätes verarbeitet. Eines der Skripte ist in einer Detailansicht dargestellt. Sie zeigt die
Graphen, die die Funktionalität für das Aufstellen, Umstoßen, Verschieben
und Löschen von Dominosteinen kapseln.
5.4.6
Level Organisation
Die Verwaltung von verschiedenen Comino-Levels funktioniert in Virtools
über den Level-Manager. Ein einzelner Level wird in Virtools als Szene bezeichnet. Für Comino wurden insgesamt fünf Szenen angelegt. Neben den
drei Szenen, die die eigentlichen Spiel-Aufgaben beinhalten, wurden zwei zusätzliche Szenen für die Eingangssequenz (Intro) und die Ausgangssequenz
(Outro) des Spiels angelegt.
Während der Entwicklungsphase wurden die drei 3D-Szenen in Virtools
nebeneinander erstellt. Abbildung 5.37 zeigt alle drei Levels im 3D-Editor
von Virtools. Das gleichzeitige Betrachten aller Objekte ist jedoch nur in der
Entwicklungsumgebung möglich. Für das Spiel werden die einzelnen Objekte
verschiedenen Szenen zugewiesen. Für jede Szene wird definiert, durch wel-
74
Abbildung 5.37: Im 3D-Raum sind die Objekte der Comino Level nebeneinander angeordnet. Beim Laden eines Spiel-Levels werden nur die der entsprechenden Virtools-Szene zugewiesenen Objekte angezeigt, der Rest wird
nicht gerendert.
che Kamera die virtuelle 3D-Welt betrachtet wird, welche Objekte in der
Szene sichtbar sind und welche Skripts laufen sollen. Alle weiteren Objekte
und Skripts werden deaktiviert, benötigen zur Laufzeit keine weiteren Ressourcen des Systems.
Auch die verschiedenen Skripts, die in den jeweiligen Szenen gestartet
werden müssen, wurden nach Szenen angeordnet, um die Übersicht bewahren zu können. Dabei muss noch eine grundlegende Unterscheidung zwischen
verschiedenen Arten von Skripts getroffen werden. Es gibt globale Skripts,
die üblicherweise in jeder Szene gestartet werden. Im Unterschied dazu gibt
es auch lokale Skripts, die nur in den Szenen aktiv sind, denen sie zugeordnet sind. Abbildung 5.38 zeigt einen Teil der implementierten Skripts, die
innerhalb von Virtools farblich codiert wurden, um so ihre Zugehörigkeit
schnell erfassen zu können. Ein Großteil der implementierten Skripts ist in
der Abbildung ausgeblendet, um die Übersichtlichkeit zu erhöhen.
Für jedes Objekt einer Szene muss in Virtools genau definiert werden,
wie der Ausgangszustand des Objektes auszusehen hat. Dies ist vor allem
bei Objekten wichtig, deren Eigenschaften sich während des Spieles ändern
können. Für Comino wurden alle drei Spiel-Levels so gestaltet, dass der Level
zu jedem Zeitpunkt in den Anfangszustand zurückversetzt werden kann oder
ein anderer Level geladen werden kann. Das Zurücksetzen des Levels ist als
eigenes Feld auf dem Anoto-Menü vorhanden, das Laden der einzelen Levels
und des Outros kann über die Funktionstasten F5 bis F8 geschehen.
5.4.7
Integration der Hilfe
Als einer der letzten Schritte wurde in Comino eine Hilfefunktion integriert,
die den Spielern die wesentlichen Spielprinzipien näherbringen sollte. Die
75
Abbildung 5.38: Zur besseren Übersicht in Virtools wurden zusammengehörige Skripts mit gleichen Farben gekennzeichnet. Die Reihung der einzelnen
Scripts ist dem Spielverlauf angepasst. Die oben angeordneten Skripts werden global verwendet. Danach sind die Skripts der fünf Szenen von oben nach
unten angeordnet.
Hilfefunktion von Comino ist für jeden Level vorhanden und lässt sich über
das Anoto-Menü aufrufen. Das Spiel wechselt dann in eine Hilfeansicht des
Levels, die sowohl textuelle als auch grafische Hinweise für die Lösung der
Aufgabe liefert (Siehe Abb. 5.39 (a)). Eine Besonderheit dabei ist, dass das
Spiel nicht angehalten wird. Die Hilfeansicht zeigt den Level nur aus einer
anderen Perspektive und überlagert die Echtzeitansicht mit 2D-Grafiken, auf
denen Beschreibungen zu den einzelnen Levels stehen. Die Hilfe bietet auch
Informationen zu den realen Spielkomponenten. So werden in der Hilfeansicht der dritten Comino-Aufgabe durch eindeutige Symbole, die sich auch
auf der Oberfläche der Portale wiederfinden, die Position und Orientierung
der Comino-Portale angezeigt. (Vergleiche auch Abb. 5.39 (b))
5.4.8
Unabhängige Virtools-Applikation
Die letzte große Aufgabe war es, das Spiel auch unabhängig von Virtools
lauffähig zu machen. Virtools-Projekte können als Web-Applikation exportiert werden, doch können in diesem Fall keine zusätzlichen DLLs geladen
werden. Somit können auch keine eigenen Building-Blocks in den exportierten Anwendungen zum Einsatz kommen. Um Comino trotzdem auf einem
Computer starten zu können, auf dem Virtools nicht vorinstalliert ist, wurde
mithilfe der SDK eine eigenes Programm erstellt, dass die Virtools-Datei direkt öffnen und abspielen kann.
Da wichtige Parameter wie der verwendete COM-Port oder die Identifikationsnummern der Anoto-Stifte bisher immer direkt in Virtools geändert
werden mussten, was auf einem Rechner ohne Virtools nicht möglich ist,
(a)
76
(b)
Abbildung 5.39: Über einen Button des Anoto-Menüs kann der Spieler für
jeden Level einen Hilfetext anzeigen lassen. Abbildung (a) zeigt die HilfeAnsicht auf Level Zwei. Grafische Elemente indizieren auch die richtige Position und Orientierung der Comino-Portale (b).
wurde im Zuge der Erstellung der unabhängigen Comino-Applikation auch
eine Konfigurationsdatei integriert, die vom Spiel beim Start ausgelesen wird
und über die die besagten Parameter direkt gesetzt werden können.
5.5
Leveldesign
Für Comino wurden drei Level implementiert, die die Spieler zu bewältigen
haben. Dabei steigt der Schwierigkeitsgrad von Level zu Level. In jedem Level stehen den Spielern eine begrenzte Anzahl von virtuellen Dominosteinen
zu Verfügung, die so aufgestellt werden müssen, dass der Start-Stein des
Levels mit dem Ziel-Stein verbunden wird.
5.5.1
Level 1:
Der erste Level in Comino ist der einfachste und ist so konzipiert, dass die
Spieler den Start- und Zielstein mit einer geraden Linie direkt verbinden
können. Der Level-Untergrund stellt noch keine Anforderungen an die Spieler, der Level ist zum kennenlernen der Interaktion gedacht. Trotzdem oder
gerade deshalb bietet dieser Level die meisten Möglichkeiten für ein offenes
Spiel. Die Dominosteine können in verschiedenen Mustern aufgestellt werden
und möglichst komplizierte Szenarien ausgetestet werden. Die Physiksimulation läuft im ersten Level im Vergleich zur realen Welt etwas verlangsamt
ab, dennoch soll der erste Level das Gefühl vermitteln, dass sich das Spiel
mit den virtuellen Dominosteinen nicht wesentlich von dem mit realen unterscheidet. Holz- und Steintexturen für den Untergrund simulieren eine reale
Oberfläche. Abbildung 5.40 zeigt einen Screenshot des ersten Levels.
77
Abbildung 5.40: Im ersten Level soll der Spieler die Interaktion mit den
virtuellen Dominosteinen kennenlernen können. Das Szenario ist möglichst
nahe am realen Spiel mit Dominosteinen gehalten.
5.5.2
Level 2:
Der zweite Level von Comino erhöht die Anforderungen an die Spieler. Der
Untergrund, auf dem die Dominosteine platziert werden müssen, ist uneben
und die Verbindung von Start- und Ziel-Stein kann nicht mehr in einer geraden Linie erfolgen. Auch ist in diesem Fall die Anzahl der verfügbaren Steine
Abbildung 5.41: Virtuelle Welten können Dominosteine an die ungewöhnlichsten Orte entführen, in diesem Fall auf eine Felspfad, der sich durch ein
Lavameer schlängelt.
78
Abbildung 5.42: Um Level Drei erfolgreich beenden zu können, müssen
auch reale Dominosteine verwendet werden. Der Screenshot zeigt nur die
virtuellen Spielelemente.
so bemessen, dass nicht zu viele Steine verloren gehen dürfen, um den Level
zu schaffen.
Das Szenario, das sich den Spielern in Level Zwei zeigt, ist im Gegensatz zum ersten Level ein sehr untypisches. Die Dominosteine müssen auf
einem Felsenpfad aufgestellt werden, der sich durch ein glühendes Lavafeld
schlängelt. Hier soll gezeigt werden, wo die Stärken der virtuellen Welt liegen. Die Dominosteine verlassen die sichere Tischoberfläche und finden sich
in einem für Dominosteine untypischen und potentiell gefährlichen Umfeld
wieder. Trotzdem wurde die Interaktion der Dominosteine mit der Umgebung auf die Bodenbeschaffenheit reduziert, auch wenn sich hier eine Menge
an Möglichkeiten aufgetan hätten. Selbst wenn Dominosteine in die Lava
fallen, können sie wieder herausgefischt werden. Abbildung 5.41 zeigt einen
Screenshot von Level Nummer zwei.
5.5.3
Level 3:
Der dritte Level entführt in die Weiten des Weltraumes. In diesem Level
ist die Kombination von realen und virtuellen Dominosteinen die wichtige
Neuerung für den Spieler, die es zu meistern gilt. Wie auch in Level Zwei ist
es auch hier nicht möglich, virtuelle Dominosteine auf der gesamten Spielfläche zu positionieren. Nur ein metallener Steg erlaubt das Aufstellen von
Dominosteinen. An anderer Position aufgestellt entschwebt der Dominostein
in das All und ist für den Spieler unerreichbar verloren. Der Steg verläuft
jedoch nicht durchgehend vom Startpunkt bis zum Ziel, ein scheinbar unüberwindbares Loch klafft zwischen den beiden Stegteilen. Dieses Loch muss
79
von den Spielern unter Verwendung der realen Dominosteine überbrückt werden. Dafür müssen die Spieler in diesem Level sowohl virtuelle als auch reale
Dominosteine aufstellen, die Comino-Portale richtig anstecken und auf der
Spielfläche positionieren und mithilfe der Anoto-Stifte aktivieren. Abbildung
5.42 zeigt einen Screenshot der virtuellen Spieloberfläche von Level Drei.
5.6
Interaktionsdesign
Im folgenden Abschnitt wird die Interaktion der Spieler mit den Dominosteinen erklärt. Das Interaktionsdesign wurde mehrere Male überarbeitet,
die hier angeführten Erklärungen beziehen sich ausschließlich auf die finale
Version des Interaktionsdesigns.
Zwischen den verschiedenen Aktionen kann mithilfe des Anoto-Menüs
gewechselt werden. Jeder der möglichen Aktionen wurde eine eigene Farbe
zugewiesen, die auch auf dem Anoto-Menü sichtbar ist. Berührt der Stift die
Tischplatte, so erscheint unter der Stiftspitze eine kleine Kugel als Cursor,
die in der Farbe der momentan gewählten Aktion eingefärbt ist. Zusätzlich
kann über das Anoto-Menü der aktuelle Level gestartet oder in den Ausgangszustand zurückversetzt werden. Hierfür reicht es, wenn ein Spieler die
jeweilige Schaltfläche berührt. Auch die Hilfeansicht kann über die AnotoToolbar aktiviert und deaktiviert werden.
5.6.1
Aufstellen
Das Aufstellen der Dominosteine war die erste Interaktionstechnik, die in
Comino integriert wurde. Das Aufstellen von realen Dominosteinen wird üblicherweise als eine Tätigkeit gesehen, die ein hohes Maß an Geduld und Geschick erfordert. Das Aufstellen der virtuellen Dominosteine hingegen sollte
spielerisch, schnell und einfach sein, und es trotzdem erlauben, Steine auch
sehr präzise zu platzieren. Auch sollte es bei einer zu unkonzentrierten oder
zu schnellen Interaktion passieren können, dass die Lücken zwischen den
einzelnen Steinen zu groß werden oder dass die Dominosteine ungewollt umzufallen beginnen.
Das Aufstellen der Dominosteine ist in Abbildung 5.43 abgebildet. Vorausgesetzt der Stift ist im richtigen Modus, wird beim Berühren der Tischoberfläche mit dem Stift der erste Dominostein an der Stiftposition aufgestellt. Wichtig ist dabei, dass der Dominostein noch nicht der Physiksimulation hinzugefügt wurde. Es handelt sich bisher nur um eine Vorschau, die
die Position des Dominosteins und Orientierung anzeigt.
Die Position des Dominosteins ist bereits fixiert und kann nicht mehr verändert werden doch die Orientierung des Steins ist noch veränderbar. Bewegt
der Spieler den Stift im direkten Umfeld rund um das Zentrum des Steines,
so rotiert der Stein mit der Breitseite zu Stift. Hat der Spieler den Stein zu
80
Abbildung 5.43: Die Abbildungen zeigen das Aufstellen von Dominoblöcken in Comino. Die virtuellen Dominoblöcke können in einer durchgehenden Bewegung aufgestellt werden, als würde man sie zeichnen.
seiner Zufriedenheit ausgerichtet und will er keine weiteren Steine mehr aufstellen, so braucht er nur den Stift von der Tischplatte abzuheben. Sobald
der Stift die Platte verlässt wird der Stein der Simulation hinzugefügt. Im
Spiel wird dies grafisch angezeigt: der Stein wirft nun einen Schatten. Will
der Spieler jedoch eine ganze Reihe von Steinen erstellen, so braucht er nur
den Stift über die Tischplatte zu bewegen. Wird ein gewisser Abstand zum
vorherigen Stein überschritten, so wird der erste Stein der Simulation hinzugefügt und eine neue Vorschau angezeigt. Wie oben beschrieben ist auch
bei dieser Vorschau die Position bereits fixiert, die Orientierung kann jedoch
noch verändert werden. Somit lassen sich ganze Reihen von Steinen ganz
einfach zeichnen.
Dabei sind ein paar Dinge zu beachten. Bewegt man den Stift schneller,
so wird der Abstand zwischen den Dominosteinen größer. Dies kann später
dazu führen, dass die Kettenreaktion stockt, da der Abstand zwischen zwei
Steinen zu groß geraten ist. Auch beim Erstellen von Dominosteinen in der
Nähe von bereits aufgestellten sollte man vorsichtig sein. Wird ein Dominostein in die Physiksimulation eingebunden, der sich mit einem anderen
überschneidet, so werden die beiden Steine auseinander katapultiert. Dies
kann dazu führen, dass die gesamte Reihe der Dominosteine umfällt, bevor
81
Abbildung 5.44: Die Abbildungen zeigen das Löschen von Dominosteinen
in Comino. Wie das Erstellen von Dominosteinen kann auch das Löschen in
einer durchgehenden Bewegung ausgeführt werden.
Start gedrückt wurde.
5.6.2
Löschen
Bereits aufgestellte Dominosteine können im Lösch-Modus wieder von der
Spielfläche entfernt werden. Der Lösch-Modus besitzt zwei verschiedene Modi, die durch verschiedene Stift-Interaktion gezielt ausgelöst werden können.
Der erste Modus erlaubt es, ganz gezielt einen Stein zu löschen. Dies kann
bewerkstelligt werden, indem kurz auf den besagten Stein geklickt wird. Dieser, und nur dieser Stein wird von der Szene gelöscht. Selbst wenn sich Steine
in unmittelbarer Nähe des besagten Steins befinden, wird nur ein einziger
Stein gelöscht. Wird der Stift jedoch für längere Zeit auf der Tischoberfläche gehalten, so wird der zweite Modus aktiviert. Dieser Modus löscht alle
Dominosteine, die das Cursor-Objekt berühren. Dieser Modus eignet sich
für das rasche Löschen von mehreren Dominosteinen, da der Stift wie ein
Radierer über die Dominosteine bewegt werden kann. Abbildung 5.44 zeigt
das Löschen von Dominosteinen.
82
Abbildung 5.45: Die Abbildungen zeigen das Umstoßen von Dominosteinen
in Comino. Über die Dauer der Interaktion kann die Stärke des ausgesendeten
Physikimpulses gesteuert werden.
5.6.3
Umstoßen
Das Umstoßen von Dominosteinen kann dazu verwendet werden, die Kettenreaktion wieder in Gang zu bringen, wenn sie einmal nicht durchgehend
funktioniert. Die Idee dabei war, den Spieler nicht dazu zu zwingen, den
Level neu starten zu müssen, sollte einmal die Reihe der Dominosteine nicht
wie geplant umfallen. Dies wurde integriert, da auch beim Spiel mit realen
Dominosteinen nachgeholfen werden kann. Zusätzlich kann die UmstoßenFunktion dazu verwendet werden, um eine Kettenreaktion zu starten, die
nicht die Beendigung des Levels zum Ziel hat, sondern einfach nur eine bestimmte Aufstellung von Dominosteinen zu Fall bringen soll. Die UmstoßenFunktion kann auf der gesamten Tischfläche ausgelöst werden und beeinflusst alle vorhandenen Dominosteine. Sobald der Stift von der Tischfläche
abgehoben wird, wird ein Physikimpuls, ausgehend von der letzten Stiftposition, an alle Dominosteine ausgesendet. Die Stärke des Impulses, der auf
den einzelnen Stein wirkt, ist abhängig vom Abstand des Steines zur letzten Stiftposition sowie der Dauer, die der Stift auf der Oberfläche war. Je
länger sich der Stift auf der Oberfläche befand, desto stärker ist auch der
ausgelöste Impuls. Ein kurzer Klick bringt nur ganz nahe Dominosteine zu
Fall, während ein längeres Drücken einen großen Teil des Tisches leerfegen
kann. Abbildung 5.45 zeigt die Verwendung der Funktion.
5.6.4
Verschieben
Die Verschieben-Funktionalität kann verwendet werden, um Dominosteine,
die falsch platziert wurden, neu auszurichten ober zu verschieben. Zusätzlich können umgefallene Dominosteine wieder aufgestellt werden. Im Verschieben-Modus ist der Stift mit dem ersten Dominostein verbunden, den er
berührt. Erst durch ein Aufheben des Stiftes von der Tischplatte wird die
Verbindung gelöst. Wie auch beim Aufstellen von Dominosteinen erlaubt
(c)
83
(d)
Abbildung 5.46: Die Abbildungen zeigen das Verschieben von Dominosteinen in Comino. Aufgestellte oder bereits umgefallene Dominosteine können
neu positioniert werden.
ein Bewegen des Stiftes in der unmittelbaren Nähe des Steins ein Drehen
desselben. In diesem Fall dreht sich der Stein jedoch mit der schmalen Seite
zum Stift. Wird eine gewisse Distanz überschritten, so springt der Stein
an die aktuelle Position des Stiftes und folgt dieser nun, die schmale Seite
voran. Dies erlaubt das genaue Neupositionieren in einer bestehenden Reihe.
Verweilt der Spieler eine gewisse Zeit auf einer Stelle, so wird automatisch
wieder in den ersten Modus zurückgewechselt. Abbildung 5.46 illustriert die
beschriebene Funktion.
Kapitel 6
Diskussion
Comino wurde im Rahmen einer Reihe von Usability-Tests von TabletopSpielen von zwölf Benutzern getestet. Die Testreihe war Teil einer Diplomarbeit [16], die am Fachhochschul-Masterstudiengang Digitale Medien 1 in
Hagenberg verfasst wurde. Die Teilnehmer konnten während der gesamten
Versuchsdauer Fragen zum Spiel an die Versuchsleitung stellen. Während
der Tests wurden Rückmeldungen zum Spiel in Form von Kommentaren
aufgezeichnet und für die Auswertung dem Autor von der Versuchsleitung
zu Verfügung gestellt.
Zum Teil wurden Ergebnisse der Tests bereits in die Implementierung
von Comino eingearbeitet. Im Rahmen dieser Arbeit werden nur die am häufigsten genannten Punkte aufgelistet. Zusätzlich werden auch Erfahrungen,
die durch Beobachtungen und Rückmeldungen von Benutzern außerhalb der
Testreihe gewonnen werden konnten, in die Diskussion mit einbezogen. Zu
guter Letzt werden bei einigen Punkten auch die Erfahrungen aus Sicht des
Autors zu Papier gebracht.
Um die Diskussion der Erfahrungen und Rückmeldungen übersichtlicher
präsentieren zu können, wurden alle besprochenen Punkte jeweils einer der
drei Phasen Eingabe, Spiel und Ausgabe zugeteilt, die in Abschnitt 1.2 vorgestellt wurden.
6.1
6.1.1
Eingabe
Stiftinteraktion
Die Mehrheit der Spieler hatte mit der Verwendung der Anoto-Stifte (Siehe
Abb. 6.1) keine Schwierigkeiten. Die Genauigkeit der Positionserkennung
wurde nur von einer Person kritisiert und auch mit der richtigen Haltung
der Stifte hatten die Spieler nach einer kurzen Eingewöhnungsphase keine
1
http://www.fh-ooe.at/campus-hagenberg/studiengaenge/studiengaenge/
master-studien/vollzeit/digitale-medien.html
84
KAPITEL 6. DISKUSSION
85
Abbildung 6.1: Die Handhabung der Anoto-Stifte führte bei keinem der
Spieler zu größeren Schwierigkeiten, und auch die Genauigkeit der Kalibrierung war in den meisten Fällen ausreichend.
Probleme.
Auch aus Entwicklersicht war die Entscheidung, Anoto-Stifte als Eingabegeräte zu verwenden, eine Gute. Die Anoto-Tracking-Technologie liefert
eine skalierbare und robuste Positionserkennung von mehreren, unterscheidbaren Benutzern. Die Interaktion mit Stiften erlaubt es den Spielern, sehr
kleine Objekte anzuklicken und durch eine gute Kalibrierung kann sogar pixelgenaue Selektion vom System unterstützt werden. Die Genauigkeit war
auch für präzise Aktionen in Comino ausreichend. Das Tracking der AnotoStifte ist des weiteren sehr unempfindlich gegenüber wechselnder Lichtsituation, was beim Einsatz von Projektoren oft problematisch sein kann.
Auch wird das Tracking durch die Platzierung von Objekten auf der Interaktionsoberfläche nicht gestört und eignet sich deshalb hervorragend für
die gemeinsame Verwendung mit weiteren physischen Komponenten. Die
Tracking-Lösung ist sowohl in Bezug auf die verwendbare Fläche als auch
in Bezug auf die Anzahl der verwendeten Stifte skalierbar und dabei relativ
billig.
Auch ermöglicht die Anoto-Technologie eine einfache und schnelle Integration von zusätzlichen Interfaces, den Anoto-Menüs. Der Entwickler spart
so sowohl Entwicklungszeit, da er keine komplizierten Menüstrukturen entwickeln muss. Vor allem wird auch auch wertvoller Platz auf dem Bildschirm
gespart. Auch das Problem der beliebigen Rotierbarkeit, die für Menüelemente auf einer Tabletop-Oberfläche gegeben sein soll, kann durch diese
86
Interfaces umgangen werden. Zusätzlich kann das Menü auf verschiedene
physische Objekte verteilt und beliebig oft verwendet werden. Es besteht
auch keine Grund, dass Buttons für alle Benutzer gleich aussehen müssen.
Kinder können andere Interfaces bekommen wie Erwachsene, ohne dass am
Programm etwas verändert werden muss. Das Interface ist dabei in der Herstellung sehr billig, ist leicht und verbraucht während der Verwendung keine
Energie. Dazu kommt eine hohe Lebensdauer, sofern das Interface durch
eine transparente, kratzfeste Oberfläche wie Hartplastik oder Glas geschützt
wird.
6.1.2
Anoto Menüs
Ein Kritikpunkt, der von mehreren Benutzern aufgebracht worden war, war
des Fehlen eines eigenen Anoto-Menüs für jeden Spieler. Vor allem für das
Wechseln zwischen den verschiedenen Aktionen wünschten sich gleich mehrere Spieler eine eigene, kleine Tool-Palette, um so im Falle eines ungewollten
Umstoßens eines virtuellen Dominosteins schnell auf das Löschen-Werkzeug
wechseln zu können. Gleichzeitig wurde aber auch bemerkt, dass das Teilen
des Menüs die Kommunikation zwischen den Spielern fördere.
Im Zusammenhang mit den Anoto-Oberflächen der Portale wurde oftmals erwähnt, dass die Interaktionsfläche besser als solche erkennbar sein
sollte. Auch sollte die Oberfläche bereits Aufschluss über die jeweilige Funktion der Interaktionsfläche geben. Zusätzlich wurde bemängelt, dass aufgrund des nicht vorhandenen Feedbacks des Stiftes das Einstellen der jeweiligen Parameter langwierig ausfallen konnte. Dies war zum Teil jedoch
auch durch einen Programmfehler bedingt, der erst nach der Benutzerstudie
entdeckt und behoben wurde.
Hierzu muss aus Entwicklersicht ergänzt werden, dass die Integration der
intelligenten Oberflächen der Türme erst für einen späteren Level vorgesehen
war, aufgrund von Zeitmangel jedoch bereits in den dritten Level vorgezogen wurde. Die Funktion der intelligenten Oberflächen der Comino-Portale
wurde integriert, um die Möglichkeiten, die sich durch die Verwendung von
Anoto Pattern auf physischen Spielelementen ergeben, aufzuzeigen.
6.2
6.2.1
Spiel
Interaktionsdesign
Die meisten Kritikpunkte am Spiel wurden an der Interaktion mit den virtuellen Dominosteinen geäußert. Dies führte auch dazu, dass diese noch einmal
komplett überarbeitet und die neue Umsetzung noch während der Tests in
Comino integriert wurde. Mehrere Benutzer wurden nach dem offiziellen Test
gebeten, die neue Steuerung mit der alten zu vergleichen und die Ergebnisse
waren ausnahmslos positiv. Ein Großteil der aufgezeigten Mängel konnte
87
somit bereits während der Testphase behoben werden. Dennoch stellt vor
allem das exakte Platzieren von Dominosteinen für viele Spieler eine Herausforderung dar. Ein Teil wertete dies jedoch nicht als Problem des Interfaces,
sondern als Herausforderung, die das Spiel an seine Spieler stellt.
6.2.2
Leveldesign
Bei Leveldesign gab es einige Punkte, die von mehreren Spielern kritisiert
wurden. Einige Spieler kritisierten, dass der Sprung vom zweiten auf den
dritten Level zu viele Neuerungen mit sich bringt. Die Funktionen der einzelnen Portale hätten besser vorgestellt und ihr Einsatz besser vorbereitet
werden müssen. Ohne die Hilfe von eingeweihten Personen wäre Level Nummer Drei nicht lösbar gewesen.
Die integrierte Hilfefunktion wurde von keinem der Spieler als hilfreich
angesehen. Als Grund hierfür wurde angegeben, dass die Hilfe den Spieler
mit zu viel Text konfrontiert. Als Alternative wurden kurze praktische Beispiele für die verschiedenen Interaktionstechniken und Portale vorgeschlagen, die den Spieler auf den nächsten Level vorbereiten. Vor allem für den
zweiten Level wurde auch eine veränderbare Kameraposition erwünscht, die
es erlauben sollte, die Oberfläche des Spielfeldes genauer unter die Lupe zu
nehmen.
Der wohl wichtigste Kritikpunkt am Spiel war das Fehlen einer Anzeige,
die die Anzahl der noch verfügbaren Steine wiedergibt. Dies wurde vor allem
dann gefordert, wenn im ersten Level ausführlich getestet wurde und dabei
alle verfügbaren Dominosteine zum Einsatz kamen. In der derzeitigen Umsetzung von Comino ist es, nachdem alle verfügbaren Steine aufgebraucht
sind, nicht mehr möglich, neue Steine aufzustellen. Es wird im Spiel darauf
jedoch nicht explizit hingewiesen, dass alle Steine aufgebraucht sind. Verschiedene Ausführungen einer Anzeige wurden mit Spielern diskutiert, doch
wurde bisher keine Anzeige in Comino integriert.
6.2.3
Spielziel
Auch in Bezug auf das Spielziel wurde von einer Testgruppe Kritik geäußert.
Die Spieler kritisierten das Fehlen einer Auswertung am Spielende und den
fehlenden Vergleich mit anderen Spielern, sei es durch eine Zeitnehmung
oder eine andere quantitative Auswertung des Spieles
Aus Entwicklersicht ist dazu zu sagen, das die Mehrheit der Spieler mit
den in Abschnitt 3.3 beschriebenen Spielmechanismen zufrieden waren und
das es schwer ist, ein für alle Spieler zufriedenstellendes Konzept zu entwickeln und umzusetzen. Dennoch wurden verschiedene andere Spielmodi
in Betracht gezogen, die jedoch nicht in die finale Version integriert wurden.
Mögliche alternative Spielziele wären das Spiel gegen die Zeit, die Verwendung möglichst weniger Dominosteine oder möglichst wenige Spieleraktio-
88
nen im Level. Auch gewisse Farbkombinationen umgefallener Dominosteine
in einem Level könnten zum Beispiel ein besseres Spielergebnis bringen. Natürlich wären auch Kombinationen aus den genannten Punkten denkbar. Die
größte Schwierigkeit bei der Implementierung dieser System sind dabei die
nötigen Kontrollmechanismen, die das Betrügen von Spielern verhindern.
Dies war der Hauptgrund, warum keine zusätzlichen Spielziele in Comino
integriert wurden.
6.3
6.3.1
Ausgabe
Grafische Ausgabe
Das grafische Design der Levels wurde von den meisten Spielern als ansprechend empfunden, nur vereinzelt wurden Details der Umsetzung kritisiert.
Die meisten dieser Kritikpunkte sind direkt oder indirekt auf den geringen
Kontrast zurückzuführen, denn die Projektion in einem hellen Raum liefert.
Dies führt dazu, dass sowohl die Sichtbarkeit der Dominosteine als auch
die Lesbarkeit der Hilfetexte darunter leidet. Generell ist zu empfehlen, die
(Farb-)Kontraste im Vergleich zu einem Spiel, das für einen normalen Bildschirm entwickelt wird, stark zu erhöhen, um gute Unterscheidbarkeit der
verschiedenen Objekte sicherzustellen. Positiv im Zusammenhang mit der
grafischen Umsetzung wurden die Verwendung von Partikel-Systemen und
Schatten kommentiert.
6.3.2
Kameraperspektive
Da auf die Position der Spieler in Comino nicht Rücksicht genommen werden
kann, wird der virtuelle Level immer aus der gleichen Perspektive dargestellt
und ist für Spieler, die rund um den Tisch stehen, verzerrt dargestellt. Vor
allem bei gleichzeitigem Einsatz von realen und virtuellen Dominosteinen ist
die unterschiedliche Perspektive deutlich sichtbar. Abbildung 6.2 illustriert
dieses Phänomen. Wider Erwarten wurde dieses Phänomen von keinem Spieler kommentiert oder gar als störend empfunden.
6.3.3
Comino-Portale
Auch wenn die Idee der Comino-Portale ausnahmslos als eine sehr interessante und gute kommentiert wurde, so wurde doch Kritik an der Umsetzung
der Portale geäußert. Konkret war die notwendige Verkabelung der Portale
Stein des Anstoßes, die laut Spielern nicht nur beim Aufstellen sowohl von
virtuellen als auch realen Dominosteinen behindere, sondern auch den optischen Gesamteindruck des Spieles zerstören würde.
Für die Spieler war außerdem nicht unmittelbar ersichtlich, wie virtuelle
und reale Dominosteine zu platzieren sind, um die korrekte Funktionsweise
89
Abbildung 6.2: Die Perspektive von realer und virtueller Spielfläche stimmt
in Comino nicht überein. Während die realen Dominosteine von der Seite
betrachtet werden, sind die virtuellen von oben sichtbar.
der Portale sicherzustellen. Zusätzlich würden die Portale, einmal auf der
Projektionsfläche platziert, es erschweren, virtuelle und reale Dominosteine
in der unmittelbaren Umgebung zu platzieren.
Aus Entwicklersicht muss hierzu gesagt werden, dass das Problem der
störenden Verkabelung durchaus als solches erkannt worden war und dass
auch verschiedene Möglichkeiten für dessen Lösung existieren, doch wäre
es nicht möglich gewesen, das Problem mit vertretbar geringem finanziellen
und technischen Aufwand zu lösen. Zwei der Möglichkeiten werden hier kurz
beschrieben:
Die erste kann wohl eher als Umgehung des Problems angesehen werden und hätte vorgesehen, die Verkabelung nicht auf dem Tisch sondern im
Tisch durchzuführen. Hierfür wäre es nötig gewesen, die notwendigen KabelBuchsen an verschiedenen Stellen in der Tischplatte zu versenken und innerhalb des Tisches mit der Sensorbox zu verbinden. Die Verkabelung auf
der Tischplatte ist dann zwar immer noch vorhanden, kann jedoch kürzer
und dezenter ausfallen und muss nicht quer über den Tisch verlegt werden.
Diese Lösung wurde aus Flexibilitätsgründen nicht durchgeführt, da Bohrungen für die versenkten Kabel-Buchsen die Tischplatte beschädigt hätten,
der Rückprojektionstisch jedoch auch für andere Projekte einsetzbar sein
sollte.
Der zweite Lösungsansatz wäre die Verwendung von Bluetooth-Arduino
Kontrollern, die eine kabellose Verbindung zum Steuerrechner ermöglichen.
90
Diese Lösung würde für jedes Portal einen dieser Kontroller plus nötiger
Stromversorung durch eine Batterie erfordern. Abgesehen vom relativ hohen Stückpreis (ca. 100 Euro pro Kontroller) hätte in diesem Fall auch die
Kommunikation über das Firmata-Protokoll überarbeitet werden müssen.
Die unterschiedlichen Hardwarespezifikationen der beiden Arduino-Boards
erlauben keine direkte Wiederverwendung des bestehenden Codes.
Das Design und die Umsetzung der Portale sind auf maximale Flexibilität bei minimalen Kosten ausgerichtet und sind in ihrer prototypischen
Umsetzung durchaus verbesserungswürdig. Dennoch ist die derzeitige Implementierung aus Karton für Testzwecke hervorragend geeignet, da Größe
und Form leicht veränderbar sind.
6.3.4
Audio
Ein Aspekt, der normalerweise in keinem Spiel fehlen darf, wurde bei der
Umsetzung von Comino gänzlich ausgeklammert. Comino hat keine AudioAusgabe. Sowohl Geräuscheffekte als auch Musik fehlen im Spiel gänzlich
und wurden auch von mehreren Spielern vermisst. Vor allem das fehlende
Geräusch der fallenden Dominosteine und diverser Audio-Effekte in den einzelnen Levels wie bei der erfolgreichen Beendigung wurden von mehreren
Spielern als ein verbesserungswürdiger Punkt angesehen.
Die Integration von Audio-Effekten und Musik wurde vor allem deshalb
nicht in Angriff genommen, da dies nicht der Kernbereich der Arbeit war
und keine passenden fertigen Tonbeispiele verfügbar waren. Aus technischer
Hinsicht ist die Integration von Audio in Virtools jedoch kein Problem und
könnte jederzeit nachgeholt werden.
Kapitel 7
Schlussfolgerungen
7.1
Zusammenfassung
Diese Arbeit dokumentiert die Ergebnisse und Erfahrungen der Umsetzung
des Tabletop-Spieles Comino. Das Spiel Comino kombiniert virtuelle und
reelle Spielelemente in einer gemeinsamen Spielumgebung. Gespielt wird auf
einem Rückprojektionstisch, bei dem die Projektionsfläche gleichzeitig auch
die reale Spielfläche des Spieles ist. Ziel des Spieles ist das erfolgreiche Lösen
von verschiedenen Puzzles, was nur durch die geschickte Kombination von
virtuellen und reellen Spielelementen bewerkstelligt werden kann.
Das Spiel bedient sich dabei spezieller Schnittstellen, sogenannten Comino-Portalen, die den nahtlosen Wechsel zwischen realer und virtueller
Spielfläche erlauben. Die Umsetzung der speziellen Hardware integriert bestehende Mikrokontroller und speziell entwickelte Software für die direkte
Kommunikation mit dem Steuerrechner. Die virtuelle Umgebung wurde in
3D umgesetzt und inkludiert eine Vielzahl unterschiedlicher Objekte, die
selbst modelliert und texturiert wurden. Die Interaktion der Benutzer mit
den virtuellen Spielkomponenten erfolgt über spezielle digitale Stifte, deren
Position auf der Tischoberfläche bestimmt werden kann. Das System wurde
für die gleichzeitige Interaktion von bis zu vier Spielern entwickelt und getestet.
Die Arbeit illustriert die unterschiedlichen Arbeitschritte beginnend bei
der Erstellung des Spielkonzeptes bis hin zur Diskussion von Kommentaren
von Testspielern des fertigen Setups. Zusätzlich werden in der Arbeit Referenzprojekte aufgelistet und verwendete Soft- und Hardware vorgestellt.
7.2
Erreichte Ziele
Die für das geplante Spiel im Vorfeld angeführten Inspirationsquellen (Vergleiche Abschnitt 1.1) aus den Bereichen Eingabegeräte, Ausgabegeräte und
Spiele(-Plattformen) dienten als Motivation für die Umsetzung eines eigenen
91
KAPITEL 7. SCHLUSSFOLGERUNGEN
92
Verarbeitung
be
ga
ga
be
an
Au
ge
H
d
Dominosteine
Po
Po
rta
l
Ei
n
s
Au
Spieler
l
rta
real
virtuell
ik
e
o
Ei
be
ng
ab
An
ot
af
gr
Virtools
o
el
a
sg
Virtools
in
Ar
d
ui
no
du
Ar
i
Sp
Au
Spielelogik
Verarbeitung
Abbildung 7.1: Die Interaktion zwischen realen und virtuellen Spielkomponenten in Comino.
Spieles. Alle drei Themenbereiche wurden für die Umsetzung von Comino
aufgegriffen und wurden in die fertige Umsetzung des Spieles integriert. Die
Umsetzung von Comino integriert sowohl neuartige Ein- als auch Ausgabegeräte, als Schnittstellen für ein neuartiges Spielkonzept basierend auf
Dominosteinen und ist eines der ersten Spiele, das auf einer neuen TabletopPlattform entwickelt wurde.
Die in Abschnitt 1.2 gestellten Anforderungen für die Umsetzung eines
Spieles, dessen Spielgeschehen die virtuelle Spielumgebung verlassen und in
die reale Welt übertragen kann, werden in Comino erfüllt. Abbildung 7.1
zeigt den Interaktionskreislauf der reellen und virtuellen Teilbereiche von
Comino. Die speziell entwickelten Comino-Portale erlauben eine Übertragung des Spielgeschehens über diese Grenze hinweg. Das Bindeglied, das
Ausgang und Eingang miteinander verbindet, fungieren von den Spielern
aufgestellte Dominosteine.
Comino integriert verschiedene Technologien als Eingabegeräte. AnotoStifte können verwendet werden, um direkt mit der virtuellen Welt zu interagieren. Mithilfe der Comino-Portale, die über einen Arduino-Kontroller
mit dem Computer verbunden sind, kann die Interaktion zwischen virtuellen
und echten Dominosteinen erfolgen und Virtools erlaubt die Integration von
Maus und Tastatur und gibt grafisches Feedback an die Spieler.
Trotz der in Abschnitt 6 angeführten Kritikpunkte am Spiel und an den
Schnittstellen kann gesagt werden, dass das Projekt erfolgreich abgeschlossen
wurde. Die umgesetzten Interfaces erlauben sowohl die Interaktion zwischen
Spieler und Spiel als auch zwischen physischen Spielelementen und virtuellen
Spielelementen und erfüllen somit die für die Arbeit gesteckten Ziele.
7.3
93
Ausblick
Die Arbeit an und die Recherche für Comino war eine reiche Inspirationsquelle für mögliche Erweiterungen, die in das Spiel integriert werden können.
Dabei sind sowohl zusätzliche Levels und virtuelle Spielelemente als auch
alternative Spielmodi und Spielziele denkbar. An dieser Stelle werden zwei
mögliche Erweiterungen beschrieben, die im speziellen die Möglichkeiten der
Interaktion mit realen Spielelementen bereichern würden.
Kameras: Das bestehende Setup von Comino ermöglicht weder herauszufinden, ob die Comino Portale an die richtigen Stellen platziert wurden, noch
ob tatsächlich reale Dominosteine eingesetzt wurden, oder die Lichtschranke
einfach durch einen Spieler unterbrochen wurde. Das Comino-Setup verlässt
sich darauf, dass der Spieler von sich aus den Ehrgeiz besitzt, das Puzzle
ordnungsgemäß zu lösen. Durch die Integration einer Kamera in den Tisch
in Kombination mit Bildverarbeitung könnte ein Teil der angeführten Informationslücken geschlossen werden.
Physische Gegenstände erscheinen vom Tischinneren aus gesehen als klar
abgegrenzte Schatten auf der diffusen Projektionsoberfläche. Abbildung 7.2
zeigt die Projektionsoberfläche von einer Kamera im Inneren des Rückprojektionstisches aufgenommen. Die Schatten der Portale und Dominosteine
sind im Bild deutlich sichtbar und könnten durch Bildverarbeitung ausgewertet werden. Natürlich muss hier gesagt werden, dass die Auswertung der
Bilder in Echtzeit keinesfalls trivial ist und eine funktionierende Umsetzung
einen nicht zu unterschätzenden Aufwand darstellen würde. Sieht man von
den technischen Schwierigkeiten ab, so wäre eine Integration von Kameras
durchaus erstrebenswert, da sich für das Spiel durch die zusätzlichen Informationen interessante Möglichkeiten ergeben.
Zum einen könnte die Position der Portale dynamisch ausgewertet werden und so auch eine flexible Platzierung innerhalb des virtuellen Levels
ermöglichen. Sowohl die Portale als auch die realen Dominosteinen könnte
durch projizierte Effekte rund um die Objekte stärker mit den virtuellen
Inhalten verknüpft werden. Auch könnte zum Beispiel durch die Erkennung
von Bewegung im Bild darauf geschlossen werden werden, ob wirklich reale
Dominosteine von einem Portal bis zum nächsten aufgestellt worden waren
und diese auch ordnungsgemäß umgefallen sind.
Roboter: Eine weiter interessante Möglichkeit wäre die Integration von
realen Robotern in des Spiel. Das im Inami Laboratory1 entwickelte Dis”
play-based Tracking and Control System“2 kann für die Steuerung und Lokalisierung von speziellen Robotern verwendet werden. Mit projizierten op1
2
http://www.hi.mce.uec.ac.jp/inami-lab/en/index.html
http://www.hi.mce.uec.ac.jp/inami-lab/en/projects/display-based/index.html
(a)
(b)
94
(c)
Abbildung 7.2: Abbildung (a) zeigt die Tischoberfläche mit einer Reihe stehender Dominosteine, die im umgefallenen Zustand einen fast durchgehenden
Schatten zwischen den beiden Portalen werfen (b). Abbildung (c) zeigt ein
Differenzbild von (a) und (b), bei dem zusätzlich der Kontrast erhöht wurde.
tischen Markern können Roboter innerhalb der projizierten Fläche bewegt
werden. In Abschnitt 2.2.10 findet sich eine kurze Beschreibung des Systems
und eines Spieles, das auf Basis dieser Technologie umgesetzt wurde.
Die Möglichkeit, reale Roboter ohne zusätzliche Hardware steuern zu
können, macht diese Technologie zu einer, die sie für die Integration in Comino interessant macht. Eine erfolgreiche Integration ergäbe eine Vielzahl
neuer Möglichkeiten für das Spiel. Roboter können zum Beispiel dazu verwendet werden, reale Dominosteine umzustoßen und so stellten so eine alternative Möglichkeit dar, aufgrund virtueller Vorgänge reale Ereignisse auszulösen. Da die Position des Roboters auch in der virtuellen Welt bekannt
ist, kann der reale Roboter auch virtuelle Dominosteine zum Umfallen bringen. Der Roboter kann auch verwendet werden, um in gewissen Bereichen
des Tisches das Aufstellen von realen Dominosteinen zu verhindern. Kombiniert mit einer Positionserkennung von physikalischen Dominosteinen wie
im vorherigen Abschnitt beschrieben, könnte der Roboter gezielt reale Dominosteine ansteuern und umstoßen. Abbildung 7.3 zeigt einen Roboter im
Mixed-Reality Spiel Augmented Coliseum“ [17].
”
Die Möglichkeiten, die sich durch die kreative Auseinandersetzung mit
Technologie ergeben, sind nicht nur für Comino eine Bereicherung, sondern
werden in Zukunft zu einer Vielzahl interaktiver Tabletop-Applikationen
führen und möglicherweise ein neues Spiel-Genre hervorbringen. Der Erfolg
von Plattformen wie Arduino und Projekten wie LEGO MINDSTORMS“
”
[29] (Abb.: 7.4 (a)), die Kinder und Jugendliche spielerisch an Themenbereiche wie Physical Computing heranführen, verspricht eine interessante
Zukunft dieses Bereiches. Kombiniert mit intelligenten Spielkonzepten wie
zum Beispiel dem von LittleBigPlanet“3 (Abb.: 7.4 (b)), das die Spieler
”
selbst Levels gestalten lässt, ergeben sich eine Fülle an Möglichkeiten, die
virtuelle und reale Spielewelt zu vereinen.
3
http://www.mediamolecule.com/games.html
95
Abbildung 7.3: Die Integration von Robotern in Comino würde zahlreiche
neu Interaktionsmöglichkeiten zwischen realen und virtuellen Spielelementen
c Inami Laboratory)
ermöglichen. (Abb.: (a)
(b)
Abbildung 7.4: (Der Umgang mit Technik in LEGO MINDSTORMS“ (a)
”
und Spielkonzepte wie das von LittleBigPlanet“ (b) sind interessante Aus”
gangspunkte für zukünftige Entwicklungen im Bereich der Spiele, sowohl mit
c LEGO MINDrealen als auch mit virtuellen Spielelementen. (Abb. (a): c Media Molecule)
STORMS, Abb. (b): Anhang A
Inhalt der CD-ROM
File System: Joliet
Mode: Single-Session (CD-ROM)
A.1
Diplomarbeit
Pfad: /
jl diplomarbeit.pdf . . .
jl diplomarbeit href.pdf
A.2
Diplomarbeit (PDF-Datei)
Diplomarbeit mit Hyperlinks (PDF-Datei)
Übersicht
Pfad: /
application/ .
development/
images/ . . .
references/ .
A.3
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Comino-Applikation und -Tools
Entwicklungs-Dateien
Bilder und Grafiken
Referenzen
Comino-Applikation
Pfad: /application/comino/
BuildingBlocks/
Managers/ . . .
Plugins/ . . . . .
RenderEngines/
Comino.exe . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Building Block Spielressourcen
Manager Spielressourcen
Plugin Spielressourcen
Renderengine Spielressourcen
Executable-Datei für Comino Spiel
96
ANHANG A. INHALT DER CD-ROM
97
comino levels.cmo . . .
Virtools Composition (CMO) der
Comino-Levels
config.txt . . . . . . . . Konfigurationsdatei (Allgemein)
patternConfiguration.xml Konfigurationsdatei (Anoto-Menüs)
readme.txt . . . . . . . Readme-Datei
A.4
Comino-Tools
Pfad: /application/tools/
configurator/ . . . . . .
drivers/ . . . . . . . . .
sender/ . . . . . . . . .
A.5
Anoto-Pattern Konfigurator
Treiber für Arduino-Board
Anoto UDP-Sender
Maya Dateien
Pfad: /development/maya/
files/ . . . . . . . . . . .
textures/ . . . . . . . .
A.6
Maya Dateien für virtuelle Spielelemente
Texturen der virtuellen Spielelemente
Virtools Dateien
Pfad: /development/virtools/
bb/ . . . . . . . . . . .
cmo/ . . . . . . . . . .
nmo/ . . . . . . . . . .
A.7
Virtools Building Blocks (BBs)
Virtools Compostion des Spieles
Virtools Objekt Dateien von virtuellen
Spielelementen
Visual Studio Dateien
Pfad: /development/visual/
anotobb/ . . . . . . . .
arduinobb/ . . . . . . .
consoleapp/ . . . . . . .
dependencies/ . . . . .
version/ . . . . . . . . .
Visual Studio Projekt des Anoto BBs
Visual Studio Projekt des Arduino BBs
Visual Studio Projekt der
Konsolenanwendung
Ressourcen für Visual Studio Projekte
Entwicklungsstadien der Konsolenanwendung
ANHANG A. INHALT DER CD-ROM
A.8
vvvv Dateien
Pfad: /development/vvvv/
modules/ . . . . . . . .
arduino.v4p . . . . . . .
A.9
Subpatches der vvvv-Anwendung
Arduino Kommunikations Patch
Bilder und Grafiken
Pfad: /images/
anoto/ . . . . .
arduino/ . . . .
comino/ . . . .
dominoblock/ .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
interaction/ .
other/ . . . .
portals/ . . .
screenshots/
sensorbox/ .
table/ . . . .
toolbar/ . . .
virtools/ . . .
vvvv/ . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
A.10
.
.
.
.
.
.
.
.
.
Anoto Abbildungen
Arduino Abbildungen
Abbildungen zum Spiel
Abbildungen zur Entstehung der virtuellen
Dominoblocks
Abbildungen zur Benutzerinteraktion
Diverse Abbildungen
Abbildungen der Comino Portale
Screenshots des Spieles
Abbildungen der Sensorbox
Abbildungen des Tisches
Abbildungen der Anoto Menüs
Abbildungen zu Virtools
Abbildungen zu vvvv
Referenzmaterial
Pfad: /references/
doc/ . . . . . . . . . . .
img/ . . . . . . . . . . .
Kopien referenzierter Webdokumente
Referenziertes Bildmaterial
98
Literaturverzeichnis
[1] AB, A. G.: Anoto History, Juli 2007.
com/filearchive/1/1579/Timeline.pdf
Kopie
(anoto history.pdf).
http://www.anoto.
auf
CD-ROM
[2] AB, A. G.: Pattern and Print, Juli 2007. http://partner.anoto.com/
cldoc/3146.htm Kopie auf CD-ROM (pattern and print.pdf).
[3] Bakker, S., D. Vorstenbosch, E. van den Hoven, G. Hollemans und T. Bergman: Tangible interaction in tabletop games: studying iconic and symbolic play pieces. In: ACE ’07: Proceedings of the
international conference on Advances in computer entertainment technology, S. 163–170, New York, NY, USA, 2007. ACM Press.
[4] Banzi, M.: Getting started with Arduino, Juli 2007. http://www.
arduino.cc/en/uploads/Booklet/Arduino booklet02.pdf Kopie auf CDROM (getting started with arduino.pdf).
[5] Barakonyi, I., M. Weilguny, T. Psik und D. Schmalstieg: MonkeyBridge: autonomous agents in augmented reality games. In: ACE
’05: Proceedings of the 2005 ACM SIGCHI International Conference
on Advances in computer entertainment technology, S. 172–175, New
York, NY, USA, 2005. ACM Press.
[6] Barragán, H.: Wiring: Prototyping Physical Interaction Design. Doktorarbeit, Interaction Design Institute Ivrea, Juni 2004.
[7] Billinghurst, M., H. Kato und I. Poupyrev: The MagicBook moving seamlessly between reality and virtuality. Computer Graphics
and Applications, IEEE, 21:6–8, 2001.
[8] Carthy, C. M. und D. Callele.: Virtools User Guide. CD-ROM,
2006. Kopie auf CD-ROM (virtools user guide.pdf).
[9] Dietz, P. und D. Leigh: DiamondTouch: a multi-user touch technology. In: UIST ’01: Proceedings of the 14th annual ACM symposium
on User interface software and technology, S. 219–226, New York, NY,
USA, 2001. ACM Press.
99
LITERATURVERZEICHNIS
100
[10] Frapolli, F., B. Hirsbrunner und D. Lalanne: Dynamic Rules:
Towards interactive games intelligence. In: Tangible Play: Research
and Design for Tangible and Tabletop Games, Workshop at the 2007
Intelligent User Interfaces Conference, Honolulu, Hawaii, USA, 2007.
[11] Gauthier, J.-M.: Building Interactive Worlds in 3D. Virtual Sets
and Pre-visualization Games, Movies and Web.: Virtual Sets and Previsualization for Games, Film and the Web. Elsevier LTD, Oxford,
Pap/Cdr Aufl., Okt. 2004.
[12] Greenberg, S. und C. Fitchett: Phidgets: easy development of physical interfaces through physical widgets. In: UIST ’01: Proceedings of
the 14th annual ACM symposium on User interface software and technology, S. 209–218, New York, NY, USA, 2001. ACM Press.
[13] Hall, P.: The Principals of Play, Sep. 2006.
http://www.
metropolismag.com/cda/story.php?artid=2283 Kopie auf CD-ROM
(the principals of play.pdf).
[14] Jordà, S., G. Geiger, M. Alonso und M. Kaltenbrunner: The
reacTable: exploring the synergy between live music performance and
tabletop tangible interfaces. In: TEI ’07: Proceedings of the 1st international conference on Tangible and embedded interaction, S. 139–146,
New York, NY, USA, 2007. ACM Press.
[15] Kaltenbrunner, M. und R. Bencina: reacTIVision: a computervision framework for table-based tangible interaction. In: TEI ’07: Proceedings of the 1st international conference on Tangible and embedded
interaction, S. 69–74, New York, NY, USA, 2007. ACM Press.
[16] Köffel, C. A.: Heuristics for Tabletop Games. Diplomarbeit,
Fachhochschul-Masterstudiengang Digitale Medien in Hagenberg, Sep.
2007.
[17] Kojima, M., M. Sugimoto, A. Nakamura, M. Tomita, H. Nii und
M. Inami: Augmented coliseum: an augmented game environment with
small vehicles. In: Horizontal Interactive Human-Computer Systems,
2006. TableTop 2006. First IEEE International Workshop on, S. 6 pp.,
2006.
[18] Kurt, E. T.: Spooky Projects Class 3 , Okt. 2006. http://todbot.com/
blog/wp-content/uploads/2006/10/arduino spooky projects class3.pdf
Kopie auf CD-ROM (spooky projects class 3.pdf).
[19] Lee, W., W. Woo und J. Lee: TARBoard: Tangible Augmented Reality System for Table-top Game Environment. In: Proceedings of PerGames2005 , Munich, Germany, Mai 2005. ACM Press.
101
[20] Litzlbauer, W., I. Stuppacher, M. Waldner und M. Weilguny:
Neon Racer: Augmented Gaming. In: 10th Central European Seminar
on Computer Graphics, Castá-Papiernicka, Slovakia, Apr. 2006.
[21] Loenen, E. van, T. Bergman, V. Buil, K. van Gelder, M. Groten, G. Hollemans, J. Hoonhout, T. Lashina und S. van de
Wijdeven: Entertaible: A Solution for Social Gaming Experiences. In:
Tangible Play: Research and Design for Tangible and Tabletop Games,
Workshop at the 2007 Intelligent User Interfaces Conference, S. 16–19,
Honolulu, Hawaii, USA, 2007.
[22] Magerkurth, C., M. Memisoglu, T. Engelke und N. Streitz:
Towards the next generation of tabletop gaming experiences. In: GI ’04:
Proceedings of Graphics Interface 2004 , S. 73–80, School of Computer
Science, University of Waterloo, Waterloo, Ontario, Canada, 2004. Canadian Human-Computer Communications Society.
[23] Magerkurth, C., R. Stenzel und T. Prante: STARS – a ubiquitous computing platform for computer augmented tabletop games. In:
5th International Conference on Ubiquitous Computing, Seattle, WA,
USA, Okt. 2003.
[24] Mandryk, R. L. und D. S. Maranan: False prophets: exploring hybrid board/video games. In: CHI ’02: CHI ’02 extended abstracts on
Human factors in computing systems, S. 640–641, New York, NY, USA,
2002. ACM Press.
[25] Mazalek, A.: Media Tables: An extensible method for developing
multi-user media interaction platforms for shared spaces. Doktorarbeit,
Massachusetts Institute of Technology, Sep. 2005.
[26] Mazalek, A., B. Mironer, E. O’Rear und D. V. Devender: The
TViews Table Role-Playing Game. In: PerGames ’07 , S. pp.127–134.,
Salzburg, Austria, Juni 2007.
[27] Mazalek, A., M. Reynolds und G. Davenport: TViews: An Extensible Architecture for Multiuser Digital Media Tables. 26:47–55, 2006.
[28] Mellis, D. A., M. Banzi, D. Cuartielles und T. Igoe: Arduino:
An Open Electronics Prototyping Platform. In: CHI 2007 , San Jose,
USA, Apr. 2007. ACM Press.
[29] Mindell, D., C. Beland, W. Chan, D. Clarke, R. Park und
M. Trupiano: LEGO Mindstorms The Structure of an Engineering (R)evolution, Dez. 2000. http://web.mit.edu/6.933/www/Fall2000/
LegoMindstorms.pdf Kopie auf CD-ROM (lego mindstorms.pdf).
102
[30] Morris, M. R., A. Huang, A. Paepcke und T. Winograd: Cooperative gestures: multi-user gestural interactions for co-located groupware. In: CHI ’06: Proceedings of the SIGCHI conference on Human
Factors in computing systems, S. 1201–1210, New York, NY, USA, 2006.
ACM Press.
[31] Nguyen, H. T.: Tabletop Games as Social Catalysts. Doktorarbeit,
University of Illinois Urbana-Champaign, Aug. 2006.
[32] N.V., K. P. E.: Gaming just got better . http://www.consumer.philips.
com/media/master/consumer/microsites/ambx/pdf/ambx leaflet EN.pdf
Kopie auf CD-ROM (gaming just got better.pdf).
[33] O’Sullivan, D. und T. Igoe: Physical Computing: Sensing and Controlling the Physical World with Computers. Premier Press, Mai 2004.
[34] Poupyrev, I., T. Nashida und M. Okabe: Actuation and tangible
user interfaces: the Vaucanson duck, robots, and shape displays. In:
TEI ’07: Proceedings of the 1st international conference on Tangible
and embedded interaction, S. 205–212, New York, NY, USA, 2007. ACM
Press.
[35] Reuters: Wii are the champions? | Technology | Reuters,
Apr.
2007.
http://www.reuters.com/article/technologyNews/
idUSN0236164420070402?pageNumber=1&sp=true Kopie auf CDROM (wii are the champions.pdf).
[36] Rogers, Y., M. Scaife, E. Harris, T. Phelps, S. Price, H. Smith,
H. Muller, C. Randell, A. Moss, I. Taylor, D. Stanton,
C. O’Malley, G. Corke und S. Gabrielli: Things aren’t what they
seem to be: innovation through technology inspiration. In: DIS ’02: Proceedings of the conference on Designing interactive systems, S. 373–378,
[37] Schmalstieg, D., A. Fuhrmann, G. Hesina, Z. Szalavári, L. M.
Encarnaçäo, M. Gervautz und W. Purgathofer: The studierstube augmented reality project. Presence: Teleoper. Virtual Environ.,
11(1):33–54, 2002.
[38] Shen, C., K. Ryall, C. Forlines, A. Esenther, F. D. Vernier,
K. Everitt, M. Wu, D. Wigdor, M. R. Morris, M. Hancock
und E. Tse: Informing the Design of Direct-Touch Tabletops. IEEE
Comput. Graph. Appl., 26(5):36–46, 2006.
[39] Sluis, R. J. W., I. Weevers, C. H. G. J. van Schijndel,
L. Kolos-Mazuryk, S. Fitrianie und J. B. O. S. Martens: ReadIt: five-to-seven-year-old children learn to read in a tabletop environ-
103
ment. In: IDC ’04: Proceeding of the 2004 conference on Interaction
design and children, S. 73–80, New York, NY, USA, 2004. ACM Press.
[40] Steiner, H.-C.: Arduino playground : Firmata. URL, http://www.
arduino.cc/playground/Interfacing/Firmata, Juli 2007. Kopie auf CDROM (arduino playground firmata.pdf).
[41] Streitz, P. T. N.: Roomware: Towards the next generation of humancomputer interaction based on an integrated design of real and virtual
worlds. In: Carroll, J. (Hrsg.): Human-Computer Interaction in the
New Millenium, S. 553–578. Addison-Wesley, Aug. 2001.
[42] Sugimoto, M., K. Hosoi und H. Hashizume: Caretta: a system for
supporting face-to-face collaboration by integrating personal and shared
spaces. In: CHI ’04: Proceedings of the SIGCHI conference on Human
factors in computing systems, S. 41–48, New York, NY, USA, 2004.
ACM Press.
[43] Valli, A.: Notes on Natural Interaction. http://www.idemployee.id.
tue.nl/g.w.m.rauterberg/lecturenotes/valli-2004.pdf Kopie auf CD-ROM
(notes on natural interaction.pdf).
[44] Virtools SA: Virtools SDK Documentation. Virtools 4 DistributionsDVD, 2006. Kopie auf CD-ROM (virtools sdk documentation.chm).
[45] Wilson, A. D.: PlayAnywhere: a compact interactive tabletop
projection-vision system. In: UIST ’05: Proceedings of the 18th annual
ACM symposium on User interface software and technology, S. 83–92,
[46] Wilson, A. D. und D. C. Robbins: Playing Games across Multiple Interactive Tabletops. In: Tangible Play: Research and Design for
Tangible and Tabletop Games, Workshop at the 2007 Intelligent User
Interfaces Conference, Honolulu, Hawaii, USA, 2007.
Messbox zur Druckkontrolle
— Druckgröße kontrollieren! —
Breite = 100 mm
Höhe = 50 mm
— Diese Seite nach dem Druck entfernen! —
104

Ein interaktives Tabletop-Spiel auf Basis von Arduino und Virtools

Transcription

Similar documents

Grundwissen Elektronik

Geometriekorrektur von Stereo

Bedienungsanleitung UR10, Version 3.0

PDF, 519,4 KB