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
1 EINLEITUNG
1.1 DIE WAHL DER ENGINE
1.2 DIE QFUSION-ENGINE
1.3 VERWANDTE ARBEITEN
2 DIE QFUSION-ENGINE UND DIE PROXY-ARCHITEKTUR
2.1 DIE QFUSION-ENGINE
2.1.1 Netzwerkarchitektur
2.1.2 Netzwerkprotokoll
2.1.2.1 Nachrichtentypen
2.1.2.2 Deltakomprimierung
2.1.2.3 Checksummen
2.1.3 Server-Mainloop
2.1.4 Client-Mainloop
2.1.5 Ausschnitt des Server-Datenmodells
2.2 DIE PROXY-ARCHITEKTUR
2.2.1 Aufbau der Netzwerkarchitektur
2.2.2 Möglichkeiten der Kommunikation
2.2.3 Abstraktion der Adressierung
2.2.4 Synchronisation des Spielzustandes
2.2.5 Fairnessunterstützung
3 IMPLEMENTIERUNG DES FRAMEWORK-API
3.1 ÜBERBLICK UND NOTATION
3.2 DAS NETZWERKPROTOKOLL
3.2.1 Client-Proxy-Kommunikation
3.2.2 Inter-Proxy-Kommunikation
3.2.3 Netzwerkprotokoll-Header
3.3 DIE SERVERKLASSE QPA_SERVER
3.4 SCHEDULING DER EINGEHENDEN PAKETE
3.5 DIE KLASSE EINGEHENDER PAKETE QPA_MESSAGE
3.6 DIE CLIENTKLASSE QPA_CLIENT
3.7 CLIENT/SERVER-DATENFLUSS
3.8 INTER-PROXY-DATENFLUSS
3.9 REMOTECLIENT-KONZEPT
3.10 ZUSAMMENFASSUNG
4 SYNCHRONISATION DES SPIELZUSTANDES
4.1 MANAGEN DES REPLIZIERTEN ZUSTANDES
4.2 MOVEMENT-SYNCHRONISATION
4.2.1 Ableitung des Zustandsupdates für einen Remoteclient
4.2.2 Das Remoteclientupdate
4.2.3 Zusammenfassung
4.3 SYNCHRONISATION DER INTERAKTIONEN
4.3.1 Synchronisation geführter Waffen
4.3.2 Interaktionen zwischen Spielern
4.3.2.1 Interaktionen mit Remoteclients
4.3.2.2 Interaktionen von Remoteclients
4.3.3 Interaktionen mit der Umgebung
4.3.4 Userinfo-Synchronisation
4.3.5 Zusammenfassung
4.4 SYNCHRONISATIONSINTERVALLE
4.5 PROBLEM UNGÜLTIGER SPIELERZUSTÄNDE
4.6 ACTION REORDERING
4.7 SYNCHRONISATIONEN DURCH DEN MASTERSERVER
4.7.1 Synchronisierung der Hostuhren
4.7.1.1 Slaveproxyserverzeit
4.7.1.2 Clientzeit
4.7.2 Synchronisierung der Spawnpoints
4.7.3 Spielsitzungsverwaltung
4.8 PROXYSERVER-MAINLOOP
4.9 MANIPULATION DER TICKRATE
5 INSTALLATION UND BENUTZUNG
5.1 INSTALLIEREN DER 3D-ENGINE
5.2 STARTEN DES SPIELS
5.2.1 Initialisierung der Server
5.2.2 Starten mit Hilfe der Batchdateien
5.3 DIE ENGINE-KONSOLE
5.3.1 Konsolenvariablen - CVAR’s
5.3.2 Konsolenbefehle
5.4 KONFIGURATION DER PROXY-ARCHITEKTUR
5.4.1 Server-Konfiguration
5.4.2 Client-Konfiguration
5.4.3 Ändern der Voreinstellungen
5.5 KOMPILIEREN DER ENGINE
5.5.1 Compiler-Einstellungen
5.5.2 Aktuelle GPA-Versionen linken
5.6 DIE BENUTZUNG UND EINSTELLUNG DES SPIELES
5.6.1 Einstellungen des Spielermodells
5.6.2 Deathmatch Scoreboard
6 EVALUATION DER PORTIERUNG
6.1 ANALYTISCHE SKALIERBARKEITSMODELLE
6.1.1 Client/Server-Skalierungsmodell
6.1.2 Proxyserver-Skalierungsmodell
6.2 VERGLEICH DER CLIENT/SERVER- UND PROXY-VERSION
6.2.1 Testbedingungen und Methodik
6.2.2 Erfassen von Messwerten
6.2.3 Auswertung des Versuches
6.2.3.1 Berechnungszeiten für einen Tick
6.2.3.2 Bandbreitenanforderungen pro Tick
6.2.3.3 Zusammenfassung
6.3 EVALUATION ÜBER DAS INTERNET
6.3.1 Testauswertung anhand der benötigten Rechenzyklen
6.3.2 Testauswertung anhand der benötigten Bandbreiten
6.4 SKALIERUNGSTEST
6.5 AUFWAND DER PORTIERUNG
6.6 ZUSAMMENFASSUNG
7 BEWERTUNG UND AUSBLICK
7.1 BEWERTUNG
7.2 AUSBLICK
Zielsetzung & Themen
Die Arbeit befasst sich mit der Portierung der 3D-Engine QFusion auf eine Proxy-basierte Netzwerkarchitektur, um die Skalierbarkeit von Mehrbenutzer-Echtzeitspielen, speziell im Bereich der First-Person-Shooter, signifikant zu erhöhen. Das primäre Forschungsziel besteht darin, durch die Verteilung der Last auf mehrere Proxyserver die bei herkömmlichen Client/Server-Architekturen auftretenden Engpässe wie Server-Überlastung und Bandbreitenbeschränkungen zu überwinden und diese Verbesserungen durch eine fundierte Evaluation zu belegen.
- Entwicklung und Implementierung eines Framework-APIs für die Proxy-Architektur innerhalb der bestehenden QFusion-Engine.
- Etablierung eines Synchronisationskonzepts basierend auf Eventual Consistency zur Verwaltung des verteilten Spielzustands.
- Optimierung der Fairness zwischen Clients durch Mechanismen wie Client Latency Levelling und Action Reordering.
- Evaluation der Skalierbarkeit mittels analytischer Modelle sowie praktischer Testreihen im lokalen Netz und über das Internet.
Auszug aus dem Buch
2.1.1 Netzwerkarchitektur
Die in der Engine eingesetzte Architektur ist die im Allgemeinen in Multiplayer-Spielen verwendete Client/Server-Architektur [6]. In diesem Szenario sendet der Client die Aktionen seines Spielers an den Server (1). Der Server empfängt alle Aktionen der Clients und berechnet den daraus folgenden Spielzustand, siehe Abbildung 2. Darin inbegriffen sind die Legalitätsprüfung der Aktionen, die Berechnung der Auswirkungen der Clientinteraktionen und das Voranschreiten aller vom Server kontrollierten Elemente der Spielumgebung (2). Im nächsten Schritt werden allen Clients die daraus resultierenden neuen Spielerzustände sowie die aktualisierten Zustände der Objekte mitgeteilt (3). Diese zeigen daraufhin eine aktualisierte Sicht auf die Spielwelt an.
Zusammenfassung der Kapitel
1 EINLEITUNG: Darstellung des Trends zu höheren Spielerzahlen in Mehrbenutzer-Echtzeitspielen und Einleitung der Motivation für den Einsatz der Proxy-Architektur.
2 DIE QFUSION-ENGINE UND DIE PROXY-ARCHITEKTUR: Erläuterung der technischen Grundlagen der QFusion-Engine sowie der Architektur der Proxy-Plattform inklusive des Konzepts der Eventual Consistency.
3 IMPLEMENTIERUNG DES FRAMEWORK-API: Beschreibung der technischen Integration der Proxy-API in den Quellcode der Engine, inklusive Datenflüssen und Klassenstrukturen.
4 SYNCHRONISATION DES SPIELZUSTANDES: Detaillierte Analyse der Synchronisationsmechanismen für Bewegungen, Interaktionen und Spielerinformationen in einer verteilten Umgebung.
5 INSTALLATION UND BENUTZUNG: Anleitungen zur Konfiguration, Kompilierung und praktischen Anwendung der portierten Engine für Testumgebungen.
6 EVALUATION DER PORTIERUNG: Vorstellung und Auswertung der Skalierungsmodelle sowie der Testergebnisse aus lokalen Netzwerken und Internet-Szenarien.
7 BEWERTUNG UND AUSBLICK: Zusammenfassende Würdigung der erzielten Ergebnisse und Diskussion potenzieller zukünftiger Erweiterungsmöglichkeiten.
Schlüsselwörter
Proxy-Architektur, QFusion-Engine, Echtzeitspiele, Skalierbarkeit, Spielzustand, Synchronisation, Eventual Consistency, Client/Server, Netzwerkprotokoll, First-Person-Shooter, Latenz, Lastverteilung, Bandbreite, Action Reordering, Fairness.
Häufig gestellte Fragen
Worum geht es in dieser Diplomarbeit grundlegend?
Die Arbeit untersucht die Portierung einer Mehrbenutzer-3D-Engine auf eine spezielle Proxy-Plattform, um die Skalierbarkeit bei der Teilnehmeranzahl von Echtzeit-Computerspielen zu verbessern.
Welche zentralen Themenbereiche werden behandelt?
Die Themen umfassen Netzwerk-Programmierung, Synchronisationsverfahren in verteilten Systemen, die Analyse der bestehenden Engine-Struktur sowie die messtechnische Evaluation der Leistungsfähigkeit.
Was ist das primäre Forschungsziel?
Das Ziel ist es, nachzuweisen, dass durch den Einsatz einer Proxy-Architektur bei gleichbleibender Spielqualität deutlich mehr Spieler gleichzeitig an einer Spielpartie teilnehmen können, als es bei herkömmlichen Servermodellen der Fall ist.
Welche wissenschaftliche Methode kommt zum Einsatz?
Es werden theoretische Skalierbarkeitsmodelle aufgestellt und die implementierte Lösung anschließend durch empirische Messungen der CPU-Berechnungszeiten und des Netzwerk-Bandbreitenverbrauchs unter kontrollierten Bedingungen evaluiert.
Was wird im Hauptteil der Arbeit behandelt?
Der Hauptteil gliedert sich in die technische Integration des Proxy-Frameworks, die Implementierung von Synchronisationslogik für Spielereignisse (wie Bewegungen oder Kampf) und die detaillierte Auswertung der Skalierungstests.
Welche Begriffe charakterisieren die Arbeit am stärksten?
Wichtige Schlüsselbegriffe sind Eventual Consistency, Proxy-Server, Skalierbarkeit, QFusion, Netzwerkprotokoll, Client-Updates und Spielzustandssynchronisation.
Wie unterscheidet sich der Proxy-Ansatz von der normalen Client/Server-Version?
Im Gegensatz zum zentralen Server verteilt die Proxy-Architektur die Last auf mehrere Proxies, was eine effizientere Verarbeitung der Spielzustände ermöglicht und die Kommunikation zu den Clients optimiert.
Was ist die spezifische Schlussfolgerung bezüglich des "Action Reordering"?
Das Verfahren verbessert die Fairness, indem es die Verarbeitungsreihenfolge von Spielereignissen basierend auf Zeitstempeln korrigiert, was besonders in Netzwerken mit schwankenden Latenzen für ein konsistentes Spielgefühl sorgt.
- Quote paper
- Tobias Schröter (Author), 2005, Portierung eines Multi-Player-Games auf eine Proxy-Plattform sowie anschließende Evaluation, Munich, GRIN Verlag, https://www.grin.com/document/46456
