Benutzeroberflächen für Computerspiele im öffentlichen Raum by Martina Huber

Benutzeroberflächen für Computerspiele im öffentlichen Raum

Martina Huber

BACHELORARBEIT Nr. 1410238031-A eingereicht am Fachhochschul-Bachelorstudiengang

Medientechnik und -design in Hagenberg

im Mai 2017

Diese Arbeit entstand im Rahmen des Gegenstands

Semesterprojekt 2 im Wintersemester 2016/2017

Betreuer:

Wolfgang Hochleitner, MSc

Erklärung Ich erkläre eidesstattlich, dass ich die vorliegende Arbeit selbstständig und ohne fremde Hilfe verfasst, andere als die angegebenen Quellen nicht benutzt und die den benutzten Quellen entnommenen Stellen als solche gekennzeichnet habe. Die Arbeit wurde bisher in gleicher oder ähnlicher Form keiner anderen Prüfungsbehörde vorgelegt.

Hagenberg, am 12. Mai 2017

Martina Huber

iii

Inhaltsverzeichnis Erklärung

iii

Kurzfassung

Abstract

vii

1 Einleitung 1.1 Problemstellung . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Lösungsansatz . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . .

1 1 1 2

2 State of the Art 2.1 Begriffsklärung . . . . . . . . . . . . . . . 2.1.1 Large Public Display Games . . . 2.1.2 Tracking . . . . . . . . . . . . . . . 2.1.3 Natural User Interface . . . . . . . 2.2 Large Public Display Games und Tracking 2.2.1 Deep Space 8K . . . . . . . . . . . 2.2.2 Lasertracking-System „Pharus“ . . 2.3 Arten von Interfaces . . . . . . . . . . . . 2.3.1 Bodenprojektion . . . . . . . . . . 2.3.2 Wandprojektion . . . . . . . . . . 2.3.3 Player View . . . . . . . . . . . . .

3 3 3 3 4 4 4 5 5 6 6 6

. . . . . . . . . . .

3 Richtlinien für Benutzeroberflächen von co-located LPD Games 3.1 Bodeninterface . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.1 Schattenbildung . . . . . . . . . . . . . . . . . . . . . 3.1.2 Trackingprobleme . . . . . . . . . . . . . . . . . . . . 3.2 Wandinterface . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1 Kontrast . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.2 Orientierung . . . . . . . . . . . . . . . . . . . . . . . 3.2.3 Position von Spielelementen . . . . . . . . . . . . . . . 3.2.4 Zusätzliche Informationen . . . . . . . . . . . . . . . . iv

8 8 8 9 10 10 10 11 12

Inhaltsverzeichnis 3.3

Allgemein . . . . . . . . . . . . 3.3.1 Player View . . . . . . . 3.3.2 Sprache . . . . . . . . . 3.3.3 Piktogramme und Icons 3.3.4 Audio . . . . . . . . . .

v . . . . .

. . . . .

12 13 13 14 14

4 Analyse bestehender LPD Games 4.1 Game Changer Suite . . . . . . . . . . . . . 4.1.1 Analyse Game Changer Suite . . . . 4.2 Limelight . . . . . . . . . . . . . . . . . . . 4.2.1 Analyse Limelight . . . . . . . . . . 4.3 Lazor Lab . . . . . . . . . . . . . . . . . . . 4.3.1 Analyse Lazor Arena und Lazor Lab 4.4 Woolpy . . . . . . . . . . . . . . . . . . . . 4.4.1 Analyse Woolpy . . . . . . . . . . .

. . . . . . . .

16 16 18 23 24 25 26 27 27

5 ResĂźmee 29 5.1 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . 29 5.2 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Quellenverzeichnis 31 Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Online-Quellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Kurzfassung Computerspiele in öffentlichen Räumen, wie zum Beispiel im Deep Space 8K des Ars Electronica Centers, werden von Personen unterschiedlichen Alters und unterschiedlicher Herkunft gespielt. Die Benutzer und Benutzerinnen sprechen verschiedene Sprachen oder können teilweise nicht lesen. Weiters haben diese Spieler und Spielerinnen oft keine Zeit, komplizierte Abläufe aus den Spielen zu lernen, da sie diese meist nur kurz spielen. Durch jenes breitgefächerte Publikum und die kurze Spielzeit benötigt man eine einfach verständliche Benutzeroberfläche. In dieser Bachelorarbeit werden verschiedene Richtlinien für solch ein User Interface für co-located Computerspiele im öffentlichen Raum herausgearbeitet und die Benutzeroberflächen verschiedener Spiele für das Deep Space 8K mithilfe der herausgearbeiteten Punkte analysiert.

Abstract Computer games in public places, such as the Deep Space 8K of the Ars Electronica Center are played by people of different ages and origin. The users speak different languages, or partially can not read. Furthermore, these players often have no time to learn complicated sequences from these games, as they usually play only briefly. This broad audience and the short playing time require a simple user interface. In this thesis, various guidelines for such a user interface for co-located computer games in public places are worked out and the user interfaces of various games for the Deep Space 8K are analyzed using the points worked out.

vii

Kapitel 1

Einleitung 1.1

Problemstellung

Computerspiele in öffentlichen Räumen, wie zum Beispiel im Deep Space: Spielräume 1 im Ars Electronica Center, werden von Personen unterschiedlichen Alters und unterschiedlicher Herkunft gespielt. Die Benutzer und Benutzerinnen sprechen verschiedene Sprachen oder können teilweise nicht lesen. Weiters haben diese Spieler und Spielerinnen oft keine Zeit, komplizierte Abläufe zu erlernen, da sie das Spiel meist nur kurz spielen. Durch dieses breitgefächerte Publikum und die kurze Spielzeit kommt es zu Schwierigkeiten bei der Vermittlung der Mechaniken und der Handlung des Spiels. Aus diesen Ansätzen ergibt sich die folgende Forschungsfrage für diese Bachelorarbeit: Wie kann eine Benutzeroberfläche für Large Public Display Games (LPD Games) aussehen, um einem möglichst großen Publikum die Mechaniken und die Handlung des Spiels verständlich und in kürzester Zeit zu übermitteln?

1.2

Lösungsansatz

In dieser Bachelorarbeit werden verschiedene Richtlinien für solch ein User Interface für Computerspiele im öffentlichen Raum herausgearbeitet und die Benutzeroberflächen verschiedener Spiele für das Deep Space: Spielräume mithilfe der herausgearbeiteten Punkte analysiert. Um die bereits angeführte Forschungsfrage nun zu beantworten, soll die Bachelorarbeit durch eine Kombination von Literaturarbeit und praktischer Umsetzung realisiert werden. Aus bestehender Literatur werden schließlich Richtlinien für das Design von Benutzeroberflächen für LPD Games erarbeitet, welche es letztlich er1

https://www.aec.at/center/ausstellungen/deep-space/

1. Einleitung

möglichen sollen, ein für ein breitgefächertes Publikum leicht verständliches User Interface zu erstellen. Weiters werden bereits existierende Spiele für das Deep Space mithilfe der Richtlinien analysiert.

1.3

Aufbau der Arbeit

Die vorliegende Arbeit besteht aus fünf Kapiteln. Die Einleitung, Kapitel 1, besteht aus der Problemstellung einschließlich der Forschungsfrage, dem Lösungsansatz und dem Aufbau der Arbeit. In Kapitel 2 werden grundlegende Begriffe für diese Bachelorarbeit geklärt und die bestehenden Technologien zu Large Public Display Games und Game Interfaces vorgestellt. In Kapitel 3 sind die eigens erarbeiteten Richtlinien zur Erstellung eines User Interfaces für LPD Games aufgeführt. Diese Richtlinien sind in drei Kategorien aufgeteilt: Bodeninterface, Wandinterface und Allgemein. Anhand dieser Richtlinien wird in Kapitel 4 das User Interface bestehender LPD Games für den Deep Space analysiert und verglichen. Im 5. und letzten Kapitel ist die Arbeit noch einmal zusammengefasst und beinhaltet einen Ausblick auf mögliche Entwicklungen bei LPD Games.

Kapitel 2

State of the Art 2.1

Begriffsklärung

In den folgenden Absätzen werden die Begriffe Large Public Display Games, Tracking und Natural User Interface beschrieben.

2.1.1

Large Public Display Games

Large Public Display Games (LPD Games) sind Spiele, die auf öffentlich zugängliche, große Flächen projiziert werden, wie zum Beispiel im Deep Space: Spielräume. LPD Games sind in den meisten Fällen co-located Games. Co-located bedeutet, dass mehrere Entitäten innerhalb des gleichen physischen Standortes platziert werden. Bei co-located Games bezieht sich dieser Ausdruck darauf, dass mehrere Spieler und Spielerinnen sich denselben physischen Spielraum teilen und gemeinsam durch Interaktionen versuchen, das Spielziel zu erreichen [1]. In co-located multiplayer games, users interact with each other to reach an either common or adversarial goal inside a virtual world by sharing the same location.

2.1.2

Tracking

Allgemein umfasst der Begriff Tracking alle Bearbeitungsschritte, die zur Verfolgung von bewegten Objekten in Echtzeit dienen. Das Ziel von Tracking ist meist, die aufgenommenen Daten abzubilden und die genaue Position von Objekten zu ermitteln [14]. Es gibt verschiedene Möglichkeiten, Bewegungen zu tracken. Die wohl bekannteste ist das GPS-Tracking. Dies ist jedoch nur im Freien möglich und es ist zu ungenau, um es für co-located Games auf kleinen Flächen zu verwenden. Eine weitere Methode ist das Tracking durch optische Kameras, 3

2. State of the Art

welche bei Kinect verwendet werden. Die Trackingmethode, die im Deep Space 8K zum Einsatz kommt, ist das Lasertracking. Beim Tracking in Bezug auf LPD Games mit dem Tracking-System Pharus werden über Sensoren die Bewegungen der Spieler und Spielerinnen eingefangen und so das Spiel gesteuert. In Kapitel 2.2 wird näher auf das Tracking-System Pharus eingegangen, welches im Deep Space 8K verwendet wird.

2.1.3

Natural User Interface

Natural User Interfaces (NUI) haben verschiedene Bedeutungen. In dieser Arbeit versteht sich das Natural User Interface als ein sehr intuitives, für die Spieler und Spielerinnen leicht verständliches Interface. Eine andere Bedeutung für NUI ist die Eingabe von Interaktionen durch alternative Methoden, wie zum Beispiel Tracking von Bewegungen (Körper, Kopf, Eye Tracking), Spracherkennung oder physiologische Konditionen (Herzschlag) [5, S. 96]. Like some other interface terminology, the term natural user interface (NUI) is not used consistently. Some use it to mean simply any interface that immediately, or at least quickly, becomes highly intuitive for the player. Others consider NUI to be an evolution of user interface beyond GUIs—such as control schemes that involve tracking of body, head, and eye movements, reading brainwaves or other physiological conditions (e.g., heart rate), or speech recognition.

2.2

Large Public Display Games und Tracking

Nachfolgend wird der Deep Space 8K vorgestellt und das LasertrackingSystem Pharus näher erklärt.

2.2.1

Deep Space 8K

Der Deep Space 8K ist eine Einrichtung im Ars Electronica Center und besteht aus Wand- und Bodenprojektion zu je 16 × 9 Meter Größe sowie einem Personen-Tracking am Boden. Die jeweils 4 Projektoren für Wand und Boden besitzen eine Auflösung von 4K und erreichen somit zusammen bis zu 8K [13]. Der genaue Aufbau des Deep Space 8K ist in Abbildung 2.1 zu sehen. Der Deep Space 8K ist für Besucher des Ars Electronica Centers frei zugänglich und beinhaltet verschiedenste Ausstellungen, wie zum Beispiel Deep Space: Universum Mensch, Deep Space: Kulturelles Erbe oder Deep

2. State of the Art

Abbildung 2.1: Aufbau des Deep Space 8K [13].

Space: Spielräume 1 . Bei Deep Space: Spielräume werden Computerspiele, die speziell für den Deep Space 8K kreiert worden sind, ausgestellt. Dazu gehören die Game Changer Suite 2 mit fünf Multiplayer-Minispielen, Limelight 3 und Lazor Lab4 .

2.2.2

Lasertracking-System „Pharus“

Pharus ist ein Tracking-System, entwickelt von Otto Naderer, das aus sechs Lasersensoren, die auf Knöchelhöhe am Rand der Bodenprojektion angebracht sind, besteht. Diese erfassen die Positionen der sich im Raum bewegenden Personen. Da dieses Tracking gleichzeitig die Daten auswertet und die Bewegungen erfassen kann, ist es möglich, bis zu 30 Personen gleichzeitig zu tracken [4].

2.3

Arten von Interfaces

In diesem Abschnitt werden die zwei verschiedenen Projektionen im Deep Space 8K aufgezeigt: die Bodenprojektion und die Wandprojektion. Weiters wird erklärt, was ein Player View ist und wie ein zweidimensionaler Player View aussieht. 1

https://www.aec.at/center/ausstellungen/deep-space/ http://pie.fh-hagenberg.at/projects/game-changer/ 3 http://pie.fh-hagenberg.at/projects/limelight/ 4 http://lazorlab.rohschinken.at/ 2

2. State of the Art

2.3.1

Bodenprojektion

Bei der Bodenprojektion handelt es sich um die Abbildung des Spiels am Boden durch die Projektion von Beamern, die an der Decke befestigt sind. Die Projektion auf dem Boden steht für die aktiven Spieler und Spielerinnen im Vordergrund. Sie können unter sich ihren Avatar und ihre ausgeführten Aktionen besser mitverfolgen als auf der Wandprojektion. Außerdem können die Spieler und Spielerinnen ihre Mitspieler und Mitspielerinnen besser im Auge behalten, um etwaige Kollisionen zu vermeiden.

2.3.2

Wandprojektion

Die Wandprojektion ist eine senkrechte Projektion auf die Wand mittels Projektor. Die Projektion eines LPD Games auf die Wand ist besonders für die Zuseher und Zuseherinnen von Bedeutung. Sie können dadurch das Geschehen im Spiel besser mitverfolgen. Weiters ist sie auch wichtig für die aktiven Spieler und Spielerinnen, da sie so den Überblick über den Spielverlauf behalten.

2.3.3

Player View

Unter Player View versteht man die Ausrichtung der In-Game-Kamera. Verschiedene Player Views sind zweidimensional, isometrisch, first-person und third-person [5, S. 69]. Player view refers to a game’s camera and basic control scheme. Choice of view is one of the most important interface-related decisions, since it defines many elements of gameplay. It is also one of the first descriptors used to identify the game type or genre. View options include two-dimensional, isometric, first-person, and third-person. Hybrid views are also possible. Bei LPD Games wird meist eine zweidimensionale Kamera gewählt, da es sich vor allem um co-located Multiplayergames handelt. Zweidimensionaler Player View Bei einer zweidimensionalen Kameraeinstellung unterscheidet man zwischen top-down und side view. Wie in Abbildung 2.2 zu sehen ist, initiiert die top-down Ansicht, dass die In-Game-Kamera von oben auf das Spiel herab schaut. Beim Side View ist die Kamera seitlich auf das Spielgeschehen gerichtet [5].

2. State of the Art

(a)

(b)

Abbildung 2.2: Zweidimensionaler Player View: Eine Variante der Top Down Ansicht (a) kann sein, dass die Kamera leicht schrĂ¤g von oben ausgerichtet ist. Der klassische Side View (b), wie er bei Super Mario Bros. Spielen eingesetzt wird, zeigt die Spielfigur und die Spielwelt von der Seite [6, 7].

Kapitel 3

Richtlinien für Benutzeroberflächen von co-located LPD Games Die folgenden Richtlinien sollen als Anhaltspunkte für User Interface Designer dienen, die Benutzeroberflächen für co-located Large Public Display Games (im speziellen für den Deep Space 8K ) entwickeln. Diese Richtlinien zeigen Probleme auf, die auftreten können und beschreiben Lösungswege, um diese Probleme zu umgehen oder zu verhindern.

3.1

Bodeninterface

Wie bereits erwähnt, steht das Bodeninterface besonders für die Spieler und Spielerinnen im Vordergrund. Daher ist es wichtig, die Benutzeroberfläche so zu gestalten, dass der Spielfluss nicht behindert wird. Hier sind vor allem die Schattenbildung (Occlusion) und Probleme mit dem Tracking-System zu beachten.

3.1.1

Schattenbildung

Bei dem Bodeninterface ist zu berücksichtigen, dass die Projektoren von der Decke des Raumes auf den Boden gerichtet sind. Dadurch entstehen Schatten unter den aktiven Akteuren und Akteurinnen, wie in Abbildung 3.1 zu sehen ist. Um zu verhindern, dass diese Schatten den Spielfluss beeinflussen, ist es wichtig, die interaktiven Interface-Bestandteile so groß zu gestalten, dass sie trotz der Schattenbildung gut zu erkennen sind. Zu den interaktiven Interface-Bestandteilen gehören unter anderem Avatare, die von den Spielern und Spielerinnen gesteuert werden oder Aktionsfelder mit denen die Teilnehmer und Teilnehmerinnen interagieren können.

3. Richtlinien für Benutzeroberflächen von co-located LPD Games

Abbildung 3.1: Die Schattenbildung unter den Spielern und Spielerinnen müssen bei der Erstellung der Avatare und Aktionsfelder berücksichtigt werden.

3.1.2

Trackingprobleme

Die Eingabe der Interaktionen mit dem Spiel durch Tracking birgt einige Probleme, die bei der Erstellung des Bodeninterfaces zu beachten sind. Spieler speichern Die einzelnen Spieler und Spielerinnen können nicht gespeichert werden. Das bedeutet: Wenn ein Akteur oder eine Akteurin die Spielfläche verlässt, wird er oder sie nicht mehr vom Tracking erkannt. Wenn der Spieler oder die Spielerin die Spielfläche wieder betritt, wird ihnen eine neue Spieler-ID zugewiesen. Somit ist es für das Spiel so, als wäre sie eine neue Person auf dem Spielfeld. Eine Lösung für dieses Problem gibt es für das Tracking-System Pharus nicht. Es kann lediglich verhindert werden, dass Spieler und Spielerinnen das Spielfeld unabsichtlich verlassen, indem man keine Aktionsfelder am Rand der Spielfläche platziert. Spieler verschmelzen Wenn sich zwei Spieler oder Spielerinnen physisch zu nahe kommen, passiert es, dass ihre zwei Avatare zu einem werden und somit einer der beiden vom Tracking nicht mehr als eigenständige Person gesehen wird. Dieses Problem kann verhindert werden, indem die Avatare groß genug gestaltet sind, sodass sich zwei Spieler oder Spielerinnen nicht zu nahe kommen. Weiters sollten Aktionsfelder ausreichend Platz bieten, damit sich mindestens eine weitere Person diesem Feld nähern kann, ohne „verschlungen“zu werden.

3. Richtlinien für Benutzeroberflächen von co-located LPD Games

Eingeschränkte Interaktionsmöglichkeit Im Deep Space 8K werden durch das Tracking die Positionen der Spieler und Spielerinnen erkannt. Durch diese Eingabemethode sind die Spielenden in ihrer Interaktion mit dem Spiel, gegenüber der Eingabe mit Keyboard und Mouse, Controller, Gesten, oder Sprachsteuerung, wesentlich eingeschränkt. Die Spieler und Spielerinnen haben zum Beispiel nicht die Möglichkeit, über Action-Buttons mit dem Spiel zu interagieren, ihnen steht lediglich die Bewegung im Raum zur Verfügung. Toter Winkel der Sensoren Wenn sich mehr als 30 Spieler und Spielerinnen gleichzeitig auf dem Spielfeld des Deep Space 8K befinden, kann es vorkommen, dass ein Spieler oder eine Spielerin vom Tracking-System nicht mehr erkannt wird, da er oder sie genau von den Mitspielern und Mitspielerinnen verdeckt wird [4]. The evaluation of motion properties of a crowd calls for elaborate means to trace the trajectory of an individual over the course of his presence. The apparent challenge for such a system is the crowded environment and hence an expectable congestion which leads to frequent occlusions and blind spots. Dieses Problem kann durch eine maximale Spieleranzahl gelöst werden.

3.2

Wandinterface

Das Wandinterface stellt sicher, dass die Zuseher und Zuseherinnen den Überblick über das Spielgeschehen behalten können und sich auch die aktiv Spielenden schnell wiederfinden. Das Boden- und Wandinterface für den Deep Space 8K können voneinander abweichend gestaltet werden.

3.2.1

Kontrast

Um das Spielgeschehen gut mitverfolgen zu können, ist es wichtig, wesentliche Dinge von unwesentlichen klar abzugrenzen. Durch einen hohen Kontrast zwischen Hintergrund und aktivem Spielgeschehen kann man die wichtigen Bereiche gut hervorheben. Durch verschiedene Kontraste können auch unterschiedliche Stimmungen erzeugt werden. Mehr über Kontraste findet sich in [3].

3.2.2

Orientierung

Damit sich nicht nur die Zuseher und Zuseherinnen auf der Wandprojektion zurecht finden, sondern auch die Spielenden, ist es wichtig, die Positionen

3. Richtlinien für Benutzeroberflächen von co-located LPD Games

Abbildung 3.2: Durch verschiedenfarbige Avatare wird die eigene Position schneller und leichter erkennbar.

der einzelnen Spieler und Spielerinnen klar zu definieren. Das kann durch voneinander unterscheidbare Avatare realisiert werden. Diese können durch unterschiedliche Farbgebung (Abbildung 3.2) oder durch eine andere Gestalt erkenntlich gemacht werden. Möchte man den Avataren verschiedene Gestalten geben, sollte man beachten, dass die Avatare mit der gleichen Funktion als eine Gruppe erkenntlich sein sollen. Um die eigene Position auf der Wandprojektion erkennen zu können, ist es auch wichtig, das Screendesign schlicht, nicht zu überladen, zu gestalten. Das gilt vor allem für den Hintergrund, der nicht vom Spielziel ablenken soll, sondern lediglich dazu dient, es gestalterisch zu unterstützen. Auch im Vordergrund sollten jedoch nicht zu viele Interaktionsfelder zugleich zu sehen sein.

3.2.3

Position von Spielelementen

Bei der Positionierung der interaktiven Spielelemente für Spiele im Deep Space 8K ist zu beachten, dass diese nicht zu nahe zum Boden oder zur Decke platziert werden. Ist ein Objekt zu nah zum Boden platziert (circa 1,5 bis 2 Meter), können die passiven Teilnehmer und Teilnehmerinnen diese hinter der aktiven Spielgruppe nicht mehr erkennen und verpassen dadurch eventuell Aktionen, welche die Spieler und Spielerinnen getätigt haben. Sind Elemente zu nah an der Decke platziert, wird es für Spieler und Spielerinnen, die nahe zum Wandinterface stehen, sehr unangenehm diese zu betrachten. In Abbildung 3.3 ist zu sehen, in welchen Teilen der Benutzeroberfläche sich möglichst keine interaktiven Flächen befinden sollten. Diese Bereiche variieren je nach Größe der Projektion.

3. Richtlinien für Benutzeroberflächen von co-located LPD Games

Abbildung 3.3: In den rot markierten Bereichen sollten keine Aktionsfelder platziert werden. In diesem Beispiel sind jeweils 1,5 Meter Höhe vom Rand gekennzeichnet bei einer Höhe von insgesamt 9 Metern.

3.2.4

Zusätzliche Informationen

Das Wandinterface bietet Platz, um zusätzliche Informationen für die Zuseher und Zuseherinnen aufzubereiten. So kann zum Beispiel ein Spielstand angegeben werden, um die passiven Teilnehmer und Teilnehmerinnen auf dem Laufenden zu halten. Außerdem können speziell für die Zuseher und Zuseherinnen vorgesehene Inhalte gezeigt werden, um ihre Aufmerksamkeit bei dem Spiel zu halten. Solche Inhalte können Aktionen sein, bei denen die Zusehenden aktiv am Spiel teilnehmen. Zum Beispiel kann man ihnen die Möglichkeit geben, über ein Mobile Device eine Aktion im Spiel auszulösen. Über die Anzeige können die Teilnehmer sehen, ob ihre Aktion erfolgreich gesendet wurde. Als weitere nützliche Information für die Zuseher und Zuseherinnen kann angezeigt werden, wie viele Aktive auf dem Spielfeld sind oder ob man als passiver Teilnehmer oder passive Teilnehmerin im Moment ins Spiel einsteigen kann.

3.3

Allgemein

Für Benutzeroberflächen bei LPD Games gibt es noch zusätzliche Aspekte, die zu beachten sind, abgesehen von den Punkten bei Boden- und Wandinterface. Ganz allgemein sollten Benutzeroberflächen für LPD Games einem Natural User Interface entsprechen. Die Spieler und Spielerinnen müssen sich sofort im Spiel zurecht finden, da sie normalerweise den Raum betreten und umgehend zu Spielen beginnen.

3. Richtlinien für Benutzeroberflächen von co-located LPD Games

Abbildung 3.4: Top-Down Ansicht bei Game Changer Suite - Swarm Defender.

3.3.1

Player View

Da die meisten Spiele für Large Public Displays für mehrere Spieler und Spielerinnen ausgelegt sind, bietet sich eine zweidimensionale Kamera an mit Side View oder Top-Down. Diese Kameraeinstellungen unterstützen ein Natural User Interface, da die aktiven Spieler und Spielerinnen ihren genauen Standort im Spiel erkennen können, ohne sich durch perspektivische Verzerrungen erst zurechtfinden zu müssen. Außerdem ermöglichen es diese Kameraeinstellungen, dass mehrere Avatare gleichzeitig auf demselben Interface gesteuert werden können [5, S. 156]. Bei einem Multiplayergame ohne Split-Screen und eingeschränkten Eingabemöglichkeiten ist es fast unmöglich eine First-Person Ansicht zu verwenden. Dieser Player View würde zusätzlich die Spielmechanik komplizieren, da extra Eingabefelder erstellt werden müssten. Er ist somit ungeeignet für LPD Games. Als Alternative zu Side View und Top-Down kann man mit der isometrischen Ansicht arbeiten, die jedoch perspektivische Verzerrungen beinhaltet und so die klare Ansicht erschwert. Weiters ist zu beachten, dass sich die Spielelemente der Perspektive anpassen müssen und die Flächen der interaktiven Elemente je nach Position größer oder kleiner werden. Hier würde man wieder auf das Problem von Abschnitt 3.1.2 stoßen.

3.3.2

Sprache

Bei LPD Games sollte man geschriebene oder gesprochene Sprache möglichst vermeiden. Da die Spieler und Spielerinnen unterschiedlicher Herkunft sein können und so meist nicht dieselbe Sprache sprechen, kann es hier zu Problemen führen, wenn das Spiel in einer bestimmten Sprache erklärt wird. Weiters sind diese Spiele auch für Menschen, die nicht lesen können, wie

3. Richtlinien für Benutzeroberflächen von co-located LPD Games

Abbildung 3.5: Piktogramme zum Thema Spielen.

zum Beispiel kleine Kinder, zugänglich.

3.3.3

Piktogramme und Icons

Um Text in einer bestimmten Sprache zu vermeiden, bietet es sich an, Piktogramme und Icons zu verwenden. Da für Kinder Abstraktionen noch nicht so verständlich sind wie für Erwachsene, sollten keine komplexen Symbole verwendet werden [5, S. 52]. Most children under six are unable to understand abstractions. Therefore, interfaces for these children should avoid the use of complex symbols. Weiters sollte beachtet werden, dass die Symbole unabhängig von der Herkunft der Spieler und Spielerinnen und somit international zu verstehen sind. Die Icons und Piktogramme sollen ohne Schrift funktionieren (Abbildung 3.5) und ein einheitliches Design aufweisen, um die Bedeutung für diese Zeichen leicht verständlich zu halten [8].

3.3.4

Audio

Die Komponente Audio ist ein wichtiger Bestandteil von User Interfaces. Durch sie können grafische Elemente unterstrichen und erweitern werden. Zum Beispiel kann eine Aktion, die ein Zeitlimit hat, durch Warngeräusche hervorgehoben werden [5, S. 46]. Audio is an important tool in interface design. Clever use of sound and music can greatly enhance a player’s enjoyment of a game and improve feedback. Bei LPD Games ist zu beachten, dass viele Spieler und Spielerinnen gleichzeitig Aktionen ausführen. Hier ist es wichtig, nicht zu viele Sounds

3. Richtlinien für Benutzeroberflächen von co-located LPD Games

zur selben Zeit abzuspielen. Die Geräusche müssen zu den Aktionen, die sie auslösen, klar zuordenbar sein. Werden zu viele Sounds simultan abgespielt, können die Beteiligten nicht mehr feststellen, zu welcher Quelle die Geräusche gehören. Dadurch kann es passieren, dass die Spieler und Spielerinnen Aktionen übersehen und die Spielrunde verlieren. Wenn die Sounds verschiedener Interaktionen zu ähnlich klingen, können auch hier die Teilnehmer und Teilnehmerinnen nicht mehr unterscheiden, welche Geräusche wodurch ausgelöst wurden.

Kapitel 4

Analyse bestehender LPD Games In diesem Kapitel werden die Benutzeroberflächen verschiedener Spiele, die für den Deep Space 8K entwickelt wurden, anhand der erarbeiteten Richtlinien analysiert. Bei dieser Analyse wird auf die grafischen Punkte eingegangen, die Audio-Analyse in Bezug auf das Interface würde den Rahmen dieser Arbeit übersteigen.

4.1

Game Changer Suite

Die Game Changer Suite ist eine Kollektion von Prototypen von MultiplayerMinispielen. Die fünf Spiele nutzen verschiedene Spielmechaniken und bieten so eine abwechslungsreiche Unterhaltung. Im Mittelpunkt des Game Changer-Projektes steht das kooperative und wettbewerbsfähige Gameplay in einer co-located Umgebung. Spieler können zwischen einem der fünf SpielPrototypen wählen, indem sie einfach auf dem gewünschten Spielfenster stehen. Auf diese Weise ist die Spielauswahl ein kollektiver, demokratischer Prozess [9]. Die Game Changer Suite wurde von Studenten der Fachhochschule Oberösterreich Campus Hagenberg entwickelt. Das Team besteht aus Jeremiah Diephuis (Projektleiter), Andreas Friedl, Georgi Kostov, Poorya Piroozan und Daniel Wilfinger. Game Changer Suite wurde auf dem Ars Electronica Festival 2014 in Linz ausgestellt [9]. Die verschiedenen Spiele sind [11]: Game Selection: Die Game Selection wurde von Andreas Friedl produziert. Bei der Spielauswahl stellen sich die Spieler und Spielerinnen auf ein Spiel-Fenster ihrer Wahl. Wenn der Timer abgelaufen ist, wird das Spiel mit den meisten Votes gestartet. Ist das Spiel zu Ende, wechselt die Applikation automatisch auf die Game Selection zurück. 16

4. Analyse bestehender LPD Games

Beelzeball: Beelzeball verbindet Sportarten wie Fußball oder Squash mit Spielelementen klassischer Spiele, wie Arkanoid und Snake. Bei diesem Spiel kämpft jedoch jeder Spieler und jede Spielerin für sich. Ist der Ball im Spiel, müssen die Spieler und Spielerinnen mit ihrem schlangenartigen Schweif versuchen, den Ball in Richtung Blöcke umzulenken. Der Ball bekommt die Farbe des Spielers oder der Spielerin, die ihn zuletzt Berührt hat. Berührt der Ball einen Block, bekommt der jeweilige Spieler oder die Spielerin einen Punkt. In diesem Spiel gibt es zusätzlich Power-Ups, die den Schweif permanent verlängern oder die es den Spielern und Spielerinnen erlauben, den Ball kurz festzuhalten und anschließend in eine Richtung abzuwerfen. Eine Spielrunde bei Beelzeball dauert 90 Sekunden. Dieses Spiel wurde von Poorya Piroozan produziert. Fish Feast: Fish Feast wurde von Andreas Friedl produziert. Bei Fish Feast ist jeder Spieler und jede Spielerin zu Beginn ein kleiner Fisch. Durch das Fressen der computergesteuerten Fische wächst der eigene Fisch. Der größte Fisch wird dann mit einer Krone ausgezeichnet und kann nun zusätzlich die Fische der Mitspieler und Mitspielerinnen fressen. Die gefressenen Spieler scheiden aus. Manchmal durchquert ein elektrischer Aal das Spielfeld und die Fische, die getroffen werden verlieren an Größe. Gewonnen hat der Spieler oder die Spielerin, der / die bei Ablauf der Zeit die Krone trägt. Fluridus 293: Fluridus 293 ist ein kooperatives Spiel in einer scheinbar friedlichen Weltraumumgebung. Anfangs entscheiden sich die Spieler und Spielerinnen für ein Mutterschiff (das Team). Danach müssen so viele Asteroidenfelder wie möglich eingenommen werden, um die Energie des Mutterschiffs aufzuladen. Damit ein Asteroidenfeld eingenommen wird, müssen sich die Spieler und Spielerinnen auf dem ständig bewegten Feld befinden. Je mehr Spieler und Spielerinnen desselben Teams sich auf dem gleichen Feld befinden, desto schneller wird es eingenommen. Das andere Team kann das verzögern, verhindern oder sogar bereits eingenommene Felder zurückerobern. Die Teams überleben nur, wenn der Energiespeicher innerhalb von zwei Minuten komplett befüllt wurde. Ansonsten wird das Mutterschiff in das schwarze Loch in der Mitte des Spielfeldes gezogen. Dieses Spiel wurde von Daniel Wilfinger produziert. Swarm Defender: Swarm Defender erinnert sehr stark an den Spieleklassiker Space Invaders. Jedoch kann bei Swarm Defender der Planet nicht von einem einzelnen Helden oder einer Heldin gerettet werden. Die Spieler und Spielerinnen müssen als Team interagieren und so die Gegner zur Strecke bringen. Die Eindringlinge können nur durch einen Laserstrahl getötet werden, der die gleiche Farbe wie ihr Körper hat. Ein einzelnes SpielerRaumschiff schießt einen grünen Strahl. Schließen sich zwei Spieler oder

4. Analyse bestehender LPD Games

Abbildung 4.1: Game Changer Game Selection Screen.

Spielerinnen zusammen, feuern sie einen blauen Strahl ab und bei drei Spielern oder Spielerinnen einen roten. Schaffen es die Spieler und Spielerinnen alle Gegner abzuwehren, haben sie gewonnen. Swarm Defender wurde von Adreas Friedl realisiert. Tower of Power: Tower of Power wurde von Georgi Kostov produziert. Dieses Spiel ist von den Spieleklassikern Bomberman und Tetris inspiriert und reinterpretiert die Spielmechanik in einem teambasierten Wettkampf. Die Spieler und Spielerinnen wählen ihr Team, indem sie am Anfang über eine der Basen (rot oder blau) laufen. Anschließend können sie Tetris-artige Blöcke aufsammeln und zu ihrer Basis bringen. Mit diesen Blöcken versuchen sie, so schnell wie möglich einen Turm zu bauen, der bis zu Mitte des Spielfeldes ragt. Jedoch tauchen von Zeit zu Zeit Bomben auf, die die Gegner und Gegnerinnen verwenden können, um den Turm zu zerstören. Das Team, das als erstes 100 Prozent der verfügbaren Energie aus der Mitte des Spielfeldes sammelt, gewinnt.

4.1.1

Analyse Game Changer Suite

Hier werden die User Interfaces der Spiele der Game Changer Suite analysiert. Bei diesen Spielen kann das Publikum jederzeit einsteigen. Sind jedoch zu viele Personen gleichzeitig im Spiel, können manche vom Tracking übersehen werden und verlieren ihren Avatar. Bei allen fünf Minispielen verfügen die Boden- und Wandinterface über dieselbe Projektion. Das bedeutet, es gibt keine unterschiedlichen Boden- und Wandinterfaces und keine zusätzlichen Informationen speziell für die Zuseher und Zuseherinnen. Des Weiteren verwenden und benötigen sie keine gesprochene oder geschriebene Sprache, um die Spielabläufe zu erklären. Game Selection: Die Game Selection, die in Abbildung 4.1 zu sehen ist, ist sehr übersichtlich und intuitiv aufbereitet. Die Spieler und Spielerinnen

4. Analyse bestehender LPD Games

Abbildung 4.2: Beelzeball Interface.

haben genug Platz, um sich auf das Feld zu begeben, auf dem sie stehen wollen, ohne mit einem Mitspieler oder einer Mitspielerin zu verschmelzen. Da das Boden- und Wandinterface miteinander übereinstimmen, ist die Zeitanzeige auch gut zu sehen, wenn sich viele Spieler und Spielerinnen auf dem Feld befinden. Die unterschiedlichen Spiele sind deutlich voneinander zu unterscheiden und machen es den Spielern und Spielerinnen leicht, ihre Auswahl zu treffen. Es wurde nur sehr sparsam Text verwendet, was den Einstieg in die Spiele leicht gestaltet. Beelzeball: Bei Beelzeball (Abbildung 4.2) gibt es kein Problem durch Schattenbildung, da der Hintergrund schwarz ist und die interaktiven Elemente lang genug sind, um nicht von Schatten verdeckt zu werden. Da die Interaktion vor allem in der Mitte des Spielfelds stattfindet, kommt es kaum zu dem Problem, dass die Spieler und Spielerinnen unabsichtlich die Fläche verlassen und so ihren Avatar verlieren. Bei diesem Spiel wird zu Beginn der Spielrunde jedem Spieler und jeder Spielerin eine eigene Farbe zugewiesen. So können alle Beteiligten ihren eigenen Avatar gut erkennen. Da letztere jedoch aus relativ kleinen Kreise bestehen und die Teilnehmer und Teilnehmerinnen oft sehr nahe zusammen stehen, passiert es, dass die Spieler oder Spielerinnen von den Mitspielenden „verschluckt“werden. Die Spieler und Spielerinnen müssen versuchen, durch ihren Schweif den Ball gegen Hindernisse zu schlagen. Da die Avatare nur der Position der Spieler und Spielerinnen folgen und nicht zusätzlich gelenkt werden können, ist es für die Teilnehmer und Teilnehmerinnen eine Herausforderung, das zu schaffen. Beelzeball hat einen sehr guten hell-dunkel-Kontrast zwischen Hintergrund und interaktiven Spielelementen. Allerdings sieht der Ball, durch den die Punkte erzielt werden, den Avataren sehr ähnlich, ist sehr klein und kann somit leicht übersehen werden. Wie schon erwähnt, findet die meiste

4. Analyse bestehender LPD Games

Abbildung 4.3: Die Fische folgen den Spielern und Spielerinnen zeitverzögert. Das kann zu Verwirrungen auf dem Spielfeld kommen.

Interaktion in der Mitte des Spielfeldes statt. Somit können die Zuseher und Zuseherinnen gut das Geschehen verfolgen und verpassen keine Aktionen. Der Art-Style von Beelzeball ist sehr abstrahiert und besteht lediglich aus kleinen Kreisen, die zu Formen zusammengesetzt wurden. Durch die starke Abstraktion ist es schwierig für manche Spieler und Spielerinnen, insbesondere für Kinder, das Spielziel ohne Erklärung zu verstehen. Bei Beelzeball wird ein komplett zweidimensionaler Top-Down Player View eingesetzt, wodurch sich die Spieler und Spielerinnen gut auf dem Spielfeld orientieren können. Fish Feast: Bei Fish Feast stellt die Schattenbildung kein Problem dar, da die Avatare durch die Geschwindigkeit der Spieler und Spielerinnen verzögert ihren Bewegungen folgen (Abbildung 4.3). Das wiederum verursacht das Problem, dass die Spieler und Spielerinnen öfter nicht mehr wissen, welcher Fisch zu ihnen gehört, trotz der Farbzuweisung der Fische. Dies kann soweit gehen, dass die Fische schon längst tot sind, bis die Spieler und Spielerinnen merken, welcher Fisch zu ihnen gehört hat. Da das Spielprinzip von Fish Feast wie Fangen-Spielen ist, passiert es öfter, dass die Spieler und Spielerinnen vom Feld laufen. Sie können danach zwar wieder einsteigen, fangen aber wieder als kleiner Fisch an. Zu Beginn der Spielrunden, wenn die Fische klein sind, kommt es öfter zur Verschmelzung der Spieler und Spielerinnen, da diese zu nahe zusammen laufen. Durch das Spielprinzip gibt es hier keine Einschränkungen bei Interaktionen, denn die Spielenden müssen sich nur gegenseitig mit ihren Avataren treffen, egal aus welcher Richtung. In Fish Feast gibt es keine fest platzierten Elemente. Hier hängt es allein von den Spielern und Spielerinnen ab, ob die Zusehenden alles mitbekommen. Das Interface von Fish Feast an sich ist sehr übersichtlich, da sich der Vordergrund durch die bunten Fische von dem blauen Hintergrund abhebt. Eine wahrscheinlich gewollte Schwierigkeit stellt der Aal dar, der die Fische schrumpfen lässt, weil dieser blau ist und so leicht übersehen wird. Der

4. Analyse bestehender LPD Games

Abbildung 4.4: Fluridus 293 Interface.

Unterwasser-Side View erinnert an ein Aquarium und macht es den Spielenden ein bisschen leichter, sich in die Situation eines Fisches zu versetzen. Die Fisch-Piktogramme werden sogar schon von Kindern verstanden. Das Interface von Fish Feast kann als Natural User Interface betrachtet werden. Fluridus 293: Bei Fluridus 293 sind die Avatare sehr klein gestaltet und verschwinden so fast vollständig auf dem Bodeninterface, durch die Schattenbildung. Dass Spieler oder Spielerinnen ihren Avatar verlieren, passiert bei Fluridus 293 nur durch Verschmelzung, weil sie zu nahe zusammen gestanden sind. Hier ist es sehr unwahrscheinlich, dass ein Spieler oder eine Spielerin unabsichtlich vom Feld läuft. Die Spielmechanik funktioniert gut mit der Eingabe durch Tracking, ohne zusätzliche Hilfsmittel. Der rot-blau-Kontrast zwischen Hintergrund und interaktiven Spielelementen zeigt deutlich, mit welchen Objekten interagiert werden kann. Durch das Gitter im Hintergrund können die Spieler und Spielerinnen ihre Positionen gut erkennen. Die Mutterschiffe sind ein wenig über der Mitte des Spielfeldes platziert und somit gut erkennbar für Zuseher und Zuseherinnen sowie für die Spielenden. Wenn ein Spieler oder eine Spielerin ein Asteroidenfeld eingenommen hat, bewegt sich dieses in Richtung des Mutterschiffs. Die am Spiel Beteiligten bekommen kein zusätzliches Feedback, wie zum Beispiel eine Farbkennzeichnung der Teamfarbe. Das Spielziel von Fluridus 293 ist für neue Spieler und Spielerinnen meist nicht sofort erkenntlich, da dieses Spiel generell sehr wenig Feedback gibt. Durch die Top-Down Ansicht bleibt das Spielfeld überdies sehr übersichtlich. Die Piktogramme der Avatare sind keinem speziellen Ding zuordenbar und erschweren so das Verständnis für das Spiel. Swarm Defender: Die Schattenbildung ist bei diesem Spiel kein Problem, da die Avatare leicht vor den Spielenden versetzt sind und der Hintergrund schwarz ist. Bei Swarm Defender müssen die Spielenden oft nahe zusammen stehen, um die Gegner abzuwehren, wie in Abbildung 4.5 zu sehen ist. Hier gibt es kein Problem mit der Verschmelzung, weil die Avatare groß genug

4. Analyse bestehender LPD Games

Abbildung 4.5: Swarm Defender Interface.

sind. Manchmal stehen die Spielenden plötzlich außerhalb des Spielfelds, da sie vor den Gegnern zurück weichen. Das ist bei diesem Spiel allerdings kein Problem, weil der Spieler oder die Spielerin einfach ohne Nachteile wieder einsteigen kann. Durch die eingeschränkte Eingabemöglichkeit müssen die Raumschiffe von selbst schießen, weitere Einschränkungen gibt es aber dadurch nicht. Durch das Weltraumszenario ist ein guter Kontrast zwischen dem schwarzem Hintergrund und den bunten Raumschiffen im Vordergrund gegeben. Jeder Spieler und jede Spielerin hat eine eigene Farbe für seinen oder ihren Avatar. Dadurch können die Spielenden von allen Beteiligten gut erkannt werden. Allerdings können Zuseher und Zuseherinnen, wenn viele Personen spielen, nicht mehr viel auf dem Wandinterface erkennen, da sich das meiste auf der unteren Hälfte der Projektion abspielt. Da die Raumschiffe automatisch schießen, merkt man schnell, dass man unterschiedliche Strahlen abfeuern kann, je nachdem wie viele Spieler und Spielerinnen zusammen stehen. Außerdem bekommen die Raumschiffe, die zusammengeschlossen sind, einen Verbindungsstrahl. So bekommen die Spieler und Spielerinnen ein zusätzliches Feedback darüber, ob sie nun miteinander verbunden sind. Die Top-Down Ansicht mit einem kleinen Ausschnitt der Erde unterstützt zusätzlich das Spielgefühl und die Piktogramme im Space Invaders Style machen die Spielweise noch deutlicher. Dies gilt jedoch vor allem für Personen, die das Spiel Space Invaders kennen, für Kinder ist keineswegs selbsterklärend. Tower of Power: Bei Tower of Power haben die Spieler und Spielerinnen keinen eigenen Avatar. Dadurch gibt es keine Probleme mit der Schattenbildung, dem Verschmelzen der Avatare oder damit, dass Spieler und Spielerinnen verloren gehen. Wenn zwei oder mehr Spielende den gleichen Block aufsammeln wollen, ist jedoch nicht sofort klar, wer diesen Block zugewiesen bekommen hat. Der Kontrast zwischen dem Hintergrund und den zwei Teams ist durch

4. Analyse bestehender LPD Games

Abbildung 4.6: Tower of Power Interface.

die Farbgebung klar zu erkennen, wie in Abbildung 4.6 zu sehen ist. Die Prozentanzeige und die interaktiven Elemente sind durch die klare Aufteilung und Positionierung überall im Raum gut zu sehen. Die Spieler und Spielerinnen werden nur durch die Tetris-artigen Blöcke oder die Bomben, die sie aufsammeln, visualisiert. Durch den zweidimensionalen Player View können sich die Spieler und Spielerinnen gut im Raum zurecht finden. Die Darstellung der Bomben und der Tetris-artigen Blöcke unterstützen ein sehr intuitives Interface und somit ist das Spielziel schnell zu verstehen.

4.2

Limelight

Limelight ist ein 2D-Platformer-Spiel, konzipiert für eine Umgebung wie im Deep Space 8K. Dieses Spiel ist für 1 bis 10 Spieler und Spielerinnen ausgelegt [10]. Die Hauptfigur ist Limus, ein Zauberlehrling. Er muss drei Zaubersteine in einem dunklen Keller finden, um die bösen SMorcS zu besiegen. Während ein Spieler oder eine Spielerin Limus mit einem Gamepad kontrolliert, können andere Spielende seine Suche nach den Steinen unterstützen oder behindern. Die Spieler und Spielerinnen werden von dem Laser-Tracking gescannt und die sogenannten Lumees erzeugt. Sie beleuchten den dunklen Keller für Limus. Zuschauer und Zuschauerinnen können auch Textnachrichten oder E-Mails versenden, um SMorcS im Spiel zu erstellen und Limus’ Aufgabe ein wenig schwieriger zu machen [2]. Das Team um Limelight besteht aus Jeremiah Diephuis (Projektleiter), Wolfgang Hochleitner (Projektleiter), Michael Lankes (Projektleiter), Gerald Hauzenberger, René Ksuz, Thomas Peintner, Magdalena Soukup. Limelight wurde 2012 veröffentlicht [10].

4. Analyse bestehender LPD Games

Abbildung 4.7: Das Wandinterface unterscheidet sich von dem Bodeninterface.

4.2.1

Analyse Limelight

Das Wandinterface von Limelight unterscheidet sich wesentlich von dem Bodeninterface, wie in Abbildung 4.7 zu sehen ist. Auf der Wandprojektion sieht man das Spielgeschehen. Auf der Bodenprojektion wird kein besonderes Interface gezeigt, es werden nur die Bewegungen der Lumees-Spieler und Spielerinnen getrackt. Die Spieler und Spielerinnen können nicht direkt unter sich sehen, wo sich ihr Avatar befindet, daher gibt es kein Problem mit Schatten. Durch die großen Lichtkegel, die von den Lumees erzeugt werden, kommen sich die Spielenden nicht zu nahe und verschmelzen oder verschwinden dadurch nicht. Durch die Kombination von Gamepad und Laser-Tracking wurden die Aufgaben so aufgeteilt, dass die Lumees-Spieler und -Spielerinnen nur die Eingabe durch Tracking nutzen. Limus kann durch die Eingabe mittels Gamepad gesteuert werden und hat so alle Möglichkeiten eines 2D-Platformers. Der tote Winkel der Laser-Sensoren ist bei diesem Spiel kein Thema, da es eine maximale Spieleranzahl von 10 Personen gibt. Trotz der generellen Schatten-Licht-Thematik ist gut zu erkennen, welche Elemente zur Spielfläche gehören und welche im Hintergrund sind. Durch die unterschiedlichen Farben der Avatare können sich die aktiven Teilnehmer und Teilnehmerinnen gut zurecht finden, obwohl die Visualisierung am Boden fehlt. Für den Spieler oder die Spielerin von Limus gibt es zusätzliche InterfaceElemente am Rand der Wandprojektion, ebenso wie für die Zuseher und Zuseherinnen, die weitere SMorcS erstellen können, um das Spiel schwieriger zu machen. Limelight ist besonders für die Lumees-Spielenden ein sehr intuitives Spiel. Der 2D-Platformer Spieltyp initiiert einen zweidimensionalen Side View. Die Grafiken der Lumees, SMorcS und jene von Limus können un-

4. Analyse bestehender LPD Games

terstreichen das Thema des Spiels und werden sogar von kleinen Kindern verstanden.

4.3

Lazor Lab

Zusätzlich zum Laser-Tracking werden bei Lazor Lab Smartphones und deren Sensoren verwendet, um Aktionen im Spiel durchzuführen und die Ausrichtung der Avatare zu kontrollieren. Lazor Lab bietet zwei Spielmodi, Lazor Arena und Lazor Lab. Lazor Lab und Lazor Arena wurden von Andreas Friedl und Jeremiah Diephuis koordiniert und hatten ihre Live-Premiere während des Ars Electronica Festivals 2015, da der Deep Space 8K im Ars Electronica Center in Linz die ursprüngliche Umgebung für diese Anwendung war [12]. Bei Lazor Lab wird MoCo Motion verwendet. MoCo Motion ist ein Framework, das Smart Devices (Smartphones, Tablets etc.) in Boden-basierte co-located Spiele zu integriert. Es erweitert die Spieldynamik und das EingabeInterface für Spieler und Spielerinnen. Die größten Vorteile von MoCo Motion sind explizite Benutzereingaben und personalisiertes Feedback. So können Spieler und Spielerinnen Aktionen über verschiedene Eingabemethoden ausführen, über physische und virtuelle Knöpfe oder über das Laser-Tracking. Die Spieler und Spielerinnen bekommen außerdem individuelles Feedback, zum Beispiel über die Smartphone Lautsprecher oder Vibrationen [12]. Lazor Arena: Lazor Arena ist eine kompetitive Kampfarena, in der Spieler und Spielerinnen Energie sammeln und sie auf ihre Gegner freigeben, um Punkte zu erzielen. Sämtliche Spielenden verfügen dabei über einen virtuellen Zeiger, der an die Ausrichtung des Smartphones gebunden ist. Auf diese Weise können die Spieler und Spielerinnen in 360 ° zielen, während sie Laserstrahlen schießen oder sie sich mit ihren Schildern verteidigen. Die Spieler und Spielerinnen bekommen auch eine Rückmeldung vom Smartphone, wenn der Spieler oder die Spielerin von einem Laserstrahl getroffen wird, wenn er oder sie einen Strahl mit dem Schild blockiert oder einen neuen Energieblock sammelt und Ähnliches. Sobald der Timer abläuft, wird eine Punktetabelle angezeigt und der Spieler oder die Spielerin mit den meisten Punkten gewinnt [12]. Lazor Lab: Lazor Lab ist, im Gegensatz zu Lazor Arena, ein kollaboratives Spiel, bei dem Spieler und Spielerinnen ihre Basis vor eingehenden Feinden verteidigen müssen. Feindliche Polygone brechen durch die umgebende Wand und greifen den Kern der Basis an. Die Spieler und Spielerinnen müssen Ressourcen verwalten, die Mauer reparieren und die mächtigen stationären Laserpistolen mit Strom versorgen. Das Spiel hat einen klaren Fokus auf Kommunikation, Kooperation und Ressourcenmanagement. Die

4. Analyse bestehender LPD Games

(a)

(b)

Abbildung 4.8: Lazor Arena (a) und Lazor Lab (b) Wand- und Bodeninterface und Smart Device Interface.

Steuerung bei Lazor Lab ist ähnlich wie die bei Lazor Arena. Allerdings können die Spieler und Spielerinnen Energieblöcke an andere Spieler oder Spielerinnen übergeben. Dies ist manchmal erforderlich, da nur ein Spieler oder eine Spielerin mit drei Energieblöcken von der passenden Farbe eine kaputte Wand reparieren kann. Von Zeit zu Zeit kommt ein Feind, der durch einen Schild geschützt ist, auf das Feld. Dieser Gegner kann nur mit einer der beiden stationären Laserkanonen zerstört werden, die jedoch drei unterschiedliche Energieblöcke benötigt. Die Spieler und Spielerinnen gewinnen das Spiel, wenn sie es schaffen, den Hauptreaktor in der Mitte des Feldes für sechs Minuten zu verteidigen [12].

4.3.1

Analyse Lazor Arena und Lazor Lab

Bei Lazor Arena und Lazor Lab unterscheiden sich Wand- und Bodeninterface nicht voneinander. Die Avatare bei Lazor Lab sind groß genug, um eine Verschmelzung der Spieler und Spielerinnen zu vermeiden und keine Probleme durch Schattenbildung zu bekommen. Durch die Verbindung mit Smart Devices ist es möglich, Spieler und Spielerinnen zu speichern und mehr Interaktionsmöglichkeiten zu nutzen. Die beiden Spiele, die zu der Applikation Lazor Lab gehören, haben den gleichen Art-Style (Abbildung 4.8): ein weißer Hintergrund, von dem sich die bunten Formen im Vordergrund gut abheben. Zu Beginn des Spiels geben die Teilnehmer und Teilnehmerinnen in ihrem Smart Device ein, welcher Avatar zu ihnen gehört. Dadurch merken sich die Spielenden schneller wie ihr Avatar aussieht, was zur besseren Orientierung auf dem Spielfeld beiträgt. Bei Lazor Lab sind die Laserkanonen sehr nah am Rand positioniert, wodurch die Spieler und Spielerinnen unabsichtlich aus dem Feld laufen oder die Zuseher und Zuseherinnen manche Aktionen hinter den Spielenden nicht mehr sehen können. Auf dem Interface wird als zusätzliche Information angegeben, über welche Adresse dem Spiel beigetreten werden kann. Bei Lazor Arena wird zusätzlich angezeigt, welcher Spieler oder welche Spielerin gerade führt. Beide Spiele haben eine Zeitanzeige am oberen Rand der Projektion.

4. Analyse bestehender LPD Games

Abbildung 4.9: Woolpy Interface.

Der Player View ist bei beiden Spielen eine Top-Down Ansicht. Bei dieser Applikation wird Sprache vor allem auf den Smart Devices eingesetzt, um die Aktions-Knöpfe zu definieren. Durch die sehr abstrahierten Formen auf dem Spielfeld ist das Spielziel nicht immer sofort zu verstehen. Besonders für Kinder ist es schwierig, bei diesen Spielen ohne Erklärung mitzumachen.

4.4

Woolpy

Woolpy wurde von dem Spieleklassiker Lemmings inspiriert. Bei Woolpy müssen die Spieler und Spielerinnen versuchen, möglichst viele der Figuren (Woolpys) ins Ziel zu bringen, ohne dass diese von den Plattformen fallen. Die Akteure und Akteurinnen steuern durch ihre Bewegungen ihre Avatare, mit denen sie verschiedene Aktionen auslösen können, wie zum Beispiel Portale aktivieren oder Brücken ausfahren lassen. Die Spieler und Spielerinnen können nicht direkt mit den Woolpys interagieren, sondern können diese nur durch die Veränderung der Umgebung ins Ziel führen. Dieser Spiele-Prototyp ist 2016 in dem Kurs Semesterprojekt 2 des Studiengangs Medientechnik und -design an der FH Oberösterreich Campus Hagenberg entstanden. Das Team bestand aus Romana Laister (Programmierung), Erik Thiele (Programmierung, Design) und Martina Huber (Design).

4.4.1

Analyse Woolpy

Bei Woolpy bestehen Boden- und Wandinterface aus derselben Projektion. Da die interaktiven Flächen sehr groß gestaltet wurden, stellt die Schattenbildung kein Problem dar. Bei manchen Hindernissen müssen die Spieler und Spielerinnen sehr nahe zusammen stehen. Es wurde aber darauf geachtet, dass genug Platz für diese Personen ist, ohne dass Avatare miteinander verschmelzen. Da die Akteure und Akteurinnen zusammen spielen, können die Spieler

4. Analyse bestehender LPD Games

und Spielerinnen bei Woolpy jederzeit ins Spiel einsteigen. Somit ist es auch nicht schlimm, wenn jemand das Spielfeld verlässt. Hier tritt der Nebeneffekt auf, dass man seine Spielerfarbe ändern kann, da die Farben zufällig zugeteilt werden. Die eingeschränkten Interaktionsmöglichkeiten sind bei Woolpy kein Hindernis, da durch virtuelle Knöpfe verschiedene Prozesse ausgelöst werden können. Zum Beispiel können Brücken ausgefahren werden oder Portale aktiviert werden. Woolpy hat keine maximale Spieleranzahl. Wenn über 30 Personen gleichzeitig spielen, kann es zu toten Winkeln im Tracking kommen. Wie schon erwähnt, ist es bei diesem Spiel kein Problem, wenn ein Spieler oder eine Spielerin neu einsteigen muss. Da das ganze Interface bei Woolpy sehr bunt ist, heben sich die SpielerAvatare zu wenig von dem restlichen Vordergrund ab (Abbildung 4.9). Für die Spieler und Spielerinnen ist das kein großes Problem, da sie sich auf dem Bodeninterface selbst sehen können. Für die Zuseher und Zuseherinnen ist es jedoch schwer, das Spielgeschehen mitzuverfolgen. Weiters sind die Spielelemente teilweise sehr nah am unteren Rand positioniert, was für das passive Publikum das Mitverfolgen des Spielverlaufs noch mehr erschwert.Es gibt keine zusätzlichen Informationen für die Zuseher und Zuseherinnen. Der Player View von Woolpy ist eine Mischform aus einem 3D-SideScroller und einer zweidimensionalen Ansicht. In Woolpy wird keine geschriebene oder gesprochene Sprache verwendet, nur leicht verständliche Icons. Die interaktiven Buttons sind durch ihre gelbe Farbe sehr gut erkennbar und zeigen anhand des Icons, wie viele Personen dieses Element benutzen müssen, um es zu aktivieren.

Kapitel 5

Resümee 5.1

Zusammenfassung

Bei co-located LPD Games ist es wichtig, einige Aspekte bei der Gestaltung der Benutzeroberflächen zu beachten. Spiele, die für den Deep Space 8K konzipiert wurden, nehmen die Bewegungen der Spieler und Spielerinnen durch das Tracking-System Pharus auf und werden in Echtzeit verarbeitet. Somit können mindestens 30 Personen gleichzeitig ohne gröbere Probleme spielen. Bei Spielen, die nur durch Tracking von Bewegungen gesteuert werden, sind einige Aspekte zu beachten, wie zum Beispiel der, dass Spieler oder Spielerinnen nicht gespeichert werden können oder sie miteinander verschmelzen, wenn sie sich zu nahe kommen. Weiters sind manche Punkte besonders für Wand- oder Bodeninterface zu unterscheiden und zu beachten. Beim Bodeninterface sind die schon genannten Trackingprobleme und die Schattenbildung durch die Körper zu beachten. Beim Wandinterface sollten vor allem Aspekte für die Zuseher beachtet werden, guter Kontrast zwischen Hintergrund und Spielebene, Positionierung der Spielelemente, Orientierung auf der Benutzeroberfläche und zusätzliche Informationen für die passiven Teilnehmer und Teilnehmerinnen. Ganz allgemein sollte das Interface einem Natural User Interface entsprechen und somit leicht verständlich sein. Das kann durch einen zweidimensionalen Player View, wenig Text und leicht verständlichen Piktogrammen und Icons realisiert werden. Bei LPD Games sollte man auf keinen Fall auf die Unterstützung durch Audio verzichten, da man viele Events und Aktionen dadurch noch zusätzlich unterstreichen kann. Die analysierten Spiele wurden alle für den Deep Space 8K entwickelt. Die Spiele sind sehr unterschiedlich und zeigen welche Möglichkeiten es gibt, durch Tracking (und Smart Devices) LPD Games zu steuern. Die meisten Probleme bestehen in der Orientierung auf dem Spielfeld und der Größe 29

5. Resümee

der Spielelemente. Es ist wichtig, die Balance zwischen großen interaktiven Flächen und einem nicht zu überladenen Interface zu finden.

5.2

Ausblick

In näherer Zukunft ist es möglich, dass immer mehr co-located LPD Games Smart Devices zur Erweiterung des Interfaces benutzen werden und so mehr Möglichkeiten zur Steuerung haben werden. Die Spielmechaniken können schwieriger werden, allerdings kann durch das eigene Smart Device das Verständnis für das Spielziel leichter gemacht werden.

Quellenverzeichnis Literatur [1]

Christian Bartsch. „Binaural Audio for an Immersive Co-Located Multiplayer Environment“. Diplomarbeit. Hagenberg, Austria: University of Applied Sciences Upper Austria, Interactive Media, Okt. 2016 (siehe S. 3).

[2]

Wolfgang Hochleitner u. a. „Limelight – Fostering Sociability in a Colocated Game“. In: Proceedings of the CHI 2013 Workshop on Designing and Evaluating Sociability in Online Video Games. CHI ’13. Paris, France, 2013, S. 23–28 (siehe S. 23).

[3]

Johannes Itten. Kunst der Farbe. Ravensburg: Otto Maier Verlag, 1961 (siehe S. 10).

[4]

Otto Naderer. „Crowd Tracking and Movement Pattern Recognition“. Diplomarbeit. Linz, Austria: Department of Computational Perception, Pervasive Computing, Juni 2015. url: http://epub.jku.at/obvulihs/ content/titleinfo/493866 (siehe S. 5, 10).

[5]

Kevin D. Saunders und Jeannie Novak. Game Interface Design. Game Development Essentials. 2. Aufl. USA: Delmar, 2013 (siehe S. 4, 6, 13, 14).

Online-Quellen [6] url: https://organicthemes.com/demo/retro/page/2/ (siehe S. 7). [7] url: http : / / www . nesmaps . com / maps / SuperMarioBrothers / SuperMarioBrothers.html (siehe S. 7). [8]

Ellen. Eine kleiner Einblick in die Welt der Piktogramme und Icons. 2011. url: http://www.elmastudio.de/eine-kleiner-einblick-in-die-weltder-piktogramme-und-icons/ (siehe S. 14).

[9]

Playful Interactive Environments. Game Changer. 2014. url: http : //pie.fh-hagenberg.at/projects/game-changer/ (siehe S. 16).

Quellenverzeichnis

[10]

Playful Interactive Environments. Limelight. 2012. url: http://pie.fhhagenberg.at/projects/limelight/ (siehe S. 23).

[11]

Andreas Friedl. Game Changer. 2014. url: http://game-changer.at/ de/index.html (siehe S. 16).

[12]

Andreas Friedl und Jeremiah Diephuis. Lazor Lab. 2015. url: http: //lazorlab.rohschinken.at/de/index.html (siehe S. 25, 26).

[13]

Magdalena Sick-Leitner. Deep Space 8K - The Next Generation. 2015. url: https://www.aec.at/feature/de/deep-space-8k/ (siehe S. 4, 5).

[14]

Wikipedia. Tracking. 2016. url: https : / / de . wikipedia . org / wiki / Tracking (siehe S. 3).