Mobile Quartett Mobile Computing

Transkript

1 Mobile Quartett Mobile Computing Sven Dworschak Robert Hahn 22. Februar 2012 Zusammenfassung Im Zuge der Lehrveranstaltung Mobile Computing wurde eine Android App entwickelt, mit der es möglich ist, das bekannte Kartenspiel Quartett zu spielen. Die App wurde darauf ausgelegt, dass zwei Spieler mit Ihren mobilen Geräten gegeneinander spielen können. Die Verbindung zwischen beiden Geräten wird mit Bluetooth aufgebaut. Um eine möglichst aktive Spielatmosphäre zu simulieren, wurde auf eine Gestensteuerung während des Spiel wert gelegt. Die App ist mit Quartett-Kartendecks frei erweiterbar. Spieler können somit Ihre eigenen Kartendecks erzeugen und anschließend spielen. Inhaltsverzeichnis 1 Einleitung 2 2 Ein Quartett spielen Anwendungsfall-Diagramm Systemarchitektur Datenhaltung Datenmodell Umsetzung Bluetooth - Kommunikation Verwendung Umsetzung User Interaktion 8 5 Design 9 1

2 Mobile Computing 2 6 Fazit 11 1 Einleitung In der heutigen Zeit von Smartphones und Apps ist es nicht mehr notwendig, ein reales Kartenspiel zu besitzen und mitzuführen. Stattdessen bieten Smartphones oder Tablets die Möglichkeit, mit virtuellen Karten zu spielen. Mobile Quartett ist eine mobile Anwendung, die dies ermöglicht. Ziel des Projekts Mobile Quartett war es, eine App zu entwickeln, mit der zwei Personen über Bluetooth gegeneinander auf Ihrem Smartphone oder Tablet spielen. Um gegeneinander Quartett auf Smartphones spielen zu können, benötigen beide Spieler das gleiche Kartendeck und Bluetooth. Da Mobile Quartett mit Gesten gesteuert wird, wird ein Smartphone mit Touchscreen benötigt. Im Nachfolgenden wird zunächst das Kartenspiel Quartett erläutert. Dabei werden die Spielregeln und der Spielablauf erklärt. Darauf aufbauend werden die Anforderungen an Mobile Quartett genannt. Die aus den Anforderungen resultierende Architektur der Anwendung wird im nächsten Kapitel beschrieben. Dort wird eine grobe Übersicht der Systembestandteile gegeben sowie die wesentlichen Merkmale von Mobile Quartett genannt, welche in den darauf folgenden Kapiteln detailliert erläutert werden. Abschließend wird das Design der Anwendung vorgestellt, indem die wichtigsten Screens dargestellt und erläutert werden. 2 Ein Quartett spielen Quartett ist ein bekanntes Kartenspiel, das mit verschiedenen Themengebieten gespielt werden kann. Ein Quartett hat 32 Karten, die unter den Spielern (zwei bis vier) gleichmäßig aufgeteilt werden. Ein Kartendeck (ein Quartett) handelt von einem Thema, wie z.b. Autos, wobei jede Karte ein Objekt dieses Themas repräsentiert. Eine Karte besitzt neben einem Bild des Objektes beliebig viele kartendeck-spezifische Attribute. Die nachfolgende Abbildung zeigt eine Karte am Beispiel eines Auto-Quartetts. In einer Spielrunde wird die aktuelle Karte jedes Spielers anhand eines ausgewählten Attributes (wie z.b. "PS") untereinander verglichen. Der Sieger der Spielrunde erhält die Karten des Verlierers und darf das Attribut der nächsten Spielrunde wählen. Gespielt wird, bis ein Spieler alle Karten besitzt. Mobile Quartett soll mit beliebig vielen Kartendecks auf unterschiedlichen Auflösungen gespielt werden können. Der Spieler kann seine Karten von jedem Deck durchblättern, bevor ein Spiel startet. Nach einem Spiel kann sich der Sieger mit einem Spielernamen in der Highscoreliste eintragen. Da es sich bei dieser App um ein grafiklastiges Spiel handelt, ist nicht nur ein ansprechendes Design, sondern auch eine benutzerfreundliche und intuitive Bedienbarkeit wichtig. Beispielsweise soll die App mit Gesten wie z.b. Sliden einer Karte bedient wer- Abbildung 1: Spielkarte

3 Mobile Computing 3 den. 2.1 Anwendungsfall-Diagramm Abbildung 2: Anwendungsfälle 3 Systemarchitektur Mobile Quartett ist eine mobile Anwendung, bei der zwei Personen an einem Ort gegeneinander über ihr Smartphone spielen. Da sich beide Spieler deshalb in unmittelbarer Nähe befinden, wurde Bluetooth zur Kommunikation verwendet. Die nachfolgende Abbildung 3 soll dies verdeutlichen.

4 Mobile Computing 4 Abbildung 3: Bluetoothkommunikation Diese Abbildung ermöglicht einen ersten Einblick auf oberster Ebene. Um die Komponenten zu betrachten, ist es notwendig, eine Ebene tiefer zu gehen.(abb.4) Die Kommunikation via Bluetooth Abbildung 4: Systemaufbau wurde durch einen Service realisiert, welcher die Verbindung zwischen beiden Geräten verwaltet. Dies besitzt den Vorteil, dass eine Trennung zwischen View, Persistenz und Kommunikation stattfinden kann. Die Kommunikation zwischen View und dem Service ist entkoppelt und findet über eine Messenger-System statt. Über diese Messages erhält die View Informationen darüber, ob sich etwas verändert hat. Dabei wird eine asynchrone Kommunikation zu Grunde gelegt. Ferner können Anfragen an das entfernte Device über den Service abgeben werden. Ob ein Spieler seine Kartendecks durchblättern, gegen eine andere Person spielt, oder sich den Highscore ansehen möchte: Bei Mobile Quartett ist der Datenaustausch ein zentrales Merkmal. Da die Kartendecks dauerhaft verfügbar sein sollen, benötigt die Anwendung Persistenz. Dies wurde durch einen ContentProvider realisiert, der mit der Datenbank auf dem Smartphone kommuniziert. Um die Anwendungslogik zu kapseln, wurde eine Schnittstelle zwischen den Activities und dem ContentProvider geschaffen. Diese Abstraktionsschicht stellt den Activities direkt ein Objekt, wie beispielsweise ein Kartendeck oder eine Karte zur Verfügung und regelt den gesamten Datenaustausch.

5 Mobile Computing 5 Abbildung 5: Architektur 3.1 Datenhaltung Im Nachfolgenden soll die Datenhaltung näher betrachtet werden. Diese wird benötigt um Kartendecks zu persistieren. 3.2 Datenmodell Abbildung 6: Datenmodell Die Kartendecks werden in einer eigenen SQLite-Datenbank auf dem Smartphone gespeichert. Ein Kartendeck ist über seine ID eindeutig identifizierbar und hat einen Namen. Es kann aus beliebig vielen Karten bestehen. Eine Karte ist eindeutig über ihre ID sowie die ID des Decks identifizierbar und besitzt einen Namen und ein Bild. Eine Karte kann beliebig viele Attribute haben. Ein Attribut

6 Mobile Computing 6 kann über die ID der Karte sowie die ID des Decks genau zugeordnet werden und besteht aus einem Namen und einem Wert. Alle Objekte besitzen eine Datenbank-ID, die unabhängig von der Deckund Karten-ID ist.für das eigentliche Spiel erhalten die Spieler Spielkarten. Eine Spielkarte ist eine Kopie einer Karte. Die Anzahl der Spielkarten nimmt während dem Spiel zu oder ab, da die eine Spielkarte nach einer Spielrunde den Besitzer wechselt. Da sich die Karten eines Decks nicht verändern sollen, existieren Spielkarten. Während des Spiels ist immer eine Spielkarte die aktuelle. Die nachfolgende Abbildung zeigt das Datenmodell von Mobile Quartett Umsetzung Ein Kartendeck ist durch eine XML-Datei auf der SD-Karte realisiert und besitzt eine festgelegte Struktur: <kartendeck titel=... id=... > <karte id=... > <titel>...</titel> <attribut name=... wert=... /> <bild>...</bild> </bild> </kartendeck> Jede XML-Datei besitzt eine einmalige ID für das Kartendeck. Damit wird sichergestellt, dass das Kartendeck eindeutig identifizierbar ist. Eine Karte gehört immer zu einem Kartendeck und wird durch eine Karten-ID sowie die ID des dazugehörigen Decks eindeutig. Die XML-Dateien werden mit einem SAX-Parser von der SD-Karte ausgelesen und in die Datenbank geschrieben. Bei jedem Start der Anwendung wird geprüft, ob sich XML-Dateien auf der SD-Karte befinden, welche noch nicht in der Datenbank sind. Ist das der Fall, werden die Dateien geparsed und in die Datenbank geschrieben. Jede Activity hält eine Instanz der Schnittstelle zum Datenaustausch, dem GameDataManager. Der GameDataManager kommuniziert über eine eindeutige Uri mit dem ContentProvider. Anhand der Uri führt der ContentProvider Befehle auf der Datenbank aus. Der GamedataManager stellt den Activities alle Daten in Form von Objekten für die Anwendung zur Verfügung. Aus dem Cursor, der aus einer Anfrage an den ContentProvider resultiert, wird in ein Objekt an die Activity gegeben. 3.3 Bluetooth - Kommunikation Bluetooth ist eine Funktechnologie für die Datenübertragung zwischen Geräten über kurze Distanz. Damit ein Quartett-Spiel durchgeführt werden kann, benötigen beide Geräte die Möglichkeit eine Bluetoothverbindung aufzubauen. Im Folgenden soll gezeigt werden, wann diese Technologie in der App zum Einsatz kommt, und wie ein Kommnikationsablauf am Beispiel eines Kartenverlusts stattfindet.

7 Mobile Computing Verwendung Beide Spieler betreten zunächst den Bereich Mitspieler zu suchen. Dazu wird über Bluetooth nach anderen in der Nähe befindlichen Geräten gesucht. Haben sich beide Spieler gefunden, können diese nun per entsprechender Auswahl des Mitspielers eine Verbindung zueinander aufbauen. Kommt es zu einer erfolgreichen Verbindung betreten beide Spieler einen Lobby-Bereich. An dieser Stelle können die Spieler über die entsprechenden Kartendecks des Mitspielers informieren, und ein Spiel initiieren. Dadurch wählt ein Spieler aus seinen vorhandenen Kartendecks eins aus, und fragt den Mitspieler per Tastendruck an dieses zu spielen. Besitzt der Mitspieler nicht das gleiche Spieldeck, so wird der Spielinitiator darüber informiert, und er sollte ein anderes Spieldeck aussuchen, welches beide Spieler im Bestand haben. Kommt ein Spiel zu Stande besitzen beide Spieler die gleiche Anzahl an Quartett-Karten. Jede dieser Karten ist eindeutig, und es wird eine Spielkarte aus dem jeweiligen Kartenbestand des Spielers angezeigt. Das Spiel beginnt der Spielinitiator indem dieser ein Attribut seiner angezeigten Karte wählt. Ein Vergleich mit dem gleichen Attribut der Karte des Gegenspielers findet unmittelbar statt. Der höhere Wert gewinnt. Die nächste Karte erscheint nach einer erneuten Interaktion des Spielers und der Gewinner des vorherigen Zugs beginnt Umsetzung Das Android-Framework bietet die Möglichkeit eine Bluetoothverbindung auf Basis eines Server- Clientprinzips zu erzeugen. Dazu muss ein Gerät die Rolle des Servers, und das andere Gerät die Rolle des Clients annehmen. Da bei einem Spieler technologische Gegebenenheiten nicht vorausgesetzt werden können, entscheidet das App bei einem Verbindungsaufbau selbstständig ob es die Rolle des Servers, oder die des Clients annimmt. Um dies zu ermöglichen wird auf die Eigenschaft, dass sich die einzelnen Bluetooth-Controller während des Verbindungsaufbaus über eine individuelle 48 bit lange MAC-Adresse identifizieren gesetzt. Anhand eines einfachen Wertvergleichs kann entschieden werden ob das Gerät Server oder Client im Kommunikationsprozess ist. Damit beide Geräte nun über die bestehende Bluetoothverbindung kommunizieren können, wird ein Kommunikationsprotokoll zu Grunde gelegt.

8 Mobile Computing 8 BEFEHL BESCHREIBUNG ZUSATZINHALT REMOTE_REQ_PACKS Anfrage nach Kartendecks des - Mitspielers REMOTE_RES_PACKS Antwort des Mitspielers mit dessen Kartendeck Ids und Spielername Kartendecks REMOTE_REQ_NEWGAME Anfrage fuer ein Spiel Karten-Ids für Mitspieler REMOTE_RES_GAME Bestätigung wenn Mitspieler - Spiel initialisiert hat REMOTE_REQ_RESULT Spieler der auswählt schickt Werte KartenID und Attribut seiner Auswahl REMOTE_RES_RESULT Spieler der nicht ausgewählt hat antwortet mit Auswertung Gewonnen / Verloren und KartenId REMOTE_RES_NEXTCARDL Verlierer teilt Gewinner mit, dass - er neue Runde starten darf REMOTE_RES_NEXCARDW Gewinner teilt Verlierer mit, dass er bereit ist - Tabelle 1: Überblick über den Kommunikationsprozess während eines Spiels Zu Beginn eines Spiels betreten beide Spieler zunächst eine Lobby. Dort befragen sie jeweils das andere Gerät welche Kartendecks der Mitspieler besitzt und welchen Namen der Mitspieler trägt (REMOTE_REQ_PACKS). Beide Antworten mit den Namen der Spieldecks und des eigenen Spielernamens (REMOTE_RES_PACKS). Einer von beiden wählt ein Spieldeck aus dem eigenen Bestand aus, und stellt die Anfrage auf ein neues Spiel.(REMOTE_REQ_NEWGAME).Da beide Geräte bereits wissen welche Decks das andere Gerät im Bestand hat, kann vor der Anfrage geprüft werden ob ein Spiel stattfinden darf. Darf das Spiel stattfinden, wird dem Mitspieler der angefragt worden ist sein Kartendeck vorgegeben. Der Spielinitiator gibt somit vor welche Karten er im Besitz während des Spiel hat, und welche der Mitspieler. Hat der Mitspieler die Spielkarten abgespeichert, bestätigt er dies. (REMOTE_RES_GAME). Der Spielinitiator beginnt das Spiel und übermittelt die Auswahl auf seiner Karte an den Mitspieler (REMOTE_REQ_RESULT). Da beide Spieler im Besitz des selben Kartendecks sind, genügt hier die Übertragung von KartenID und Auswahl des Attributs. Der Empfänger wertet das Ergebnis aus. Im Falle, dass der Empfänger gewonnen hat, nimmt er die gewonnene Karte in sein Spieldeck auf, und teilt dem Sender mit, dass dieser verloren hat (REMO- TE_RES_RESULT).Dieser löscht die Karte aus seinem Spieldeck. Im Falle eines Verlusts wird dem Sender die gewonne Karten-Id mitgeteilt(remote_res_result). Der Spieler, der verloren hat muss die Karte visuell abgeben. Durch das Abgeben (REMOTE_RES_NEXTCARDL) erhält der Gewinner die Erlaubnis zur nächsten Karte zu wechseln. Wechselt der Gewinner die Karte visuell, teilt er dies dem Verlierer mit (REMOTE_RES_NEXCARDW). Eine neue Runde beginnt. 4 User Interaktion Die Benutzeroberfläche von Mobile Quartett wurde so gewählt, dass eine einfache Navigation über großse UI-Elemente gewährleistet wird. Alle Menüpunkte lassen sich per Touchäuf das jeweilige Icon öffnen. Das zurücknavigieren geschieht mit dem von Android vorgegebenen Back-Button, und

9 Mobile Computing 9 spricht damit für eine erwartungskonforme Navigation. Im Kartenspiel wird neben der Möglichkeit die Attribut-Werte per Touch auszuwählen eine Gestenerkennung eingesetzt. Damit soll dem Benutzer in eine realistischere Spielatmosphäre versetzt werden. Ein Spieler gibt eine Karte ab, indem er in senkrechter Richtung vom unteren Bildschirmrand zum Oberen wischt. Eine Animation unterstreicht den Verlust einer Karte. Im Falle eines Gewinnes ist es vorgesehen, dass der Spieler zur nächsten Karte blättert. Dadurch schiebt er seine gespielte Karte von rechts nach links weg. Erst dann erscheint eine neue Spielkarte. 5 Design Das Design der App wurde möglichst an dem von Android vorgegebenen UI-Design-Pattern-Empfehlungen ausgerichtet. Empfehlungen können in diesem PDF nachgelesen werden: Das Dashboard von Mobile- App nähert sich der Empfehlung von Google an. Ziel ist es die wichtigsten Elemente in den Fokus der Betrachtung zu setzen. Dadurch rückte beispielsweise der Button ein Spiel zu beginnen in die Mitte vom Bildschirm. Das Ändern eines Spielernamens wurde in das Options-Menü verlagert, um den Dashboard-Platz mit weniger wichtigeren Funktionen nicht zu vergeuden. Unterschiedliche Bildschirmauflösungen die gegenwärtig bei Android eine entscheidenen Einfluss auf ein Design haben können wurden berücksichtigt. Die verwendeten Icons wurden in allen drei Auflösungstypen (hdpi,mdpi,ldpi) hinterlegt, um eine schlechte Darstellung auf unterschiedlichen Geräten zu vermeiden. Die Spielkartenbilder, wurden in einer Auflösung gewählt, die eine entsprechende Darstellung auf einem Tablet gewährleisten. Für kleinere Bildschirme wird eine eigene Skalierung verwendet. Diese kommt im Hauptmenü während der Auswahl der Kartendecks, sowie bei der Darstellung von Spielkarten zum Einsatz.

10 Mobile Computing 10 Abbildung 7: links: Das Dashboard, rechts: Die Lobby Das Dashboard ist der Einstiegspunkt in die Anwendung. Der Benutzer kann seine Kartendecks ansehen, die Karten eines Decks durchblättern, die Spielregeln und den Highscore anschauen. Möchte er spielen, gelangt er zunächst in die Spielersuche. In der Gamerlist werden Bluetoothgeräte gesucht, und miteinander verbunden. Existiert noch keine Bluetoothverbindung wird diese auf Anfrage eingeschaltet. Explizit besteht die Möglichkeit sein Gerät sichtbar zu machen, und eine Suche nach Geräten zu beginnen. Sind Geräte noch nicht gepaired ist dies auch von hier aus möglich. In der Lobby sieht der Spieler die Kartendecks des Mitspielers. Er kann aus seinen Kartendecks am oberen Bildschirm durch Sliden eins auswählen und mit dem Button Spielen ein Spiel beginnen. Das Spiel beginnt, wenn beide Spielpartner das selbe kartendeck besitzen

11 Mobile Computing 11 6 Fazit Abbildung 8: Die Gamerlist Gegenwärtige Quartett-Spiele im Market bieten nur wenig, bis gar keine Interaktionsmöglichkeiten während eines Spiels. Ebenso ist das Erweitern der Apps durch Kartendecks oft nicht möglich. Mit Mobile-Quartett konnten Anforderungen umgesetzt werden, die im Kontext eines Quartett-Apps bisher kaum umgesetzt worden sind. Ein Quartettspiel lebt davon sich mit den Karten auseinanderzusetzen. Leider wird viel zu oft dies vernachlässigt und die Karten verschwinden nach Auswahl eines Attributes umgehend. Durch das aktive Abgeben und Weiterblättern bleibt dem Spieler genug Zeit sich die Karte anzusehen, die er gewonnen hat. Durch das Erweitern eigener Spieldecks und das Spiel mit Freunden in der Nähe spielen zu können erhöht den Spielspass.In Zukunft könnte man sich vorstellen Kartenpakete im Market anzubieten, oder einzigartige Karten im Spiel zu verwenden.