Subsections
1. Einführung
Bei diesem Genre handelt es sich um ein Computerspiel für eine große Anzahl von
Nutzern, die gleichzeitig und in Echtzeit gegen- oder miteinander interagieren.
Die Anbindung und Kommunikation der verschiedenen Spieler basiert auf Internet-Technologien,
traditionell in einer Client-Server-Architektur. Hierbei werden Spielzüge über
einen Server abgewickelt, d.h. der Client erhält Informationen über die persistente
Spielwelt und meldet seine Spielzüge zurück. Seltener basieren solche Systeme
auf Peer-to-Peer Technologien.
Die gängigen MMPGs locken mit persistenten Spielwelten, die sich über Monate, wenn nicht
sogar über Jahre entwickeln, verändern und erweitern. Zumeist verbringt ein Spieler -
verglichen zur Gesamtlaufzeit des Spiels - eine relativ kurze Zeit (Sitzung bzw. Session)
in dieser Welt. Seine Spieldaten bleiben jedoch während der gesamten Lebenszeit
des Spiels verfügbar. Mitunter werden MMPGs mehrere Jahre betrieben.
1.2 Klassische Client-Server Systeme
Der Server in dieser Infrastruktur ist verantwortlich dafür, dass die übermittelten
Spielzüge der Clients regelkonform sind und dass nicht geschummelt wird (Cheating).
Der Informationsfluß ist kontinuierlich und erfordert daher ständig ausreichend
Rechenleistung auf Seiten des Servers sowie genügend Kapazität auf der Anbindung
zum Internet.
Die Anforderung an ausreichend Rechenleistung sind die Ursache dafür, dass die Kosten
zum Betreiben von Client-Server-basierten MMPGs nichtlinear mit der Anzahl der
Teilnehmer ansteigen.
Für den Betreiber entsteht das Problem, dass er für Spitzenzeiten genügend Reserven an
Rechenleistung benötigt. Diese Über-Ausstattung mit Rechenleistung für Spitzenzeiten
nennt man auch ``Overprovisioning''.
Somit sind solche Server-Systeme zwar für diese Spitzenzeiten gewappnet, die
meiste Zeit jedoch werden sie völlig unterbelastet. Bei bekannten MMPGs kommt
es mitunter vor, dass zehntausende Spieler gleichzeitig aktiv sind, zu andern
Zeiten wiederum nur ein paar hundert.
Die hohen Betriebskosten für MMPGs resultieren daraus, dass Rechenleistung nicht linear
mit den dazugehörigen Kosten skaliert. Meistens muß für einen kleinen Zuwachs
an Leistung eine starke Erhöhung der Anschaffungskosten in Kauf genommen werden.
Verdoppelt man die Ausgaben für Hardware, dann erhält man zumeist nicht einmal annähernd
doppelt soviel Leistung.
1.3 Distributed Server Systeme
Wie bei den klassischen Client-Server-Systemen sind weiterhin Server für die
Berechnung der Spielzüge zuständig. Jedoch wird bei dieser Architektur die Welt
in Teile zerlegt, wobei jeder Server nun für einen Teil zuständig ist. Durch
die Aufteilung der Spielwelt wird die Last der Server verteilt und die Anwendung
skaliert dadurch besser, jedoch entstehen wieder neue Probleme.
Durch die Verteilung der Welt auf verschiedene Systeme entsteht ein Konsistenzproblem,
denn Spieler und Objekte müssen zwischen den Teilwelten transferiert und
konstistent gehalten werden.
Der Umstand, dass Rechenleistung teuer ist, führt ihn vielen Gebieten
zur Nutzung von Peer-to-Peer-Systemen. Diese skalieren zumeist mit der Anzahl
der Nutzer, da jede neue ``Peer'' einen Teil seiner Rechenleistung zur Verfügung
stellt bzw. stellen könnte. Bekannte Vertreter dieses Modells sind Tausch-Systeme wie Edonkey,
Kaazaa oder Bitorrent, die Primär Speicherplatz und Netzwerkbandbreite zur Verfügung stellen.
Ein weiterer bekannter Vertreter zur Nutzung von Rechenleistung auf Heim-PCs ist
Seti@Home [26].
Ein Nachteil dieser Technologie ist die erforderliche
Kommunikation untereinander zum Austausch von Daten, die zumeist in der Summe
1.1weitaus umfangreicher
ist als jene bei einem Client-Server-Modell, wo der Datenfluß direkt über
den Server abläuft.
Ein weiterer kritischer Punkt ist die fehlende Kontrolle über die Funktionen,
die auf den Clients ausgeführt werden und die Verteilung der simulierten Spielwelt. Für
kommerzielle Anbieter kommt hinzu, dass die Kontrolle über teilnehmende Spieler erschwert
wird.
Der Vorteil jedoch liegt auf der Hand: Das System benötigt weniger Ressourcen auf
der Seite des Servers. Mit weniger Kosten für Server-Hardware kann somit ein überschaubarer
finanzieller Rahmen geschaffen werden.
Wie bereits erwähnt ist ein wichtiges Kriterium von MMPGs die persistente
Spielwelt und langwierige Entwickeln seines Charakters bzw. Avatars.
Spieler verweilen jedoch nur kurz in dieser Welt. Die Rechenleistung
und Speicherkapazität des Clients ist somit meist nur für die Dauer
einer Sitzung nutzbar, denn mit Beendigung des Spiels endet oft auch die
Teilnahme am Peer-to-Peer-Netzwerk.
Dies stellt somit den Peer-to-Peer-basierten Ansatz eines
verteilten MMPGs vor ein großes Problem: die Daten über die Welt müssen dauerhaft verfügbar
sein, selbst wenn ein Client unbeabsichtigt ausfällt. Das bedeutet, dass jedes Objekt
in der Welt redundant gespeichert werden muß, damit es auch dann weiter existiert, wenn
der derzeitig kontrollierende Client ausfällt. Die effiziente Verwaltung der unterschiedlichen
Objekte stellt somit eine Herausforderung an das System dar.
Bei netzwerkbasierten Computerspielen muß gewährleistet sein, dass man den Berechnungen
der Spielzüge trauen kann. Dies muß somit beim Design solcher Systeme mit berücksichtigt
werden. Optimal wäre es, sicher zu verhindern, dass sich ein Client Vorteile
durch gefälschte Daten verschaffen kann.
Klassische Client-Server basierte Systeme haben diese Art von Problemen nicht, da
Überprüfung der Gültigkeit eines Spielzuges und die Berechnung von neuen Zuständen
auf Seiten des Betreibers erfolgt, nämlich auf den geschützten und unzugänglichen
Servern (von Hacking sei an dieser Stelle abgesehen). Zur Absicherung von
Client-Server basierten Systemen gegen Cheating gibt es bereits etablierte Techniken,
die an dieser Stelle nicht weiter erörtert werden. Weitere Informationen findet
sich in [23] und [5].
In der vorliegenden Arbeit soll eine Möglichkeit erarbeitet werden, mit welcher
der Betrieb eines MMPG auf einem grundsätzlich Peer-to-Peer basierten Netzwerk
umgesetzt werden kann. Die Auslastung von zentralen Servern soll minimiert werden und
das System soll mit der Anzahl der verbundenen Clients (möglichst linear) skalieren.
Ein Teil der Ressourcen der Clients soll für das System zur Verfügung stehen.
Ebenso soll das System auf die Bedürfnisse von professionellen Spielebetreibern eingehen
und einen gewissen Grad an Sicherheit sowie Kontrolle über die Spieler garantieren. Es
soll somit für den kommerziellen Einsatz vorbereitet sein.
Diese Arbeit soll sich nicht mit der Implementierung eines Spieles beschäftigen,
sondern ein Framework schaffen, das sich für eine breite Palette von MMPGs einsetzen
lässt. Spiele mit einem Schwerpunkt auf Echtzeit-Kommunikation und Forderung nach sehr kurzen
Latenzzeiten (zum Beispiel First-Person-Shooter wie ``Counter Strike'' [6])
gehören nicht zur Zielgruppe.
Ziel dieser Arbeit ist es somit, ein lauffähiges Framework für den Betrieb eines MMPG
zu schaffen, das die geforderten Leistungen erbringt. Das Framework soll die Stärken
von P2P ausnutzen und zugleich die bekannten Nachteile aufwiegen.
Die vorliegende Arbeit gliedert sich wie folgt:
- Kapitel 2 beschäftigt sich zunächst mit den Hintergründen und
Grundlagen von MMPGs und führt in die Problemstellung ein.
- Kapitel 3 nennt einige existierende Arbeiten und Frameworks
für den Betrieb von MMGPs. Vor- und Nachteile dieser Systeme werden gegenübergestellt.
- Kapitel 4 beschäftigt sich mit der theoretischen Entwicklung
und Verbesserung einer Architektur, die möglichst viele der geforderten Leistungen erbringt.
- Kapitel 5 beschreibt die Umsetzung der Architektur aus Kapitel 4
in ein Java-basiertes Framework. Hier werden Details zur Implementierung und verwendete Strategien vorgestellt.
- Kapitel 6 stellt einige Beispiele vor, wie man das System
einsetzt und enthält ein Tutorial zur Verwendung des Java-Frameworks. Das Tutorial
erklärt die Verwendung der Klassen anhand eines einfachen Spiels.
- Kapitel 7 befasst sich mit der Frage, wie sich die Performanz
des Systems unter hoher Last bzw. unter einer Flut von Clients verhält. Hier sollte sich
feststellen lassen, wie das System mit der Anzahl verbundener Clients skaliert.
- Kapitel 8 fasst die Details, die in dieser Arbeit geleistet
wurden, noch einmal zusammen und geht auf noch offene Fragen und Verbesserungsmöglichkeiten
ein.
http://www.psitronic.de/ti/mmpg/mmpg-peer_to_peer/
|
|