Stationäres Multiplayer Game mit Smartphone I/O

Fachbereich 4: Informatik
Stationäres Multiplayer Game mit
Smartphone I/O
Masterarbeit
zur Erlangung des Grades eines Master of Science (M.Sc.)
im Studiengang Computervisualistik
vorgelegt von
Gerrit Lochmann
Erstgutachter:
Prof. Dr. Stefan Müller
Institut für Computervisualistik, AG Computergraphik
Zweitgutachter:
Dipl.-Inform. Dominik Grüntjens
Institut für Computervisualistik, AG Computergraphik
Koblenz, im April 2012
Erklärung
Ich versichere, dass ich die vorliegende Arbeit selbständig verfasst und
keine anderen als die angegebenen Quellen und Hilfsmittel benutzt habe.
Ja
Nein
Mit der Einstellung der Arbeit in die Bibliothek bin ich einverstanden.
Der Veröffentlichung dieser Arbeit im Internet stimme ich zu.
.................................................................................
(Ort, Datum)
(Unterschrift)
a
Inhaltsverzeichnis
1
Einleitung
3
1.1
Szenario 1: Im Wartebereich eines Flughafens . . . . . . . . .
4
1.2
Szenario 2: Eine Stadtrallye . . . . . . . . . . . . . . . . . . .
5
1.3
Szenario3: Ein werbewirksamer Eyecatcher in der Fußgänger-
1.4
zone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
Verwandte Arbeiten
6
1.4.1
. . . . . . . . . . . . . . . . . . . . . . .
„Using a Mobile Phone as a ’Wii-like’ Controller for
Playing Games on a Large Public Display“ . . . . . .
1.4.2
„Smartymote: Revolutionizing the Gaming and Social
Experience“ . . . . . . . . . . . . . . . . . . . . . . . .
1.5
Konzept des Smartphone-Controllers
2.1
2.2
3
9
11
Statistiken über die Nutzung von Smartphones und Mobile
Games . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
Smartphones als Videospielplattform . . . . . . . . . . . . . .
12
Analyse der Design Parameter von Multiplayer Games
15
3.1
Auswirkung der Kommunikation auf das Multiplayer Erlebnis 15
3.2
Psychologische Kommunikationsmodelle im Videospielkontext 16
3.3
4
8
Formulierung der wissenschaftlichen Fragestellungen und
Abgrenzung zu verwandten Arbeiten . . . . . . . . . . . . .
2
7
3.2.1
Symbolvarietät . . . . . . . . . . . . . . . . . . . . . .
18
3.2.2
Geschwindigkeit des Feedbacks . . . . . . . . . . . .
19
Schlussfolgerung der kommunikationspsychologischen Betrachtung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
3.4
Kommunikationsförderndes Game-Design . . . . . . . . . .
23
3.5
Private und öffentliche Spielansichten . . . . . . . . . . . . .
24
3.6
Menünavigation in Multiplayer Games . . . . . . . . . . . .
27
Konzeption einer Beispielanwendung
29
4.1
Spezifikationen . . . . . . . . . . . . . . . . . . . . . . . . . .
29
4.2
Ausarbeitung des Game-Designs für einen Prototypen . . .
31
4.2.1
Die Zwille . . . . . . . . . . . . . . . . . . . . . . . . .
32
4.2.2
Der Schießstand . . . . . . . . . . . . . . . . . . . . . .
33
Spielregeln im Singleplayer Modus . . . . . . . . . . . . . . .
34
4.3
i
5
4.4
Spielregeln im Multiplayer Modus . . . . . . . . . . . . . . .
36
4.5
Menünavigation und GUI-Elemente . . . . . . . . . . . . . .
37
4.5.1
Private Informationen auf dem Smartphone . . . . .
37
4.5.2
Öffentliche Informationen auf dem Monitor . . . . .
41
Technische Umsetzung
42
5.1
Gerätespezifikation und verwendete Technologien . . . . . .
42
5.2
Bluetooth Verbindung und Messagehandling . . . . . . . . .
43
5.2.1
Verworfener Ansatz: Winsock 2 Bindings für Python
45
5.2.2
Threading innerhalb der C++ Shared Library . . . . .
45
5.3
5.4
6
Implementierung der Clientanwendung unter Verwendung
des Android SDK . . . . . . . . . . . . . . . . . . . . . . . . .
46
5.3.1
Implementierung der Zwille . . . . . . . . . . . . . .
46
5.3.2
Zielvorgang und Abfeuern der Projektile . . . . . . .
48
5.3.3
Anzeige der Schussrichtung . . . . . . . . . . . . . . .
51
Implementierung der Serveranwendung unter Verwendung
der Blender Game Engine . . . . . . . . . . . . . . . . . . . .
52
5.4.1
Blender Logic Bricks . . . . . . . . . . . . . . . . . . .
53
5.4.2
Erweiterung durch Python Scripting . . . . . . . . . .
54
5.4.3
Physikalische Modellierung der dynamischen Objekte 56
5.4.4
Implementierung des dynamischen Objektverhaltens
59
Evaluation der Beispielanwendung
61
6.1
Vorstellung der Probandengruppe . . . . . . . . . . . . . . .
61
6.2
Die Singleplayer Phase . . . . . . . . . . . . . . . . . . . . . .
63
6.2.1
Testverlauf und Zielsetzung der Phase . . . . . . . . .
63
6.2.2
Ergebnisauswertung und Erkenntnisse . . . . . . . .
65
Die Multiplayer Phase . . . . . . . . . . . . . . . . . . . . . .
73
6.3.1
Testverlauf und Zielsetzung der Phase . . . . . . . . .
74
6.3.2
Ergebnisauswertung und Erkenntnisse . . . . . . . .
74
6.3
7
Fazit
77
8
Ausblick
79
ii
Abstract (de)
Videospiele gewinnen zunehmend an Popularität und stellen im privaten Umfeld eine häufig genutzte Unterhaltungsform dar. Im öffentlichen
Umfeld hingegen, zum Beispiel im touristischen Kontext oder bei Gruppenaktivitäten, kommt ihnen nur eine geringe Bedeutung zu.
Konsolen- und Arcadespiele, bei denen die Spieler gemeinsam einen großen
Bildschirm betrachten, können zwar das Gemeinschaftsgefühl stärken, allerdings sind diese Geräte für gewöhnlich nicht in der Öffentlichkeit vorzufinden. Eher werden private portable Spielkonsolen oder Smartphones
für das Spielen an diesen Orten verwendet. Jedoch verhindert das kleine
Display und die eingeschränkte Interaktionsweise, dass eine starke soziale
Atmosphäre zwischen Mitspielern und Zuschauern erzeugt wird, weshalb
sich diese Systeme nur schlecht für öffentliche Gruppenaktivitäten und
touristische Zwecke eignen.
Daher wird in dieser Arbeit ein hybrides Konzept vorgestellt, das die Vorteile eines Smartphones mit denen eines großen interaktiven Bildschirms
verbindet. Es wurden Interaktionsmethoden entwickelt, welche die spezifischen Eigenschaften des Smartphones, wie den Touchscreen, seine Konnektivität und seine Sensorik nutzbar machen, um mit den komplexen
Grafiken auf einem Bildschirm zu interagieren, welche wiederum von der
Rechenleistung des stationären Computers profitieren.
Anschließend wurde ein smartphonegesteuertes stationäres Multplayer
Game unter Berücksichtigung etablierter Videospielparadigmen implementiert, das im Rahmen einer Evaluation auf seine Benutzerfreundlichkeit und
sozialen Aspekte hin untersucht wurde.
1
Abstract (en)
Video games are quickly rising in popularity. They are often played in
private, but in public they are rarely used as a tourist attraction or a group
activity.
If all players play on a single display, console and arcade games are able to
create a social atmosphere. However, generally they are not used in public
places. In contrast, portable consoles or smartphones are commonly played
with in such places. Anyway, due to of their small displays they can not
create a social atmosphere among players and an audience. Hence, they are
not well-suited for a tourist attraction.
The thesis at hand aims to create a hybrid concept, combining the advantages
of a smartphone and a large interactive screen. To achieve this, interaction
methods have been developed which use the specific features of the smartphone such as its touch-screen, its connectivity and its sensors. The graphics
on the display profit by the PC’s computing power.
A smartphone-driven stationary multi player video game was created, considering established design paradigms for video games. Finally, the game
was evaluated to consider the usability and social aspects of the hybrid
concept.
2
1
Einleitung
Durch portable Computer, angefangen beim Nintendo GameBoy bis zum
modernen Smartphone können an jedem erdenklichen Ort Videospiele gespielt werden. Mobile Spiele auf diesen Geräten eignen sich jedoch nur
bedingt für Gruppenaktivitäten und touristische Zwecke. Zwar besitzen die
gängigsten portablen Geräte eine Verbindungsschnittstelle für einen Multiplayer Modus, streng genommen wird jedoch nicht ein Medium gemeinsam
konsumiert, sondern jeder Spieler betrachtet seinen eigenen Bildschirm.
Die Interaktion findet lediglich auf virtueller Ebene statt. Zudem ist es
für Außenstehende schwierig, ein Spiel mitzuverfolgen oder zumindest
ihr Interesse zu wecken, um somit eine soziale Gruppe zu involvieren. Es
existieren Unterhaltungsformen, die genau darauf abzielen und für die der
Spaß am gemeinsamen Betrachten des Unterhaltungsmediums ein wichtiger
Aspekt ist. Dies sehen wir an der Tatsache, dass sich Menschen treffen, um
etwa einen Kinofilm anzusehen oder gemeinsam touristische Attraktionen
zu besuchen. Computerspiele haben bereits in Form von „Pervasive Games“
Einzug in die Öffentlichkeit gehalten (siehe [Pri06]). Beispielsweise erhält
der Spieler bei dem Spiel „REXplorer“ einen elektronischen Detektor, der
mittels GPS prüft, ob sich der Spieler an einem interaktiven Ort im Sinne
des Spiels befindet. Führt der Spieler an diesem Ort eine bestimmte Geste
mit dem Gerät aus, spielt der Detektor eine Audiodatei ab, die das nächste
Ziel mitteilt (siehe [WBB+ 06]).
Potenzielle Interessenten geraten jedoch so lange nicht in Kontakt mit diesen
Spielen, bis sie sie aus eigener Initiative aufsuchen. Videospiele sind somit
keine Form der Unterhaltung, die an den Konsumenten bei einem touristischen Stadtbesuch herangetragen werden kann, wie etwa das Musikangebot
auf einer Bühne, eine Skulptur oder die Vorstellung eines PerformanceKünstlers. Diese Einschränkung hat eine pragmatischen Ursache: Videospiele grenzen sich besonders durch ihre Interaktivität von derartigen Unterhaltungsformen ab. Die Konsumenten müssen aktiv werden und die
Möglichkeit haben, Spielzüge zu tätigen.
Eine Lösung stellt das in dieser Arbeit vorgestellte Computer Setup dar:
Während das hauptsächliche Spielgeschehen auf einem öffentlichen stationären Server berechnet wird, dessen Bildausgabe auf einem von allen
3
Abbildung 1: Schematische Darstellung des Setups: Zwei Spieler interagieren
gleichzeitig mit Hilfe ihrer Smartphones mit dem Kiosksystem. Dieses besteht aus einem Server und einem großen Bildschirm.
Spielern gut einsehbaren Monitor erfolgt (im Folgenden „Kiosksystem“ genannt), findet die Eingabe der Spielzüge über die privaten Smartphones der
Spieler statt (siehe Abbildung 1).
In den folgenden denkbaren Benutzerszenarien werden Situationen beschrieben, in denen das Konzept eines stationären Multiplayer Games mit
Smartphone I/O Anwendung finden könnte und wie es auf Spieler und
Betrachter wirken würde.
1.1
Szenario 1: Im Wartebereich eines Flughafens
Der Flughafen in diesem fiktiven Szenario ist Dreh- und Angelpunkt für
den Tourismus einer naheliegenden Großstadt. Einstündige Wartezeiten im
Gate sind gängig und werden von Reisenden zum Beispiel für einen Einkauf
in Flughafengeschäften genutzt. Interaktive Unterhaltungsmedien stellen
eine Alternative dar, die Zeit kurzweilig zu überbrücken und sind hier in
Form von mobilen Videospielen häufig zu beobachten. Ein Kiosksystem,
das ein stationäres Videospiel mit Smartphone I/O betreibt, wurde in der
Nähe von Sitzgelegenheiten platziert und weckt durch eine Animation die
Neugierde einiger Wartender. Eine Anzeige fordert zum Download der
Anwendung aus dem Softwaremarkt des Smartphones auf. Eine Person
ergreift die Initiative, lädt die Steuerungsanwendung herunter und beginnt
spielerisch mit den Grafiken auf dem Bildschirm zu interagieren, wäh4
rend sie von ihren Freunden und Dritten beobachtet wird. Dadurch wird
die Neugierde weiterer Personen geweckt. Neue Mitspieler laden die Anwendung ebenfalls herunter und treten dem Spiel bei. Die unkomplizierte,
selbsterklärende Steuerung und das auf Vorwissen aufbauende Spielprinzip
ermöglichen, dass das Spiel ohne längere Eingewöhnungszeit verstanden
wird und gespielt werden kann. Das Thema des Spiels ist an das Ziel des
Fluges angepasst und erhöht die Vorfreude auf die Reise. Das Spiel schafft
eine kommunikative und soziale Atmosphäre, bis das Flugzeug betreten
werden kann.
1.2
Szenario 2: Eine Stadtrallye
Eine Gruppe von Smartphonebesitzern, aus der bereits einige erste Erfahrungen mit stationären Multiplayer Games mit Smartphone I/O gemacht
haben, trifft sich in der Stadt, um eine Rallye zu veranstalten. Dazu laden
alle Spieler eine Client-Anwendung herunter, in welche sie ihre Spielerdaten, wie Namen und Spielerfarbe eingeben. Die Rallye besteht aus fünf
Stationen, die über einen Stadtplan gefunden werden können und jeweils
ein Kiosksystem aufweisen. Wird eine Station erreicht, lassen Spieler ihre
Clients eine Verbindung zum Server herstellen. An jeder Station wartet
eine andere Herausforderung auf die Spieler, in der mittels Bewegung des
Smartphones und geschickter Benutzung des Touchscreens Aufgaben auf
dem großen Monitor des Kiosksystems erfüllt werden müssen. Eine der
Aufgaben besteht darin, Zielscheiben auf dem Bildschirm zu treffen. Auf
dem Touchscreen jedes Spielers wird dazu eine Zwille angezeigt, deren
Gummiband bestückt mit einem Projektil gespannt werden kann, indem es
mit dem Finger heruntergezogen wird. Die Orientierung des Smartphones
gibt die Schussrichtung an, so dass eine natürliche Zielbewegung entsteht.
Der Spieler, der die meisten Zielscheiben trifft, erhält die höchste Punktzahl. Die Punkte aller Stationen werden auf dem Smartphone gespeichert
und können mit den Punkten anderer Spieler verglichen werden. Das Spiel
ermöglicht es, den Stadtbesuch mit einem spielerischen Ziel zu verbinden
und somit ein spannendes Gruppenerlebnis zu schaffen.
5
1.3
Szenario3: Ein werbewirksamer Eyecatcher in der Fußgängerzone
In der hochfrequentierten Fußgängerzone einer Großstadt werben ansässige
Einzelhandelsunternehmen vorbeiziehende Kunden mit Produktwerbung
und Eyecatchern in ihren Schaufenstern. Ein Sportartikelgeschäft platziert
im Schaufenster einen großen Bildschirm, auf dem ein stationäres Multiplayer Game mit Smartphone I/O angezeigt wird. In diesem Spiel muss
mit dem Smartphone die Bewegung eines Tennisschlägers nachempfunden
werden, um einen virtuellen Schläger zu schwingen und „das Match zu
gewinnen“. Passanten werden mit einem kurzen Einführungsvideo neugierig gestimmt und möchten die dort aufgezeigte Interaktionsmöglichkeit
mit ihren eigenen Smartphones erkunden. Dadurch, dass die Verbindung
des Smartphones mit dem Spielserver drahtlos erfolgt und sich das Spiel
vollständig mit dem Smartphone steuern lässt, können alle nötigen Schritte
zum Verbindungsaufbau selbstständig vor dem Schaufenster ausgeführt
werden. Auch zwei, drei oder vier Spieler können gleichzeitig an dem Spiel
teilnehmen. Da sich das Angebot hinter diesem Schaufenster durch seine Interaktivität von anderen abhebt, wirkt es verblüffend auf Betrachter,
Spieler und spätere Kunden. Nicht nur das Spiel ansich, sondern auch die
ungewöhnliche Tatsache, dass Menschen vor dem Schaufenster stehen und
ein Spiel spielen ist werbewirksam.
1.4
Verwandte Arbeiten
Thoresson beschrieb 2003 in seinem Paper „PhotoPhone Entertainment“ wie
Handys dazu genutzt werden können, mit großen öffentlichen Bildschirmen
spielerisch zu interagieren. Ein Spielzug des von ihm vorgestellten Systems
besteht darin, ein Foto mit der Handykamera aufzunehmen, welches anschließend per Email an einen Spielserver gesendet wird, der dieses mittels
Bildverarbeitungsalgorithmen auswertet. Das Ergebnis des Spielzugs wird
anschließend auf einem großen öffentlichen Display angezeigt. Das folgende
Zitat beschreibt ein Spielkonzept, welches auf diese Weise umsetzbar wäre:
„Bus stop wrestling is a one-on-one wrestling game to be played between
people on the bus stop. It is based on the old stone-scissors-paper-principle,
but in this application, a reddish photo beats a greenish, a greenish beats
6
Abbildung 2: Links: Ein Screenshot aus dem Spiel „Tilt Racer“. Die Autos werden
durch Neigen des Handys gesteuert. Rechts: Tilt-Racer Spieler auf
einer Konferenz.
a bluish and finally a bluish beats a reddish. Animations of the wrestling
game is displayed on a large display at the bus stop.“ ([Tho03])
Da moderne Smartphones im Vergleich zu den hier verwendeten Kamerahandys viele weitere Sensoren, wie ein Accelerometer aufweisen, entstanden
Ideen, auch diese zur Interaktion mit großen öffentlichen Bildschirmen zu
nutzen. Im Folgenden werden zwei Arbeiten vorgestellt, in denen derartige
Konzepte umgesetzt wurden.
1.4.1
„Using a Mobile Phone as a ’Wii-like’ Controller for Playing Games on a Large Public Display“
In der Spielumsetzung dieser Arbeit (siehe [VCBE08]) verwenden die Teilnehmer Nokia 5500 Handys, die mit einem 2D Beschleunigungssensor ausgestattet sind. Sie interagieren innerhalb einen Multiplayer Games miteinander, das auf einem großen öffentlichen Bildschirm angezeigt wird. Die
dazu entwickelte Spielsoftware „Tilt Racer“ stellt, wie Abbildung 2 zeigt,
eine Rennstrecke aus der Vogelperspektive dar, während jeder Spieler durch
Neigen des Handys ein Fahrzeug steuert.
Als Vorteile des Handy-Controller Systems werden genannt, dass Spieleentwickler nicht auf die grafischen Fähigkeiten des Handys beschränkt sind,
sondern die erweiterte Rechenleistung des stationären Computers genutzt
werden kann. Vom interaktiven Standpunkt gesehen, wird es als positiv
7
Abbildung 3: Der Spieler steuert in „Smartymote“ den violetten Kreis, mit dem er
blaue Kreise einsammeln und weißen Kreisen ausweichen muss.
bewertet, dass die Spieler Bewegungsabläufe durchführen müssen und eine
starke soziale Atmosphäre erzeugt wird. Zudem erkennen die Entwickler
das Potenzial, das Setup an öffentlichen Plätzen auszustellen und somit eine
Gelegenheit für soziale Interaktion zu schaffen.
1.4.2
„Smartymote: Revolutionizing the Gaming and Social Experience“
In dieser Konzeptstudie wird dieser Gedanke ausgeweitet und ein konkretes Nutzerszenario vorgestellt: Wird die spezielle Smartphone-Anwendung
„Smartymote“ (siehe [Bae11]) gestartet, erhält der Benutzer auf einem interaktiven Stadtplan Informationen über die Standorte, an denen sich Kiosksysteme befinden, mit denen er interagieren kann. Befindet sich der Spieler
in der Nähe einer Station, wird er durch ein Signal seines Smartphones,
beispielsweise einen Vibrationsalarm, hierauf aufmerksam gemacht. Hat
der Spieler den Bildschirm entdeckt, kann er mit diesem interagieren, indem er eine Wurfbewegung mit seinem Smartphone andeutet, die mit Hilfe
der Beschleunigungssensoren erfasst wird. Ein 30 sekündiges Singleplayer
Game wird gestartet, in welchem das Smartphone als Controller fungiert.
Mittels Neigung des Smartphones wird ein farbiger Kreis beschleunigt, mit
dem Ziel, anderen Kreisen auszuweichen oder sie einzusammeln (siehe
Abbildung 3).
Ein weiterer Fokus wird auf die soziale Komponente des Systems gelegt. Im
Gegensatz zum zuvor beschriebenen Spiel „Tilt Racer“ findet die Interaktion
mit anderen Spielern über soziale Netzwerke und somit asynchron statt. Die
erreichte Punktzahl wird zusammen mit den GPS-Koordinaten des Spielers
und einem Foto der Smartphonekamera auf einen Webserver geladen und
8
ist über einen Webservice für andere Spieler einsehbar. Kommunikation
zwischen den Spielern kommt somit erst dann zustande, wenn ein anderer
Spieler die Informationen zu einem späteren Zeitpunkt abruft.
1.5
Formulierung der wissenschaftlichen Fragestellungen und Abgrenzung zu verwandten Arbeiten
Eine Umfrage im Rahmen dieser Arbeit unter 16 Studenten ergab, dass die
Motivation, ein Videospiel in der Öffentlichkeit zu spielen, wesentlich geringer ist als im privaten Umfeld. Neun der Befragten (56%) sind nach eigener
Angabe dadurch gehemmt, dass sie sich beobachtet fühlten. Des Weiteren
wurde von sieben Befragten (44%) angegeben, dass ihnen die Zeit fehlt, sich
mit dem Spiel zu beschäftigen, während jedoch nur drei Studenten (19%)
angaben, dass ihnen das Interesse an Videospielen im Allgemeinen fehlt.
Aus diesen Gründen sollte bei der Konzeption eines Spiels für den öffentlichen Einsatz berücksichtigt werden, dass die Motivation zu spielen spontan
entstehen muss, ganz so wie es im Flughafen-Szenario (siehe Kapitel 1.1)
beschrieben wurde.
Die grundlegende Annahme dieser Arbeit lautet, dass eine besonders intuitive Form der Interaktion erforderlich ist, um diese Skepsis zu vermindern
und einen einfachen Zugang zum Spiel zu gewährleisten. Die Untersuchung
der Interaktion teilt sich in zwei Aspekte auf, die in dieser Arbeit behandelt
werden:
1. Die Interaktion eines Spielers mit dem Spiel
2. Die Interaktion zwischen den Spielern untereinander.
Jesper Juul beschreibt in seinem Buch „A Casual Revolution: Reinventing
Video Games and Their Players“, dass die Interaktion zwischen Spieler
und Spiel durch intuitive Eingabegeräte mit mimetischem Interface stark
vereinfacht wird, wodurch zunehmend Gelegenheitsspieler angesprochen
werden (vergleiche [Juu09], S.5). Am Beispiel des Nintendo Wiimote Controllers wird aufgezeigt, wie die Verdrossenheit gegenüber Videospielen
dadurch gemindert wird, dass die Interaktion mit dem Spiel mittels natürlicher Bewegungsabläufe stattfindet. Das Konzept der vorliegende Arbeit
baut daher auf den Konzeptstudien der beiden zuvor beschriebenen Ar9
beiten auf. Der intuitive, bewegungsgesteuerte Smartphone-Controller, der
den Spieler mit zusätzlichen Informationen über das Spiel versorgt, entspricht dem Smartymote Konzept. Im Gegensatz zu Tilt Racer werden in
dieser Arbeit Geräte mit einem Touchscreen verwendet. Dadurch erhält der
Spieler mehr Interaktionsmöglichkeiten, die im Spielkonzept berücksichtigt
werden: Die Gesten, die durch die Accelerometer des Smartphones erkannt
werden, sollen durch Zeigegesten auf dem Touchscreen erweitert werden.
Um der dadurch steigenden Komplexität des Spiels entgegenzuwirken, soll
das Vorwissen der Spieler aus der realen Welt genutzt werden können. Dies
erfordert, dass sich die Bedienmetaphern dreidimensionaler Bewegungen
und Zeigegesten an realen Objekten orientieren und diese so naturgetreu
wie möglich abbilden. Dies wird durch einen geringen Abstraktionsgrad der
Grafiken, beziehungsweise durch die Darstellung realitätsgetreuer Objekte
in einem virtuellen dreidimensionalen Raum erzeugt.
Eine zentrale Fragestellung dieser Arbeit zielt somit darauf ab, in welchem
Maße die technischen Möglichkeiten des PCs und des Smartphones dazu
genutzt werden können, diese Interaktion aus natürlicher Bewegung und
realitätsgetreuem computergrafischem Feedback herzustellen. Dazu soll ein
etabliertes Game Engine Framework um Module erweitert werden, die eine
Schnittstelle für den Smartphone-Controller bereitstellen. Dadurch soll es
möglich sein, mit Hilfe visueller Programmierung, high-level Skriptsprachen sowie einer leistungsstarken Modellierungs- und Animationssoftware
dynamische und grafisch anspruchsvolle Szenen zügig zu erstellen und mit
diesen via Smartphone zu interagieren.
Die Interaktion der Spieler untereinander ist eine weiterer Aspekt, der in dieser Arbeit behandelt werden soll. Allerdings wird der Fokus hier nicht auf
ein asynchrones Multiplayer Game und die Eingliederung in Soziale Netzwerke wie am Beispiel von Smartymote gelegt, sondern auf das gemeinsame
Spielen an einem öffentlichen Bildschirm, wie im Beispiel von Tilt Racer.
Diese Entscheidung wird aus psychologischer Sicht in Kapitel 3 begründet.
Die Konzeption und Entwicklung einer Beispielanwendung in Kapitel 4
und 5 sowie die Evaluation durch Probanden dienen dazu, die in Kapitel 6
aufgestellten Hypothesen zu untersuchen und zu diskutieren.
10
2
Konzept des Smartphone-Controllers
Die Idee, das Smartphone als Controller zu verwenden rührt von der Tatsache, dass moderne Smartphones viele Funktionen der Controller moderner
Spielekonsolen, wie der Nintendo Wiimote Fernbedienung, besitzen. Beide
Geräte weisen Beschleunigungssensoren und eine Kamera (im Falle der Wiimote eine Infrarot Kamera) auf, mit deren Hilfe Bewegungen in Spielzüge
umgewandelt werden können. Dies lässt eine besonders intuitive Steuerung
des Spiels zu. Beide unterstützen eine Vibrationsfunktion für haptisches
Feedback und Lautsprecher für akustisches Feedback. Da diese Signale vom
Controller ausgehen, können Spieler unabhängig voneinander adressiert
werden. Zudem bieten beide Geräte die Möglichkeit der kabellosen Datenübertragung, um Informationen über Ein- und Ausgaben mit einem Server
auszutauschen und einen internen Speicher, um persönliche Einstellungen
zu sichern. Fehlende Bedienelemente, wie die Buttons des Controllers können auf dem Touchscreen des Smartphones dargestellt oder durch eine
spezielle Belegung der physischen Tasten ersetzt werden. Zudem sind beide Geräte sowohl für die Einhandnutzung als auch für die beidhändige
Nutzung in horizontaler Lage ausgelegt.
Die Voraussetzung dafür, dass der Spielserver mit dem Smartphone kommuniziert, ist eine Applikation, die auf dem Smartphone ausgeführt wird,
um die oben genannten Funktionen bereitzustellen. Über die Eingabe- und
Ausgabemöglichkeiten eines Controllers hinaus bieten Smartphones natürlich viele weitere Funktionen, die im Kontext eines Spiels nutzbar sind. Das
auffälligste Feature ist der Bildschirm zur Darstellung von Spielinhalten,
welche die Informationen auf dem Monitor ergänzen. Zudem verfügen
moderne Smartphones über hohe eigene Rechenleistung, die zur Verteilung
von Spielberechnungen genutzt werden kann.
2.1
Statistiken über die Nutzung von Smartphones und Mobile
Games
Langfristig gesehen erfüllt ein großteil der westlichen Bevölkerung die Voraussetzung, ein kompatibles Eingabegerät mit sich zu führen und dieses
potenziell zum Spielen von Videospielen zu benutzen. Der Grund für die-
11
Abbildung 4: Der Anteil der Smartphone-Nutzer an allen Handybesitzern in den
einzelnen untersuchten Ländern
se Annahme liegt in der hohen Akzeptanz von Smartphones und Mobile
Games und der rapide steigenden Benutzerzahlen. Wie Abbildung 4 zeigt,
ergab die Comsore-Studie, dass im Dezember 2011 in Deutschland 37%
der Handynutzer ein Smartphone besitzen. Zudem prognostiziert die Studie, dass in Europa und den fünf großen europäischen Ländern im Jahr
2012 mehr Menschen ein Smartphone besitzen werden als ein Handy (siehe
[Mel11]). In der Videospielindustrie werden Smartphones als zukunftssichere Plattform angesehen. Nach Angaben der Entertainment Software
Association ([Esa11]) spielten im Jahr 2010 in den USA 55% der Videospieler
an mobilen Geräten wie Smartphones oder Handhelds. Unter den mobilen
Betriebssystemen stellen Google Android und Apple iOS die kommerziell attraktivsten Plattformen für Spieleentwickler dar. Auf dem US-Markt
stieg der Marktanteil der Spiele für mobile Geräte mit diesen SmartphoneBetriebssystemen im Vergleich zu anderen portablen Plattformen von 19%
im Jahr 2009 auf 34% im Folgejahr, was einem Umsatz von 800 Millionen USDollar entsprach und damit den auf 700 Millionen US-Dollar geschätzten
Umsatz mit PC-Spielen überholte (siehe [Ste11]).
2.2
Smartphones als Videospielplattform
Um die Fähigkeiten des Smartphones bei der Entwicklung eines stationären
Multiplayer Games mit Smartphone I/O auszunutzen, ist es sinnvoll, einen
12
Blick auf die Produkte der Videospielindustrie zu werfen. Im Folgenden
sollen daher die Eigenschaften neuster Smartphones und deren Nutzung in
Videospielen analysiert werden.
Moderne Smartphones verfügen über weitreichenden Multimediafähigkeiten, welche über die zur Businessnutzung notwendigen Anforderungen
weit hinausgehen. Viele Smartphonehersteller haben den Anspruch, die
Rechenleistung eines vollwertigen Multimedia-PCs mobil zugänglich zu
machen. Die Taktrate neuester High-End-Geräte befindet sich im Gigahertzbereich unter Verwendung eines Mehrkernprozessors. NVIDIAs mobiler
Quad-Core Prozessor TEGRA3 arbeitet beispielsweise mit einer Taktfrequenz von 1,4 GHz auf vier Kernen, besitzt einen L2 Cache von 1MB und
einen L1 Cache von 32KB pro Kern sowie einen Arbeitsspeicher von bis zu
2 GB. Die GPU des Chips enthält 12 voll programmierbare Grafik-Kerne
mit OpenGL ES 2.0 Spezifikation (siehe [NVI12]). Komplexe Spielgrafik
wird dadurch ebenso unterstützt wie rechenaufwändige Spielinhalte und
echtzeitfähige physikalische Berechnungen.
Die Interaktion mit einem Smartphone erfolgt zum Teil über physische
Tastaturen, die entweder einen erweiterten Nummernblock, oder eine vollständige QWERTZ-Belegung aufweisen. Die meisten neueren Geräte verzichten jedoch aus Portabilitätsgründen auf einen solchen Eingabebereich
zu Gunsten eines großflächigen Touchscreens, auf welchem entweder eine
vollständige Tastatur oder lediglich inhaltsbezogene Buttons dargestellt
werden. Im Kontext von Computerspielen werden häufig Bedienelemente
dargestellt, die in ihrer Funktionalität Analogsticks oder Buttons auf einem
Gamecontroller nachempfunden sind. Darüber hinaus können durch die
Verwendung der Multi-Touch-Technologie mehrere Buttons gleichzeitig aktiviert werden, wodurch das Look and Feel eines Controllers realitätsgetreu
nachempfunden werden kann. Neben der Metapher einer Tastatur wird der
Touchscreen häufig auch als Zeigegerät verwendet, um direkt mit Spielelementen zu interagieren. Zum Beispiel wird in dem Spiel Angry Birds1 eine
virtuelle Zwille dadurch gespannt, dass eine entsprechende Ziehgeste mit
dem Finger ausgeführt wird.
Smartphones unterstützen gängige Wireless LAN und 3G Mobilfunkstandards zur IP-Verbindung von Endgeräten, sowie Bluetooth, für die direk1
Angry Birds, Rovio Entertainment Ltd., 2009, http://www.angrybirds.com/
13
te Kommunikation zweier gepaarter Geräte. Dadurch wird das Ausführen plattformübergreifender Server-Clientanwendungen beziehungsweise
Netzwerk vermittelter Multiplayer Games ermöglicht. Zudem werden Anwendungen auf diesen Systemen ausschließlich als Download über die
Internet-Verkaufsportale Google Play und Apple Appstore vertrieben, was
den Veröffentlichungsprozess neuer Software stark vereinfacht. Ein interner
Speicher im zweistelligen Gigabyte Bereich lässt die persistente Speicherung
von Spielinhalten wie Grafik- und Audiodateien zu. Auch ermöglicht dieser
die Speicherung von Benutzerdaten, Spielfortschritten und -konfigurationen
sowie deren mobilen Zugriff.
Des Weiteren verfügen Smartphones über Funktionen, welche die Mobilität
der Hardware ausnutzen und über die Fähigkeiten eines PCs hinaus gehen.
Beschleunigungssensoren sowie ein integrierter Kompass lassen Rückschlüsse darauf ziehen, in welcher Lage das Smartphone gehalten wird. In den
meisten Smartphone-Anwendungen wird durch die Änderung der Lage ein
Wechsel zwischen dem Portrait- und dem Landscape Modus durchgeführt.
In vielen Spielen wirkt sich die Neigung des Smartphones direkt auf die
Steuerung aus. Beispielsweise führt in Rennspielen wie Need For Speed Undercover2 für das iPhone das Kippen des Smartphones zur Drehbewegung
des virtuellen Lenkrads des gesteuerten Fahrzeugs. Ursprünglich für Navigationssoftware verbaute GPS Sensoren erlauben die metergenaue Ortung
des Geräts und kommen insbesondere bei Pervasive Games und Location
Based Games, wie Parallel Kingdom3 zum Einsatz.
Smartphones verfügen über Kameras im Megapixelbereich. Im Zusammenhang mit der oben genannten Grafik- und Prozessorleistung lassen
sich komplexe Bildverarbeitungsalgorithmen, beispielsweise zur Mustererkennung, in Echtzeit ausführen, wodurch sich die Geräte neben dem
Aufnehmen von Fotos und Videos auch für Augmented Reality Anwendungen eignen. Beispielsweise wird in dem Spiel Biljet AR4 eine Banknote als
Marker verwendet, die auf dem Display durch eine 3D-Karte ersetzt wird,
auf welcher sich Spielcharaktere bewegen, die mit Schüssen aus Position
des Smartphones getroffen werden müssen.
2
Need For Speed Undercover, Electronic Arts, 2009
Parallel Kingdom, PerBlue, 2009, http://www.parallelkingdom.com/
4
Biljet AR, Beyond Reality, 2011
3
14
3
Analyse der Design Parameter von Multiplayer Games
Multiplayer Games grenzen sich von Singleplayer Games insbesondere dadurch ab, dass menschliche Spieler innerhalb der Spieldomäne miteinander
interagieren. In der Systemtheorie nach Niklas Luhmann ([Luh87]) wird unter Interaktion auch die Kommunikation unter Anwesenden (hier „im Spiel
Anwesenden") verstanden, weshalb in diesem Kapitel viele Modelle der
Kommunikationspsychologie herangezogen werden. Da die Kommunikation unter den Spielern, wie jede Form der Kommunikation, aus Nachrichten
besteht, die nach Watzlawick durch die Selbstoffenbarung stets auch eine
Vermittlung emotionaler Inhalte ist ([WBJ96]), kann auch beim Videospielen
ein Gemeinschaftsgefühl entstehen. Das durch Videospiele hergestellte Gemeinschaftsgefühl wird im Folgenden als Multiplayer Erlebnis bezeichnet.
Ein intensives Multiplayer Erlebnis zu genießen ist häufig ein zentrales
Anliegen von Videospielern. Eine Umfrage unter 16 Studenten ergab, dass
87% der Befragten aus der einfachen Motivation heraus Videospiele spielen,
eine Aktivität gemeinsam mit Freunden zu unternehmen. Warum dies der
Fall ist und wie man diese Tatsache beim Game-Design eines stationären
Multiplayer Games mit Smartphone I/O nutzbar machen kann, wird in
diesem Kapitel behandelt.
3.1
Auswirkung der Kommunikation auf das Multiplayer Erlebnis
Dass das gemeinsame Betrachten eines Unterhaltungsmediums Menschen
begeistert, sehen wir besonders gut am Beispiel der Fußball Weltmeisterschaft 2010. Obwohl die Spiele auch bequem von zu Hause aus hätten verfolgt werden können, trafen sich die Menschen an zum Teil stark überfüllten
öffentlichen Plätzen, um ihre Nationalmannschaft gemeinsam anzufeuern,
einen Sieg zu feiern oder einen Verlust zu bedauern. Das Gemeinschaftsgefühl entstand daraus, dass die Menschen ihre spontanen Emotionen miteinander teilten und ein hohes Maß an Identifikation mit der Gruppe entstand.
Dies wurde dadurch ermöglicht, dass eine unkomplizierte und natürliche
Form der Kommunikation stattfand, welche die Freude an der Teilnahme
15
und somit die touristische Qualität der Veranstaltung begünstigte. Auch
Videospiele bieten alle Voraussetzungen für derartige Emotionen. Bevor ein
Spiel beginnt, steigt die Aufregung, im Verlauf des Spiels werden Erfolge
oder Misserfolge erzielt und dadurch Motivation oder Ehrgeiz geweckt.
Siege und Niederlage lösen Freude oder Bedauern aus. Diese Emotionen
können in Videospielgenres unterschiedlicher Art unabhängig von der Spieleranzahl erzeugt werden. Sowohl im Single- als auch im Multiplayer Modus, in rundenbasierten Strategiespielen, genau so wie in kurzweiligen
Action-Spielen.
Das Umfeld, in dem Videospieler miteinander spielen und kommunizieren,
ist mannigfaltig und genreabhängig: So bieten Action-Spiele stationärer
Konsolen üblicherweise das gemeinsame Spielen an einem Bildschirm an,
zu dessen Zweck sich eine Spielerguppe in einem Raum versammelt. Online
Rollenspiele werden hingegen räumlich voneinander getrennt gespielt. Das
Umfeld ist ein Kriterium dafür, ob ein Genre von einem Spieler bevorzugt
wird oder nicht. Dies liegt vor allem daran, dass die Art der Kommunikation unter Mitspielern von diesem Umfeld abhängt: Zwar kommunizieren
die Spieler in jedem Multiplayer Game durch die Interaktion innerhalb
der virtuellen Spielwelt miteinander, zusätzlich findet jedoch auch direkte
Kommunikation über geschriebenen Text, Stimme oder non-verbale Kommunikation statt, mit der die Aktionen innerhalb der Spielwelt kommentiert
werden. 78% der Befragten gaben an, dass sie gerne oder sehr gerne Multiplayer Games spielen, bei denen alle Spieler auf denselben Bildschirm
schauen, während lediglich 50% angaben, dass sie gerne Videospiele via
Netzwerk spielen, bei denen sich die Spieler an unterschiedlichen Orten
befinden. Die Tatsache, dass mehr Personen das Spielerumfeld bevorzugen,
in welchem face-to-face Kommunikation stattfindet, lässt die Vermutung zu,
dass hierbei das Multiplayer Erlebnis stärker ist, als bei computervermittelter Kommunikation. Diese These soll im Folgenden erörtert werden.
3.2
Psychologische Kommunikationsmodelle im Videospielkontext
Ein essentieller Bestandteil des Spiels ist das Spielziel (siehe [Ada09]). Haben
mehrere Spieler ein gemeinsames Spielziel, dessen Erreichen den gemein-
16
samen Erfolg der Spieler bedeutet, spricht man von kooperativem Spielen.
Bedeutet hingegen der Erfolg des einen Spielers den Misserfolg des anderen, spricht man von kompetitivem Spielen. Neben der Vermittlung von
Spielzügen haben gegenseitige Motivation durch Lob und Anerkennung
und gemeinsames Taktieren aus kooperativer sowie Provokation und Bluffen aus kompetitiver Sicht einen großen Einfluss auf den Spielverlauf, das
Multiplayer Erlebnis und den Spielspaß. Der gewünschte Effekt, der durch
die Kommunikation eintreten soll, wird als Kommunikationsziel bezeichnet.
Neben den Kommunikationszielen spielen die Kommunikationswege eine
Rolle: Viele Computerspiele bieten bereits interne Wege zur Kommunikation an, wie einen Live Chat oder ein E-Mail-System. Verschiedene Genres
und Szenarien erfordern einen Informationsaustausch auf unterschiedliche
Weise. In diesem Zusammenhang muss zwischen synchronen und asynchronen Spielen differenziert werden. Vertreter asynchroner Spiele sind Social
Games, die durch die wachsende Internet- und Smartphonenutzung an
immer größerer Popularität gewinnen. Als Beispiel sei das Browsergame
Online Fußball Manager5 angeführt, bei welchem der Spieler in die Rolle des Managers eines Fußballvereins schlüpft. Über Sieg und Niederlage
zweier virtueller Mannschaften entscheidet eine Losung auf Grundlage
einer durch verschiedene Parameter bedingten Wahrscheinlichkeit. Während diese Berechnung stattfindet, haben die Spieler keinen Einfluss auf das
Spielgeschehen. Da alle Spielparameter strategisch durch langfristige asynchrone Aktionen der Spieler bestimmt werden, ist keine Kommunikation
während des Spiels notwendig. Der am meisten frequentierte Kommunikationsweg ist somit der auf der Website integrierte E-Mail-artige Textverkehr
sowie öffentliche Forumsdiskussionen, in denen sich Spieler anonym und
asynchron über erfolgsträchtige Langzeitstrategien austauschen, aber auch
provozieren oder motivieren. Es existiert kein Kommunikationsziel, das
eine spontane Reaktion erfordert und somit auch kein Bedarf an synchronen
Kommunikationswegen wie Live-Chats, Video-Chats oder face-to-face Kommunikation. Daraus kann geschlussfolgert werden, dass die bereitgestellten
Kommunikationswege dem Kommunikationsziel angemessen sind.
In der Sozialpsychologie existieren verschiedene Modelle, mit deren Hilfe
eine Aussage über die Eignung eines Kommunikationsweges zum Errei5
Online Fußball Manager, 2003, http://www.onlinefussballmanager.de/
17
chen eines bestimmten Kommunikationsziels getroffen werden kann. Am
Beispiel eines asynchronen Spiels wie dem Online Fußball Managers kann
das Fazit aus der sozialpsychologischen Diskussion nachvollzogen werden,
dass nicht zu jedem Kommunikationsziel die soziale Präsenz notwendig ist.
In Fällen wie diesem sind computervermittelte Kommunikationswege mit
face-to-face Kommunikation gleichwertig oder sogar effektiver. Der Mediensynchronizitätstheorie nach Dennis und Valacich zufolge ist die Eignung
eines Kommunikationsmediums von fünf Faktoren abhängig: Symbolvarietät, Geschwindigkeit des Feedbacks, Parallelität, Überarbeitbarkeit und
Wiederverwendbarkeit (siehe [DV99]). Im Kontext synchroner Videospiele
spielen insbesondere die beiden erstgenannten Punkte eine Rolle und sollen
im Bezug auf unterschiedliche Kommunikationsformen in Videospielen
erörtert werden.
3.2.1
Symbolvarietät
Die Symbolvarietät gibt an, auf wievielen Kanälen wie viele Hinweise zum
gleichen Kommunikationsvorgang übermittelt werden können, oder anders
ausgedrückt, wieviele Symbolsysteme zur Verfügung stehen. Beispielsweise hat ein gedruckter Brief eine geringe Symbolvarietät und face-to-face
Kommunikation eine hohe Symbolvarietät, da Stimmhöhe, Gesichtsausdruck etc. im gleichen Kommunikationsvorgang die gesprochene Aussage
unterstützen (siehe [Sch01]).
So genannte Filtertheorien beschreiben in diesem Zusammenhang, dass
der Gehalt an Informationen durch das Wegfallen von Hinweisreizen bei
computervermittelter Kommunikation im Vergleich zur face-to-face Kommunikation abnimmt. E-Mail-Verkehr ist somit eine stärker gefilterte Kommunikation als Video-Telefonie, und Video-Telefonie ist wiederum stärker
gefiltert als face-to-face Kommunikation. [BG96]
In Videospielen ist die Symbolvarietät von einem zweiten Faktor abhängig:
Dem Grad der Ablenkung, die durch das Spiel hervorgerufen wird. Diese
Aussage lässt sich anhand des Multiple Resource Models [Wic08] erklären.
Nach diesem Modell stehen einer Person unterschiedliche kognitive Ressourcen zur Verfügung. Eine Person ist eher in der Lage, Multitasking zu
verarbeiten, sofern sich unterschiedliche Informationsquellen auf diese Res18
sourcen verteilen. So stehen Ressourcen auf der Kodierungsebene sowohl
für räumliche als auch sprachliche Informationen zur Verfügung. Auf der
Modalitätenebene können eher Kombinationen aus auditiven und visuellen
Informationen gleichzeitig verarbeitet werden. Diese Kriterien betrachtend
erscheint ein Voice-Chat beziehungsweise ein Telefonat als passender Kommunikationsweg, um das Kommunikationsziel synchron zu einer visuell
anspruchsvollen Aufgabe, wie dem Spielen eines Action-Spiels zu erreichen.
Ein unpassender Kommunikationsweg wäre hingegen ein Text-Chat, da der
Empfänger gleichzeitig das Spielgeschehen beachten und den Text lesen
müsste. Im Fall schwach gefilterter Kommunikationswege werden Hinweisreize eingeschränkt. Zum Beispiel können Spieler während einer visuell
anspruchsvollen Spielsituation besser miteinander Reden, als auf die Mimik
des Mitspielers zu achten.
Dass dennoch alle Kommunikationsziele durch stark gefilterte Kommunikationswege erreicht werden können, beschreibt der Messaging threshold
Ansatz. Er besagt, dass stark gefilterte Kommunikationswege zwar die
gleiche Qualität besitzen wie schwach gefilterte Wege, jedoch mehr Zeit
benötigen als diese. Obendrein seien alle Facetten der Kommunikation, von
sachlichen bis hin zu emotionalen Kommunikationszielen, mit dem nötigen
Zeitaufwand vermittelbar (siehe [BG96]).
3.2.2
Geschwindigkeit des Feedbacks
Da asynchrone Spiele praktisch keine spontanen Reaktionen verlangen,
sondern lediglich Deadlines eingehalten werden müssen, besteht genügend Zeit, um die Kommunikationsziele auch durch asynchrone und stark
gefilterte Kommunikationswege zu erreichen und dem Fehlen von Hinweisreizen wie Mimik, Gestik oder Stimmlage durch detailliertere Beschreibungen entgegenzuwirken. Bei synchronen Mehrspieler-Spielen ist diese
Zeit zwischen den Spielzügen jedoch nicht zwangsläufig gegeben. Als Beispiel seien Action-Spiele angeführt. Diese erfordern eine synchrone Befehlseingabe, kurze Reaktionszeiten und spontane, taktische Kommunikation.
Asynchroner E-Mail-Verkehr ist somit von vorne herein ausgeschlossen und
synchrone textuelle Kommunikationswege wie Text-Chats sind im Punkte
19
Reaktionszeit solchen Kommunikationsmedien gegenüber benachteiligt, die
synchrone Sprachübertragung zulassen.
Als die durchschnittliche Internetbandbreite noch keine Übertragung von
Sprache zuließ, entstanden diesbezüglich Lösungen durch die Entwickler,
um in ihren Spielen synchrone Kommunikation mittels Tastaturbefehlen zu
ermöglichen. Zum Beispiel ist es beim Echtzeitstrategiespiel Age of Empires6 möglich, jeweils durch Chat-Eingabe eines Zahlenkürzels vorgefertigte
Botschaften zu senden. Der zur Verfügung stehende Fundus besteht aus
taktischen Inhalten (Eingabe: „12“, Ausgabe: „Schließ’ dich mir an“) sowie
Provokationen (Eingabe: „15“, Ausgabe: „Wer ist hier der Größte, he?“). Ist
dem Sender die Semantik dieser Botschaft bekannt, kann er äußerst effizient
über die auditive Ressource des Empfängers kommunizieren.
Als spielübergreifende Lösungen behelfen sich die Spieler zumeist durch
konventionierte Abkürzungen sowie Emoticons, mit deren Hilfe Motivation,
Provokationen und taktische Abstimmungen binnen kürzester Zeit kodiert
werden können. Die Informationserstellung durch den Sender erfordert
hierbei einen ebenso geringen kognitiven Aufwand, wie die Informationsaufnahme des Empfängers und kann auch in einer kurzen „Feuerpause“
stattfinden. Im Folgenden sollen ein paar Beispiele aus dem so entstandenen
Computerspieler-Jargon7 angeführt werden, bei denen besonders komplexe
Sachverhalte durch Kürzel beschrieben werden:
6
Age of Empires, Microsoft-Game-Studios, 1997
Computerspieler-Jargon, Wikipedia, http://de.wikipedia.org/wiki/ComputerspielerJargon, Version 19.04.2012
7
20
b
exe, exen
inc
Ein einfaches im Chat geschriebenes b wird häufig in Strategiespielen wie zum Beispiel Warcraft verwendet. Das b steht für back
(engl. für zurück). Der Spieler möchte damit seinem Teamkameraden symbolisieren, dass er sich mit seinen Einheiten, zum Beispiel
aus einem Kampf mit einem oder dem gegnerischen Team, zurückziehen soll, da es sonst zu Verlusten seiner Einheiten kommt,
was eine eventuelle Niederlage zur Folge hätte.
(Abkürzung für engl. expansion: Expansion/Erweiterung) Wird
vorwiegend in Echtzeitstrategiespielen verwendet und bezeichnet das Sichern weiterer Ressourcenquellen durch Sekundärbasen/Außenposten, um sich so langfristig einen ökonomischen
Vorteil zu verschaffen. Wenn dies sehr früh nach Spielbeginn geschieht, spricht man von einer fast expansion (speziell in StarCraft
II).
(engl. Abkürzung von incoming für hereinkommend) Wird verwendet, um Mitspieler des eigenen Teams zu warnen, dass sich
die gegnerische Mannschaft der Basis nähert bzw. dort bald eintreffen wird. [. . . ]
Allerdings können komplexe Kommunikationsziele nur erreicht werden,
wenn mit Hilfe des Fundus an Kürzeln die gewünschte Botschaft dargestellt
werden kann. Daher besteht die Gefahr, dass das Ausdrucksvermögen für
variantenreiche Spielsituationen unter Umständen nicht ausreicht und daher auf ausformulierte Botschaften zurückgegriffen werden muss. Existiert
ein passendes Kürzel, muss es obendrein allen Kommunikationspartnern
bekannt sein. Dies ist jedoch erst der Fall, wenn alle Spieler genügend
Erfahrung mit dieser Kommunikationsform gesammelt und eine Routine
entwickelt haben, was insbesondere für Gelegenheitsspieler eine Hürde
darstellt.
3.3
Schlussfolgerung der kommunikationspsychologischen Betrachtung
Aus den vorhergehenden Texten lässt sich folgendes Modell abstrahieren,
welches kommunikationsfördernde Aspekte kommunikationshemmenden
Aspekten gegenüberstellt:
21
Kommunikatinsfördernd
Kommunikationshemmend
Die durch den Spielablauf bestimmte
zur Verfügung stehende Kommunikationszeit
Die Erfahrung, in der Spieldomäne abstrakt zu kommunizieren
Die Stärke des Kommunikationsfilters
Der für das Senden und Empfangen
benötigte kognitive Aufwand (Multitasking)
Die Vermutung, dass face-to-face Kommunikation ein stärkeres Multiplayer
Erlebnis durch den Grad der Filterung der Kommunikation erlaubt, lässt
sich nun widerlegen. Rundenbasierte Spiele oder Rollenspiele können genügend Zeit bieten, auch mit stark gefilterter Kommunikation Emotionen
im Verlauf des Spiels zu teilen. Auch Action-Spiele lassen dies durch Abstraktion der Botschaften zu. Je weniger Zeit jedoch die Spieler in die Kommunikation im Rahmen eines Spiels investieren können und je weniger
Erfahrungen die Spieler mit der Abstraktion der Botschaften haben, desto
weniger intensiv ist das Multiplayer Erlebnis bei gleicher Filterstärke. Im
Umkehrschluss bevorzugen daher insbesondere Gelegenheitsspieler gering
gefilterte Kommunikationswege, wie face-to-face Kommunikation. Dies
lässt sich durch zwei Korrelationen innerhalb der in Kapitel 3.1 erwähnten
Befragung der Studenten unterstreichen: Keiner der 5 von 16 Befragten, der
angab, seltener als einmal pro Woche Zeit mit Videospielen zu verbringen,
spielt gerne Multiplayer Games, bei denen sich alle Spieler an unterschiedlichen Orten befinden. Alle 5 Personen dieser Untergruppe spielen hingegen
gerne oder sehr gerne Spiele, bei denen alle Spieler auf denselben Bildschirm
schauen.
Für Spielkonzepte, die sich wie im Flughafen-Szenario (Kapitel 1.1) an
Gelegenheitsspieler richten sollen, ergibt sich dadurch die Anforderung,
möglichst gering gefilterter Kommunikationswege, wie face-to-face Kommunikation. Das Multiplayer Konzept hinter Smartymote, welches ein Social Network als Plattform nutzt, eignet sich somit nicht so gut für Gelegenheitsspieler, wie das hinter Tilt-Racer. Dadurch, dass Spielteilnehmer
und Zuschauer das Medium gemeinsam betrachten und ein hohes Maß an
Kommunikation stattfindet, wird eine starke soziale Atmosphäre geschaffen.
22
3.4
Kommunikationsförderndes Game-Design
Damit ein intensives Multiplayer Erlebnis erzeugt werden kann, sollte das
Spiel viele Spielzüge zulassen, die Kommunikationsziele aufwerfen. Dies
kann in Videospielen durch zwei Maßnahmen im Zuge des Game-Designs
erreicht werden:
Erstens durch die Integration von Elementen, die durch alle Spieler beeinflusst werden können. Beispielsweise stellt der Ball in einer FußballSimulation ein solches Element dar. Im kompetitiven Fall entsteht das Kommunikationsziel dadurch, dass die Spieler das selbe Objekt in entgegengesetzte Richtungen bewegen müssen. Der Erfolg des einen Spielers bedeutet
gleichzeitig den Misserfolg des anderen Spielers. Auch abstrakte Spielobjekte fallen in diese Kategorie, wie die Platzierung in einem Rennspiel, oder
die Punktdifferenz bei einem Shooter. Verhält sich das Objekt zu Gunsten
eines Spielers, löst dies die Freude dieses Spielers und das Bedauern des anderen Spielers aus, deren Mitteilungsbedarf zu einem Kommunikationsziel
führt.
Zweitens durch das Erlauben von Aktionen, die sich direkt auf die Mitspieler auswirken, wie zum Beispiel das Rempeln in Rennspielen oder das
Einsetzen von Items, die bei Mitspielern ein Handicap auslösen.
Die Fun-Rennspiele der Mario Kart Reihe8 bedienen sich sehr erfolgreich
beider Elemente des Game-Designs. Die Platzierungsanzeige der Spieler
nimmt einen großen Bereich am Bildschirmrand des Spielers ein und lässt
einen direkten Vergleich zu den Mitspielern zu. Die Fahrtechnik entscheidet
in erster Linie darüber, wie groß der Abstand zwischen den Spielern ist.
Zudem bieten Items, wie der „Blitz“, welcher alle Gegenspieler über einen
begrenzten Zeitraum schrumpft und dadurch verlangsamt, die Möglichkeit,
Handicaps zu verhängen.
Dass Spiele wie Mario Kart viele Kommunikationsziele aufwerfen und dies
eine Grundlage für den Spielspaß darstellt, lässt sich durch die negative Pressereaktion erkennen, nachdem Mario Kart Hersteller Nintendo im Jahr 2008
die Information veröffentlichte, in der neu erscheinenden Online-Version
Mario Kart Wii9 während des Rennens keine computervermittelte Kommu8
9
Mario Kart, Nintendo, 1992, 1996, 2001, 2003, 2005, 2008, 2011
Mario Kart Wii, Nintendo, 2008
23
nikation zwischen den Spielern zuzulassen. Dies wird aus folgendem Artikelausschnitt des 4Players-Redakteurs Michael Krosta deutlich: „Während
der Rennen ist dagegen überhaupt keine Kommunikation möglich. Schade,
denn gerade dort stehen diverse Wutanfälle an der Tagesordnung, die die eigene Schadenfreude weiter steigern... Hier geht dann in den Online-Rennen
wohl ein nicht zu unterschätzender Spaßfaktor verloren.“ ([Kro08])
3.5
Private und öffentliche Spielansichten
Viele Spielkonzepte basieren auf der Tatsache, dass bestimmte Informationen über das Spielgeschehen versteckt beziehungsweise nur für einen Teil
der Spieler sichtbar sind. Durch die Tatsache, dass nicht alle Informationen
offen gelegt werden, können Taktiken angewendet werden, die darauf basieren, den Gegner zu überraschen. Dadurch wird dem Spiel mehr Tiefgang
verliehen.
Bei Gesellschaftsspielen und klassischen Kartenspielen wie Poker, Rummy
oder Mau Mau wird die Umsetzung privater und öffentlicher Informationen
normalerweise durch einen öffentlichen Spielbereich auf dem Tisch und
einer Menge privater Spielbereiche in Form von Handkarten ermöglicht.
In vielen Computerspielsystemen ist die Kombination aus privaten und
öffentlichen Inhalten zumeist nur indirekt gegeben. Zur Erläuterung muss
zwischen zwei Setups für Multiplayer Games differenziert werden: Entweder sind die Spieler über ein Netzwerk miteinander verbunden und haben
keine Einsicht auf die Bildschirme der anderen Spieler, oder alle Spieler
betrachten denselben Monitor.
Im Fall des ersten Setups sind prinzipiell alle Spielinhalte privat. Das ausführen verdeckter Spielzüge ist somit ein zentraler Bestandteil vieler taktischer Genres wie Ego-Shootern oder Echtzeitstrategiespielen. Öffentliche
Informationen, also solche, auf die jeder Spieler zugreifen kann, sind hingegen lediglich Kopien, die auf jedem der Bildschirme in gleicher Form
ausgegeben werden. Auf diese Weise funktionieren auch zahlreiche Online Gesellschaftsspiele, wie die Online-Poker-Plattform Pokerstars.com10 :
Die Handkarten der Spieler werden in einem privaten Bereich angezeigt,
während die gemeinsamen Karten (beispielsweise bei der Texas Hold’em
10
Pokerstars.com, PokerStars, 2001, http://www.pokerstars.com
24
Pokervariante) auf dem Hintergrundbild eines Tischs platziert sind. Es wird
das Vorwissen der Spieler vorausgesetzt, dass dieser Bereich für alle Spieler
gleichermaßen ersichtlich ist, sowie das Vertrauen, dass jedem Spieler eine
gleichwertige Kopie der öffentlichen Inhalte zur Verfügung steht und kein
Spieler über mehr oder weniger Informationen verfügt als der andere. Dass
dieses Vertrauen gebrochen werden kann, beweisen Verdächtigungen, dass
bei Ego-Shootern wie Counterstrike so genannte Wallhack oder Smokehack
Cheats verwendet werden, um durch Wände oder Nebel hindurchsehen zu
können und sich dadurch einen Vorteil zu verschaffen.
Multiplayer Videospiele auf Spielkonsolen oder PCs ohne Netzwerkverbindung weisen nur einen öffentlichen Spielbereich auf. Alle Spieler betrachten
den Monitor zur selben Zeit. Die Eingabe erfolgt entweder asynchron, also
abwechselnd in Form eines Hot-Seat Modus (zum Beispiel bei Worms11 oder
Heroes of Might and Magic12 ) oder synchron über mehrere Eingabegeräte.
Die Ausgabe kann über einen gemeinsamen Viewport (beispielsweise bei
Tilt-Racer oder Arcade-Spielen wie Bomberman13 ) oder in auf dem Bildschirm verteilten Viewports im Split-Screen Modus erfolgen, sowie aus
einer Kombination dieser Möglichkeiten. Zum Beispiel wird bei Mario Kart
die Split-Screen Ansicht durch eine gemeinsame Streckenkarte erweitert.
Im Split-Screen Modus sind zwar die Bereiche auf jeweils einen Spieler
bestimmt und zeigen personalisierte Inhalte an, allerdings sind diese nicht
privat, sondern durch alle anderen Spieler einsehbar, wodurch oben genannte Mehrspielerkonzepte wie Poker oder Echtzeit Strategiespiele nicht ohne
weiteres umsetzbar sind.
Jedoch hat die öffentliche Information bei dieser Form des MehrspielerSpiels eine andere Qualität: Sie ist durch die reale Situation bedingt, wodurch kein Vorwissen darüber nötig ist, welcher Spieler über welche Informationen verfügt. Auch ist es nicht nötig, das oben beschriebene Vertrauen
an die Anzeige in Frage zu stellen. Zudem ist durch die face-to-face Kommunikation, beschrieben in Kapitel 3.1, im Gegensatz zur Netzwerkverbindung
sichtbar, wann und wie ein Spieler die öffentlichen Inhalte einsieht oder wie
er auf Veränderungen reagiert. Streng genommen wird der Spieler selbst
zu einer öffentlichen Informationsquelle für alle anderen Spieler. Dies gilt
11
Worms, Team17, 1995
Heroes of Might and Magic, New World Computing, 1995
13
Bomberman, Hudson Soft, 1983
12
25
Abbildung 5: Scrabble für das iPad. Die privaten Steinablagen werden auf den
iPhones angezeigt.
gerade im Beispiel des Pokerspiels, in dessen Zusammenhang Begriffe wie
„Pokerface“ darauf hindeuten, dass ein großer Bestandteil des Spiels in der
Selbstoffenbarung liegt.
Quintessenz ist, dass Spielkonzepte wie Poker von gemeinsam betrachteten öffentlichen Inhalten profitieren, jedoch ohne die Möglichkeit privater
Inhalte nicht umsetzbar sind, weshalb es einer hybriden Lösung bedarf.
Eine solche Lösung bietet Scrabble14 für das iPad. Wie auf Abbildung 5
sichtbar, dient bei diesem Spiel das iPad Tablet als öffentliches Spielbrett,
das von allen Spielern betrachtet wird. Via Wifi werden iPods, beziehungsweise iPhones mit dem iPad verbunden und dienen als private Steinablage,
ähnlich der Handkarten eines Kartenspiels.
Auch das Setup stationärer Multiplayer Games mit Smartphone I/O bieten
die Möglichkeit, taktische Game-Design Elemente durch private Inhalte auf
dem Smartphone und öffentliche Inhalte auf dem Monitor zu erlauben. Es
ist nicht nötig, Spielbereiche als privat oder öffentlich zu kennzeichnen oder
spezielles Vorwissen darüber vorauszusetzen. Gerade für Spieleinsteiger
ist dadurch ein besonders einfacher Einstieg in komplexe taktische Spiele
möglich.
14
Scrabble, Electronic Arts, 2010
26
3.6
Menünavigation in Multiplayer Games
Die Menünavigation in Multiplayer Games wirft eine Menge von Problemen
auf. Ein Problem, das insbesondere bei Spielen auftritt, die von mehreren
Spielern an einem Bildschirm gleichzeitig bedient werden können, besteht
darin, jeden Spieler seine persönlichen Einstellungen tätigen zu lassen. Dieses Manko ist aus Multiplayer Games wie FIFA 1215 bekannt: Jeder Spieler
kann die aktuelle Menüansicht beenden, obwohl unter Umständen die anderen Spieler ihre Einstellungen noch nicht abgeschlossen haben. Dies kann
zu Verwirrung und Unstimmigkeiten zwischen den Spielern führen. Eine
Möglichkeit, dies zu verhindern besteht darin, dass nur ein Spieler sämtliche
Einstellungen vornimmt. Allerdings besteht das Problem, dass besonders
in solchen Ansichten, die zu Personalisierungseinstellungen dienen, eine
genaue Absprache zwischen dem menüführenden Spieler und dem Spieler,
den die Einstellungen betreffen, erforderlich ist. Eine Modifikation dieser
Methode ist es, denjenigen Spieler zum Menüführenden Spieler zu ernennen, den die Einstellungen der aktuellen Ansicht betreffen. Allerdings ist
es weniger effizient, wenn die Einstellungen aller Spieler hintereinander
getätigt werden müssen. Eine weitere Möglichkeit ist es, jedem Spieler einen
eigenen Bildschirmbereich zuzuweisen, in welchem er unabhängig von
den anderen Spielern durch die Menühierarchie navigieren kann, um seine
Einstellungen zu treffen. Hierbei tritt das Problem der Unübersichtlichkeit
auf dem Bildschirm auf, da für jeden Spieler ein Bereich vorhanden sein
muss.
Der Smartphone-Controller lässt hingegen die Einstellungsmethoden zu,
die aus verteilten Multiplayer Systemen bekannt sind, in denen jeder Spieler
seinen eigenen Bildschirm besitzt: Alle privaten Einstellungen der Spieler
können gleichzeitig vom jeweiligen Client aus getätigt werden. Obendrein
können diese ort- und zeitversetzt stattfinden, da keine Verbindung zum
Server erforderlich ist. Diese Möglichkeit setzt lediglich voraus, dass die
einmal eingestellten Konfigurationen dem Server nach dem Login mitgeteilt
werden.
Allerdings besteht in diesem Fall das Problem, dass sich die Spieler, die bisher ihre privaten Einstellungen unabhängig vom Server getätigt haben, vor
15
FIFA 12, EA Spots, 2011
27
dem Spiel versammeln müssen. Dieses Problem kann durch eine virtuelle
Lobby gelöst werden. Die Spielernamen der eingeloggten Spieler werden in
einer Liste angezeigt. Hier können auch öffentliche Einstellungen getätigt
werden, die alle Spieler gleichermaßen betreffen. Für manche Entscheidungen kann eine Abstimmung erforderlich sein, beispielsweise bei der Frage,
wann eine Spielrunde gestartet werden soll beziehungsweise, wann alle
Spieler ihre privaten Einstellungen abgeschlossen haben und bereit für die
Spielrunde sind. Dies geschieht in Spielen wie Age of Empires durch Aktivierung einer „Ich bin bereit“-Markierung. Das Spiel beginnt erst, wenn alle
Spieler eine solche Markierung aufweisen.
28
4
Konzeption einer Beispielanwendung
Um eine Aussage darüber treffen zu können, wie hoch die Akzeptanz der
Spieler ist, ein smartphonegesteuertes Videospiel auf einem öffentlichen
Monitor zu spielen, soll im Rahmen dieser Arbeit ein exemplarisches Spiel
entwickelt werden. Dazu sollen die in Kapitel 2 und 3 theoretisch erarbeiteten Design-Entscheidungen bezüglich des Multiplayer Games die spezifischen Fähigkeiten des Smartphone-Controllers berücksichtigt werden. Ziel
der Implementierung ist die anschließende Durchführung einer Evaluation
des Konzepts auf Grundlage einer Probandenbefragung.
4.1
Spezifikationen
In diesem Abschnitt werden die Softwarespezifikationen in Form eines
Pflichtenhefts nach Balzert ([Bal98]) vorgenommen:
1. Zielbestimmung
(1) Das Spiel soll ein Actionspiel sein, (2) das mit einem Smartphone gesteuert werden muss, während (3) die grafische Ausgabe der
wichtigsten Spielinhalte über einen Monitor erfolgen muss. (4) Auch
das Display des Smartphones soll für das Anzeigen von Spielinhalten
verwendet werden. (5) Das Spiel muss einen Multiplayer Modus aufweisen. (6) Es darf neben einem Smartphone pro Spieler kein weiteres
Eingabegerät nötig sein, um mit dem Bildschirm zu interagieren.
2. Produkteinsatz
(1) Das Spiel soll an einem großen öffentlichen Bildschirm gespielt
werden können. (2) Es soll thematisch eine möglichst breite Interessentengruppe ansprechen.
3. Produktumgebung
(1) Die Smartphonesteuerung soll auf einem populären Betriebssystem ausgeführt werden. (2) In der prototypischen Implementierung
brauchen keine weiteren Betriebssysteme unterstützt werden. (3) Die
Drahtlosschnittstelle zwischen den Smartphoneclients und dem Server
muss allerdings einen gängigen Standard erfüllen, damit viele Geräte
kompatibel sind. (4) Die Serveranwendung kann ein beliebiges System
29
verwenden. (5) Jedoch soll die Rechen- und Grafikleistung ausreichen,
um eine aufwändige Grafik und Spielphysik zu unterstützen.
4. Produktfunktionen
(1) Es muss ein fest definiertes Spielziel in begrenzter Zeit erreicht
werden. (2) Es muss Spielelemente geben, die von allen Spieler gleichzeitig beeinflussbar sind, um Kommunikationsziele aufzuwerfen. (3)
Dazu soll es Items geben, die ein Handicap verhängen. (4) Das Spiel
kann taktische Spielweisen zulassen.
5. Produktdaten
(1) Auf dem Server dürfen große Datenmengen an Spielressourcen
anfallen. (2) Für die Smartphone-Anwendung sollen lediglich geringe
Speicherressourcen aufgewendet werden.(3) Persönliche Spielerdaten
müssen auch ohne Verbindung zum Server geändert werden können,
um einen besonderen Vorteil des Smartphone-Controllers auszunutzen. (4) Diese Daten sollen auf dem Smartphone des jeweiligen Benutzers gespeichert werden und dem Server bei einem Login für die
Dauer der Spielsitzung zur Verfügung stehen.
6. Leistungen
(1) Die Spielregeln sollen selbsterklärend und (2) die Spielbedienung
einfach zu erlernen sein. (3) Alle nötigen Systemeinstellungen des
Smartphones müssen automatisch durch die Clientanwendung vorgenommen werden.
7. Benutzeroberfläche
(1) Die Eingabe von Spielzügen muss über intuitive Zeigegesten auf
dem Touchscreen und (2) mittels natürlichen Bewegungen des Smartphones erfolgen. (3) Die Grafik des Spiels soll möglichst realistisch
sein, um einen geringen Abstraktionsgrad aufzuweisen und das Spiel
leicht verständlich zu machen. (4) Aus demselben Grund sollen die
Animationen physikalisch plausibel erscheinen. (5) Im Multiplayer
Modus sollen sich alle Spieler in einer Lobby versammeln können
bevor das Spiel beginnt. (6) Alle GUI-Elemente, die einen Spieler betreffen, können in einer ihm zugeordneten Farbe angezeigt werden.
8. Qualitätsziele
(1) Das Spiel muss den Spielern der Zielgruppe so viel Spaß machen,
30
dass sie ihm eine gute oder sehr gute Gesamtbewertung aussprechen.
(2) Das Spiel muss so leicht erlernbar sein, dass ein Spielanfänger ohne
Hilfestellung ein Spiel beginnt, das Ziel eigenständig versteht und
darauf hinarbeitet. (3) Das Spiel muss ein gutes Multiplayer Erlebnis
bieten, so dass alle Spieler der Zielgruppe den Spaß am Spiel gegen
einen menschlichen Gegner bezeugen.
9. Testszenarien
(1) Es muss eine Evaluation mit Probanden durchgeführt werden, die
das Spiel zuvor noch nicht gespielt haben. (2) In einer ersten Phase
soll das Spiel auf seine Erlernbarkeit und (3) auf die Intutivität der
Steuerung hin untersucht werden. (5) Zudem soll untersucht werden,
ob die Probanden die spezifischen Eigenschaften des SmartphoneControllers als Mehrwert erkennen. (5) In der zweiten Phase soll der
Multiplayer Modus getestet (6) und die soziale Interaktion der Spieler
untereinander beobachtet werden.
10. Entwicklungsumgebung
(1) Das Spiel soll leicht und zügig um Spielinhalte erweiterbar sein. (2)
Dazu können high-level Skriptsprachen und visuelle Programmierung
ebenso verwendet werden, (3) wie eine leistungsfähige Animationsund Modellierungssoftware. (4) Wichtig ist die Integration einer SmartphoneController Schnittstelle für das verwendete Framework. Die genaue
technische Spezifikation wird in Kapitel 5.1 beschrieben.
4.2
Ausarbeitung des Game-Designs für einen Prototypen
Ein Spielgenre, das sich besonders gut zur Erfüllung der in Kapitel 4.1
aufgezählten Spezifikationen eignet, ist das des Action-Shooters (vergleiche Spezifikation 1.1). Das Treffen von Zielen mittels Projektilen ist aus
vielen Sportarten und Freizeitbeschäftigungen unseres Alltags bekannt.
Dart-Spiele, Bogenschießen oder Büchsenwerfen sind zeitlose Spielkonzepte, welche die Menschen seit jeher faszinieren und Geschick und Präzision
abverlangen. Aus diesem Grund basieren sehr viele Videospiele, wie Space
Invaders16 , Boom Blox17 oder unzählige Ego-Shooter auf diesem Konzept.
16
17
Space Invaders, Midway Games, 1987
Boom Blox, Electronic Arts, 2008
31
Das Spielziel, fest definierte Objekte zu treffen und die Anzahl erfolgreicher
Treffer mit Punkten zu honorieren, ist einfach und selbsterklärend (vergleiche Spezifikation 6.1). Bei der Übertragung des Konzepts in eine virtuelle
Spielwelt liegt es nahe, dem Smartphone die Metapher des Schussgeräts
zuzuweisen, während die Ziele auf dem Monitor angezeigt werden (siehe
Spezifikation 1.2). Sobald eine Schussaktion auf dem Smartphone durchgeführt wird, erscheint das beschleunigte Projektil auf dem Monitor und
bewegt sich in Richtung des Ziels. Durch selbsterklärende Grafiken soll die
Selbstbeschreibungsfähigkeit auch nach der Übertragung des Spielkonzepts
in die virtuelle Realität gewährleistet sein vergleiche (vergleiche Spezifikation 6.2). Auf dem Smartphone-Display wird daher eine Zwille angezeigt
(nach Spezifikation 1.4), während auf dem Monitor ein Schießstand simuliert
wird (nach Spezifikation 1.3).
4.2.1
Die Zwille
Die Wahl des simulierten Schussgeräts fiel aus verschiedenen Gründen
auf eine Zwille. Eine Zwille besitzt ein charakteristisches Erscheinungsbild,
dessen Zweck auf den ersten Blick identifizierbar ist, ohne dabei im Gegensatz zu vielen anderen Schussgeräten primär militärisch konnotiert zu
sein. Dieser Designaspekt ist wichtig, um Kontroversen zu vermeiden und
ein großes Publikum anzusprechen (vergleiche Spezifikation 2.2). Die Form
einer Zwille ist kompakt und passt gut auf das Format eines SmartphoneDisplays. Die Projektile liegen während des Spannvorgangs frei. Somit ist
stets sichtbar, welche Beschaffenheit das Projektil besitzt. Der Spannvorgang
selbst lässt eine intuitive Skalierung der Schusskraft zu: Je weiter das Gummiband gespannt wird, desto fester ist der Schuss. Auch die Schussrichtung
wird von der Spannrichtung des Gummibandes beeinflusst. Die Grafik der
Zwille soll einen großen Bereich des Viewports einnehmen und um einen
45◦ Winkel in die Tiefe gekippt sein, um bei gewöhnlicher Haltung des
Smartphones den Eindruck einer parallelen Ausrichtung der Zwille zum
Monitor zu erzeugen. Die Schussrichtung wird durch die Lage des Smartphones bestimmt: Wird das Smartphone nach hinten geneigt, verändert sich
die Schussrichtung nach oben. Wird das Smartphone geschwenkt, kann
nach links oder rechts gezielt werden. Dieser Vorgang nutzt die Sensorik des
Smartphones aus (vergleiche Spezifikation 7.2). Abbildung 6 verdeutlicht
32
Abbildung 6: Der Spannvorgang der Zwille auf dem Smartphone: Mit dem Finger
wird das Projektil auf dem Touchscreen nach unten gezogen.
den Zielvorgang. Das Gummiband der Zwille ist im Ruhezustand ein horizontaler Streifen. Dieser reagiert auf Berührungen und kann mit dem Finger
durch eine Ziehgeste in der Bildebene gespannt werden, während die Enden
des Bandes an der Aufhängung der Zwille befestigt sind. Die Fingerposition
gibt dabei den Griffpunkt des Gummibandes an, der nach Belieben an jede
Position des Touchscreens gezogen werden kann (vergleiche Spezifikation
7.1). Befindet sich ein Projektil auf dem Gummiband, bewegt es sich entsprechend mit. Sobald der Finger den Touchscreen verlässt, wird der Griffpunkt
aufgehoben. Das Projektil wird durch das Zentrum der Zwille vom Band
beschleunigt und verlässt den Viewport. Je weiter das Band auf dem Display nach unten gezogen wurde, desto stärker fällt die Beschleunigung
und somit der Schuss aus. Um den Eindruck eines realen Gummibandes
zu unterstreichen, federt es nach dem Schuss nach(vergleiche Spezifikation
7.4).
4.2.2
Der Schießstand
Der Schießstand, der auf dem Monitor angezeigt wird, besteht aus einem
dreidimensionalen quaderförmigen Raum in der Fluchtpunktperspektive,
der mit unterschiedlich weit entfernten Zielscheiben mit gewohnt konzentrischem Kreismuster und anderen zu treffenden Gegenständen ausgestattet
ist. Wurde mit der Zwille ein Schuss abgegeben, fliegt das Projektil aus Richtung der Kamera in die Tiefe der Szene und wird dabei von der Schwerkraft
und Kollisionen physikalisch plausibel abgelenkt. Der Raum zeichnet sich
33
durch seine Interaktivität aus: Sämtliche Objekte, die sich darin befinden
sind durch die Geschosse zu beeinflussen und reagieren mit authentischen
Animationen auf einen Treffer (vergleiche Spezifikation 7.4). Abbildung 8
zeigt den Schießstand auf dem Monitor während eines Spiels. Die Zielscheiben sind an Scharnieren befestigt, die bei einem Treffer zurück klappen. Auf
dem Boden des Schießstands sind Bauklötze platziert, die ähnlich der Büchsen in einem Büchsenwurfspiel aufgetürmt sind. Werden diese getroffen,
stürzt der Turm in sich zusammen. Eine Taschenlampe steht aufrecht auf
dem Boden und wirft einen Lichtkegel an die Decke. Bei einem Treffer kippt
sie um und rollt über den Boden. Luftballons schweben in regelmäßigen
Abständen in die Szene und können durch Schüsse zum Platzen gebracht
werden. Diese Gegenstände erhöhen den Detailreichtum und lassen das
Spiel ansprechender auf den Spieler wirken. Auch soll der Spieler angeregt
werden, den interaktiven Raum zu erkunden, um seinen Spieltrieb und
das Interesse der Zuschauer zu wecken. Dadurch kann die Spielmechanik
und die Steuerung verinnerlicht werden, ohne sich zuvor mit Spielregeln
auseinander gesetzt haben zu müssen.
4.3
Spielregeln im Singleplayer Modus
Damit sich der Spieler einer Herausforderung stellen kann, ist es notwendig,
ein Spielziel zu definieren. Das Ziel einer Spielrunde besteht darin, möglichst viele Punkte in einem festgelegten Zeitraum von 60 Sekunden zu
erreichen (vergleiche Spezifikation 4.1). Punkte können durch das Treffen
von Objekten erreicht werden. Jede Zielscheibe, die getroffen wird, addiert
100 Punkte auf den Punktestand. Nach einem Treffer klappt die Zielscheibe
nach hinten und richtet sich erst nach einer unbekannten Zeitspanne wieder
auf. Dadurch ist gewährleistet, dass der Spieler seine Zielausrichtung häufig
ändern muss, um seine Punktzahl innerhalb eines begrenzten Zeitraums zu
maximieren. Durch die Bauklötze und die Taschenlampe wird nach einem
Treffer ein Punktbetrag gutgeschrieben, der abhängig von der Strecke ist,
die das jeweilige Objekt zurücklegt. Somit zählen präzise und kraftvolle
Treffer mehr Punkte als Streifschüsse.
34
Abbildung 7: Alle interaktiven Objekte in ihrer Spielgrafik: Links die Projektile,
rechts die Ziele
Abbildung 8: Der Schießstand auf dem Monitor während des Spiels: Alle sichtbaren Objekte reagieren mit Animationen auf einen Treffer.
35
Eine gute Spielerleistung erfordert somit Geschick, Präzision und Geschwindigkeit. Im Hinblick auf die Evaluation entsteht dadurch ein anspruchsvolles
Testszenario für die Intuitivität und die Bedienbarkeit der Steuerung.
Um das Spiel um ein optionales strategisches Element zu erweitern und
ihm mehr Tiefgang zu verleihen, gibt es die Möglichkeit, das Projektil zu
wechseln. Zu Beginn des Spiels stehen dem Spieler ausschließlich Standardprojektile zur Verfügung. Die in Kapitel 4.2.2 erwähnten Luftballons
gewähren dem Spieler, der sie zum Platzen bringt, jeweils das Schießen
eines Dynamit-Projektils. Wird dieses geschickt platziert, detoniert es und
beschleunigt in der Nähe befindliche Objekte wie die Bauklötze oder die
Taschenlampe, die in Folge dessen besonders hohe Punktzahlen bescheren (vergleiche Spezifikation 4.4). Das Dynamitprojektil ist in Abbildung
10 und die Auswirkungen der Detonation im unteren rechten Bereich der
Abbildung 8 zu sehen.
4.4
Spielregeln im Multiplayer Modus
Die Regeln des Multiplayer Games stellen eine Erweiterung der Singleplayer
Regeln dar, damit auf möglichst viele Erfahrungen aus dem Singleplayer
Game zurückgegriffen werden kann. Hierbei hat jeder Spieler gleichzeitig
die Möglichkeit, mit der Zwille auf seinem Smartphone Punkte zu sammeln (vergleiche Spezifikation 1.5). Derjenige Spieler, der innerhalb der 60
Sekunden die meisten Punkte sammeln konnte, gewinnt das kompetitive
Spiel. Alle Spieler interagieren mit demselben Schießstand zur selben Zeit.
Kommunikationsziele entstehen zum Beispiel, wenn beide Spieler gleichzeitig auf dieselbe Zielscheibe zielen, so dass nur der Schuss des schnelleren
Schützen gezählt wird, da die Zielscheibe sofort nach hinten weg klappt
(vergleiche Spezifikation 4.2). Auch das alternative Projektil des Dynamits
wird durch die Möglichkeit, von den Gegenspielern vor der Detonation
durch einen gezielten Schuss entfernt zu werden, zu einem kommunikationsfördernden Element. Im Multiplayer Modus kann durch Treffen eines
Luftballons eine dritte Projektilart erspielt werden: Ein grüner Edelstein
„Monkeyhead“ verhängt allen Gegenspielern ein Handicap, sobald er in die
Szene geschossen wird (vergleiche Spezifikation 4.3). Dieses äußert sich darin, dass das Zielen so lange erschwert wird, bis der Monkeyhead getroffen
36
wurde und verschwindet (Die Art der Erschwernis wird in Kapitel 4.5.2 beschrieben). Alle Gegenspieler haben also die Motivation, den Monkeyhead
oder das Dynamit zu treffen, wodurch kurzzeitige kooperative Spielzüge vonnöten sind. Der Wechsel zwischen kooperativen und kompetitiven
Zielen kann mitunter zu sehr komplexen Spielsituationen und emergentem Gameplay führen (vergleiche [Ada09]), wie folgende Beispielsituation
zeigt:
Bemerkt ein Spieler, dass das Dynamit-Projektil eines Gegenspielers in der
Nähe eines Turmes aus Bauklötzen landet, der dem Schützen eine großen
Punktevorsprung bescheren würde, fordert er alle anderen Mitspieler auf,
ihm zu helfen, das Dynamit rechtzeitig vor der Detonation zu entfernen. In
diesem Moment einen Monkeyhead zu schießen, wäre obendrein kontraproduktiv, da es für die zeitweiligen Kooperationspartner ein Hindernis beim
Erreichen des gemeinsamen Zieles wäre. Allerdings könnte die Aufforderung der Mitspieler auch missbraucht werden, indem sich der auffordernde
Spieler selbst nicht damit befasst das Dynamit zu entfernen, sondern derweil
durch das Treffen von Zielscheiben in seine eigene Tasche wirtschaftet.
4.5
Menünavigation und GUI-Elemente
Eine Design-Frage bezüglich der Ansichten und GUI-Elemente ist insbesondere, welche Informationen öffentlich auf dem Monitor angezeigt werden
und welche privat auf jedem Smartphone sichtbar sind (siehe Kapitel 3.5).
Im Folgenden werden daher öffentliche und private Ansichten getrennt
voneinander beschrieben.
4.5.1
Private Informationen auf dem Smartphone
Wie Abbildung 9 zeigt, sind die Unterschiedlichen Bildschirmansichten
(Views) auf dem Smartphone in einer zweistufigen Hierarchie angeordnet: Nach dem Starten der Clientanwendung ist die Mainview aktiv. Von
dieser aus kann in eine Subview gewechselt werden. Die Subviews sind
die Optionsview, die Highscoreview (im vorliegenden Prototypen noch
nicht implementiert), die Calibrationview und schließlich die Gameview.
Wird eine Subview geschlossen, wird erneut die Mainview angezeigt.
37
Smartphone
Kiosksystem
Highscoreview
Mainview
(nicht verbunden)
Optionsview
Verbindungsaufbau
Lobbyscene
Lobbyscene (1 Spieler verbunden)
Mainview
(verbunden)
Calibrationview
Lobbyscene (mit Kalibrierungsmarkierung)
Gameview
Gamescene
Abbildung 9: Alle Views des Singleplayer Modus im Überblick: Links sind die
Views des Smartphones zu sehen, rechts die entsprechende Reaktion
des Servers. Die gestrichelten Pfeile stellen Drahtlossignale dar.
38
In der Mainview sind der Identifikationsbereich und das Hauptmenü sichtbar. Der Identifikationsbereich zeigt den Spielernamen und die Spielerfarbe,
die in der Personalisierungsansicht angepasst werden können. Sie stehen
exemplarisch für die Kategorie der Einstellungen, die ohne Verbindung zum
Server getätigt werden können und stellen damit einen der Vorteile im Gegensatz zu einem Controller dar (vergleiche Spezifikation 5.3). Ebenso steht
die Highscoreview ohne Serververbindung zur Verfügung, in welcher
die erspielten Erfolge eingesehen werden können. Weitere Möglichkeiten,
die Highscores in Social Networks zu veröffentlichen oder in ein ubiquitäres
Spiel zu integrieren, würden hier ansetzen.
Ein einfaches ToggleButton Widget lässt den Client automatisch nach
dem Server suchen und eine Verbindung zu diesem herstellen. Es ist nicht
notwendig, manuell im Einstellungsmenü des Smartphones eine Verbindung mit dem Server herzustellen (vergleiche Spezifikation 6.3). Lediglich
eine Berechtigungsnachfrage wird aufgerufen, welche die Software zur Herstellung der Verbindung autorisiert. Ist die Verbindung aufgebaut, wird der
Bereich der Gameview aktiv.
Wie Abbildung 10 zeigt, nimmt die Zwille, die in Kapitel 4.2.1 beschrieben wurde, den größten Bereich der Gameview ein. Am unteren Rand der
Zwille ist das Inventar abgebildet. Es zeigt Projektilsymbole zusammen
mit einem Zähler, der Auskunft darüber gibt, wie häufig das jeweilige Projektil zur Verfügung steht. Bei einem Druck auf das Symbol erscheint das
entsprechende Projektil im Gummiband. Nach dem Abfeuern wird es so
häufig automatisch nachgeladen, bis der Zähler in der Inventaranzeige auf
null gesunken ist. Ist ein Projektil ausgewählt, dessen Zähler null anzeigt,
wird ein Platzhaltersymbol auf das Gummiband gelegt, das bis zur Wahl
eines anderen Projektils keinen Schuss in die Szene zulässt. Die Munitionsanzeige befindet sich auf dem privaten Touchscreen jedes Spielers, damit
diese Information für alle Spieler verborgen ist. Somit hat jeder Spieler die
Möglichkeit, seine Gegenspieler zu überraschen. Wird beispielsweise ein
Monkeyhead ausgewählt, können sich die Spieler nicht vorzeitig auf das
Handicap einstellen.
39
Abbildung 10: Die Gameview auf dem Smartphone: Im oberen Bereich ist die
Zwille, im unteren das Inventar zu sehen.
Abbildung 11: Die Bildschirmansicht zu Beginn einer 2-Spieler-Runde: Am oberen
Bildschirmrand werden der Countdown und die Namensschilder
mit der erreichten Punktzahl angezeigt. Unten sind die ballistischen
Kurven zu sehen, die das Zielen erleichtern sollen.
40
4.5.2
Öffentliche Informationen auf dem Monitor
Die Ansichten auf dem Monitor (im Folgenen „Scenes“ genannt) sind für
alle Spieler und Zuschauer gleichermaßen sichtbar. Wird der Server gestartet, zeigt er auf dem Monitor die Lobbyscene an. Hier kann in späteren
Versionen ein Einführungsfilm abgespielt werden, der erklärt, wie die Clientanwendung heruntergeladen wird. Für jeden Spieler, der eine Verbindung
zum Server hergestellt hat, wird ein Namensschild im oberen Bildschirmbereich eingeblendet. Er befindet sich nun in der virtuellen Lobby (vergleiche
Spezifikation 7.5). Das Namensschild erhält zur eindeutigen Identifizierung
des Spielers den auf dem Smartphone eingegebenen Spielernamen und seine gewählte Spielerfarbe. Alle Informationen auf dem Monitor, die zwar für
alle Spieler sichtbar sind, sich aber auf einen bestimmten Spieler beziehen,
werden in dieser Spielerfarbe dargestellt (siehe Spezifikation 7.6).
Wird die Gamescene auf dem Server aufgerufen, beginnt die Spielrunde.
Dies geschieht, sobald alle Spieler, die sich in der Lobby befinden, auf ihren
Smartphones in die Gameview gewechselt haben (siehe Abbildung 9). Die
Namensschilder der Spieler sind während des Spiels weiterhin sichtbar und
zeigen nun zusätzlich zu dem Namen und der Farbe die bisher erspielte
Punktzahl des jeweiligen Spielers an. Die Information der Punktzahlen
ist bewusst öffentlich, um eine größere Spannung im Spiel zu erzeugen.
Zudem wird die noch zur Verfügung stehende Spielzeit für alle gut sichtbar
angezeigt.
Eine Anzeige, die im Zuge erster Tests hinzugefügt wurde, ist die ballistische Kurve, welche die exakte Flugbahn des Projektils bis zu seiner ersten
Kollision anzeigt. Die Kurve streckt und richtet sich in Echtzeit im Zuge
der Bewegung des Smartphones und des Spannens der Zwille auf dem
Touchpad aus. Zur besseren Identifikation wird die Kurve in der jeweiligen
Spielerfarbe gezeichnet. Mit Hilfe dieser Anzeige ist es besonders einfach,
vorherzusagen, wo ein Schuss landet. Aus diesem Grund ist die Kurve nur
bis zu einer begrenzten Entfernung sichtbar. Eine Auswirkung des Monkeyheads ist die weitere Verkürzung, die nur noch Rückschlüsse auf eine
ungefähre Richtung gibt. Dadurch wird die Hilfe der ballistischen Kurve
stark eingeschränkt.
41
5
Technische Umsetzung
In diesem Kapitel wird die konkrete Umsetzung der Beispielimplementierung beschrieben. Auch wird begründet, weshalb die Entscheidung auf die
verwendeten Technologien oder programmatischen Lösungen fiel. Einige
Problemstellungen konnten erst nach einem missglückten Ansatz, der ebenfalls hier beschrieben wird, erfolgreich umgesetzt werden. Zudem werden
eigens für diese Software entwickelte Konzepte detailliert beschrieben und
im Anschluss evaluiert.
5.1
Gerätespezifikation und verwendete Technologien
Die Implementierung des Spielkonzepts basiert auf einem verteilten System
bestehend aus einem öffentlichen Spielserver und einer Anzahl von einem
bis vier Smartphone Clients. Die Clientanwendung wurde exemplarisch für
Android 2.3 Systeme unter Verwendung des Java JDK 1.7, OpenGL ES 2.0
und GLSL implementiert und unter anderem auf einem Huawai Ideos X3
Smartphone getestet. Die Clientsoftware auf den Smartphones kommuniziert via Bluetooth mit dem Server. In dieser konkreten Umsetzung handelt
es sich beim Server um einen Sony Vaio VPCZ12C5E Laptop mit einem Intel
Core i7 Dualcore Prozessor (2,67 GHz, Hyperthreading), 6 GB RAM und
einem NVIDIA GeForce GT 330M Grafikchipsatz mit 1024 MB dediziertem
Grafikspeicher. Die Bildschirmausgabe erfolgt während der Benutzertests
auf einem an den Laptop angeschlossenen 45 Zoll Plasmafernseher (118
cm Bildschirmdiagonale) mit einer Full HD-Auflösung von 1920 x 1080
Pixeln. Als Betriebssystem wird Windows 7 verwendet, auf welchem die
Crossplatform Open Source Anwendung Blender 2.6 ausgeführt wird. Diese übernimmt das Ressourcenmanagement und startet die Spielszene. Die
Spiellogik auf dem Server wurde in der high-level Scriptsprache Python
3.2 geschrieben. Die einzelnen Softwaremodule, die im Zuge dieser Arbeit
entwickelt wurden, werden im Folgenden detailliert beschrieben.
42
5.2
Bluetooth Verbindung und Messagehandling
Mit einer Reichweite von mindestens 10 Metern bietet die Funktechnologie
Bluetooth gute Voraussetzungen für eine kabellose Controllerverbindung
zu einem in der Nähe befindlichen Empfänger. Mittels Bluetooth kann eine
Direktverbindung zwischen zwei Geräten hergestellt werden, ohne dass
weiteres Routing notwendig ist. Zudem kann ein Bluetooth Gerät mit mehreren Geräten gleichzeitig verbunden sein. Dadurch ist es nicht nötig, dass der
Spieler, bevor er an dem Spiel teilnehmen kann, die Verbindung zu bereits
verwendeten Bluetoothgeräten, beispielsweise einem Headset, trennt. Das
RFCOMM Bluetooth Protokoll bietet ähnlich zu TCP einen verlässlichen Datenaustausch ohne Paketverlust. Zudem emuliert das Protokoll die serielle
Schnittstelle RS-232, die vor der Nutzung von USB ein häufig verwendeter Anschluss für Game Controller und andere Eingabegeräte war (siehe
[RFC01]).
Eigene Praxistests bestätigen die Eignung der Bluetooth Technologie: Das
Spiel kann von jeder Position aus gesteuert werden, von der die Inhalte
auf dem 45 Zoll Bildschirm gut erkennbar sind. Zudem ist keine Latenzzeit
der Datenübertragung spürbar, so dass auf Eingaben des Smartphones eine
unmittelbare Reaktion der Spiellogik erfolgt.
Unter Android können alle Schritte, um eine Verbindung zum Server herzustellen, aus der bereits gestarteten Anwendung heraus eingeleitet werden
(vergleiche Spezifikation 6.3). Der Benutzer ist also nicht gezwungen, in
den Systemmenüs seines Smartphones Einstellungen vorzunehmen. Soll
während des Ausführens einer Anwendung der inaktive Bluetooth Adapter
aktiviert werden, wird der Benutzer hierum in Form einer Messagebox um
Berechtigung gebeten. Aus Sicherheitsgründen ist vor dem Verbindungsaufbau eine Paarung der Geräte notwendig, die einmalig vom Benutzer über
über eine Messagebox bestätigt werden muss. Anschließend kann die eigentliche Verbindung zwischen Server und Client hergestellt werden.
Beim Starten der Serveranwendung wird ein „ListenSocket“ geöffnet, der in
einem Thread darauf wartet, dass ein Client über das RFCOMM Protokoll
eine Verbindung herstellt. Befindet sich ein Spieler in der Nähe und möchte
eine Verbindung herstellen, startet der Client ebenfalls einen Thread, welcher das Bluetoothgerät des Clients nach der eindeutigen MAC-Addresse
43
des Servers suchen lässt. Wurde das Gerät gefunden, stellt der Client eine
Verbindungsanfrage an den ListenSocket des Servers, der daraufhin einen
Service startet, der mit einem eindeutigen Universally Unique Identifier
(UUID) gekennzeichnet ist. Jeder freie Spielerslot erhält einen eigenen UUID,
der erst wieder freigegeben wird, wenn ein Spieler die Verbindung beendet. Dem Client sind die UUIDs jedes Spielerslots ebenfalls bekannt und er
versucht sich nacheinander mit diesen zu verbinden. Sind keine Slots frei,
entweder weil kein Server geöffnet wurde oder weil alle Plätze von Spielern
belegt sind, beendet das der Client die Suche erfolglos. Bei einer erfolgreichen Verbindung wird sowohl auf dem Server als auch auf dem Client ein
neuer Socket vom jeweiligen Bluetoothgerät erstellt, welche miteinander
kommunizieren. Um eine Networkmessage zu empfangen, wird auf beiden
Systemen ein neuer Thread gestartet, der in einer Endlosschleife den Eingangsstream des Sockets ausliest. Bei eingehenden Networkmessages wird
eine Callback-Funktion aufgerufen, welche diese behandelt. Zudem können
Networkmessages über den Schreibbefehl des Sockets zum jeweils anderen
Gerät versendet werden.
Die hier verwendeten Networkmessages bestehen aus einem 4 Byte großen
Networkmessage-Header und einem bis zu 12 Byte großen NetworkmessageBody. Der Header enthält die ID einer vom Empfänger aufzurufenden
Methode, während der Body die Aufrufparameter bestimmt. Der Body
kann beispielsweise 12 Character Werte zur Übertragung von Text oder
3 Float Werte enthalten, was einem dreidimensionalen Float Vektor entspricht.
Da die Spiellogik des Servers in Python 3.2 implementiert wurde, muss die
Bluetooth Verbindung ebenfalls eine kompatible Python API bereitstellen.
Bislang existiert jedoch kein Python Modul, das diese Aufgabe erfüllt. Die
C++ Bibliothek „Winsock 2“ des Windows SDK stellt allerdings Funktionen
bereit, um einen Bluetooth Service unter Windows 7 zu implementieren.
Um die Funktionalität von Winsock 2 auch in der Python API zugriffsfähig
zu machen, wurden zwei Ansätze verfolgt, von denen der erste verworfen
wurde:
44
5.2.1
Verworfener Ansatz: Winsock 2 Bindings für Python
Der erste Ansatz bestand darin, die nötigen Funktionen der Winsock 2
Bibliothek in einer Shared Library für Python zugänglich zu machen. Dazu
wurden unter anderem Funktionen in eine Python API überführt, um einen
Socket zu erstellen und die Funktionen listen() und accept() zum
Aufbau der Verbindung, sowie receive() und send() zum Empfangen
und Senden von Networkmessages zugriffsfähig zu machen. Erste Tests
zeigten jedoch, dass das Threading, welches dazu nötig ist, simultan zum
Verbindungsaufbau und Networkmessagehandling weitere Berechnungen
durchzuführen, unter Python zu starken Geschwindigkeitseinbußen der
Anwendung führt. Insbesondere der Aufruf der listen() Funktion, die
erst zurückspringt, wenn eine Verbindung aufgebaut wird, führt dazu, dass
der Python Interpreter währenddessen nicht den Thread wechseln kann und
die Anwendung einfriert, bis die Verbindung hergestellt wird. Dies liegt
wahrscheinlich am Global Interpreter Lock (GIL) des C-Python Interpreters.
Auch daraufhin wird nur in den Hauptthread des Programms gewechselt,
wenn die receive() Funktion zurückspringt, was nur der Fall ist, wenn
der Socket eine Networkmessage des Clients empfängt. Aufgrund dieses
Verhaltens, wurde der Ansatz fallen gelassen und die folgende Alternative
umgesetzt.
5.2.2
Threading innerhalb der C++ Shared Library
Die Idee des zweiten Ansatzes bestand darin, das Threading im C++ Code der Shared Library durchzuführen. Die listen() Funktion und die
receive() Funktion warten also in eigenen Threads unabhängig vom
Python Interpreter auf die Verbindungsanfrage und die hereinkommenden Networkmessages. Tests zeigten, dass damit das vorherige Problem
behoben wurde.
Jedoch trat ein neues Problem auf: Da die receive() Funktion in einem
vom Python Interpreter unabhängigen Thread ausgeführt wurde, war es
nicht ohne weiteres möglich, einen Python Callback im Falle hereinkommender Networkmessage aufzurufen. Damit keine Networkmessage unbehandelt verloren geht, falls mehr als eine pro Logik-Intervall empfangen
45
wird, muss eine Lösung durch Pufferung der Networkmessages erfolgen. In
der vorliegenden Umsetzung wird jede Networkmessage eines receive()
Rücksprungs in eine Datenstruktur gespeichert. Diese Datenstruktur hat die
Funktion eines Posteingangs. Die Python API des Moduls gewährt lediglich
Lesezugriff und eine clear() Funktion auf die Datenstruktur. In jedem Berechnungsintervall der Spiellogik der Blender Game Engine (im Folgenden
„Logik-Tick“ genannt) kann somit der Posteingang abgerufen und geleert
werden. Anschließend wird über alle eingegangenen Networkmessages
iteriert und jeweils die im Header referenzierte Funktion aufgerufen.
5.3
Implementierung der Clientanwendung unter Verwendung
des Android SDK
Die Android Clientanwendung besteht aus einer Menge von Activity
Klassen, denen jeweils eine View Ressource zugewiesen ist, welche ein grafisches Layout definiert. Die initiale MainActivity stellt den Einsprungspunkt der Clientanwendung dar. Sie bleibt die gesamte Laufzeit des Spiels
über aktiv und enthält das Spielermodell, das alle nötigen Informationen
über den Spieler kapselt. Bei Instanziierung der MainActivity werden
aus einer Konfigurationsdatei die zuletzt getätigten Personalisierungseinstellungen in das Spielermodell geladen. Anschließend wird die Mainview
angezeigt, die das Hauptmenü und den Identifikationsbereich enthält, in
dem der Name und die Farbe des Spielers in Form eines farbig hinterlegten
Label Widgets dargestellt werden. Die Callback-Funktionen der Buttons
starten weitere Activities, wie die OptionsActivity, in der Personalisierungseinstellungen geändert und anschließend in die Konfigurationsdatei
geschrieben werden. Befindet sich der Server in der Nähe, kann eine Bluetoothverbindung mit Hilfe des integrierten Bluetooth Geräts hergestellt
werden.
5.3.1
Implementierung der Zwille
Nach dem Verbindungsaufbau kann die GameActivity gestartet werden,
welche die Mainview auf die Gameview wechselt. Diese besteht aus einem zweigeteilten Layout bestehend aus Inventar und Zwille. Das Inventar
46
A
B
TB
ɑ
β
TA
Finger
Abbildung 12: Eine schematische Zeichnung des Gummibands
besteht aus dem gewöhnliche Android Widget einer Buttonleiste. Die Zwille wird in einen großen OpenGL Surfacebereich gerendert. Der OpenGL
Renderer besitzt zwei Shaderprogramme: Eines zur einfachen Darstellung
statischer texturierter Meshes und eines zur Animation des Gummibandes
der Zwille. Da die Perspektive der Zwille sich nicht verändert, wird zu ihrer
Anzeige ein statisches zweidimensionales Billboard verwendet, wodurch
eine höhere visuelle Qualität und geringere Rechenlast erreicht wird.
Das Gummiband soll realitätsnah animiert sein und mit einem Finger gespannt werden können. Dazu reicht die Funktion des Single Touch Events
der Android API aus. Da die Spannbewegung nur in der Bildebene stattfindet, genügt auch hier eine zweidimensionale grafische Repräsentation.
Um ein ansprechendes Look and Feel zu erzeugen, ist es wichtig, dass
sich das Band dynamisch nach der Position des Fingers richtet. Dazu sind
einige geometrische Überlegungen unter Betrachtung der Abbildung 12
notwendig:
In gespanntem Zustand befindet sich der Finger an der Position des Bandes,
die am weitesten von der Geraden durch die Aufhängung der Bandenden
A oder B entfernt ist oder anders ausgedrückt, am Rand des Projektils. Von
dort aus beschreibt das Band eine Kreisform, die sich nach der Umspannung
eines kugelförmigen Projektils richtet. Dieser Kreis ist nur geöffnet bis zu
den Winkeln α und β an den Schnittpunkten der Kreistangenten TA und
TB , die durch die Bandenden verlaufen, damit (von unten betrachtet) eine
konvexe Form entsteht. Alle Punkte des Bandes liegen entweder auf einer
47
der beiden Strecken ATA und BTB zwischen jeweils einer Bandaufhängung
und ihrem Tangentenschnittpunkt oder auf dem Kreisbogen zwischen α
und β.
Die Position des Bandes lässt sich für jeden Punkt separat berechnen, wodurch es möglich ist, diesen Vorgang mit Hilfe der Grafikhardware zu parallelisieren. Das Ziel ist, die Vertices eines streifenförmigen Meshes derart
zu transformieren, dass sie sich gleichmäßig über die Form des gespannten
Gummibandes verteilen. Allerdings müssen die Punkte je nach ihrer Position mit einer Streckenfunktion oder mit einer Kreisfunktion transformiert
werden.
Um zu ermitteln, auf welchen Vertex die jeweilige Funktion zutrifft, ist es
notwendig, vor dem Parallelisierungsschritt die Längen der Strecken lA =
ATA und lB = BTB und die Bogenlänge lK zwischen α und β zu berechnen.
Anschließend werden die Längenverhältnisse r1 =
lA +lK
lA +lK +lB
lA
lA +lK +lB
und r2 =
berechnet, bei denen Umbrüche in der Transformationsfunktion
auftreten.
Diese Verhältnisse und die Funktionsparameter der Strecke und des Kreisbogens werden dem Vertexshader übergeben. Alle Vertices, die sich im
Verhältnis zur Gesamtlänge des Bandes bei einem Wert x < r1 und x > r2
befinden, werden entlang der Strecke ATA und BTB transformiert, die Vertices im Bereich r1 ≤ x ≤ r2 hingegen mit der Kreisfunktion.
Wird das Band losgelassen, beziehungsweise der Finger gehoben, wird das
Projektil in Richtung des Zentrum der Aufhängung beschleunigt. Nachdem
das Projektil das Zentrum passiert hat, werden die Funktionen des Vertexshaders in eine einfache Parabelfunktion übergeblendet, die entlang der Zeit
mit dem Wert einer abnehmenden Sinusschwingung skaliert wird. Dadurch
entsteht der Eindruck des Nachfederns.
5.3.2
Zielvorgang und Abfeuern der Projektile
Um die Bewegungen des Smartphones in einen Zielvorgang zu übersetzen,
müssen die Daten des Magnetfeldsensors und des Accelerometers abgerufen
werden. Der Ziel- und Schussvorgang setzt sich insgesamt aus drei Sensormessungen zusammen, die an den Server übertragen werden: Erstens aus
48
der Orientierung des Smartphones, zweitens aus der Bildschirmkoordinate
an welcher der Touchscreen bei Spannen des Gummibandes berührt wird
und drittens aus dem Zeitpunkt an dem das Band losgelassen wird. Sobald
eine der jeweiligen Informationen auf dem Smartphone anfällt, wird diese in
Anlehnung an einen gewöhnlichen Controller ohne vorherige semantische
Auswertung an den Server weitergeleitet und im dortigen Spielermodell
aktualisiert.
Der Beschleunigungssensor des Smartphones ermittelt mehrmals pro Sekunde die Kräfte, die auf das Smartphone wirken. In ruhiger Lage entsprechen
diese ausschließlich der Schwerkraft und geben somit Aufschluss über die
Neigung des Smartphones.
Für die Schussrichtung ist auch das Wissen über die Orientierung des Smartphones vonnöten. Die Beschleunigungssensoren lassen jedoch nur Messungen der linearen Bewegungen zu. Um Drehbewegungen, die bei einem
Zielvorgang üblich sind, zu erkennen, ist ein Gyroskop erforderlich. Dass
mit dieser Sensorik Zielbewegungen durchführbar sind, beweist das Wii
Spiel The Legend of Zelda: Skyward Sword18 , welches den Gyroskopgesteuerten Wii Remote Plus Controller verwendet. Allerdings sind Gyroskope
zu diesem Zeitpunkt in nur wenigen Smartphones verbaut. Eine weitere
Möglichkeit, die Orientierung zu bestimmen, stellt optisches Tracking dar.
Dieses besitzt den Vorteil, dass nicht nur die Orientierung, sondern auch
die Position des Geräts bestimmt werden kann. Dadurch können auch die
translatorischen Freiheitsgrade gesteuert werden. Am Beispiel von Biljet AR
wird deutlich, dass hierdurch ein sehr authentisches Gefühl einer Zielbewegung entsteht. Voraussetzung für einen sicheren Betrieb sind eine hohe
Rechenleistung, robuste Bildverarbeitungsalgorithmen und zum Teil spezielle Referenzpunkte, wie Marker oder Lichtemitter. Zudem ist optisches
Tracking anfällig für störende Umwelteinflüsse, wie etwa lichtarme Umgebungen. Auch die Notwendigkeit, die Kamera auf ein zu trackendes Objekt
oder eine erkennbare Struktur auszurichten, kann als Nachteil angesehen
werden. Aus diesen Gründen wird in der vorliegenden Implementierung
auf den Magnetfeldsensor zurückgegriffen. Dieser gehört zur üblichen Ausstattung eines Smartphones und misst, sofern keine Störquellen vorliegen,
das Magnetfeld der Erde.
18
The Legend of Zelda: Skyward Sword, Nintendo, 2011
49
N
α
N
β
Abbildung 13: Zwei Personen deuten mit ihren Smartphones auf den Monitor.
Nach der Kalibrierung stehen α und β fest. Diese dienen anschließend als Referenzwinkel der Zielrichtung.
Die Android API implementiert für einen einfachen Zugriff auf die Sensordaten eine Callback-Funktion getOrientation()(siehe [Goo12]), welche
bereits auf die Achsen des Smartphones umgerechnete Werte der Pitch und
Roll Rotation übergibt sowie den Azimut der Richtung, in welche die Oberkante des Smartphones zeigt (siehe Abbildung 13 ). Um die Zielrichtung
relativ zum Monitor zu bestimmen, ist die Kenntnis über die Ausrichtung
des Monitors wichtig. Dazu wird eine Kalibrierung vorgenommen, indem
mit dem Smartphone auf einen Fixpunkt am Bildschirm gedeutet wird und
der gemessene Azimut als Referenzwinkel gespeichert wird. Während des
Zielens wird stets der Referenzwinkel vom aktuellen Messwinkel unter
Berücksichtigung der zyklischen Eigenschaft des Winkelmaßes subtrahiert.
Sofern es sich um ein stationäres System handelt, kann diese Kalibrierung
einmalig erfolgen. Wird sie jedoch durch den Benutzer vor jedem Spiel
ausgeführt, kann zusätzlich die Abweichung berücksichtigt werden, die
durch die Standposition des Benutzers vor dem Monitor entsteht. Zudem
kann im Multiplayer Modus aus den Referenzwinkeln ermittelt werden, in
welcher Reihenfolge sich die Spieler vor dem Monitor befinden. Dadurch
können die Namensschilder der Spieler in der selben Reihenfolge auf dem
Bildschirm angezeigt werden.
50
5.3.3
Anzeige der Schussrichtung
Bei ersten Tests der Beispielanwendung fiel auf, dass es ohne ein Feedback
auf dem Monitor schwierig für den Spieler ist, die Schussbahn vorherzusagen. Dies ist damit zu begründen, dass die translatorischen Freiheitsgrade
nicht im Spiel berücksichtigt werden. Daher entstehen Ungenauigkeiten,
wenn der Spieler ausschweifende Bewegungen mit dem Smartphone ausführt oder vor dem Bildschirm seine Position verändert, ohne die Referenzwinkel mit einer erneuten Kalibrierung zu aktualisieren. Zudem verfälschen das Rauschen und die Trägheit der Accelerometer und des Magnetfeldsensors das Messergebnis. Als Resultat der Ungenauigkeit begannen
die Spieler probeweise Projektile zu schießen, um sich der gewünschten
Schussrichtung anzunähern. Daraus entstand leicht Frustration über viele
missglückte Treffer.
Um direktes Feedback synchron zur Bewegung zu erzeugen, wurde in einem
ersten Anlauf eine HUD (Head-Up Display)-Anzeige eines Fadenkreuzes
implementiert. Da sich jedoch der Ursprung der Schüsse nicht in der Kameraposition befindet, sondern in Anlehnung an den Abstand zwischen Hand
und Auge etwas unterhalb der Kameraposition und das Fadenkreuz keine
korrekte Projektion in die Tiefe darstellt, konnte die zweidimensionale Anzeige nicht ausreichend Informationen bieten, um zwischen Schussneigung
und Schussstärke zu differenzieren. Daher wurde die Idee eines Fadenkreuzes verworfen und durch die Anzeige der ballistischen Kurve ersetzt.
Diese passt sich der vorberechneten Flugbahn synchron zur Zielbewegung
an. Die Beziehung zwischen der Bewegungen des Smartphones und der
resultierenden Schussrichtung wird somit ersichtlich. Aufgrund des Tiefentests im Zuge des Rendervorgangs wird die Kurve genau an der Position
abgeschnitten, an welcher das Projektil auftreffen würde. Dadurch ist eine
eindeutige Vorhersage über den Kollisionspunkt möglich.
Der erste naive Ansatz bei der Animation der Kurve bestand darin, diese lediglich bei einem eingehenden Signal durch den Client zu aktualisieren. Da
eigenen Versuchen zufolge die Senderate der Sensormessungen jedoch lediglich bei unter zehn Signalen pro Sekunde liegt (eigene Messungen ergaben
90 eingehende Signale in 10 Sekunden), führte dies zu einem sichtbaren Ruckeln der ballistischen Kurve. Auch wurde deutlich, dass die Sensoren eine
51
hohe Trägheit aufweisen und nach einer ruckartigen Bewegung mit einem
spürbaren Verzug die angepeilte Richtung erreichen. Aus diesem Grund ist
es nötig, die Signale zu glätten. Da gewöhnliche exponentielle Glättung zu
besonders trägen Ergebnissen führte, wurde eine trendbehaftete doppelt
exponentielle Glättung nach dem Holt-Winters Verfahren implementiert
(siehe [KB04]). Hierdurch konnte die Verzögerung spürbar reduziert werden. Da die Glättung serverseitig zu jedem Logik-Tick vorgenommen wird,
ist zudem keine separate Interpolation für eine weiche Animation der Kurve
nötig.
5.4
Implementierung der Serveranwendung unter Verwendung
der Blender Game Engine
Serverseitig wurde die leistungsfähige Blender Game Engine als Basisframework verwendet. Diese bietet im Gegensatz zu anderen Game Engines
insbesondere den Vorteil, dass sie direkt in die Modellierungs- und Animationssoftware integriert ist und somit eine zügige Entwicklung und Anpassung der Spielinhalte zulässt. Der Workflow der durch diese Integration
ermöglicht wird, beinhaltet das Erstellen von 3D Modellen sowie deren
Texturierung, die Definition von GLSL Materialshadern und das Generieren von Keyframe-Animationen. Die so erstellten Objekte können ohne
einen separaten Exportvorgang in der virtuellen Szene instanziiert werden.
Testdurchläufe des Spiels werden ohne einen Kompiliervorgang aus der
Entwicklungssoftware heraus gestartet. Die dazu verwendete Skriptsprache
Python unterstützt diesen Vorgang zusätzlich: Da Kompilationszeiten bei
Änderung der Spiellogik wegfallen, werden empirische Anpassungsvorgänge beschleunigt. Somit ist es unter anderem möglich, die Funktionen und
Parameter von Spielsteuerung, Objektverhalten oder Regelbalancing vor
jedem Testdurchlauf zu optimieren. Die von Blender genutzte Python API
besitzt zu diesem Zweck unter anderem API Bindings für die Spiellogik,
OpenGL und die in Blender integrierte Echtzeitphysikengine Bullet.
Äquivalent zu den bei Android verwendeten Activities, die in Kapitel 5.3
beschrieben wurden, verhalten sich „Scenes“ für die Blender Game Engine.
Das Erzeugen der initialen Scene Mainscene stellt den Einsprungspunkt
der Anwendung dar. Ähnlich zu den Android Activities können Scenes
52
hinzugeladen und somit simultan ausgeführt werden. Mehrere gleichzeitig
ausgeführte Scenes werden übereinander in festgelegter Reihenfolge gerendert, wodurch sich beispielsweise HUDs realisieren lassen. Wird eine Scene
gestartet, werden die Ressourcen aller in dieser Scene befindlichen Blender
Objekte, wie Kameras, Lichter oder Geometrieobjekte geladen. Instanzen
werden beim Start der Scene jedoch nur von dazu vorgesehenen Objekten
(welche sich im ersten Blender Layer befinden) erzeugt.
In der vorliegenden Implementierung bleibt die Mainscene über die gesamte Laufzeit der Anwendung bestehen. Sie ist für das Rendern des HUDs
und das Ausführen der sceneübergreifenden Spiellogik zuständig, welche
die Spieler verwaltet und die Lobby oder den Schießstand als Backgroundscenes hinzulädt.
5.4.1
Blender Logic Bricks
Funktionen der Spiellogik werden in Blender mittels visueller Programmierung durch so genannte „Logic Bricks“ realisiert. Jedes Blender Objekt
kann ein eigenes Logiknetzwerk bestehend aus Logic Bricks enthalten. Dies
hat den Vorteil, dass das dynamische Verhalten des jeweiligen Objekts besonders unkompliziert während des Modelliervorgangs bestimmt werden
kann.
Logic Bricks bestehen aus „Sensors“, „Controllers“ und „Actuators“ und
sind an Objektinstanzen in einer Scene gebunden. Sensors fangen ähnlich eines Listeners objektbetreffende Events ab. Eine Spezialisierung des Sensors
ist etwa der „Delay Sensor“, der nach einer beliebigen zeitlichen Verzögerung, nachdem das Objekt instanziiert wurde, ein Signal ausgibt. Ein „Touch
Sensor“ hingegen signalisiert, dass das Objekt mit einem anderen Objekt
kollidiert. Der „Always Sensor“ gibt ohne ein spezifisches Event ein Signal
aus. Sensors können entweder so eingestellt werden, dass sie nur einmal
ausgelöst werden, wenn das Event zum vorherigen Logik-Tick verschieden
ist oder im „Trigger Mode“, der bewirkt, dass in jedem Logik-Tick ein Signal
ausgegeben wird. Zudem können die Events Parameter enthalten. Beispielsweise wird bei einem Touch-Event die ID des Kollisionspartners ermittelt
und als Parameter übergeben.
53
Sensors können mit einer n zu n Multiplizität an Controller geknüpft sein.
Die Aufgabe des Controllers besteht darin, auf alle eingehenden Sensor
Signale eine logische Operation auszuführen und das Resultat an alle angehängten Actuators weiterzuleiten. Beispielsweise werden im Falle eines
AND-Konjunktors erst die angehängten Actuators aktiviert, wenn alle eingehenden Sensors im selben Logik-Tick ein Signal ausgeben. Ein OR-Konjuktor
hingegen löst die Actuators bereits aus, wenn mindestens ein Sensorsignal
anliegt.
Ein Actuator entspricht schließlich einem Funktionsaufruf. Blender unterstützt eine Menge von Actuators, wie das Ausführen einer Animation, das
Starten oder Beenden von Backgroundscenes, das Wirken von Kräften auf
Physikobjekte und vieles mehr.
Verschiedene Objekte können über Messages miteinander kommunizieren.
Dazu stehen ein „Message Sensor“ und ein „Message Actuator“ zur Verfügung. Der Message Actuator erhält drei Parameter: Ein Blender Objekt als
Adressaten, einen Header String als Subject und einen Body bestehend aus
einem beliebigen primitiven Datentyp. Der Message Sensor gibt ein Signal
ab, sobald eine Message eingeht. Wahlweise kann ein Subject Filter angegeben werden, durch welchen nur Messages mit entsprechendem Header
akzeptiert werden.
Um Variablen zu speichern, steht pro Objekt eine „Game Property“ Tabelle
zur Verfügung, welche mit den Feldern der objektorientierten Programmierung gleichzusetzen ist. Unterstützte Datentypen sind lediglich die primitiven Typen Float, Boolean, String, Integer und Timer. Um Properties
zu prüfen, zu vergleichen oder zu überschreiben, sind spezielle „Property
Sensors“ und „Property Actuators“ vonnöten. Diese Form des Zugriffs stellt
sich als sehr umständlich heraus, da bereits für simple Operationen große
Logiknetzwerke verbunden werden müssen. Zudem ist es nicht vorgesehen,
Datenstrukturen durch Logic Bricks abzubilden.
5.4.2
Erweiterung durch Python Scripting
Um den Einschränkungen der Logic Bricks zu entgehen, sollen in komplexeren Fällen als bei der Bestimmung eines einfachen Objektverhaltens
54
die Logiknetzwerke mit Python Code ergänzt oder ganze Module ausgegliedert werden. Dies geschieht über einen speziellen „Python Controller“,
der ein Python Script bei einem eingehenden Sensor Signal ausführt. Innerhalb dieser Python Scripts stehen Befehle des Blender Game Engine API
Moduls bge zur Verfügung. Das Modul besitzt ein weiteres Untermodul
bge.logic mit dessen Hilfe direkt auf alle Blender Objekte jeder aktiven
Scene zugegriffen werden kann. Somit lassen sich alle Logiknetzwerke zur
Laufzeit des Programms verändern. Zudem können Signale zwischen den
Logikbausteinen abgefangen und ausgelöst werden. Da unter Python die
Klassenstruktur zur Laufzeit geändert werden kann, ist es möglich, mit diesen Scripts weitere Felder zum globalen bge.logic Objekt hinzuzufügen
und somit ebenfalls global zugriffsfähig zu machen.
In der vorliegenden Implementierung stellt das geometrielose Blender Objekt GAME die zentrale Verbindung zwischen den Logik Netzwerken und Python Modulen dar und wird bei der Initialisierung der Mainscene erzeugt.
Es besitzt einen Always Sensor, der bei Erstellung des Blender Objekts ein
Python Scipt ausführt, welches eine Instanz der Python Klasse PythonGame
erstellt und an das globale Objekt bge.logic.game knüpft. Ein zweiter
Always Sensor führt im Trigger Mode zu jedem Logik-Tick die Methode
bge.logic.game.update() aus.
PythonGame stellt somit die zentrale Klasse der Architektur dar, da es beim
Starten der Anwendung initialisiert und in jedem Logik-Tick aktualisiert
wird.
PythonGame verwaltet eine Liste aller verbundenen Spieler und besitzt
Funktionen zum Starten der Backgroundscene, wie der Lobby oder dem
Schießstand, und verwaltet das Regelobjekt der Klasse Rules, das zum
Ausführen der Automatismen während des Spielvorgangs dient. Das Regelobjekt definiert die Dauer einer Spielrunde und besitzt eine Datenstruktur
Timetable, bestehend aus Tupeln, die einem Zeitpunkt der Spielrunde
einen Funktiosaufruf zuweisen. Dadurch wird beispielsweise festgelegt,
dass nach 10 Sekunden ein Ballon in den Schießstand geschickt wird. Zudem
besitzt das Regelobjekt Funktionen, welche den Spielern Punkte gutschreiben oder ihnen neue Projektile bescheren.
55
Abbildung 14: Das Logiknetzwerk eines einfachen Zieles. Wenn das Ziel berührt
wird, wird das Script „iGotHit.py“ aufgerufen, das die Message
mit der Punktzahl an das GAME Objekt sendet und eine Animation
ausgeführt.
Damit diese Spielregeln in Kraft treten, müssen Events aus der Blender
Scene einen Funktionsaufruf in dem Python Modul auslösen. Die Anforderung besteht also darin, das Message System der Logic Bricks Domäne
mit dem Listener Pattern aus der objektorientierten Programmierung zu
verbinden. Dazu wird das Blender Objekt GAME durch einen Message Sensor ergänzt, der ungefiltert bei jeder eingehenden Message einen Python
Controller aktiviert, dessen Script die Message ausliest und die Funktion
game.messageHandler.receive() mit den Übergabeparametern des
Subject Headers und des Bodys der Message aufruft. Innerhalb der Funktion
werden den unterstützten Subjects Listen mit Callback-Funktionen zugewiesen. Wird ein Subject empfangen, so werden alle Callback-Funktionen der
jeweiligen Liste aufgerufen. Dadurch ist es zum Beispiel einfach, eine Regel
zu definieren, beim Treffen eines Ziels einem Spieler Punkte hinzuzufügen.
Dazu muss lediglich die entsprechende Funktionsreferenz an die Liste des
Subjects gehängt werden. Ausgelöst wird das Event, wie Abbildung 14 zeigt,
sobald der Touch Sensor des Ziels einen Message Actuator aktiviert, der
eine Message mit demselben Subject an das GAME Objekt sendet. Zudem
können Parameter, wie der Name des betroffenen Spielers oder die konkrete
Punktzahl im Message Body angegeben werden und als Übergabeparameter
der Callback-Funktionen dienen.
5.4.3
Physikalische Modellierung der dynamischen Objekte
Blender implementiert ein für das in Kapitel 4.2 vorgestellte Spielkonzept
gut geeignetes dynamisches Objektverhalten, das auf einer Verbindung
mit der Physikengine Bullet basiert. Bullet Physikkomponenten sind mit
56
einer 1 zu 1 Beziehung an Blender Renderkomponenten beziehungsweise
3D-Meshes geknüpft. Diese werden beim Ausführen der physikalischen
Echtzeitberechnung stets miteinander synchronisiert. Das bedeutet, dass
die Position und Orientierung einer Renderkomponente durch die Kollisionskörper der Physikkomponente bestimmt werden, wodurch sich sehr
leicht einfache Starrkörpersimulationen zur Umsetzung der Projektile, der
Bauklötze, der Taschenlampe und der Luftballons umsetzen lassen. Diese Objekte unterscheiden sich lediglich durch ihre Starrkörperparameter
voneinander. Die Parameter sind Kollisionsform, das Massezentrum, die
Skalierung des Trägheitstensors, die translatorische und rotatorische Dämpfung, sowie Materialeigenschaften wie der Reibungskoeffizient und die
Elastizität.
Die Kollisionsform gibt an, an welcher Stelle ein Objekt tatsächlich getroffen werden muss, damit eine Kollision erkannt wird. Dabei ist sie nicht
zwangsläufig identisch mit der grafischen Repräsentation des Objekts. Um
die Performanz der Physikberechnung zu steigern, wird die Kollisionsform
häufig durch eine Bounding Box, eine Kugel oder die konvexe Hülle repräsentiert. Beispielsweise ist die Kollisionsform des Standardprojektils eine
Kugel, während die Taschenlampe durch ihre konvexe Hülle abstrahiert
wird.
Das Massezentrum bestimmt den Punkt, um den sich ein Objekt mit geringstem Kraftaufwand drehen lässt. Hat ein Objekt einen Drehimpuls,
pendelt sich dieser ohne fremde Krafteinwirkung auf eine Rotation um das
Massezentrum ein. Bei der Taschenlampe befindet sich beispielsweise das
Massezentrum nicht im Mittelpunkt des Objekts, sondern näher in Richtung des Griffs, da sich dort im Gegensatz zum leichten Vorderbereich die
schweren Batterien befinden. Der Trägheitstensor beschreibt in diesem Zusammenhang die Masseverteilung innerhalb des Objekts. Je stärker sich die
Masse eines Objekts bezüglich einer Ebene im Massezentrum konzentriert,
desto kleiner ist der Trägheitstensor in Richtung der Normalen dieser Ebene.
Die komplexe Ermittlung des Trägheitstensors wird abhängig von der Form
des Objekts von der Physikengine übernommen. Einzig die Skalierung des
Trägheitstensors kann vom Benutzer gewählt werden. Beispielsweise besitzt
der mit Luft gefüllte Luftballon einen größeren Trägkeitstensor, als der geplatzte Luftballon, da sein Massezentrum in allen Ebenen weiträumig von
57
Luft umgeben ist und sich somit bei gleichem Drehimpuls langsamer dreht
als im zerplatzten Zustand.
Die translatorische und rotatorische Dämpfung gibt abstrahiert auf zwei
Werte an, wie stark ein Starrkörper durch äußere Einflüsse, wie dem Luftwiderstand, in seiner Bewegung gebremst wird. Eine hohe translatorische
Dämpfung kommt insbesondere bei der Simulation des aufgepumpten Luftballons zum Tragen, da dieser durch seine geringe Masse zwar stark durch
die Kollision mit anderen Objekten beschleunigt, jedoch durch sein großes
Volumen und den dadurch bedingten hohen Luftwiderstand zügig gebremst
wird.
Die physikalischen Materialeigenschaften sind nicht von einem einzelnen
Objekt, beziehungsweise seinem Material abhängig, sondern werden aus
Materialpaaren ausgewertet. Bullet vereinfacht diese Zuordnung durch die
Zuweisung eines Reibungswertes pro Material. Der Reibungskoeffizient
zweier Materialien wird aus diesen Reibungswerten berechnet. Zum Beispiel weisen die Luftballons einen hohen Reibungswert auf, die Steinwände
hingegen einen niedrigen. Somit sind zwei kollidierende Luftballons einander einer stärkeren Reibung ausgesetzt, als ein Luftballon und eine Wand.
Äquivalent verhalten sich die Elastizitätswerte zweier Materialien, die bestimmen, wie stark sich zwei kollidierende Objekte elastisch voneinander
abstoßen. Beispielsweise weisen die Luftballons hohe, der Boden und die
Bauklötze hingegen geringe Elastizitätswerte auf. Dies führt dazu, dass der
Bauklotz schwächer vom Boden zurückfedert, als der Luftballon.
Um Beziehungen zwischen dynamischen Objekten zu modellieren, die über
Kollisionen hinausgehenden, können Constraints bestimmt werden. Die
Zielscheiben sind mit einem Constraint ohne Freiheitsgrade jeweils mit
einem Schwenkarm befestigt, welcher wiederum durch einen winkelbeschränkten Scharnierconstraint an Wand, Boden oder Decke befestigt ist
und nach hinten geklappt werden kann. Je nachdem, ob die Zielscheibe
aufgerichtet sein soll oder nicht, wird eine zu diesem Scharnier tangentiale
Drehkraft auf den Schwenkarm ausgewirkt, welche ihn gegen die jeweilige
Winkelbeschränkungen des Scharniers drückt. Kollidiert ein dynamisches
Objekt mit der Zielscheibe, wird die Drehkraft mit dem Stoßimpuls verrechnet, was zu einer authentischen Animation führt: Die Zielscheibe wird nach
hinten gestoßen und richtet sich prompt wieder auf.
58
5.4.4
Implementierung des dynamischen Objektverhaltens
Wie in Kapitel 5.4.1 und 5.4.2 beschrieben, lösen Kollisionen im Logikprozessor der Blender Game Engine Sensor Events aus, die mit Python Scripts
und Messages behandelt werden können. Dadurch lassen sich Spielregeln,
wie hier am Beispiel der Zielscheibe implementieren: Zum einen soll die
Zielscheibe für einen gewissen Zeitraum inaktiv werden und sich nach
hinten klappen. Dazu wird innerhalb eines Zeitintervalls die Drehkraft des
Armes, an dem die Zielscheibe befestigt ist, umgekehrt. Zum anderen sollen
demjenigen Spieler, der mit einem Projektil eine Zielscheibe trifft, Punkte
gutgeschrieben werden. Dazu ist es notwendig, dass jedes Projektilobjekt
als Property eine Referenz auf denjenigen Spieler speichert, welcher es abgefeuert hat. Zudem besitzt die Zielscheibe einen Message Actuator, welcher
die gutzuschreibende Punktzahl im Body definiert und diese bei Berührung
einmalig an den Spieler sendet.
Eine andere Methode der Punktevergabe verwenden die in Kapitel 4.2.2
beschriebenen Bauklötze, die zu Türmen aufgestellt sind. Diese schreiben
dem Spieler Punkte für die Strecke gut, die sie im Zuge eines Treffers zurücklegen. Dazu wird in jedem Logik-Tick die zurückgelegte Strecke mit einem
Punktefaktor gewichtet und auf den Punktestand des Spielers addiert.
Hierbei bestehen zwei Probleme: Würde erstens, wie im Fall der Zielscheibe,
die Referenz auf den Spieler nur als Membervariable des Projektils gespeichert, schriebe dies dem Spieler nur Punkte zum Zeitpunkt der Kollision
gut, jedoch nicht während der anschließenden Bewegung. Befände sich also
der Bauklotz während der Kollision im Ruhezustand, würde der Spieler
keinerlei Punkte für den Treffer erhalten. Zweitens kommt nicht jeder Bauklotz, der im Zuge eines Schusses beschleunigt wird, auch mit dem Projektil
des Schützen in Berührung. Wird beispielsweise ein Klotz aus der unteren
Turmreihe herausgeschossen, kippt der Turm um, wodurch viele Bauklötze
ihre Position verändern. Beide Probleme lassen sich dadurch lösen, dass
jeder Bauklotz ebenfalls eine Referenz auf einen Spieler besitzt, welche
durch die Kollisionsevents mit Projektilen oder ihn berührenden Bauklötzen
weitergegeben wird. Es werden bei Beschleunigung eines Bauklotzes also
demjenigen Spieler Punkte gutgeschrieben, der die Kettenreaktion ausgelöst
hat.
59
Das Dynamit ist ein komplexeres Projektil als das Standardprojektil. Wird es
in die Szene geschossen, bleibt es eine Weile regungslos liegen, bevor es deto~
niert und naheliegende Objekte aus Richtung seines Detonationszentrums C
beschleunigt. Dazu wird über alle dynamischen Objekte Oi ∈ {O0 ..On } mit
~ i iteriert und jeweils ein Impulsvektor P~i = X~ i −C~ · Pmaxu
den Positionen X
di
(di +1)
~ i − C|
~ zum Detonationszentrum bemit der euklidischen Distanz di = |X
rechnet. Dieser Impulsvektor wird auf den bestehenden Impulsvektor jedes
Objekts addiert. Durch die Parameter Pmax und u lässt sich die Detonation
zum Balancing des Spiels einstellen: Der Skalar Pmax gibt den maximalen
Impuls an, der bei einer Nulldistanz auf ein Objekt wirkt. Je weiter die
Objekte entfernt sind, desto schwächer ist der Impuls. Die Potenz u gibt an,
wie stark der Impuls bei steigender Entfernung abnimmt. Bei u = 0 wirkt
auf alle Objekte der Szene der gleiche Impuls, während die Auswirkung
bei u = 4 nur Objekte in unmittelbarer Nähe zum Detonationszentrum
sichtbar ist. Alle Bauklötze, bei denen dieser Impuls über einem bestimmten
Schwellwert liegt, erhalten die Referenz auf den Spieler, der das Dynamit
geworfen hat, damit dieser Punkte für die anschließende Bewegung der
Bauklötze erhält.
60
6
Evaluation der Beispielanwendung
Zur Evaluation der Software fand im Rahmen dieser Arbeit eine Benutzertestreihe statt (siehe Abbildung 15). In dieser wurden Testpersonen gebeten,
die Beispielanwendung zu spielen und darauf bezogene Fragen zu beantworten. Zudem wurde das Spielverhalten der Probanden beobachtet und
dokumentiert. Der Test fand in zwei Phasen statt: Einer Singleplayer- und
einer Multiplayerphase.
Für jede Phase wird zunächst eine Reihe von Hypothesen aufgestellt. Daraufhin wird die Zielsetzung des Testverlaufs beschrieben, welche jeder Proband
eigenständig erfüllen sollte. Den Probanden wurde keine Aufgabe textuell
vorgegeben, da sie sich implizit aus der Selbstbeschreibungsfähigkeit der
Software ergeben sollten. Der Proband wurde lediglich zur Personalisierung
der Spielerdaten und zur Nutzung alternativer Projektile durch den Spielleiter aufgefordert. In der darauffolgenden Bewertung wird das Vorgehen
der Probanden beschrieben und analysiert, um die aufgestellten Hypothesen zu stützen oder zu widerlegen. Dazu dienen Beobachtungen und die
aus der Befragung hervorgehenden Statistiken. Anschließend lassen sich
weiterführende Erkenntnisse, wie Lösungen zur Verbesserung mit Hilfe der
Probandenaussagen herleiten.
6.1
Vorstellung der Probandengruppe
Die Probandengruppe besteht aus 7 Studenteninnen und 9 Studenten unterschiedlicher Fachbereiche (1 der Volkswirschaftslehre, 3 der Grundschulpädagogik, 1 der Wirtschaftsinformatik, 11 der Computervisualistik) im
Alter zwischen 20 und 30 Jahren. Das Durchschnittsalter liegt bei 25 Jahren
bei einer Varianz von 4,25. Personen in dieser Altersklasse wurden ausgewählt, da sie die Hauptzielgruppe des vorgestellten Systems bilden. 15 der
Probanden (94%) besitzen ein eigenes Smartphone, während sieben (44%)
mindestens wöchentlich auf diesem ein Spiel spielen. Elf Personen gaben
an, häufiger als einmal pro Woche Videospiele im Allgemeinen zu spielen.
Lediglich vier Testpersonen (25%) konnten an diesem Test mit ihrem eigenen Smartphone teilnehmen, da die Beispielimplementierung nur auf das
Betriebssystem Android 2.3 beschränkt war.
61
Abbildung 15: Zwei Probandinnen während der Multiplayer Phase
62
6.2
Die Singleplayer Phase
Die erste Phase simuliert die Situation, nachdem der Proband das Spiel
in der Öffentlichkeit entdeckt und die Clientanwendung installiert hat.
Diese Situation ist in sofern authentisch, dass der Proband zuvor noch
kein derartiges Spiel mit seinem Smartphone bedient hat. Da er zuerst
ohne weitere Mitspieler mit dem Spiel interagiert, dient diese Phase der
Erkenntnisgewinnung im Bezug auf die Interaktion des Spielers mit dem
Spiel. (siehe Kapitel 1.5)
6.2.1
Testverlauf und Zielsetzung der Phase
Der Proband wird vor dem ersten Start des Spiels aufgefordert, den Identifikationsbereich mit Namen und Spielerfarbe zu personalisieren. Die Phase
beginnt damit, dass der Spieler vor dem Bildschirm steht, auf dem die Lobby
angezeigt wird.
Der Proband hält das Smartphone mit der gestarteten Clientanwendung
in der Hand und wird anhand der Reihenfolge, in der die Menüpunke
eingeblendet werden, durch die notwendigen Schritte geführt. Im Personalisierungsmenü soll er seine Spielerfarbe wählen und den Spielernamen
eingeben. Anschließend soll er die Verbindung mit dem Server herstellen,
indem er den Login-Befehl ausführt, so dass sein Namensschild auf dem
Monitor erscheint. Ihm soll bewusst sein, dass die Verbindung erfolgreich
hergestellt wurde und der Server nun auf das Smartphone reagiert. Er
führt die Kalibrierung aus und startet das Spiel. In diesem Zusammenhang
werden folgende Hypothesen und Subhypothesen aufgestellt:
H1 „Der Smartphone-Controller ist aufgrund seiner spezifischen Merkmale für die Steuerung eines unbetreutes Kiosksystem geeignet.“
H1.1 „Da der Benutzer mit dem Smartphone vertraut ist, fällt ihm die
Interaktion mit dem System leicht.“
H1.2 „Die Nutzung des eigenen Smartphones zum Steuern des Systems wird der eines propietären Eingabegeräts vorgezogen.“
H1.3 „Die Mobilitätseigenschaften des Smartphones werden als Mehrwert wahrgenommen. Darunter fallen das ,Mitnehmen‘ von Per63
sonalisierungsdaten und Spielständen sowie das Tätigen von
Einstellungen ohne direkte Verbindung zum Server.“
Nachdem der Spieler die Spielrunde gestartet hat, soll ihm sofort klar sein,
welche Beziehung zwischen der Zwille der Clientanwendung und dem
Schießstand der Serveranwendung besteht. Er soll das Gummiband der
Zwille als interaktives Element erkennen und es mit einem Finger spannen.
In Folge dessen soll er die ballistische Kurve auf dem Monitor bemerken
und verstehen, wie diese sowohl durch Neigung des Smartphones als auch
durch die Fingerbewegung auf dem Touchpad beeinflusst werden kann.
Ebenso soll der Proband herausfinden, dass durch Anheben des Fingers
der Schuss ausgelöst wird. Der Spieler soll nach einer kurzen Eingewöhnungszeit gezielte Schüsse abfeuern können, ohne zwischendurch auf das
Smartphone schauen zu müssen. Er soll die virtuelle Szene ohne eine konkrete Herausforderung erkunden und dabei versuchen, die Zielscheiben und
Bauklötze zu treffen und die physikalischen Auswirkungen eines Schusses
nachzuvollziehen.
H2 „Die Möglichkeit der Bewegungssteuerung eines Smartphones kann
genutzt werden, um den Spieler einsteigerfreundlich und intuitiv mit
einem stationären Action- und Geschicklichkeitsspiel interagieren zu
lassen.“
H2.1 „Durch die erweiterten Möglichkeiten der Grafiken auf Smartphone und Monitor kann die bewegungsgesteuerte Interaktion
selbsterklärend eingeführt werden.“
H2.2 „Die Bewegungssteuerung des Smartphones bietet die Möglichkeit eines präzisen Zielvorgangs mit kurzen Reaktionszeiten.“
H2.3 „Synchrones grafisches Feedback auf dem betrachteten Bildschirm
ist notwendig, damit sich der Spieler auf die Bewegungssteuerung verlassen kann.“
In weiteren Spielrunden soll der Proband auch das alternative DynamitProjektil anwenden. Sollte er dieses nicht bereits aus eigenen Stücken gefunden haben, wird er durch den Testleiter auf diese Möglichkeit aufmerksam
gemacht. Folgende Hypothesen sollen in diesem Zusammenhang untersucht werden:
64
H3 „Die Informationen des Smartphone-Displays lassen sich parallel zum
Verlauf eines Action- und Geschicklichkeitsspiels auf dem Monitor
wahrnehmen und können eine sinnvolle Ergänzung der Spielinhalte
darstellen.“
H3.1 „Die Direktselektion sichtbarer Items mit Hilfe des Touchscreens
wird als Vorteil angesehen.“
H3.2 „Dem Spieler fällt es leicht, seine Aufmerksamkeit zwischen dem
Smartphone-Display und dem Monitor zu wechseln.“
6.2.2
Ergebnisauswertung und Erkenntnisse
Die Reihenfolge, in der die spielvorbereitenden Aktionen ausgeführt werden mussten, wurde von allen Testpersonen eigenständig erkannt. Dies
lässt darauf schließen, dass der Menüaufbau als logisch und selbsterklärend
angesehen wurde. Anfänglich ausgegraute Widgets wurden von allen Testpersonen als inaktiv interpretiert, da diese Semantik in vielen SmartphoneAnwendungen verwendet wird. Auch die sich aufklappende Bildschirmtastatur, die erst bei einem Druck auf das Eingabefeld erscheint, war für die
Probanden problemlos zu finden. Das Color-Widget hingegen, das zur Auswahl der Spielerfarbe verwendet wurde, ist nicht im Standardrepertoire des
Smartphones vorhanden. Hier war vielen Testpersonen nicht auf den ersten
Blick ersichtlich, wie die Auswahl bestätigt werden musste. Diese Erkenntnis zeigt, dass der Spieler seine Erfahrungen aus der Smartphonenutzung als
technisches Vorwissen in die Benutzung des Smartphone-Controllers einfließen lassen kann, womit sich Subhypothese H1.1 untermauern lässt.
Damit hebt sich das smartphonegesteuerte System von Spielen mit proprietären Eingabegeräten ab: Bei diesen kann nicht vorausgesetzt werden, dass
der Benutzer die systemspezifischen Eigenschaften bezüglich der Usability
beherrscht. Diese Erkenntnis kann bewusst durch den Entwickler eines
smartphonegesteuerten Kiosksystems unterstützt werden, indem er sich
beim Design der Clientanwendung an dem Styleguide des Betriebssystems
orientiert. Zudem kann der Spielentwickler eine für jedes Betriebssystem
angepasste Version der Clientsoftware bereitstellen. Der Nachteil der Benutzung von fremden Eingabegeräten lässt sich auch an einem speziellen Fall in
65
diesem Benutzertest verdeutlichen: Um aus Subviews zurück zur Mainview
zu navigieren, musste die Testperson den integrierten Zurück-Befehl des
Smartphones ausführen. Dieser musste jedoch insbesondere von den Probanden, die nicht ihr eigenes Smartphone benutzten, zuerst gesucht werden.
Das Vorwissen bezüglich der Normen, wie das Aktivieren der SoftwareTastatur oder das Ausgrauen inaktiver Bereiche, konnte in diesem Fall nicht
eingesetzt werden, da sich der Befehl auf verschiedenen Geräten an unterschiedlichen Stellen verbirgt. Beispielsweise wird der Zurück-Befehl beim
Apple iPhone gewöhnlich durch eine Wischgeste ausgeführt, während beim
Huawai Ideos X3 ein Soft-Button und beim HTC Desire ein haptischer Button verwendet wird. Geht man allerdings davon aus, dass jeder Spieler, wie
im ursprünglichen Konzept des Smartphone-Controllers beschrieben, sein
eigenes Gerät verwendet, wird dieser Nachteil aufgehoben. Auch in dieser
Eigenschaft bietet das System Vorteile gegenüber einer integrierten oder
proprietären Steuerung, wie im Fall gängiger stationärer Videospiele.
Die Vorteile, die sich daraus ergeben, die Menüs auf dem Smartphone anzuzeigen, wurde auch von den Testpersonen erkannt und als Mehrwert
wahrgenommen. Wie Abbildung 16 zeigt, gab der größte Anteil der Befragten nach der Testphase an, es als hilfreich zu empfinden, die Eingaben nicht
am PC, sondern auf dem Smartphone zu tätigen. Zudem beantworteten alle
Probanden, die ihr eigenes Smartphones benutzen konnten, diese Frage mit
„sehr hilfreich“. Daher kann die Richtigkeit der Subhypothese H1.2 angenommen werden. Zwei Motivationen für diese Antwort werden in Betracht
gezogen: Erstens könnte der Spieler den Weg zum PC vermeiden wollen,
der vor jeder Spielrunde nötig wäre. Zweitens könnte er die Usability des
ihm nicht vertrauten PC Systems komplizierter erwarten als die Bedienung
der Smartphone-Anwendung.
Aus den Umfrageergebnissen aus Abbildung 17 und Abbildung 18 geht
hervor, dass das Speichern von Benutzerdaten auf dem Smartphone als besonders nützliche Fähigkeit des Geräts angesehen wird. Auch die Tatsache,
diese Einstellungen auch ohne eine Verbindung zum Server zu tätigen, wird
von den Probanden als „sehr gut“ angesehen. Dadurch lässt sich Hypothese
H1.3 bestärken. Gründe für die positive Resonanz könnten sein, dass es
als Vorteil gesehen wird, die Personalisierung nicht vor jedem Spiel erneut
manuell durchführen zu müssen oder sich nicht vor jeder Spielsitzung ein-
66
sehr hilfreich
eher hilfreich
neutral
eher nicht hilfreich
gar nicht hilfreich
0
1
2
3
4
5
6
7
8
9
Abbildung 16: Umfrage: „Wie hilfreich fanden Sie, dass Sie das Spiel starten konnten, ohne direkt den PC zu bedienen?“, Median (M ) der gegebenen
Antworten: „sehr hilfreich“
sehr gut
gut
neutral
schlecht
sehr schlecht
0
1
2
3
4
5
6
7
8
9
10
Abbildung 17: Umfrage: „Wie gefiel Ihnen, dass die persönlichen Einstellungen
unabhängig von der Station getätigt werden konnten?“ M :„sehr
gut“
sehr gut
gut
neutral
schlecht
sehr schlecht
0
1
2
3
4
5
6
7
8
9
10
Abbildung 18: Umfrage: „Wie gefiel Ihnen, dass Ihre persönlichen Einstellungen
(Spielerfarbe, Spielername) auf dem Smartphone gespeichert wurden?“ M :„sehr gut“
67
zuloggen, wie es im Falle der Datenspeicherung auf dem Server erforderlich
wäre. Hierdurch hebt sich das Spiel von gängigen stationären Videospielen
ab. Aus den oben ausgeführten Subhypothesen lässt sich die Eignung des
Smartphones für die Steuerung eines unbetreuten Kiosksystems bezüglich
Hypothese H1 ableiten.
Als nächstes wird die Qualität der Bewegungssteuerung eines Action- und
Geschicklichkeitsspiels unter Verwendung eines Smartphone-Controllers
diskutiert. Die allgemeine Bewertung der Steuerung fiel, wie in Abbildung
20 sichtbar, mit dem Medianwert M : „neutral“ aus. Um die Gründe hierfür
festzustellen, soll die Erlernbarkeit unabhängig von Präzision und Reaktionsgeschwindigkeit betrachtet werden. In den Umfragebögen wurde allerdings nicht zwischen diesen Eigenschaften differenziert. Daher lassen sich
zu deren Analyse lediglich Beobachtungen und textuelle Kommentare der
Probanden zurate ziehen.
Zunächst soll auf die Erlernbarkeit eingegangen werden. Erwähnenswert
ist in diesem Zusammenhang, dass es sich um die simultane Steuerung von
drei Freiheitsgraden handelt: Pitch, Yaw und die Entfernung durch die Skalierung der Schusskraft auf dem Touchscreen. Allerdings war zu beobachten,
dass jeder Spieler die Beziehung zwischen der Smartphone-Anwendung
und dem Spiel auf dem Bildschirm verstand. Von allen Probanden wurde
das Smartphone ohne weitere Anleitung und Vorkenntnisse in korrekter
Weise auf den Bildschirm gerichtet und die Tatsache, das Gerät bewegen zu
müssen, intuitiv als Steuerung angenommen. Dies ist dadurch zu erklären,
dass die Selbstbeschreibungsfähigeit der Grafiken und somit der Transfer
von Vorwissen zum Tragen kam. Das animierte Gummiband in der Mitte
der abgebildeten Zwille wurde von jedem Spieler umgehend als interaktives Touchscreenelement wahrgenommen. Dadurch, dass der Monitor einen
Raum in der Fluchtpunktperspektive anzeigt, war den Probanden klar, dass
die Bewegung des Smartphones relativ zum Monitor als Zielgeste fungieren musste. Die textuellen Kommentare zweier Probanden stützen diese
Behauptung. Sie hoben die einfache Erlernbarkeit positiv hervor, wodurch
Subhypothese H2.1 unterstrichen wird. Allerdings sind auch Einschränkungen für diese Hpothese gegeben: In einem Kommentar wurde die Anzahl
der Freiheitsgrade kritisch beäugt und als Grund für einen erschwerten Einstieg genannt. Beobachtungen zufolge war vielen Probanden nicht bewusst,
68
3
wichtig
11
5
eher wichtig
5
6
neutral
3
11
2
2
eher unwichtig
unwichtig
0
5
10
aufwändige Spielgrafik
15
20
präzise Steuerung
25
plausible Spielphysik
Abbildung 19: Umfrage: „Wie wichtig ist Ihnen eine aufwändige Spielgrafik 1
/ präzise Steuerung 2 / plausible Spielphysik 3 ?“ M1 : „neutral“/“eher wichtig“, M2 : „wichtig“, M3 : „eher wichtig“
sehr gut
3
3
gut
7
2
10
neutral
3
schlecht
3
8
8
1
sehr schlecht
0
5
10
15
die Spielgrafik auf dem Monitor
20
die Steuerung
25
die Spielphysik
Abbildung 20: Umfrage: „Wie gefiel Ihnen die Spielgrafik auf dem Monitor 1 / die
Steuerung 2 / die Spielphysik 3 ?“ M1 : „gut“, M2 : „neutral“, M3 :
„gut“
sehr gut
gut
neutral
schlecht
sehr schlecht
0
1
2
3
4
5
6
7
8
9
10
Abbildung 21: Umfrage: „Wie gefiel Ihnen das Spiel im Allgemeinen?“ M : „sehr
gut“
69
dass lediglich eine Messung der Orientierung des Controllers erfolgte, jedoch keine Positionsmessung. Dieses Verständnisproblem wurde dadurch
deutlich, dass die Probanden das Smartphone „aus einer Armbewegung
heraus“ bewegten, wobei die Orientierung des Smartphones kaum verändert wurde. Der Hinweis durch den Testleiter, das Smartphone „aus dem
Handgelenk heraus“ zu bewegen, war somit erforderlich.
Vier Probanden (25%) bemängelten in einem Freitextfeld explizit die Reaktionsgeschwindigkeit der Steuerung. Dies ist auf die technischen Eigenschaften des Magnetfeldsensors und die starke Glättung der Messwerte
zurückzuführen. Die Glättung wurde deshalb so stark eingestellt, um die
Präzision des Zielvorgangs zu erhöhen. Die Präzision wurde von einer Person (6%) als positiv herausgestellt, allerdings von drei Probanden (19%)
kritisiert. Beobachtungen ergaben, dass häufig Schüsse nicht wegen mangelnder Präzision ihr Ziel verfehlten, sondern weil die Schusskraft nicht
korrekt eingeschätzt und die Zielscheiben somit nicht erreicht wurden, obwohl die Richtung präzise angepeilt wurde. Da die Beobachtungen von den
Benutzerkommentaren abweichen, ist es schwierig, eine Aussage darüber
zu treffen, ob die Präzision der Steuerung tatsächlich der ausschlaggebende
Punkt für die Schwierigkeiten war. Zusammengefasst lässt sich Subhypothese H2.2 mit den vorliegenden Ergebnissen nicht untermauern.
Vor dem Test wurden die Probanden gefragt, wie wichtig ihnen generelle Eigenschaften von Action-Videospielen sind. Wie Abbildung 19 zeigt,
wurde die Präzision der Steuerung (M : „wichtig“) stärker gewichtet, als
etwa eine aufwändige Spielgrafik (M : „eher wichtig“) oder die Spielphysik
(M : „neutral“). Somit liegt zwar die Erwartung nahe, dass sich die kritisierte Steuerung (siehe Abbildung 20) negativ auf die Gesamtbewertung
des Spiels auswirken würde, allerdings wurde dies nicht durch die anschließende Umfrage bestätigt. Das Spiel wurde trotz der kritisierten Steuerung
im Allgemeinen als (M :)„sehr gut“ bewertet (siehe Abbildung 21). Einen
Grund dafür stellt mit hoher Wahrscheinlichkeit die synchron zum Zielvorgang angezeigte ballistische Kurve dar. Dies lässt sich dadurch bestätigen,
dass 87% der Befragten die Darstellung der ballistischen Kurve auf den Monitor als „sehr hilfreich“ empfanden (siehe Abbildung 22). Nach wenigen
Schüssen beherrschten die Probanden das Spannen der Zwille, ohne auf den
Bildschirm des Smartphones zu schauen, da die ballistische Kurve ein direk-
70
sehr hilfreich
eher hilfreich
neutral
eher nicht hilfreich
gar nicht hilfreich
0
2
4
6
8
10
12
14
16
Abbildung 22: Umfrage: „Wie hilfreich fanden Sie die Anzeige der ballistischen
Kurve auf dem Monitor?“ M : „sehr hilfreich“
25
4
20
3
15
PC-Maus1
Wiimote2
Light Gun3
Xbox360 / PS3
Controller4
Kinect5
4
1
10
8
5
0
7
4
1
2
3
4
2
viel schlechter schlechter etwa gleich gut
1
2
1
1
besser
viel besser
3
Abbildung 23: Umfrage: „Wie gut wären andere Eingabegeräte im Vergleich zum
Smartphone-Controller für dieses Spiel geeignet?“ M1 : schlechter,
M2 : etwa gleich gut, M3 : etwa gleich gut, M4 : schlechter, M5 :
schlechter
71
tes Feedback der Zielgesten auf dem Monitor darstellt. Differierte hingegen
die Anzeige von der angestrebten Zielrichtung, warteten die Probanden mit
dem Schuss auf die träge nachziehende Kurve, bis diese in die gewünschte
Richtung zeigte. Der Spieleinfluss der Trägheit der Steuerung konnte somit
kompensiert werden. Somit lässt sich Subhypothese H2.3 bekräftigen.
Zusammenfassend kann Hypothese H2 nur mit Einschränkungen unterstützt werden. Die Steuerung wurde zwar nicht als ausgereift angesehen,
allerdings konnte mit visuellen Hilfen dennoch ein gutes Spielgefühl erzeugt werden. Eine abschließende Befragung bestätigt, dass der SmartphoneController aus Sicht der Probanden besser für dieses Spiel geeignet erscheint,
als die meisten anderen, zum Teil bewegungsgesteuerten Eingabegeräte (siehe Abbildung 23).
Allerdings nannten auf die Frage hin, welche Anzeige sich der Spieler
auf dem jeweils anderen Bildschirm gewünscht hätte, 9 Probanden (56%)
die Munitionsanzeige. Daher lässt sich Hypothese H3 mit den bisherigen
Tests nicht belegen. Folgende Gründe können dafür in Betracht gezogen
werden:
1. Es wurde nicht als Vorteil erkannt, dass die Projektile direkt mit Druck
auf das entsprechende Symbol ausgewählt werden konnten. Dieser
Grund ist jedoch unwahrscheinlich, da die Direktauswahl eine besonders intuitive Form der Menüselektion darstellt. Die Alternative der
Auswahlmethode wäre das Ausführen einer Geste, welche wiederum
nicht auf das Vorwissen des Benutzers aufbauen könnte. Somit trifft
die Begründung der Subhypothese H1.1 auch auf Subhypothese H3.1
zu.
2. Es fiel den Spielern nicht leicht, die Aufmerksamkeit zwischen Smartphone und Monitor zu wechseln. Dieser Grund kann als zutreffend
angesehen werden. Auf die Frage, weshalb die Munitionsanzeige auf
dem Monitor angezeigt werden sollte, antworteten alle Befragten, dass
es schwer falle, den Blick vom Monitor zu lösen. Subhypothese H3.2
kann somit als falsch angesehen werden.
Zusammenfassend lässt sich aus den Benutzertests die allgemeine Erkenntnis ziehen, dass im Kontext der kombinierten Interaktion, bestehend aus
einem stationären Display und einem Smartphone-Touchscreen, einige
72
Design-Entscheidungen beherzigt werden müssen. Insbesondere bei konzentrationsintensiven Aufgaben, wie dem Spielen eines Action- und Geschicklichkeitsspiels ist die Art der Information entscheidend dafür, ob sie
auf dem Smartphone oder auf dem Monitor angezeigt werden sollte. Die
Darstellung der Zwille auf dem Smartphone trug zwar entscheidend zur
Erlernung der Steuerung bei, nachdem diese verinnerlicht wurde verlor sie
allerdings an Bedeutung für den Spieler, da nun das synchrone grafische
Feedback auf dem Monitor relevant für eine gute Spielerleistung wurde.
Die Munitionsanzeige auf dem Smartphone wurde nun als Einschränkung
der verinnerlichten Steuerung angesehen.
Allgemein ausgedrückt handelt es sich um Informationen unterschiedlicher
Art, die verschieden behandelt werden müssen: Eine statische Information,
die sich während des Spiels nicht verändert (zum Beispiel der Ort auf dem
Touchscreen, an dem das Gummiband gegriffen werden muss) und eine
dynamische Information, die während des Spiels aktualisiert wird (zum
Beispiel die Anzahl der verfügbaren Projektile im Inventar oder die ballistische Kurve). Die Erkenntnis lautet, dass während das Hauptfeedback
der Eingabe auf dem Monitor erfolgt, zwar statische Informationen wie die
Anordnung der interaktiven Elemente auf dem Touchscreen (zum Beispiel
bei Unklarheiten bezüglich der Steuerung) sinnvolle Anhaltspunkte bieten
können, jedoch alle dynamischen Informationen auf dem Monitor angezeigt
werden sollten. Zudem sollten die interaktiven Elemente auf dem Touchscreen durch einprägsame Gesten bedient werden können, die auch dann
leicht auszuführen sind, wenn die Aufmerksamkeit des Benutzers nicht auf
dem Smartphone liegt.
6.3
Die Multiplayer Phase
In dieser Phase ist bereits jeder Spieler mit der Steuerung und den Regeln
des Spiels vertraut. Jede Probandengruppe besteht aus zwei bis sechs Personen, von denen zwei bis drei Spieler gleichzeitig an einer Spielrunde
teilnehmen. Die Interaktion der Spieler untereinander wird gemäß Kapitel
1.5 im Folgenden analysiert. Außerdem wird auf Grundlage der Probandenbefragung die Frage diskutiert, ob diese Art des Multiplayer Games
73
für öffentliche Nutzung, beispielsweise im touristischen Umfeld, geeignet
wäre.
6.3.1
Testverlauf und Zielsetzung der Phase
Im Gegensatz zu der Singleplayer Phase besteht nun das Ziel darin, innerhalb der Spielrundenzeit von 60 Sekunden eine höhere Punktzahl zu
erreichen als die Gegenspieler. Durch die alternativen Projektile ist es den
Spielern möglich, sich einen beachtlichen Punktevorsprung gegenüber den
anderen Spieler zu verschaffen. Diese Phase zeichnet sich durch wechselnde
Spielteilnehmer in einer beliebigen Anzahl von Spielrunden aus. Es darf
ein Wechsel zwischen Zuschauern und Spielern stattfinden, wodurch eine
soziale Atmosphäre entstehen soll.
H3 „Ein stationäres Multiplayer Game mit Smartphone I/O eignet sich
als öffentliche Gruppenaktivität.“
H3.1 „Das Spiel kann Spieleinsteigern ein starkes Multiplayer Erlebnis
vermitteln.“
H3.2 „Die Kommunikation zwischen den Spielern wird durch gemeinsame interaktive Spielobjekte gefördert.“
H3.3 „Das Spiel wird als öffentliche Attraktion akzeptiert.“
6.3.2
Ergebnisauswertung und Erkenntnisse
Das Multiplayer Erlebnis wurde besonders positiv aufgenommen. Die Nachteile des Smartphone-Controllers, die aus der Singleplayer Phase deutlich
wurden, nahmen kaum einen negativen Einfluss auf den Spielverlauf der
Multiplayer-Phase. Dies ist damit zu begründen, dass alle Spieler gleichermaßen von den Einschränkungen der Steuerung betroffen waren, so dass für
das Spiel faire Rahmenbedingungen galten. Durch die kurze Spielzeit von 60
Sekunden wurden häufig neue Runden begonnen und die Spielteilnehmer
gewechselt. Es entstanden Diskussionen über erfolgsträchtige Spielweisen.
Da die Wahrnehmung des Spiels nur schwierig durch vorgegebene Antworten adäquat ausdgedrückt werden kann, wurden die Probanden unmittelbar
74
nach der Phase gebeten, ihre Eindrücke des Spiels in einem Freitextfeld mitzuteilen. Folgende Zitate entstammen den Antworten auf die Fragestellung:
„Was hat Ihnen an dem Spiel gut gefallen oder Sie positiv überrascht?“
• „Das Spielprinzip ist gut durchdacht und setzt den Spieler sofort in eine motivierende Situation (beim 2 Player-Versus jedenfalls). Die Items
machen Sinn und das Entwickeln eigener Strategien wird geschickt
gefördert.“
• „Die Steuerung war zwar ein wenig hakelig aber dennoch macht es
Spaß, vor allem wenn man gegen jemanden spielt.“
• „[Mir gefiel der] Nervenkitzel, die Ziele zu treffen und gegen den
Gegner zu gewinnen.“
• „[Mir gefiel,] dass man sich verschiedene Strategien aussuchen konnte
und die Features wie Dynamit und Affenkopf.“
• „Besonders gut fand ich die verschiedenen Munitionen und deren
Wirkungen. Es hat sich ein echtes Duell mit dem Mitspieler ergeben, da
zeitweilig auch nur ein Ballon abzuschießen war, um neue Munitionen
zu erlangen. Die variantenreichen Items waren ansprechend und gut
mit verschiedenen Aufgaben bzw. Wirkungen verknüpft.“
Da sich die positiven Eindrücke auf die Motivation und das Multiplayer
Erlebnis beziehen, lässt sich Subhypothese H3.1 unterstreichen. Zudem
wurden die alternativen Projektile, wie das Dynamit und der Monkeyhead
positiv erwähnt. Während der Beobachtung der Spieler fiel auf, dass der
Effekt des Monkeyheads häufig zu provokanten und ironischen Kommentaren führte (beispielsweise „bitteschön“ und „na vielen Dank“), welche
jedoch positiv sozial konnotiert waren. Das Schießen des Dynamits wurde
zum Spannungsmoment, da der Schütze auf die Detonation in der Nähe
der Bauklötze hoffte, während die Gegner versuchten, es zu entfernen. Der
Zeitpunkt der Detonation ging zum Teil mit einer lautstarken Emotionalexpression des erfolgreichen Spielers einher. Diese Beobachtungen stützen
Subhypothese H3.2.
Da das Spiel nicht an einem frei zugänglichen Ort in der Öffentlichkeit und
nur im Rahmen dieses Tests gespielt wurde, ist es schwierig eine Aussage
über Subhypothese H3.3 zu treffen. Allerdings wurden die Pobanden nach
75
14
12
12
10
8
8
8
7
6
6
6
5
4
3
2
2
0
4
4
4
1
1
zu Hause1
ja
vielleicht
in einer Bar2
1
vor einem Schaufenster
in der Fußgängerzone3
nein
im Wartebereich
eines Flughafens4
auf der Kirmes
oder einer ähnlichen
Freiluftveranstaltung5
Abbildung 24: Umfrage: „Können Sie sich vorstellen, das Spiel an folgenden Orten
zu spielen?“ M1 : „ja“, M2 : „vielleicht“, M3 : „vielleicht“, M4 : „ja“,
M5 : „ja"/"vielleicht“
der Testphase gefragt, ob sie sich vorstellen könnten, das Spiel zu Hause
oder an einer Auswahl öffentlicher Orte zu spielen. Das Umfrageergebnis
bestätigt die Ergebnisse der in Kapitel 1.5 beschriebenen Vorabbefragung,
dass im Allgemeinen die Motivation ein Videospiel in der Öffentlichkeit zu
spielen wesentlich geringer ist als im privaten Umfeld. Allerdings wurde
insbesondere der Wartebereich eines Flughafens, der an das FlughafenSzenario aus Kapitel 1.1 angelehnt ist, von 8 der 16 Befragten (50% mit zwei
Enthaltungen) als ein Ort angegeben, an dem sie das Spielen dieses Spiels in
Betracht ziehen würden. Das Spielangebot in der Fußgängerzone, angelehnt
an das Schaufenster-Szenario aus Kapitel 1.3, würden hingegen nur 4 Personen (25%) nutzen. Zusammengefasst wird die öffentliche Nutzung des
Systems zwar theoretisch akzeptiert, dennoch ist die Motivation stark von
äußeren Einflüssen und der Situation abhängig, in welcher die Person in
Kontakt mit dem Spiel geraten würde. Begünstigen die situativen Faktoren
diese Motivation, ist die Akzeptanz eines stationären Multiplayer Games
mit Smartphone I/O zur öffentlichen Gruppenaktivität gemäß Hypothese
H3 allerdings gegeben.
76
7
Fazit
Durch Benutzertests konnte gezeigt werden, dass ein stationäres Multiplayer Game mit Smartphone I/O die Voraussetzungen für eine spannende
und kommunikative Gruppenaktivität besitzt und eine starke soziale Atmosphäre erzeugen kann. Die Spieler hatten große Freude an den Interaktionsmöglichkeiten des neuartigen hybriden Videospielsystems und daran, diese
Erfahrungen mit ihren Mitspielern zu teilen.
Aus Sicht des Entwicklers lassen sich diverse Vorzüge des in dieser Arbeit
vorgestellten Systems aufzeigen und durch die vorliegende Implementierung belegen. Die Möglichkeit, alle Spieler an dem Bildschirm eines leistungsfähigen PCs spielen zu lassen, behält den Vorteil, dass etablierte Entwicklungsumgebungen und APIs genutzt werden können, um die zentralen
Inhalte des Spiels zu erstellen. Dadurch ist ein zügiger Workflow möglich,
ohne auf Gerätekompatiblitäten eingehen oder auf starke leistungstechnische Einschränkungen achten zu müssen. Lediglich die Clientanwendung
auf dem Smartphone erfordert diesen weiteren Schritt. Im Vergleich zu
reinen Smartphone Multiplayer Games ist es nicht nötig, einen komplexen
Spielstatus, zum Beispiel schnelle Abfolgen von Spielzügen oder das Ergebnis physikalischer Berechnungen zwischen den Geräten zu synchronisieren,
da alle Eingaben direkt an den Server weitergeleitet werden können, der die
gesamte Spiel-Logik berechnet.
Im Bezug auf das Game-Design lässt das System einen Großteil der etablierten Paradigmen aus bekannten Arcade- oder Konsolenspielen zu, die dazu
eingesetzt werden können, dem Spieler einen einfachen Einstieg und ein intensives Multiplayer Erlebnis zu bieten. Daher besteht auch die Möglichkeit,
das einsteigerfreundliche Spiel in der Öffentlichkeit zu platzieren und als
unbetreutes Kiosksystem zu betreiben. Im Gegensatz zu konventionellen
Arcade Games können zudem diverse Vorteile des Smartphone-Controllers
ausgenutzt werden. Die Spieler können Spieldaten mitnehmen und austauschen. Während des Spiels halten sie ein vertrautes Eingabegerät in der
Hand und müssen sich nicht an proprietäre Steuergeräte gewöhnen. Der
Touchscreen lässt zudem eine besonders flexible Gestaltung der Steuerung
zu. Er unterstützt Zeigegesten und Buttons, die mit der Bewegungssteuerung mit Hilfe der Beschleunigungs- und Magnetfeldsensoren des Smart77
phones kombiniert werden können. Wie die virtuelle Zwille zeigt, können
dadurch neue Möglichkeiten des Game-Designs umgesetzt werden, die
sich von konventionellen Steuerungen abheben und neue Spielerfahrungen
schaffen.
78
8
Ausblick
Da das Spiel bisher nur im universitären Umfeld gespielt wurde, wäre es
interessant, seine Akzeptanz auch in der allgemeinen Öffentlichkeit zu untersuchen und es als unbetreutes Kiosksystem über einen längeren Zeitraum
zu betreiben. Dadurch ließen sich weitere Erkenntnisse über das Nutzerverhalten und die Eignung als touristische Anwendung gewinnen. Das Spiel
könnte zu diesem Zweck in einen tieferen touristischen Kontext gesetzt
werden. Zum Beispiel können Spiele mit themenbezogenen Inhalten an
öffentlichen Orten platziert werden oder eine Verknüpfung mit sozialen
Netzwerken zu einem ubiquitären Spiel stattfinden. Da für das Platzieren in
der Öffentlichkeit im Gegensatz zu aufwändigen Arcade Systemen lediglich
ein leistungsstarker PC und ein konventioneller Bildschirm erforderlich
sind, können Spielideen schnell und kostengünstig umgesetzt werden. Somit könnte das System auf die wirtschaftlichen Aspekte geprüft werden. Da
die Smartphone-Applikation aus dem Softwaremarkt des Betriebssystemherstellers bezogen wird, lassen sich neuartige Geschäftsmodelle für Mobile
Applications auf das System übertragen.
Um die Robustheit des Systems zu gewährleisten sind jedoch noch weitere
Optimierungen im Zusammenhang mit der Usability notwendig. Zu diesem
Zweck könnte eine differenzierte Evaluation der Steuerung durchgeführt
werden, die zwischen Präzision, Trägheit und Anzahl der Freiheitsgrade unterscheidet. Zudem könnte die Steuerung für die Verwendung neuer Smartphones, die ein Gyroskop aufweisen, angepasst werden. Dieses zeichnet sich
durch wesentlich zügigere Reaktionszeiten im Bezug auf die Messung der
Orientierungsänderung aus als der in dieser Arbeit verwendete Magnetfeldsensor. Alternativ ließen sich Messverfahren einsetzen, welche die genaue
Position des Smartphones bestimmen, wie etwa optisches Tracking.
Auch ließen sich weitere Fähigkeiten des Smartphones nutzen. Zum Beispiel wären Augmented Reality Elemente auf dem Touchscreen denkbar.
Auch das Kiosksystem ließe sich mit Sensoren, wie einer Webcam oder einer
Microsoft Kinect ausstatten, um zusätzliche Interaktionsmöglichkeiten herzustellen, die zu weiteren kreativen Spielkonzepten führen können.
79
Abbildungsverzeichnis
1
Schematische Darstellung des Setups . . . . . . . . . . . . . .
4
2
Tilt-Racer Screenshot und Spielteilnehmer, Quelle: Vajk2008
7
3
Smartymote Spieler, Quelle: [Bae11] . . . . . . . . . . . . . .
8
4
Anteil der Smartphone-Nutzern an Handybesitzern, Quelle:
[Mel11] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
12
Scrabble für das iPad, Quelle: Offizielles Werbevideo, Electronic Arts, 2010 . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
6
Spannvorgang der Zwille . . . . . . . . . . . . . . . . . . . .
33
7
Interaktive Objekte . . . . . . . . . . . . . . . . . . . . . . . .
35
8
Der Schießstand . . . . . . . . . . . . . . . . . . . . . . . . . .
35
9
Alle Views des Singleplayer Modus . . . . . . . . . . . . . .
38
10
Ansicht der Gameview auf dem Smartphone . . . . . . . . .
40
11
Bildschirmansicht eines 2-Spieler Spiels . . . . . . . . . . . .
40
12
Schematische Zeichnung des Gummibands . . . . . . . . . .
47
13
Referenzwinkel für die Zielrichtung . . . . . . . . . . . . . .
50
14
Das Logiknetzwerk eines einfachen Zieles . . . . . . . . . . .
56
15
Zwei Probandinnen während der Multiplayer Phase . . . . .
62
16
Umfrageergebnisse bezüglich der Interaktion mit dem Server
über das Smartphone . . . . . . . . . . . . . . . . . . . . . . .
17
Umfrageergebnisse bezüglich Personalisierungseinstellungen auf dem Smartphone . . . . . . . . . . . . . . . . . . . . .
18
67
67
Umfrageergebnisse bezüglich der Speicherung von Personalisierungseinstellungen auf dem Smartphone . . . . . . . . .
67
19
Umfrageergebnisse zur Gewichtung der Bewertungskriterien 69
20
Umfrageergebnisse zur Bewertung der Spielkriterien . . . .
21
Umfrageergebnisse zur Bewertung des Spiels im Allgemeinen 69
22
Umfrageergebnisse bezüglich der ballistischen Kurve . . . .
71
23
Umfrageergebnisse bezüglich alternativer Eingabegeräte . .
71
24
Umfrageergebnisse zur öffentlichen Nutzung des Spiels . . .
76
80
69
Literatur
[Ada09]
A D A M S , Ernest ; J O H N S O N , Karyn (Hrsg.): Fundamentals of
Game Design. Prentice Hall, 2009. – 700 S. – ISBN 0321643372
[Bae11]
B A E , Minu: Smartymote : Revolutionizing the Gaming and
Social Experience. (2011)
[Bal98]
B A L Z E R T , Helmut: Lehrbücher der Informatik. Bd. 1 Software:
Lehrbuch der Software-Technik. Spektrum Akademischer Verlag,
1998. – ISBN 3827400651
[BG96]
B O O S , Margarete ; G Ö T T I N G E N , Universität: S o z i a l p s yc
h o l o g i s c h e G r u n d l a g e n c o m p u t e r - vermittelter
Kommunikation Überblick Die Theorie der sozialen Präsenz. In:
Text (1996), S. 1–16
[DV99]
D E N N I S , A R. ; V A L A C I C H , J S.: Rethinking media richness:
towards a theory of media synchronicity. In: Proceedings of the
32nd Annual Hawaii International Conference on Systems Sciences
1999 HICSS32 Abstracts and CDROM of Full Papers 00 (1999), Nr.
c, S. 10. ISBN 0769500013
[Esa11]
E N T E R T A I N M E N T S O F T WA R E A S S O C I A T I O N : Essential
Facts About the Computer and Video Game Industry. 2011. –
Forschungsbericht
[Goo12]
G O O G L E:
Android API Reference.
http://developer.
android.com/reference. Version: 2012
[Juu09]
J U U L , Jesper: A Casual Revolution: Reinventing Video Games
and Their Players. MIT Press, 2009. – 252 S. http://www.
jesperjuul.net/casualrevolution/. – ISBN 0262013371
[KB04]
K A L E K A R , Prajakta S. ; B E R N A R D : Time series Forecasting
using Holt-Winters Exponential Smoothing Under the guidance
of. In: Technology (2004), Nr. 04329008, S. 1–13
[Kro08]
K R O S T A , Michael:
Nur mit Text-Kommunikation.
http:
//www.4players.de/4players.php/spielinfonews/
81
Allgemein/9267/1752798/Mario\_Kart\_WiiNur\
_mit\_Text-Kommunikation.html. Version: 2008
[Luh87]
L U H M A N N , Niklas: Soziale Systeme. Suhrkamp, 1987. – 443 S. –
ISBN 3518282662
[Mel11]
M E L Z E R,
Deutschland.
Rene:
Smartphones
überholen
Handys
in
http://www.areamobile.de/news/
20981-comscore-studie-smartphones-ueberholen-.
handys-in-deutschland. Version: 2011
[NVI12]
N V I D I A:
NVIDIA Tegra Mobilprozessoren.
http://www.
nvidia.de/object/tegra-3-de.html. Version: 2012
[Pri06]
P R I N Z , Wolfgang: Pervasive Games, Fraunhofer FIT, 2006
[RFC01]
RFCOMM with TS 07.10. In: Bluetooth Specification Version 1
(2001)
[Sch01]
S C H WA B E , G: Mediensynchronizität - Theorie und Anwendung bei Gruppenarbeit und Lernen. In: H E S S E , F (Hrsg.) ;
F R I E D R I C H , H (Hrsg.): Partizipation und Interaktion im virtuellen
Seminar. Waxmann, 2001, S. 111–134
[Ste11]
S T E I N L E C H N E R , Peter: iOS und Android gewinnen spielend
Marktanteile.
http://www.golem.de/1104/82903.html.
Version: 2011
[Tho03]
T H O R E S S O N , Johan: PhotoPhone entertainment. In: CHI 03
extended abstracts on Human factors in computing systems PLAY,
Interactive Institute, ACM Press, 2003. – ISBN 1581136374, 896–
897
[VCBE08] V A J K , Tamas ; C O U L T O N , Paul ; B A M F O R D , Will ; E D WA R D S ,
Reuben: Using a Mobile Phone as a Wii-like Controller
for Playing Games on a Large Public Display. In: International
Journal of Computer Games Technology 2008 (2008), S. 1–6. – ISSN
1687–7047
[WBB+ 06] W A L Z , Steffen P. ; B A L L A G A S , Rafael ; B O R C H E R S , Jan ;
M E N D O Z A , Joel ; K R A T Z , Sven ; W A R T M A N N , Christoph
; F U H R , Claudia ; T A N N , Martin J. ; S H I N , Dong Y. ; H A 82
M E E D,
Bilal ; B A R D O S , Laszlo ; H O V E S T A D T , Ludger: Cell
Spell-Casting: Designing a Locative and Gesture Recognition
Multiplayer Smartphone Game for Tourists. In: Proc PERGAMES
Third International Workshop on Pervasive Gaming Applications at
Pervasive 2006, LNCS, 2006
[WBJ96]
W A T Z L A W I C K , Paul ; B E AV I N , Janet H. ; J A C K S O N , Don D.:
Menschliche Kommunikation. Huber, 1996. – 271 S.. – ISBN
345682825X
[Wic08]
W I C K E N S , Christopher D.: Multiple Resources and Mental
Workload. In: Human Factors 50 (2008), Nr. 3, S. 449–455
83