Echtzeitapplikationen im Web-Kontext am Beispiel eines Multiplayer-Spiels

Transkript

1 Hochschule RheinMain Fachbereich Design Informatik Medien Studiengang Medieninformatik Abschlussarbeit zur Erlangung des akademischen Grades Bachelor of Science (B.Sc.) Echtzeitapplikationen im Web-Kontext am Beispiel eines Multiplayer-Spiels Vorgelegt von Wasili Adamow am 04. Oktober 2013 Referent Prof. Dr. Jörg Berdux Korreferent Prof. Dr. Wolfgang Weitz

2 2

3 3 Erklärung gemäß ABPO Ich erkläre hiermit, dass ich die vorliegende Abschlussarbeit selbstständig angefertigt, keine anderen als die angegebenen Quellen benutzt, die wörtlich oder dem Inhalt nach aus fremden Arbeiten entnommenen Stellen, bildlichen Darstellungen und dergleichen als solche genau kenntlich gemacht und keine unerlaubte fremde Hilfe in Anspruch genommen habe. Wiesbaden, 04. Oktober 2013 Wasili Adamow Erklärung zur Verwendung der Bachelor Thesis Hiermit erkläre ich mein Einverständnis mit den im folgenden aufgeführten Verbreitungsformen dieser Abschlussarbeit: Verbreitungsform Ja Nein Einstellung der Arbeit in die Hochschulbibliothek mit Datenträger Einstellung der Arbeit in die Hochschulbibliothek ohne Datenträger Veröffentlichung des Titels der Arbeit im Internet Veröffentlichung der Arbeit im Internet Wiesbaden, 04. Oktober 2013 Wasili Adamow

4 4

5 Zusammenfassung Das Internet entwickelt sich immer weiter und übernimmt immer mehr Bereiche des alltäglichen Lebens. Dadurch wandern viele Applikationen, welche man bisher noch lokal installieren musste, in das Netz ab und werden somit für immer mehr Menschen zugänglich. Diese Arten von Diensten bringen viele Vorteile mit sich: Sie sind von überall auf jedem Endgerät erreichbar, speichern zuverlässig Daten ab und laufen so schnell, als wären sie lokal installiert. Jedoch steigt dadurch der Anspruch an die Hardware und an die Technologien immer weiter, wodurch diese sich immer weiterentwickeln müssen - was früher mit HTTP umgesetzt wurde, ist für diese Applikationen schon viel zu langsam. Diese Arbeit soll an einem Beispiel aufzeigen, wie man mit den heutigen Mitteln eine effiziente, verteilte Web- Applikation entwickeln kann, welche zudem in Echtzeit auf nahezu jedem Gerät lauffähig ist.

6 2

7 Inhaltsverzeichnis 1 Einleitung 5 2 Spielkonzept Grundlegende Spielmechanik Spielmechanik im Mehrspieler-Modus Echtzeitkommunikation im Web HTTP AJAX Websockets WebRTC Vergleich Websockets, Socket.IO & WebRTC Zusammenfassung Anforderungsanalyse Benutzerinteraktionen Spielelemente Echtzeit Kompatibilität Konzept Gesamtüberblick Netzwerkkommunikation Infrastruktur

8 4 Inhaltsverzeichnis Nachrichtentypen Datenverwaltung Struktur der Clients Ablauf der Kommunikation Implementierung Auswahl der Technologien Netzwerkschicht Server Client Schlusswort 77

9 Kapitel 1 Einleitung Das Internet und dessen Funktionalitäten wachsen immer weiter. Während zu Beginn der Entwicklungen vor allem der schnelle Transport von einfachen Textnachrichten im Vordergrund stand, haben sich heutzutage diese Nachrichten soweit entwickelt, dass man mit ihnen alle erdenklichen Daten verschicken kann. Durch die immer besser werdende Hardware und die damit schnellere Übertragung von Daten durch das Netz, etabliert sich seit einigen Jahren auch das Cloud Computing, welches als Grundlage für verschiedene Dienste über das Internet dient. Hierbei werden nach dem National Institute of Standards and Technology (NIST) drei Formen unterschieden: Platform as a Service (PaaS), Infrastructure as a Service (IaaS) und Software as a Service (SaaS) [12]. Neben dem Sichern von Daten im Netz (Cloud Storage), was zum Bereich IaaS zählt, ist vor allem das Auslagern von Software sehr verbreitet und wird von vielen Internetdiensten angeboten - ein Beispiel hierfür sind Textverarbeitungsprogramme. Diese Verschiebung der Dienste in das Netz hat sowohl für die Nutzer als auch für die Anbieter einige Vorteile. Die Nutzer können, ungeachtet der genutzten Geräte, von überall auf ihre Daten zugreifen, diese bearbeiten und wieder abspeichern. Dies ist wiederum auch ein Vorteil für die Anbieter, da diese immer mehr Dienste direkt im Browser anbieten können und somit nicht für jedes System unterschiedliche Software produzieren müssen. Jedoch steigen hierdurch auch die Ansprüche an die Technologien, auf denen diese Dienste basieren. Die Server müssen viel mehr Daten abspeichern, verwalten und anbieten können, ohne dabei an Geschwindigkeit zu verlieren. Auch das Netzwerk muss eine immer größer werdende Datenmenge übertragen können. Zuletzt müssen die verschiedenen Dienste auch auf allen Endgeräten die gleichen Funktionalitäten anbieten, weshalb diese bestimmte Technologien unterstützen müssen. Da all dies in der Praxis meist nicht umsetzbar ist, müssen Kompromisse eingegangen und Alternativen zur Verfügung gestellt werden, damit 5

10 6 Einleitung möglichst viele Nutzer die Dienste verwenden können. Diese Arbeit befasst sich mit der Thematik von Software im Netz und zeigt dabei am Beispiel eines Multiplayer-Spiels auf, mithilfe welcher Technologien momentan eine Applikation im Web-Kontext umgesetzt werden kann. Hierbei liegt der Fokus auf der Kommunikation in Echtzeit - es werden jedoch auch andere Bereiche der Server und Clients behandelt. Die Entwicklung eines Spiels hat dabei mehrere Vorteile: Zum einen ist es bei einem Spiel einfach, Probanden zu finden und durch diese wertvolle Verbesserungsvorschläge zu erhalten. Dies liegt vor allem daran, dass die Zielgruppe bei einem Spiel sehr breit gestreut ist und auch viele technikaffine Personen einschließt. Zum anderen gibt es nur sehr wenige andere Anwendungsfälle, in denen der Benutzer eine Verzögerung als so störend wahrnimmt, wie bei einem Spiel, in dem teilweise Millisekunden über den Ausgang einer Spielrunde entscheiden können. Dadurch ergibt sich eine optimale Umgebung, in der man eine verteilte Applikation mit dem Fokus auf die Echtzeit implementieren kann. Hierzu wird in dieser Arbeit zuerst die Spielmechanik beschrieben, welche in die Bereiche Einzelspieler- und Mehrspielermodus aufteilt ist. Danach zeigt die Entwicklung der Technologien für die Internetkommunikation auf, wie die beiden heutigen Ansätze für die Echtzeitkommunikation entstanden sind und welche älteren Technologien als Fallback genutzt werden können. Als nächstes werden die durch das Spiel gestellten Anforderungen gesammelt und analysiert, bevor sie im nächsten Schritt zum Konzept umgewandelt werden. Dieses Kapitel ist zuerst in die Bereiche Netzwerk, Server und Client aufgeteilt. Danach werden die dabei entstandenen Informationen verbunden, sodass ein Gesamtkonstrukt entsteht, an dem dann gezeigt wird, wie die einzelnen Komponenten miteinander kommunizieren können. Basierend auf diesem Konzept werden zuerst die verschiedenen Technologien ausgewählt, welche für die Implementierung genutzt werden. Danach folgen kurze Übersichten über die Umsetzungen der einzelnen Bereiche der Applikation. Wie sich die Technologien bewährt haben und was in Zukunft noch bevorsteht, wird im Schlussteil dargestellt.

11 Kapitel 2 Spielkonzept In diesem Kapitel wird die Spielmechanik der Applikation beschrieben, welche in dieser Arbeit beispielhaft umgesetzt wird. Dazu wird zunächst erläutert, wie dieses Spiel aussieht und welche Möglichkeiten der Benutzer hat. Diese Erläuterung bezieht sich zunächst auf die grundlegende Spielmechanik, wie sie bereits in anderen Spielen im Einzelspieler-Modus auftaucht. Danach wird dieses Konzept so erweitert, dass sich daraus ein Mehrspieler-Modus ergibt, in dem mehrere Benutzer parallel zusammen und gegeneinander spielen können. 2.1 Grundlegende Spielmechanik Die Vorlage für das Spiel wurde im Juni 1994 vom japanischen Spieleentwickler Taito Corporation als Puzzle Bobble veröffentlicht [1]. Als Grundlage für das Spiel dient ein rechteckiges Spielfeld, welches in Abbildung 2.1 dargestellt ist. Auf diesem werden vom oberen Spielfeldrand aus mehrere Reihen von verschiedenfarbigen Kugeln in das Spielfeld hineingeschoben. Am unteren Rand befindet sich mittig eine weitere Kugel, welche durch einen Klick auf das Spielfeld auf die oberen Kugeln geschossen werden kann. Der Spieler besitzt einen Kugelvorrat mit maximal fünf Kugeln, welche in einem Zusatzfeld unter dem Spielfeld dargestellt werden. Beim Abschuss einer Kugel fliegt diese immer in Richtung des Punktes los, auf den geklickt wurde. Gelangt die Kugel im Flug entweder an den linken oder rechten Spielfeldrand, so prallt diese ab und ändert die horizontale Richtung. Das geschieht solange, bis die Kugel auf eine andere Kugel oder auf den oberen Spielfeldrand trifft. In beiden Fällen wird sie auf den nächsten freien Platz im Raster gesetzt und ist nun Teil der Kugelreihen. Danach wird überprüft, ob die gesetzte Kugel an eine gleichfarbige Kugelgruppe an- 7

12 8 Spielkonzept Abbildung 2.1: Das Spielfeld mit allen relevanten Objekten grenzt, sodass sich nun eine Gruppe von mindestens drei gleichfarbigen Kugeln bildet. Wenn dies der Fall ist, werden alle Kugeln dieser Gruppe vom Spielfeld entfernt. Dabei kann es passieren, dass Kugeln ohne Verbindung zum oberen Spielfeldrand zurückbleiben und somit auf dem Spielfeld schweben. Diese Kugeln werden dann ebenfalls entfernt, wie in Abbildung 2.2 zu sehen ist. Abbildung 2.2: Zunächst wird die Gruppe der gelben Kugeln entfernt, wodurch die drei blauen Kugeln schweben. Diese werden daher als nächstes vom Spielfeld genommen Nachdem das Spielfeld, falls benötigt, aufgeräumt wurde, erhält der Benutzer die nächste Kugel am unteren Spielfeldrand und kann mit dieser das Spiel fortsetzen. Hat der Nutzer mit seiner zuletzt abgeschossenen Kugel keine Gruppe gebildet, so wird eine Kugel vom Vorrat entfernt. Wird die letzte Kugel vom Kugelvorrat verschossen, so wird vom oberen Spielfeldrand eine neue Reihe von Kugeln nachgeschoben. Dann werden mögliche schwebende Kugeln entfernt und der Kugelvorrat

13 Spielkonzept 9 wird wieder mit fünf neuen Kugeln aufgefüllt. Während des Spiels ist es möglich, dass man eine Kugelfarbe komplett vom Spielfeld entfernt, wo-durch diese Farbe nicht mehr neu produziert wird. Dadurch nehmen nachfolgende Kugeln sowohl am unteren Spielfeldrand als auch in den Reihen diese Farbe nicht mehr an. Das sorgt dafür, dass das Spielfeld übersichtlicher wird und man sich dem Ziel des Spiels schrittweise nähern kann. Jedoch hat das auch Auswirkungen auf den Spielverlauf, da für jede entfernte Kugelfarbe eine weitere Reihe beim Verbrauchen des Vorrats hinzugefügt wird. Ziel des Spiels ist es, alle Kugelreihen vom Spielfeld zu entfernen. Dabei erhält man je nach benötigter Zeit oder verschossenen Kugeln unterschiedlich viele Punkte und kann sich so mit anderen Spielern messen. Erreicht man hingegen mit einer Kugel den unteren Rand des Spielfelds, so hat man das Spiel verloren und erhält keine Punkte. 2.2 Spielmechanik im Mehrspieler-Modus Das Spiel soll nun so erweitert werden, dass mehrere Benutzer zusammen und gegeneinander spielen können. Hierzu verbindet der Benutzer sich zunächst mit einem Server und befindet sich danach im Hauptmenü des Spiels, welches in Abbildung 2.3 dargestellt ist. Hier kann er seinen Benutzernamen sehen und ändern und bekommt eine Liste der aktuellen Spiellobbys dargestellt. Aus dieser Liste kann er sich einen Eintrag aussuchen und beitreten oder eine eigene Spiellobby erstellen. Abbildung 2.3: Im Hauptmenü sieht der Benutzer seinen Namen und die aktuellen Spiellobbys

14 10 Spielkonzept Sobald der Benutzer eine Spiellobby auswählt oder eine eigene Lobby erstellt, gelangt er in das Lobby-Menü, welches in Abbildung 2.4 zu erkennen ist. Hier sieht der Benutzer zunächst den Namen der Lobby und eine Liste der aktuellen Teilnehmer. Unter dieser Liste befindet sich eine Schaltfläche um wieder ins Hauptmenü zu gelangen. Ist der Benutzer der Ersteller der Lobby, so kann er andere Benutzer aus der Lobby entfernen oder auch das Spiel starten. Abbildung 2.4: In der Spiellobby hat der Ersteller die Möglichkeit, andere Spieler zu entfernen und das Spiel zu starten Im Spiel hat jeder Benutzer ein eigenes Spielfeld und sieht zusätzlich noch eine verkleinerte Darstellung der anderen Spielfelder. Dadurch ist es bereits möglich, das Spiel parallel zu nutzen und zu sehen, was auf den anderen Spielfeldern passiert man kann also parallel spielen. Für die Interaktion zwischen den Spielern sorgen die Extras, welche bei besonders vielen entfernten Kugeln auf dem eigenen Spielfeld erscheinen. Ein Extra ist eine besondere Kugel ohne Farbe, welche beim Entfernen einer angrenzenden Gruppe eingesammelt wird und in das Inventar des aktuellen Benutzers übergeht. Der Benutzer kann dann die einzelnen Extras sequentiell in der Reihenfolge des Einsammelns nutzen und diese entweder auf sich selbst oder andere Teilnehmer des Spiels anwenden. Beim Anwenden verursacht jedes Extra eine Aktion, welche dem jeweiligen Ziel schaden oder helfen kann. Entfernt der Benutzer mit einem Schuss zehn gleichfarbige oder aber fünf schwebende Kugeln, so verwandelt sich eine zufällige andere Kugel auf dem Spielfeld in ein Extra, was durch einen Buchstaben auf der nun farblosen Kugel dargestellt wird. Die verschiedenen Typen der Extras sind in Tabelle 2.1 zu erkennen. Sammelt der Benutzer das Extra durch das Entfernen benachbarter Kugeln ein, so landet es in seinem Inventar, wobei neue Extras immer hinten angefügt werden. Der Benutzer

15 Spielkonzept 11 kann nun das erste Extra durch Drücken einer Spielertaste (1-9) anwenden und so beispielsweise eine Reihe von seinem Spielfeld entfernen und sich helfen oder einem Mitspieler eine Reihe hinzufügen und diesen behindern. Dabei unterscheiden sich die einzelnen Extras in der Art, wie sie wirken. Manche Extras wirken direkt, während andere eine gewisse Wirkdauer haben, über welche der jeweilige Effekt anhält. Letztere sind mit der jeweiligen Dauer in der Tabelle vermerkt. Symbol Bedeutung Effekt A Reihe hinzufügen Neue Kugelreihe von oben R Reihe entfernen Oberste Kugelreihe wird entfernt C Steuerung verdrehen Steuerung 10s lang invertiert F Schnellere Kugel Kugel 10s lang doppelt so schnell S Langsamere Kugel Kugel 10s lang halb so schnell Tabelle 2.1: Die einzelnen Extras mit ihren jeweiligen Effekten Der Oberfläche müssen nun weitere Elemente hinzugefügt werden, um so die neuen Funktionalitäten darstellen zu können, wie in Abbildung 2.5 zu sehen ist. Neben den anderen Spielfeldern und dem Inventar des Spielers werden außerdem noch aktive Extras mit der verbleibenden Dauer angezeigt. Im abgebildeten Fall wurde die Steuerung des Benutzers verdreht ( C -Extra) und die Kugelgeschwindigkeit erhöht. Durch das zweite C -Extra wird die Steuerung wieder richtiggestellt, solange beide Extras aktiv sind. Nach fünf Sekunden würde der Benutzer also wieder eine verdrehte Steuerung für die verbleibenden drei Sekunden erhalten. Diese Regeln bilden die Grundlage für die Applikation und werden in den folgenden Kapiteln analysiert, erweitert und umgesetzt.

16 12 Spielkonzept Abbildung 2.5: Die Oberfläche wurde um die Spielfelder der anderen Benutzer, das Inventar und aktive Extras erweitert

17 Kapitel 3 Echtzeitkommunikation im Web Benutzer wollen Anwendungen, welche ohne merkbare Verzögerung auf Eingaben reagieren und passende Ausgaben liefern, weshalb das Arbeiten in Echtzeit eine grundlegende Anforderung an viele Anwendungen ist. Sobald diese Anwendungen über mehrere Systeme und Benutzer verteilt werden, muss auch die Kommunikation zwischen den einzelnen Stellen so verzögerungsarm verlaufen, dass die einzelnen Benutzer in ihrem Arbeitsfluss nicht behindert werden. Doch vor allem im Web- Umfeld war die ursprüngliche Entwicklung nicht darauf ausgelegt, dass Benutzer in Echtzeit miteinander kommunizieren können - ein Beispiel hierfür ist das in dieser Arbeit thematisierte Mehrspieler-Spiel. Deshalb gab es in den letzten Jahren vermehrt Technologien, welche diese Lücke schließen sollten. Diese Technologien bilden die Grundlage für die Entwicklung von Echtzeit-Anwendungen im Web- Kontext und sollen deshalb aufgezeigt werden. 3.1 HTTP Als Grundlage für die Kommunikation im Internet dient das Hypertext Transfer Protocol (HTTP) derzeit in der Version 1.1. Auf Basis dieses Standards kommunizieren auch heutzutage noch Browser, Server und Web-Applikationen miteinander "HTTP is the common language of the modern global Internet."[8]. HTTP selbst ist ein Protokoll, welches eine zuverlässige Datenübertragung sicherstellt. Es baut auf dem bereits vorhandenen Protokoll TCP auf, welches wiederum über IP und die darunterliegende Netzzugriff-Schicht eine Verbindung herstellen. Durch die Nutzung dieser Elemente entsteht eine zuverlässige Verbindung, über welche die Applikationen kommunizieren können. 13

18 14 Echtzeitkommunikation im Web Abbildung 3.1: Die Kommunikation zwischen dem Client und dem Server mittels HTTP per Request und Response Für die Kommunikation schickt der Client eine Anfrage (Request) mit einer Methode, einem Ziel und der genutzten Protokoll-Version, wie in Abbildung 3.1 zu dargestellt ist. Diese Daten werden als Befehl (Command) in der ersten Zeile der Anfrage gesammelt. Danach folgt der Kopf (Header) der Anfrage, welcher weitere Informationen enthalten kann: was für ein Format wird erwartet, wer schickt die Anfrage und welche Sprache wird bevorzugt. Der Server erhält diesen Request, verarbeitet ihn passend und sendet eine Antwort (Response) zurück. Je nach Art des Servers kann dabei die Antwort aus einer statischen Datei gelesen oder auch dynamisch erstellt werden. Die Antwort enthält in der obersten Zeile zunächst den Status der Antwort ebenfalls mit der genutzten Protokoll-Version sowie mit einem Status-Code und der passenden Status-Nachricht. Danach folgt auch in der Antwort ein Header, in dem weitere Informationen zusammengefasst sind. Mögliche Inhalte des Headers sind das Datum, der Typ und die Länge der Antwort, sowie Informationen über den Server. Zusätzlich zu diesen beiden Bereichen gibt es noch den eigentlichen Inhalt der Antwort: den Body. Hier befindet sich beispielsweise bei der Abfrage einer Internetseite der HTML-Quelltext. 3.2 AJAX Wie man in Abbildung 3.1 erkennen kann, muss zunächst der Client eine Anfrage an den Server schicken, um eine Antwort zu erhalten. Das bedeutet auch, dass nur der Client für eine Aktualisierung des Inhaltes sorgen kann, selbst wenn sich

19 Echtzeitkommunikation im Web 15 serverseitig etwas verändert hat. Dies führt natürlich zu einem Problem, weil viele Web-Applikation mit Live-Daten arbeiten, welche sich ständig aktualisieren können so wird beispielsweise ein Live-Ticker für ein Sportevent ständig mit neuen Daten versorgt, welche dann direkt beim Benutzer angezeigt werden sollen. Eine Möglichkeit wäre das ständige neu Laden der gesamten Seite mit den aktuellen Daten. Dies hat jedoch enorme Nachteile bei der Geschwindigkeit, da die gesamte Datenmenge neu geladen werden muss das schließt beispielsweise auch Bilder mit ein, die sich nicht verändert haben. Ziel ist es jedoch, nur die Daten anzufordern, die sich seit der letzten Aktualisierung verändert haben. Eine Möglichkeit hierfür wird am 18. Februar 2005 von Jesse James Garrett vorgestellt und trägt das Akronym AJAX ( Asynchronous JavaScript and XML ). Diese Technik ermöglicht es, nur bestimmte Daten asynchron vom Server anzufordern und im Client zu aktualisieren. Hierdurch ergibt sich eine neue Möglichkeit, mit der Entwickler nur die Daten laden können, die wirklich aktualisiert werden müssen. Dabei werden die einzelnen Anfragen wiederum vom Client initiiert, aber ohne dass die Seite selbst neu geladen werden muss. Diese Anfrage wird dann ebenfalls über ein HTTP-Request an den Server gesendet, welcher dann eine Response zurückschickt. Die Daten aus dem Body können dann im Client ausgelesen und die Seite passend aktualisiert werden [7]. Durch dieses Vorgehen verringert sich die Menge der benötigten Daten in dem zuvor beschriebenen Szenario (Live-Ticker) massiv, da nur die Informationen übertragen werden, die sich geändert haben. Doch obwohl die Technik sehr innovativ war und die Art der Web-Applikationen massiv erweitert hat, nutzt sie weiterhin HTTP als Kommunikationsweg und ist deshalb auch an die Restriktionen dieses Protokolls gebunden. So muss weiterhin der Client einen Request abschicken, um neue Daten zu erhalten. Zwar funktioniert dies asynchron (der Client muss nicht aktiv auf den Response warten), jedoch kann der Server die Antwort nicht direkt zum Client durchleiten, weshalb der Client im Hintergrund den Status durch zyklisches Abfragen ermitteln muss ( polling ). Somit ist AJAX keine optimale Lösung für Echtzeitanwendungen, auch wenn sie als etablierter Standard und Ausweich-Technologie ( Fallback ) bis heute einen festen Platz in Web-Applikationen einnimmt. Eine erweiterte Form von polling ist das long polling. Auch hier sendet der Client eine Anfrage an den Server, die dieser verarbeitet und direkt beantworten kann. Liegen die angeforderten Informationen noch nicht vor, schickt der Server jedoch keine leere Nachricht zurück, wie es bei HTTP und polling üblich wäre, sondern hält die Verbindung solange offen, bis die passenden Informationen zur Verfügung stehen - erst danach wird eine Antwort zurückgeschickt. Das bedeutet zwar, dass der Server ohne Verzögerung neue Informationen an den Client leiten kann, dafür

20 16 Echtzeitkommunikation im Web aber sehr viele Ressourcen benötigt, da für jede offene Anfrage eine Verbindung gehalten werden muss. 3.3 Websockets Ein großes Problem bei HTTP und AJAX ist, dass für jeden Datenaustausch eine Verbindung aufgebaut werden muss, über welche die beiden Nachrichten geschickt werden. Diese Verbindung ist jedoch nur für ein einmaliges Austauschen der Nachrichten verfügbar und wird danach vom Server geschlossen. Zwar wurde das Problem bereits im Update von HTTP 1.0 auf 1.1 adressiert, indem die Verbindung aktiv gehalten werden kann, jedoch nur für die Daten einer einzigen Anfrage [6]. Will man mehrere unabhängige Daten anfordern, so müssen diese immer über eigene Requests/Repsonses angefragt und geliefert werden. Das bedeutet auch, dass jedes Mal alle Informationen im Header geschickt werden müssen, wodurch ein sehr großer Overhead entsteht, welcher viele redundante und teilweise uninteressante Informationen enthält. Vor allem bei kurzen Nachrichten (weniger als 32 Byte) verursacht der Header ein Vielfaches der Datenmenge, die im Body enthalten ist. Dadurch entsteht ein unnötiger Overhead, welcher besonders in modernen Web- Applikationen eine starke Verlangsamung verursacht. Diese Probleme der unzähligen Verbindungen und der redundanten Header werden seit einigen Jahren von verschiedenen Entwicklerteams behandelt und resultierten 2011 in einem neuen Standard: dem Websocket Protokoll [5]. Wie in Abbildung 3.2 zu erkennen ist, benötigt dieses Protokoll zuerst einen Handshake, welcher vom Client initiiert wird. Dafür sendet dieser eine Nachricht, welche komplett zu HTTP kompatibel ist und somit auf dem gleichen Port laufen kann, an den Server und übergibt einige Parameter für die Verbindung. Zunächst sind das, wie bei HTTP üblich, die angefragte Ressource und der Host. Hinzu kommt dann noch eine Anfrage für die Verwendung des Websocket-Protokolls (Upgrade), das darauf aufbauende eigene Protokoll und die gewünschte Protokoll-Version. Der Server kann dann diese Daten wiederum verarbeiten und sendet, falls das Protokoll unterstützt wird, eine passende Nachricht mit dem Status-Code 101 und einigen Informationen zum Upgrade. Nach diesem Upgrade steht eine Verbindung mit einem Voll-Duplex zur Verfügung, auf welcher sowohl der Client Daten an den Server senden, als auch der Server ohne vorherige Anfragen vom Client direkt eine Nachricht an den Client zustellen kann. Diese Socket-Verbindung sorgt dafür, dass Web-Applikationen ohne Anfrage direkt Daten vom Server beziehen können. Außerdem wird die Verbindung solange offen gehalten, bis eine Seite sie gezielt schließt. Das bedeutet auch, dass nach dem

21 Echtzeitkommunikation im Web 17 Abbildung 3.2: Der Handshake des Websocket Protokolls basiert auf HTTP Request und Response einmaligen Handshake und Upgrade keine weiteren Overheads mehr gesendet werden müssen: alle Nachrichten enthalten nur die Daten, welche die Applikation tatsächlich benötigt. Zwar können nach Anwendungsfall auch Informationen wie Nachrichtentyp oder Topic mit in die Nachricht aufgenommen werden, jedoch sind diese Angaben, im Gegensatz zum Header von HTTP, immer abhängig von der Nachricht selbst und können zwischen einzelnen Nachrichten variieren. Das Websocket Protokoll wird aufgrund dieser Vorteile heutzutage verstärkt in Web-Applikationen genutzt und deshalb auch von sehr vielen Browsern und Server- Technologien unterstützt. So gibt es für alle gängigen Programmiersprachen eigene Bibliotheken, mit denen das Aufsetzen eines Servers erleichtert wird. Eine der verbreitetsten Umgebungen für Web-Applikationen ist dabei node.js auf Basis von JavaScript, welches über verschiedenste Erweiterungen nicht nur als HTTP-Server sondern auch als Websocket-Server bertrieben werden kann. Dabei reichen die einzelnen Erweiterungen von einer einfachen Serverumgebung, welche nur das Websocket Protokoll unterstützen und die einzelnen Nachrichten pur, also komplett ohne Overhead, verschicken, bis hin zu Lösungen für Server- und Clientseite. Letztere liefern dabei auch Unterstützung für ältere Browser, wie ein Fallback auf AJAX und Long-Polling. Eine bekannte Erweiterung ist socket.io 1, welche außer für node.js 2 auch für andere Programmierumgebungen zur Verfügung steht und das Erstellen von Echtzeit-Applikation für das Web nochmals vereinfacht. Mittlerweile hat sich das Websocket-Protokoll jedoch so weit verbreitet, dass fast JavaScript Bibliothek für Entwicklung von Netzwerk-Applikationen;

22 18 Echtzeitkommunikation im Web alle aktuellen Browser diese Verbindungsart unterstützen. Lediglich der Android Standard Browser und Opera Mini verweigern in der aktuellen Version noch die Zusammenarbeit. Eine genauere Übersicht über die Unterstützung durch die einzelnen Browser ist in Tabelle 3.1 zu erkennen. IE Firefox Chrome Safari Opera ios Safari Opera Mini Android Blackberry Opera Mobile Chrome Mobile Firefox Android Tabelle 3.1: Unterstützung des Websocket-Protokolls durch einzelne Browser (aktuelle Version zuletzt). Grün = unterstützt, gelb = teilweise unterstützt, rot = nicht unterstützt [4] 3.4 WebRTC Obwohl das Websocket Protokoll bereits viele Lösungen für die Echtzeitkommunikation im Web-Kontext bereitstellt, eine Vielzahl von Verbesserungen gegenüber anderen Technologien liefert und stetig ausgebaut wird, gibt es bereits neue Ansätze, mit denen man die Echtzeitkommunikation im Web-Kontext verbessern will. Eine Arbeitsgruppe um das World Wide Web Consortium (W3C) und die Internet Engineering Task Force (IETF) arbeitet derzeit an Web Real-Time Communication, kurz WebRTC. Nach dieser Technologie soll, im Gegensatz zu Websockets und HTTP, die Web-Applikation nicht über einen Server, sondern direkt zwischen zwei oder mehr Browsern kommunizieren. Die dadurch geschaffenen Peer-to-Peer-Verbindungen sollen dabei um ein Vielfaches schneller sein als der Umweg über einen Server [10]. Eine Möglichkeit für die Verbindung ist ein Dreieck, bestehend aus einem Server, welcher für die Vermittlung verantwortlich ist, und zwei Clients, welche dann einen oder mehrere Daten-Streams untereinander aufbauen und darüber kommunizieren können, wie in Abbildung 3.3 zu sehen ist. Ziel der Entwickler ist es außerdem, nicht nur einfache Daten verschicken zu können, sondern ebenfalls eine API zum Auslesen von Medienquellen (Kamera, Mikrofon) zur Verfügung zu stellen, mit deren Hilfe Entwickler Audio und Video auslesen und über eigene Streams versenden können. So verwundert es auch nicht, dass die erste

23 Echtzeitkommunikation im Web 19 Abbildung 3.3: Durch WebRTC wird die Verbindung von dem Server nur vermittelt, die Kommunikation erfolgt direkt zwischen den beiden Clients mit Hilfe von Daten- Streams [10] große Demonstration der Technologie einen Live-Video-Chat á la Skype 3 zwischen zwei Personen zeigt, wobei die Besonderheit darin liegt, dass alles direkt über den Browser zur Verfügung gestellt wird. Ziel der Entwickler ist es außerdem, einen Standard zu schaffen, welcher über verschiedene Client- und Servertypen hinweg sogar einfache Telefonanlagen mit Computern verbinden können soll. Jedoch ist das größte Problem an der Technologie heutzutage, dass sie sich noch in der Entwicklung befindet und frühestens Ende 2013 in einer ersten Version offiziell erscheint. Bis dahin gibt es nur Empfehlungen für die Nutzung der verschiedenen Komponenten, welche beispielsweise zwischen den einzelnen Browsern sehr unterschiedlich sind und daher dafür sorgen, dass Mozilla Firefox und Google Chrome unterschiedliche Implementierungen benötigen, um miteinander kommunizieren zu können. Allgemein gibt es derzeit nur wenige unterstützende Browser: Mozilla Firefox ab der aktuellen Version 23.0 und Google Chrome ab Version 25.0, außerdem unterstützt die Beta des mobilen Browsers Google Chrome in der Version 29.0 bereits als erstes WebRTC auf mobilen Geräten. Dennoch ist es noch ein weiter Weg, bis eine Abdeckung erreicht wird, wie sie das Websocket-Protokoll bereits hat. Ein weiterer aktueller Nachteil ist, dass der Verbindungsaufbau zwischen zwei Clients noch sehr viele Anpassungen benötigt, damit es zu keinen Problemen kommt. Für etwas Abhilfe sorgt hier eine erste Bibliothek: PeerJS 4. Diese Bibliothek unter

24 20 Echtzeitkommunikation im Web stützt die Vermittlung der Verbindung und fügt die APIs von Mozilla Firefox und Google Chrome so zusammen, dass man für beide Browser einheitliche Befehle nutzen kann, wodurch Entwickler stark entlastet werden. Dennoch bleibt festzuhalten, dass diese Technologie im aktuellen Zustand noch zu große Probleme aufweist und somit nur bedingt genutzt werden kann. Jedoch soll diese Technologie trotzdem für diese Arbeit berücksichtigt und getestet werden, da die zukünftigen Aussichten und die Möglichkeiten, welche diese Technologie liefern könnte, beeindruckend sind und einen weiteren, sehr wichtigen Schritt in der Entwicklung des Web darstellen können. 3.5 Vergleich Websockets, Socket.IO & WebRTC Nachdem geklärt ist, welche Technologien aktuell zur Umsetzung von Echtzeitkommunikationen im Web zur Verfügung stehen, soll nun noch überprüft werden, welche Vorteile und Nachteile die jeweiligen Alternativen bieten. Zum einen soll vor allem die Latenz der Verbindungsarten durch die Round-Trip-Time ermittelt werden, da dies der wichtigste Faktor für die verzögerungsfreie Kommunikation ist. Die Round-Trip-Time (RTT) misst dabei die Zeit, welche ein Paket vom Client zum Server und wieder zurück braucht. Jedoch spielen auch die Übertragungsgeschwindigkeit, die Zuverlässigkeit und die Implementierung eine wichtige Rolle. Websockets sind mittlerweile sehr weit verbreitet und haben dadurch, wie bereits erwähnt, sehr viele verschiedene Implementierungen zu bieten, welche verschiedene Szenarien abdecken. Eine einfache Bibliothek stellt dabei WebSocket Node von Brian McKelvey bereit, welches serverseitig die aktuellen Websocket Protokolle umsetzt [11]. Eine mächtigere Alternative stellt Socket.IO dar, welches neben dem eigentlichen Websocket Protokoll auch andere Technologien wie AJAX als Fallback nutzt und diese sowohl auf Server- als auch auf Client-Seite passend implementiert zur Verfügung stellt[13]. Dieses Komplettpaket bietet viele Erweiterungen im Vergleich zum eigentlichen Websocket- Protokoll und sichert vor allem die Verwendung in älteren Browsern ab, welche noch keine Websockets unterstützen. Bei WebRTC hingegen gibt es nur die bereits erwähnte Bibliothek PeerJS, welche, bedingt durch den Entwicklungsstand von WebRTC an sich, nur wenige Funktionalitäten bereitstellt [3]. Die Implementierung bei Websockets ist im Allgemeinen durch die verschiedenen Bibliotheken schnell abgeschlossen. Bei beiden Implementierungen basieren serverseitig die Websocket-Verbindungen zunächst auf einem HTTP-Server, welcher standardmäßig von node.js unterstützt wird. Auf diesem Server wird dann ein Websocket-Server aufgesetzt, welcher auf dem gleichen Port lauscht und eingehende

25 Echtzeitkommunikation im Web 21 Ereignisse an die jeweiligen Listener weiterleitet. Dafür warten beide Implementierungen auf eingehende Verbindungen und liefern im passenden Listener den Socket mit, welcher dann gespeichert und genutzt werden kann. Auf diesem Socket werden dann weitere Listener angemeldet, welche dann ein Verbindungsende abfangen und ankommende Nachrichten je nach Nachrichtentyp verwalten können. Das Verschicken von Nachrichten wird ebenfalls über die einzelnen Sockets ausgeführt, indem die Senden-Methode für jeden Socket aufgerufen wird. Clientseitig setzt Websocket Node auf die Standardimplementierung von Websockets, während SocketIO eine eigene Bibliothek mitliefert, die neben den Fallbacks auch einige Vereinfachungen für Websockets bereithält. Dennoch arbeiten beide Implementierungen nach demselben Prinzip: Es wird eine Verbindung zu einem bestimmten Server mit Adresse und Port geöffnet, welche dann ebenfalls über vorgegebene Listener Ereignisse abfangen und verarbeiten kann. Auch das Versenden von Nachrichten ist mit einem Methodenaufruf auf den Socket zu erledigen. Beide Seiten der Verbindung sorgen dafür, dass die gesamte Kommunikation mit Websockets sehr einfach zu implementieren ist. Bei WebRTC mit PeerJS benötigt man ebenfalls zunächst einen Server, welcher die Verbindung zwischen den beiden Clients austauscht. Dieser Server basiert ebenfalls auf node.js und ist durch einen zweizeiligen Code aufgesetzt. Die Clients benötigen dann die Adresse und den Port des Servers und verbinden sich mit diesen Daten auf den Server. Wie bereits erwähnt, muss dabei ein Client einen Peer-Server mit einer einmaligen ID erstellen, auf den sich der andere Client dann verbinden kann. Hierbei fehlt aber ein Austausch der einzelnen IDs, wodurch man bereits vor dem Verbindungsaufbau die IDs fest hinterlegen muss. Auch die Kommunikation über die aufgebaute Peer-to-Peer-Verbindung ist in der aktuellen Version dürftig, da es nur einen unverlässlichen Nachrichtentyp gibt. Insgesamt ist die Struktur noch sehr starr, was aber zweifellos an dem aktuellen Entwicklungsstand von WebRTC liegt. Neben der Implementierung und den dabei entstehenden Problemen ist vor allem die Übertragungsgeschwindigkeit von essentiellem Interesse, da diese maßgeblich dafür verantwortlich ist, ob die Applikation in Echtzeit abläuft. Zwar spielen auch Faktoren wie die Implementierung der eigentlichen Spiele-Logik eine große Rolle, jedoch ist dies vom eigentlichen Netzwerk-Bereich abgekapselt und stellt eine eigene Thematik dar. Für die Untersuchung der Geschwindigkeit soll also nur die Übertragungsgeschwindigkeit erfolgen, wobei hier die RTT entscheidend ist. Für diesen Test wird eine Nachricht vom Client an den Server gesendet und von diesem sofort wieder zurückgeschickt - ein solcher Server wird auch Echo-Server genannt. Bei WebRTC dient ein Client als Server und schickt ebenfalls einkommende Nachrichten direkt wieder zurück. Damit man dabei feststellen kann, wie lange die Nachricht unterwegs war, beginnt jede Nachricht mit einem Zeitstempel mit der

26 22 Echtzeitkommunikation im Web aktuellen UNIX-Systemzeit, also der Zeit seit dem 1. Januar :00 Uhr UTC. Dieser Zeitstempel liefert eine auf die Millisekunde genaue Zeitangabe, welche dann vom Client wieder gelesen und mit dem aktuellen Zeitstempel verrechnet werden kann. Daraus ergibt sich dann die RTT für diese Nachricht. Um außerdem eine bessere Übersicht über die Übertragungsgeschwindigkeit abhängig von der Nachrichtengröße zu erhalten, variiert die Nachrichtengröße von 2 5 bis 2 14 Byte. Pro Nachrichtengröße werden dabei jeweils Nachrichten verschickt und zum Schluss gemittelt, um so eine bessere Aussagekraft zu erzielen. Außerdem werden die Tests sowohl im Intranet über WLAN und Kabel durchgeführt, als auch über einen Server im Internet auch hier wurden die Werte gemittelt. Insgesamt wurden dreimal drei Tests mit 10 Runden und Schritten durchgeführt. Die gesammelten Ergebnisse sind im Abbildung 3.4 zu erkennen. Dabei fällt auf, dass bei kleineren Nachrichtengrößen sowohl die pure Implementierung der Websockets, wie auch SocketIO ähnliche Laufzeiten haben. Bei größeren Datenmengen hingegen benötigt SocketIO etwas mehr Zeit als Websockets selbst. Dies könnte sowohl durch die komplexeren Serverstrukturen als auch durch den Overhead entstehen, den SocketIO anhängt. Dennoch sind beide Technologien derzeit deutlich schneller als die Datenübertragung mittels PeerJS basierend auf WebRTC. Hinzu kommt, dass PeerJS Probleme mit Nachrichten ab 512 Byte hat und im durchgeführten Test abstürzt. Aus diesem Grund sind nur die Messwerte bis einschließlich 512 Byte gelistet. Abbildung 3.4: Untersuchungen der Round-Trip-Time (RTT) mit verschiedene Nachrichtengrößen für Websockets, SocketIO und WebRTC mit PeerJS

27 Echtzeitkommunikation im Web 23 Der deutliche Geschwindigkeitsunterschied zwischen Websockets und WebRTC könnte dadurch erklärt werden, dass WebRTC in der aktuellen Version noch keine Kommunikation per TCP beherrscht und somit auf UDP zurückgreifen muss. Damit jedoch keine Nachrichten verloren gehen, wird die Zustellung nicht von der Transport- sondern von der Anwendungsschicht, in diesem Fall WebRTC, sichergestellt. Dies kann zu längeren Übertragungs- und Verarbeitungszeiten führen. 3.6 Zusammenfassung Zum Zeitpunkt der Untersuchungen war klar zu erkennen, dass WebRTC zwar ein sehr großes Ziel verfolgt, dieses jedoch noch lange nicht erreicht hat. Die Umsetzung der Audio- und Video-Streams ist bereits sehr gut umgesetzt und funktioniert sowohl bei Mozilla Firefox wie auch bei Google Chrome in einer sehr guten Qualität und Geschwindigkeit Medien-Streams können also bereits auf die neue Technologie setzen. Die unfertigen Standards bei den anderen Datenverbindungen sorgen jedoch dafür, dass die Verbindungsgeschwindigkeit von WebRTC derzeit noch klar von Websockets geschlagen wird. Auch führen die offenen Richtlinien dazu, dass man Applikation häufig umschreiben und neu gestalten muss. Das Websocket-Protokoll hatte bereits viel Zeit, sich zu etablieren und hat das auch getan. Es gibt eine Vielzahl von verschiedenen Implementierungen, welche je nach Anwendungsfall mit immer mehr Funktionalitäten aufwarten. Auch das Management der Verbindungen und die eigentliche Kommunikation sind viel ausgereifter. Deshalb sind Websockets zum aktuellen Stand der klare Favorit, wenn es um Echtzeitkommunikation im Web geht.

28 24 Echtzeitkommunikation im Web

29 Kapitel 4 Anforderungsanalyse Um von der Spielmechanik zur Umsetzung zu gelangen, müssen die einzelnen Ideen und Regeln zusammengefasst und analysiert werden. Dazu dient die Anforderungsanalyse, welche als eine erste Abstraktion der Spielidee die spätere Implementierung vorbereiten soll. Hierzu werden zunächst die möglichen Benutzerinteraktionen und deren Folgen ausgewertet und zusammengefasst. Danach werden daraus mögliche Spielelemente konstruiert, welche eine Grundlage für die späteren Objekte in der Implementierung bilden. Danach soll auch die benötige Infrastruktur für die Kommunikation und deren Schnittstellen behandelt werden. Zuletzt sollen auch noch die nicht-funktionalen Anforderungen bezüglich der Kommunikation in Echtzeit und der Kompatibilität behandelt werden. 4.1 Benutzerinteraktionen Beim Auswerten des Spielkonzeptes fällt auf, dass der Benutzer sich zunächst in drei verschiedenen Bereichen bewegen kann. Direkt nach dem Starten der Applikation gelangt er in das Hauptmenü und hat hier die Interaktionsmöglichkeiten aus Abbildung 4.1 zur Verfügung. Der Benutzer kann hier seinen Benutzernamen wählen, welcher dann im weiteren Spielverlauf für ihn genutzt wird. Diese Möglichkeit hat er jederzeit im Hauptmenü. Des Weiteren kann der Benutzer alle aktiven Spiellobbys sehen, welche vom System geladen werden müssen. Um immer aktuelle Daten zur Verfügung zu haben, wird die Lobby-Liste immer automatisch aktualisiert, wenn es eine Änderung bei den Spiellobbys im System gibt. Aus dieser Liste kann der Benutzer sich dann ein Element aussuchen und dieser Lobby beitreten. Er gelangt dann als einfacher Benutzer in die Spiellobby. Jedoch kann er auch eine eigene Spiellobby erstellen und gelangt direkt in die neu erstellte Lobby dieses Mal jedoch als Lobby-Ersteller. 25

30 26 Anforderungsanalyse Abbildung 4.1: Im Hauptmenü können die Benutzer ihren Namen festlegen und in eine Spiellobby wechseln Die Spiellobby ist der zweite Bereich der Applikation, in dem alle Benutzer gesammelt werden, bevor das eigentliche Spiel beginnt. Wie bereits im Abschnitt 2.2 beschrieben und in Abbildung 4.2 zu erkennen ist, gibt es zwei Arten von Benutzern, wobei der Lobby-Ersteller einige Privilegien im Vergleich zum normalen Benutzer hat. Zunächst können beide Benutzertypen die Spiellobby wieder verlassen und gelangen dann ins Hauptmenü. Verlässt jedoch der Ersteller seine eigene Lobby, so wird diese geschlossen und alle Benutzer werden in das Hauptmenü geleitet. Um einen Überblick über die bereits verbundenen Teilnehmer zu haben, können alle Benutzer diese in einer Liste sehen. Dabei hat der Ersteller der Lobby hier die Möglichkeit, Benutzer zu entfernen, wodurch diese wieder im Hauptmenü landen. Ist der Ersteller mit der Liste der Teilnehmer zufrieden, kann er das Spiel starten und alle Benutzer dieser Lobby gelangen zum Spiel. Abbildung 4.2: Die Spiellobby stellt je nach Benutzertyp verschiedene Möglichkeiten bereit und kann entweder in Richtung Hauptmenü verlassen werden oder ins Spiel übergehen

31 Anforderungsanalyse 27 Das Spiel selbst lässt sich wiederum in drei Handlungsstränge unterteilen, welche in Abbildung 4.3 zu sehen sind. Zunächst können die Benutzer Kugeln verschießen und somit bestimmte Aktionen auslösen und Extras sammeln. Dann haben sie die Möglichkeit die gesammelten Extras einzusetzen und somit das Spiel zu beeinflussen. Dies führt letztendlich dazu, dass Benutzer verlieren können und am Ende nur noch ein Gewinner übrig bleibt. Abbildung 4.3: Das Spiel besteht aus drei Bereichen: Abschießen der Kugel, Benutzen von Extras und Spielende Wie bereits in Kapitel 2.1 beschrieben, besteht der eigentliche Spielablauf aus dem Abschießen und Abbauen von Kugeln. Dies ist in Abbildung 4.4 zu erkennen. Der Benutzer kann dafür zunächst eine Kugel in das Spielfeld abschießen, welche dann in die Richtung des Mauszeigers losfliegt und solange an den Banden abprallt, bis sie an eine Kugelgruppe oder den oberen Spielfeldrand andockt. Wenn das geschieht, wird zunächst überprüft, ob das Spielfeld überfüllt ist, die Kugel also unterhalb der 15. Kugelreihe angedockt ist. Falls dies der Fall sein sollte, hat der Spieler das aktuelle Spiel verloren. Andernfalls wird die Kugelgruppe, an welche die neue Kugel angedockt ist, überprüft. Befinden sich hier mindestens noch zwei andere Kugeln mit der gleichen Farbe, wird diese gesamte Kugelgruppe entfernt. Ebenfalls werden alle an diese Kugelgruppe angrenzenden Extras entfernt und dem Inventar angefügt. Werden dabei mehr als fünf Kugeln entfernt, erscheint auf dem Spielfeld ein neues Extra. Falls jedoch keine Kugelgruppe abgebaut wird, muss eine Kugel aus dem Kugelvorrat entfernt werden. Ist dieser Vorrat aufgebraucht, wird außerdem eine neue Reihe von Kugeln angefügt. Hierbei kann es ebenfalls passieren, dass das Spielfeld überfüllt wird und der Spieler verliert. Bleibt das Spielfeld aber innerhalb der 15 vorhandenen Zeilen, so wird der Kugelvorrat wieder aufgefüllt. Falls das Spiel nicht vorbei ist, erhält der Spieler eine neue Kugel und kann mit dieser weiterspielen.

32 28 Anforderungsanalyse Abbildung 4.4: Das Abschießen einer Kugel kann viele verschiedene Aktionen auslösen

33 Anforderungsanalyse 29 Hat der Benutzer durch das Abbauen von Kugelgruppen Extras in seinem Inventar gesammelt, kann er diese Extras benutzen. Dazu stehen ihm die Möglichkeiten aus Abbildung 4.5 zur Verfügung. Zunächst kann der Benutzer zu jeder Zeit sein Inventar mit den aktuellen Extras sehen und somit erkennen, welches Extra er als nächstes nutzen kann. Dieses nächste Extra kann er dann auf sich selbst oder einen anderen Mitspieler anwenden. Das hat zur Folge, dass das benutzte Extra aus dem Inventar entfernt wird und sich die Anzeige aktualisiert. Extras mit einer Wirkdauer werden dem jeweiligen Benutzer dann ebenfalls angezeigt, um den Benutzer darüber zu informieren. Damit die einzelnen Spieler eine Vorstellung davon haben, wie der Spielstand bei den anderen Mitspielern aussieht, können sie neben ihrem eigenen Spielfeld auch die Spielfelder der anderen Teilnehmer sehen. Abbildung 4.5: Der Spieler kann sein Inventar sehen und Extras daraus benutzen. Außerdem hat er auch eine Übersicht über seine aktuell aktiven Extras und alle Spielfelder Bei der Benutzung von Extras kann es auch dazu kommen, dass das Spielfeld eines Spielers überfüllt wird. In diesem Fall hat der Spieler, wie auch beim Überfüllen des Feldes durch eine eigene Aktion, das Spiel verloren. In beiden Fällen wird das Spielfeld geräumt und der Benutzer kann das Spiel nur noch verlassen. Sobald der vorletzte Mitspieler sein Spielfeld überfüllt, gewinnt der verbleibende Spieler das aktuelle Spiel. Außerdem steht es jedem Mitspieler zu jedem Zeitpunkt frei, das Spiel zu verlassen. Hier werden alle Spieler, also auch der frühere Lobby-Ersteller, gleichbehandelt: verlässt ein Spieler das Spiel, so gelangt er in das Hauptmenü und sein Spielfeld wird geräumt, genauso als hätte er verloren. Diese Use-Cases stellen die Interaktionen des Benutzers dar und schaffen einen Überblick darüber, welche Eingaben der Benutzer tätigen kann, zu welchen Reaktionen es dann jeweils kommt und welche Zustände unterschieden werden können.

34 30 Anforderungsanalyse 4.2 Spielelemente Die möglichen Interaktionen des Benutzers ergeben neben den Use-Cases auch eine erste Übersicht über die Elemente und Objekte der Applikation. Diese Elemente repräsentieren teilweise reale Objekte aus der natürlichen Welt, wie die einzelnen Benutzer, aber auch Applikationselemente, wie beispielsweise Spiellobbys und Kugeln. Da diese Objekte die spätere Applikationswelt darstellen, müssen sie aus der Spielmechanik und den Use-Cases aus Kapitel 4.1 extrahiert und passend verbunden werden. Aus diesen Vorlagen entsteht das Domänenmodell in Abbildung 4.6, welches als Grundlage für die späteren Objekte und Daten in der Applikation dienen soll. Im Mittelpunkt der Applikation steht der Benutzer, welcher die anderen Elemente manipulieren kann. Deshalb wird der Benutzer im Domänenmodell ebenfalls im Zentrum positioniert und hat Verbindungen zu fast allen anderen Objekten. Er wird repräsentiert durch einen Benutzernamen. Im Hauptmenü sieht er zunächst die Spiellobby-Liste. Diese Liste besteht aus allen aktuell aktiven Spiellobbys im System und steht allen Benutzern im Hauptmenü zur Verfügung. Aus dieser Liste kann jeder Benutzer ein Element auswählen und diesem beitreten, wodurch die Spiellobby einen weiteren Benutzer aufnimmt. Insgesamt können sich bis zu neun Spieler in einer Lobby befinden, jeder Benutzer jedoch in maximal einer gleichzeitig. Außerdem kann jeder Benutzer maximal eine Spiellobby erstellen, wodurch dieser zu einem Ersteller wird. Dieser kann dann die Spiellobby in ein Spiel überführen, wodurch alle Benutzer und der Ersteller der Lobby zu Spielern werden. Im Spiel erhält jeder Spieler weitere Elemente, welche nur im Spielkontext relevant sind, weshalb der Spieler beim Verlassen des Spiels wieder zu einem Benutzer wird. Jeder Spieler hat ein Spielfeld, welches je nach festgelegter Größe aus beliebig vielen Kugeln bestehen kann. Diese Kugeln haben eine bestimmte Farbe, die für das Abbauen von Kugelgruppen von Bedeutung ist. Jede Kugel kann von einem Benutzer verschossen werden, jedoch können Kugeln auch direkt auf dem Spielfeld auftauchen. Kugeln, die vom Benutzer verschossen werden können, werden im Kugelvorrat gesammelt. Dabei besteht dieser aus maximal fünf Kugeln gleichzeitig, wobei mit jedem Schuss ohne entfernte Kugelgruppe jeweils eine Kugel daraus entfernt wird. Jeder Spieler hat genau einen Vorrat, welcher auch nur diesem Spieler gehört und beliebig oft aufgefüllt werden kann. Neben den normalen Kugeln besteht das Spielfeld auch aus beliebig vielen Extras, welche einen bestimmten Typ haben, der mit einer Aktion verbunden ist. Dabei kann jedes Extra entweder auf dem Spielfeld liegen, bei einem Benutzer aktiv sein

35 Anforderungsanalyse 31 oder sich im Inventar eines Benutzers befinden. Jeder Benutzer kann beliebig viele aktive Extras haben, wobei jedoch jedes Extra auf nur einen Benutzer angewendet werden kann. Dabei kann das Extra auch einmalig auf das Spielfeld des jeweiligen Benutzers wirken und dieses manipulieren. Bevor das Extra angewandt werden kann, befindet es sich im Inventar eines Spielers, welches auch nur von diesem Spieler benutzt werden kann. Das Inventar selbst kann beliebig viele eingesammelte Extras sequentiell halten und stellt dem Benutzer immer das älteste davon zur Verfügung. Abbildung 4.6: Objekte des Spiels als Domänenmodell mit den Spielbereichen oben, darunter den Benutzertypen und den Spielelementen

36 32 Anforderungsanalyse 4.3 Echtzeit Die Anforderungen an die Applikation beschränken sich natürlich nicht nur funktional. Es existieren auch einige nicht-funktionale Anforderungen, welche ebenfalls beachtet werden müssen. Eine dieser Anforderungen steckt bereits im Namen der Arbeit: die Echtzeit. Der Benutzer soll Eingaben tätigen können, die dann von der Applikation verarbeitet werden und ein bestimmtes Feedback liefern. Diese drei Bestandteile sollen dabei in Echtzeit ablaufen. Zunächst muss dazu geklärt werden, was Echtzeit bedeutet. Hierzu gibt es verschiedene Ansichten und Definitionen, die sich teilweise überschneiden: Eine definierte Aktion im System muss für den Betrachter in einer garantierten Zeit simultan zu der gleichen Aktion in der realen Welt ablaufen. So muss beispielsweise ein Video genauso schnell abgespielt werden, wie es auch aufgenommen wurde, um das Kriterium der Echtzeit zu erfüllen. [9] Für den hier vorgestellten Fall muss diese Definition jedoch erweitert werden, da es keinen direkten Vergleich für die Kommunikation im Internet in der realen Welt gibt. Die Zeitspanne muss also anders festgelegt werden. Hierfür muss man die Erwartungen des Benutzers heranziehen. Dieser löst eine bestimmte Aktion aus und erwartet ein sofortiges Feedback vom System. Die Zeitspanne für die Verarbeitung und Ausgabe der Daten wird hierbei nach der Flimmerverschmelzungsfrequenz (FVF) bestimmt. Diese besagt, dass ab einer bestimmten Wiederholfrequenz zwei aufeinanderfolgende Reize nicht mehr separat, sondern simultan wahrgenommen werden quasi verschmelzen [15]. Eine der bekanntesten Anwendungen ist dabei der Film: Hier werden einzelne Bilder so schnell ausgewechselt, dass Auge und Gehirn diese als Bewegung interpretieren. Dieses Medium soll auch als Grundlage für die Festlegung der Zeitspanne dienen. Basierend auf den aktuellen Standards bei Film und Fernsehen variiert die Anzahl der Bilder pro Sekunde zwischen 24 (Kino) und 30 (Fernsehen, NTSC 1 ). Das bedeutet, dass zwischen einer Benutzerinteraktion und der Anzeige des daraus resultierenden Ergebnisses maximal 33 Millisekunden vergehen dürfen. Dies schließt im Netzwerkbetrieb auch die Dauer für die Übertragung einer Nachricht mit ein. 4.4 Kompatibilität Eine weitere nicht-funktionale Anforderung der Applikation ist die Kompatibilität mit verschiedenen Systemen, auf welchen sie lauffähig sein soll. Es soll eine Übertragbarkeit sichergestellt werden, die möglichst vielen Benutzern auf unter- 1 Fernsehsystem für Farbübertragung nach dem National Television Systems Committee, USA

37 Anforderungsanalyse 33 schiedlichen Endsystemen die Möglichkeit liefert, die Applikation in vollem Umfang parallel benutzen zu können. Dies soll durch die Nutzung von Technologien und Frameworks sichergestellt werden, welche möglichst viele Systeme abdecken. Da die Applikation in zwei Bereiche, Server und Client, aufgeteilt ist, müssen diese beiden Systeme bezüglich der Kompatibilität separat betrachtet werden. Bei der Betrachtung dieser Komponenten fällt auf, dass auf einem Server immer beliebig viele Clients arbeiten können es gibt also tendenziell mehr Clients als Server. Das bedeutet auch, dass ein Server ein starres Element ist, welches auf einem bestimmten System gestartet wird und auf diesem langfristig laufen kann, während die Clients viel kurzlebiger sind und sich ständig austauschen können. Daraus folgt, dass der Serverpart nicht auf jedem beliebigen System lauffähig sein muss - es soll ausreichen, wenn er auf einem passend vorbereiteten System ausgeführt werden kann. Die Clients hingegen müssen auf möglichst allen Systemen vollständig lauffähig sein. Um dies zu erreichen, werden diese in eine Website eingebettet und somit von einem Browser abgespielt. Durch die Nutzung von gängigen Webtechnologien wird sichergestellt, dass alles standardkonformen Browser die Applikation in vollem Umfang darstellen können. Jedoch gibt es tendenziell auch Bestandteile der Applikation, die noch nicht als verbreiteter Standard in allen Browsern identisch implementiert wurden. Um testen zu können, welche Technologien auf möglichst vielen Systemen lauffähig sind, muss zunächst analysiert werden, welche Browser aktuell wie stark auf dem Markt vertreten sind. Dazu soll eine Statistik zur Browsernutzung vom August 2013 herangezogen werden, welche in Abbildung 4.7 dargestellt wird. Die hier präsentierten Daten basieren auf Seitenaufrufen von verschiedenen Benutzern unterschiedlicher Webseiten ohne Beachtung der jeweiligen Platformen. Dabei findet auch keine Gewichtung statt. Insgesamt sind die Daten zwar nicht repräsentativ, sie geben jedoch eine ausreichende Vorstellung von der aktuellen Marktverteilung. Abbildung 4.7: Statistik zur Browsernutzung vom August 2013, Desktop & mobil [14]

38 34 Anforderungsanalyse Basierend auf diesen Daten müssen die Desktop-Browser Google Chrome ab Version 28, Microsoft Internet Explorer ab Version 8, Mozilla Firefox ab Version 22, Apple Safari ab Version 6 und Opera ab Version 12.1 von den genutzten Technologien unterstützt werden. Durch die immer stärker werdende Nutzung von Smartphones und Tablets ergibt sich im Moment ein Marktanteil von 18% bei Seitenaufrufen [14]. Daher müssen auch die Browser auf diesen mobilen Systemen berücksichtigt werden, dazu gehören Apple Safari ab ios 6, der Android Browser ab Android 2.3 und Google Chrome ab Version 28.

39 Kapitel 5 Konzept Die verschiedenen erhobenen Anforderungen zeigen auf, welche Elemente die Implementierung beinhalten soll, wie sie miteinander verbunden sind und vor allem, wie der Benutzer mit ihnen interagieren kann. Nun gilt es diese gesammelten Anforderungen in ein Konzept zu fassen und für die Implementierung vorzubereiten. Zunächst soll dazu eine vereinfachte Übersicht über die gesamte Applikation gegeben werden, bevor es anschließend detailliert in die einzelnen Bereiche geht. Da die Applikation über ein Netzwerk auf einen Server und mehrere Clients verteilt werden soll, wird als nächstes dargestellt, wie die einzelnen Daten über das Netzwerk vom Server zu den einzelnen Clients und wieder zurück transportiert werden, wie diese Schnittstelle erweiterbar bleibt und welche Optimierungen dabei berücksichtigt werden müssen. Diese abstrahierte Netzwerk-Schnittstelle ist dann die Zwischenschicht für die eigentliche Spiellogik, welche über die Bereiche Server und Client verteilt ist. Hierzu soll zunächst die serverseitige Spiellogik mit allen benötigten Objekten, Zuständen und Abhängigkeiten modelliert werden. Danach wird dargestellt, wie die einzelnen Clients an diese Elemente angebunden werden. Als letztes sollen dann noch die verschiedenen Aktionen der Benutzer von der Eingabe über die Verarbeitung bis zur Ausgabe dargestellt werden. 5.1 Gesamtüberblick Die hier vorgestellte Applikation verteilt sich über die Bereiche Server, Netzwerk und Clients. Die dabei benötigten Klassen und ihre bestehenden Abhängigkeiten sind in Abbildung 5.1 dargestellt. In dieser Darstellung werden diese drei Bereiche nochmals anders aufgeteilt: Die Clients bestehen hier aus einer Anzeigelogik, einem Zwischenspeicher und der GUI. 35

40 36 Konzept Abbildung 5.1: Vereinfachte Übersicht über die Objekte der Applikation und deren Abhängigkeiten und Kommunikationswege

41 Konzept 37 Die GUI startet clientseitig zuerst und ist für die Anzeige von Informationen in den einzelnen Elementen zuständig. Diese Informationen befinden sich im Zwischenspeicher der Clients, welcher durch die Anzeigelogik verwaltet wird. Hierzu erhält diese Schicht neue Daten über einen Listener von der Netzwerkschicht und speichert diese Daten im Zwischenspeicher. Als nächstes benachrichtigt die Logik ebenfalls über einen Listener das GUI-Objekt über die Art der Veränderung, woraufhin sich das GUI-Objekt die jeweiligen Daten abholt und darstellt. Die Netzwerkschicht besteht in diesem vereinfachten Fall aus nur einem Objekt, welches genau einen Server mit beliebig vielen Clients verbindet. Dabei wird diese Schicht von außen direkt angesprochen und signalisiert Aktualisierung an den Server beziehungsweise an die Clients über zuvor registrierte Listener. Hierbei werden der Typ der Aktion und die benötigten Daten an die verarbeitenden Klassen übergeben, dort verarbeitet und dem passenden Callback zugewiesen. Der Server beinhaltet die eigentliche Logik der Applikation und startet unabhängig von den Clients. Auch hier kommen neue Informationen über die Netzwerkschicht von den Clients an, werden jedoch nicht nur abgespeichert, sondern manipulieren die verschiedenen Objekte der Applikation. Hierbei gibt es zunächst die Benutzer- Objekte, welche die einzelnen Clients darstellen. Diese können Spiellobby-Objekte erstellen und diesen beitreten, was ebenfalls durch das Backend-Objekt gesteuert wird. Der Ersteller kann dann die Lobby in das Spiel überführen, woraufhin die einzelnen Benutzer-Objekte ein Spielfeld und ein Inventar erhalten und mit diesen dann am Spiel teilnehmen. All diese Informationen werden immer durch Eingaben der Benutzer in die Clients erzeugt, über die Netzwerkschicht zum Server geleitet und hier verarbeitet. Die aktualisierten Objekte und Daten werden dann wieder über die Netzwerkschicht entweder an alle oder nur an bestimmte, einzelne Clients geschickt und sorgen dort für eine Aktualisierung der Anzeige. 5.2 Netzwerkkommunikation Da diese Arbeit von der Entwicklung einer verteilten Applikation handelt, soll zunächst diese Nahtstelle zwischen den einzelnen Clients und dem Server beschrieben werden. Dabei sollen die verschiedenen Daten, welche auf dem Server vorliegen, von den einzelnen Clients manipuliert werden können. Dazu können die Benutzer verschiedene Aktionen ausführen, wodurch die Clients Nachrichten an den Server verschicken, welche dieser dann passend interpretieren und verarbeiten muss. Die daraus entstehenden neuen Informationen müssen dann ebenfalls über das Netzwerk zu den einzelnen Clients gelangen und auch dort passend verarbeitet und dann dargestellt werden.

42 38 Konzept Durch die verschiedenen Datentypen ergibt sich eine Vielzahl von Nachrichten, welche für den jeweiligen Zweck unterschiedliche Aktionen mit verschiedenen Informationen auslösen sollen. Damit alle diese Anwendungsfälle möglichst einfach nutzbar werden, soll eine kommunikationsorientierte Middleware entwickelt werden, welche als Bindeglied zwischen den Applikationen auf den einzelnen Clients und dem Server fungieren soll. Dadurch soll das Verschicken, Empfangen und Verarbeiten der einzelnen Nachrichten so vereinfacht werden, dass die Netzwerkkommunikation aus Entwicklersicht in den Hintergrund rückt. Für eine solche Netzwerkschicht soll zunächst die mögliche Infrastruktur entwickelt werden, welche sich um das Versenden, Empfangen und Verarbeiten der Informationen kümmert. Hierbei wird eine Schnittstelle entwickelt, welche es dem Entwickler vereinfachen soll, die Daten zwischen dem Server und den Clients auszutauschen. Dazu wird auch der Ablauf der Kommunikation in dieser Schicht beleuchtet. Danach soll diese Infrastruktur erweitert werden, um zunächst zwei Arten von Informationen separat behandeln zu können: Ereignisse und Daten. Hierzu wird aufgezeigt, worin die Unterschiede zwischen diesen Informationen bestehen und welche Verarbeitung sie erfordern. Dabei wird auch beschrieben, wie andere Informationsarten hinzugefügt werden können und wie die resultierende Netzwerkkomponente aussieht Infrastruktur Für die grundlegende Infrastruktur sollen die beiden Seiten der Applikation, Server und Client, zunächst stark vereinfacht dargestellt werden, wie in Abbildung 5.2 zu erkennen ist. Es soll ausreichen, wenn die beiden Seiten nur die Elemente beinhalten, welche für das Empfangen und Verarbeiten von Nachrichten benötigt werden. Da diese Schritte auf beiden Seiten gleich ablaufen, sind die zwei dargestellten Klassen zunächst fast identisch. Der Server erhält jedoch bei eingehenden Nachrichten zusätzlich noch die Verbindung, über welche die Nachricht eingegangen ist. Die Unterschiede befinden sich in den jeweiligen Callbacks, welche in einer Map gesammelt werden. Hierbei verlinkt eine bestimmte Aktion im Format String auf eine Methode. Sobald eine Nachricht über die Verbindung eingeht, wird die Methode handle() aufgerufen und erhält die gewünschte Aktion sowie Schlüssel-Wert-Paare mit allen vorhandenen Daten. Diese Methode sucht dann den passenden Callback aus der Map und übergibt der darin festgelegten Callback-Methode die Daten. Diese Callback-Methode ist dann für die eigentliche Verarbeitung der Daten zuständig. Für die Kommunikation über das Netzwerk soll eine andere abstrahierte Klasse sorgen: der Verbindungs-Manager. Dieser hält, wie in Abbildung 5.3 zu erkennen ist, die einzelnen Verbindungen und kann über diese Nachrichten versenden. Hierbei

43 Konzept 39 Abbildung 5.2: Server und Client besitzen für die Verarbeitung von Nachrichten die gleichen Elemente wird sichergestellt, dass alle Nachrichten zuverlässig übertragen werden. In der späteren Umsetzung besteht dieser Bereich aus mehreren Elementen, welche auf Server und Client aufgeteilt werden. Für die Darstellung des Verbindungsablaufs soll diese Abstraktion jedoch ausreichen. Abbildung 5.3: Der Verbindungs-Manager ist für den Nachrichtenaustausch zuständig und umfasst hier sowohl die Client- als auch die Serverseite Theoretisch könnte ein Client nun eine Nachricht über den Verbindungs-Manager an den Server schicken und dieser könnte auf dem gleichen Weg antworten. Jedoch soll das Verpacken der Informationen in eine Nachricht weder Aufgabe der Verbindung, noch von Server und Client sein. Auch das Entpacken der ankommenden Nachricht gehört nicht in die Aufgabenbereiche der bisherigen Elemente. Für diese beiden Aufgaben ist ein Bindeglied verantwortlich: der Nachrichten-Manager. Dieser wird einmal zwischen dem Client und der Verbindung sowie zwischen dem Server und der Verbindung eingebaut und übernimmt die oben beschriebenen Funktionalitäten, wie in Abbildung 5.4 zu erkennen ist. Client und Server können über diesen Manager Informationen versenden, indem sie die Methode send() mit einer Aktion als String und den jeweiligen Daten als Schlüssel-Wert-Paare aufrufen. Der Server gibt dabei noch die jeweilige Verbindung an, über welche die Nachricht geschickt werden soll der Client hält hingegen nur eine. Der Manager wandelt diese Informationen dann in eine Nachricht um und leitet diese an den Verbindungs-Manager. Empfängt dieser Manager eine neue Nachricht, wird diese an den Nachrichten-Manager geleitet, welcher die Nachricht dann entpackt. Diese entpackten Informationen werden dann über einen Listener zum Front- beziehungsweise Backend geschickt, welches dann die passende Callback-Methode startet.

44 40 Konzept Abbildung 5.4: Der Nachrichten-Manager ver- und entpackt Informationen und leitet diese weiter Wie diese einzelnen Komponenten zusammenspielen, soll an einer einfachen Benutzerinteraktion und dem daraus resultierenden Ergebnis dargestellt werden. Der Benutzer soll dazu seinen Benutzernamen abfragen und diesen dann angezeigt bekommen, wie im Sequenzdiagramm in Abbildung 5.5 dargestellt ist. Hierzu interagiert der Benutzer zunächst mit dem Client und fordert den Benutzernamen an. Der Client übergibt dann die passende Aktion an den clientseitigen Nachrichten-Manager, welcher diese Information dann verpackt. Die daraus resultierende Nachricht wird dann vom Verbindungs-Manager an den serverseitigen Nachrichten-Manager geleitet, welcher daraus wieder die Informationen ausliest und diese an den Server weiterleitet. Hier wird dann aus der Map die passende Methode zur Verarbeitung der Aktion gesucht und gestartet. Abbildung 5.5: Der Benutzername wird über das Netzwerk transportiert Auf diese Weise können Nachrichten zwischen genau einem Server und einem Client ausgetauscht werden. Es soll aber auch die Möglichkeit bestehen, eine Nachricht vom Server an alle Clients verschicken zu können - hierzu dienen Broadcasts. Diese werden ebenfalls von der Netzwerk-Schnittstelle als Funktionalität zur Verfügung gestellt und mit einer Aktion und den jeweiligen Daten aufgerufen, wodurch simultan einzelne Nachrichten an alle Clients verschickt werden. Die Nachrichten werden clientseitig genauso behandelt, wie auch die direkten Nachrichten, jedoch ist es auf diese Weise möglich, alle Clients gleichzeitig mit Informationen zu versorgen.

45 Konzept Nachrichtentypen Durch die Interaktion der einzelnen Benutzer mit der Applikation entstehen sehr unterschiedliche Arten von Informationen, welche vom Benutzer zum Server übertragen, dort verarbeitet und dann wieder verteilt werden müssen. Dabei kann sich nur ein einzelner Zustand ändern oder aber große Datenmengen anfallen, welche an alle Benutzer verteilt werden müssen. Hier sollte auch die Middleware so angepasst werden, dass diese die verschiedenen Arten von Informationen in spezielle Nachrichten umwandelt und diese passend zu der jeweiligen Informationsart verschickt. Dabei werden zunächst zwei Arten von Nachrichten unterschieden: Ereignisse und Daten. Die erste Nachrichtenart enthält Informationen zu Zustandsänderungen, welche mit nur kleinen Datenmengen und ohne Verarbeitung schnellstmöglich verschickt und verarbeitet werden sollen. Die resultierenden Nachrichten sind atomar und liefern immer neue Informationen, ohne dabei von alten Zuständen abhängig zu sein. Beispiele im aktuellen Anwendungsfall wären das Schließen einer Spiellobby oder das Anwenden eines Extras. Für diesen Nachrichtentyp muss der bereits festgelegte Ablauf nicht verändert werden der Nachrichten-Manager entspricht also in seiner Funktionsweise bereits dem Ereignis-Manager. Die Informationen werden bereits vollständig in eine Nachricht verpackt, direkt verschickt und verarbeitet. Dem gegenüber stehen die Datennachrichten, welche beliebig große Datenmengen zwischen den einzelnen Clients und dem Server austauschen sollen. Im Gegensatz zu den Ereignissen können diese Datenmengen auf einem vorhergehenden Datenstand aufbauen und diesen aktualisieren. Eine Ausnahme stellen die initialen Daten dar, welche jedoch aus Konsistenzgründen ebenfalls als Daten-Nachrichten übertragen werden sollen. Falls eine Aktualisierung vorgenommen werden soll, werden nur die Teile der Nachricht neu übertragen, die sich auch verändert haben diese Art der Aktualisierung wird als Delta-Update bezeichnet. Dazu müssen immer zwei Datenstände vorliegen: zum einen der Datenstand mit den neuen Daten und zum anderen der zuletzt verschickte Datenstand, welcher den Zustand der Daten beim Ziel repräsentiert. Hat man diese beiden Versionen, kann man den dazwischen bestehenden Unterschied an Informationen berechnen und diesen so herausziehen, dass man nur die neuen Informationen zu übertragen braucht. Durch diese Methode kann man vor allem bei kleinen Aktualisierungen in großen Datenmengen Bandbreite und Übertragungszeit einsparen. Das dafür benötigte Delta wird von der Klasse Zipper erstellt und wieder entpackt, wie in Abbildung 5.6 dargestellt ist. Grundlage für diese Sequenz ist das Aktualisieren des Spielfeldes bei einem Benutzer welche an den Server geschickt werden soll. In diesem Fall werden nur wenige Elemente des Spielfeldes verändert eine

46 42 Konzept teilweise Aktualisierung der Daten ist also dem erneuten Versenden aller Kugeln vorzuziehen. Hierzu sendet der Server zunächst das Spielfeld mit der jeweiligen Aktion an den serverseitigen Nachrichten-Manager, welcher in diesem Fall der Daten-Manager ist. Dieser verpackt die Informationen wieder in eine Nachricht, wobei jedoch das Spielfeld noch nicht gesetzt wird, da hier zunächst noch das Delta gebildet werden muss. Hierzu übergibt der Daten-Manager das aktuelle Spielfeld sowie den letzten Stand des Spielfeldes, welcher ebenfalls im Server verwaltet wird, an die Zipper-Klasse, welche daraus das Delta erstellt. Da alle Nachrichten zuverlässig zugestellt werden, hat der Server immer einen Datenstand, welcher dem Datenstand bei den jeweiligen Clients entspricht. Das erstelle Delta wird nun an die vorbereitete Nachricht angehängt. Sobald dies geschehen ist, wird die Nachricht über den Verbindungs-Manager an den clientseitigen Daten-Manager geschickt und von diesem verarbeitet die Zuteilung zu dem passenden Manager erfolgt dabei über ein Flag in der Nachricht. Alle bei diesem Manager eingehenden Nachrichten beinhalten ein Delta, das zusammen mit dem letzten Datenstand wieder an eine Zipper-Klasse übergeben wird - dieses Mal jedoch zum Zusammenbauen des aktuellen Datenstands. Dieser wird dann an den Daten-Manager zurückgegeben und von diesem zum Client-Objekt gereicht, dort gespeichert und dem Benutzer angezeigt. Der Abgleich und die teilweise Aktualisierung der Daten läuft dabei immer synchron ab, um die Reihenfolge der Aktualisierungen zu wahren. Abbildung 5.6: Sequenzdiagramm für ein Delta-Update des Spielfeldes Es ist aber auch vorstellbar, dass alternative Anwendungsfälle andere Nachrichtentypen verlangen, welche ebenfalls auf beiden Seiten der Netzwerkschicht gleich behandelt und somit von der Middleware selbst abstrahiert angeboten werden sollen. Für eine solche Erweiterung bietet der Verbindungs-Manager auf beiden Seiten jeweils eine Schnittstelle an, an welche weitere Manager angehängt werden können. Dadurch soll er ermöglicht werden, neue Funktionalitäten beidseitig anzubinden und diese dann wiederum per Schnittstelle aus der Middleware heraus anzubieten.

47 Konzept 43 Aus diesen Vorgaben entsteht die Aufteilung der Netzwerkschicht, wie sie in Abbildung 5.7 dargestellt ist. Hier wird bereits die klare Trennung in Server und Client beachtet, welche für zwei Verbindungs-Manager mit unterschiedlichen Funktionen sorgt. So bietet der Server einen Dienst über einen Port an, welchen der Client dann benutzen kann, um sich mit dem Server zu verbinden. Über die dann gebildete Datenverbindung können nun beide Seiten miteinander kommunizieren, in dem die Informationen von den jeweiligen Nachrichten-Managern verpackt und an die Verbindungs-Manager weitergeleitet werden. Abbildung 5.7: Die einzelnen Komponenten auf Server- und Client-Seite für den Verbindungsaufbau und den Nachrichtenaustausch 5.3 Datenverwaltung Nachdem nun eine Netzwerkinfrastruktur geschaffen ist, welche beliebige Daten vom Server zum Client und wieder zurück transportieren kann und diese Dienste so per Schnittstelle anbietet, dass der eigentliche Transport in den Hintergrund rückt, sollen jetzt die eigentlichen Objekte und Daten der Applikation betrachtet werden. Dazu werden in diesem Abschnitt zunächst die Spielelemente behandelt, welche die Grundlage des Spiels bilden und auf dem Server verwaltet werden. Auch die Anbindung dieser Elemente untereinander und an die Netzwerkschicht wird hier erläutert, während die Anbindung der Clients erst Bestandteil des nächsten Abschnitts ist. Einen Überblick über die Objekte des Servers wird in Abbildung 5.8 vermittelt. Der Server besteht, wie bereits im Abschnitt 5.1 erläutert, aus der Netzwerkschnittstelle und der Spiellogik. Die Spiellogik ist auch hier in die bereits vorgestellten Objekte unterteilt, wobei jedoch das Backend-Objekt die einzelnen Benutzer- und Lobby- Objekte nicht mehr direkt, sondern über eine Listen-Klasse hält und verwaltet. Die

48 44 Konzept detaillierteren Beschreibungen der einzelnen Klassen und ihre Zusammenhänge werden nachfolgend behandelt. Abbildung 5.8: Vereinfachte Darstellung aller serverseitigen Spielobjekte und die jeweiligen Beziehungen dazwischen

49 Konzept 45 Die Nahtstelle zwischen dem Netzwerk und dem Backend ist in Abbildung 5.9 dargestellt. Hierbei ist das Netzwerk-Interface die eigentliche Netzwerkanbindung, welches die Funktionalitäten der serverseitigen Manager aus dem vorherigen Abschnitt abstrahiert zur Verfügung stellt. Dazu gehört das Verschicken der beiden verschiedenen Nachrichtenarten an entweder einen oder alle Benutzer, wobei auch das Ziel für einen Broadcast, etwa eine Lobby, angegeben werden kann. An dieses Interface ist die Klasse Backend gebunden, welche die Nachrichten aus dem Netzwerk über einen Listener signalisiert bekommt und diese an die passenden Callback-Methoden weiterleitet. Diese Methoden befinden sich entweder direkt in der Klasse Backend oder gehören zu einem anderen Spielobjekt und werden vom Backend kombiniert und aufgerufen. Bei Aktualisierungen wird dann die passende Nachricht verschickt. Abbildung 5.9: Die Schnittstelle zur Netzwerkschicht und das daran angebundene Backend Um die Aktionen aus dem Netzwerk passend weiterleiten zu können, muss das Backend die beiden wichtigsten Spielobjekte halten, welche wiederum alle anderen Elemente des Spiels beinhalten: die Liste aller Benutzer und die Liste aller Lobbys. Diese beiden Listen werden jeweils in einer eigenen Klasse verwaltet und bieten neben den üblichen Gettern und Settern auch spezielle Methoden zur Datenmanipulation an. Für die Verwaltung der Benutzer ist die Benutzer-Liste zuständig, welche zusammen mit der Benutzer-Klasse in Abbildung 5.10 zu erkennen ist. Bei diesen sowie bei allen anderen Klassen und Objekten auf dem Server muss die Abstraktion klar erkennbar sein, da es sich hier beispielsweise nicht um den Benutzer selbst, sondern nur seine Repräsentation handelt. Damit es zu keiner Verwechslung kommt, werden alle hier die verwendeten Klassen und Objekte explizit als solche bezeichnet. Die Benutzer-Liste bietet Methoden zum Anfügen, Entfernen und Auslesen von Benutzer-Objekten, sowie zur Überprüfung, ob ein bestimmtes Benutzer-Objekt in der Liste enthalten ist. Die Benutzer werden über einen Benutzernamen identifiziert,

50 46 Konzept welcher beim erstmaligen Einfügen zufällig gesetzt und zurückgegeben wird. Dieser muss in der gesamten Applikation einmalig sein. Für den Fall, dass ein Benutzer von einer Lobby in ein Spiel gelangt, steht eine Methode zum Erstellen der einzelnen Spielelemente bereit, welche später detailliert erläutert werden. Zusätzlich kann das Benutzer-Objekt dann auch eine neue Kugel zum jeweiligen Spielfeld hinzufügen, den aktuellen Stand seines Spielfeldes liefern, das erste Extra aus dem eigenen Inventar holen oder sich selbst ein neues aktives Extra hinzufügen. Abbildung 5.10: Die Benutzer werden als Objekt abstrahiert und in einer Benutzer- Liste verwaltet Die Benutzer-Liste wird jedoch nicht nur einmalig vom Backend gehalten und verwaltet, sondern findet auch Verwendung bei den Spiellobbys und hält in diesen ebenfalls alle Benutzer-Objekte, welche sich gerade in einer Lobby befinden. Diese Lobbys wiederum werden von einer Listen-Klasse verwaltet, wie in Abbildung 5.11 zu sehen ist. Die Klasse bietet dabei dem Backend Funktionalitäten an, um die Liste passend manipulieren zu können. So können neue Lobby-Objekte an die Liste angefügt oder über den Ersteller beziehungsweise den Lobbynamen wieder entfernt werden. Außerdem kann das Backend auch gezielt nach einem Lobby- Objekt suchen. Für die Ausgabe der gesamten Lobbyliste wird außerdem eine Methode bereitgestellt, welche aus den Lobby-Objekten die Namen ausliest, damit diese als Liste von Strings an die Clients geschickt werden können. Die Lobbys selbst werden durch einen Namen identifiziert, wobei auch hier jeder Name einmalig in der Applikation ist. Außerdem hält jede Lobby neben der Liste von Benutzern auch den Ersteller der Lobby, da dieser mehr Privilegien im Lobbybetrieb genießt. Während der Ersteller für die Dauer der Lobby fest ist und nur einmalig beim Erstellen gesetzt werden kann, können sich die anderen Teilnehmer frei bewegen. Hierzu werden die Methoden der Listen-Klasse übernommen und erweitert, damit das Backend direkt auf den Daten arbeiten kann. Die Erweiterung dient dazu, dass beim Entfernen eines Benutzers geprüft wird, ob dieser der Ersteller der Lobby ist und die Lobby noch nicht ins Spiel übergeführt wurde, da in

51 Konzept 47 Abbildung 5.11: Lobbys werden in einer Lobby-Liste verwaltet und können zu einem Spiel erweitert werden diesem Fall die Lobby entfernt werden muss. Startet der Ersteller das Spiel, wird dies im Lobby-Objekt durch das Setzen einer Flag gesichert. Die anderen Daten der Lobby werden nicht verändert, lediglich die Überprüfungen beim Manipulieren der Lobby werden somit dem aktuellen Zustand angepasst. Außerdem gibt es auch bei dieser Klasse die Möglichkeit, von allen aktuellen Teilnehmern die Benutzernamen auszulesen und in eine Liste von Strings zusammenzufügen, damit diese für die clientseitige Darstellung genutzt werden kann. Befindet sich der Benutzer in einem Spiel, so erhält das Benutzer-Objekt weitere Elemente, welche die spielrelevanten Objekte darstellen. Eine Übersicht dieser Spielobjekte ist in Abbildung 5.12 sichtbar. Dabei werden alle Klassen von dem Benutzer-Objekt gehalten und verwaltet. Zunächst hat jeder Benutzer ein eigenes Spielfeld, welches wiederum aus Kugeln besteht, wobei die Kugeln hier immer nur ein Teil des Spielfeldes sind. Dazu wurde auch der Kugelvorrat abstrahiert dieser ist nur noch eine Zahl im Benutzer-Objekt, welche die Anzahl der verbleibenden Kugeln darstellt, wobei die Farbe der jeweils nächsten Kugel separat als Zahl abgespeichert wird. Die Kugel-Objekte selbst werden immer zufällig erzeugt, wenn der Spieler die nächste Kugel zum Abschuss benötigt oder eine neue Reihe eingefügt wird. Schießt der Spieler eine Kugel ab und bleibt diese an einer Position hängen, wird an eben dieser Position ein Kugel-Objekt im Spielfeld-Objekt eingefügt. Nach dem Einfügen der Kugel, wird die benachbarte Kugelmenge durchlaufen und entfernt, wenn mindestens drei gleichfarbige Kugeln zusammenkommen. Dabei werden auch schwebende Kugeln und Extra abgebaut, wobei letztere wieder zum Benutzer-Objekt gelangen und von diesem in sein Inventar gelegt werden. Baut der Benutzer außerdem mehr als fünf Kugeln oder mehr als fünf schwebende Kugeln ab, wird dem Spielfeld ein neues Extra ange-

52 48 Konzept Abbildung 5.12: Im Spiel wird das Benutzer-Objekt um ein Spielfeld und ein Inventar erweitert fügt. Außerdem bietet die Klasse auch Methoden zum Hinzufügen und Entfernen ganzer Kugelreihen an, sowie zum vollständigen Bereinigen des Spielfeldes, was beispielsweise beim Ende des Spiels geschieht. Andererseits hat der Spieler auch ein Inventar, in dem er Extras sammeln und diese benutzen kann. Dazu hat das Benutzer-Objekt eine Instanz der Inventar- Klasse, welche beliebig viele Extra-Objekte halten kann. Extras sind in diesem Fall Erweiterungen der Kugel-Klasse um einen Typ, welcher die Aktion festlegt, die beim Benutzen des Extras angewendet wird. Hierzu können neue Extra-Objekte ans Ende des Inventars angehängt und von vorne wieder ausgelesen werden. Sobald beim Server ein Extra ankommt, wird dieses vom Benutzer-Objekt angewendet. Bei Extras, welche das Spielfeld manipulieren, wird die Aktion auf das Spielfeld-Objekt des Benutzers angewandt. Bei anhaltenden Effekten mit einer Wirkdauer, wird das Extra an den jeweiligen Spieler geschickt und im Frontend angewendet.

53 Konzept Struktur der Clients Während der Server die gesamten Informationen der Applikation hält, manipuliert und über das Netzwerk zur Verfügung stellt, befinden sich auf der anderen Seite der Verbindung die einzelnen Clients, welche die Manipulation der Daten steuern. Diese basieren auf den in Abschnitt 5.1 beschriebenen Elementen Netzwerk, Anzeigelogik, Zwischenspeicher und GUI. Wie jedoch in Abbildung 5.13 zu erkennen ist, wurde der Zwischenspeicher in die einzelnen Spielelemente aufgeteilt, um diese so besser verwalten zu können. Auch die GUI wurde um eine Klasse erweitert, welche die Bewegungen der aktiven Kugel steuert. Abbildung 5.13: Die vereinfachten Klassen des Clients mit den jeweiligen Beziehungen und der Anbindung an die Netzwerkschicht