Konzeption und prototypische Umsetzung einer Social Gaming-Plattform unter Verwendung einer Multiplayer-Architektur und Ruby on Rails-Programmierparadigmen

Inhaltsverzeichnis

Abstract

Abbildungsverzeichnis

Tabellenverzeichnis

Abkürzungsverzeichnis

Glossar

1 Einleitung
1.1 Relevanz des Themas
1.2 Problemstellung und Abgrenzung
1.3 Aufbau der Arbeit

2 Ausgangssituation
2.1 Das Web 2.0
2.2 Das Begriffsumfeld Social Gaming

3 Anforderungen an eine Social Gaming-Plattform
3.1 Die Verknüpfung der Komponenten
3.2 Multiplayer-Elemente
3.3 Community-Features

4 Konzeption des Prototypen
4.1 Festgelegte Techniken
4.2 Architektur der Plattform
4.3 Geplante Funktionalitäten

5 Das Web-Framework Ruby on Rails
5.1 Die Programmiersprache Ruby
5.2 Zur Installation benötigte Komponenten
5.3 Grundlegende Bestandteile und Eigenschaften
5.4 Paradigmen
5.4.1 Model View Controller (MVC)
5.4.2 Convention over Configuration
5.4.3 Don’t repeat yourself (DRY)
5.5 Architektur des Frameworks
5.6 AJAX
5.7 Integrierte Testumgebung

6 Multiplayer-Architektur
6.1 Adobe Flash
6.1.1 Entwicklungsmöglichkeiten
6.1.2 Das Adobe Flash CS3 Authoring-Tool
6.2 Die Programmiersprache ActionScript
6.2.1 ActionScript Version 3.0
6.2.2 Interaktion mit Elementen aus Adobe Flash
6.3 Der Socket-Server
6.3.1 Wahl des Servers
6.3.2 Eigenschaften des Electro-Servers 4.0
6.3.2.1 Erweiterbares Framework
6.3.2.2 Sicherheitsaspekte
6.3.3 Grundlegende Server-Architektur einer Multiplayer-Anwendung
6.4 Multiplayer Game Design Patterns
6.4.1 Authoritative Client
6.4.2 Authoritative Server
6.4.3 Hybride Strukturen

7 Prototyping der Community-Module mit Ruby on Rails
7.1 Vorbereitende Maßnahmen
7.2 Grundstruktur und Datenmodell
7.3 Prototyping der Community-Module
7.3.1 Login und Registrierung
7.3.2 Mein Account
7.3.2.1 Übersichtsseite
7.3.2.2 Nachrichten
7.3.2.3 Spielstatistik
7.3.3 Profilseite
7.3.3.1 Minifeed
7.3.3.2 Pinnwand
7.3.4 Freundesnetzwerk
7.3.5 Community-Startseite
7.3.5.1 Blog
7.3.5.2 Benutzersuche
7.3.6 Spielinformationen
7.4 Abschließender Test

8 Prototyping der Multiplayer-Elemente
8.1 Architektur der Multiplayer-Anwendung
8.1.1 Interaktion der Komponenten
8.1.2 Ablaufsequenz einer Spielanfrage
8.2 Flash-Client
8.3 Implementierung eigener Server-Extensions
8.3.1 Game Manager-Initialisierung
8.3.2 Login Event Handler
8.3.3 LobbyLogic
8.4 Referenzspiel
8.4.1 Spielprinzip und Grundlagen
8.4.2 Serverseitiges Spiel-Plugin und Rundenwechsel
8.4.3 Grafische Oberfläche

9 Der fertige Prototyp

10 Fazit

11 Ausblick

Literaturverzeichnis

Ehrenwörtliche Erklärung

Anhang A Flowcharts

Anhang B Screenshots

Anhang C Quellcode

Abstract

Deutsch

Diese Diplomarbeit befasst sich mit der Konzeption und prototypischen Umsetzung einer Social Gaming-Plattform mit browserbasierten Casual Games. Analysiert wird in diesem Zusammenhang die Tauglichkeit des erst seit Ende 2004 verfügbaren Open-Source Web-Frameworks Ruby on Rails für ein solches Projekt. Für die Entwicklung der Multiplayer-Elemente wird die aktuelle ActionScript 3.0-Version von Adobe Flash verwendet und eine passende Architektur herausgearbeitet. Anhand eines rundenbasierten Puzzle-Referenz-spiels und der prototypischen Ausarbeitung der Community werden Usability und Performance der verwendeten Techniken aufgezeigt.

English

This diploma thesis addresses the conception and prototypic implementation of a Social Gaming Platform with browser-based Casual Games. In this context, the suitability of the new Open Source Web Framework Ruby on Rails – released at the end of 2004 – is analysed. After designing an adequate architecture, the Multiplayer Elements are developed, based on ActionScript 3.0. Finally, the usability and performance of the used techniques, including a turn-based sample puzzle game, are demonstrated.

Abbildungsverzeichnis

Abbildung 1-1: Aufbau und Struktur der Diplomarbeit

Abbildung 4-1: Geplante Architektur der Social Gaming-Plattform

Abbildung 4-2: Geplante Module der Social Gaming-Plattform

Abbildung 5-1: Einfache Beispielsausdrücke in Ruby

Abbildung 5-2: Ausgabe der Beispielsausdrücke in Ruby

Abbildung 5-3: Rails und MVC (modifiziert nach [HEHA2006, S. 13])

Abbildung 5-4: 1:n-Mapping einer Datenbanktabelle

Abbildung 5-5: Bestandteile und Zusammenspiel (nach [WIBA2007, S. 10])

Abbildung 5-6: Synchrone und asynchrone Kommunikation im Vergleich (nach [WIBA2007, S. 239])

Abbildung 6-1: Beispiels-Klasse in ActionScript

Abbildung 6-2: Hierarchie einer DisplayList (nach [MOOC2007, S. 469])

Abbildung 6-3: Autoritativer Client eines Schach-Spiels

Abbildung 6-4: "Out of Sync" bei Echtzeit-Multiplayer-Spielen

Abbildung 7-1: Abstrakte Datenmodellierung des Prototypen

Abbildung 7-2: Blogs-Migrationsdatei

Abbildung 7-3: Wahl zwischen Login- und Logout-Anzeige

Abbildung 7-4: Partial für Spielstatistik – gruppiert nach Kategorien

Abbildung 7-5: Serialisierung eines Minifeeds

Abbildung 7-6: Partial für Freundschaftsanfragen

Abbildung 7-7: Beispiels-Benutzersuche

Abbildung 7-8: Statistik des Community-Prototypen

Abbildung 8-1: Architektur der Multiplayer-Anwendung

Abbildung 8-2: Ablauf einer Spielanfrage

Abbildung 8-3: Sequenzdiagramm der Client-Server-Extension-Kommunikation

Abbildung 8-4: GUI-Prototyp der Lobby

Abbildung 8-5: Verwendete Bestandteile und Attribute der GameConfiguration

Abbildung 8-6: GUI-Prototyp des Spielbereichs

Abbildung A-1: Flowchart: Client/Server-Kommunikation des Puzzle-Spiels

Abbildung A-2: Flowchart: Algorithmus der Client-Spielsequenz

Abbildung B-1: Registrierungsmaske

Abbildung B-2: Mein Account

Abbildung B-3: Nachrichten: Posteingang

Abbildung B-4: Benutzersuche

Abbildung B-5 Community-Übersichtsseite

Abbildung B-6: Profilseite

Abbildung B-7: Lobby

Abbildung B-8: Puzzle-Spielfeld

Abbildung B-9: Puzzle-Spiel – Gewinnbenachrichtigung

Tabellenverzeichnis

Tabelle 2-1: Die sieben Web 2.0-Prinzipien. Eigene Übersetzung (modifiziert nach [OREI2005])

Tabelle 5-1: Detaillierte Ergebnisse der Portierung auf Ruby on Rails (nach [RELE2005])

Tabelle 6-1: Zone-Room-Architektur von ES

Tabelle 8-1: Individuelle Server-Extensions der Plattform. Eigene Darstellung

Tabelle 8-2: Paket- und Klassenübersicht des Flash-Clients

Tabelle 8-3: Paket- und Klassenübersicht der Server-Extensions

Tabelle 8-4: Struktur der LoginEventHandler-Extension

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Glossar

Abbildung in dieser Leseprobe nicht enthalten

1 Einleitung

1.1 Relevanz des Themas

„Denn, um es endlich auf einmal herauszusagen, der Mensch spielt nur, wo er in voller Bedeutung des Worts Mensch ist, und er ist nur da ganz Mensch, wo er spielt.“ – Friedrich Schiller , in „Über die ästhetische Erziehung des Menschen in einer Reihe von Briefen“

Der Markt für Video- und Computerspiele wächst ungebremst. 2006 haben die Hersteller von Spielen, Spielkonsolen und tragbaren Spielgeräten weltweit um die 31 Milliarden Dollar eingenommen [ZEIT2007]. Innerhalb Europas hat sich mittlerweile Deutschland nach Großbritannien zum zweitgrößten Absatzmarkt entwickelt und wird mit dem Geschäftsjahr 2007 voraussichtlich zum ersten Mal die Grenze von zwei Milliarden Euro Umsatz überschreiten [BKOM2007a].

Obwohl der meiste Erlös der Branche durch Videospiele für Konsolen wie Xbox, Playstation oder den Computer entsteht, haben in jüngster Zeit Online-Spiele einen großen Anteil an dieser rasant fortschreitenden Entwicklung. „Die Erlöse aus Lizenzen und Abo-Gebühren für Online-Spiele wachsen [...] deutlich schneller als der Umsatz aus dem Verkauf herkömmlicher, nicht über das Internet spielbarer Titel“ [PWHC2007]. Laut einer Studie des Marktforschungsinstituts Nielsen/NetRatings [NIELS2007] stieg die Anzahl der deutschen Online-Spieler im Speziellen in den vergangenen drei Jahren von 5,2 Millionen um 76 Prozent auf 9,2 Millionen.

Der „Media Report Gaming“ des ProSiebenSat.1-Vermarkters SevenOne Media nennt die Ursachen dieses Trends:

„Die zunehmende Durchdringung der deutschen Haushalte mit Breitband-Internetzugängen spielt der Games-Industrie [...] in die Hände. Denn eine steigende Personenzahl greift auf Online-Spiele zu, bildet Netzwerke und spielt gegen- oder miteinander. Für den deutschen Markt sind 2007 deutliche Umsatzsteigerungen von über 50 Prozent auf knapp 400 Millionen Euro zu erwarten. Im Jahr 2010 wird die Branche voraussichtlich bereits 672 Millionen Euro mit Online-Spielen umsetzen.“ [PROS2007]

Dabei haben zwei Arten von Spielen in letzter Zeit wieder vermehrt an Bedeutung gewonnen: Spiele im Multiplayer-Modus (siehe [BKOM2007b]) und Casual Games (vgl. [IDGA2006, S. 8], [DFCI2008]). Online-Multiplayer-Spiele nutzen die – auch jedem Gesellschaftsspiel außerhalb des Internets eigene – sozial-interaktive Komponente des Spielens:

Kommunikation, gegenseitiger Vergleich und gemeinsamer Spielspaß stehen im Vordergrund. So genannte Massively Multiplayer Online Games (MMOGs), meist komplizierte Rollen- oder Strategiespiele wie beispielsweise World of Warcraft, lassen dabei mehrere tausend Spieler gleichzeitig zu, die miteinander interagieren und kommunizieren können und zusammen in eine aufwändig gestaltete Spielwelt eintauchen.

Casual Games verzichten im Gegensatz dazu auf diese Immersion in eine virtuelle Welt. Sie sind „dadurch gekennzeichnet, dass sie intuitiv zu bedienen sind und sich durch einen schnellen Spielerfolg auszeichnen“ [INGA, S. 37]. Darüber hinaus sind sie vergleichsweise einfach und schnell zu produzieren und lassen sich auf Grund ihrer geringen Größe auch auf leistungsschwächeren PCs spielen.

Um Casual Games im WWW anzubieten, haben sich verschiedene Plattformen und unterschiedliche Geschäftsmodelle entwickelt. Manche davon ermöglichen den Nutzern nach einer Registrierung, wahlweise kostenlos oder um Echtgeld zu spielen und so die eigenen Fähigkeiten bei Spielen, die nicht vorrangig durch Glück gewonnen werden können („skill-based-Games“), unter Beweis zu stellen. Durch das wiederholte Zusammentreffen der Spieler und ihr geteiltes Interesse kann sich eine Spielergemeinschaft (im folgenden „Community“ genannt), entwickeln, die auf Grund der kundenbindenden Wirkung vom Betreiber verstärkt und mit technischen Hilfsmitteln aktiv gefördert werden sollte [PANT2005, S. 348]. Die Plattform wird durch die Kombination von Spielen mit einer Community zu einer „Social Gaming-Plattform“ im Sinne von Web 2.0 (siehe Kapitel 2).

1.2 Problemstellung und Abgrenzung

In dieser Arbeit soll auf Grund der Aktualität der oben genannten Bereiche eine Social Gaming-Plattform mit „Multiplayer Casual Games“ (und somit einer Multiplayer-Architektur), zunächst theoretisch konzipiert und anschließend prototypisch umgesetzt werden. Dabei wird auf die programmiertechnischen Anforderungen ein besonderer Schwerpunkt gelegt. Das relativ neue, erst Ende 2004 herausgegebene, Web-Framework Ruby on Rails (RoR, oder auch kurz „Rails“), welches bereits in einigen anderen kommerziellen Anwendungen mit Web 2.0 – Charakter verwendet wurde (siehe [HAPP2008]), bot sich auf Grund seiner flexiblen Vorgehensweise und der implizierten Möglichkeit, eine besonders agile Softwareentwicklung für das geplante Startup zu betreiben, als Testobjekt für die Programmierung des Grundgerüsts der Plattform (der „Community-Features“) an. Ob und in welcher Weise sich Ruby on Rails – ohne umfangreiche Vorkenntnisse aufweisen zu können – für eine, auf Grund der aktuell hohen Konkurrenzsituation auf dem Online-Spielemarkt notwendigerweise, schnelle und trotzdem robuste Umsetzung des Prototypen einer Social-Gaming-Plattform eignet, soll in dieser Arbeit überprüft werden.

Interessant ist dabei die Tatsache, dass bereits bestehende Online-Spiele-Plattformen auf dem deutschen Markt vornehmlich nicht diese (neue) Technik, sondern Java und ein dazugehöriges Framework verwenden. Eine doppelte Konzeption in Java und Ruby (on Rails) und somit ein direkter Vergleich in Bezug auf den Prototyp ist nicht Ziel dieser Arbeit. Jedoch sollen sporadisch Vergleiche mit anderen Programmiertechniken angestellt werden, um die Besonderheiten von RoR herauszuarbeiten.

Ebenso soll durch eine logische Vorgehensweise die Multiplayer-Architektur aus einem Vergleich von verschiedenen Möglichkeiten entwickelt und im Prototyping überprüft werden. Eine komplette Umsetzung der Plattform mit wirtschaftlicher Planung kann auf Grund des begrenzten Umfangs dieser Arbeit nicht geleistet werden. Zur weiterführenden Lektüre sei in diesem Zusammenhang u.a. [IDGA2006, S. 33- 43] und [PAN2005] genannt.

Aufbauend auf den gezeigten Ergebnissen soll im Anschluss die vollständig umgesetzte Plattform entstehen.

1.3 Aufbau der Arbeit

Nach der Klärung der Ausgangssituation und Definitionen im Begriffsumfeld „Social Gaming“ (Kapitel 2) werden in Kapitel 3 dieser Arbeit die Grundelemente, die eine Social Gaming-Plattform enthalten sollte, herausgearbeitet. Kapitel 4 erläutert anschließend die Wahl der für den konkreten Prototyp verwendeten Techniken und dessen Architektur. Die grundlegenden Eigenschaften des Frameworks Ruby on Rails werden in Kapitel 5 aufgezeigt. Ob und in welcher Weise Rails als Vertreter der agilen Softwareentwicklung für dieses Projekt tatsächlich geeignet ist, wird in Kapitel 7 durch Prototyping der Community-Features analysiert.

Die für die gewählte Mulitplayer-Architektur notwendige Programmier- und Servertechnik erklärt Kapitel 6. Darauf aufbauend wird in Kapitel 8 das Prototyping der Multiplayer-Elemen-te beschrieben und ein rundenbasiertes Puzzle-Referenzspiel erstellt. In Kapitel 9 werden schließlich beide Elemente des Prototypen zusammengeführt und der erstellte Code getestet. Kapitel 10 und 11 bieten eine Zusammenfassung der Ergebnisse und einen Ausblick auf die weitere Entwicklung der dargestellten Plattform und der Branche.

Abbildung 1-1 zeigt den Aufbau der Arbeit, untergliedert in die einzelnen Themenbereiche.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1-1: Aufbau und Struktur der Diplomarbeit

2 Ausgangssituation

Im Folgenden werden für eine Social Gaming-Plattform wichtige ökonomische und technische Grundlagen aufzeigt, das Schlagwort Web 2.0 und dessen Bezug auf eine solche Plattform geklärt und für diese Arbeit relevante Begriffe im Umfeld des Social Gamings genannt und erläutert.

2.1 Das Web 2.0

Nach dem Kollaps der New Economy um die Jahrtausendwende stagnierte die Entwicklung im World Wide Web nicht, wie damals von vielen Seiten befürchtet wurde. Dennoch veränderte sie sich wesentlich. War es vorher in Form von reinen HTML-Seiten eher statisch konzipiert und auf die reine Betrachtung der Seiten durch den Nutzer ausgelegt, wuchs im Web seither die Zahl der interaktiven Anwendungen, welche die Anwender in den Mittelpunkt stellen, exponentiell. Man ging von der alleinigen Betrachtung („read only“) über zur „Interaktion, Collaboration und Peer-to-Peer-Kommunikation („write and contribute“)“ [LEMB2006, S. 131] der Nutzer. Vormalige Rezipienten wurden vermehrt zu Produzenten, die nun den Inhalt des Webs aktiv mitgestalten, Daten miteinander vernetzen und so eine neue Struktur des Internets schaffen.

Der US-Verleger Tim O’Reilly prägte 2004 für diese Entwicklungen den Begriff „Web 2.0“ und formulierte im Artikel „What is Web 2.0“ dessen sieben wichtigste Prinzipien:

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2-1: Die sieben Web 2.0-Prinzipien. Eigene Übersetzung (modifiziert nach [OREI2005])

Wie Tabelle 2-1 zeigt, ist es nicht eine einzige Technik oder Entwicklung, die den Wandel zum Web 2.0 ausmacht. „Web 2.0 is a set of economic, social, and technology trends that collectively form the basis for the next generation of the Internet – a more mature, distinctive medium characterized by user participation, openness, and network effects” [OREI2006, S. 4].

Auf diese Arbeit bezogen ist besonders relevant, dass das Web heute als allgegenwärtige Plattform fungiert. Viele Anwendungen kann man bereits (wie es beispielsweise mit E-Mail-Programmen schon länger funktioniert) immer und überall „dabei haben“, da sie im WWW stets abrufbar sind, sei es während der Arbeit, unterwegs oder im Urlaub (Prinzip 1). Dabei sind diese Applikationen auf Grund neuer Techniken wie Asynchronous JavaScript And XML (AJAX) zunehmend so leicht, einfach und schnell zu benutzen und grafisch ähnlich gebaut, als ob sie über den Desktop laufen würden („Rich Clients“) (Prinzip 7). Für die Nutzer einer Social Gaming-Plattform im Web 2.0 bedeutet dies, dass sie grundsätzlich überall spielen können, wo ein Webbrowser zur Verfügung steht, ohne eine Anwendung installieren zu müssen oder deswegen eine schlechtere „Usability“ erwarten zu müssen (browserbasiertes Spielen).

Auch das zweite Prinzip („Die Nutzung kollektiver Intelligenz“) spielt in Hinblick auf den geplanten Prototypen eine Rolle. Eine vernetzte Nutzergemeinschaft, die an der Anwendung (durch Blogs, Einstellen eigener Inhalte) selbst partizipiert, bindet sich mit hoher Wahrscheinlichkeit eher an einen Anbieter als Besucher, die mit dem Inhalt einer Seite nicht direkt etwas zu tun haben.

Der Host einer Social Gaming-Plattform kann den Nutzern zudem indirekt Gestaltungsmacht über die Anwendung einräumen, indem er deren (veränderliche) Bedürfnisse herausfindet und seine Applikation stets an diese anzupassen versucht. Die Anwendung ist somit nie komplett „fertig“ und muss flexibel bleiben, um immer wieder ergänzt oder umgestaltet zu werden. Dies entspricht dem vierten Web 2.0-Prinzip (im Original von O´Reilly „Perpetual Beta“ genannt).

O´Reillys sechstes Web 2.0-Prinzip kann in Hinblick auf eine Social Gaming-Plattform durch die beständige Weiterentwicklung mobiler Endgeräte wie beispielsweise das Apple iPhone zum Tragen kommen. Es ist denkbar, dass, sobald alle Techniken kompatibel sind, in Kürze eine komplette Social Gaming-Plattform auf solchen Geräten lauffähig ist.

Die Prinzipien 3 („Daten als Kapital“) und 5 („Einfache und beliebig kombinierbare Anwendungen werden sich durchsetzen“) kommen in Verbindung mit der in dieser Arbeit geplanten Plattform nicht unmittelbar zum Einsatz.

2.2 Das Begriffsumfeld Social Gaming

Wie in Kapitel 2.1 erläutert, konzentrieren sich Applikationen im Web 2.0 vermehrt auf die soziale Interaktion und Kollaboration der Nutzer. Sir Tim Berners-Lee, Begründer des WWW, konstatiert, dass im Web (2.0) nun Realität sei, wozu es von Anfang an gedacht gewesen sei: „ ... ein kollaborativer Raum, in dem die Menschen interagieren können“ [IBMD2006].

Deshalb findet man online und in der neueren Fachliteratur, die das Web 2.0 betrifft, häufig Wortzusammensetzungen mit „Social-“, wie „Social Networking“, „Social Bookmarking“ oder auch „Social Gaming“. Dabei steht „Social“ (bzw. dt. „sozial“) hier nicht (nur) für „die menschliche Gesellschaft, Gemeinschaft betreffend; gesellschaftlich“ [DUDE2001], sondern allgemein „für gemeinschaftlich, zusammen, miteinander“ [SCJO2006]. Der Begriff „Social Software“ meint beispielsweise „Anwendungen bzw. Systeme, mit denen Menschen kommunizieren, zusammenarbeiten oder auf eine andere Art interagieren können“ ([ALBY2006, S. 89], zitiert nach [MIKL2007, S. 56]).

Wegen der relativen Neuheit des Themas gibt es für den Begriff des „Social Gamings“ nur wenige Erklärungsversuche, geschweige denn eine in der Fachliteratur allgemein akzeptierte Definition des Begriffs. Um die Anforderungen an den zu gestaltenden Prototyp trotzdem adäquat festlegen zu können, wird im Folgenden eine Arbeitsdefinition versucht.

Die XING AG, ein Anbieter im Bereich Global Networking für Geschäftsleute, belegt das oft genannte Schlagwort „Social Networking“ folgendermaßen:

„Das Herstellen und Nutzen sozialer Kontakte; in der Form des Online Social Networking mittels spezieller Websites, die die Kommunikation der Nutzer untereinander und die Suche nach Nutzern mit bestimmten Eigenschaften ermöglichen.“ [XING2007]

Überträgt man dies zusammen mit den in der Einleitung zu dieser Arbeit vorgestellten Begriffen auf das hier relevante „Social Gaming“, lässt sich dies wie folgt umschreiben.

Arbeitsdefinition Social Gaming

„Social Gaming meint Spielen als Möglichkeit der sozialen Interaktion; es vereint in der Form des Online Social Gamings mittels spezieller Plattformen im Web 2.0 browserbasierte Multiplayer-Spiele (insbesondere Casual Games) mit Community-Features, welche u.a. die Kommunikation der Spieler untereinander und die Suche nach Mitspielern mit bestimmten Eigenschaften ermöglichen und fördern.“

Eine Social Gaming-Plattform wäre der begrifflichen Definition nach theoretisch auch mit anderen Spielen als Casual Games möglich, da sich z.B. auch in MMORPGs eine Spielergemeinschaft bildet. Die Kommunikation und Interaktion der Spieler verläuft dort allerdings vorrangig innerhalb der Spielwelt. Aus diesem Grund und aus der wirtschaftlichen Aktualität der Casual Games, die als „Spiele für alle“ nicht auf eine bestimmte Zielgruppe festgelegt sind, wird eine solche Plattform in den weiteren Ausführungen nicht in Betracht gezogen.

3 Anforderungen an eine Social Gaming-Plattform

Aus der aufgestellten Arbeitsdefinition ergeben sich verschiedene Anforderungen an eine Social Gaming-Plattform. Im Folgenden sollen diese, unter Einbeziehung der Eigenschaften großer Online-Spiele-Plattformen mit Casual Games, herausgearbeitet werden.

3.1 Die Verknüpfung der Komponenten

Zunächst müssen die beiden grundlegenden Komponenten „Spiele“ (Casual Games) und „Community-Features“ zusammengebracht werden.

Betrachtet man in diesem Zusammenhang auf dem deutschen Markt länger existierende Spiele-Plattformen wie King [KING2008] oder Gameduell [GAMD2008], die ihre Spiele ebenfalls mit einer Community verknüpfen, so zeigt sich, dass diese dort direkt integriert wurde. Neuere Spiele-Plattformen auf dem US-amerikanischen Markt wie z.B. Zynga [ZYNGA2008a], Webs [WEBS2008] oder Mytopia [MYTP2008] arbeiten dagegen damit, ihre Casual Games in bereits bestehende Online Social Networks wie z.B. Facebook [FACE2008] oder Friendster [FRST2008] zu integrieren. In dieser Diplomarbeit geht es jedoch nicht darum, wie Zynga in „What is Zynga anyway“ [ZYNGA2008b] beschreibt, sich mit alten Freunden in einem schon existierenden Netzwerk zu verbinden und mit diesen und neuen Freunden zu spielen, sondern um eine Community, die sich innerhalb der Plattform aufbaut und deren Funktionen auch dort verwirklicht werden. Die vorrangige Verbindung zwischen den einzelnen Community-Mitgliedern soll deren gemeinsames Interesse am Spielen, Gewinnen und am sozialen Vergleich sein. Der exakte begriffliche Unterschied zwischen einer Community und einem Social Network wird in der Fachwelt kontrovers diskutiert und soll auf Grund des begrenzten Rahmens dieser Arbeit nicht näher erörtert werden, da er nicht ausschlaggebend für das weitere Vorgehen ist.

3.2 Multiplayer-Elemente

Der aufgestellten Arbeitsdefiniton folgend, sollten Social Gaming-Plattformen Multiplayer Casual Games beinhalten. Dies kann auf unterschiedliche Art und Weise gestaltet werden. [GAME2008] stellt beispielsweise die meisten seiner Spiele (26 von insgesamt 31) zunächst einmal im Singleplayer-Modus zur Verfügung und vergleicht anschließend die erzielten Punkte der jeweiligen Spieler, die sich zu einem gemeinsamen Spiel angemeldet haben, miteinander. Dadurch vermischen sich gewissermaßen die beiden Aspekte Multiplayer und Singleplayer, da das Ziel des Spiels nicht ist, einen für den einzelnen Spieler befriedigenden Punktestand oder ein vorher gestecktes Ziel zu erreichen, sondern immer, im Vergleich mit einem bestimmten anderen Spieler/mehreren anderen Spielern einen höheren Punktestand zu erzielen. Ähnlich präsentiert sich [KING2008] in diesem Zusammenhang. Auch hier funktioniert das Gros der Spiele (72 von 83) über einen solchen, geringfügig anders strukturierten Singleplayer-Modus. Den Singleplayerspielen der beiden Plattformen ist gemeinsam, dass die Nutzer dort (fast) keine Auswahlmöglichkeit bezüglich ihrer Spielpartner haben.

Auf Grund der sich hier zeigenden begrifflichen Unschärfe zwischen Single- und Multiplayerspielen seien letztere im weiteren Verlauf dieser Arbeit dadurch definiert, dass sie im Gegensatz zu Singleplayerspielen das simultane Spiel von mindestens zwei Teilnehmer erfordern, unabhängig davon, ob dieses schlussendlich rundenbasiert (ein Spieler macht einen Spielschritt, im Anschluss daran folgt der des anderen/nächsten Spielers) oder in Echtzeit (die Teilnehmer können ihr Spiel gegenseitig beeinflussen und gleichzeitig ins Spielgeschehen eingreifen) gestaltet ist. Das wesentlichste Merkmal eines Multiplayerspiels sei es, dass alle Spieler gleichzeitig (bzw. je nach eingesetzter Technik nur geringfügig zeitverzögert) dasselbe Spielgeschehen auf ihrem PC sehen.

Eine Social Gaming-Plattform im Sinne von Web 2.0 sollte im Gegensatz zu [KING2008] und [GAMD2008] ausschließlich solche „echten“ Multiplayerspiele anbieten, um den interaktiven Charakter der Applikation zu verstärken und lange Wartezeiten auf das Spielergebnis zu vermeiden. Eine größere Freiheit hinsichtlich der Gegnerauswahl kann dazu beitragen, trotz der geforderten simultanen Spielweise immer einen Spielpartner zu finden. In Hinblick auf ihre vergleichsweise wenigen Multiplayerspiele stellen die genannten Betreiber als Treffpunkt für jedes Spiel eine „Lobby“ zur Verfügung. Über diese können einzelne Spielräume eröffnet und demzufolge in Echtzeit Spielabsichten erklärt werden, was ein wichtiger Aspekt für eine Social Gaming-Plattform ist und als Anforderung übernommen werden kann.

3.3 Community-Features

Die Community (dt. „Gemeinschaft“; in dieser Arbeit ist stets die Variante der Online-Community gemeint) bilden an und für sich die Spieler einer Social Gaming-Plattform, weswegen im Weiteren die Funktionen, mit deren Hilfe eine Community unterstützt werden kann, „Community-Features“ genannt werden.

Diese sollten laut der aufgestellten Arbeitsdefinition die Interaktion und Kommunikation der Spieler untereinander und die Suche nach Mitgliedern mit bestimmten Eigenschaften unterstützen und fördern. Um dies zu gewährleisten, müssen die Nutzer der Plattform sich zuallererst beschreiben und diese Beschreibung anderen präsentieren können. Dafür empfiehlt es sich, gleichbleibende benutzerspezifische Daten (Alter, Geschlecht, Herkunft etc.) mittels einer Datenbank persistent in einem Profil zu speichern. Der Spieler registriert sich einmalig auf der Plattform und wird zukünftig über seinen Benutzernamen identifiziert.

Die International Game Developers Association (IGDA) beschreibt in ihrem Casual Games Whitepaper, dass ein „community-based Gaming” typischerweise folgende Elemente be-inhaltet: „…chat, points based rewards systems, prizing, persistence features, tournaments, ladders, message boards and friend/buddy lists“ [IGDA2006, S. 18].

Im Folgenden wird auf einige der genannten Elemente, die als Ist-Situation konstatiert werden, genauer eingegangen. Außerdem werden Ergänzungsmöglichkeiten vorgestellt.

Einen Chat stellen die beiden in Kapitel 3.2 erwähnten großen deutschsprachigen Online-Spiele-Plattformen [GAMD2008] und [KING2008] zwar (meist) innerhalb eines Multiplayerspiels zur Verfügung. In der Lobby jedoch gibt es bei [GAMD2008] keine Möglichkeit zur Echtzeit-Kommunikation; bei [KING2008] muss der Nutzer sich erst durch zwei Menüpunkte klicken, um einen kleinen, schwach frequentierten Chat zu erreichen. Dies sollte in einer Social Gaming-Plattform anders gestaltet sein, da die Interaktion zwischen den Nutzern jederzeit gefördert werden und so auch außerhalb der Spiele ein Chat angeboten werden sollte, über den sich die User austauschen und zum Spielen verabreden können.

Für die Kommunikation innerhalb eines Spielraums bietet es sich an, diese zusätzlich zum zeichenbasierten Chat um eine visuelle und/oder auditive Komponente zu erweitern. Auch ist es denkbar, während des Spiels Zuschauer zuzulassen, die nicht aktiv in das Spielgeschehen eingreifen können, wie [SCJO2006] beschreibt:

„Social Gaming ist ein Spielablauf, der den Spieler nicht isoliert und unerreichbar in eine Welt versetzt, sondern eine Art zu spielen, bei der Menschen irgendwie dabei sind. Das kann als Zuschauer sein, kann aber [...] auch als echter Mit- oder Gegenspieler sein.“

Um soziale Aspekte wie Stolz, Rivalität, Zusammenhalt oder Wettbewerb zu betonen und so ein echtes „Social Gaming-Erlebnis“ zu schaffen, kann außerdem ein Community-Feature angedacht werden, das es erlaubt, Spielsequenzen in begrenzter Länge aufzunehmen und anschließend für andere Nutzer einseh- und kommentierbar zu machen.

Das Belohnungssystem einer Social Gaming-Plattform kann entweder über „Spielgeld“, andere Arten von virtuellen Einheiten (im Weiteren „Coins“ genannt) oder auch Echtgeld funktionieren. Letzteres setzt in Deutschland voraus, dass die Spiele „skill-based“ sind, das heißt, nicht vorrangig durch Glück gewonnen werden können (siehe §285 STGB). Dabei ist es wichtig, ein faires Spiel garantieren zu können, indem ein „Ranking System“, eine Spielstärke, eingeführt wird, welche für jedes Spiel unterschiedlich ist. Dieses System unterstützt wiederum den sozialen Vergleich und ermöglicht es dem Betreiber einer Social Gaming-Plattform unter anderem, Bestenlisten zu erstellen und eine „Hall of Fame“ einzurichten.

4 Konzeption des Prototypen

Im Folgenden wird die Konzeption des Prototypen der zu entwickelnden Social Gaming-Plattform beschrieben. Den Ausgangspunkt bilden dabei die aus in Kapitel 4.1 dargelegten Gründen gewählten Techniken. Anschließend werden die Möglichkeiten einer Architektur der Plattform herausgearbeitet (Kapitel 4.2). Schließlich beschreibt Kapitel 4.3 die geplanten Funktionalitäten des Prototypen.

4.1 Festgelegte Techniken

Das für diese Arbeit als Testobjekt festgelegte Framework Ruby on Rails verspricht eine agile Entwicklung von Webapplikationen, welche auch innovative Geschäftsprozesse bestmöglich unterstützt. Agilität bedeutet für das Prototyping eine flexible, iterative und leichtgewichtige Vorgehensweise, mit der in kurzer Zeit ein robustes System entwickeln werden kann. Dabei sind keine detaillierten Spezifikationen, wie aus der klassischen Softwareentwicklung bekannt, notwendig. Mittels planorientierter Vorgehensweisen geht dort das Design (der Architektur) der Implementierung voraus, der Ablauf ist regelgesteuert und auf Meilensteine fokussiert.

Durch die agile Vorgehensweise von Ruby on Rails nimmt der Autor an, dass es sich optimal für eine zeitnahe, prototypische Umsetzung der Anforderungen eignet, was im weiteren Verlauf dieser Arbeit überprüft werden soll.

Neben der Festlegung auf das Framework Ruby on Rails für das Prototyping der Community-Features ist die Wahl der für das Spieler-Frontend eingesetzten Technologie für die Konzeption des Prototypen von Bedeutung. Obwohl es denkbar wäre, Echtzeit-Spiele einer Social Gaming-Plattform direkt über einen nativen Browser zu spielen (z.B. per AJAX, siehe Kapitel 5.6), empfiehlt sich dessen Erweiterung durch Plugins wie z.B. Flash, Java, Shockwave oder Silverlight, mit deren Hilfe eine wesentlich höhere Spielkomplexität und bessere Grafikeigenschaften erzielt werden.

Die zukünftige Plattform soll auf Grund ihrer kommerziellen Ausrichtung möglichst vielen Nutzern, unabhängig von Browser und Betriebssystem, die Möglichkeit bieten, Spiele in gleich hoher Qualität erleben zu können. Daher bietet es sich an, den aktuellen Flash Player 9 von Adobe zu verwenden, da dieser zu 98,8% auf dem Weltmarkt verbreitet ist (vgl. [ADOB2007a]) und er sich durch sein schnelles Rendern von Vektorgrafiken für die Spieleentwicklung eignet (Kapitel 6.1). Darüber hinaus bietet Adobe Flash Schnittstellen zu physikalisch entfernten Servern, welche essentiell für die Multiplayer-Programmierung sind.

Für die Datenhaltung wird die bewährte Open-Source-Datenbank MySQL verwendet.

4.2 Architektur der Plattform

Die Gesamtarchitektur der Plattform besteht aus der Multiplayer-Architektur und der Architektur der Community-Features.

Hinsichtlich der Multiplayer-Architektur der Plattform werden zwei Ansätze in Betracht gezogen: Die Peer-to-Peer- und die Client-Server-Architektur.

In einer Peer-to-Peer-Architektur tauschen die einzelnen Peers (beispielsweise Spieler-Frontends) Daten direkt aus und verwalten ein eigenes Abbild der aktuellen Spielsituation. Jeder Peer fungiert als Entscheidungsträger und sendet die getroffenen Entscheidungen anschließend an alle verbundenen Peers weiter.

In einer Client-Server-Architektur hingegen verwaltet eine zentrale Instanz ((Game-)Server) die aktuelle Spielsituation. Dieser berechnet die Auswirkungen einer bestimmten Aktion, trifft eine Entscheidung und/oder leitet diese an die jeweiligen Clients weiter. [BARR2001, S. 52ff]

Auf den ersten Blick scheint eine Peer-to-Peer-Architektur geeigneter, da durch den Entfall des Servers eine geringere Latenzzeit entsteht. „Latenz ist die Zeitspanne, die benötigt wird, um Daten von einem Client zum Server zu übertragen“ [MAKA2004, S. 365]. Für die Multiplayer-Spiele der geplanten Social Gaming-Plattform ist dieser Ansatz jedoch nicht zweckmäßig, da als Technologie Adobe Flash verwendet wird und diese, auf Grund des Sandbox-Prinzips (siehe [ADOB2008]), keinen direkten Datenaustausch zwischen verteilten Anwendungen erlaubt.

In Bezug auf die Community-Features gestalten sich die Überlegungen zur Architektur wesentlich einfacher. Plattformen, auf denen das Online Social Gaming basiert, sind Webapplikationen und werden infolgedessen zentral auf einem Webserver ausgeführt. Die Interaktion des Servers mit dem Benutzer (Client) erfolgt über den Browser und einen Kommunikationsdienst. Ob dies via Internet oder (Firmen-)Intranet funktioniert, ist grundsätzlich irrelevant: „A Web Application is a software application that’s accessed using a web browser over a network. In most cases, that network is the Internet, but it could also be a corporate intranet.” [LENZ2007, S. 24f] In dieser Arbeit ist jedoch stets die Variante über das Internet gemeint.

Ein weiterer Aspekt hinsichtlich der Architektur der Plattform ist die Möglichkeit des Datenaustauschs. Als Kommunikationsdienste zwischen Client und Server dienen häufig standardisierte Übertragungsprotokolle wie z.B. HTTP für das Übertragen von Webseiten. Dieses Protokoll ist für die Umsetzung der Community-Features geeignet. Da es verbindungs- und zustandslos ist und somit eine eindeutige Zuordnung einer Anfrage zu einem Nutzer prinzipiell nicht möglich ist, empfiehlt sich allerdings für die Realisierung der Multiplayer-Elemente der Social Gaming-Plattform eine zustandsorientierte Verbindung, die deren Echtzeitcharakter gerecht wird.

Da als Client ein Browser mit dem Adobe Flash-Plugin verwendet wird, ist der Datenaustausch auf die zwei folgenden Möglichkeiten beschränkt:

- Flash Remoting

Diese serverseitige Technologie stellt einen Gateway zwischen dem Flash-Player und (entfernten) Diensten zur Verfügung. Ein Dienst kann von einem einfachen PHP-Skript bis hin zu Applikationsservern reichen und u.a. für Datenbankabfragen, E-Mail-Versand oder zur Nutzung von Webservices verwendet werden. [MUCK2003, S. 4]

- Socketverbindung

Seit ActionScript Version 1.0 gibt es die Möglichkeit, in Adobe Flash Daten über so genannte Sockets auszutauschen. Ein Socket bildet das Ende einer Kommunikationsschnittstelle und wird durch eine Kombination von IP-Adresse und Port-Nummer repräsentiert.

Flash Remoting ermöglicht eine zeitnahe Implementierung externer Schnittstellen. Nachteilig ist jedoch, dass der Server keine Daten direkt an den Flash-Player übertragen kann, sofern dieser sie nicht explizit angefordert hat. Für eine Multiplayer-Anwendung in Flash ist diese Restriktion aber eine grundlegende Anforderung, da sonst nur über Umwege (z.B. Datenbank als Schnittstelle) Änderungen von anderen Clients mitgeteilt werden können und diese auch permanent in einem bestimmten Intervall überprüft werden müssten. Auf Grund der dadurch zu erwartenden Performanceeinbußen in der Multiplayer-Spieleentwicklung fällt die Wahl für die zu entwickelnde Social Gaming-Plattform auf einen Socket-Server (Kapitel 6.3), welcher eine dauerhafte, zustandsoriente Verbindung von Clients erlaubt.

Abbildung 4-1 zeigt die geplante Gesamtarchitektur der Social Gaming-Plattform.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4-1: Geplante Architektur der Social Gaming-Plattform

Als Client in dieser Architektur fungiert ein Browser, der für die Multiplayer-Elemente mit einem Flash-Plugin erweitert wird. Da dieses separat mit dem Socket-Server kommuniziert, wird nachfolgend die Bezeichnung „Flash-Client“ verwendet. Wie auch die Community-Module wird der Flash-Client über die HTTP-Verbindung des Web-Servers aufgerufen, die Kommunikation mit dem Socket-Server findet jedoch ausschließlich über die permanente Socket-Verbindung statt. Kapitel 5.4 enthält den detaillierten Ablauf einer Anfrage des Browsers an das Rails-Framework.

Als zentrale Schnittstelle für den Datenaustausch zwischen den Community- und Multiplayer-Elementen dient eine MySQL-Datenbank. Physikalisch gesehen können Socket-, Datenbank- und Web-Server auf dem gleichen Server laufen.

4.3 Geplante Funktionalitäten

Nachfolgend werden die Module der geplanten Social Gaming-Plattform beschrieben. Der in Kapitel 7 und 8 entwickelte Prototyp enthält die minimalen Kernfunktionalitäten der Module einer solchen Plattform, welche für die in dieser Arbeit festgelegten Anforderungen notwendig sind (horizontales Prototyping). Abbildung 4-2 zeigt alle geplanten Module:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4-2: Geplante Module der Social Gaming-Plattform

Je nach Modul können Inhalte nur von eingeloggten Benutzern gelesen bzw. verändert werden. Für die uneingeschränkte Nutzung der Plattform ist eine einmalige Registrierung mit einem Benutzernamen notwendig.

Öffentliche Module der Plattform:

- Login/Registrierung

Für die Nutzung der Plattform ist eine einmalige Registrierung mit einem eindeutigen Benutzernamen notwendig. Bevor bestimmte Bereiche der Plattform aufgerufen werden können, ist ein vorheriger Login notwendig.

- Öffentliche Profilseite

Zeigt alle Informationen (Avatar, Alter, Geschlecht, Lieblingsspiel etc.) zu einem Benutzer an. Weiterhin können über die Profilseite das Mini-Feed, die Freunde und die Pinnwand aufgelistet werden.

- Mini-Feed

Das Mini-Feed zeigt alle Aktivitäten (Spiel gewonnen/verloren, neue Freundschaften/Pinnwandeintrag etc.) eines bestimmten Benutzers auf der jeweiligen Profilseite an.

- Pinnwand

Auf der Pinnwand eines Profils können andere Benutzer Gästebucheinträge hinterlassen, welche vom Profilinhaber kommentiert werden können.

- Spielstatistiken

Zeigt die Statistik (Spielstärke, Spiele gewonnen/verloren etc.) aller Spiele eines Benutzers an.

- Community-Startseite/Blog

Auf der Community-Startseite werden – neben dem Community-Blog – neu registrierte und aktuell eingeloggte Benutzer aufgelistet. Zusätzlich können registrierte Benutzer einzelne Blog-Einträge kommentieren.

Module der Plattform für registrierte Benutzer:

- Accountverwaltung (Dashboard)

Dieser Bereich dient als zentrale Anlaufstelle für die Verwaltung aller relevanten Informationen, die das eigene Benutzerkonto (Account) betreffen.

- Nachrichten

Zwischen Benutzern der Plattform können Nachrichten verschickt werden und über einen Posteingang gelesen werden.

- Freundesnetzwerk

Das Freundesnetzwerk enthält Freundesanfragen- und -absagen, sowie eine Übersicht aller Freunde eines Benutzers.

- Benutzersuche

Als Teil der Community-Funktionen können Benutzer nach bestimmten Suchkriterien (Benutzername, Alter, Geschlecht, Online-Status) gefiltert werden.

- Spielinformationen

Dieses Modul enthält eine Auflistung aller verfügbaren Spiele der Social Gaming-Plattform mit der dazugehörigen Kurzbeschreibung. Im Umfang des Prototypen enthält diese Seite nur das Referenz-Puzzle-Spiel. Nachdem ein Spiel beendet wurde und ein Gewinner feststeht, wird eine Spieldetail-Seite mit allen relevanten Informationen über dieses Spiel angezeigt.

- Lobby

Die Lobby enthält als Sammelpunkt für die Spieler eine Liste aller dort eingeloggten Benutzer, eine Chat-Funktion, um sich zum Spielen verabreden zu können, sowie eine Liste aller verfügbaren Spielräume. Benutzer können entweder selbst ein Spiel erstellen oder an einem bereits vorhandenen, noch nicht gestarteten Spiel teilnehmen.

- Casual Games

Theoretisch soll es bei den Casual Games der Plattform möglich sein, gegen jeden beliebigen Nutzer anzutreten. Um die Spiele trotzdem fair zu gestalten, wird ein System gewählt, welches eine Berechnung der Spielstärke auf Basis der des Gegners erlaubt (siehe 8.4.2). So profitiert ein Spieler, wenn er einen überlegenen Spieler als Gegner auswählt, im Gewinnfall durch eine entsprechend höhere neue Spielstärke. Als Demonstration der Multiplayer-Elemente wird ein Casual Game mit Puzzle-Charakter verwendet (Kapitel 8.4).

Aufwändigere Features wie die Aufnahme- und Zuschaueroption der Spiele, das Forum und eigene Blogs der Benutzer sind auf Grund des begrenzten Umfangs dieser Arbeit nicht Bestandteil des Protoypen.

Die umgesetzte Social Gaming-Plattform ist als reiner Prototyp zu verstehen, bei dem der Fokus auf der Funktionalität und nicht auf dem grafischen Design oder der inhaltlichen Korrektheit der verwendeten Daten liegt. Nichtsdestotrotz wurde parallel zu dieser Arbeit ein Design erstellt und in CSS umgesetzt, um den grundsätzlichen Web 2.0-Charakter des Prototypen auch im Design widerzuspiegeln (Anhang B).

5 Das Web-Framework Ruby on Rails

„ Ruby on Rails verringert die Barrieren für den Einstieg ins Programmieren. Gewaltige Webapplikationen, die bisher in Wochen oder Monaten programmiert wurden, können nun in wenigen Tagen entwickelt werden.“ Tim O’Reilly, in [LANGE2007, S. 18]

Der dänische Programmierer David Heinemeier Hansson entwickelte im Jahr 2003 auf Grundlage der Programmiersprache Ruby das webbasierte Projektmanagement-Tool „Basecamp“ für die Firma 37signals. Ein halbes Jahr später gelang es ihm, grundlegende Funktionalitäten aus der Anwendung zu extrahieren, die universell einsetzbar waren. Daraufhin veröffentlichte er Anfang 2004 die Beta-Version des Web-Frameworks Ruby on Rails unter der Open Source-Lizenz MIT, welche die freie Wiederverwendung von Software gestattet. Dank einer schnell wachsenden Community haben Rails-Entwickler bis heute bereits mehrere tausend frei zugängliche Erweiterungen publiziert und Fehler behoben haben. [CARL2007, S. 153]

Im folgenden Kapitel soll zunächst die Rails zu Grunde liegende Programmiersprache Ruby kurz vorgestellt werden. Anschließend werden allgemeine und speziell für diese Arbeit benötigte Komponenten für die Entwicklung mit Ruby on Rails angegeben (Kapitel 5.2). Kapitel 5.3 nennt grundlegende Bestandteile und Eigenschaften des Frameworks. Nachdem in 5.4 die Architektur des Frameworks dargestellt wurde, werden die Programmierparadigmen unter Ruby on Rails in Kapitel 5.5 näher erläutert. Die für die Entwicklung von Webanwendungen wichtig gewordene Technik AJAX, welche von Ruby on Rails unterstützt wird, beschreibt Kapitel 5.6. Zuletzt wird die für eine agile Prototypenentwicklung wichtige integrierte Testumgebung erörtert.

5.1 Die Programmiersprache Ruby

„Ruby is simple in appearance, but is very complex inside, just like our human body” - Yukihiro Matsumoto, in [RUBY2008]

Ruby on Rails basiert auf der Programmiersprache Ruby, die bereits 1995 von Yukihiro Matsumoto in Japan veröffentlicht wurde, aber erst um das Jahr 2000 herum in der westlichen Welt Aufmerksamkeit erregte. Als einfache, vollständig objektorientierte Skriptsprache verzichtet Ruby auf eine komplizierte Syntax und ist stark an die natürliche Sprache angelehnt, so dass Ruby-Code auf Anhieb gut verständlich ist [CARL2007, S. 4]:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5-1: Einfache Beispielsausdrücke in Ruby

Die in Abbildung 5-1 aufgeführten Ausdrücke erzeugen die folgende Ausgabe:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5-2: Ausgabe der Beispielsausdrücke in Ruby

Eine Ruby-Variable ist im Lauf ihrer Existenz nicht auf einen bestimmten Datentyp festgelegt, sondern kann unterschiedliche Wertetypen annehmen, welche die Skriptsprache automatisch erkennt. Für diese stark dynamische Typisierung wurde speziell für Ruby der Begriff „Duck Typing“ geprägt [KERS2007, S. 47].

Darüber hinaus können Klassen in Ruby jederzeit erweitert werden. So könnte der Basisdatentyp Integer (in Ruby ebenfalls ein Objekt) um eine Funktion is_prime_number erweitert werden, um zu prüfen, ob die entsprechende Zahl eine Primzahl ist. In Java oder C# müsste vergleichsweise die Klasse erst von einer Unterklasse erben, um mit eigenen Methoden erweitert werden zu können. Werden in Ruby Methoden verwendet, die während der Laufzeit nicht existieren, können diese über eine Methode namens method_missing abgefangen und neu definiert werden. Diese Vorgehensweise findet beispielsweise bei dynamischen Findern (siehe Kapitel 7.3.2.1) statt. Zusätzlich vereinfachen Iteratoren die Ausführung wiederholter Aufrufe. [RUBY2008]

Eine weitere Besonderheit von Ruby ist es, dass Sonderzeichen zur Trennung von Kommandos wie beispielsweise Klammern oder Semikola bei der Programmierung weggelassen werden können, sofern eine Eindeutigkeit einer Befehlsfolge vorliegt. Gültigkeitsbereiche von Variablen werden nur durch vorangestellte Zeichen geregelt. Ein Variablenname ohne Vorzeichen repräsentiert eine lokale Variable, @ eine Instanzvariable und $ eine globale Variable. Weiterhin kann über einen Doppelpunkt als Vorzeichen ein Symbol erstellt werden; gleichlautende Symbole referenzieren immer auf das gleiche Objekt und werden üblicherweise bei der Parameterübergabe verwendet. [RUBY2008]

5.2 Zur Installation benötigte Komponenten

Zur Erstellung des geplanten Prototypen wird das Windows-Betriebssystem verwendet. Daher werden für eine datenbankbasierte Ruby on Rails-Webanwendung im Umfang dieser Arbeit folgende Komponenten benötigt [LENZ2007, S. 15f]:

- Ruby language interpreter (Version 1.8.6)
- Ruby on Rails framework (Version 1.2.5)
- MySQL database server (da in dieser Arbeit mySQL verwendet wird; RoR unterstützt weitere Datenbank-Server wie z.B. PostgreSQL, Microsoft SQL Server oder auch Oracle)

Für Windows gibt es außerdem ein Setup namens „InstantRails“ mit allen relevanten Komponenten für die Rails-Entwicklung (analog dazu steht für das Mac OS-Betriebssystem die Installationshilfe Locomotive zur Verfügung). Der darin enthaltene Apache-Server wird im Rahmen dieser Arbeit allerdings nicht benötigt. Für das hier geforderte Entwickeln und Testen einer Rails-Anwendung bietet sich der im Framework mitgelieferte, sofort lauffähige WEBrick-Webserver an, der sich in jedem Rails-Projekt einfach starten lässt. Um jedoch im weiteren Betrieb eine Rails-Webapplikation produktiv und skalierbar einzusetzen, sollte ein Apache-Webserver mit FastCGI oder der in Ruby geschriebene Mongrel-Server verwendet werden [WIBA2007, S. 195f].

Eine Entwicklungsumgebung (wie z.B. Microsoft Visual Studio für C# oder Borland JBuilder für Java) ist für RoR nicht erforderlich – ein einfacher Texteditor ist völlig ausreichend. In dieser Arbeit wird der „e“-Texteditor verwendet, der ein Bundle beinhaltet, das alle Konventionen zum Schreiben von Ruby-Text (Farb- und Formatierungsvorgaben), welche die Community mit dem Ziel eines besser lesbareren Codes festgelegt hat, unterstützt. Viele Entwickler der Ruby on Rails-Community arbeiten auf einem Macintosh und verwenden dafür den weit verbreiteten „Textmate“-Editor. Die Scriptsprache Ruby ist darüber hinaus bereits im Betriebssystem Mac OS X enthalten – das aktuelle Leopard (OS X 10.5) wird sogar mit Rails ausgeliefert [RORA2006a].

5.3 Grundlegende Bestandteile und Eigenschaften

Ein Web-Framework wie Ruby on Rails ermöglicht es Entwicklern dank einer Reihe von Werkzeugen und Bibliotheken, sich auf die eigentliche Problemstellung zu konzentrieren, ohne dabei für jede Webanwendung wiederkehrende Programmier-Aufgaben erledigen zu müssen. Das Rails-Framework enthält beispielsweise Code-Generatoren, die automatisch ein Code-Skelett für die Ausgestaltung der Anwendungslogik erstellen, sowie weitere nützliche Bestandteile, „etwa die integrierte Unterstützung von Web-Services, der Empfang eingehender E-Mails, AJAX (für in hohem Maße interaktive Web-Anwendungen), ein voll-ständiges Framework für Unit-Tests [...] sowie getrennte Umgebungen für Entwicklung, Tests und Produktion“ [HEHA2006, S. 2].

Ferner ist eine grundsätzliche „Agilität [...] Bestandteil der Struktur von Rails ... Es gibt [in Rails] keine schwergewichtigen Werkzeugsammlungen, keine komplizierten Konfigurationen und keine ausufernden Prozesse“ [HEHA2006, S. 3].

Diese agile Vorgehensweise wird durch folgende wichtige Bestandteile und Eigenschaften des Ruby on Rails-Frameworks unterstützt:

- Objektrelationales Mapping (ORM)

Objektrelationales Mapping „ ... steigert [...] die Effizienz beim Programmieren datenbankgestützter Webanwendungen enorm“ [CARL2007, S. 157]. Gemeint ist hier das Prinzip, in welcher Weise relationale Datenbanktabellen auf Klassen bzw. Objekte abgebildet werden können.

Gewöhnlich erstellen Programmierer für den Datenbankzugriff auf eine konkrete Tabelle ganze Programmteile. Diese Vorgehensweise ist bei einer Änderung der Datenbankstruktur äußerst ineffizient. ORM, und hier speziell das ORM von Ruby on Rails, stellt eine allgemeingültige Vorgehensweise zur Verfügung, um ein relationales Datenbankmodell in einem fertigen Model abzubilden und dabei das DRY- und Convention over Configuration-Prinzip zu berücksichtigen. „Aus einer Tabelle namens dogs zaubert Ihnen Ruby on Rails eine Klasse namens Dog.“ [CARL2007, S. 157f]

Assoziationen zwischen Modellklassen werden dabei mit verständlichen, vordefinierten Active Record-Deklarationen wie z.B. has_many, has_one oder belongs_to und der jeweiligen Bennungen der Fremdschlüssel-Spalte in der Datenbank beschrieben.

- Scaffolding und Code-Generatoren

Das so genannte Scaffolding (engl. für „Gerüstmaterial”) erzeugt automatisch ein Code-Skelett aller relevanten Methoden, um Daten manipulieren oder anzeigen zu können. Derartige grundlegende Funktionalitäten einer Web-Anwendung bezeichnet man als CRUD (Create, Read, Update and Delete). Der Programmierer kann sich so gezielt auf die Anwendungslogik konzentrieren. Scaffolding kann einerseits mittels Metaprogrammierung für eine schnelle prototypische Entwicklung genutzt und andererseits direkt als Ruby-Code in Dateien eingefügt und so später verfeinert werden. Neben dem Scaffolding bietet Rails noch weitere Generatoren, um den entsprechenden Ruby-Code für ein Model bzw. einen Controller laut Konvention (und nicht Konfiguration) zu erzeugen. [CARL2007, S. 161f]

- Sub-Frameworks

Rails enthält Sub-Frameworks, die die Entwicklung alltäglicher Aufgaben, wie z.B. Datums- und Währungsformatierungen, E-Mail-Versand oder die Nutzung und Erstellung von Web-Services, erleichtern. Das Zusammenspiel dieser Module wird in Kap. 5.1.2.2 detailliert aufgezeigt. Sollten die mitgelieferten Methoden nicht ausreichen, kann der Funktionsumfang von Rails-Anwendungen durch so genannte Plugins erweitert werden.

Darüber hinaus bietet Rails weitere Hilfsmittel und Komponenten, welche die Entwicklung und Optimierung von Rails-Anwendungen unterstützen:

- Rails-Konsole Mithilfe dieser Konsole kann direkt mit einer Rails-Anwendung interagiert werden. Objekte können so z.B. untersucht, modifiziert oder direkt in die Datenbank geschrieben werden.

- Unterschiedliche Entwicklungsumgebungen

Dem Entwickler stehen drei Standardumgebungen (Environments) zur Verfügung, die maßgeblich den jeweiligen Zweck berücksichtigen [CARL2007, S. 162]:

- Development-Environment Umgebung für den Entwicklungsprozess mit detaillierter Fehlerausgabe und diversen Debug-Informationen
- Test-Environment Testumgebung zur Überprüfung, ob die Anwendung sich durch Nachstellen möglicher Einsatzszenarien auch wie gewünscht verhält.
- Production-Environment Diese Umgebung ist für den produktiven und performanten Einsatz ausgelegt und besitzt keine Test- und Entwicklungswerkzeuge.

- Caching

Für die Entwicklung performanter Rails-Anwendungen unter hoher Last können dynamische Seiten nach ihrer initialen Erzeugung zwischengespeichert und bei Folgeanfragen aus dem Cache geladen werden. Rails unterscheidet das Caching in drei Varianten: Seiten-Caching, Action-Caching und Fragment-Caching. Seiten- und Action-Caching findet dabei auf Controller-Ebene statt, Fragment-Caching auf View-Ebene. [WIBA2007, S. 275]

- Sicherheit

Rails bietet die Grundlage für eine sichere Programmierung von Webanwendungen. Sicherheitslücken wie beispielsweise „SQL-Injection“ (Einschleusen fremder SQL-Anweisungen in die Datenbank) oder „Cross Side Scripting“ (XSS) – das Stehlen von Cookies anderer Benutzersitzungen (durch JavaScript-Code) – können durch das Rails-Framework geschlossen werden. ActiveRecord sorgt über die Binding-Funktionalität dafür, dass Rails für die Ersetzung bestimmter Platzhalter einer SQL-Anweisung verantwortlich ist. [WIBA2007, S. 267]

Um XSS-Attacken, und somit die Einbindung von fremden JavaScript-Code, zu verhindern, bietet Rails die Möglichkeit HTML-Meta-Zeichen (z.B. „<“ bzw. „>“) in die entsprechenden HTML-Entitäten („&lt;“ bzw. „&gt;“) zu konvertieren.

5.4 Paradigmen

„Jeder Programmiersprache liegt ein bestimmtes Konzept zugrunde, ein bestimmtes Be-griffssystem, mit dem die Lösung gefaßt [sic!] (konzipiert) wird. Dieses Konzept nennt man auch (...) ihr Paradigma (griechisch, eigentlich: „Musterbeispiel“).“ [APPE2000, S. 239]

Die drei folgenden Programmierparadigmen von Ruby on Rails wurden in Kapitel 5.3 absichtlich ausgeklammert, da sie als essentielle Bestandteile einer näheren Betrachtung wert sind. Sie beeinflussen wesentlich die Entwicklung mit Ruby on Rails in Hinsicht auf Dauer und spätere Wartbarkeit.

5.4.1 Model View Controller (MVC)

„Das MVC-Entwurfsmuster besagt, dass die Entwicklung einer Software mit grafischer Benutzeroberfläche in drei voneinander relativ unabhängigen, getrennten Schichten stattfinden soll.“ [CARL2007, S. 155]

Dieses Pattern ist keine Erfindung von Rails. Bereits in den 1970er Jahren schuf Trygve Reenskaug eine neue Architektur für die Entwicklung von interaktiven Anwendungen, die eine Aufteilung in drei Komponententypen (Models, Views und Controller) vorsieht. [HEHA2006, S.11]

Das Model verwaltet den Zustand einer Anwendung, der entweder flüchtig und nur für kurze Interaktionen mit dem Benutzer benötigt wird, oder persistent ist und in einer Datenbank gespeichert werden muss. Darüber hinaus sorgt eine Einhaltung der Geschäftslogik dafür, dass die Daten durch die Anwendung nicht verfälscht werden können. „Das Modell dient sowohl als Aufpasser als auch als Datenträger“ [HEHA2006, S.11].

Auf Basis der Daten im Model erzeugt der View (die Ansicht) eine Benutzerschnittstelle mit der gesamten Präsentationslogik. Um eine Software letztendlich bedienen zu können, stellt ein View dem Benutzer Elemente zur Anzeige und Speicherung von Daten zur Verfügung. Ruby on Rails setzt diese Views-Schicht auf Basis von Templates (HTML, JavaScript oder XML) und integriertem erb-Ruby-Code („embedded Ruby“) um. [CARL2007, S. 156]

Der Controller übernimmt als Steuerungsschicht die Koordination zwischen Model und View. Er fordert Daten an und leitet diese an den View zur Darstellung weiter und vice versa.

Ruby on Rails verwendet für die Darstellung von URLs „PrettyURLs“ [RORA2006b]. Diese können vom Benutzer leichter gelesen und verstanden werden.

Die URL „http://mein.url/store/add_to_cart/123“ fügt beispielsweise das Produkt mit der ID 123 dem Warenkorb in einem Online-Shop hinzu.

Das folgende Abbildung veranschaulicht die Vorgehensweise von Rails bei einer eingehenden (URL-)Anfrage:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5-3: Rails und MVC (modifiziert nach [HEHA2006, S. 13])

Die Routing-Komponente zerlegt die eingehende Anfrage „http://mein.url/store/add_to_cart/ 123“ in ihre Bestandteile. Der erste Teil des Pfades repräsentiert den Controller-Namen store, der zweite Teil (add_to_cart) den Namen der Aktion. Gemäß der Konvention wird der letzte Teil 123 als interner Parameter namens id verwendet, die Methode add_to_ cart()automatisch im Controller StoreController aufgerufen und das Produkt mit der ID 123 in die Datenbank eingetragen. [HEHA2006, S. 14f]

5.4.2 Convention over Configuration

Für die Entwicklung einer Ruby on Rails-Anwendung sind, im Gegensatz zu anderen Programmiersprachen, die meist in Form von XML-Dateien konfiguriert werden, nur wenig Konfigurationsparameter notwendig. Das Paradigma „Konvention vor Konfiguration“ gibt vor, vernünftige Standardwerte statt einer expliziten Konfiguration zu verwenden. Ein Beispiel dafür ist die in Abbildung 5-5 gezeigte 1:n-Beziehung der beiden Datenbanktabellen „users“ und „projects“:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5-4: 1:n-Mapping einer Datenbanktabelle

Um die kleingeschriebenen, im Plural angegebenen Tabellennamen „users“ und „projects“ aus den Klassennamen User und Project abzuleiten, verwendet Rails die so genannte Introspek-tion. Für die 1:n-Datenbankrelation kommt ebenfalls „Convention over Configuration“ zum Einsatz. Das Framework nimmt an, dass die Tabelle „projects“ eine Spalte „user_id“ als Fremdschlüssel enthält. „Konventionen ersetzen [sic!] niemals Konfiguration“ [RAYM 2007, S. 12], daher können diese Standardwerte selbstverständlich auch überschrieben werden. [RAYM2007, S. 12f]

Das Relevance-Team [RELE2005] dokumentiert die Portierung einer Web-Anwendung von Java auf Ruby on Rails. Das Resultat ist (neben einem Geschwindigkeitsvorteil von 15-30%) ein Code-Umfang, der in Java alleine durch die Konfigurationsdateien abgedeckt werden würde.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 5-1: Detaillierte Ergebnisse der Portierung auf Ruby on Rails (nach [RELE2005])

5.4.3 Don’t repeat yourself (DRY)

„Das DRY-Prinzip besagt, dass Wissen nur eine einzige, eindeutige Repräsentation in einem System hat“ [WIBA2007, S. 8]. Das Ziel von DRY ist es, redundante Informationen zu vermeiden, da dies unweigerlich einen Programmfehler zur Folge hat, falls z.B. bei redundanten Variablen nur eine der beiden Variablen geändert wird. Angefangen von Symbolen und globalen Konstanten bis hin zum automatischen Mappen der Datenbankspalten bietet Rails als „Full-Stack-Framework“ die Grundlage für das konsequente Einhalten des DRY-Paradigmas. „Full Stack bedeutet, dass jede Information, die einem Teil des Programms (Model, View oder Controller) erzeugt wird, in den anderen verfügbar ist“ [CARL2007, S. 157].

Um das DRY-Prinzip einzuhalten, werden meist „Partial Views“ oder „Helper“ verwendet. Partial Views sind Templates, denen aus dem aufrufenden Template Daten übergeben werden. Diese werden anschließend an unterschiedlichen Stellen auf der Webseite angezeigt. Per Konvention beginnen Partial Views immer mit einem Unterstrich [WIBA2007, S.170]. Helper enthalten in Methoden ausgelagerte, komplexe, mehrfach verwendbare Code-Stücke, die normalerweise in HTML-Templates als Ruby-Code vorhanden sind. Für jeden Controller existiert jeweils ein eigener Helper. Ein ähnliches Prinzip wird auch bei der Verwendung von Cascading Style Sheets (CSS) angewandt, um die Gestaltung einer Webseite zentral ändern zu können.

5.5 Architektur des Frameworks

Abbildung 5-3 zeigt alle Komponenten von Ruby on Rails und deren Interaktion:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5-5: Bestandteile und Zusammenspiel (nach [WIBA2007, S. 10])

Der Web-Server empfängt den vom Client gesendeten Request und leitet diesen an den Dispatcher weiter. Der Dispatcher, welcher selbst ein Ruby-Programm ist, deligiert die Anfrage an den jeweils zuständigen Controller. Jeder Controller basiert auf dem Framework „Action Controller“ und führt in der Regel Aktionen wie „Erzeugen“ und „Lesen“ auf einem Domain-Objekt aus. Ein Domain-Objekt nutzt das „Active Record“-Framework, welches u.a. die Verbindung zu den Datenbanktabellen bereitstellt und dabei auch die übergebenen

Parameter validieren kann. Anschließend leitet der Controller auf einen anderen Controller weiter oder beginnt mit der Auslieferung der Antwort, welche typischerweise aus einem, mittels „Action View“ erzeugtem, HTML View besteht. Eine Anfrage von einem Web-Service beantwortet ein Controller mit Hilfe des „Action Web Service“ durch ein XML-Dokument. Über das „Action Mailer“-Framework können wahlweise eine oder mehrere E-Mails versendet werden. [WIBA2007, S. 10f]

5.6 AJAX

Wie zu Beginn dieser Arbeit erwähnt, ist eine der zentralen Web 2.0-Technologien AJAX. Der Begriff wurde vom US-Amerikaner Jesse James Garret geprägt und steht für Asynchronous JavaScript und eXtensible Markup Language (XML). Diese Sammlung von Technologien ermöglicht, im Gegensatz zu klassischen Web-Anwendungen, die nach dem Request-/Response-Modell („Request Cycle“) arbeiten, über eine in JavaScript geschriebene AJAX-Engine asynchrone HTTP-Anfragen des Clients an den Server. Der Anwender erhält eine dynamische Oberfläche, ohne die Seite stets komplett neu laden zu müssen. [WIBA2007, S. 238]

Als zentrale Bestandteile von AJAX nennt Garret das Document Object Model (DOM), XMLHttpRequest und JavaScript. XMLHttpRequest dient dabei als API für den Transfer beliebiger Daten über das HTTP-Protokoll. [GARR2005]

Abbildung 5-6 verdeutlicht den Unterschied zwischen synchronen, klassischen Web-Anwendungen und asynchronen Anwendungen mit einer AJAX-Engine.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5-6: Synchrone und asynchrone Kommunikation im Vergleich (nach [WIBA2007, S. 239])

Technisch gesehen wird nach dem Klick auf ein JavaScript-Ereignis am Client eine Anfrage mittels XMLHttpRequest an den Server geschickt. Dieser verarbeitet die Anfrage und generiert die passende Antwort, welche in einem bestimmten Format an den Client zurückgeschickt wird. Dieser interpretiert die Antwort und passt die nach wie vor unveränderte Seite mittels Zugriff auf das Document Object Model entsprechend an. Wie in Abbildung 5-6 dargestellt, sind bei einer AJAX-Anwendung die Zeitspannen, die der Client nach einer HTTP-Anfrage blockiert, wesentlich kürzer, obwohl die Request-Bearbeitungszeiten bei beiden Techniken identisch sind.

Als eines der ersten Frameworks bietet Rails eine umfangreiche AJAX-Unterstützung an: Die Integration der JavaScript-Bibliotheken „Prototype“ und „Script.aculo.us“ vereinfachen die Entwicklung sowohl mit AJAX als auch mit JavaScript. Seit Rails Version 1.1 können neben den üblichen HTML-Templates so genannte Remote JavaScript Templates (RJS) eingesetzt werden. Der von den RJS Templates erzeugte JavaScript-Code ermöglicht es, mehrere Bereiche einer Webseite gleichzeitig zu aktualisieren, ohne die ganze Seite neu laden zu müssen. Eine Programmierung ist auch ohne umfangreiche JavaScript-Kenntnisse möglich, da die Templates in Ruby programmiert werden. [WIBA2007, S. 257f]

5.7 Integrierte Testumgebung

Gerade bei der in dieser Arbeit anzuwendenden agilen Softwareentwicklung ist es auf Grund der flexiblen Programmierweise und den daraus resultierenden iterativen Abschnitten, in denen der Code während des Prototypings entwickelt wird, dringend notwendig, bereits während der Implementierung zu prüfen, ob sich der Prototyp wie gewünscht verhält. Ruby on Rails enthält hierzu eine integrierte Testumgebung, welche mit einer von der Development-Umgebung abweichenden Konfiguration und einer separaten Datenbank verwendet werden kann.

In RoR sind folgende Testtypen möglich [FERN2008, S. 545-552]:

- Unit Tests

Unit Tests werden isoliert vom Gesamtsystem ausgeführt und benachrichtigen den Entwickler nach der automatischen Ausführung über aufgetretene Fehler. Unit Tests werden in Ruby on Rails für das Testen von Models verwendet.

- Functional Tests

Mit Hilfe von Functional Tests können mit „TestRequests“ und „TestResponses“ spezifische Controller-Actions (Methodenaufrufe in Controllern) getestet. So kann beispielsweise der Erfolg einer Anfrage, die Authentifizierung oder die Weiterleitung zu einer anderen Seite überprüft werden.

- Integration Tests

Integration Tests können zum Test komplexer Szenarien verwendet werden. Dabei werden unterschiedliche Controller einbezogen und deren Interaktion überprüft.

- Mocks

Mocks werden beispielsweise dann benötigt, wenn die Testumgebung externe Schnittstellen wie Payment-Gateways oder Webservices verwendet, und diese während der Tests keine Transaktionen auslösen sollen.

Im Allgemeinen wird eine Rails-Anwendung durch Simulation eines bestimmten Anwendungsfalls getestet. Als Testdaten werden im YAML-Format (Yet Another Markup Language) strukturierte Datensätze („Fixtures“) verwendet, welche während der Tests in die (Test-)- Datenbank eingetragen werden. Der Ablauf eines Tests wird über Behauptungen („Asser-tions“) gesteuert. Assertions formulieren Annahmen in Form erwarteter Ergebnisse.

6 Multiplayer-Architektur

Wie in Kapitel 4.1 festgelegt, wird die Multiplayer-Architektur auf Basis von Adobe Flash und mit Hilfe eines Socket-Servers umgesetzt. Nachfolgend werden deshalb zunächst die Grundlagen von Adobe Flash erläutert. Kapitel 6.2 befasst sich mit der zu Adobe Flash gehörigen Programmiersprache ActionScript. Anschließend werden die Wahl eines passenden Socket-Servers und dessen Eigenschaften (Kapitel 6.3) aufgezeigt. Kapitel 6.4 nennt schließlich für Multiplayer-Spiele wichtige Game Design-Patterns, die beachtet werden sollen.

6.1 Adobe Flash

„Flash with ActionScript 3.0 is a great, practical way to make small and medium-size games.“ [ROZW2008, S. 2]

Anfänglich nur als Entwicklungsumgebung für einfache Animationen verwendet, lassen sich bereits seit 1999 durch die Einführung der dazugehörigen Programmiersprache ActionScript Spiele in Adobe Flash entwickeln.

Auf Grund des begrenzten Umfangs der Diplomarbeit werden hier nur grundlegende Eigenschaften von Adobe Flash und ActionScript erklärt, die für das weitere Verständnis der Arbeit relevant sind.

6.1.1 Entwicklungsmöglichkeiten

Adobe bietet folgende Produkte für die Erstellung eines Flash-Films (SWF-Datei) an [MOOC2007, S. XXVf]:

- Adobe Flash CS3 Authoring-Tool

Das Authoring Tool ist eine Entwicklungsumgebung, mit der visuelle Komponenten wie z.B. Video, Audio und Grafiken mit ActionScript kombinieren werden können. Hier kann der Actionscript-Code direkt auf Objekte gesetzt werden oder zur besseren Strukturierung und Wartbarkeit in externe Dateien ausgelagert werden.

- Adobe Flex Builder

Der Flex Builder enthält ein Framework für MXML, eine XML-basierte Sprache, mit deren Hilfe das Aussehen von Benutzer-Interfaces einfach verändert werden kann. Er basiert komplett auf Eclipse, einer populären Open-Source-Entwicklungsumgebung.

- Adobe Flex 2 Software Development Kit (SDK)

Adobe Flex 2 SDK ist ein kommandozeilenbasiertes Hilfsmittel, anhand dessen sich Inhalte entweder mit ActionScript 3.0 oder MXML erstellen lassen. Mit diesem SDK ist es möglich, auch Adobe-unabhängige Editoren zu verwenden.

[...]