Entwurf und Implementierung einer Middleware für mobile

Freie Universität Berlin
Institut für Informatik
Diplomarbeit
Entwurf und Implementierung einer
Middleware für mobile MMOGs
Betreuer: Prof. Dr.-Ing. habil. Jochen H. Schiller
Dipl.-Inform. Tobias Fritsch
Michael Schran
Matrikel-Nr. 3677732
Hänselstrasse 6
12057 Berlin
1
Eidesstattliche Erklärung
Hiermit erkläre ich an Eides statt, die Arbeit bis auf die dem Aufgabensteller bereits bekannte
Hilfe selbständig angefertigt, alle verwendeten Hilfsmittel vollständig und genau angegeben
und alles kenntlich gemacht zu haben, was aus Arbeiten anderer unverändert oder mit
Abänderung entnommen wurde.
Berlin, den 26. September 2006
3
Inhaltsverzeichnis
Abkürzungsverzeichnis ..........................................................................................................7
1.
2.
Einleitung........................................................................................................................9
1.1.
Motivation ...............................................................................................................9
1.2.
Aufgabenstellung ..................................................................................................10
1.3.
Aufbau der Arbeit ..................................................................................................11
Multiplayerspiele im Desktop- und Konsolenbereich.....................................................13
2.1.
2.1.1.
Actionspiele...................................................................................................14
2.1.2.
Strategiespiele ..............................................................................................16
2.1.3.
Abenteuerspiele / Adventures .......................................................................18
2.1.4.
Simulationen .................................................................................................19
2.1.5.
Sport- und Rennspiele...................................................................................20
2.2.
Technische Realisierungen für Multiplayer-Umgebungen..............................22
2.2.2.
Populäre Multiplayer-Genres.........................................................................27
Einführung in den MMOG-Bereich ........................................................................27
2.3.1.
Netzwerkstrukturen .......................................................................................28
2.3.2.
Beeinflussung der Spielbarkeit ......................................................................32
2.3.3.
Fallbeispiel: World of WarCraft......................................................................36
Mobile Netzwerke..........................................................................................................39
3.1.
Übertragungstechniken.........................................................................................40
3.1.1.
Bluetooth (802.15).........................................................................................40
3.1.2.
Wireless LAN (802.11) ..................................................................................41
3.1.3.
GSM und GPRS............................................................................................42
3.1.4.
UMTS............................................................................................................43
3.1.5.
WMAN (802.16) ............................................................................................45
3.2.
4.
Multiplayer-Spiele .................................................................................................22
2.2.1.
2.3.
3.
Allgemeine Computerspiel-Genres .......................................................................13
Beeinflussung drahtloser Kommunikation .............................................................45
3.2.1.
Netzauslastung und Zellatmung ....................................................................46
3.2.2.
Ausbreitung der Funksignale.........................................................................46
3.3.
Eignung drahtloser Übertragungstechniken für mobile Spiele ...............................47
3.4.
Einführung in Standortbasierte Dienste.................................................................48
3.4.1.
Global Positioning System (GPS)..................................................................48
3.4.2.
Netzwerk-basierte Positionsbestimmung.......................................................49
3.4.3.
Assisted GPS (A-GPS)..................................................................................50
3.4.4.
Weitere Ansätze............................................................................................51
Verwandte Arbeiten.......................................................................................................53
5
4.1.
Mobile MMOGs .................................................................................................... 53
4.1.1.
TibiaME ........................................................................................................ 53
4.1.2.
Undercover 2: Merc Wars............................................................................. 54
4.2.
Middleware für mobile Umgebungen.................................................................... 55
4.2.1.
5.
Entwurf und Implementierung der Middleware.............................................................. 59
5.1.
Middlewarekonzepte ............................................................................................ 59
5.2.
Middleware für MMOGs ....................................................................................... 60
5.2.1.
Vorteile......................................................................................................... 60
5.2.2.
Anforderungen ............................................................................................. 61
5.3.
Gaming-Schnittstelle .................................................................................... 62
5.3.2.
Netzwerk-Schnittstelle .................................................................................. 64
5.3.3.
Programmiersprache.................................................................................... 66
Entwurf und Implementierung .............................................................................. 66
5.4.1.
Struktur ........................................................................................................ 66
5.4.2.
Nachrichtensystem....................................................................................... 71
5.4.3.
Gesamtübersicht .......................................................................................... 77
5.4.4.
Area of Interest............................................................................................. 78
5.4.5.
Flooding Algorithmus.................................................................................... 79
5.5.
Implementierung in eine Anwendung ................................................................... 81
Evaluierung und Test.................................................................................................... 83
6.1.
Testumgebung und Vorgehensweise ................................................................... 83
6.2.
Verhalten des Flooding Algorithmus..................................................................... 86
6.2.1.
Erwarteter Versuchsausgang ....................................................................... 86
6.2.2.
Versuchsausgang und Auswertung .............................................................. 86
6.3.
7.
Design- und Implementierungskriterien ................................................................ 62
5.3.1.
5.4.
6.
GASP – Gaming Service Platform................................................................ 55
Einfluss der „Area of Interest“............................................................................... 88
6.3.1.
Erwarteter Versuchsausgang ....................................................................... 89
6.3.2.
Versuchsausgang......................................................................................... 89
Zusammenfassung und Ausblick .................................................................................. 91
7.1.
Gaming-Architekturen .......................................................................................... 92
7.2.
I/O Multiplexing .................................................................................................... 93
7.3.
Umsetzen eines Clients auf J2ME........................................................................ 93
7.4.
Location based Services ...................................................................................... 94
7.5.
Weitere mögliche Funktionen............................................................................... 94
Verwendete Hilfsmittel......................................................................................................... 95
Quellennachweis ................................................................................................................. 97
6
Abkürzungsverzeichnis
CSMA/CA
Carrier Sense Multiple Access with Collision Avoidance
CSMA/CD
Carrier Sense Multiple Access with Collision Detection
DSL
Digital Subscriber Line
EDR
Enhanced Data Rate
FPS
First Person Shooter
GPRS
General Packet Radio Service
GPS
Global Positioning System
GSM
Global System for Mobile Communications
http
Hypertext Transfer Protocol
J2ME
Java 2 Micro Edition
LAN
Local Area Network
LBS
Location Based Services
MMOG
Massive(ly) Multiplayer Online Game
MMORPG
Massive(ly) Multiplayer Online Role-Playing Game
MOM
Message-oriented Middleware
P2P
Peer to Peer
PC
Personal Computer
PDA
Personal Digital Assistant
RPC
Remote Procedure Calls
RPG
Role-Playing Game
RTS
Realtime Strategy
RTT
Round Trip Time
SNES
Super Nintendo Entertainment System
TCP
Transmission Control Protocol
UDP
User Datagram Protol
UMTS
Universal Mobile Telecommunications System
VE
Virtual Environments
WAN
Wide Area Network
WAP
Wireless Application Protocol
WEP
Wired Equivalent Privacy
WLAN
Wireless Local Area Network
WMAN
Wireless Metropolitan Area Network
WPAN
Wireless Personal Area Network
XML
Extensible Markup Language
7
1. Einleitung
“Eine gute Theorie ist das Praktischste was es gibt.”
– Gustav Robert Kirchhoff, deutscher Physiker
1.1. Motivation
Der Computerspielemarkt hat in den vergangenen Jahren einen riesigen „Boom“ erfahren,
der mittlerweile zum Beispiel in Deutschland sogar die Umsatzzahlen der Filmindustrie in
den Schatten stellt [diepresse04]. Insbesondere Multiplayerspiele mit wenigen bis zu
mehreren tausend Mitspielern (MMOGs) sind sehr populär geworden. Mit der stark
gestiegenen Verbreitung mobiler Endgeräte ist auch die Nachfrage nach Spielen auf solchen
Geräten immer größer geworden. Verfolgt man den Trend auf Desktop-Computern und
Spielekonsolen, so werden MMOGs künftig auch im mobilen Spielesektor von großem
Interesse sein.
Im Mobilbereich bietet sich insbesondere die Möglichkeit des so genannten „Pervasive
Gamings“1, also Spiele, die durch die gegebene Mobilität der Endgeräte die reale Welt in die
virtuelle Spielwelt mit einbeziehen. In diesem Zusammenhang sind ortsbezogene Dienste
(LBS) von besonderem Interesse für künftige mobile Multiplayerspiele. Insbesondere ist dies
für VE (Virtual Environments) und kurzzeitiges Spielen (z.B. auf dem Weg zu Arbeit) ein
immer weiter wachsender Markt.
Während bei mobilen Computerspielen bisher technische Größen wie Speicher-, Video- und
Rechenleistung limitierende Faktoren bei Nachahmungen erfolgreicher Computerspiele
waren, ergeben sich bei mobilen Multiplayerspielen vor allem Probleme durch zugrunde
liegende Netzwerkstrukturen, die Funktionen des Spiels entscheidend beeinflussen. Die
Entwicklung eines jeden Multiplayerspiels muss sich folglich mit den Möglichkeiten und
Begrenzungen der verschiedenen mobilen Netzwerkstrukturen und der Verwaltung der
vielen tausend Spieler auseinandersetzen.
Eine einheitliche Plattform für den Zugang und die Nutzung der Netzstrukturen, aber auch
die Verwaltung der gesamten MMOG-Umgebung stellt eine sinnvolle Lösung für Entwickler
mobiler
Mehrbenutzerspiele
dar,
die
sich
dadurch
fast
ausschließlich
Implementierung des Spielkonzepts konzentrieren können. Der Entwurf
1
auf
die
einer solchen
pervasive (engl.) = durchdringend, tiefgreifend
9
Middleware erlaubt die einfache Verwaltung und Kontrolle von Funktion und Sicherheit
verschiedener für mobile Mehrbenutzerspiele in Frage kommender Netzwerkstrukturen. Sie
ermöglicht die Zusammenführung und Abstraktion der Parteien Programmierer, Spielesoftware, Netzwerk und Netzwerkbetreiber unter Einhaltung der gegenseitig geforderten
Funktionsansprüche.
Da die Anzahl der bisher veröffentlichten mobilen Multiplayerspiele noch stark begrenzt ist
und dieser Marktsektor noch in Kinderschuhen steckt, ist dem Entwurf und insbesondere der
Implementierung einer solchen Middleware für MMOGs auf mobilen Endgeräten bisher nur
wenig Beachtung geschenkt worden.
1.2. Aufgabenstellung
Eine Middleware für mobile Endgeräte, die Funktionen der Schnittstelle zum Netzwerk
realisiert, als auch Datenverwaltung eines Spiels für mehrere tausend Spieler unterstützt,
wird im Rahmen dieser Diplomarbeit entworfen und in grundsätzlichen Strukturen
implementiert.
Die Implementierung umfasst dabei im Wesentlichen:
Abstraktion
von
der
Netzwerkschnittstelle
durch
ein
entsprechendes
Nachrichtensystem
Bereitstellung diverser Methoden zur lokalen Verwaltung der Spieldaten einer
MMOG-Umgebung
Entwurf zusätzlicher Schnittstellen für spätere Erweiterungen
Die Middleware wird dabei in Java implementiert, um später Umsetzungen für verschiedene
mobile Plattformen, die beispielsweise J2ME unterstützen, leicht realisieren zu können. Dies
ist insbesondere von großer Relevanz, da im mobilen Sektor durch die J2ME Umgebung
zum ersten mal ein gemeinsamer Standard versucht wird zu schaffen, auf dessen Grundlage
allgemeine Spielentwicklung möglich ist.
Unabhängig von der Implementierung werden ortsbezogene Dienste für künftige
Mehrbenutzerspiele im Bereich des „Pervasive Gamings“ betrachtet, die eine mögliche
Erweiterung des mobilen Middlewarekonzepts in späteren Versionen sein können.
10
1.3. Aufbau der Arbeit
Kapitel 2 gewährt zuerst einen Einblick in den Multiplayer-Bereich in nicht-mobilen
Umgebungen. Dazu werden allgemein Computerspiel-Genres betrachtet, bevor der
Übergang zu Multiplayer-Spielen erfolgt, dessen technische Realisierungen vorgestellt
werden. Der dritte Teil des Kapitels leitet schließlich in den MMOG-Bereich über und
präsentiert mögliche Netzwerkstrukturen und damit verbundene Faktoren, die die
Spielbarkeit beeinflussen können. Abschließend wird exemplarisch ein MMOG-Spiel aus
dem Desktop-Bereich betrachtet.
Im dritten Kapitel werden mobile Netzwerke untersucht. Aktuelle und künftige mobile
Übertragungstechniken werden vorgestellt. Da mobile Systeme hauptsächlich in drahtlosen
Umgebungen genutzt werden, ergeben sich weitere Faktoren, die eine Übertragung
beeinflussen und erschweren. Diese Faktoren werden analysiert, und es wird auf die
Eignung mobiler Umgebungen für MMOGs eingegangen. Als weiteres Thema dieser
Diplomarbeit werden Techniken, die Standort basierte Dienste ermöglichen, diskutiert.
Das vierte Kapitel stellt die bisher noch seltenen Umsetzungen massiver Mehrbenutzerspiele
im Handheldbereich vor und präsentiert einen verwandten Ansatz einer MiddlewareImplementierung für mobile Mehrbenutzerspiele.
Kapitel 5 erarbeitet die wichtigsten Komponenten einer Middleware für MMOGs, deren
Merkmale schließlich auch für die mobile Variante übernommen werden sollen. Es folgt der
eigentliche Entwurf der Middleware, der grundlegende Strukturen vorstellt und einige
implementierte Features erklärt.
Im sechsten Kapitel werden Testergebnisse, die mit der entwickelten Middleware erzielt
wurden, präsentiert. Hierbei steht die Frage der Leistungsfähigkeit der Middleware anhand
entstehender Verzögerungszeiten im Vordergrund. Hierbei soll die Skalierbarkeit des
Systems durch implementierte zusätzliche Funktionen deutlich verbessert werden.
Kapitel 7 fasst die erarbeiteten Ergebnisse noch einmal kurz zusammen und gibt einen
Ausblick für zukünftige Weiterentwicklungen der Middleware.
11
2. Multiplayerspiele im
Desktop- und
Konsolenbereich
“I think there is a world market for maybe five computers.”
– Thomas J. Watson, Gründer von IBM, 1943
Dieses Kapitel gibt zunächst eine Übersicht über Multiplayerspiele und Genres, die sich im
Heimcomputerbereich – also im Markt für Spielekonsolen und Desktop PCs – etabliert
haben.
Dazu werden sowohl die populärsten Spiel-Genres vorgestellt als auch die verschiedenen
(technischen) Multiplayer-Varianten und deren entsprechend benötigte Netzwerkstrukturen.
Im Mittelpunkt der Betrachtungen stehen dabei Onlinespiele, die mehrere tausend Spieler
unterstützen. Die möglichen technischen Realisierungen und Anforderungen, um eine
akzeptable Spielbarkeit dieser so genannten Massive Multiplayer Online Games zu
erreichen, sind dabei von besonderem Interesse im Hinblick auf die spätere Übertragung auf
mobile Netzwerke.
2.1. Allgemeine Computerspiel-Genres
Computerspiele können anhand diverser Kriterien in Genres eingeteilt werden. Dabei ist
sowohl eine eindeutige Aufstellung der Genres selbst als auch die Einteilung der Spiele in
ein bestimmtes Genre nur schwierig möglich. Durch innovative Ideen und dem Streben der
Spielhersteller, ein möglichst breites Spektrum an potentiellen Käufern zu erreichen, werden
neue Spielfelder kreiert oder Spiele entwickelt, die gleichzeitig in mehrere Kategorien fallen.
Dass eine eindeutige und zeitlose Klassifizierung nicht möglich ist, liegt unter anderem auch
an der rasanten Weiterentwicklung der Technik (schnellere Prozessoren/Grafikkarten,
größerer Arbeitsspeicher), die die Entstehung neuer Spiele und somit auch Genres fördert.
Umgekehrt haben Spielhersteller heutzutage ebenfalls einen großen Einfluss auf die
13
Hardware der nächsten Generationen. So werden neue Spiele mit innovativen Features
oftmals in Absprache und im Gleichschritt mit der Hardware der Zukunft entwickelt.
Die hier betrachtete Einteilung orientiert sich an [Myers90] und [Wiec02] und dem darin
vorgestellten Ansatz aus „Computerspiele: Design und Programmierung“ [DoMü02]. Hierbei
wird eine pragmatische Aufteilung vorgeschlagen, die dem Spieler durch Faktoren wie
technische Kriterien (z.B. 2D- oder 3D-Grafik) aber vor allem Thematik (analog zu
Einteilungen von Filmen in Kategorien) bereits von außen einen groben Eindruck vermittelt,
um welche Art Spiel es sich handelt.
In [DoMü02] wird folgende Gruppierung vorgeschlagen:
Actionspiele
Strategiespiele
Abenteuerspiele
Simulationen
Rennspiele
Sportspiele
Zusätzlich zu dieser Aufteilung ist die Betrachtung weiterer Unterkategorien - wie im
Folgenden aufgeführt - möglich.
2.1.1.
Actionspiele
Actionspiele gehören zu den Vorreitern der Computerspielindustrie. Sie werden häufig auch
als Arcade2-Games bezeichnet, da die ersten elektronischen Spiele den Spielern
hauptsächlich durch Automaten in Spielhallen zugänglich gemacht wurden.
Actionspiele fordern in erster Linie die Geschicklichkeit des Spielers, insbesondere erfordern
Sie „Reflexe und die Koordination von Hand und Augen“ [Myers90].
Eine weitere Unterteilung dieses Genres ist in folgende Unterkategorien möglich:
2
Arcade (engl.) = Spielhalle
14
Jump ’n’ Run
Der Spieler steuert eine Spielfigur durch die Spielwelten (meist durch so genannte Levels3)
und überwindet dabei Hindernisse und Fallen. Ein populäres Beispiel ist das Spiel „Super
Mario Land“ [SuML89], welches 1989 bereits auf dem tragbaren Handheld Gameboy
[Gboy89] erhältlich war.
Abbildung 2.1: Super Mario Land (Gameboy)
Beat’em Up
Diese Variante legt den Schwerpunkt auf das Bekämpfen/Schlagen von Gegnern. Dabei
kann noch zwischen Spielen mit Bildschirm-Scrolling (die Levels werden durchlaufen ähnlich
wie bei Jump ‚n’ Runs) und reinen Kampfspielen mit Eins-gegen-Eins (1 vs 1) Kämpfen, wie
etwa „Streetfighter“ [StFi87], unterschieden werden.
Abbildung 2.2: Streetfighter 2 Turbo (SNES)
3
Unterteilung des Spiels in einzelne Spielabschnitte (auch „Stages“) unterschiedlicher Schwierigkeit
15
Shooter / Shoot’em Up
Bei den Shootern werden Gegner (Computer oder Mitspieler) durch Schießen bekämpft.
Dieses Genre erfuhr mit dem Klassiker „Doom“ [Doom93] einen enormen Schub. Während
vorherige Shooter mit verschiedenen Bildschirmtechniken wie Single-Screen (z.B. Space
Invaders
[SpIn78])
oder
Bildschirm-Scrolling
(zum
Beispiel
Raumschiff-
oder
Hubschrauberspiele) in 2D-Grafik dargestellt wurden, gelang es id Software 1993 das erste
mit fließender 3D- Grafik und Netzwerkfähigkeit ausgestatte Spiel auf den Markt zu bringen,
welches als Shareware als Download erhältlich war und somit schnell starke Verbreitung
fand.
Abbildung 2.3: Doom (PC Version)
„Doom“ wurde zu einem so großen Erfolg, dass Nachahmer nicht lange auf sich warten
ließen und der Computermarkt in den folgenden Jahren regelrecht von 3D Shootern
überschwemmt wurde. Shooter im Stile von „Doom“, die direkt aus der Sicht des Spielers
gesteuert werden, bilden eine weitere Unterkategorie, die heute allgemein als First Person
Shooter (FPS) bekannt sind. Dank immer schneller werdender Rechner und dem Einsatz
zusätzlicher Prozessoren auf Grafikkarten, die 3D Berechnungen und Rendering
beschleunigen, werden FPS immer realistischer.
2.1.2.
Strategiespiele
Strategiespiele verlangen vom Spieler „kreative und logische Denkfähigkeit“ ([Wiec02] und
[DoMü02]). Strategisches Planen und Denken stehen im Vordergrund. Man kann wie folgt
unterscheiden:
16
Echtzeitstrategiespiele
Die Entscheidungen des Spielers und die Entwicklung der Spielwelt geschehen in Echtzeit.
Dies bedeutet, dass die Spielzeit ständig voranschreitet und somit in Echtzeit agiert (z.B.
Verteilen von Aufgaben an seine Spielfiguren) und reagiert werden muss (auch bekannt als
Realtime Strategy).
Echtzeitstrategiespiele erfreuen sich insbesondere im Mehrspielermodus großer Beliebtheit.
Ein beliebter Vertreter dieses Genres ist die „WarCraft“-Serie [WarCraft94].
Abbildung 2.4: WarCraft III: Reigns of Chaos (PC-Version)
Rundenbasierte Strategiespiele
Das strategische Denken und Handeln erfolgt in einzelnen Runden. In jeder Runde trifft der
Spieler eine Entscheidung, die anschließend in das Spielgeschehen übertragen wird. Dabei
hat der Spieler genug Zeit, bevor er sich für einen Spielzug entscheiden muss.
Ein typisches Beispiel wäre Schach (ein „Hybrid“, da es ebenfalls in die Kategorie
„Sportspiel“ passt).
Aufbauspiele
Hier steht das Aufbauen und Verwalten einer Spielwelt im Vordergrund, so zum Beispiel die
Entwicklung einer Stadt oder die Evolution eines virtuellen Volkes.
17
Wirtschaftssimulationen
Der Spieler leitet ein Unternehmen oder ein Imperium, dessen wirtschaftlicher Erfolg Ziel des
Spieles ist. Es werden betriebswirtschaftliche und volkswirtschaftliche Entscheidungen und
entsprechendes Vorgehen vom Spieler verlangt.
2.1.3.
Abenteuerspiele / Adventures
Die wichtigsten Elemente eines Abenteuerspiels sind die Story und der Dialog. Der Spieler
muss anhand der gelieferten Story und Interaktionen mit Gegenständen und Charakteren
des Spiels (insbesondere Dialoge) Zusammenhänge erkennen und Rätsel lösen.
Abenteuerspiele haben ihren Ursprung in den Text-Adventures. Hier wurde das
Spielgeschehen durch eine textbasierte Geschichte getragen.
Der Spieler bekam die Story wie in einem Buch präsentiert und konnte durch Eingabe von
simplen Befehlen („gehe nach links“, „benutze Taschenlampe“) die Geschichte und somit
das Spiel vorantreiben.
Anfang der 90er Jahre gingen die Entwickler aufgrund verbesserter (Grafik-) Hardware zu
Grafik-Adventures über. Die Steuerung der Spielfigur(en) wurde durch den Einsatz der
Computermaus vereinfacht, und die Geschichte wurde neben dem Dialog nun vor allem von
grafischen Elementen unterstützt.
Besonders erwähnenswert sind hier die Adventures von LucasArts4, die durch speziellen
Witz und liebevoll gezeichnete Grafiken beeindruckten.
Abbildung 2.5: The Secret of Monkey Island (PC-Version)
4
bis 1991 LucasFilm Games
18
Rollenspiele
Computer-Rollenspiele (auch bekannt als Role-Playing Games) stammen von ihren
Brettspiel-Vorbildern ab, die wiederum von entsprechender Literatur, wie den Werken von
J.R.R. Tolkien, inspiriert wurden.
In einem Rollenspiel übernehmen die Spieler die Rolle eines Charakters in einer
Fantasiewelt und versuchen unter vorgegebenem Regelwerk, die Entwicklung ihres eigenen
Charakters voranzutreiben (Hinzugewinnen neuer Fähigkeiten wie „Zauberkräfte“, Sammeln
von Gegenständen), um diverse Abenteuer in der Spielwelt zu meistern.
Dabei werden den Spielern verschiedene Aufgaben, so genannte Quests, gestellt, die es zu
lösen gilt.
Rollenspiele müssen kein vorgesehenes Ende haben, so dass die Fantasiewelten parallel
zur „echten Welt“ ständig weiterleben und weiterentwickelt werden können.
Wie im nächsten Abschnitt aufgeführt, sind Rollenspiele durch diese fiktiven Welten und
Charaktere ein besonders interessantes Mehrspieler-Genre. Die starke Verbreitung des
Internets in den letzten Jahren hat dafür gesorgt, dass Rollenspiele mit mehreren tausend
Spielern möglich geworden sind (MMORPGs).
Abbildung 2.6: Diablo II LOD (PC-Version)
2.1.4.
Simulationen
Simulationsspiele versuchen, Teile der realen Welt abzubilden, indem bestimmte Szenarien
so realitätsnah (dies kann sich sowohl auf die Grafik als auch auf die inhaltlichen Elemente
beziehen) wie möglich dargestellt werden. Die virtuellen Umgebungen sind dabei von
19
besonderer Bedeutung, da sie dem Spieler den Eindruck einer wirklichen Umgebung
suggerieren sollen.
Hierbei seien insbesondere Flugsimulationen zu erwähnen, die teilweise so realistisch
gestaltet wurden, dass aufgrund diverser Kritik nach Terroranschlägen durch entführte
Flugzeuge eine Überarbeitung bzw. Rücknahme der Spiele nötig war (siehe [Siegen02]).
Abbildung 2.7: Microsoft Flight Simulator 2004 (PC-Version)
2.1.5.
Sport- und Rennspiele
In diesem Genre werden fast alle Sportarten auf den Computer übertragen, unter anderem
auch als Kollektionen wie z.B. Olympische Sportarten.
Computer-Sportspiele erfahren einen ähnlichen Trend, wie die entsprechenden Sportarten
selbst. Ein Sport, der in den Medien und beim Publikum an Beliebtheit gewinnt, wird nicht
lange mit einer Umsetzung als Computerspiel auf sich warten lassen. Da die Identifizierung
mit Sportidolen ein nicht zu unterschätzender Faktor in der Kaufentscheidung eines
Computerspielers ist, wird die ständig verbesserte Hardware vor allem für eine realitätsnahe
Verwirklichung der Idole auf dem Computerbildschirm genutzt.
Rennspiele, wie Autorennen, können als eigenes Genre oder Unterkategorie betrachtet
werden, da sie teilweise etwas aus dem Sportrahmen fallen können - so sind beispielsweise
auch futuristische Autorennen denkbar.
20
Abbildung 2.8: FIFA 2005 (PC und PS2 Version)
21
2.2. Multiplayer-Spiele
Nachdem im ersten Abschnitt ein kurzer Einblick in eine mögliche Einteilung der
Computerspiel-Genres gegeben wurde, werden nun solche Spiele detaillierter betrachtet,
die für mehrere Spieler besonders interessant und gefragt sind.
Dazu wird in erster Linie auf die technischen Möglichkeiten zur Implementierung eines
Mehrbenutzer-Modus
in
Spielen
im
Heimcomputerbereich
–
insbesondere
die
Realisierung durch Netzwerkunterstützung – eingegangen.
2.2.1. Technische
Umgebungen
Realisierungen
für
Multiplayer-
Es ist bemerkenswert, dass „Pong“ [Pong72], das erste populäre Videospiel der Welt5,
bereits für zwei Spieler entwickelt wurde und wenig später sogar Varianten mit 4 Spielern
(vergleichbar mit einem Tennis-Doppel) vorgestellt wurden.
Abbildung 2.9: Pong für 4 Spieler
Single-Screen
Während „Pong“ aufgrund technischer Limitierungen einen Mehrspielermodus auf einem
einzigen Bildschirm (Single-Screen, d.h. alle Spieler benutzen denselben Bildschirm) bot,
wurde diese erste Möglichkeit mehrere menschliche Spieler gleichzeitig an derselben
Konsole spielen zu lassen, wiederholt in den ersten Generationen der Videospiele
5
es wurden bereits Videospiele vor „Pong“ entwickelt, allerdings wird „Pong“ aufgrund der
weltweiten Verbreitung als „Urvater“ der Videospiele bezeichnet [Wiki06]
22
genutzt. Die Entwicklung hin zu „bewegten“ Bildern (horizontales und vertikales Scrolling)
übertrug sich ebenfalls auf die Multiplayer-Spiele, auch wenn es hier zu möglichen
Problemen bei der Steuerung kommen konnte, da zwei Spieler den Bildschirm nicht
gleichzeitig in zwei Richtungen verlassen und somit zum Weiterscrollen bringen konnten.
Eine weitere Variante eines Single-Screen Multiplayer-Modus sind runden basierte Spiele,
in denen die einzelnen Benutzer abwechselnd eine gewisse Zeit für ihre Spielzüge haben
und dabei mitunter sogar dieselben Eingabegeräte benutzen. Ein Beispiel hierfür ist das
Spiel „Giana Sisters“ [GiSi87], bei dem die Spieler sich nach jedem „virtuellen Sterben“
der Spielfigur abwechselten.
Split-Screen
Eine andere weit verbreitete Technik, Mehrbenutzerspiele an einem einzigen Bildschirm
zu ermöglichen stellt die Bildschirmaufteilung (Split-Screen) dar. Single-Screen Spiele
präsentieren jedem beteiligten Spieler die gleiche Perspektive auf die Spielwelt.
Durch die (meist horizontale) Aufteilung des Bildschirms ist hingegen die Realisierung
mehrerer Blickwinkel durchführbar, so dass jedem Benutzer seine eigene Perspektive
eingeräumt werden kann.
Der Nachteil dieses Ansatzes ist – neben der beschränkten Anzahl an Spielern (meist nur
zwei Benutzer) – die optische Irritation, die speziell bei schnellen, mit 3D-Grafik
ausgestatteten Videospielen auftritt.
Abbildung 2.10: Super Mario Kart (SNES-Version) als Beispiel der Split-Screen Technik
23
Netzwerklösungen
Die bisher beschriebenen Mehrspieler-Modi basieren auf Veränderungen der Software
und zeitlicher beziehungsweise räumlicher Aufteilung der gemeinsam verwendeten
Hardware-Ressourcen.
Computernetzwerke erlauben eine neue Art des Mehrspielerbetriebs, indem jeder Spieler
das gemeinsame Spiel auf seiner eigenen Hardware laufen lässt und demnach jeder
Benutzer seinen eigenen Blickwinkel (getrennt von den übrigen) erhält. Basis dieses
gemeinsamen Spiels sind verschiedenartige Netzwerke, die getrennte Spielgeräte
verbinden und so den Informationsaustausch zwischen der parallel laufenden
Spielsoftware ermöglichen.
Der entscheidende Unterschied liegt also vor allem in der Tatsache, dass mehrere
Versionen derselben Software (Clients) gleichzeitig laufen. Somit taucht unweigerlich das
Problem der Verwaltung der gemeinsamen Spielwelt, also der Synchronisation auf. Jeder
Spieler sollte zu nahezu jedem Zeitpunkt möglichst dieselbe Spielwelt wahrnehmen, um
eine
logische
Wahrnehmung
im
Sinne
des
Spielprinzips
zu
gewährleisten
(Synchronisationsprinzip). Dazu ist ein Austausch an Informationen zwischen den
Softwares erforderlich. Aus diesem Grund muss die verwendete Netzwerkstruktur, die
diesen Informationsaustausch bewerkstelligt, gewissen Anforderungen genügen. Unter
anderem muss die Spielbarkeit des Mehrbenutzerspiels akzeptabel gestaltet werden
(siehe Abschnitt 2.3.2).
Die Vernetzung zweier Spieler wurde anfangs durch eine direkte Verbindung zwischen
den Spielgeräten, die in den meisten Fällen über serielle Schnittstellen der Geräte
zustande kam, verwirklicht. Im PC-Bereich wurden zunächst vor allem die COMSchnittstellen genutzt, die mit Hilfe eines Nullmodem-Kabels verbunden wurden. Auch im
mobilen Handheldbereich konnten durch eine direkte Verkabelung des Nintendo
Gameboys über das so genannte DirectLink-System bereits Spiele mit zwei menschlichen
Spielern durchgeführt werden.
Die einfachste Form der Vernetzung mehrerer Spieler geschieht über Local Area
Networks (LAN) mit fester Verkabelung, also kleine Netzwerke mit geringer Reichweite
(etwa für die Vernetzung in einem Gebäude). Der am weitesten verbreitete Standard für
LANs ist das Ethernet.
Im Zuge der technischen Entwicklung durchlief das Ethernet verschiedene Versionen, die
in Bezug auf die Datenübertragungsrate stetig verbessert wurden. Zuerst dominierte ein
Ethernet-Standard, der einen Datendurchsatz von 10 Mbit/s gestattete. In nächsten
Generationen wurden Standards mit 100 Mbit/s (Fast Ethernet) und 1Gbit/s (Gigabit
Ethernet) und sogar 10 Gbit/s entwickelt. Die einzelnen Standards arbeiten mit
unterschiedlichen
24
Technologien,
wie
verschiedenen
Verkabelungen
oder
Modulationstechniken.
Durch
Router/Splitter
ist
die
maximale
Anzahl
an
Netzwerkteilnehmern eines LANs auch nicht mehr auf 2 beschränkt.
Anfangs wurden Koaxialkabel verwendet, wobei der Standard 10Base2 bei dieser
Verkabelung der damals am häufigsten verwendete Typ war. 10Base2, auch bekannt als
Thin Ethernet (da die Kabel im Vergleich zum Standard 10Base5 – dessen Kabel etwa
daumendick waren - vergleichsweise dünn und daher biegsamer waren), unterstützte
Geschwindigkeiten bis zu 10 Mbit/s und eine Kabellänge von maximal 185m (als Resultat
war die maximale Anzahl der Teilnehmer oft auf 14-16 beschränkt). Der Anschluss der
maximal 30 (eher 14-16) Rechner an das Koaxialkabel erfolgt durch so genannte TStecker, mit denen die Bus-Schiene von den einzelnen Knoten (also Rechnern)
„angezapft“ wurde. Um das Netzwerk „abzuschließen“ wurde an den beiden Enden der
Schiene je ein Endwiderstand (10 Ohm) positioniert. Neben der Netzwerkhardware der
beteiligten Knoten selbst wurde nur wenig Hardware benötigt, so dass dieser Standard
kostengünstig und beliebt im Heimanwenderbereich war.
Der Nachteil einer solchen Bus-Topologie ist jedoch, dass der Ausfall eines einzigen
Kabelsegments (z.B. durch einen Kabelbruch) den Ausfall des gesamten Netzwerks
bedeutete. Daher ging man zu der Einführung einer zusätzlichen Hardware, eines Hubs
(später auch Switches) über, der mit jedem einzelnen Knoten verbunden war und den
Netzwerkverkehr regelte (Stern-Netzwerktopologie). Für diesen Verkabelungstyp wurden
Twisted-Pair-Kabel benutzt, die bereits bei der Telefonverkabelung Einsatz fanden. Der
Hub ermöglichte nicht nur die leichte Entfernung oder das Hinzufügen neuer Knoten ohne
den Netzverkehr zu stören - durch ihn wurde ebenfalls gesichert, dass der Ausfall eines
einzigen Knotens beziehungsweise Kabels keinen Einfluss auf das restliche Netzwerk
hatte. Nachteilig hierbei ist allerdings die begrenzte Länge eines Kabels auf 100m bzw.
200m (je nach verwendetem Kabeltyp), so dass für etwas längere Verbindungen andere
Techniken zum Einsatz kommen müssen (zum Beispiel Glasfaser).
Möchte man die Verkabelung der Rechner umgehen, so kann man den Netzwerkverkehr
auch drahtlos über Wireless LANs abwickeln, die ebenfalls eine Verbreitung des
Netzwerks in einem Gebäude möglich machen. Mit dem Datenverkehr über Funk sind
Datenraten von 11 Mbit/s bis 54 Mbit/s realisierbar. Für WLANs existieren zwei
Betriebsmodi, der Infrastruktur- und der Ad-Hoc-Modus. Im Infrastruktur-Modus gibt es
eine Basisstation (auch Access Point), über welche die gesamte Kommunikation läuft;
während im Ad-Hoc-Modus die Rechner direkt miteinander kommunizieren. Obwohl
WLANs offensichtlich den großen Vorteil bieten, dass eine Verkabelung erspart bleibt und
somit die Mobilität der Spielgeräte ermöglicht wird, steht demgegenüber vor allem noch
die Frage der Sicherheit und Zuverlässigkeit, da die Kommunikation über Funk abgehört
und gestört werden kann (eingesetzte Sicherungsprotokolle: z.B. WEP). Weitere drahtlose
Verbindungen sind durch Kurzstreckenfunktechniken wie Infrarot oder Bluetooth möglich.
25
Um über das Ethernet vernetzte Spiele synchron zu halten, schickt die Spielsoftware
regelmäßig (oder bei Bedarf) Pakete über das LAN an andere Netzwerkteilnehmer, um
Veränderungen in der lokalen Version des Spiels mitzuteilen (wie etwa Spielzüge).
Andere Rechner empfangen Pakete und führen entsprechende Berechnungen durch, die
zu
einem
Update
des
Spielstatus
führen
und
unter
Umständen
weitere
Benachrichtigungen des Netzwerks nach sich ziehen. Damit die Synchronisation des
Spiels garantiert werden kann, muss sowohl die Ankunft der Statusupdate-Pakete bei den
anderen Rechnern gesichert als auch die Verzögerungszeiten (Latenz) bei der
Paketauslieferung in Grenzen gehalten werden.
Da LANs in ihrer Größe beschränkt sind (je nach Struktur sind auch LAN Parties mit mehr
als 2500 Teilnehmern möglich), ergeben sich nur selten Probleme in Hinblick auf die
Latenz. Ein Paketverlust ist hingegen nie auszuschließen. Benutzen zwei Rechner das
gemeinsame Medium (das Kabel des LANs) gleichzeitig, so kollidieren die Pakete und
zerstören sich gegenseitig. Damit Kollisionen reduziert werden, wird bei Ethernet das
CSMA/CD-Verfahren angewendet: Jeder Rechner, der Pakete über das Netzwerk
schicken will, überprüft zunächst die Leitung (Carrier Sense), ob nicht schon ein Paket
übertragen wird. Ist das Medium unbenutzt, so sendet er sein Paket. Sollten nun trotzdem
zwei Rechner das ungenutzte Medium benutzen wollen, und es kommt zu einer Kollision,
so erkennen die beteiligten Rechner den Fehler (Collision Detection) und jeder wartet eine
zufällige Zeit ab (damit eine erneute Kollision verhindert wird), bevor ein erneuter Versuch
gestartet wird. Somit wird ein flüssiger Spielverlauf im Multiplayer-Betrieb nur selten
gestört. Bei drahtlosen Netzwerken findet CSMA/CD keine sinnvolle Anwendung (siehe
[Tan03]), da unter anderem viele Funkgeräte nicht gleichzeitig Senden und das Medium
nach Kollisionen und Störungen abhören können (also halbduplex arbeiten). Daher wird
versucht, Kollisionen vorausschauend zu vermeiden (CSMA/CA). Das Versenden der
Pakete über Funk ist insgesamt viel unzuverlässiger als bei Kabelverbindungen, da
Funkverkehr durch eine Vielzahl von Faktoren gestört und beeinflusst werden kann
(anderer Funkverkehr, Hindernisse wie Wände).
Typische maximale Spieleranzahlen im LAN-Bereich liegen bei 8 bis 16 Spielern (in
seltenen Ausnahmen 32+, oder LAN-Parties im großen Stil). Mit der Etablierung des
Internets ergab sich für Spieler von Mehrbenutzerspielen die Gelegenheit, eine enorm
große Spielergemeinde zu erreichen. Mit Hilfe des Internets war es möglich, Mitspieler zu
finden, die in der ganzen Welt verteilt waren. Sowohl durch Internet-Schnittstellen lokaler
Spielsoftware (client-basierte Spiele) als auch über das World Wide Web selbst, in Form
von browser-basierten Spielen, entstand eine neue Dimension der Mehrbenutzerspiele,
die nun Spieleranzahlen im hohen tausendstelligen Bereich gestatteten.
26
Netzwerke, die Verteilungen der Spieler auf verschiedene Länder oder sogar Kontinente
unterstützen, werden als Wide Area Networks bezeichnet. Wegen der teilweise sehr
großen Distanzen zwischen den Teilnehmern eines WAN-Spiels, treten nun Faktoren wie
Latenzzeiten verstärkt in den Vordergrund. Nicht nur der Umgang mit großen Distanzen
(die meist durch sehr schnelle Verbindungen wie Glasfaserkabel überbrückt werden) ist
dabei Ausschlag gebend, um eine gewisse Qualität bzw. eine akzeptable Ausführung des
Spiels zu erreichen. Auch die so genannte letzte Meile, das heißt der Anschluss des
Spielteilnehmers am Internet selbst kann eine einschneidende Limitierung darstellen.
Dieser Zugriff eines Endnutzers auf das Internet kann auf vielfältige Weise erfolgen und
mit unterschiedlichen Bandbreiten gestaltet sein.
Im Rahmen dieser Diplomarbeit sind in erster Linie Verbindungen interessant, die den
Zugriff von mobilen Geräten aus gestatten und somit Zugang zu Spielen mit vielen
tausend Spielern verwirklichen können.
Übertragungstechniken
(wie
Bluetooth
Deshalb stehen oben erwähnte Funkund
WLAN),
die
eine
Verbindung
zur
Internetspielgemeinde herstellen können, im Mittelpunkt der nachfolgenden Kapitel.
2.2.2.
Populäre Multiplayer-Genres
Eine Umfrage bei etwa 11.000 Internetnutzern, die im Rahmen einer Bachelorarbeit
[Schob03] der Carl von Ossietzky Universität Oldenburg auf mehreren deutschen
Gaming- und Clan-Webseiten durchgeführt wurde, ergab, dass die beliebtesten Genres
bei deutschsprachigen Spielern First Person Shooter (51.3% der Befragten), Rollenspiele
(30.4%) und Strategiespiele (RTS 7.5%, andere Strategiespiele 7.1%) sind. Anhand der
angemeldeten Spieler bei einzelnen Online-Spielen [GamSur05] ist ebenfalls ersichtlich,
dass FPS und RPGs auch international einen großen Zulauf verzeichnen.
Im MMOG-Bereich nehmen die Rollenspiele eine dominierende Position ein, wie die
Anzahl der Teilnehmer ([MMOGChart]) an Online-Rollenspielen wie „World of Warcraft“
oder „LineAge II“ [LineAge2] zeigen.
Für
die
nachfolgenden
Untersuchungen
im
MMOG-Bereich
werden
daher
im
Wesentlichen MMORPGs betrachtet.
2.3. Einführung in den MMOG-Bereich
Online-Spiele, die über das Internet abgewickelt werden unterliegen verschiedenen
Problemen, die hauptsächlich in der Verzögerungszeit beim Datenaustausch über das
Internet begründet sind. Abgesehen von geographischen Gegebenheiten und der
27
genutzten Bandbreite der Spielteilnehmer, entsteht bei massiven Multiplayerspielen vor
allem ein erheblicher Verwaltungsaufwand der vielen tausend Spieler, der technisch
gehandhabt werden muss (siehe z.B. Serverstatistiken von Eve Online [EveOnl06]).
Um den Anforderungen der verschiedenen Online-Spiele gerecht zu werden, müssen
demnach vor allem die verwendeten Netzwerkstrukturen und Verwaltungsmöglichkeiten
der MMOGs untersucht werden.
2.3.1.
Netzwerkstrukturen
Client-Server-Systeme
Die häufigsten eingesetzte Netzwerkstruktur für Onlinespiele (insbesondere MMOGs) im
Internet ist das Client-Server-System. Hierbei steht ein ausgezeichneter Rechner, der
Server, bereit und wartet auf die Kontaktaufnahme durch die anderen Rechner
(Spielteilnehmer), die Clients. Der Server stellt den Clients einen Dienst zur Verfügung,
der in Anspruch genommen werden kann. Für Mehrbenutzerspiele bedeutet dies speziell,
dass Spielzüge wie Bewegungen und Aktionen der Spielfiguren, über das Netzwerk an
den Server gesendet werden, der somit alle Anfragen zentral überprüfen und verwalten
kann. Nach der Auswertung durch den Server wird der Client, also der jeweilige Spieler,
entsprechend informiert und kann die Änderungen lokal darstellen.
Abbildung 2.11: Client Server System
Spielhersteller stellen der Online-Gemeinde Spielserver zur Verfügung, auf denen sich die
lokal betriebene Spielsoftware einloggen kann (in manchen Fällen kann auch der Rechner
28
eines Spielers die Rolle des Hosts übernehmen). Die Server verwalten die komplette
Spielwelt indem sie Anfragen der einzelnen Clients annehmen, auf Gültigkeit prüfen und
in die Spielwelt integrieren. Anschließend wird der Client entsprechend benachrichtigt.
Möchte beispielsweise ein Spieler auf ein Monster schießen, so sendet der Client
Informationen über Position und Richtung des Geschosses an den Server. Der Server
berechnet dann, ob der Schuss ein „Erfolg“ oder „Misserfolg“ war und informiert den Client
über das Ergebnis. Die lokale Software kann dann entsprechend darstellen, ob das
Monster getroffen wurde oder nicht (lokales Rendering). Da alle Aktionen eines jeden
Spielers über den Server erfolgen, hängt der Spielfluss somit von der Verbindung des
Clients zum Server, aber in erster Linie von der Rechenleistung und Bandbreite des
Servers ab. Verzögerungen können also ebenfalls durch hohe Auslastungen der Server
bedingt sein, die nicht immer alle Anfragen gleichzeitig beantworten können. Aus diesem
Grund wird die Anzahl der Spieler pro Server begrenzt, und die Spieler werden auf
verschiedene Server verteilt. Dies führt zur Aufteilung der Spielwelt in so genannte
Shards6, das heißt in Kopien der Spielwelt, die parallel existieren, aber dessen Teilnehmer
einer Kopie der Spielwelt nicht mit Teilnehmern einer anderen Kopie interagieren können
[Wiki06a] (Ausnahme ist das Chatten zwischen Servern). Standardmäßige Client-ServerSysteme sind nicht gut skalierbar, da mit ansteigender Spielerzahl immer mehr
Bandbreite beim Server benötigt wird: Angenommen jeder der n Netzwerkspieler schickt
in gleichen Abständen eine Statusmeldung der Größe x an den Server. Dann hat der
neue Gesamtstatus, der anschließend vom Server an alle n Teilnehmer zurückgeschickt
wird eine Größe von n * x. Die benötigte Bandbreite beim Server steigt somit quadratisch
(sofern keine Optimierungen an der Gesamtstatusmeldung vorgenommen werden, was
die Situation zwar etwas verbessert, allerdings immer noch keine annehmbare
Skalierbarkeit erreicht) [PeDo03].
Ein weiterer entscheidender Schwachpunkt des Client-Server-Ansatzes ist die Tatsache,
dass ein Serverausfall (auch durch Einspielen eines Updates) bedeutet, dass kein Spiel
während der Ausfallzeit möglich ist. Leider können oder wollen viele Spieler in einem
solchen Fall nicht auf einen anderen Server ausweichen, da „ihr“ Server meist den Status
und somit die Fähigkeiten des eigenen Charakters speichert, um ein Modifizieren
(cheaten) dieser Daten offline von der Seite des Spielers aus zu vermeiden. Dynamische
Spiel Updates sind in verschiedenen MMOGs versucht worden, doch als momentan nicht
realisierbar abgelehnt worden.
Dies wiederum ist jedoch ein wesentlicher Vorteil des Client-Server-Systems. Da die
gesamte Kommunikation über den Server geschieht, der Berechnungen für die Spielwelt
6
engl. Scherben
29
durchführt und Inkonsistenzen ausgleicht, ist ein Cheating zumindest nur erschwert
möglich - hauptsächlich durch die eben erwähnte Vorsichtsmaßnahme, den Status der
Spieler online auf dem Server zu speichern.
Um die Skalierbarkeit eines Client/Server-Systems zu verbessern, können auch
softwareseitig Maßnahmen getroffen werden, die das Nachrichtenaufkommen und somit
die Gesamtlast reduzieren.
Peer-to-Peer Systeme
Neben der zentralisierten Variante, existiert ein dezentrales Netzwerk-System, dass als
Peer-to-Peer (P2P) bezeichnet wird. Bei P2P-Systemen sind alle Rechner gleich
berechtigt und können Dienste wie ein Server anbieten, aber auch Dienste von anderen
„Peers“ in Anspruch nehmen. P2P auf Multiplayerspiele angewendet bedeutet dann, dass
jeder beteiligte Rechner die Spielwelt selbst berechnen muss. Somit muss gewährleistet
sein, dass jeder einzelne Peer entweder die komplette Spielwelt oder zumindest die für
ihn relevanten Teile hält.
Abbildung 2.12: Peer to Peer System (Beispiel von 4 Clients)
Update-Nachrichten werden an alle beteiligten Peers gesendet, wobei jeder einzelne Peer
für die korrekte Berechnung der Spielwelt verantwortlich ist. Dadurch wird die
Handhabung von Inkonsistenzen erschwert und im Gegenzug die Chancen einer
Manipulation erhöht (siehe hierzu MiMaze [MiMaze06], die erste wirklich skalierbare
Implementation einer P2P Variante, die auch cheating-protection enthält).
Da die Kommunikation nicht über einen Server erfolgt, können Latenzen zwischen
Teilnehmern reduziert werden und man umgeht den Schwachpunkt, dass ein
Serverausfall auch den Ausfall eines Spiels bedeutet. Die begrenzte Bandbreite des
30
Servers als Flaschenhals entfällt ebenfalls, da die Bandbreite auf die Peers „verteilt“ wird.
Da immer mehr Internetnutzer Breitbandanschlüsse nutzen, sind P2P-Systeme daher im
Vergleich zum Client-Server-Ansatz in diesem Sinne besser skalierbar. P2P-Systeme sind
im Multiplayerbereich bisher kaum vertreten. Dies liegt einerseits an der teilweise
schwierigen
Implementierung
(zum
Beispiel
Vermeidung
von
Inkonsistenzen),
andererseits ist es schwierig, ein geeignetes Abrechnungssystem für kostenpflichtige
Spiele zu integrieren (es ist bisher nicht möglich). [PeDo03]
Ein Hybrid-Ansatz: P2P mit Central Arbiter
Die Vorteile der Client-Server-Systeme (Konsistenzverwaltung) und P2P-Netzwerke
(geringere Latenzen) werden in dem in [PeDo03] vorgestellten Hybrid-System „Peer-toPeer with Central Arbiter“ vereint. Die hauptsächliche Struktur ist dabei ein P2P-Netzwerk,
welches um einen zusätzlichen Knoten, den Central Arbiter (CA), erweitert wird.
Die Nachrichten werden an alle Peers und den CA geschickt. Der CA verhält sich dabei
wie ein Zuhörer des Netzverkehrs und simuliert anhand der gelieferten Nachrichten die
Spielwelt. Die Peers berechnen den Zustand der Spielwelt weiterhin selbst. Wird eine
Inkonsistenz vom CA festgestellt, so werden alle Peers davon informiert und die lokal
berechneten Spielwelten müssen unter Umständen korrigiert werden.
Abbildung 2.13: Peer to Peer mit Central Arbiter (4 Clients, 1 Arbiter)
Tests
einer
Implementierung
dieses
Systems
haben
gezeigt,
dass
die
Bandbreitenanforderungen bei einem Inkonsistenzausgleich von 50% (das bedeutet,
jedes zweite Update der Spielwelt wird als inkonsistent erkannt) beim CA linear mit der
31
Anzahl der Spieler steigen, während in einem echten Client-Server-System unter gleichen
Bedingungen quadratische Auslastungen beobachtet wurden.
2.3.2.
Beeinflussung der Spielbarkeit
Die in 2.3.1 angesprochene Skalierbarkeit der Netzwerkstrukturen ist im MMOG-Bereich
von entscheidender Bedeutung. Während im normalen Multiplayerbetrieb mit bis zu 16
Spielern, etwa bei First Person Shootern, ein einziger Server ohne Probleme das Spiel
hosten kann, benötigen Spiele mit mehreren tausend Spielern erheblich mehr Aufwand.
Browser-basierte MMOGs sind nur selten streng zeitkritisch und das Spielgeschehen wird
meist über übliche Datenbanken gesteuert. Ein Anbieter eines browser-basierten MMOGs
hat somit kaum einen größeren technischen Aufwand als eine populäre dynamische
Website zu bewältigen.
Die meisten client-basierten Onlinespiele hingegen, also Spiele, die eine lokale Software
benötigen, beruhen auf dem Client-Server-Prinzip, so dass der Betreiber zur Unterhaltung
einer
MMOG-Spielergemeinde von mehreren hunderttausend Teilnehmern, über
regelrechte „Serverfarmen“ verfügen muss. Die Auslastung bei (zeitkritischen) Spielen
wird dann auf verschiedene Server verteilt. Um eine gemeinsame Spielwelt zu simulieren,
gibt es die Möglichkeit, die Welt in Zonen aufzuteilen, die jeweils einem Server zugeteilt
werden.
Jeder Server hält dann einen virtuellen geographischen Teil des Gesamten und wird nicht
zu schnell überfordert (die Unterteilung der Welt geschieht nicht immer nur nach Zonen,
manchmal auch nach Instanzierung oder dynamischen Auslastungsverfahren). Verlässt
ein Spieler eine Zone, so kann eine Übergabe zum nächsten Server, also der nächsten
Zone, erfolgen. Da dieser Handover den Aufbau einer Verbindung zu einem anderen
Server bedeutet, kann es hier allerdings zu einer längeren Wartezeit kommen, die den
Spielfluss merklich bremst. Können aufgrund mangelnder Kapazität nicht alle Spieler in
einer Zone teilnehmen, so bleibt immer noch die Aufspaltung der Welt in „Shards“. Der
Unterschied zu Servershards besteht allerdings hierbei darin, dass die Spieler in der Lage
sind im Laufe der Zeit die Shards zu wechseln. Gruppen werden gegebenenfalls nicht
getrennt und die Kommunikation ist über einen gemeinsamen Zonen-Channel gegeben.
32
Abbildung 2.14: Zonenserver (4 Zonenserver, 1 Hauptserver, 3 Beispiel-Clients)
Abbildung 2.14 illustriert ein mögliches Zonenserversystem. Die Clients 1 und 2 sind beim
ersten Server angemeldet, während Client 3 über den vierten Server spielt. Sollte der
Spieler auf Client 3 seine Zone verlassen (zum Beispiel dargestellt durch das Verlassen
einer Stadt der Spielwelt), so regelt der Hauptserver, welche Zone, also Server, als
nächstes für Client 3 zuständig ist.
Latenz und Round Trip Time
Da wegen der oben beschriebenen Gründe fast ausnahmslos Client-Server-Systeme
eingesetzt werden, ist die Round Trip Time7 ein wichtiger Faktor für die Spieler. Ursachen
einer schlechten Verbindung zum Server und hoher Latenzzeiten sind beispielsweise
7
zu große Distanz zum Server
zu hohe Server- oder Netzauslastung (siehe Artikel [GaStar06])
zu langsamer Internetzugang („letzte Meile“)
Zeit, die ein Datenpaket von der Quelle zum Ziel und zurück benötigt
33
Um große Entfernung zum Spielserver zu vermeiden, werden häufig geographisch
verteilte Zugangspunkte zum Spiel angeboten. Beliebte Spiele (z.B. EverQuest
[EverQu99], World of WarCraft [WoW04]), die in den USA ihren Ursprung haben, sind
meist auch durch einen oder mehrere Servercluster in Europa und Asien vertreten (siehe
dazu Abschnitt 2.3.3)
Auch das Problem des langsamen Internetzugangs verschwindet zunehmend. Laut
Statistik der Bundesnetzagentur des Jahres 2005 [BuNetz05] verfügen bereits 27% der
deutschen Haushalte über einen DSL-Anschluss (im Vergleich zu 17% im Jahr 2004). Im
Bereich mobiler Endgeräte hingegen ist der Anschluss zum weltweiten Netz immer noch
ein Faktor, der die Spielfreude erheblich beeinflussen kann. Zwar ist durch Techniken wie
GPRS, welches in etwa Datenraten eines Modems ermöglicht, und vor allem UMTS mit
Transferraten bis 384 kbit/s theoretisch genug Bandbreite für die Beteiligung an
Onlinespielen gegeben, allerdings hängt die Konnektivität auch von der Infrastruktur der
mobilen Umgebung ab (plus eventuellen Hindernissen der mobilen Umgebung, die die
Ausbreitung der elektromagnetischen Wellen behindern). Auslastung der Funkzelle,
Entfernung und Sicht zu den Antennen, sowie schnelle Bewegung des Benutzers und
Handovers in eine andere Zelle (sofern kein Soft Handover unterstützt wird) sind störende
Größen (siehe nächstes Kapitel). Ferner sind die Gebühren für die mobile Internetnutzung
noch (Stand April 2005) sehr hoch und verschrecken viele Hobbyspieler (Beispiel Japan:
umgerechnet 10 Euro pro übertragenem MB Daten).
Die Frage nach der maximalen Latenz, die ein Onlinespiel noch „erträglich“ durchführbar
macht, ist bei zeitkritischeren Spielen wie FPS noch strenger zu bewerten als bei
Rollenspielen (allgemeinen Papers zufolge hat man sich bei RTS und FPS auf einen
maximalen Wert von 150ms, bei RPGs in einem Bereich um 350-500ms geeinigt). Da
aber auch Rollenspiele immer zeitnaher durch aufwendige 3D-Grafik dargestellt werden
und Kämpfe schnelle Reaktionsfähigkeit verlangen sollen, zeigen MMORPGs mittlerweile
ähnliche Toleranzschwellen bezüglich der Ping-Zeiten.
Abbildung 2.15 zeigt beispielhaft auf, wie die Spielbarkeit bei Quake 3 [Quake3],
gemessen an der Anzahl der Frags, das heißt der „getöteten Mitspieler“, bei zwei
verschiedenen Serverstandorten mit steigender RTT, immer weiter sinkt [OpScore05].
34
Abbildung 2.15: Beziehung Frags pro Minute zu Ping-Zeiten (Quake III Deathmatch mit
äquivalenten PCs)
Paketverluste
Der Verlust eines Paketes kann kurzzeitig falsche Darstellungen in der Spielwelt oder in
der Wahrnehmung des Spielers bewirken. Die Spielserver können dem teilweise
entgegenwirken, indem sie bei einem Paketverlust anhand der zuletzt gelieferten Daten
die wahrscheinlich folgenden Bewegungen und Aktionen des Spielers voraussagen (Dead
Reckoning). Sollten diese Berechnungen jedoch falsch sein, so muss die Position des
Spielers nachträglich korrigiert werden (dynamische Prediktion), so dass unnatürliche
Änderungen an der Spielwelt vorgenommen werden (plötzliche Änderung der Position).
Besonders ärgerlich bei FPS ist der Verlust von Paketen, die einen Schuss auf ein Objekt
an den Server melden sollen. Der Spieler erkennt lokal, dass das Objekt getroffen wurde,
erhält aber keine Bestätigung vom Server und somit auch keinen „Score“.
Jitter
Jitter8 ist ein weiterer unerwünschter Effekt, der die Spielbarkeit merklich beeinflussen
kann. Darunter versteht man die Varianz der Latenz, also Schwankungen in den
Verzögerungszeiten.
8
Jitter (engl.): Schwankung
35
Würden die Latenzen halbwegs konstant bleiben, so könnten Spieler die Verzögerungen,
die durch das Netzwerk entstehen in das eigene Spiel einbauen, indem Sie die
Bewegungen der Gegenspieler antizipieren und somit in Shootern zum Beispiel nicht
direkt auf ihre Gegner schießen, sondern in ihre Laufbahn zielen (Vorhalten oder PreAiming). Starker Jitter macht diese Möglichkeit zunichte.
Die Entstehung von Jitter kann viele Ursachen haben, wie die Verwendung
unterschiedlicher Routingwege oder eine schwankende Auslastung des eigenen
Internetanschlusses, wenn zusätzlicher Hintergrund-Traffic durch weitere Internetnutzer
(durch LANs) oder Prozesse vorhanden ist (besonders durch das Verwenden von P2P
Sharing Tools wie Edonkey, Emule oder Morpheus kann auch begrenzter Upload dazu
führen, dass Antworten nicht vollständig oder stark verzögert empfangen werden).
Ein sehr starkes Jittering kann einen ähnlichen Effekt wie ein Paketverlust erzeugen:
werden Pakete zum Server nicht rechtzeitig ausgeliefert (Updates werden in einem
vorgesehenen Intervall angenommen), so kann dieser die Datenpakete im schlimmsten
Fall gänzlich ignorieren [OpScore05].
2.3.3.
Fallbeispiel: World of WarCraft
Zum Abschluss dieses Kapitels wird kurz ein Spiel aus dem MMORPG-Bereich als reales
Beispiel der genannten Techniken vorgestellt. Dabei handelt es sich um das im Jahr 2005
erschienene Spiel „World of WarCraft“, das im ersten Jahr weltweit über 5 Millionen Mal
verkauft wurde, aktuell mehr als 6 Millionen Mitspieler besitzt und damit das zweit meist
gespielte MMORPG der Welt ist.
Spielablauf
Jeder Spieler muss sich zunächst für eine Fraktion entscheiden, Allianz oder Horde,
wobei anschließend je nach Fraktion eine Rasse (zum Beispiel Menschen, Zwerge, Orks)
und Klasse (zum Beispiel Magier, Jäger, Krieger) für den eigenen Charakter gewählt wird.
Die Spielwelt selbst besteht aus zwei Kontinenten, auf denen verschiedene Dörfer und
Städte zu finden sind, die bereist werden können. Durch Bestreiten diverser Missionen
(Quests) und Kämpfe kann der Spieler Erfahrungspunkte sammeln und so die Fähigkeiten
seines Charakters weiterentwickeln.
Das Spiel unterstützt vier verschiedene Modi. Im PvE-Modus (Player versus Environment)
liegt der Schwerpunkt auf der Erkundung der Umgebung und das Bekämpfen
gegnerischer Spieler, das heißt Spieler einer anderen Fraktion, ist nur möglich, wenn
36
beide Spieler einem Duell zustimmen. Das Hauptziel des späteren PvE-Spiels besteht im
so genannten Raiding9 (40 Spieler versuchen zusammen starke Dungeons zu
bezwingen). Im PvP-Modus (Player versus Player) besteht die Gefahr häufigerer Kämpfe.
Die Welt ist im PvP-Modus in 3 Zonen eingeteilt: freundlich, feindlich und umkämpft. In
freundlichen Gebieten kann man selbst nicht angegriffen werden, kann aber feindliche
Gegner attackieren. In feindlichen Gebieten kann man hingegen ständig attackiert
werden, selbst aber keinen Kampf starten. Die umkämpften Gebiete erlauben zu jeder
Zeit einen gegenseitigen Angriff. Der RP-Modus (Role Playing Modus) stellt die Rolle des
eigenen Charakters in der virtuellen Spielwelt in den Vordergrund. Jeder Charakter hat
seine eigene Geschichte und es wird darauf geachtet, dass eine angemessene
Rollenspiel-Verhaltensweise
und
Sprache
verwendet
wird.
Dies
kommt
dem
ursprünglichen Gedanken eines Rollenspiels am nächsten. Der vierte Modus, RP-PvP,
entspricht einem PvP-Modus mit den Eigenschaften eines RP-Spiels. Insgesamt kann
jeder Spieler mehrere Charaktere (maximal 10 pro Spielwelt) erzeugen. Eine derartige
Aufteilung der Spielwelt wird als Individualisierung der Shards bezeichnet und bietet der
Zielgruppe genauere Informationen über die Spielwelt. In extremen Fällen können
grundsätzliche Regeln einer Spielwelt komplett verschieden im Vergleich zu „normalen“
Shards sein. [Wiki06b]
Server
World
of
WarCraft
benutzt
verschiedene
Serverstandorte,
wie
beispielsweise
Servercluster in Europa oder den USA. Die Server werden auch als Realms bezeichnet.
Ein Spieler kann sich bei einem der vielen Realms anmelden, die sich durch oben
beschriebene Spielmodi oder unterstützter Sprache unterscheiden können. Es befinden
sich im Durchschnitt etwa 2.500 Spieler gleichzeitig auf dem US-Server (Abbildung 2.16
nach [WRealms06]).
9
Raiding (engl.): überfallen
37
Abbildung 2.16: Durchschnittliche WoW-Spieleranzahl in 24 Stunden auf den US-Servern
38
3. Mobile Netzwerke
“Never trust a computer you can’t throw out a window.”
– Steve Wozniak, Gründer von Apple
Kommunikation mit mobilen (und insbesondere drahtlosen) Geräten ist auf zwei
erdenkliche Weisen möglich: durch die Bildung eines Netzwerks mit Hilfe einer
gegebenen Infrastruktur unter Verwendung zusätzlicher Hardware (zum Beispiel über
„Hot Spots“, also Access Points) oder die spontane Vernetzung unter den Geräten selbst
zu einem Ad-Hoc Netzwerk. Bei gegebener Infrastruktur können dann etwa Anschlüsse
zu weiteren Netzen, wie dem Internet, hergestellt werden.
Im Gebiet der mobilen Multiplayerspiele sind Ad-Hoc Netze von besonderem Interesse,
wenn man an Szenarien wie das Bilden einer spontanen Spielgemeinschaft etwa beim
Warten am Bahnhof oder in der Pause auf dem Schulhof denkt. Jedoch kann mit der
immer weiter verbesserten Infrastruktur und besseren Übertragungstechniken wie etwa
UMTS oder der großen Verbreitung von WLAN Hot Spots das Internet in naher Zukunft
jederzeit und fast überall mit für Spiele annehmbaren Datenraten zugänglich gemacht
werden und daher Zugang zu beliebig großen (wenige Spieler bis hin zum MMOGBereich) Spielgemeinschaften ermöglichen.
Der Anschluss der mobilen Geräte an einen Zugangspunkt der Infrastruktur erfolgt über
unterschiedliche Übertragungstechniken. Die Infrastruktur kann dann nicht nur ein lokales
Netz für die mobilen Knoten aufspannen, sondern auch eine Schnittstelle zu einem WAN
darstellen. Der Zugriff auf einen solchen Access Point (kurz AP), geschieht entweder
durch eine entsprechende Verkabelung (zum Beispiel Ethernet) oder aber über drahtlose
(wireless) Verbindungen.
Drahtlose Kommunikation bietet ein weitaus höheres Maß an Mobilität, so dass
nachfolgende Abschnitte sich auf die bedeutendsten Funkübertragungstechniken und
Protokolle der mobilen Kommunikation beschränken.
39
3.1. Übertragungstechniken
3.1.1.
Bluetooth (802.15)
Geschichte
Die Motivation hinter der Bluetooth-Funktechnik war die Abschaffung kurzer Kabel zur
einfachen Vernetzung von Geräten. Bereits 1994 von Ericsson entwickelt, wurde die
Grundlage zur weiten Verbreitung der Bluetooth-Technik erst mit der Gründung einer
Special Interest Group (SIG) durch mehrere Unternehmen (Ericsson, IBM, Intel, Nokia,
Toshiba) im Jahre 1998 geebnet [Wiki06c].
Wenig später beschäftigte sich auch das IEEE-Gremium mit dieser Technik und
genehmigte 2002 den Standard 802.15.1, ein Standard für WPANs auf Basis von
Bluetooth [IEEE02].
Technik
Bluetooth nutzt für den Funkverkehr das lizenzfreie ISM-Band10 im Bereich von 2,4GHz.
Da unter anderem WLANs diesen Frequenzbereich nutzen, können Störungen verursacht
werden. Um dem entgegen zu wirken, verwendet Bluetooth das Frequency Hopping
Verfahren, bei dem das gesamte Frequenzband in 79 Kanäle zu je 1MHz aufgeteilt wird
und verwendete Kanäle ständig gewechselt werden (1600 Sprünge pro Sekunde). Dieses
schnelle Umschalten sorgt allerdings dafür, dass der Bluetooth-Verkehr eher den anderen
Verkehr stört, als selbst gestört zu werden [Tan03b].
Es gibt verschiedene Klassen von Bluetooth-Modulen, die verschiedene Sendeleistungen
anbieten, mit denen Reichweiten von 10-100m ansprechbar sind. Es werden sowohl
synchrone als auch asynchrone Übertragungen unterstützt. Im asynchronen Modus kann
eine
symmetrische
Übertragung
mit
maximal
433,9
kbit/s
erfolgen
und
eine
asymmetrische Übertragung mit maximal 723,2 kbit/s in die eine und 57,6 kbit/s in die
andere Richtung. Im synchronen Betrieb, der für die Übertragung von Sprache gedacht
ist, stehen bis zu 3 Kanäle zur Verfügung mit einer symmetrischen Übertragungsrate von
je 64 kbit/s. Durch das EDR-Verfahren, eine Technik, die andere Modulationsverfahren
einsetzt, sind sogar Brutto-Übertragungsraten von 2 oder 3 Mbit/s möglich.
Architektur
Bluetooth-Geräte sind Teil eines oder mehrerer Piconetze, die jeweils maximal 8 Knoten
unterstützen. Ein ausgewählter Master-Knoten regelt dabei, welcher Slave-Knoten wann,
10
Industrial, Scientific and Medical Band
40
das heißt in welchem Zeitschlitz, übertragen darf und gibt die Sprungsequenzen des
Frequency Hoppings vor. Um mehrere Piconetze über Bluetooth zu realisieren, kann ein
Knoten, ein so genannter Bridge-Slave, eine Brücke zwischen zwei Netzen bilden. Das
Benutzen des Master-Slave-Systems ist unter anderem darauf zurückzuführen, dass
Module besonders preiswert angeboten werden sollten. Da ein Slave-Modul nicht allzu
viel Komplexität verlangt, können diese sehr billig produziert und angeboten werden.
Es sei noch angemerkt, dass die gebildeten Piconetze zwar einem Ad-Hoc Netzwerk
entsprechen, allerdings wäre auch eine Bluetooth-Kommunikation im Infrastruktur-Modus
denkbar (Bluetooth-HotSpots für Handybesitzer).
3.1.2.
Wireless LAN (802.11)
Geschichte
Mit der Entwicklung des Computermarktes hin zu mobilen Endgeräten entstand auch die
Nachfrage nach einer Netzwerkanbindung der neuen Notebooks und PDAs. Man stellte
sich vor, wie praktisch es wäre, wenn diese Geräte automatisch eine Netzwerkverbindung
herstellen würden, wenn man seinen Arbeitsplatz wechseln würde. Dies führte zur
Entwicklung der drahtlosen LANs, deren Standardisierung durch das IEEE-Gremium 1997
durchgeführt wurde. Der erste Standard mit der Bezeichnung 802.11 erreichte Datenraten
von zunächst 1 Mbit/s. Da dies für viele Ansprüche nicht genügte, entstanden aus diesem
ursprünglichen Standard 1999 zwei neue Standards, die als 802.11a und 802.11b
bekannt sind. 802.11g ist ein weiterer Standard, der Techniken der beiden anderen
Standards verbindet. [Tan03c]
Technik
Auch WLAN benutzt das ISM-Band im Bereich von 2,4GHz. Dieser Frequenzbereich wird
abgesehen von Bluetooth auch von anderen Quellen wie Mikrowellen gestört. Die
Technik, die bei 802.11a Übertragungsraten bis zu 54 Mbit/s bereitstellt, beruht auf der
Verwendung eines breiteren Frequenzbandes und eines Frequenzmultiplex-Verfahrens
(OFDM, Orthogonal Frequency Division Multiplexing) und arbeitet im 5GHz Band. Der
Standard 802.11b hingegen benutzt ein anderes Modulationsverfahren und erzielt
Datenraten bis 11 Mbit/s.
Architektur
Der Standard 802.11 funktioniert sowohl im Ad-Hoc-Modus als auch über eine
Basisstation. Wie im vorherigen Kapitel erwähnt, gibt es bei Funknetzwerken im
Gegensatz zu „verkabelten“ Netzwerken wie Ethernet, einige Probleme. Das Hidden-
41
Station Problem kann auftreten, wenn zwei Stationen nicht in Funkreichweite sind und
gleichzeitig zu einer dritten Station senden wollen, die im Funkbereich beider liegt. Da die
beiden Stationen sich gegenseitig nicht empfangen können, gibt die Prüfung des
Mediums durch eine Station „grünes Licht“ zum Senden an die dritte Station. Wenn diese
aber schon mit der Hidden Station kommuniziert, bleibt das Senden erfolglos. Ein anderes
Hindernis des Funkverkehrs sind Situationen, in denen das Medium scheinbar belegt ist.
Wenn nun aber zwei unbeteiligte Stationen kommunizieren, so wäre eigentlich ein
Austausch zwischen zwei anderen Stationen möglich. Ferner arbeiten die meisten
Funkmodule nur halbduplex, so dass ein gleichzeitiges Senden und Abhören des Kanals
auf eventuelle Kollisionen meist nicht möglich ist, so dass im Standard 802.11 das
CSMA/CA-Verfahren Anwendung findet.
3.1.3.
GSM und GPRS
Geschichte
GSM (zuerst benannt nach der Arbeitsgruppe Groupe Spécial Mobile, seit 1991 bekannt
als Global System for Mobile Communications) war der erste digitale Mobilfunk-Standard,
der nach der analogen Technik der ersten Generation folgte. Er ist (Stand April 2006) der
am weitesten verbreitete Standard und ist mit wenigen Ausnahmen (zum Beispiel Japan)
in den meisten Ländern mit einem Gesamtanteil von etwa 78% aller Mobilfunkkunden
vertreten.
Trotz
digitaler
Technik,
war
GSM
zunächst
hauptsächlich
für
Sprachübertragung gedacht. Der rasante Aufstieg des Internets sorgte dafür, dass GSM
nun auch „webtauglich“ gemacht werden sollte und einige Erweiterungen erfuhr. Diese
Erweiterungen, wurden anschließend durch den Begriff 2,5G beschrieben, der einen
Schritt in Richtung der Mobilkommunikation der dritten Generation bezeichnen sollte. Um
Internet auf dem mobilen (Sprach-)Netz durchzusetzen, wurde ein paketvermittelter
Dienst aufgesetzt, der General Packet Radio Service. [Wiki06d]
Technik
GSM benutzt Frequenzen im Bereich von 450MHz bis 1900 MHz, wobei in Europa
insbesondere Frequenzen um 900 MHz (GSM 900) und 1800 MHz (GSM 1800)
verwendet werden. Die Frequenzen werden in Bändern zu je 200 kHz eingeteilt, wobei für
eine Kommunikation eines Endteilnehmers ein Uplink-Kanal zur Basisstation und ein
niederfrequenter Downlink-Kanal benutzt wird (bei GSM 900 124 Kanäle à 200 kHz pro
Richtung). GSM verwendet außerdem ein Zeitmultiplexing, so dass pro Kanal acht
unterschiedliche Zeitschlitze existieren. Pro Kanal ist eine Übertragungsrate von 270.833
42
Bit/s möglich, das entspricht pro Zeitschlitz 33,854 kbit/s. Nach Abzug des Overheads und
der
Fehlerkorrektur
erhält
man
eine
Nettorate
von
etwa
13
kbit/s
für
die
Sprachübertragung. [Tan03d]
Im Bereich der Datenübertragung sind Datenraten von 9,6 kbit/s bis 14,4 kbit/s üblich. Für
viele Internetanwendungen wie Videostreaming sind solche Datenraten zu gering, so dass
andere Lösungen her mussten. GPRS ist ein paketorientierter Dienst, der die 8 zur
Verfügung stehenden Zeitschlitze dynamisch nutzt. Ist die Auslastung eines Kanals nicht
zu hoch, so ist es leichter, entsprechende Zeitschlitze bereit zu stellen, so dass mehrere
Teile des Pakets „parallel“ gesendet werden können. In der Praxis werden meist bis zu 4
Zeitschlitze gleichzeitig für den Download und 2 Zeitschlitze für den Upload angeboten.
Bei geringer Netzauslastung ist daher eine maximale Datenrate von 53,6 kbit/s realistisch.
Die Reichweite von GSM kann zwischen wenigen hundert Metern und über 30km
schwanken, je nachdem wie die Sichtverhältnisse der Umgebung sind. [Wiki06e]
Architektur
Möchte eine mobiles Endgerät (Mobile Station) über GSM kommunizieren, so muss es
sich in einer Funkzelle, also „in der Nähe“ der Antennen einer Basisstation (Base
Transceiver Station), befinden. Die Basisstation und ihre Steuereinheit (Base Station
Controller) werden als Base Station Subsystem bezeichnet. Der Übergang vom
Funkverkehr in das Festnetz wird dann von der Vermittlungsstelle, dem Network
Subsystem bewerkstelligt. Bei GPRS übernimmt hier eine andere Einheit (Serving und
Gateway GPRS Support Node) den Übergang in ein paketbasiertes Netz (Internet).
3.1.4.
UMTS
Geschichte
UMTS (Universal Mobile Telecommunications System) ist ein Mobilfunk-Standard der
dritten Generation (3G). Der globale Standard IMT-2000 [IMT2000] wurde Anfang der
90er
Jahre
vorgestellt
und
formulierte
einige
Anforderungen
an
Mobilkommunikationssysteme der dritten Generation, wie beispielsweise eine gewisse
Bandbreite (ursprünglich geplant: 2 Mbit/s), die Multimediaanwendungen des Internets
ermöglichen kann.
Die neue Technik entfachte eine Euphorie bei den Mobilfunkanbietern, die scheinbar eine
enorme Umsatzquelle gefunden hatten. Die Verteilung der vorhandenen UMTS-
43
Frequenzen an die Anbieter der verschiedenen Länder geschah entweder durch
Bewerbungen der verschiedenen Mobilfunkanbieter („Schönheitswettbewerb“) oder – wie
in Deutschland – in Form einer Versteigerung. So kam es im August 2000 zur „teuersten
Auktion der deutschen Wirtschaftsgeschichte“ [FAZ05], in der sechs Unternehmen
Lizenzen im Wert von etwa 100 Milliarden Deutschen Mark ersteigerten. Leider
entwickelte sich der UMTS-Markt in den folgenden Jahren nicht so schnell und stark wie
erwartet und erst Ende 2003 wurden die ersten Gebiete mit UMTS ausgestattet. Auch
wenn die Infrastruktur weiterhin verbessert wird, so ist UMTS für die meisten privaten
Anwender aufgrund der hohen Preise derzeit uninteressant. Die Frage, ob sich die
Telekommunikationsunternehmen bei der Ersteigerung verspekuliert haben, ist demnach
mehr als berechtigt, insbesondere in Anbetracht der Tatsache, dass das der Wunsch
nach einem „allgegenwärtigen“ Internet unter Umständen durch schnellere Techniken wie
WLAN, falls es Flächen deckender eingesetzt wird, verwirklicht werden kann.
Technik
Die verwendete Übertragungstechnik bei UMTS ist das Codemultiplex-Verfahren WCDMA
(Wideband Code Division Multiple Access), bei dem ein Frequenzband von mehreren
Teilnehmern gleichzeitig benutzt wird und die einzelnen Benutzer Nachrichten, die für sie
bestimmt sind, anhand eines orthogonalen Codemusters zurückgewinnen können. Durch
die „Spreizung“ des Signals wird die Übertragung nicht mehr all zu sehr durch starke
schmale Störimpulse gestört.
UMTS gibt es in zwei Varianten. Der FDD-Modus (Frequency Division Duplex) hält je
einen Kanal für den Downlink (im Bereich 2.110 MHz – 2.170 MHz) und den Uplink (im
Bereich 1.920 MHz – 1.980 MHz) bereit. Im TDD-Modus (Time Division Duplex, 1.900
MHz – 1.920 MHz und 2.020 MHz – 2.025 MHz) senden mobiler Endteilnehmer und
Basisstation Zeit versetzt in der gleichen Frequenz. Die Datenübertragungsrate hängt
wieder von verschiedenen Faktoren ab, wie der Auslastung der Funkzelle und der
Bewegung des Endteilnehmers. Um den Ansprüchen des ursprünglichen Standards
gerecht zu werden, sollte eine Rate von 2 Mbit/s angestrebt werden. In der Praxis können
UMTS-Kunden in einem FDD-Netz Datenraten bis zu 384 kbit/s erhalten. TDD kann zwar
noch höhere Übertragungsraten erzielen, wird aber bisher kaum eingesetzt. T-Mobile
beispielsweise erhält mit einem UMTS-TDD-Netz in Tschechien Geschwindigkeiten bis zu
4,5 Mbit/s. Allerdings lag die durchschnittliche Übertragungsrate mit 512 kbit/s deutlich
niedriger. [Telek05]
44
3.1.5.
WMAN (802.16)
WMAN steht für Wireless Metropolitan Area Networks und beschäftigt sich mit
Breitbandanschlüssen, die drahtlos in größeren Reichweiten, wie einem gesamten
Stadtbereich, verfügbar und zum Beispiel eine Alternative zu DSL auf der „letzten Meile“
sein sollen. Viele Regionen sind immer noch nicht mit DSL Anschlüssen versorgt und
durch WMAN soll eine kostengünstige Alternative entstehen, die keiner teuren
Infrastruktur (Verkabelung) bedarf. Die Arbeitsgruppe IEEE 802.16 entwickelt diverse
Standards im WMAN-Bereich, der auch als WiMAX (Worldwide Interoperability for
Microwave Access) bekannt ist.
Zunächst für den Anschluss stationärer Teilnehmer gedacht, wird seit Juli 2002 im
Standard 802.16e versucht, WiMAX auch für mobile Benutzer zugänglich zu machen. Es
wird erwartet, dass innerhalb einer Reichweite von 3 km eine Bandbreite von 15 Mbit/s
oder mehr für mobile Kommunikation realistisch ist und im Jahr 2007 erste HandheldComputer mit entsprechenden Funkkarten ausgestattet werden [WiMAX06].
Eine weitere Arbeitsgruppe der IEEE arbeitet an dem Standard 802.20, der vergleichbar
mit
802.16e
ist,
allerdings
in
einem
anderen
Frequenzband
sendet
und
Übertragungsgeschwindigkeiten im DSL-Bereich auch bei schnellen Bewegungen bis zu
250km/h bieten soll. [802.20]
Ob 802.16e oder 802.20 eine Alternative, Ergänzung oder sogar bessere Lösung als
UMTS darstellt, ist eine heftige Diskussion, die wohl erst in den nächsten Jahren gelöst
werden kann. Eine sachliche Einschätzung des mobilen WMAN scheint derzeit nicht
möglich, wenn man bedenkt, dass Unternehmen, die Milliarden teure Lizenzen ersteigert
haben, nicht einfach UMTS fallen lassen werden, um auf die nächste Technik
„aufzuspringen“ und daher UMTS vehement verteidigen.
3.2. Beeinflussung drahtloser Kommunikation
Zwar können „verkabelte Systeme“ ebenfalls gestört oder unterbrochen werden,
allerdings ist die Beeinflussung der drahtlosen Kommunikation durch verschiedene
Störgrößen ungleich größer. Die Garantie einer gewissen Bandbreite (und vor allem der
Erhalt der Verbindung mit einem drahtlosen Endgerät selbst) ist von Faktoren
verschiedener Natur abhängig, von denen im Folgenden einige aufgezeigt werden.
45
3.2.1.
Netzauslastung und Zellatmung
Bei Systemen, die mehrere Teilnehmer durch Zeit- und Frequenzmultipexing verwalten,
existiert das offensichtliche Problem, dass auch die Anzahl der Kanäle oder Zeitschlitze
begrenzt ist und eine hohe Teilnehmeranzahl in einer Funkzelle dazu führen kann, dass
keine Verbindung hergestellt werden kann oder sogar Verbindungen abgebrochen
werden, wenn Anforderungen höherer Priorität wie Notrufe bereits verbundene Nutzer
verdrängen. Bei GPRS drohen bei hoher Netzlast Einbrüche der Datenrate, da weniger
Zeitschlitze für Datenpakete zur Verfügung stehen.
Bei Codemultiplex-Systemen wie UMTS tritt ferner das Problem der so genannten
Zellatmung auf. Da beim CDMA-Verfahren alle Signale „gemischt“ übertragen werden,
wird das gesamte Rauschen mit jedem Teilnehmer einer Funkzelle stärker. Um weiterhin
das Nutzsignal vom restlichen Rauschen unterscheiden zu können, wird die Übertragung
der Endgeräte verstärkt. Da alle Endgeräte die Sendeleistung der Funkzelle teilen, kann
die Kapazität der Funkzelle bei vielen Teilnehmern bereits erschöpft sein und Teilnehmer,
die sich am Rand der Funkzelle befinden, werden nicht mehr versorgt. Die Funkzelle
„schrumpft“ und „wächst“ daher mit der Anzahl der Teilnehmer.
3.2.2.
Ausbreitung der Funksignale
Leider ist es in einer realen Umgebung sehr unwahrscheinlich, dass Signale genau in der
Form bei mobilen Empfängern ankommen, in der sie auch vom Sender losgeschickt
wurden. Während die Empfangsleistung im freien Raum bereits quadratisch mit dem
Abstand des Senders zum Empfänger abnimmt, können weitere Faktoren wie
Reflektionen, Beugungen und Streuungen an Gebäuden und anderen Hindernissen die
Leistung weiterhin schmälern. Durch diese „Störgrößen“ kann es zu Überlagerungen des
Signals beim Empfänger kommen, da die Funkwellen teilweise mehrfach und je nach
Wegewahl
phasenverschoben
eintreffen.
Auftauchende
Probleme
in
der
Empfangsleistung können sich in „kurzzeitigen Einbrüchen“ (fast fading, durch
Überlagerung der phasenverschobenen Signale) oder „langsamen Veränderungen“ (slow
fading, zum Beispiel durch allmählich zunehmende Entfernung zum Sender) äußern
[Schiller05]. Obwohl der Empfänger das ursprüngliche Signal aus den Überlagerungen
und Dämpfungen zurückgewinnen muss, ist die Mehrwegeausbreitung des Signals
durchaus sinnvoll, da so Kommunikation mit der Basisstation ohne direkten Sichtkontakt
möglich wird.
Ein weiteres Problem stellt die Verwaltung der sich verändernden Entfernung zwischen
mobilen Endteilnehmern und Basisstation dar. Diese ständige Änderung bedeutet auch
eine permanente Änderung der Signallaufzeiten. Bei GSM beispielsweise wird dem
46
entgegengewirkt, indem die Basisstation anhand der ermittelten Signallaufzeit der
Mobilstation mitteilt, um wie viele Zeiteinheiten das Senden der Mobilstation verzögert
werden soll, damit der Teilnehmer in seinem Zeitschlitz bleibt. Ein jeder Zeitschlitz besitzt
daher einen Puffer als Schutzzeit, um Verschiebungen der Signalankunft durch
wechselnde Teilnehmerentfernung zu bewerkstelligen.
3.3. Eignung drahtloser Übertragungstechniken für
mobile Spiele
Abgesehen von den eben beschriebenen Störfaktoren, die abhängig von der benutzten
Übertragungstechnik mehr oder weniger Einfluss auf die drahtlose Verbindung haben,
stellt sich die Frage, inwieweit die zur Verfügung stehende Technik überhaupt unter
nahezu optimalen Bedingungen für Netzwerkspiele geeignet ist.
Alle Techniken bieten anscheinend genug Bandbreite, um mehrmals pro Sekunde kleine
Spielupdate Pakete in der Größenordnung von weniger als 100 Byte zu senden und zu
empfangen. Der limitierende Faktor ist jedoch die Latenz, die sich gerade durch die
kleinen, ständig verschickten Pakete äußert: Angenommen ein solches 100 Byte Paket
wird über UMTS mit einer Übertragungsrate von 384 kbit/s verschickt, so dauert die
Übertragung etwa 2ms. Hierbei wird allerdings die Latenz übersehen, die bei UMTS in
etwa zwischen 200 und 300ms liegt [heise06]. Die für akzeptable Spielbarkeit von FPS
geforderte maximale Latenz von 150ms [Armi01] ist daher bei UMTS und vor allem
GPRS, welches teilweise Latenzen im Sekundenbereich haben kann, problematisch. Je
nach Echtzeit-Charakter eines MMORPG sind etwas größere Latenzzeiten im Bereich von
500ms tolerierbar und somit mit UMTS offenbar spielbar. GPRS hingegen biete keine
akzeptable Lösung für Echtzeitspiele, die eine geringe Latenz fordern.
Um zeitkritische mobile Netzwerkspiele zu realisieren, muss man folglich auf Techniken
mit geringerer Latenz zurückgreifen. Hier bieten sich Bluetooth (< 50ms) und das UMTSVerfahren HSDPA/HSPUA (High Speed Downlink/Uplink Packet Access) an, welches die
Latenzzeit auf 100ms und weniger reduzieren soll [heise06].
Lassen sich hohe Verzögerungszeiten nicht vermeiden, so kann schließlich über das
Spieldesign versucht werden, Latenzen zu verstecken, wie es beispielsweise im Spiel Die
Sims geschieht [Palm03]. Die zu steuernden Charaktere bewegen sich bei diesem Spiel
auch
ohne
Anweisungen
selbständig
und
erzeugen
so
den
Eindruck
eines
47
kontinuierlichen Spiels. Die verzögert ausgeführten Anweisungen werden dadurch ein
wenig verdrängt.
Zusammenfassend lässt sich feststellen, dass mobile MMOGs im Prinzip auch mit dem
aktuellen Stand der Technik (auch mit 2.5G) realisiert werden können, man aber das
Spieldesign auf Kosten der Echtzeit-Interaktion je nach Übertragungstechnik anpassen
muss.
3.4. Einführung in Standort basierte Dienste
Standort basierte Dienste, auch als Location Based Services (LBS) bekannt, sind
zusätzliche Dienste, die einem Teilnehmer eines mobilen Netzwerks anhand seiner
Position, also des Ortes an dem er sich befindet, angeboten werden können. Typische
LBS-Anwendungen können aus den folgenden Bereichen stammen:
Navigations- und Ortungssysteme: „Wo bin ich?“, „Wie komme ich an mein Ziel?“
Points of Interest (POI): „Wo finde ich eine bestimmte Sehenswürdigkeit / den
nächsten Bahnhof / das nächste italienische Restaurant?“
Buddy-Applikationen: „Wo sind meine Freunde?“
Notfall-Situationen: „Wo befindet sich der Verletzte / der Unfallort?“
Überwachung: „Wo befindet sich mein Kind?“
Ein System, dass LBS bereitstellt, muss abgesehen von der mobilen Kommunikation über
entsprechende
Positionierungsverfahren
und
Kontextwissen
(dies
kann
sowohl
geographisches Wissen als auch zusätzliche Information im Sinne eines POI-Services
umfassen) verfügen. Das bekannteste Positionierungsverfahren GPS ist nicht immer die
optimale Lösung, da es einige Nachteile, wie im Folgenden beschrieben, mit sich bringt.
Netzwerk-basierte Positionierungstechniken bieten manchmal eine Alternative zu GPS,
auch wenn diese ebenfalls einige Schwächen aufweisen.
3.4.1.
Global Positioning System (GPS)
Bei GPS wird die Position anhand der Signallaufzeiten und Positionen von vier Satelliten
ermittelt. Insgesamt stehen mindestens 24 Satelliten für GPS zur Verfügung, die auf 6
Bahnen verteilt sind und von Bodenstationen kontrolliert und synchronisiert werden. Da
48
GPS
ursprünglich
für
militärische
Zwecke
eingesetzt
wurde,
verwendete
das
amerikanische Militär zunächst einen Mechanismus, der nur Messgenauigkeiten auf
ungefähr 100m erlaubte. Diese „Selective Availability“ wurde im Jahr 2000 abgeschaltet
[USgov00]. Seitdem liegt die Genauigkeit bei weniger als 20m, mit so genanntem
differentiellen GPS sogar bei etwa 1m.
Die Positionierung selbst erfolgt durch Triangulation. Für jeden der vier benutzen
Satelliten ist die Entfernung zum Empfänger und die Position der Satelliten selbst
bekannt. Im Normalfall würden für die Bestimmung der dreidimensionalen Position des
Empfängers drei Bezugspunkte, sprich Satelliten, reichen (für Längengrad, Breitengrad
und Höhe). Um den Empfänger entsprechend zu synchronisieren, werden die Zeitsignale
der Satelliten verwendet. Um die zusätzliche Unbekannte „Zeit“ in der Rechnung zu
verwalten ist demnach ein vierter Bezugspunkt erforderlich [Wiki06f].
GPS hat den Nachteil, dass es bei schlechter Sicht zu den Satelliten häufig keine Signale
empfangen kann. Ferner kann der initiale Verbindungsaufbau (TTFF, Time to First Fix)
teilweise mehrere Minuten dauern, was vor allem in Notruf Situationen keine akzeptable
Lösung
ist.
Bisher
war
GPS
vorwiegend
als
Extra-Hardware
in
Form
von
Navigationssystemen erhältlich. Mittlerweile bauen auch Mobiltelefonhersteller immer
häufiger GPS-Chips in ihre Geräte [Silicon06].
3.4.2.
Netzwerk-basierte Positionsbestimmung
Trotz fehlender GPS-Module der Endteilnehmer können Netzbetreiber durch ihre
vorhandenen Infrastrukturen ihren Kunden LBS anbieten. Die Berechnung der Position
geschieht hierbei nicht über Satelliten, sondern durch Informationen, die die
Basisstationen einer Funkzelle liefern können [Magon06].
Cell of Origin (COO)
Die Position wird durch die Funkzelle identifiziert, in der sich der mobile Nutzer gerade
befindet. Die Genauigkeit hängt hier von der Infrastruktur ab. Je kleiner der Bereich der
Funkzelle, desto genauer die Ortung. In ländlichen Gegenden, in denen Funkmasten
mehrere Kilometer abdecken ist die Ortung also nur sehr grob. Der Vorteil von COO (auch
Cell-ID) ist der geringe Verwaltungsaufwand und die damit verbundenen niedrigen
Kosten. Das Verfahren kann etwas verbessert werden, wenn man zusätzlich den Timing
Advance Faktor berücksichtigt, der bei GSM die unterschiedlichen Laufzeiten die durch
Entfernungen entstehen, ausgleichen soll.
49
Time Difference of Arrival (TDOA)
TDOA benutzt die Signallaufzeiten zwischen Mobilstation und mehreren (mindestens drei)
Basisstationen, um Entfernungen zu den jeweiligen Stationen zu bestimmen und so auf
die Position der Mobilstation zu schließen. Die Ortungsgenauigkeiten liegen im Bereich
von 100-200m [OpWa02].
Angle of Arrival (AOA)
AOA analysiert die Winkel der Funkwellen bei Ankunft an einer Basisstation und erkennt
so die Herkunft, sprich Richtung des Signals der Mobilstation. Die Position der
Mobilstation erhält man durch Verwendung dieser Information von mindestens zwei
verschiedenen Basisstationen. Die Ortungsgenauigkeit von AOA ist ähnlich wie bei
TDOA. Sowohl für TDOA als auch AOA sind zusätzliche Aufrüstungen auf Seiten des
Netzwerkbetreibers um Vermessungseinheiten (LMU, Location Measurement Unit) nötig,
wobei zur Vermessung der Winkel bei AOA spezielle Antennen benötigt werden.
Enhanced Observed Time Difference (E-OTD)
E-OTD ist eine Art umgekehrtes TDOA. Hier nehmen im Wesentlichen die Mobilstationen
selbst die Vermessungen vor, so dass auch auf der Seite des Endteilnehmers
entsprechende
Softwareveränderungen
vorgenommen
werden
müssen.
Die
Ortungsgenauigkeit liegt dann bei etwa 50-200m [OpWa02].
3.4.3.
Assisted GPS (A-GPS)
Bei A-GPS wird GPS durch zusätzliche Information, die aus dem Mobilfunknetz
gewonnen wird unterstützt und stellt somit einen Hybridansatz aus Netzwerk-basierter
und GPS-Ortung dar. Die Endgeräte sind mit einem GPS-Empfänger ausgestattet und
erhalten über das drahtlose Netz Zugang zu einem so genannten Assistance Server, der
dem Empfänger weitere Hilfsdaten liefern kann.
Die Ortung mit GPS ist zwar sehr genau, hat aber entscheidende Nachteile:
50
Sehr große TTFF, das heißt einen lang andauernden ersten Verbindungsaufbau
zu den Satelliten
Beschränkter Empfang bei schlechter Sicht auf die Satelliten
Hoher Stromverbrauch des Endgeräts
A-GPS nutzt in den Mobilfunkzellen weitere fest installierte GPS-Empfänger mit guter
Sicht zu den Satelliten, durch deren Hilfe der mobile GPS-Empfänger die Suche nach
Satellitensignalen bereits stark einschränken kann und nur noch Signallaufzeiten zum
Satelliten ermitteln muss (also auch keine empfangenen Signaldaten in großem Umfang
dekodieren muss), während die fest installierten Empfänger bereits über alle
Satellitendaten verfügen. Dadurch wird sowohl die Positionsermittlung erheblich verkürzt
als auch der Stromverbrauch merklich gesenkt. Da keine Daten vom Satelliten dekodiert
werden, kann das Empfangssignal um einiges schwächer sein, und durch die Hilfsdaten
muss der mobile Empfänger nicht immer Sichtkontakt zu vier Satelliten haben.
Letztendlich werden so alle angesprochenen Schwachstellen von GPS behoben. A-GPS
ist aufgrund seiner Zuverlässigkeit die Technik, die für Standort basierte Dienste am
besten in Frage kommt, wie auch der Trend, GPS Module in Mobiltelefone einzubauen,
bestätigt.
3.4.4.
Weitere Ansätze
Zur Ortung können andere drahtlose Techniken eingesetzt werden, die die Position des
Teilnehmers mit Hilfe fest installierter Punkte, deren Position bekannt ist, ermitteln.
Zum Beispiel:
WLAN Zugangspunkte (Hot Spots)
Fest installierte Bluetooth Module (siehe [TagAttack05])
RFID Module
Der Einsatz von RFID Modulen ist besonders für Positionsermittlung in kleineren
Umgebungen sinnvoll. Die Ausstattung der mobilen Handhelds mit RFID-Lesern würde so
beispielsweise in einem großen Einkaufscenter Anwendung finden oder auch im Bereich
des Multiplayergamings könnte eine komplette Umgebung für Spiele präpariert werden
(vergleichbar mit einem Gotcha-Spiel).
51
4. Verwandte Arbeiten
“Jegliche Bewegung setzt ein Unbewegliches voraus.”
–
Thomas von Aquin, italienischer Philosoph
Dieses Kapitel betrachtet bereits umgesetzte oder geplante MMOGs für mobile Geräte
unter den Gesichtspunkten der beiden vorangehenden Kapitel und stellt ferner das
Design einer der wenigen entwickelten Middlewares für den mobilen Spielemarkt vor.
4.1. Mobile MMOGs
4.1.1.
TibiaME
TibiaME vom deutschen Softwareunternehmen CipSoft [CipSoft], die „Micro Edition“ des
PC Onlinespiels Tibia, startete im Frühjahr 2003 als erstes MMORPG für Handys. Das
Spiel findet in der mittelalterlichen Welt „Tibia“ statt und bietet typische Merkmale eines
Rollenspiels wie gemeinsames Kämpfen oder das Lösen von Quests mit menschlichen
Mitspielern. Die Entwicklung des Charakters steht im Vordergrund.
Abbildung 4.1: Tibia ME
Das Spiel wird von allen „Series 60“ Geräten [Series60] unterstützt und beruht auf einer
Client-Server-Architektur, wobei Updatenachrichten über GPRS an den Spielserver
gesendet werden. Nach Angaben des Herstellers ist die Kommunikation derart optimiert,
dass pro Spielstunde nur in etwa 400kB Traffic erzeugt wird um so die Kosten, die durch
GPRS entstehen gering zu halten. Das Spiel selbst gibt es in einer kostenlosen Version
53
und einer „Gold Version“, die zusätzliche Spielfeatures mit sich bringt und für eine
einmalige Downloadgebühr von ungefähr 5 Euro erhältlich ist. Das Benutzen der
Spielserver ist derzeit (Stand April 2006) kostenlos. Ursprünglich wurde das Spiel in
Zusammenarbeit mit T-Mobile entwickelt, und man einigte sich auf ein Geschäftsmodell,
bei dem der Hersteller, der auch die Spielserver bereitstellte, am Umsatz durch
übertragenes Datenvolumen beteiligt wurde [Nokia03].
Da bereits eine PC Version des Spiels existierte, konnten Großteile des Codes (vor allem
für den Server) wieder verwendet werden. Die Clientsoftware wurde in C++ für Symbian
OS implementiert. Bei der Umsetzung auf mobile Handhelds, mussten vor allem drei
Probleme gelöst werden:
der geringe Speicher der Handys
die Umsetzung der Userinterfaces
die hohe Latenz von GPRS
Das Spiel konnte mit etwa 390kB Speicherbelegung im Rahmen der Hardwareressourcen
bleiben, und die Komplexität des Userinterfaces des Originalspiels konnte sinnvoll
heruntergeschraubt werden. Um die hohe Latenz von teilweise mehreren Sekunden zu
verstecken, benutzt der Hersteller Vorhersage-Algorithmen, die bei sehr hoher Latenz
zwar keine Echtzeitinteraktion mit menschlichen Spielern ermöglichen, aber zumindest
das Spiel nicht zu stark ausbremsen. Je kleiner die Verzögerungszeiten, desto stärker
wird der Echtzeitcharakter des Spiels. Allerdings ist zum Beispiel eine Echtzeit-Aktion wie
der direkte Kampf gegen einen menschlichen Mitspieler - abgesehen von wenigen
Ausnahmesituationen – untersagt. Der Traffic selbst wird nach Angaben der Entwickler
gering gehalten, indem eine TCP-basierte Verbindung zum Server genutzt wird.
4.1.2.
Undercover 2: Merc Wars
Undercover2: Merc Wars [MercWars] ist ein MMORPG, dass Standort basierte Dienste
als optionales Feature nutzen kann. Der Spieler bewegt sich in einem futuristischen
Szenario der Erde. Auch hier kann der Spielcharakter Fähigkeiten dazu gewinnen und es
können Allianzen mit anderen menschlichen Spielern gebildet werden. Dazu kann die
ganze Welt bereist werden, während Feinde bekämpft und Missionen erfüllt werden.
54
Abbildung 4.2: Undercover2: Merc Wars
Das javabasierte Spiel läuft derzeit auf etwa 30 verschiedenen Handys und ist für eine
monatliche Gebühr von etwa 3 Euro plus GPRS-Kosten spielbar. Besitzt ein Spieler ein
GPS-fähiges Endgerät oder benutzt einen Mobilfunkanbieter, der LBS anbietet, so kann
die echte Umgebung in das Spiel miteinbezogen werden. Der Hersteller benutzt dazu
digitale Landkarten und Stadtpläne des Anbieters Navteq, der Content für LBSAnwendungen wie Navigationssysteme erstellt. Die Position des Spielers in der realen
Welt entspricht dann seinem Aufenthaltsort in der virtuellen Spielwelt.
4.2. Middleware für mobile Umgebungen
4.2.1.
GASP – Gaming Service Platform
GASP [Gasp05] ist ein Open Source Projekt zur Entwicklung einer Middleware für
Multiplayerspiele, die auf mobilen Endgeräten laufen kann, die J2ME Programme
unterstützen.
Das Design der Middleware ist an die Spezifikationen der Open Mobile Alliance [OMA06]
Game Services Arbeitsgruppe angelehnt. Diese Arbeitsgruppe, bestehend aus führenden
Anbietern
des
Mobilfunkmarkts,
legt
in
dieser
Spezifikation
Design-
und
Architekturstandards für die Entwicklung mobiler Computerspiele fest, wobei für den
Entwurf der Middleware insbesondere das Client-Server-Interface von Interesse ist
[OMA06b].
55
Das sogenannte Domainmodell eines Spielservers besteht nach [OMA06b] aus folgenden
Einheiten (Abbildung 4.3):
User: teilnehmender Spieler, der sich am Server anmeldet
Application: ein Spiel das auf dem Server angeboten wird, wobei
unterschiedliche Spiele, also Applications pro Server möglich sind
Actor: Repräsentation eines Users in einer Application, dies bedeutet ein
User kann pro Application einen Actor haben
Session: Spielsitzung, die für einen Actor, der an einer Application
teilnimmt, erstellt wird
ApplicationInstance: die verschiedenen Instanzen der Applications
ActorSession: Verbindung zwischen Actor und einer Instanz einer
Application,
Abbildung 4.3: Das Server Domainmodell der OMA GS Spezifikation
Zur Veranschaulichung der Aufgaben dieser Einheiten, wird ein erläuterndes Beispiel
gegeben (siehe auch Spezifikationen [OMA06b]):
Der User „John Doe“ meldet sich mit seinen Zugangsdaten beim Server an. Er kann
zwischen verschiedenen Applications wie Schach oder Poker wählen. Möchte „John
Doe“ eine Partie Poker spielen, so wird er dort durch seinen Poker-Actor repräsentiert
und eine Session erzeugt.
Dabei können beispielsweise beim Pokerspiel verschiedene Pokertische oder –partien,
also ApplicationInstances laufen. Meldet sich „John Doe“ bei mehreren
Pokertischen simultan an, so wird je Pokertisch (ApplicationInstance) eine
ActorSession erstellt.
56
GASP nutzt ein leicht verändertes Modell, das jedoch wesentliche Bestandteile wie die
Idee der Sessions und Actors erhält.
Da viele J2ME Geräte und Mobilfunk-Netzwerke auf das http-Protokoll über GPRS
beschränkt sind, ist der Server als Servlet implementiert, der http-Anforderungen durch
Clients bearbeitet und beantwortet.
Das GASP-Design wird durch folgende Einheiten beschrieben (Abbildung 4.4):
Platform Representation: zentrale Instanz, Verwaltung der Spielinstanzen und
dazugehöriger Actors bzw. ActorSessions
Servlet Container: Annahme und Bearbeitung der Anforderungen von Clients
über http (Communication Management)
Game Server: serverseitige Logik des Spiels
Datenbank: persistente Daten wie Accounts
Mobile: clientseitige Logik des Spiels sowie Kommunikationsschnittstelle
Abbildung 4.4: GASP Design
Zusätzlich nutzt GASP ein eigenes Nachrichtenprotokoll. Um die Größe der gesendeten
Pakete zwischen Client und Server möglichst gering zu halten, werden Daten nicht stur
serialisiert sondern unterschiedliche Pakettypen werden anhand eindeutiger IDs erkannt.
57
Die unterschiedlichen Nachrichten werden dafür in einer XML Struktur definiert ähnlich
wie es der Ansatz in [Hsiao05] vorsieht.
58
5. Entwurf und
Implementierung der
Middleware
“To err is human, but to really foul up requires a computer.”
–
Dan Rather, amerikanischer Journalist
Unter Middleware versteht man allgemein Software, die zwischen der Anwendungsschicht
und Betriebssystemschicht (beziehungsweise der Schnittstelle zur Hardware) angesiedelt
werden kann und Dienstleistungen für oben aufgesetzte Anwendungen bereitstellt, indem
sie Funktionen der darunterliegenden Schicht nutzt. Middleware arbeitet unabhängig von
der aufgesetzten Anwendung, so dass diese beliebig sein kann und wird häufig in
verteilten Systemen eingesetzt. Dort agiert die Middleware einem Protokoll ähnlich und
vereinfacht die horizontale Kommunikation zwischen Applikationen, die auf verschiedenen
(heterogenen) Systemen im Netzwerk verteilt sein können.
5.1. Middlewarekonzepte
Nach [Emmer00] kann man Middleware wie folgt klassifizieren:
Transaktionsorientierte Middleware
Nachrichtenorientierte Middleware (MOM – message-oriented middleware)
Prozedurale Middleware (RPC – remote procedure calls)
Objektorientierte Middleware
Bei transaktionsorientierter Middleware steht das Konzept der Transaktion, wie es in
Datenbanksystemen üblich ist, als Mittel der Kommunikation im Vordergrund.
MOM-Systeme kommunizieren klassisch über Nachrichtenaustausch und können somit
gegenseitige Anfragen senden und empfangen. Dabei werden Warteschlangen genutzt,
die Nachrichten zwischenpuffern.
Prozedurale Systeme erlauben den Zugriff auf Prozeduren entfernter Rechner, die dem
aufrufenden System daher wie lokale Prozeduren erscheinen. Der entfernte Aufruf (RPC)
wird hierbei mit allen Parametern versehen für die Übertragung serialisiert (auch bekannt
59
als marshalling) und beim Empfänger wieder deserialisiert (unmarshalling). Der Ablauf ist
standardmäßig synchron, so dass der aufrufende Prozess solange wartet, bis er eine
Rückmeldung vom Server erhält.
Objektorientierte Middleware erweitert die Idee der RPC indem Konzepte der
objektorientierten Programmierung genutzt werden. Statt auf Prozeduren kann nun auf
entfernte Objekte zugegriffen werden (zum Beispiel CORBA, RMI).
5.2. Middleware für MMOGs
5.2.1.
Vorteile
Der Einsatz einer Middleware für Onlinespiele bringt für alle beteiligten Parteien einen
Mehrwert.
Content-Programmierer
Die Programmierer des eigentlichen Spiels erhalten durch die Middleware eine
vereinfachte Schnittstelle zum Netzwerk, die von den technischen Gegebenheiten
abstrahiert. Der Content-Programmierer muss sich demnach nicht darum kümmern, durch
welche Architektur das Netzwerk verbunden ist und wie zu übertragene Daten in Pakete
gekapselt werden müssen. Einfache Funktionen dieser oberen Schnittstelle der
Middleware reduzieren damit Aufwand und Kosten der Entwicklung des Spiels.
Spielsoftware
Auch der Spielsoftware werden Funktionen der oberen Schnittstelle vereinfacht
bereitgestellt. Die Spielsoftware kann seine Anforderungen, die eine akzeptable
Spielbarkeit ermöglichen, an die Middleware stellen und erhält ein Feedback, ob diese
gewünschten Voraussetzungen vorhanden und erfüllbar sind. Anhand von Information,
die durch Abfrage des Netzstatus von der Middleware bereitgestellt werden, kann die
Software auf Unzulänglichkeiten reagieren und versuchen, durch geeignete Algorithmen
(zum
Beispiel
Vorhersage)
technische
Schwierigkeiten
auszugleichen.
Funktionen für die Applikation könnten sein:
60
Laden und Speichern von Daten während des Spiels
Lobbysysteme: finden und starten von Spielen, Highscore Handling
Weitere
Buddy- und Chatfunktionen
Spiel- und Netzbetreiber
Für Betreiber des Spielnetzwerks ergibt sich die Möglichkeit, dass zum Beispiel zukünftige
Ausfälle von Servern durch Wartungsarbeiten angekündigt oder Überlastungen rechtzeitig
mitgeteilt werden. Dadurch kann bereits im Vorfeld reagiert werden, und es können
Umleitungsstrategien oder Verteilungen (Load Balancing) rechtzeitig organisiert werden.
Die Wartung und Verwaltung wird insbesondere durch die Monitoring-Funktionen
erleichtert.
5.2.2.
Anforderungen
Eine Middleware für massive Multiplayerspiele sollte im Wesentlichen die folgenden
Kriterien beachten und optimal umsetzen.
Skalierbarkeit
Die Skalierbarkeit ist der entscheidende Faktor bei MMOGs. Zwar hängt er hauptsächlich
von der Netzwerkstruktur und Hardware ab, allerdings kann auch die Software die
Skalierbarkeit erheblich einschränken. Hierunter fallen vor allem die Entscheidung für das
verwendete Netzwerkprotokoll (TCP oder UDP) und die Kommunikationsart (RPC oder
MOM) aber auch schlechte Implementierungen der Kommunikationsverwaltung allgemein.
Vereinfachung der Spielentwicklung
Die Middleware soll den Spielentwicklern ein transparentes Nachrichtensystem ohne
Zusatzwissen über Netzwerkprogrammierung oder –struktur bieten und ebenso eine
Auswahl an verschiedenen Schnittstellenfunktionen für das Gaming bereithalten.
Zuverlässigkeit, Fairness, Fehlertoleranz
Das verwendete System sollte robust laufen und mit beabsichtigten oder zufälligen
Überlast- und Fehlersituationen wie einem plötzlichen Verbindungsabbruch zum Spieler
umgehen können. Bestimmte Nachrichten müssen beim Empfänger unter allen
Umständen ankommen. Ferner sollten möglichst alle verbundenen Spieler in gleichem
Maße mit Nachrichten bedient werden. Spieler, die das System stören oder missbrauchen
können notfalls gebremst oder ausgeschlossen werden.
61
Diese Faktoren hängen natürlich in hohem Maße von tieferen Schichten im
Netzwerkmodell ab, die zuverlässige und verbindungsorientierte Dienste anbieten.
Allerdings ist es teilweise nötig, verwendete Dienste auf höheren Schichten abzusichern.
Ein Beispiel stellt hier die Verwendung von unzuverlässigem UDP dar. In bestimmten
Situationen soll unter Umständen ein UDP Paket versendet werden (da es eventuell
schneller als TCP verschickt wird), das aber garantiert ankommen soll. Hier könnten
Bestätigungen, Zeitstempel und ähnliches auf Anwendungsebene mitgeschickt werden,
um beim Empfänger Ankunft und Reihenfolgetreue zu gewährleisten.
Preiswerte Wartung und Verwaltung
Es können Funktionen angeboten werden, die die Überwachung erleichtern (Monitoring)
und Probleme voraussehen oder künftige Wartungsarbeiten ankündigen und somit die
Möglichkeit schaffen, bereits im voraus ein Umorganisieren der verwendeten Server oder
Spielstrukturen zu erlauben.
Sicherheit
Dies umfasst unter anderem das Authentifizieren berechtigter Spieler, das Erkennen
gefälschter Identitäten oder Nachrichten und andere Formen des Cheatings.
5.3. Design- und Implementierungskriterien
Für den Entwurf und die Implementierung einer mobilen Multiplayer-Middleware ergeben
sich verschiedene Optionen für die Realisierung der Gaming-Schnittstelle „nach oben“
und der Netzwerk-Schnittstelle „nach unten“, die unter Berücksichtigung der eben
genannten Anforderungen geschehen soll.
5.3.1.
Gaming-Schnittstelle
Welche wesentlichen Funktionen soll die Middleware für den Programmierer und die
Spielsoftware bereitstellen?
62
Verwaltung der Spieldaten (Abrufen und Setzen der Eigenschaften von Spielern,
Objekten, z.B. Positionen in der virtuellen Welt)
Sende und empfange Nachrichten zum Server oder Spieler
Erstellen, Starten und Beenden eines Spiels (Verbindung aufbauen, Speichern
und Laden, Highscore Handling)
Lobby- / Chat- / Buddyfunktionen (finde Spiele, kommuniziere mit anderen
Spielern)
Monitoring (Beobachten von Latenz, Jitter)
Verwaltung der Spieldaten
Der Spielstatus kann, falls vom Spielentwickler gewünscht, zu großen Teilen von der
Middleware verwaltet werden. Während sich die Middleware grundsätzlich um Daten wie
„teilnehmende Spieler“ kümmert, können auch spielrelevante Daten wie Objektpositionen
abgefragt und gesetzt werden. Für die Implementierung sollte dann beachtet werden,
dass diese zusätzlichen Informationen möglichst generisch implementiert werden, da
diese Daten in großem Maße vom Design des Spiels abhängig sind und unter Umständen
Anpassungen bedürfen. Beispielsweise kann eine Klasse „Position“ je nach Spieltyp zweioder dreidimensionale Koordinaten beinhalten oder zusätzlich eine Orientierung
beinhalten.
Ferner kann man für Funktionen, die spielrelevante Daten zunächst lokal verändern und
dann zur Überprüfung an den Server schicken bei negativer Bestätigung des Servers das
Rückgängigmachen durch entsprechende Rollback-Funktionen unterstützen. Während die
Spielsoftware sofort auf Eingaben des Spielers reagiert und diese in die Tat umsetzt
(beispielsweise indem unter anderem Vorhersage-Algorithmen benutzt werden), werden
diese Aktionen mit leichter Verzögerungen durch den Server verifiziert.
Nachrichtenaustausch
Der Nachrichtenaustausch zwischen einem Client und einem Server (oder mehreren
Peers) sollte größtenteils implizit erfolgen, wenn Anforderungen über die GamingSchnittstelle, wie das lokale Setzen einer Spielerposition, erfolgen. Dies bedeutet, dass
die Middleware ein bestimmtes Repertoire an Nachrichtentypen (wie Statusupdates,
Loginanforderungen) beinhalten sollte. Um die Erweiterung durch die Spielprogrammierer
um zusätzliche Pakettypen nicht einzuschränken, sollten allerdings Nachrichtenfunktionen
existieren, die individuell erstellte Pakete versenden und empfangen können. Hierbei kann
ein Konzept zur Erstellung von neuen Pakettypen von der Middleware vorgeschlagen
werden.
63
Erstellen, Starten und Beenden eines Spiels
Je nach verwendeter Architektur, stehen Server- oder Client-typische Funktionen zur
Verfügung. Server-typische Funktionen beinhalten das Erstellen eines neuen Spiels unter
Angabe diverser Parameter wie die maximal zulässige Spieleranzahl oder Zuteilung
benachbarter Zonenserver. Clients können Serverlisten abfragen, sich bei einem Server
registrieren und anmelden.
Den Spielern soll das explizite Speichern ihrer Daten während des Spiels (Gewinnung
neuer Fähigkeiten oder Items im Spiel) ermöglicht werden, wobei auch eine AutosaveFunktion realisiert werden kann, die den Spielstatus in vorbestimmten Zeitabschnitten in
eine Datenbank überträgt.
Lobby-, Chat- und Buddyfunktionen
Da der Aspekt der zwischenmenschlichen Kommunikation bei Multiplayerspielen im
Vordergrund steht, sollten auch weitere Funktionen, die diesen Aspekt unterstützen, im
aber auch außerhalb des Spiels (also außerhalb der virtuellen Welt) angeboten werden.
Dazu können Features wie Chats bereits in der Middleware implementiert sein.
Monitoring
Informationen über den Netzwerkstatus sind sowohl für die Spielsoftware als auch für den
Spieler interessant. Die Software kann durch Informationen über Latenz und Paketverlust
Gegenmaßnahmen wie Bewegungsvorhersage von Objekten einleiten. Der Spieler kann
am „Ping“ erkennen, ob er vielleicht einen anderen Server aufsuchen sollte.
5.3.2.
Netzwerk-Schnittstelle
Für die Netzwerk-Schnittstelle stellen sich hauptsächlich zwei Fragen: soll die Anbindung
zum Spielserver verbindungsorientiert über TCP oder verbindungslos über einen
Datagrammdienst (UDP) realisiert werden, und welches Modell der oben beschriebenen
Middlewareklassifikation eignet sich am ehesten für Multiplayer-Onlinespiele?
64
TCP oder UDP?
Ob sich verbindungsorientierte Protokolle wie TCP oder verbindungslose Protokolle wie
UDP besser für die Client/Server-Kommunikation eignen, ist ein häufig diskutiertes Thema
unter
den
MMOG-Entwicklern.
Verschiedene
Spielentwickler
tendieren
zu
unterschiedlichen Lösungen [GamDev05]. Die Entscheidung für oder gegen eines dieser
Protokolle ist im allgemeinen eine Abwägung zwischen Zuverlässigkeit, Geschwindigkeit
und Skalierbarkeit.
Die Wahl des Protokolls ist somit vor allem von den Anforderungen des Spiels abhängig.
Da im MMOG-Bereich je nach Genre verschieden große Latenzzeiten akzeptierbar sind,
ist es denkbar, für rundenbasierte und langsamere Spiele auf TCP zurückzugreifen,
während für First Person Shooter durch häufige Bewegungen und Aktionen eher UDP
geeignet ist. Eine Middleware sollte daher grundsätzlich beide Optionen anbieten können.
Dies würde ebenfalls die Möglichkeit bieten, für Pakete, die sicher ankommen und
verwaltet werden müssen (wie Starten des Spiels und erstem Herunterladen des
Spielzustands oder einem Zonenserver-Wechsel), auf das verbindungsorientierte
Protokoll zurückzugreifen und schnelle, häufige Pakete (wie Aktionen während des
Spiels) durch unzuverlässige Datagramme zu versenden, deren eventueller Verlust durch
lokale Vorhersage minimiert werden kann.
RPC oder MOM?
Wie in [Hsiao05] beschrieben, hat eine nachrichtenorientierte Middleware für Onlinespiele
einige
Vorteile
gegenüber
der
prozedualen
oder
objektorientierten
Variante.
Beispielsweise erlaubt ein nachrichtenbasiertes System, dass Clients nach dem Senden
ihrer Anfragen an den Server, lokal bereits Berechnungen, die auf VorhersageAlgorithmen beruhen, durchführen können und nicht explizit auf die Antwort des Servers
warten müssen.
Ein weiterer wichtiger Faktor, der für MOM spricht, ist die Tatsache, dass besonders in
einem massiven Mehrspieler-Umfeld, welches außerdem noch mobile Teilnehmer
unterstützt, die Paketgröße der gesendeten Nachrichten von entscheidender Bedeutung
ist. Diese ist bei einem individuell erstellten Nachrichtensystem immer übersichtlich,
während bei RPC zusätzlich Daten für die zu verwendenden Prozeduren oder Objekte
serialisiert werden müssen.
65
5.3.3.
Die
Programmiersprache
Programmiersprache
Hardwareausnutzung,
kann
nach
Multithreading)
Kriterien
und
wie
Performanz
Kompatibiltät
(zum
Beispiel
beziehungsweise
Plattformunabhängigkeit gewählt werden.
So unterschiedlich die vielen verschiedenen mobilen Geräte sind, so unterschiedlich ist
auch die Unterstützung der verschiedenen Programmiersprachen. Die Möglichkeiten
reichen je nach Modell von einfachen WAP-Anwendung, über Java (insbesondere J2ME)
bis hin zu der Möglichkeit, C++ Programme entwickeln zu können. Die Frage lautet daher,
ob man sich auf eine Gerätegruppe (die zum Beispiel ein bestimmtes Betriebssystem
unterstützt) spezialisiert und die dafür nützlichste, also effektivste Sprache verwendet,
oder ob man ein möglichst breites Spektrum an Hardware abdecken will und damit
Einbußen in der Performanz toleriert.
5.4. Entwurf und Implementierung
5.4.1.
Struktur
Die hier entworfene Middleware ist standardmäßig als Client/Server-System ausgelegt.
Auf der Seite eines Clients und eines Servers werden neben spezifischen Klassen
dieselben Elemente verwendet.
Basis der Kommunikation zwischen Client und Server ist das Nachrichtensystem, dass
sowohl TCP als auch UDP unterstützt. Die Middleware präsentiert auf beiden Seiten eine
Netzwerkschnittstelle, die das Senden von Nachrichten zu anderen Spielern oder zum
Server ermöglicht. Die Gaming-Schnittstelle realisiert für Client und Server gemeinsame
Funktionen wie das Setzen der Position eines Spielers in der Spielwelt. Sie kann aber
auch spezifische Methoden beinhalten, die nur auf der Seite des Clients oder des Servers
Sinn ergeben.
Die hauptsächliche Aufgabe der Middleware besteht nun in der Verteilung und Annahme
der Nachrichten und dem Aufruf der dafür notwendigen Prozeduren. In einem typischen
Multiplayer-Szenario senden Clients regelmäßig Updatenachrichten an den Server, der
diese validiert und periodisch (unter Umständen korrigierte oder zusammengefasste)
Nachrichten an Spieler verteilt.
Die dafür nötigen Einheiten und deren Interaktionen sind in Abbildung 5.1 schematisch
dargestellt und werden in den folgenden Abschnitten erläutert.
66
Abbildung 5.1: Vereinfachtes Schema der Middleware-Architektur
GameState
Das Herzstück der Middleware ist der GameState, der alle Spieler (Player) und
Spielobjekte (GameObject) hält. Ferner können Applikationen, die auf der Middleware
aufsetzen, eigene Nachrichtentypen (NetworkMessage) und entsprechende Methoden
(MessageListener), die auf diese Nachrichten im Sinne eines Beobachters (Observer
Pattern) reagieren, beim GameState registrieren. Somit verwaltet der GameState alle
wesentlichen Strukturen, die sowohl für die Netzwerk- als auch für die GamingSchnittstelle von Bedeutung sind.
Im Sinne des Gaming-Interfaces gilt das Klassendiagramm aus Abbildung 5.2, dass
Strukturen zur Haltung der Spielobjekte, also zum Beispiel der Spieler, beim GameState
in den Vordergrund stellt.
Abbildung 5.2: Klassendiagramm aus Sicht des Gaming-Interfaces
67
Hierbei relevante Methoden des GameStates umfassen beispielsweise Funktionen zum
Einfügen und Entfernen von Spielern oder dem Laden und Speichern einzelner
Spielerattribute, die aus einer eventuell angebundenen Datenbank gewonnen werden.
Spielerattribute selbst können das Inventar die Spielcharakters, seine zuletzt bekannte
Position in der Spielwelt und weitere Statusabfragen bedeuten.
Die angesprochene Möglichkeit, Nachrichten, die während eines Spiels gesendet werden
zu registrieren, wird im Abschnitt 5.4.2 genauer erläutert. Die Bedeutung der pro Spieler
verwalteten ConnectionSession wird im Zusammenhang des nächsten Abschnitts
deutlich.
Client und Server
Der GameState wird von zwei möglichen Klassen benutzt: dem Client und dem
Server. Diese beiden Klassen stellen die Anbindung an das Netzwerk dar und regeln
Verbindungsaufbau sowie eine Benachrichtigung des GameStates nach Empfang einer
neuen Nachricht.
Der Server steht für TCP-Verbindungen bereit und eröffnet für jeden Client eine
neue ConnectionSession. Diese stellt die logische Verbindung zwischen einer
Netzwerkverbindung und dem repräsentierten Spieler dar und führt neben den
Verbindungsparametern eines Spielers auch Statistiken zur Anzahl der gesendeten
Nachrichten, die genutzt werden können, um das Verhalten eines Netzwerkteilnehmers zu
kontrollieren. Somit kann im Sinne der angesprochenen Fairness interveniert werden,
wenn Spieler mit einem extremen Nachrichtenaufkommen entdeckt werden.
UDP-Nachrichten werden ebenfalls unterstützt, allerdings ist dazu erst der Aufbau einer
gesichterten TCP-Verbindung Voraussetzung. Dies bedeutet, dass erst nach der
Anmeldung eines Spielers am Spiel („Join“) UDP Nachrichten versendet werden dürfen.
Da zuallererst eine TCP-Verbindung bei Kontaktaufnahme mit dem Server geschehen
muss, ist es möglich jederzeit zuverlässig wichtige Nachrichten über TCP an die
Teilnehmer zu versenden.
In dieser ersten Version der Middleware wird serverseitig zunächst ein sauberer
Multithreading-Ansatz für TCP-Verbindungen implementiert, so dass für jeden neuen
Client,
der
eine
Verbindung
zum
Server
aufbaut
ein
eigener
Thread
(TCPConnectedClient) erzeugt wird. In späteren Versionen sollte man aufgrund des
teilweise sehr zeitaufwändigen Context Switchings bei Threadwechseln, insbesondere bei
mehreren tausend Teilnehmern, von diesem Ansatz wegkommen, um die Skalierbarkeit
für TCP-Nachrichten deutlich zu verbessern (siehe Ausblick).
68
Abbildung 5.3: Klassen des Netzwerk-Interfaces
Wie in Abbildung 5.3 ersichtlich, nutzt der Client für die TCP-Verbindung und den UDP
Port zum Server je einen eigenen Thread (TCPClient und UDPClient), der auf
Nachrichten wartet. Der Server nimmt TCP-Verbindungen über den TCPServer-Thread
an und erzeugt die erwähnten Threads pro neuem Client. Ferner wartet ein einzelner
Thread (UDPServer) auf einem vorgegebenen Port auf ankommende Nachrichten die
per UDP geschickt wurden.
Mit Aufbau der Verbindung und Erstellung eines neuen TCPConnectedThread,
versucht der Server, den Spieler beim GameState anzumelden. Ist es möglich, den
Spieler
anzumelden,
so
wird
ihm
eine
eindeutige
ID
zugewiesen
und
eine
ConnectionSession erzeugt, die nun eine Netzwerkverbindung auf einen Player
abbildet und umgekehrt. Lehnt der GameState den neuen Spieler ab, beispielsweise da
der Server seine maximal zulässige Spieleranzahl erreicht hat, so wird die Verbindung
beendet. Im Falle eines Clients hält die ConnectionSession lediglich die
Verbindungsparameter zum Server und stellt keine Abbildung auf einen Spieler dar.
Der Client besitzt nun Methoden der Netzwerk-Schnittstelle und erlaubt das direkte
Senden von Nachrichten zum Server und kann optional Funktionen anbieten, die bei
Empfang bestimmter Nachrichten von Interesse sind. Beispiele hierfür sind das Setzen
der vom Server erhaltenen Parameter für den eigenen lokalen Spieler nach genehmigter
Spielteilnahme („JoinAnswer“) durch die Methode setLocalPlayer oder nach Erhalt
einer Strafe durch den Server (setPenalty, siehe dazu Abschnitt 5.4.5).
Analog besitzt der Server Methoden zum Versenden von Nachrichten an bestimmte
Clients oder Clientgruppen.
69
StandardClient und StandardServer
Im Gegensatz zu den reinen Netzwerkaufgaben eines Clients und eines Servers,
werden die Klassen, die den vollen Funktionsumfang der Middleware bieten als
StandardClient und als StandardServer bezeichnet.
In der hier umgesetzten Client-/Serverarchitektur verwendet der implementierte Client
(StandardClient) die Klasse Client als Schnittstelle zum Netzwerk, also zum
Nachrichtenaustausch mit dem Server und den GameState zur Haltung und
Berechnung des Spielzustands und zur Benachrichtigung der entsprechenden Routinen
bei Nachrichtenerhalt. Der StandardClient stellt somit die Middleware für die
Spielteilnehmer-Software dar und bietet Standardfunktionen zum Speichern und Laden,
zum Erhalt von Latenzinformation und ähnlichem. Die Applikation kann neben den
Standardfunktionen beliebige Nachrichtentypen definieren.
Analog stellt der StandardServer die Implementierung und Haltung des Servers
und GameStates auf der Seite des Servers dar. Abbildung 5.4 veranschaulicht diese
grundsätzliche Struktur und das Zusammenwirken der bisher besprochenen Einheiten.
StandardClient
+movePlayer()
+pingTCP()
+pingUDP()
+joinGame()
+quitGame()
+onPingMessage()
+onJoinMessage()
+onPenaltyMessage()
network
gaming etc.
Client
GameState
Abbildung 5.4: Middleware auf Seiten des Clients
Der StandardClient abstrahiert hierbei von der Client- und GameState-Instanz,
indem es vereinfachte Methodenaufrufe zur Nutzung der Instanzen implementiert.
Beispiele hierfür sind die Methoden movePlayer oder pingTCP, die den Client dazu
veranlassen eine Bewegungsupdatenachricht des Spielers über UDP oder eine
nachgeahmte (softwareseitige) Ping-Nachricht über TCP zu versenden.
Weiterhin
werden
Listener-Methoden
wie
onJoinMessage implementiert, die
aufgerufen werden, wenn eine entsprechende Nachricht dieses Typs empfangen wurde.
70
Analog ist der Aufbau des StandardServers, in Abbildung 5.5 dargestellt. In einem
Szenario, in dem der StandardClient die Teilnahme am Spiel durch joinGame
forcieren möchte, wird eine entsprechende Join-Nachricht gesendet, die nach Empfang
auf der Seite des Servers durch den Listener onJoinMessage verarbeitet werden kann.
Abbildung 5.5:Middleware auf Seiten des Servers
5.4.2.
Nachrichtensystem
Das entscheidende Merkmal dieser Middleware ist das Nachrichtensystem. Um die
Entwicklung durch den Spielprogrammierer zu vereinfachen, wurde ein generischer
Ansatz gewählt. Im Zentrum dieses Ansatzes steht die Basisklasse NetworkMessage,
die grundlegende Methoden zum Empfang und Versenden von Nachrichten über TCP
und UDP beinhaltet, sowie die dafür benötigten „low level“-Funktionen zum Einlesen und
Schreiben der einzelnen Datentypen, die in den Paketen versendet werden.
Von dieser Basisklasse ausgehend werden alle weiteren Nachrichtentypen erzeugt. Um
dem Spielprogrammierer eine große Arbeit zu ersparen, wurde ein Tool entworfen, das in
XML definierte Nachrichtentypen in Programmcode umwandelt, der die Benutzung dieser
neuen Nachrichten ermöglicht. Diese Umsetzung orientiert sich in Grundzügen an der in
[Hsiao05] vorgestellten Idee.
Der Programmierer definiert sich dazu nach folgendem XML-Schema seine gewünschten
Nachrichten:
Eine neue Nachricht wird durch einen <Message>-Block angegeben, der als Parameter
die zu verwendende, eindeutige ID der Nachricht, dessen Name, Pakettyp (UDP oder
TCP) und Priorität benötigt.
71
Pro <Message>-Block wird ein Block zur Nachrichtenbeschreibung (<MessageDesc>)
und für den Payload der Nachrichten (<Parameters>) angegeben. In einem PayloadBlock werden dann die einzelnen Datenblöcke (<Param>) aufgelistet, wobei ein
einzelner Datenblock durch den Datentyp (<ParamType>) und den Variablennamen
(<ParamName>) definiert wird.
In Abbildung 5.6 wird eine mögliche Struktur einer Nachricht vorgestellt. Es handelt sich
dabei um eine Penalty-Nachricht, die vom Server vergeben wird, wenn ein Client entdeckt
wird, der zu viele Nachrichten sendet. Da es sich um eine wichtige Nachricht handelt, ist
die Nachricht vom Typ tcp und hat die Priorität 0 (Nachricht wird immer gesendet). Der
Payload besteht aus drei Parametern, die alle vom Datentyp int sind.
Abbildung 5.6: Beispiel einer Nachrichtendefinition in XML
Wird das Tool „xml2code“ aufgerufen, so werden pro definierter Nachricht zwei
Codefragmente erstellt:
Eine von der Basisklasse NetworkMessage abgeleitete Klasse, die die
Methoden zum Empfang und Versenden auf den Payload anpasst und
gleichzeitig Schnittstellenfunktionen erstellt, mit deren Hilfe auf den
Payload zugegriffen werden kann
Ein Listener-Interface für diese Nachricht, die eine Methode beinhaltet, die
vom Entwickler zu implementieren ist und aufgerufen wird, falls eine
Nachricht dieses Typs empfangen wird
72
Im Beispiel der Penalty-Nachricht wird demnach folgendes erstellt:
PenaltyMessage, die die Klasse NetworkMessage erweitert und die
Funktionen
-
get_intervallLength()
-
get_numberOfMessagesAllowed()
-
get_duration()
-
get_state()
bereitstellt
PenaltyListener, ein Interface mit der zu implementierenden Methode
onPenaltyMessage(PenaltyMessage msg)
Nach diesem Schema lassen sich alle benötigten Nachrichten erstellen. Anschließend
müssen die verwendeten Nachrichten beim GameState angemeldet werden. Sind die
Nachrichten registriert, ist es möglich pro Nachrichtentyp ein oder mehrerer Listener, die
auf diese Nachricht warten, zu registrieren. Solche Listener müssen dann die
entsprechende Methode (zum Beispiel onPenaltyMessage) implementieren.
Abbildung 5.7: Schematische Darstellung der gesamten Middleware in Bezug auf den
Nachrichtenaustausch
Stellt dann eine Netzwerk-Instanz (über TCP oder UDP, beim Client oder beim Server)
den Empfang einer neuen Nachricht fest, so wird der GameState informiert. Dieser stellt
fest, um welchen Nachrichtentyp es sich handelt und ruft die Methoden zum Empfang der
73
Nachricht innerhalb der von NetworkMessage abgeleiteten Nachrichteninstanzen auf.
Der Payload ist nun über die Schnittstellenfunktionen der abgeleiteten Klasse abrufbar.
Anschließend werden alle Listener, die auf diese Nachricht gewartet haben, aufgerufen.
Diese Vorgehensweise ist in Abbildung 5.7 schematisch dargestellt.
Da die Middleware einen gewissen Pool an Funktionen für Spiel und Spielprogrammierer
bereitstellen soll, wurden bereits einige typische Nachrichten und Methoden zur
Behandlung dieser Nachrichten bereitgestellt:
Penalties: Server → Client
Server kann Verhalten der Clients kontrollieren
Ping TCP/UDP: Server ↔ Client
softwareseitige Messung der Umlaufzeiten von TCP und UDP Nachrichten
Join / Quit: Client → Server
Teilnahme und Verlassen eines Spiels
JoinAnswer: Server → Client
Bestätigung der Teilnahme an einem Spiel
NewPlayer: Server → Client
Benachrichtigung, dass ein neuer Spieler im Spiel ist
SavePlayer: Client → Server
Speichere aktuellen Spielstatus (Inventar, Position, …) des Spielers in Datenbank
(nicht implementiert in dieser Version)
Move: Client ↔ Server
Bewegungsupdates eines Spielers / Benachrichtigung anderer Spieler
Chat: Client ↔ Client
Senden einer Chatnachricht an einen anderen Spieler (über den Server)
Diese Nachrichten werden zum Funktionsumfang der Middleware gezählt. Die
dazugehörigen
Listener
wurden
StandardServer realisiert.
74
in
den
Klassen
StandardClient
und
Abschließend ist auch für das Nachrichtensystem die bisher geführte Darstellung der
einzelnen Middleware-Einheiten in Bezug auf die zentrale Einheit GameState
anwendbar (Abbildung 5.8).
PenaltyMessage
PingMessage
JoinMessage
NetworkMessage
+addListener()
+getNewInstance()
+getID()
+getType()
+setType()
+sendTCP()
+onReceiveTCP()
+sendUDP()
+onReceiveUDP()
+notifyAllListeners()
+read_object()
+write_object()
GameState
«interface»
MessageListener
«interface»
PenaltyListener
«interface»
PingListener
«interface»
JoinListener
Abbildung 5.8: Klassen des Nachrichtensystems
Die Nachrichten selbst werden in einem simplen Paketformat verschickt, welches aus
einem Header und dem Payload besteht. Während bei TCP der Verbindungsteilnehmer
über die ConnectionSession identifiziert wird, ist die Zuordnung bei UDP-Paketen
nicht sofort ersichtlich (die Erkennung über den genutzten Port kann bei vielen tausend
Spielern sehr umständlich werden). Daher unterscheiden sich die Header von TCP- und
UDP-Nachrichten um zusätzliche Informationen. Der Header einer UDP-Nachricht sendet
die ID der Nachricht und die eindeutige ID des Players bevor die Daten folgen. Diese
Player ID ist bei TCP Nachrichten nicht nötig. Stattdessen wird die Länge des Payloads
angegeben. Dies ist darin begründet, dass die TCP Verbindung aus einem Datenstrom
liest,
der
bereits
mehrere
Nachrichten
hintereinanderpuffern
kann.
Durch
die
75
Längenangabe können die Grenzen einzelner Nachrichten aus diesem Strom erkannt
werden.
Um die Fehlertoleranz zu erhöhen, können beim TCP-Datenstrom einzelne Pakete durch
Anfangs- und Endflags gekennzeichnet werden. Sollte die Bearbeitung des Empfangs von
Paketen über eine TCP-Verbindung einmal aus der Synchronisation kommen, so würde
zwar das aktuelle Paket unter Umständen unbrauchbar sein, aber nachfolgende Pakete
könnten anhand der Flags entdeckt werden, und die Synchronisation würde wieder
hergestellt sein.
Abbildung 5.9: Paketformat einer Nachricht über TCP Verbindungen
Beim Empfang wird nun zunächst die Nachricht eingelesen, indem das Startflag aus dem
Datenstrom extrahiert wird und dann alle nachfolgenden Daten bis zum Endflag
eingelesen werden. Ein Abgleich mit der Anzahl der eingelesenen Daten und dem
Längenfeld validiert, ob die eingelesene Nachricht korrekt und vollständig empfangen
wurde.
76
5.4.3.
Alle
Gesamtübersicht
vorgestellten
Klassen
eines
Client
und
eines
Server
haben
folgende
Zusammenhänge.
Abbildung 5.10: Vollständiges Klassendiagramm eines Clients
StandardServer
«interface»
MessageListener
UDPServer
Server
GameState
NetworkMessage
TCPServer
TCPConnectedClient
ConnectionSession
GameObject
GameObjectAttributes
«interface»
Position
Player
PlayerAttributes
Position2D
Abbildung 5.11: Vollständiges Klassendiagramm eines Servers
77
5.4.4.
Area of Interest
Das Verwenden einer „Area of Interest“ ist bei massiven Multiplayer-Spielen von enormer
Wichtigkeit und kann entscheidend zur Skalierbarkeit des Gesamtsystems beitragen.
Hierbei filtert der verwendete Server Nachrichten nach Kriterien wie virtuellen Positionen
der Spieler oder Spielparteizugehörigkeit und verringert somit deutlich die Last der
weitergeleiteten Nachrichten.
Das Prinzip der „Area of Interest“ lässt sich einerseits hardwareseitig durch die
beschriebenen Zonenserver erreichen, andererseits sollte auch jeder einzelne Server
softwareseitig das Aussenden der Nachrichten kontrollieren.
Mögliche Implementierungen einer „Area of Interest“ im Sinne virtueller Spielerpositionen
sind:
Statische Einteilung der Spielwelt (mehrere „Zonen“ pro Server)
Dynamische Anpassung pro Spieler
Teilt man die Spielwelt in bestimmte Zonen ein, innerhalb derer Nachrichten ausgetauscht
werden, während Nachrichten außerhalb nicht in diese Zone gelangen, so ergibt sich der
Vorteil, die Spieler mit entsprechenden „Flags“ auszustatten, die angeben, in welcher
Zone sich der Spieler befindet. Ein großer Nachteil hierbei taucht jedoch an den Grenzen
dieser Zonen auf: Spieler die sich in der direkten Nähe eines anderen Spielers befinden,
aber sich in einer anderen Zone aufhalten, werden vom lokalen Betrachter nicht
registriert. Für solche Grenzen, sind also komplexere Verfahren erforderlich, da bei naiver
Implementierung insbesondere ein Hin- und Herspringen eines Spielers zwischen zwei
Zonen ständig wechselnde Mitspieler bewirken würde. Eine nicht-technische Lösung
bietet hier wieder ein Angleichen durch das Spieldesign. So ist es beispielsweise denkbar,
dass virtuelle Räume, Städte oder Gegenden als Zonen aufgefasst werden, die der
Spieler explizit verlässt, wobei ein Wechsel eine kurze Spielpause bewirkt, während der
neue Schauplatz geladen wird.
Die hier implementierte Middleware nutzt die zweite Variante und verteilt die Nachrichten
dynamisch. Dabei kann die Größe der „Area of Interest“ während der Laufzeit an die
Serverlast angepasst werden. Spieler werden nur über Ereignisse innerhalb ihrer „Area of
Interest“ informiert, indem ein einfacher Positionsvergleich für ausgehende Nachrichten
durchgeführt wird. Nachteilig ist der Aufwand für das dynamische Filtern potentieller
Empfänger. Allerdings ist dieser Aufwand im Vergleich zum ständigen Broadcast an alle
Teilnehmer mehr als gerechtfertigt.
78
5.4.5.
Flooding Algorithmus
Um die Leistung des Servers auf hohem Niveau zu halten und den Server vor einer
gewollten oder zufälligen Überlastung weitestgehend zu schützen, unterstützt die
Middleware einen Mechanismus, der das „Fluten“ des Servers durch ständig sendende
Clients vermeidet.
Der dabei verwendete Algorithmus benutzt serverseitig für jeden verwalteten Client vier
Parameter:
das Flutintervall (floodingIntervall)
die Flutschwelle (floodingThreshold)
das Überschreitungslimit (floodingViolationLimit)
und die Rücksetzschwelle (floodingResetThreshold)
Diese Parameter können manuell eingegeben werden, sollten aber später durch ein
entsprechendes Verfahren dynamisch anhand der aktuellen Serverlast bestimmt werden.
Für jeden Client wird innerhalb des Flutintervalls die Anzahl seiner gesendeten
Nachrichten (sowohl TCP als auch UDP) ermittelt. Dabei ist zu beachten, dass das
implementierte Nachrichtensystem Prioritäten beachtet. Bisher genutzte Prioritätsstufen
sind:
0 – höchste Priorität, d.h. diese Nachrichten werden stets gesendet
1 – zweite Prioritätsstufe, d.h. das Senden dieser Nachrichten kann
eingeschränkt werden
Übersteigt die Anzahl der Pakete der Priorität 1 in einem Flutintervall die Flutschwelle, so
erhält der Client einen Punkt auf seinem Überschreitungskonto. Wiederholt sich dieses
Fluten so oft, dass das Konto das Überschreitungslimit übersteigt, so erhält der Client
vom Server eine Bestrafung in Form einer Penalty-Nachricht, die ihm mitteilt, wieviele
Nachrichten er künftig (für eine angegebene Anzahl von Intervallen) pro Intervall (Länge
des Intervalls definiert in der Penalty-Nachricht) versenden darf. Ist sein Kredit pro
Penalty-Intervall aufgebraucht, werden nur noch Nachrichten versendet, deren Priorität 0
ist. Dies ist nötig, um bestimmte Spielfunktionen, wie beispielsweise das Verlassen des
Spiels, trotz vergebener Penalties ausführen zu können.
Alle anderen Nachrichten werden dann nicht mehr gesendet und der Client muss auf das
nächste Intervall warten. Der Penalty teilt dem Client mit, dass er sich in den nächsten
Zeitintervallen einschränken muss und gibt, wie oben erwähnt, gewisse Schranken vor,
die zunächst einigermaßen großzügig ausgelegt sind.
79
Versucht der Client weiterhin zu fluten und nähert sich daher der vorgegebenen Schranke
ständig an, so wird ein weiterer, strengerer Penalty vergeben.
Insgesamt sieht der Algorithmus vier verschiedene Penalty-Level vor, in der sich jeder
Client zu einem Zeitpunkt befinden kann. Abbildung 5.12 zeigt diese vier möglichen
Penalty-Level mit beispielhaften Übergangsdaten. Zunächst befindet sich jeder Client im
Zustand 0, indem soviel gesendet werden darf, wie man möchte. Die Flutschwelle beträgt
hier zehn Nachrichten bezogen auf die Intervallgröße von einer Sekunde. Wird die
Flutschwelle nun zu oft übertreten (Erreichen des Überschreitungslimits nach zum
Beispiel 30 Verletzungen), so erhält der Client einen Penalty Level 1 vom Server und
kann nun nur noch acht Nachrichten pro Sekunde versenden. Wird auch dieses
Kontingent zu stark genutzt, so erhält der Client Penalty Level 2 und wird auf sechs
Nachrichten eingeschränkt. Da der Client in der kürzeren Vergangenheit aggressives
Flutverhalten gezeigt hat, gelangt er bei weiterem Ausnutzen des immer kleiner
werdenden Kontingents allmählich in den dritten Level, indem nur noch 4 Nachrichten pro
Sekunde erlaubt sind.
Abbildung 5.12: Die vier Zustände des Flooding-Algorithmus
Ist das Fluten nur von kurzer Dauer, so soll der Client nicht sofort bestraft werden oder
aber vergebene Penalties allmählich wieder abgebaut werden. Nähert sich der Client dem
Überschreitungslimit nur sehr langsam, so wird für jedes Intervall, das nicht die
Flutschwelle
übertrat
ein
Zähler
hochgezählt.
Erreicht
dieser
die
genannte
Rücksetzschwelle, bedeutet dies, dass der Client zwar ab und an ein Flutverhalten
gezeigt hat, allerdings zwischendurch genug Pausen gelassen hat. In diesem Fall wird
das Überschreitungskonto auf null zurück gesetzt und gegebenenfalls in ein niedrigeres
Penalty Level zurückgeschaltet. Somit ist sichergestellt, dass Clients die kurzzeitig ein
Flutverhalten gezeigt haben, die Möglichkeit besitzen in den normalen Spielmodus
zurückzukehren.
80
5.5. Implementierung in eine Anwendung
Rückblickend
ein
kurzer
Überblick
über
den
in
dieser
Version
verfügbaren
Funkionsumfang.
Implementierte Funktionen
funktionsfähiges und leicht erweiterbares Nachrichtensystem,
Grundfunktionen wie Ping, Join, Quit, PlayerMove unterstützt
Tool, welches die Erweiterung des Systems oder Spiels um beliebige
Nachrichtentypen (beschrieben durch eine XML Datei) ermöglicht
Verwaltung der Spieler und Spielobjekte (erweiterbar durch Spielentwickler)
Flooding Algorithmus mit Penaltyfunktion zur Regulierung von Clients, die zu
häufig senden
Area Of Interest: Spieler erhalten nur Informationen, die für sie wichtig sind
Das
Gesamtpaket
der
Middleware
für
einen
Client
ist
über
die
welches
Klasse
StandardClient zu erhalten, ein vollständiger Server kann über die Klasse
StandardServer zum Laufen gebracht werden.
Möchte man eine Anwendung wie eine GUI oder gar ein gesamtes Spiel aufsetzen, so
müssen diese beiden Klassen einfach nur von der neuen Anwendung erweitert werden.
81
6. Evaluierung und Test
“Der Glaube an das Zählen und Messen verführt in allen
Künsten zu den gröbsten Fehlern.”
– Paul Renner, deutscher Typograph
Nach der Implementierung der grundlegenden Struktur der Middleware plus der in Kapitel
5 aufgeführten Funktionen, werden verschiedene Tests auf Funktionsfähigkeit und
Performance durchgeführt.
6.1. Testumgebung und Vorgehensweise
Die Tests werden unabhängig von einer mobilen Umgebung in einem LAN durchgeführt,
da nur die Funktionsfähigkeit, Performance und das Verhalten der Middleware von
Interesse ist.
In dem lokalen Netzwerk wurden insgesamt neun Rechner verwendet, die im folgenden
mit den Bezeichnungen Lab1 bis Lab9 gekennzeichnet sind.
Jeder Rechner hat folgende Leistungsmerkmale:
Windows XP Workstation
Pentium 3GHz
1GB Arbeitsspeicher
Dabei wird auf Lab1 die Serverversion der Middleware gestartet, während auf den
Rechnern Lab2 – 9 je zehn Clientversionen laufen. Somit entsteht eine Testumgebung
von einem Server und 80 verbundenen Clients.
Der Server simuliert hierbei eine 2D Spielwelt mit 200x200 Feldern, auf denen sich
Spieler aufhalten können.
Die einzelnen Clients werden periodisch alle fünf Sekunden zwei Pingpakete, die mit dem
Nachrichtensystem erstellt wurden, schicken: eines über TCP und eines über UDP. Diese
„Pings“ entsprechen keinem üblichen Ping, sondern sind softwareseitig implementierte
Nachrichten (siehe Abschnitt 5.4.2), die die aktuelle Auslastung des Servers über TCP
und UDP überprüfen.
Die damit erhaltenen Round Trip Times werden ebenfalls alle fünf Sekunden an den
Server für Statistikzwecke übermittelt.
83
Die Rechner Lab2 – 9 werden in vier Spamming-Stufen eingeteilt, wobei jede Stufe zu
einem gewissen Prozentsatz ein bestimmtes Flutverhalten ausführt und periodisch und
zufällig sein Verhalten ändern kann. Nach jeweils einer Minute wird mit der vorgegebenen
Wahrscheinlichkeit bestimmt, ob das vordefinierte Verhalten beibehalten wird oder ob ein
zufälliges Verhalten in dem Bereich von 1 bis 20 zu sendenden Nachrichten pro Sekunde
ausgeführt wird.
Die Nachrichten, die dabei versendet werden, werden über UDP geschickt und stellen
zufällige Bewegungen des Spielers auf dem Spielfeld dar. Alle eingehenden
Bewegungsnachrichten werden vom Server umgehend an die Spieler weiterverteilt. In
einem normalen Spiel würde natürlich keine sofortige Weiterleitung einer jeden Nachricht
üblich sein. Statusupdates werden vom Server eher periodisch und leicht optimiert
verschickt. Um aber den Sever einem gewissen Stress auszusetzen, der einer Situation
mit
mehreren
hundert
oder
tausend
Clients
gleichkommt,
werden
alle
Bewegungsnachrichten umgehend weitergeleitet.
Die vier angesprochenen Spamming-Gruppen werden wie folgt verteilt:
Gruppe 1: sehr starkes Spamverhalten
Lab2 sendet 12 Nachrichten pro Sekunde und ändert sein Verhalten mit 33%
Wahrscheinlichkeit
nach
einer
Minute
(d.h.
er
sendet
mit
etwa
66%
Wahrscheinlichkeit weiterhin 12 Nachrichten pro Sekunde oder mit 33%
Wahrscheinlichkeit führt er ein zufälliges Spamverhalten für die nächste Minute
aus)
Lab3
sendet
12
Nachrichten
pro
Sekunde
und
wechselt
mit
66%
Wahrscheinlichkeit
Gruppe 2: starkes Spamverhalten
Lab3 und Lab4 senden 9 Nachrichten pro Sekunde und wechseln mit 33% bzw.
66% Wahrscheinlichkeit ihr Verhalten pro Minute
Gruppe 3: normales Spamverhalten
Lab5 und Lab6 senden 6 Nachrichten pro Sekunde und wechseln mit 33% bzw.
66% Wahrscheinlichkeit ihr Verhalten pro Minute
Gruppe 4: schwaches Spamverhalten
Lab8 und Lab9 senden 3 Nachrichten pro Sekunde und wechseln mit 33% bzw.
66% Wahrscheinlichkeit ihr Verhalten pro Minute
84
Auf der Seite der Clients steht eine kleine Benutzeroberfläche (siehe Abbildung 6.1) zur
Verfügung, die ankommende und ausgehende Nachrichten anzeigt und ein paar mögliche
Funktionen wie Chat, Ping, Spielteilnahme und Spielabbruch bietet.
Abbildung 6.1: GUI eines Clients
Serverseitig wird jeder am Spiel teilnehmende Client mitprotokolliert und die aktuelle
Position sowie Round Trip Times über TCP und UDP und der aktuelle Penalty Level des
Flooding Algorithmus angezeigt. Ferner erlaubt die GUI des Servers das Ein- und
Ausschalten der „Area of Interest“-Funktion zur Laufzeit mit verschiedenen Parametern
(Abbildung 6.2).
Abbildung 6.2: GUI des Servers mit 5 verbundenen Clients
85
Zu Beginn des Versuchs wird der Server gestartet. Anschließend werden alle Clients
gestartet, so dass die Verbindung zum Server von allen Clients in einem kleinen
Zeitfenster stattfindet.
6.2. Verhalten des Flooding Algorithmus
Der Flooding Algorithmus soll das Fluten des Servers durch ein oder mehrere Clients
verhindern, indem Penalties vergeben werden, die die Sendefähigkeit dieser Clients
gegebenenfalls einschränken.
In diesem Test werden in einem Abstand von zwei Minuten drei Messungen durchgeführt.
Mehr Messungen sind in diesem Test nicht nötig, da das Verhalten der Clients nach einer
kurzen Anlaufzeit größtenteils reguliert ist. Somit ist ist diese Anlaufzeit zunächst zu
beobachten.
Die im Test verwendeten Parameter des Flooding Algorithmus sind wie folgt:
in Level 0: mehr als 30 mal 10 Nachrichten pro Sekunde führt zu Penalty Level 1
in Level 1: mehr als 30 mal mal 8 Nachrichten pro Sekunde führt zu Penalty Level
2
in Level 2: mehr als 30 mal mal 6 Nachrichten pro Sekunde führt zu Penalty Level
3
in Level 3: erlaube 4 Nachrichten pro Sekunde, bei Ausnutzung verweile in diesem
Level
Um einen Level heruntergesetzt zu werden, müssen mindestens 10 mal Sekunden
registriert worden sein, in denen keine Verletzung des vorgegebenen Limits geschehen
ist.
6.2.1.
Erwarteter Versuchsausgang
Obwohl das Verhalten der Clients zu einem großen Teil zufällig ist, fallen die Clients oft in
das vorgegebene Spamverhalten ihrer Gruppe zurück. Somit sollten sich Clients mit
einem höheren Flutverhalten im Durchschnitt in einem höheren Penalty Level befinden als
Clients mit niedrigerem Flutverhalten.
6.2.2.
Versuchsausgang und Auswertung
Wie erwartet befinden sich die Clients der Gruppe 1 bei jeder Messung im Schnitt im
höchsten Penalty Level und die Gruppe 4 im niedrigsten Level. Für die Gruppe 2 und 3
86
gibt es zunächst eine Abweichung zum erwarteten Ausgang in der Anlaufphase, in der die
Penalty Level für die weniger spammenden Clients in den ersten zwei Messungen über
dem Schnitt der stärker spammenden zweiten Gruppe liegen. Bei der letzen Messung
stellt sich dann das erwartete Gesamtbild ein (Abbildung 6.3).
Durchschnittslevel nach Gruppen
3
2,5
Gruppe 1
Durchschnittslevel
Level
2
Gruppe 2
Durchschnittslevel
1,5
1
Gruppe 3
Durchschnittslevel
0,5
Gruppe 4
Durchschnittslevel
0
0 Minuten 2 Minuten 4 Minuten 6 Minuten
Abbildung 6.3: Durchschnittliches Penalty Level der Spam-Gruppen
Die Abweichung in der Anlaufphase kann darauf zurückgeführt werden, dass das
Verhalten der verwendeten Clients nicht intelligent genug auf die vergebenen Penalties
reagiert. Während Clients der Gruppe 1 häufig spammen und somit, sobald sie die
höchste Penaltystufe erreicht haben, nur schwer wieder aus dieser herauskommen und
Clients der Gruppe 4 durch ihr schwaches Flutverhalten nur selten in einen Penalty
gelangen, ergibt sich bei den Clients der Gruppe 2 und 3 folgendes Problem:
Ein Client benötigt mehr als 10 Nachrichten pro Sekunde, um überhaupt den ersten
Penalty Level zu erreichen. Dies ist für Gruppe 2 und 3 (mit 9 bzw. 6 Nachrichten pro
Sekunde) überhaupt nur möglich, wenn für sie ein zufälliges Verhalten mit mehr als 10
Nachrichten pro Sekunde generiert wurde. Solch ein zufälliges Verhalten kann jedoch
sehr schnell in ein hohes Penaltylevel führen. Fällt der Client in sein vorgegebenes
Verhalten zurück, so ist es auf einmal möglich, dass er trotz geringeren Spamverhaltens,
keinen niedrigeren Level erreichen kann. Beispielsweise kann ein Client der Gruppe 3,
der sich in Level 3 befindet (sende weniger als 4 Nachrichten, dann Level 2) und in sein
altes Verhalten zurückfällt (sende 6 Nachrichten pro Sekunde) nicht den Level 2
erreichen, da er die vorgegebenen 4 Nachrichten pro Sekunde immer verletzt.
Das Zurückfallen in eine niedrigere Stufe hängt hier also in großem Maße vom zufällig
generierten Verhalten ab. Die für die Simulation präparierten Clients sind zu stur.
87
In einer realen Umgebung mit echten Spielern ist die Penaltyvergabe mit steigender
Einschränkung jedoch sinnvoll, da der Spieler in höheren Penaltystufen gezwungen wird,
sein Verhalten zu verändern (weniger Nachrichten schicken), um nach einer gewissen
Zeit in den normalen Spielmodus zurückkehren zu dürfen.
Die Anlaufphase des Algorithmus ist in Abbildung 6.4 veranschaulicht, die den
durchschnittlichen Penalty Level aller Gruppen nach verschiedenen Messpunkten zeigt.
Durchschnittliches Penalty Level
2
1,8
1,6
Level
1,4
1,2
Durchschnittliches
Penalty Level
1
0,8
0,6
0,4
0,2
0
Zeit
Abbildung 6.4: Anlaufphase des Flooding Algorithmus
6.3. Einfluss der „Area of Interest“
Es werden die Round Trip Times über UDP Nachrichten in einer ausgelasteten
Serversituation unter verschieden großen „Area of Interest“ Werten untersucht. Die Round
Trip Times werden dabei über einen Zeitraum von je drei Minuten pro „Area of Interest“
Wert protokolliert. Anschließend wird der Durchschnitt aller Clients betrachtet.
Bei ausgeschalteter „Area of Interest“ sendet der Server in der Simulation jede
eingehende Bewegungsnachricht umgehend an alle anderen Spielteilnehmer. Sendet
jeder Spieler eine Nachricht, so ist der Aufwand für den Server quadratisch.
Der Server hat je nach Anzahl der pro Sekunde gesendeten Nachrichten der 80 Clients
folgende Anzahl ausgehender Nachrichten weiterzuleiten:
88
Nachrichten pro Sekunde pro Client
Zu sendende Nachrichten pro Sek.
5
10
15
20
31.600
63.200
94.800
126.400
Bei einer Spielfeldgröße von 200x200 Felder, werden „Area of Interest“-Größen von 180,
150, 120, 90, 60 und 30 auf Auswirkung untersucht.
Dabei beschreibt eine Größe von x, dass Spieler nur über Nachrichten informiert werden,
die von Spielern kommen, die innerhalb des Quadrats liegen, das rechts, links, oben und
unten durch den Abstand x von der Spielerposition gegeben ist.
Eine Größe von 180 bedeutet somit, dass nur Spieler in den Ecken des Spielfelds
profitieren, da für sie Spieler, die sich in anderen Ecken befinden unsichtbar sind. Somit
ist einer „Area of Interest“-Wert von 180 nur eine sehr geringfügige Verbesserung der
Lastsituation.
6.3.1.
Erwarteter Versuchsausgang
Durch Einschalten der „Area of Interest“ reduziert sich die Anzahl der weitergeleiteten
Nachrichten. Je kleiner die „Area of Interest“, desto besser kann der Server
softwareseitige UDP Ping-Anfragen beantworten. Die durchschnittlichen UDP Round Trip
Times sollten mit reduzierter Größe der Area deutlich geringer werden.
6.3.2.
Versuchsausgang
Die UDP Round Trip Times der Clients nehmen ab einem Area-Wert von 100 deutlich ab.
Dies ist dadurch begründet, dass Werte unter 100 auch für Spieler, die sich in der Nähe
des Spielfeld-Zentrums befinden, immer weniger Nachrichten an diese und von diesen
generieren.
Für einen Wert von 90 wird pro Spieler im besten Fall (Spieler befindet sich in einer Ecke)
ein Spielfeld von 90x90 = 8.100 Größe abgedeckt. Dies entspricht einer „Area of Interest“
von etwa 20%. Im schlechtesten Fall (näher am Zentrum des Spielfelds) hat das relevante
Spielfeld die Größe 180x180 und deckt etwa 80% des gesamten Feldes ab.
Die weiteren „Area of Interest“ Felder haben folgende Größen:
89
AOI Wert
180
150
120
90
60
30
best case
81%
56%
36%
20%
9%
2%
worst case
100%
100%
100%
81%
36%
9%
Tabelle 1: Relativer Anteil einer „Area of Interest“ am Gesamtspielfeld
In Abbildung 6.5 sind die durchschnittlichen Umlaufzeiten über UDP aller 80 Clients des
Versuchs protokolliert. Der Abfall der UDP Verzögerungen sind ab einem Wert um 100
deutlich zu beobachten.
RTT bei verschiedenen AOI
4000
3500
RTT in ms
3000
2500
RTT bei
verschiedenen AOI
2000
1500
1000
500
0
AOI = AOI = AOI = AOI = AOI = AOI =
180 150 120
90
60
30
Abbildung 6.5: Durchschnittliche UDP RTT bei verschiedenen Area of Interest Größen
90
7. Zusammenfassung und
Ausblick
“I never think of the future – it comes soon enough.”
– Albert Einstein
Setzt sich der Trend fort, dass Anwendungen und Spiele aus dem Desktop- und
Konsolenbereich auch Einzug in den mobilen Markt finden, so ist es nur eine Frage der
Zeit, bis die massiven Multiplayerspiele in großer Zahl für Handhelds verfügbar sind.
Die Möglichkeit des „Pervasive Gamings“, immer und überall mit seinem Handy oder PDA
an Spielen teilzunehmen, die sogar die reale und virtuelle Welt vermischen und tausende
von Mitspielern beinhalten, klingt sehr verlockend. Schreckten die Entwickler bisher vor
technischen Limitierungen der kleinen mobilen Geräte zurück, so ist es ebenfalls nur eine
Frage der Zeit, bis sowohl die Hardware der Endgeräte als auch die Netzwerkinfrastruktur
keine limitierenden Faktoren in Bezug auf Spielbarkeit und Spielfreude mehr sind.
Die hier entworfene Middleware stellt somit ein Grundgerüst für künftige MMOGs dar, die
unter anderem durch die Verwendung der Java-Plattform auf allen denkbaren mobilen
Endgeräten, die eine Java Laufzeitumgebung bieten (insbesondere J2ME), eingesetzt
werden
kann.
Mit
der
Implementierung
eines
Systems
zum
Austausch
von
Updatenachrichten zwischen den Spielern und den Servern wurde der Grundstein der
Middleware gelegt, der nun ermöglicht beliebige neue Nachrichten durch den
Spielentwickler hinzuzufügen. Neben den Grundzügen der MMOG-Middleware wurden
ferner Mechanismen wie der „Flooding Algorithmus“ und „Area of Interest“ verwendet, die
die Leistung des Systems vor Überlastung schützen sollen und somit letztendlich den
Weg zur höheren Skalierbarkeit ebnen.
Die folgenden Abschnitte beschreiben mögliche Ansätze für die Weiterentwicklung der
Middleware in nächsten Versionen.
91
7.1. Gaming-Architekturen
Die Middleware ist als klassisches Client/Server-System entwickelt worden. Um einem
Spielentwickler mehr Freiheiten zu gewähren sind Umsetzungen für weitere GamingArchitekturen sinnvoll, wie sie in Abschnitt 2.3.1 erläutert wurden.
Andere Architekturen wie Peer-to-Peer oder Zonenserver-Systeme können dabei aus den
drei Klassen GameState, Client und Server gewonnen werden. Im Falle eines
Zonenservers muss die Serverklasse um zusätzliche Information erweitert werden:
Welche Server (IP Adressen) sind für alle Zonen zuständig?
Wie reagiert ein Zonenserver, wenn ein Spieler seine Zone verlässt? (Übergabe
an den nächsten Server)
Wie reagiert ein Zonenserver, wenn ein Spieler seine Zone betritt?
Der Client geht weiterhin von einem einzigen Server aus. Verlässt der Spieler eine Zone,
so sollte er von seinem aktuellen Server Informationen über den nächsten Server
erhalten. Der Client muss daher einfach den Wechsel von einem Server zum anderen
implementieren.
In einer P2P-Architektur ist eine etwas größere Anpassung notwendig. Da hier jeder Peer
sowohl die Eigenschaften eines Servers als auch eines Clients haben muss, können die
entsprechenden Klassen beide gleichzeitig für einen Peer verwendet werden. Da der
GameState unabhängig von der Implementierung der Netzwerkschnittstelle ist, können
beide Klassen auf den gemeinsamen GameState zugreifen. Die Implementierungen
muss dann beachten, dass alle Statusupdates an alle anderen Peers über die
Netzwerkschnittstelle informiert werden. Hierbei ist die Problematik zu beachten, dass
Programmiersprachen wie Java grundsätzlich Funktionen für eine Client/ServerArchitektur bieten. Eine P2P-Lösung erfordert daher im Gegensatz zu anderen
Client/Server-Varianten eine Erweiterung der Netzwerk-Schnittstelle „nach unten“ zum
Netzwerk. Eine Lösung für Implementierungen einer P2P-Architektur in Java bietet zum
Beispiel [JXTA06].
92
7.2. I/O Multiplexing
Die Middleware unterstützt sowohl TCP als auch UDP als Netzwerkprotokoll. Während
UDP Nachrichten über einen einzigen Thread empfangen und den entsprechenden
Spielern zugeordnet werden, wurde bei der Implementierung für TCP in dieser Version
zunächst die übliche Variante des Multithreadings gewählt. Dabei wird für jeden
verbundenen Client ein eigener Thread erzeugt. Entscheidet sich ein Spielentwickler,
auch häufige Updatenachrichten über das zuverlässige TCP zu versenden, so skaliert das
System nicht gut, da die häufigen Kontextveränderungen beim Threadwechsel bei sehr
vielen Clients schwer ins Gewicht fallen, auch wenn eher kleinere Nachrichten
ausgetauscht werden.
Um die Skalierbarkeit entscheidend zu verbessern, bietet die Java New I/O API
Funktionen,
nicht-blockierende
Sockets
zu
realisieren
[Nacc02].
Dabei
werden
empfangene Netzwerkdaten über eine zentrale Instanz, dem Selector, verwaltet. Werden
Daten empfangen, so erkennt der Selector den entsprechenden Client und informiert die
Anwendung,
so
dass
die
neuen
Daten
eingelesen
werden
können.
Durch
Implementierungen wie [Santos04] sind nach Aussagen des Autors skalierbare
javabasierende Server möglich, die mehrere tausend Verbindungen gleichzeitig
verarbeiten können.
Dieser Ansatz ist insbesondere im Hinblick auf die Diskussion „TCP vs. UDP“ in MMOGKreisen interessant. Ein Vergleich von TCP und UDP für verschiedene Nachrichtentypen
eines Spiels kann durch nicht-blockierende Sockets, die Probleme wie zeitintensive
Kontextwechsel reduzieren, durchgeführt und analysiert werden.
7.3. Umsetzen eines Clients auf J2ME
Clientseitig sollte der nächste Schritt die Konvertierung der Middleware auf eine Java 2
Micro
Edition
fähige
Version
sein.
Zwar
besitzen
Handys
und
PDAs
die
unterschiedlichsten Voraussetzungen, allerdings ist derzeit die Unterstützung von J2ME
als Plattform noch am häufigsten – insbesondere auf Handys – vorzufinden.
Da die Middleware komplett in Java implementiert ist, sollte eine Umstellung auf den
reduzierten Funktionsumfang der Micro Edition mit geringem Aufwand durchzuführen
sein. Dabei sollte unter Umständen beachtet werden, dass oftmals die HandheldHardware, aber auch Netzwerkbetreiber die Netzwerkfähigkeit durch Java einschränken.
Häufig ist das einzig erlaubte Protokoll http, so dass für einige Geräte bestimmte
Anpassungen für das http-Protokoll erforderlich sind. Auf Seite des Servers ist dann ein
Servlet zu realisieren, dass die entsprechenden http-Anfragen verwaltet.
93
7.4. Location based Services
Ortsbezogene Dienste sind noch auf einen kleinen Nutzerkreis beschränkt, aber auch hier
ist der Trend vorstellbar, dass künftige Geräte standardmäßig mit GPS-Chips ausgestattet
werden oder andere Möglichkeiten der Positionsermittlung erhalten.
Es könnten daher Funktionen von der Middleware angeboten werden, die das Auslesen
der aktuellen Position in vorgegebene Strukturen zur Verfügung stellen.
7.5. Weitere mögliche Funktionen
Künftige Erweiterungen der Middleware könnten beinhalten:
94
Verwaltung persistenter Daten durch Anbindung an eine Datenbank (Abfrage
registrierter Spieler, Speichern des Inventars, usw.)
Rollback-Stack: alle Spieleraktionen können nach negativer Bestätigung
rückgängig gemacht werden
Dynamische Anpassung
Serverauslastung
Ausbau des Nachrichtenpools: Erweiterung der zur Verfügung gestellten
Nachrichten (Definition in XML) und entsprechender Schnittstellenfunktionen
des
Flooding-Algorithmus
an
die
aktuelle
Verwendete Hilfsmittel
Für die Erstellung der Diplomarbeit wurden folgende Hilfsmitteln verwendet:
Java 2 SDK, SE v1.4.2 und NetBeans IDE 3.5.1 als Programmierumgebung
Microsoft Word 2002 zur Erstellung dieses Dokuments
Microsoft Office Visio 2003 für Abbildungen
Microsoft Excel 2002 für Diagramme der Simulation und Test
95
Quellennachweis
Literatur und Referenzen
[802.20]
„IEEE 802.20 Mobile Broadband Wireless Access (MBWA)”
http://grouper.ieee.org/groups/802/20/
[Armi01]
„Lag over 150 milliseconds is unacceptable“, G. Armitage, 2001.
http://gja.space4me.com/things/quake3-latency-051701.html
[BuNetz05]
Bundesnetzagentur Jahresbericht 2005.
http://www.bundesnetzagentur.de/media/archive/5278.pdf
[DoMü02]
„Computerspiele: Design und Programmierung“, Peter J. Dobrovka, Daniel
Mühlbacher, Jörg Brauer. Bonn 2002.
[Doom93]
“Doom”, id Software 1993.
[Emmer00]
“Software Engineering and Middleware: A Roadmap”, Wolfgang Emmerich,
Dept. of Computer Science, University College London, 2000.
[EveOnl06]
“Eve Online”, Eve-Online.de Serverstatistiken, CCP 2006.
http://www.eve-online.de/page_serverstatus.php
[EverQu99]
“EverQuest”, Verant Interactive, 1999.
[FAZ05]
„Fünf Jahre UMTS - eine perfekte Illusion“, F.A.Z. 18.08.2005, Nr.191,
Seite 16
[diepresse04] “Computerspiele: Hollywood übertrumpft”, Andreas Weinberger,
12.09.2004.
http://www.diepresse.com/Artikel.aspx?channel=h&ressort=hg&id=442096
[GamDev05] “MMORPG and the ol’ UDP vs. TCP”, GameDev.net Forum Discussion,
November 2005.
http://www.gamedev.net/community/forums/topic.asp?topic_id=319003
[GamSur05]
http://www.video-games-survey.com/online_gamers.htm
97
[Gasp05]
„GASP: an open source gaming service middleware dedicated to
multiplayer games for J2ME based mobile phones“, R. Pellerin, 2005.
http://forge.objectweb.org/docman/view.php/198/122/Cgame05-pellerin.pdf
[GaStar06]
“World of Warcraft: Blizzard erklärt Lag-Probleme”, GameStar, Artikel vom
16.01.2006.
http://www.gamestar.de/news/pc-spiele/adventure/30773/
[Gboy89]
“Nintendo Gameboy”. Tragbare Spielekonsole, Nintendo 1989.
[GiSi87]
“Giana Sisters”, Time Warp Productions 1987.
[heise06]
“CeBIT 2006 Spezial – Mobilfunk”, Rudolf Opitz, Heise.de, 2006.
http://www.heise.de/cebit/highlights/ct/2006/06032/
[Hsiao05]
“Practical Middleware for Massively Multiplayer Online Games”, Tsun-Yu
Hsiao, Shyan-Ming Yuan, National Chiao Tung University. September
2005.
[IEEE02]
“IEEE-SA IEEE Std 802.15.1™-2002 Press Release”, Juni 2002.
http://standards.ieee.org/announcements/802151app.html
[IMT2000]
International Mobile Telecommunications-2000
http://www.itu.int/home/imt.html
[JXTA06]
“JXTA: P2P Sockets”, Brad Neuberg, Alex Lynch.
http://p2psockets.jxta.org/
[LineAge2]
„LineAge II“, NCSoft 2004.
http://www.lineage2.com
[Magon06]
“LBS, the ingredients and alternatives”, A. Magon, R. Shukla. Abruf April
2006.
http://www.gisdevelopment.net/technology/lbs/techlbs006pf.htm
[MiMaze06]
“MiMaze – The Multicast internet Maze”, letzter Abruf 23. September 2006.
http://www-sop.inria.fr/rodeo/MiMaze/
[MMOGChart] http://www.mmogchart.com
[Myers90]
98
„Computer Game Genres“, D. Myers, Play&Culture, 3, 286-301. 1990.
http://www.loyno.edu/~dmyers/research_goals.html
[Nacc02]
“Introducing nonblocking sockets”, Giuseppe Naccarato, 2002.
http://www.onjava.com/pub/a/onjava/2002/09/04/nio.html
[OMA06]
“Open Mobile Alliance”, http://www.openmobilealliance.org
[OMA06b]
„OMA Game Services Client Server Interface V1.0“, 2006.
http://www.openmobilealliance.org/release_program/gs-csi_V1_0.html
[OpScore05] “OPScore, or Online Playability Score: A Metric for Playability of Online
Games with Network Impairments”, Ubicom Inc, March 2005.
[OpWa02]
„Overview of Location Technologies“, Openwave, November 2002.
http://developer.openwave.com/omdtdocs/location_studio_sdk/pdf/Intro_to_
Location_Technologies.pdf
[Palm03]
„The Birth of the Mobile MMOG”, Tommy Palm, Gamasutra.com, 2003.
http://www.gamasutra.com/resource_guide/20030916/palm_pfv.htm
[PeDo03]
“Bandwidth requirement and state consistency in three multiplayer game
architectures“, Joseph D. Pellegrino, University of Delaware, Constantinos
Dovrolis, Georgia Institute of Technology, 2003.
[Pong72]
„Pong“, Atari 1972. “Pong Story”, http://www.pong-story.com
[Quake3]
“Quake III Arena”, id Software 1999.
[Santos04]
“Building highly scalable servers with Java NIO”, Nuno Santos, 2004.
http://www.onjava.com/pub/a/onjava/2004/09/01/nio.html
[Schob03]
“Strukturen und Motivation von Online-Spielgemeinschaften“, Jan Schob,
Carl von Ossietzky Universität Oldenburg, 2003.
http://gamers-survey.aldafea.de/studie/
[Schiller05]
„Mobilkommunikation Kapitel 2: Technische Grundlagen“, Jochen Schiller,
Vorlesung an der Freien Universität Berlin im Sommersemester 2005
[Siegen02]
“Terror-Anschläge in Amerika: Reaktionen der Software-Branche“,
Medienstudiengang, Universität Siegen 2002.
http://www.medien-peb.uni-siegen.de/beta/methik/index.php?author=hp&page=43
99
[Silicon06]
“GPS-Features sind der Renner auf US-Handys”, Silicon.de, März 2006.
http://www.silicon.de/enid/0,4409c4636f6e5f6964092d093138333332093a0
95f7472636964092d093138353237/mobile_und_wireless_34.html
[SpIn78]
“Space Invaders”, Taito Corporation 1978.
[StFi87]
“Street Fighter”, Capcom 1987.
[SuML89]
„Super Mario Land“, Nintendo. 1989.
[Swiss04]
“swisstopo: Location Based Services“, Bundesamt für Landestopographie,
2004.
http://www.swisstopo.ch/pub/down/about/coll/coll_2003_2004/16JAN04Location%20Based%20Services/lbs_2004.pdf
[TagAttack05] „TagAttack“, CST Gruppe, Institut für Informatik, Freie Universität Berlin
2005-2006.
http://www.inf.fu-berlin.de/inst/ag-tech/projects/gaming/TagAttack.htm
[Tan03]
“Computernetwzerke”, 4. überarbeitete Auflage. Andrew. S. Tannenbaum,
Pearson Studium 2003. (Seite 330ff.)
[Tan03b]
“Computernetzwerke”, 4. überarbeitete Auflage. Andrew. S. Tannenbaum,
Pearson Studium 2003. (Seite 345ff.)
[Tan03c]
“Computernetzwerke”, 4. überarbeitete Auflage. Andrew. S. Tannenbaum,
Pearson Studium 2003. (Seite 87ff.)
[Tan03d]
“Computernetzwerke”, 4. überarbeitete Auflage. Andrew. S. Tannenbaum,
Pearson Studium 2003. (Seite 182ff.)
[Telek05]
„T-Mobile Czech Republic startet UMTS TDD“, Deutsche Telekom,
23.06.2005 http://www.telekom3.de/de-p/aktu/3-ne/2005/06-j/050623-tmobile-cz-umts-ar,templateId=_2Fdt_2Fweb_2Fstruct_2FContent.jsp.html
[Usgov00]
“Statement by the president regarding the United States’ decision to stop
degrading GPS accuracy”, The White House, Office of the Press Secretary,
May 2000.
http://www.ngs.noaa.gov/FGCS/info/sans_SA/docs/statement.html
[WarCraft94] “WarCraft”, Blizzard Entertainment 1994.
100
[Wiec02]
„Fallstudien zur organisatorischen Gestaltung der Softwareentwicklung bei
deutschen Computerspielherstellern“, Henning Wiechers, Diplomarbeit im
Studiengang Wirtschaftsinformatik. Universität Köln, Wirtschafts- und
Sozialwissenschaftliche Fakultät 2002.
[Wiki06]
“Wikipedia – Die freie Enzyklopädie”, letzter Abruf 11. September 2006,
http://de.wikipedia.org/wiki/Shard
[Wiki06a]
“Wikipedia – Die freie Enzyklopädie”, letzter Abruf 21. Mai 2006,
http://de.wikipedia.org/wiki/Pong
[Wiki06b]
“Wikipedia – The Free Encyclopedia”, letzter Abruf 24. Juli 2006,
http://en.wikipedia.org/wiki/World_of_warcraft
[Wiki06c]
“Wikipedia – Die freie Enzyklopädie”, letzter Abruf 24. Juli 2006,
http://de.wikipedia.org/wiki/Bluetooth_SIG
[Wiki06d]
“Wikipedia – Die freie Enzyklopädie”, letzter Abruf 24. Juli 2006,
http://de.wikipedia.org/wiki/General_Packet_Radio_Service
[Wiki06e]
“Wikipedia – Die freie Enzyklopädie”, letzter Abruf 24. Juli 2006,
http://de.wikipedia.org/wiki/Global_System_for_Mobile_Communications
[Wiki06f]
“Wikipedia – Die freie Enzyklopädie”, letzter Abruf 24. Juli 2006,
http://de.wikipedia.org/wiki/Global_Navigation_Satellite_System
[WiMAX06]
„WiMax Forum“, http://www.wimaxforum.org
[WoW04]
“World of WarCraft”, Blizzard Entertainment, 2004.
[WRealms06] http://www.warcraftrealms.com
Abbildungen
2.1 Super Mario Land
Nintendo Database http://www.gamespy.com
2.2 Streetfighter
http://www.capcom.com
2.3 Doom
http://www.idsoftware.com
101
2.4 WarCraft III: Reigns of Chaos
http://www.blizzard.com
2.5 The Secret Of Monkey Island
http://www.adventureclassicgaming.com
2.6 Diablo II
http://www.blizzard.com
2.7 Microsoft Flight Simulator 2004
http://www.microsoft.com/games/flightsimulator/screenshots.asp
2.8 FIFA 2005
http://www.easports.com/games/fifa2005/home.jsp
2.9 Pong 4 Spieler Version
http://www.pong-story.com/arcade.htm
2.10 Super Mario Kart (SNES)
http://www.videogamecritic.net/snesss.htm
2.15 Durchschnittliche Frags pro Minute bei verschiedenen Ping-Zeiten zwei
unterschiedlicher Quake 3 Server
http://gamer.ubicom.com/benchmarks/benchmarks.html
2.16 Serverstatus der WarCraft Realms
http://www.warcraftrealms.com
4.1 TibiaME
http://www.tibiame.com
4.2 Undercover 2: Merc Wars
http://www.undercover2.com
4.3 Server Domainmodell der OMA GS Client-Server Interface Spezifikation
http://www.openmobilealliance.org/release_program/docs/GS-CSI/V1_0-20060307C/OMA-TS-Game-Services-Client-Server-Interface-V1_0-20060307-C.pdf
4.4 GASP Design
http://forge.objectweb.org/docman/view.php/198/123/GASP-CGAME05.pdf
102