Mehrbenutzer-Echtzeitspiele erfreuen sich immer größerer Beliebtheit. Ein Grund dafür ist die in letzter Zeit steigende Anzahl an möglichen Mitspielern bzw. das daraus resultierende Spielerlebnis. Die Proxy-Architektur wurde unter diesem Gesichtspunkt entworfen und soll die heutigen Probleme, wie Skalierbarkeit, Serverengpässe und Fairnessunterstützung, etablierter Netzwerkarchitekturen lösen. Aus diesem Grund sind in der Proxy-Netzwerkarchitektur die an einer Partie teilnehmenden Clients jeweils mit einem von mehreren Proxyservern verbunden, welche zusammen einen virtuellen Server darstellen. Der Spielzustand liegt dabei als lokale Kopie auf den Proxies vor und wird über Benachrichtigungen zwischen ihnen synchronisiert. Diese Arbeit beschäftigt sich mit der Portierung einer Modifikation(QFusion)des quelloffenen Mehrbenutzer-Echtzeitspiels Quake II auf die Proxy-Architektur. Mit Hilfe dieses Engineports sollen die Erwartungen an die Skalierbarkeit der Proxy-Architektur evaluiert werden. In der Arbeit werden zunächst einige Grundlagen des originalen Enginecodes, wie das eingesetzte Netzwerkprotokoll, die Mainloops der Client- und Serverapplikation und die zu replizierenden Spielzustandselemente, erläutert. Im Anschluss wird ein Überblick über die verwendete Proxy-Architektur vermittelt. Darauf folgt eine Beschreibung der Implementierung des Framework-API’s der Proxy-Architektur. Anschließend werden die notwendigen Schritte zur Synchronisation des Spielzustandes veranschaulicht und für jede Aktionsart wird die Implementierung des Synchronisationskonzeptes(Eventual Consistency)vorgestellt. Die Evaluierung der Portierung umfasst drei Testläufe. Einerseits ein direkter Vergleich der Client/Server-Version mit der portierten Version der Engine. Dabei stellte sich heraus, dass die Proxy-Architektur unter Verwendung von zwei Proxyservern bis zu 40% mehr teilnehmende Clients erlaubt. Andererseits ein Internet- und ein Skalierungstest, aus deren Messergebnissen eine Unterstützung von fast 50 Spielern auf 4 Proxyservern ermittelt wurde.
Inhaltsverzeichnis
- EINLEITUNG
- DIE WAHL DER ENGINE
- DIE QFUSION-ENGINE
- VERWANDTE ARBEITEN
- DIE QFUSION-ENGINE UND DIE PROXY-ARCHITEKTUR
- DIE QFUSION-ENGINE
- Netzwerkarchitektur
- Netzwerkprotokoll
- Nachrichtentypen
- Deltakomprimierung
- Checksummen
- Server-Mainloop
- Client-Mainloop
- Ausschnitt des Server-Datenmodells
- DIE PROXY-ARCHITEKTUR
- Aufbau der Netzwerkarchitektur
- Möglichkeiten der Kommunikation
- Abstraktion der Adressierung
- Synchronisation des Spielzustandes
- Fairnessunterstützung
- IMPLEMENTIERUNG DES FRAMEWORK-API
- ÜBERBLICK UND NOTATION
- DAS NETZWERKPROTOKOLL
- Client-Proxy-Kommunikation
- Inter-Proxy-Kommunikation
- Netzwerkprotokoll-Header
- DIE SERVERKLASSE QPA_SERVER
- SCHEDULING DER EINGEHENDEN PAKETE
- DIE KLASSE EINGEHENDER PAKETE QPA_MESSAGE
- DIE CLIENTKLASSE QPA_CLIENT
- CLIENT/SERVER-DATENFLUSS
- INTER-PROXY-DATENFLUSS
- REMOTECLIENT-KONZEPT
- ZUSAMMENFASSUNG
- SYNCHRONISATION DES SPIELZUSTANDES
- MANAGEN DES REPLIZIERTEN ZUSTANDES
- MOVEMENT-SYNCHRONISATION
- Ableitung des Zustandsupdates für einen Remoteclient
- Das Remoteclientupdate
- Zusammenfassung
- SYNCHRONISATION DER INTERAKTIONEN
- Synchronisation geführter Waffen
- Interaktionen zwischen Spielern
- Interaktionen mit Remoteclients
- Interaktionen von Remoteclients
- Interaktionen mit der Umgebung
- Userinfo-Synchronisation
- Zusammenfassung
- SYNCHRONISATIONSINTERVALLE
- PROBLEM UNGÜLTIGER SPIELERZUSTÄNDE
- ACTION REORDERING
- SYNCHRONISATIONEN DURCH DEN MASTERSERVER
- Synchronisierung der Hostuhren
- Slaveproxyserverzeit
- Clientzeit
- Synchronisierung der Spawnpoints
- Spielsitzungsverwaltung
- PROXYSERVER-MAINLOOP
- MANIPULATION DER TICKRATE
- INSTALLATION UND BENUTZUNG
- Initialisierung der Server
- INSTALLIEREN DER 3D-ENGINE
- STARTEN DES SPIELS
- Starten mit Hilfe der Batchdateien
- DIE ENGINE-KONSOLE
- Konsolenvariablen - CVAR's
- Konsolenbefehle
- KONFIGURATION DER PROXY-ARCHITEKTUR
- Server-Konfiguration
- Client-Konfiguration
- Ändern der Voreinstellungen
- KOMPILIEREN DER ENGINE
- Compiler-Einstellungen
- Aktuelle GPA-Versionen linken
- DIE BENUTZUNG UND EINSTELLUNG DES SPIELES
- Einstellungen des Spielermodells
- Deathmatch Scoreboard
- EVALUATION DER PORTIERUNG
- ANALYTISCHE SKALIERBARKEITSMODELLE
- Client/Server-Skalierungsmodell
- Proxyserver-Skalierungsmodell
- VERGLEICH DER CLIENT/SERVER- UND PROXY-VERSION
- Testbedingungen und Methodik
- Erfassen von Messwerten
- Auswertung des Versuches
- Berechnungszeiten für einen Tick
- Bandbreitenanforderungen pro Tick
- Zusammenfassung
- EVALUATION ÜBER DAS INTERNET
- Testauswertung anhand der benötigten Rechenzyklen
- Testauswertung anhand der benötigten Bandbreiten
- Portierung der Quake II-Engine auf die Proxy-Architektur
- Evaluation der Skalierbarkeit der Proxy-Architektur
- Synchronisation des Spielzustands durch Eventual Consistency
- Optimierung der Netzwerkkommunikation
- Analyse der Performance und Ressourcenverbrauch
Zielsetzung und Themenschwerpunkte
Diese Arbeit befasst sich mit der Portierung einer Modifikation (QFusion) des quelloffenen Mehrbenutzer-Echtzeitspiels Quake II auf die Proxy-Architektur. Ziel ist es, die Erwartungen an die Skalierbarkeit der Proxy-Architektur zu evaluieren.
Zusammenfassung der Kapitel
Die Arbeit beginnt mit einer Einführung in die Wahl der Engine und die QFusion-Engine. Sie beschreibt die Architektur der QFusion-Engine, das Netzwerkprotokoll und den Server- und Client-Mainloop. Anschließend wird ein Überblick über die Proxy-Architektur gegeben, einschließlich des Aufbaus der Netzwerkarchitektur, der Kommunikationsmöglichkeiten und der Synchronisation des Spielzustands.
Kapitel 3 beschreibt die Implementierung des Framework-APIs der Proxy-Architektur, einschließlich des Netzwerkprotokolls, der Serverklasse QPA_Server, des Schedulings der eingehenden Pakete und der Clientklasse QPA_Client.
Kapitel 4 behandelt die Synchronisation des Spielzustands, insbesondere das Management des replizierten Zustands, die Movement-Synchronisation, die Synchronisation der Interaktionen, die Synchronisationsintervalle, das Problem ungültiger Spielerzustände und die Synchronisationen durch den Masterserver.
Kapitel 5 befasst sich mit der Installation und Benutzung der portierten Engine, einschließlich der Installation der 3D-Engine, dem Starten des Spiels, der Engine-Konsole und der Konfiguration der Proxy-Architektur.
Kapitel 6 evaluiert die Portierung durch den Vergleich der Client/Server- und Proxy-Version, die Evaluation über das Internet und die Analyse der Performance und Skalierbarkeit.
Schlüsselwörter
Proxy-Architektur, Mehrbenutzer-Echtzeitspiele, Skalierbarkeit, Synchronisation, Eventual Consistency, Netzwerkprotokoll, Quake II, QFusion-Engine, Performance, Evaluation, Testläufe
- Arbeit zitieren
- Tobias Schröter (Autor:in), 2005, Portierung eines Multi-Player-Games auf eine Proxy-Plattform sowie anschließende Evaluation, München, GRIN Verlag, https://www.hausarbeiten.de/document/46456
