Examensarbeit

Transcription

Examensarbeit

Inhaltsverzeichnis
Danksagung
3
1 Einleitung
4
1.1
Der wachsende Markt der Casual Games
. . . . . . . . . . . . . . . . . .
4
1.2
Auf der Suche nach einer geeigneten Mehrspieleranbindung . . . . . . . .
5
1.3
Anforderung an ein 3D Lobbysystem
6
. . . . . . . . . . . . . . . . . . . .
2 Derzeitige Lobby und Matchmakingsysteme in Multiplayerspielen
7
2.1
Command and Conquer: Generals . . . . . . . . . . . . . . . . . . . . . .
7
2.2
World of Warcraft . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
2.3
Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
3 Entwurf eines eigenen Konzeptes für eine 3D Lobby
14
3.1
Grundlegende Benutzerführung und Zustände des Lobbysystems . . . . .
14
3.2
Kameraführung und Steuerung
. . . . . . . . . . . . . . . . . . . . . . .
15
3.3
Matchmaking
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
3.3.1
Intuitives Matchmaking
. . . . . . . . . . . . . . . . . . . . . . .
17
3.3.2
Erschaen von Rauminstanzen . . . . . . . . . . . . . . . . . . . .
18
3.4
Umgebung und Physik
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
3.5
Kommunikation zwischen Spielern . . . . . . . . . . . . . . . . . . . . . .
20
3.6
Codedesign
21
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.6.1
Leichte Anpassbarkeit an neue Inhalte
. . . . . . . . . . . . . . .
21
3.6.2
Weitgehende Unabhängigkeit vom Design des Multiplayerspiels . .
21
3.7
Neuerungen
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
3.8
23
4 Implementation des Lobbysystems
24
4.1
Die verwendeteten C++ Bibliotheken . . . . . . . . . . . . . . . . . . . .
24
4.2
Grundelemente und Lobbyzustände . . . . . . . . . . . . . . . . . . . . .
27
1
Inhaltsverzeichnis
4.3
4.4
4.2.1
Grundlegendes Design von Client und Server
. . . . . . . . . . .
27
4.2.2
Client Zustände und deren Aufgaben
. . . . . . . . . . . . . . . .
28
4.2.3
Modizierbarkeit mit Hilfe von Scripten und Datenbanken
. . . .
32
. . . . . . . . .
33
4.3.1
Erzeugung von Entities . . . . . . . . . . . . . . . . . . . . . . . .
34
4.3.2
Eingesetzte Game Entities . . . . . . . . . . . . . . . . . . . . . .
35
4.3.3
Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
Aufbau des Lobby Clients durch Entities und Properties
Das Client/Server System
. . . . . . . . . . . . . . . . . . . . . . . . . .
39
4.4.1
Aufbau des Servers . . . . . . . . . . . . . . . . . . . . . . . . . .
41
4.4.2
Übermitteln von Bewegungs- und Positionsdaten
. . . . . . . . .
42
4.4.3
Übersicht: Verwendete Kommunikationsstreams
. . . . . . . . . .
43
4.5
Wechsel zwischen Lobby und Multiplayerspiel
. . . . . . . . . . . . . . .
47
4.6
49
5 Test und Auswertung der Implementation
51
5.1
Testsysteme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
5.2
Testprogramme und Erweiterungen
52
5.3
. . . . . . . . . . . . . . . . . . . . .
5.2.1
Simulation von Wide Area Network Bedingungen
. . . . . . . . .
52
5.2.2
Erzeugung von Pseudo Clients . . . . . . . . . . . . . . . . . . .
52
Serverauslastungstests
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
5.3.1
Maximale Anzahl von Spielern . . . . . . . . . . . . . . . . . . . .
53
5.3.2
Zusammenhang zwischen Serverreaktionszeit und Botaktivität
. .
55
5.3.3
Gleichzeitiger Login von vielen Clients
. . . . . . . . . . . . . . .
57
5.4
FPS Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
58
5.5
Wahrnehmung von steigender Latenz
59
. . . . . . . . . . . . . . . . . . . .
6 Zusammenfassung und Ausblick
61
6.1
61
6.2
Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
62
7 Glossar
63
8 Screenshots
71
Abbildungsverzeichnis
75
Literaturverzeichnis
77
2
Inhaltsverzeichnis
Danksagung
An dieser Stelle möchte ich mich bei Prof. Dr.-Ing. Detlef Krömker für die Möglichkeit eine Arbeit über dieses Thema zu verfassen, sowie bei Dr. Tobias Breiner für die
Hilfe bei der Themenndung und Betreuung dieser Arbeit.
Desweiteren geht mein besonderer Dank an die Leiter der Zeal und Spielkind Gmbh,
Boris Triebel, Marc Kamradt sowie damals Matthias Schindler, die es mir ermöglichten
die Implementierung dieser Arbeit bei ihnen vorzunehmen. Für die Unterstützung im
Umgang mit spezischen Nebula/Mangalore Funktionen und inspirierende Gespräche
über Spiel und Programmdesign möchte ich mich zudem bei Rafael Van Daele-Hunt bedanken. Für die Hilfe bei 3D Studio Max und dem Nebula 2 Exporter möchte ich mich
bei Christian Kleinsteinberg bedanken.
Mein ganz besonderer Dank geht an meine Eltern Renate und Hans-Joachim Bufe, sowie
meine Freundin Julia Fey, die sich viel Zeit für das Korrekturlesen der Arbeit genommen
haben und mich während des Studiums immer unterstützten.
3
1 Einleitung
In diesem Abschnitt werden wir uns mit der Motivation der Thematik beschäftigen sowie
Grundbegrie klären, damit diese in den weiteren Kapiteln verwendet werden können.
Diese und weitere Begrie können zudem im Glossar, nachgeschlagen werden.
1.1 Der wachsende Markt der Casual Games
Noch immer streben die meisten Konzepte von Computerspielen in Richtung einer komplexeren und realistischeren (meist kampfbetonten) Spielewelt. Diese sogenannten Core
Games haben den klassischen Computerspieler vor Augen, der im Alter bis 30 Jahren
- meist männlich - genug Geduld und Zeit hat, sich in die komplexe Spielewelt einzuarbeiten und einzutauchen.
1
Dem Gegenüber stehen die sogenannten Casual Games,
die auf einfache Konzepte setzen, die sich durch intuitive Bedienung und schnelle Erfolgserlebnisse auszeichnen sollen. Mit den Casual Games wird von der Industrie somit
beabsichtigt eine neue Zielgruppe zu erschlieÿen, die sich von den bisherigen Core Games
nicht angesprochen fühlt. Als erstes Casual Game wird oft das mit Microsoft Windows
3.x ausgelieferte Solitäre bezeichnet.
Auf der Game Convention Developer's Conference 2005 beschreibt Jessica Turns in ihrem Vortrag den typischen Casual Spieler wie folgt:
Ein Casual Gamer ist jemand, der sich selbst nicht als Gamer betrachtet,
und der sich nicht dafür interessiert, Spiele-Titel zu kaufen, die über den
Einzelhandel vertrieben werden wie z. B. Halo oder Warcraft III. Casual
Gamers lesen keine Spiele-Zeitschriften, sie reden selten mit ihren Freunden
über das Spielen und Spielen hat für sie keine vorrangige Bedeutung. Casual
Gamers sind durchschnittlich 45 Jahre alt, weiblich und verheiratet -weisen
also eine fast entgegengesetzte Demographie auf als die klassischen GamerZielgruppen.
2
1 Quelle[17]
2 Quelle[1]
4
1 Einleitung
Abbildung 1.1: Ein klassisches Casual Game:
Solitäre
Derzeit wächst der Markt der Casual Games rasant, die Spielerzahlen verdoppeln sich
alle ein bis zwei Jahre und allein in den USA werden bis 2008 Umsätze um die zwei
Milliarden US-Dollar erwartet.
1.2 Auf der Suche nach einer geeigneten
Mehrspieleranbindung
Ebenso wie die Casual Games ist auch der Markt der Online Spiele in einem rasanten Wachstum, besonders Europa bietet hier noch laut einer Studie von Screen Digest
[2] viel Potential. Da mittlerweile ein Groÿteil der europäischen Haushalte über einen
Internetzugang verfügt, ist dies nicht sehr verwunderlich und ebnet auch den Weg für
Multiplayer Casual Games. Also Casual Games die Online über ein Netzwerk, wie das
Internet gespielt werden können.
Ein zentrales Problem, welches der Entwickler eines solchen Projektes lösen muss, ist
die Frage: Wie lasse ich einen Spieler entscheiden mit wem er ein Spiel starten will?
Dieser Prozess, wie man einen Spieler mit oder gegen ein oder mehrere andere antreten lässt, wird auch als Matchmaking bezeichnet. Viele Core Games präsentieren hier
ihr Matchmaking in einer nüchternen Liste, die alle verfügbaren Spiele verzeichnet und
zumeist viele zusätzliche Informationen wie Ping, Beliebtheit, Art des Spiels etc. besitzt. Dieses Konzept wird jedoch einen Casual Gamer nur wenig ansprechen, da er mit
diesen vielen, zunächst abstrakten Beschreibungen nur wenig anfangen kann und nicht
5
1 Einleitung
die Geduld oder Zeit besitzt sich in diese einzuarbeiten. Zudem schätzen viele Spieler,
die in eine Mehrspielerpartie einsteigen, nicht nur das spannende Spiel mit/gegen einen
anderen Menschen sondern auch zwischenmenschliche Interaktion wie Unterhaltung.
So ist es sinnvoll, dass Kommunikationsmöglichkeiten, wie z.B. ein Austausch von Textnachrichten, nicht erst im Spiel geschaen werden, sondern noch vor dem Matchmaking.
Dies erönet den potentiellen Spielern die Möglichkeit sich gegenseitig kennenzulernen,
so dass man im Vorraus entscheiden kann mit wem man ein Spiel beginnen will und wer
nicht in Frage kommt. Solche Systeme werden auch als Lobby bezeichnet. Es bezeichnet
parallel zu einer Lobby, die im richtigen Leben einen Empfangsraum darstellt, den Raum
der betreten wird, bevor das eigentliche Spiel beginnt und in dem man sich entscheiden
kann mit wem in welchem Spiel gespielt werden soll. Bisher nden Lobby Systeme zur
Gestaltung des Matchmakings eher wenig Verwendung, in einigen Spielen beschränkt
sich die Lobby auf einen Chat. Viele Multiplayer Casual Games versuchen den Spieler
automatisch nach eigenen Kriterien mit einem Mitspieler zu verbinden, um den Prozess
des Matchmakings so einfach wie möglich zu halten und so dem Casual Gamer entgegen
zu kommen.
1.3 Anforderung an ein 3D Lobbysystem
Ziel dieser Arbeit soll es jedoch sein, eine solche Lobby zu entwickeln, die den Benutzer
mit anderen Spielern in einer virtuellen 3D Umgebung interagieren lassen soll und dort
auch die Möglichkeit des Matchmaking bietet. Dabei sollte die Steuerung für den Spieler
so intuitiv wie möglich geschehen, damit Einarbeitungsphasen vermieden werden und
sie so u.a. für Casual Gamer interessant wird. Das Matchmaking sollte dabei auch sehr
intuitiv erscheinen, in dem sich z.B. die Spieler an einen Tisch setzen und so miteinander
spielen können.
Von der Entwickler Seite ist zudem zu beachten, dass das Entwickeln des Spieles nicht
zu sehr durch die Lobby eingeengt wird. Das heiÿt, dass das eigentliche Spiel zunächst
unabhängig von der Lobby entwickelt werden kann und nur über festgelegte Schnittstellen mit dieser kommuniziert, jedoch u.a. in der Wahl des Szenegraphen unabhängig
bleiben soll.
6
2 Derzeitige Lobby und
Matchmakingsysteme in
Multiplayerspielen
Um einen Überblick über derzeitige Lobby und Matchmakingsysteme zu bekommen,
betrachten wir zunächst einige ausgewählte aktuelle Multiplayer Spiele. Im Anschluÿ
stellen wir anhand dieser State of the Art Analyse ein eigenes Konzept für die zu
realisierende Lobby auf.
2.1 Command and Conquer: Generals
CC:Generals ist als ein klassischer Vertreter des Echtzeitstrategie(RTS) Genres mit komplexen Inhalten klar im Bereich der Core Games ansiedeln. Wie bei vielen Vertretern
der RTS, ist die Multiplayer Komponente hier von groÿer Bedeutung. Aus diesem Grund
entwickelte
Electronic Arts: Los Angeles
ein komplexes Lobbysystem um den Spielern
einen komfortablen Einstieg in Multiplayer Spiele zu geben. So werden neben einem
Chat indivduelle Prole und eine persönliche Freundesliste bereitgestellt, die allerdings
eine Anmeldung des Spielers erforderlich macht.
Spielerprol
Jeder Spieler besitzt ein eigenes Prol, das auch für andere Spieler einsehbar ist. Hier
werden neben den Siegen, Niederlagen und den Abbrüchen einer Partie u.a. auch das
angegebene Herkunftsland des Spielers sowie Medaillen für spezielle, erreichte, Einsatzziele aufgelistet. Anhand dieser Daten ist es potenziellen Mitspielern möglich, die Stärke
ihres Gegners oder Mitspielers vor Spielbeginn abzuschätzen und so zu entscheiden ob
eine Partie sinnvoll erscheint.
7
Kommunikator/Freundesliste
Eine weitere sinnvolle Erweiterung des Lobbysystems ist die Buddylist oder auch Freundesliste genannt. Hier kann jeder Spieler andere befreundete Spieler hinzufügen und ihren
derzeitigen Online-Status sehen. Das heiÿt man kann direkt nach Betreten der Lobby
erkennen, ob ein Freund online ist und in welchem Spiel er sich anmeldet oder spielt.
Auch ist es so möglich diesem eine Nachricht über den sog. Kommunikator zu schicken
oder sich in dessen Spiel einzuklinken, sofern dieses noch nicht begonnen hat.
Lobby
Die eigendliche Lobby ist als Chat mit mehreren sog. Chaträumen realisiert, die nach
der nationalen Herkunft oder auch nach dem gewünschten Spieltyp organisiert sind.
Zusätzlich zu dem Chat existiert eine Liste oener Spiele, in die man sich, mit einem
Doppelklick, einklinken kann und so zum Matchmaking geleitet wird. Hier wird u.a. die
Zusammenstellung der Teams etc. durchgeführt. Auch kann hier schon eine Vorauswahl
möglicher Spielpartner durchgeführt werden, da zusätzlich zu der Selektion durch den
Austausch von Textnachrichten auch die Prole einzelner Spieler eingesehen werden
können.
Abbildung 2.1: Die Lobby ist in mehrere Räume unterteilt
8
Matchmaking
Sobald sich der Spieler in der Lobby für ein Spiel entschieden oder ein eigenes erönet hat, gelangt er zu dem Matchmaking Dialog. Dieser zeigt detaillierte Informationen
über das Spiel an und bietet mit einem integrierten Chat die Möglichkeit, sich abzusprechen,Teams zu bilden und seine bevorzugte Spielpartei zu wählen. Nachdem jeder
Spieler auf einen Akzeptiert Button geklickt hat, und so signalisiert, dass er bereit
ist das Spiel zu starten, kann der Host -derjenige der die Partie erönet hat- das Spiel
starten.
Abbildung 2.2: Der Matchmaking Dialog
Der Host hat zudem als einziger die Rechte, alle Spieloptionen einzustellen und Spieler
aus der Partie auszuschlieÿen. Sobald der Host das Spiel verlässt, wird bei allen Mitspielern der Matchmaking Dialog geschlossen und sie nden sich in der Lobby wieder.
Fazit
Die
CC: Generals
Lobby bietet mit umfangreichen Prolen und der Freundesliste viel
Komfort für den einzelnen Spieler. Es ist möglich, Spiele zu starten bei denen beide Parteien vergleichbar stark sind. User, die spezielle Spieleinstellungen bevorzugen, können
dank der verschiedenen Chat Räume schnell ein geeignetes Spiel erönen oder einem
vorhandenen beitreten. Für Neueinsteiger gestaltet sich die Suche nach einem Spiel allerdings schwieriger, zum Einen werden Spieler mit wenigen Spielen in ihrem Prol oft
aus vielen Spielen ausgeschlossen, da nur wenige Leute mit Neulingen spielen möchten. Zum Anderen gibt es einige Spieler, die es besonders erstrebenswert nden gegen
Neueinsteiger zu gewinnen, um so ihr Prol aufzubessern.
9
2.2 World of Warcraft
World of Warcraft, das derzeitig erfolgreichste MMORPG, lässt den Nutzer eine riesige
3D Umgebung mit gleichzeitig Tausenden von Mitspielern entdecken. Obwohl in World
of Warcraft keine Lobby im bisher erwähnten Stil existiert, möchte ich einige Aspekte des Spieles hier näher betrachten. In diesem Spiel wie auch in der zu realisierenden
Lobby, müssen ähnliche Probleme gelöst werden: Wie lasse ich Spieler in einer 3D Umgebung miteinander interagieren/kommunizieren und auf welche Weise wird mit der groÿen
Anzahl von gleichzeitig eingeloggten Nutzern umgegangen?
Visualisierung und Umgebung
Bevor sich der Nutzer auf einem Server in das Spiel einloggt, muss er sich zunächst einen
individuellen Avatar anhand von verschiedenen Eigenschaften und Körpermerkmalen zusammenstellen oder einen bereits vorhandenen auswählen. Nachdem Avatar und Eigenschaften ausgewählt worden sind, kann der Spieler sich mit einem Server verbinden, um
das Spiel zu beginnen.
Steuerung und Kameraführung
Der Nutzer steuert seinen gewählten Avatar mit der Tastatur in der Szene, dabei zeigt
die Kamera diesen aus Sicht der dritten Person. Die Kamera kann hierbei zusätzlich mit
Hilfe von Mausbewegung und Scrollrad in Entfernung und Winkel ausgerichtet werden,
um die Übersicht zu erhöhen.
Kommunikation mit anderen Spielern
Der Austausch von Textnachrichten mit anderen Spielern kann entweder in sogenannten
Channels, öentlich oder über Privatnachrichten erfolgen.
Wird eine Textnachricht über einen Channel gesendet, kann diese von allen Spielern gelesen werden die sich im selben Channel benden, unabhängig wie groÿ die Entfernung
in der Spielwelt zwischen Sender und Empfänger ist. Verschiedene Channels übernehmen
hierbei in der Regel unterschiedliche Aufgaben, so dass z.B. ein Channel für Gruppensuche oder Handeln existiert.
Privatnachrichten hingegen werden nur zwischen zwei Spielern gesendet. Dies wird auch
oft als üstern bezeichnet, da sie von keinem anderen Spieler eingesehen werden können.
Verschickt der Spieler eine öentliche Nachricht, ist sie für alle Spieler im Umkreis sicht-
10
Abbildung 2.3: Screenshot: Charakterauswahl in World of Warcraft
bar und erscheint zusätzlich als Sprechblase über dem eigenen Avatar. Der Spieler hat
zudem die Möglichkeit, die Nachricht zu schreien, d.h. die Nachricht wird rot dargestellt
und der Umkreis in dem diese empfangen wird erhöht sich drastisch.
Matchmaking
Es handelt sich bei World of Warcraft zwar nicht um eine Lobby, die in ein Spiel führen
soll jedoch ndet hier auch eine Art - meiner Meinung nach sehr intiutives - Matchmaking
statt, das ich hier kurz vorstellen möchte.
Die meisten der Aufgaben die der Nutzer in World of Warcraft erlebt, kann er alleine
bestreiten. Jedoch existieren auch schwierigere Teile, sogenannte Instanzen, die nur von
Spielergruppen gelöst werden können - wie zum Beispiel der Angri auf eine gegnerische
Burg. Für jede Gruppe, die diesen festgelegten Bereich - die Instanz - betritt, wird eine
Kopie des Gebietes angelegt, so dass unabhängig mehrere Gruppen dieselbe Aufgabe
erfüllen können ohne sich gegenseitig zu begegnen, da jede Gruppe in ihrer eigenen Kopie
11
Abbildung 2.4: Visualisierung der Kommunikation mit Hilfe von
Sprechblasen
des Gebietes spielt. Diese Gruppen bestehen üblicherweise aus fünf Spielern, jedoch gibt
es auch Aufgaben, die nur für Gruppen mit 40 Mitgliedern vorgesehen sind.
Die Zusammenstellung ist dabei den Spielern überlassen, sie können so Bekannte in ihre
Gruppe einladen oder über Textnachrichten zusätzliche Mitglieder rekrutieren. Diese
treen sich dann vor dem Eingang der Instanz, um diese zu betreten und ihre Aufgabe
- die zumeist im Besiegen eines Endgegners besteht - zu erfüllen.
Der Vorgang des Matchmaking, also das Zusammennden der Spieler und Beginnen
der Instanz fügt sich also direkt in das Spiel ein, ohne als Fremdkörper zu wirken.
Dadurch, dass jede Instanz als eine Kopie für die jeweilige Gruppe angelegt wird, ist
es möglich, dass nahezu beliebig viele Spieler dasselbe Abenteuer erleben können, ohne
sich zu behindern.
Fazit
Obwohl es sich bei diesem Spiel nicht um eine Lobby handelt, sind sehr interessante
Aspekte für die Visualisierung einer interaktiven Multiplayer 3D Anwendung zu sehen. Ebenso wie hier die Kommunikation zwischen vielen Spielern gelöst wurde, ist das
Matchmaking für eine Instanz sehr intuitiv für die Spieler durchführbar.
Jedoch wurden in dieser kurzen Beschreibung von World of Warcraft lediglich die Aspek-
12
te, welche für die zu realisierende Lobby interessant erscheinen aufgegrien.
2.3 Zusammenfassung
In diesem Abschnitt haben wir zwei aktuelle Spiele auf ihre Lobby und Matchmaking
Fähigkeiten untersucht.
Zum Einen die Mehrspieleranbindung des Echtzeitstrategiespieles Command and Conquer als Vertreter für eine klassische Lobby in Core Games. Neben dem Einstieg in das
Spiel bietet das Lobbysystem den Nutzern die Möglichkeit, Textnachrichten auszutauschen, Spielstatistiken von Mitspielern einzusehen und mit diesen über eine Freundesliste
in Kontakt zu bleiben, sowie zu organisieren. Zum Anderen wurde World of Warcraft
untersucht. Obwohl hier keine Lobby existiert, wurden in diesem Spiel einige Probleme
gelöst, die auch für das nun zu realisierende Lobbyprojekt von grundlegender Bedeutung
sind. So wurde hier unter anderem betrachtet, wie viele Spieler gleichzeitig in einer virtuellen, dreidimensionalen Umgebung miteinander kommunizieren und auf welche Weise
diese sich zu Gruppen für gröÿere Aufgaben organisieren können. Ausgehend von den
gewonnenen Erkenntnissen wollen wir im nächsten Kapitel versuchen ein eigenständiges
Konzept für unser Lobbysystem zu entwerfen.
13
3 Entwurf eines eigenen Konzeptes
für eine 3D Lobby
Im vorhergehenden Kapitel haben wir in einer State of the Art Analyse verschiedene
aktuelle Lobbysysteme untersucht. Von diesen Kenntnissen ausgehend werden wir nun
ein eigenes Konzept aufstellen und dieses dann im nächsten Kapitel umsetzen.
3.1 Grundlegende Benutzerführung und Zustände des
Lobbysystems
Zunächst muss eine Struktur geschaen werden, die der Lobby zugrunde liegt. Der Einstieg in die Lobby geschieht, wie wir in den Beispielen gesehen haben, mit einem Login
Dialog, in dem der Nutzer seinen Avatar wählen kann und sich mit seinen Daten wie
z.B. seinem gewünschten Benutzer und ggf. seinem Passwort einloggt. Dies ist zum Einen
sinnvoll, um dem Benutzer einen gewohnten Einstieg in die Lobby zu geben und zum
Anderen kann dieser auf diese Weise schnell die von ihm gewählten Einstellungen einsehen und ändern.
Nach der Eingabe der Daten verbindet sich der Spieler mit dem Lobby Server und gelangt
in den eigentlichen Lobby Bereich. Falls bei der Verbindung mit dem Server Probleme
auftreten oder die gewählten Daten ungültig sind, wird der Benutzer mit einer entsprechenden Fehlermeldung wieder zum Login Dialog zurück geleitet.
Im Lobby Bereich ndet die Kommunikation unter den Spielern und das Matchmaking
statt. Wenn ausreichend Mitspieler für eine Partie gefunden worden sind, kann das Spiel
starten und die Teilnehmer werden aus der Lobby entfernt. Nachdem das Spiel beendet
wurde, kehren sämtliche Spieler wieder in die Lobby zurück. Falls in der Lobby oder
im Spiel ein kritischer Fehler (wie z.B. ein Verbindungsabbruch zum Server) auftritt,
wird der Spieler wieder zum Login Dialog zurückgeleitet. Dies kann ebenso manuell vom
Benutzer über das Drücken eines Logout Buttons erreicht werden.
14
Abbildung 3.1: Grundzustände des Lobbysystems
3.2 Kameraführung und Steuerung
In dem einleitenden Kapitel haben wir als Motivation für ein 3D Lobbysystem, eine
Multiplayer Anbindung gesehen, die nicht nur für Core, sondern auch für Casual Gamer
geeignet sein soll. Die Grundzustände des Lobbysystems aus dem vorherigen Abschnitt
orientieren sich bisher an klassischen Modellen, wie wir diese in der Analyse der Beispiele
in Kapitel 2 gesehen haben. Wenn ein Unterschied zu diesen für den Benutzer geschaen
werden soll, muss dies in der eigentlichen Lobby sowie im Matchmaking geschehen. Wie
der Titel dieser Arbeit beschreibt, sollen die Benutzer als 3D Avatare die Lobby betreten
und so interagieren können.
Bevor wir uns mit den genauen Details der Steuerung und der Interaktion der Spieler
beschäftigen, muss geklärt werden aus welcher Position die virtuelle Kamera die Szene
erfasst und wie diese auf den Spieler reagiert. Hierbei möchte ich mich auf die drei
geläugsten Kamera-Modelle für benutzergesteuerte Kameras beschränken.
•
First Person
Bei der
rst person
Ansicht wird die Szene aus der Sicht des Avatars gezeigt. Der
Avatar wird also (bis auf ggf. die Extremitäten) nicht direkt vom Spieler gesehen,
welches eine bessere Identikation mit dem gespielten Charakter ermöglichen soll.
•
Third Person
Die
third person Kamera zeigt die Szene aus der dritten Person, meist leicht schräg
von oben, der Sichtwinkel kann dabei oft vom Nutzer gesteuert werden. Ein Vorteil dieser Ansicht ist eine gröÿere Übersicht über die Szene, da der Spieler auch
Bereiche einsehen kann, die unmittelbar neben und hinter seinem Avatar liegen.
15
•
Frei schwebende Kamera
Im Gegensatz zu den beiden ersten Kamerapositionen ist diese Position der Kamera
nicht an einen speziellen Avatar gebunden, sondern bewegt sich vom Benutzer
gesteuert frei im Raum. Diese Perspektive wird oft gewählt, wenn der Benutzer
keinen Avatar verkörpert, wie z.B. in 3D Grakprogrammen.
Da der eigene Avatar in einer Lobby von zentraler Bedeutung ist, eignet sich eine frei
schwebende Kamera hier wenig. Das Interesse des Spielers liegt zumeist bei seinem eigenen Avatar, daher ist es am sinnvollsten eine Kameraführung zu wählen, die die Kamera
an diesen xiert und somit diesem Zentrum des Interesses folgt. Es muss also entschieden
werden, ob die Kamera die Szene aus der
third- oder der rst person
Perspektive zeigt.
Da die geeignete Kameraposition auch von der gewählten Art der Benutzersteuerung
abhängt, möchte ich zunächst auf diese eingehen.
Ich beschränke mich hier auf die Steuerung mit Standardeingabegeräten und vernachlässige somit z.B. Kontrollmöglichkeiten mit Hilfe eines Gamepads, da diese an den
wenigsten Computern zu nden sind.
•
Steuerung mit der Tastatur
Der Nutzer steuert seinen Avatar mit Hilfe der Pfeiltasten (oder einer alternativen
Tastaturbelegung) durch die Szene. Üblicherweise bewegt sich hier der Spieler mit
den Pfeiltasten oben/unten vor, zurück und mit links/rechts wird eine Drehung
in die entsprechende Richtung vorgenommen. Diese Art der Kontrolle war bereits
in frühen 3D Spielen wie z.B. Doom, welches im Dezember 1993 erschienen ist,
vertreten.
•
Steuerung mit der Maus
Bei der Steuerung mit Hilfe der Maus wird der Avatar kontrolliert, indem der
Nutzer mit dem Mauscursor auf eine Position in der Szene klickt, zu der sich der
Avatar bewegen oder mit der er interagieren soll. Eine hier bestehende Schwierigkeit ist, dass der zu wählende Weg vom Computer berechnet werden muss, damit
z.B. Hindernisse umgangen werden.
•
Steuerung mit der Tastatur und Maus
Diese Art der Steuerung hat gröÿtenteils die ausschlieÿliche Kontrolle des Spielers
mit der Tastatur abgelöst. Der Nutzer steuert zwar weiterhin die Bewegung seiner
Figur mit den Pfeil oder auch häug den WASD Tasten, jedoch wird der Charakter mit Hilfe der Maus ausgerichtet, d.h. das Drehen der Figur mit der Tastatur
16
ist nun überüssig und die rechts/links Tasten bewirken einen Seitschritt in die
entsprechende Richtung.
Die Maus und Tastatur Steuerung ist von allen drei Kontrollmöglichkeiten die am
schwersten zu erlernende, da das gleichzeitige Ausrichten mit der Maus und Bewegen mit
der Tastatur erst nach ein wenig Übung problemlos funktioniert. In modernen Spielen
ist sie dennoch oft die erste Wahl, da sie eine sehr präzise und schnelle Bewegung in der
Szene ermöglicht.
In dieser Arbeit sollen jedoch auch Nutzer angesprochen werden, die diese Steuerung
noch nicht kennengelernt haben oder denen es an Motivation fehlt sich in diese einzuarbeiten. Aus diesem Grund will ich von der Verwendung dieser Eingabemöglichkeit als
Standard absehen. Die Maussteuerung bietet gegenüber der Tastatureingabe eine einfachere Interaktion mit der Umgebung, z.B. können andere Spieler, denen eine private
Nachricht geschickt werden soll, einfach angeklickt werden. Ein weiterer Vorteil dieser
Variante stellt die automatische Navigation zum Zielpunkt dar, die einsetzt nachdem
der Nutzer an die gewünschte Stelle geklickt hat. Der Spieler kann sich so mehr auf die
Interaktion mit anderen Personen und das Matchmaking konzentrieren, als darauf zu
achten, dass er nicht gegen Hindernisse in der Szene läuft.
Mit der Wahl der Maussteuerung bietet sich auch die
third person
Ansicht an, da sie
Dank der Sicht von leicht oben ein Klicken auf die gewünschte Bewegungszielposition
erleichtert und die erforderliche Übersicht bietet.
3.3 Matchmaking
Das Matchmaking ist die zentrale Aufgabe jeder Lobby. Da wir in diesem Projekt eine
3D Lobby schaen wollen, können wir die Möglichkeiten dieser Umgebung nutzen, um
dies auch für unerfahrene Nutzer intutiv zugänglich zu machen.
3.3.1 Intuitives Matchmaking
Wenn sich Spieler im realen Leben auf einem Brettspieleabend oder in einem Kasino
eine Partie suchen oder anders gesagt das Matchmaking durchführen, setzen sie sich
zumeist nach einer kurzen Unterhaltung an einen Tisch, um das Spiel zu beginnen. Das
Matchmaking beginnt also schon mit dem Kennenlernen zwischen den Spielern bevor
sich diese gemeinsam zu einer Partie zusammensetzen und endet mit dem Beginn der
Spielpartie.
17
Ebenso soll das Matchmaking in diesem Projekt gestaltet werden. Der erste Teil - das
Kennenlernen und Unterhalten - wird durch die Möglichkeit des Chattens und der freien
Bewegung in der Lobbyszene geschaen. Es ist also sinnvoll, den zweiten Teil - also
das Zusammensetzen und Starten eines Spieles - ebenso zu gestalten wie es der Nutzer
aus ggf. real erlebten Spieleabenden kennt. Aus diesem Grund werden wir in diesem
Projekt das Matchmaking an virtuellen Tischen stattnden lassen. Hierbei stellt jedes
Polygonmodell eines Tisches ein seperates Spiel dar. Freie Plätze sind durch unbesetzte
Stühle, belegte Plätze durch besetzte Stühle am Tisch erkennbar. Der Nutzer kann also
sofort intuitiv sehen, ob Plätze in einem Spiel frei sind, ob Personen teilnehmen, die er
vielleicht kennt oder ob er das Spiel lieber meiden möchte, weil ihm die anderen Spieler
nicht zusagen.
3.3.2 Erschaen von Rauminstanzen
Ein Problem, welches sich beim Aufstellen von jenen Matchmaking Tischen zwangsläug
stellt, ist die Frage wieviele Spieler sind gleichzeitig in meiner Lobby und entsprechend
wieviele Tische sollen aufgestellt werden. Es ist momentan möglich, dass an jedem Spieltisch schon eine Person Platz genommen hat und man mit seinem gewünschten Spielepartner kein Spiel starten kann. Wenn, um dies zu vermeiden, eine sehr groÿe Anzahl
von Spieltischen aufgestellt wird, kann sich der Nutzer verloren fühlen und verliert sich
vielleicht in diesem riesigen Raum voller Tische.
Es sollte also ein System gefunden werden, das je nachdem wieviele Nutzer in der Lobby
sind bzw. an Spielen teilnehmen wollen, mehr Tische erönet. Die direkteste Möglichkeit wäre es im Lobbyraum entsprechende Tische erscheinen zu lassen bzw. zu entfernen.
Für die Spieler könnte man dieses Erscheinen/Verschwinden, bei einer guten Umsetzung
glaubwürdig darstellen lassen. Beispielsweise könnten vom Computer gesteuerte Polygon
Helfer einen Tisch aus einem für den Nutzer nicht zugänglichen Teil der Lobby herreintragen und so neue Matchmaking Plätze schaen. Jedoch ist die eigentliche Lobbyszene
immer noch in ihrer virtuellen Gröÿe begrenzt und es können also nicht beliebig viele
Tische hinzugefügt werden ohne die Lobby selbst zu vergröÿern.
Aus diesem Grund will ich in diesem Projekt einen anderen Ansatz verfolgen. Zunächst
teilen wir die Lobby auf in eine Eingangsszene, in der die Spieler nach ihrem Login oder
dem Beenden ihrer Partie erscheinen und in, von dieser aus zu betretenden, Matchmaking Szenen. In diesen Matchmaking Räumen benden sich die beschriebenen Tische,
an denen die Spielpartien gestartet werden können. Der Nutzer erreicht die Spielräume
aus der Lobby, indem er einen bestimmten Bereich betritt, z.B. vor einem Aufzug und
18
über ein GUI Dialog auswählt in welchen Raum er möchte. Die Matchmaking Räume
unterscheiden sich entsprechend nur durch die Spieler, die sich in ihnen benden. Es können also beliebig viele Instanzen von Ihnen parallel existieren. Wenn alle Räume belegt
sind bekommen Spieler, die den Übergangsbereich in der Eingangsszene betreten, neue
Räume angeboten. Falls sehr viele Räume leer sind, können diese einfach geschlossen
werden.
Abbildung 3.2: Zustände eines Clients innerhalb der Lobby
Ein weiterer positiver Eekt dieses Systems ist die Entlastung des Netzwerks, da die
Daten z.B. über die Bewegung nur innerhalb eines Raumes ausgetauscht werden und
nicht mehr an alle eingeloggten Nutzer geschickt werden müssen.
3.4 Umgebung und Physik
Bisher haben wir uns mit dem groben Aufbau, der Kameraführung, der Steuerung sowie
dem Matchmaking unseres Lobby Projektes beschäftigt. Ein weiterer wichtiger Punkt
ist, wie Kollisionen zwischen Avatar und Umgebung und speziell zwischen Avatar und
Avatar gehandhabt werden sollen.
Die Handhabung von Kollisionen eines Avatars und der Umgebung lassen wenig Spielraum zu. Sobald ein Charakter auf ein Hindernis stöÿt, muss dieser stehen bleiben oder
einen alternativen Weg wählen. Die eigentliche Herausforderung wird eine korrekte Navigation sein, falls der Nutzer einen Bewegungszielpunkt für seinen Avatar wählt, der
nicht direkt ohne Hindernisse erreichbar ist. Falls diese perfekt funktioniert, könnten
theoretisch alle Kollisionen, bis auf die Bodenkollision, vernachlässigt werden, da sämtliche Hindernisse automatisch von einer Navigationsroutine umgangen werden.
Bei einer Kollision zwischen zwei Spieler Avataren haben wir jedoch die Möglichkeit entweder nicht zu reagieren, d.h. sämtliche Spieler können durcheinander hindurchlaufen
oder wir beachten sie und Spieler können aneinander hängenbleiben. Falls es möglich
19
ist, dass Avatare sich gegenseitig blockieren können, kann dies sehr schnell für Frust sorgen. Dies gilt speziell, wenn viele Spieler in einen kleinen Raum wollen, wie z.B. in die
Zone, die den Raumwechsel zwischen dem Lobby Eingang und den Matchmakingräumen
ermöglicht. Dieses Konzept hat sich bereits im MMORPG World of Warcraft, welches
wir in unserer
State of the Art Analyse
in Kapitel 2 betrachtet haben, bewährt. Aus
diesen Gründen werden Kollisionen zwischen Avataren in meiner Arbeit ebenfalls nicht
beachtet werden. Diese Wahl bringt als positiven Nebeneekt eine Entlastung des Spieleservers mit sich, da dieser nun keine Kollisionen zwischen Spielern berechnen muss.
Dies spart Ressourcen in Form von Rechenkraft und Bandbreite, die anderen Bereichen
zu gute kommen könnnen.
3.5 Kommunikation zwischen Spielern
Spieler sollen in dieser Lobby mit Hilfe von Textbotschaften kommunizieren können. Es
wäre jedoch wenig befriedigend, wenn dies nur in einem kleinen Gui Fenster geschieht.
Da ein zentraler Punkt der Lobby und speziell des Matchmakings die Kommunikation zwischen den Nutzern ist, muss direkt erkenntlich sein, von welchen Spieleravatar
eine Nachricht stammt. Ein bereits in anderen Spielen und speziell im letzten Kapitel
verwendetes Mittel, um dies zu erreichen, sind Sprechblasen über dem Avatar, die den
gesendeten Text oder falls dieser zu lang ist, nur einen Teil beinhalten. Wahlweise können diese Sprechblasen je nach Entfernung skaliert werden oder zur besseren Lesbarkeit
sich mit der Entfernung zu der Kamera nicht verändern. Die Sprechblasen müssen sich
jedoch nach einem zu wählenden Zeitraum wieder ausblenden, damit die Szene nicht an
Übersichtlichkeit einbüÿt. Aus diesem Grund ist jedoch auch ein kleines Gui Fenster, in
dem die Textnachrichten aufgelistet werden, unerlässlich um den Verlauf einer Unterhaltung festzuhalten.
Oft wollen Nutzer jedoch Nachrichten senden, die nicht für jeden sichtbar sind, sondern
nur für einen speziellen Mitspieler. Dieses Versenden von privaten Nachrichten wird oft
üstern
genannt. Das Flüstern zwischen Spielern sollte sich in die Steuerung so gut wie
möglich integrieren. Da die Interaktion zwischen Objekten und das Festlegen eines Bewegungszielpunkts eben mit einem einfach Klick auf die gewünschte Stelle geschieht, ist
es sinnvoll, durch einen Klick auf einen Spieler einen
Flüstern Dialog
gezielt Nachrichten an diese Person gesendet werden können.
20
zu önen, mit dem
3.6 Codedesign
In den vorherigen Abschnitten dieses Kapitels haben wir ein Konzept für das Erscheinungsbild und die Benutzerführung des Lobbysystems erarbeitet. Ein weiterer, für den
Endbenutzer nicht sichtbarer, aber sehr wichtiger Teil ist die Organisation des Quellcodes. Dieser bestimmt wie leicht oder wie schwer die Lobby an unterschiedliche Anforderungen angepasst werden kann, wie zum Beispiel die Lokalisation in andere Sprachen
oder die Verwendbarkeit in anderen Projekten. In der Einführung haben wir unter anderem eine mögliche Verwendung in Casual Games gesehen, da jedoch bei deren Entwicklung das Budget verständlicherweise knapp ist, muss sich eine Lobby leicht ohne groÿen
Aufwand anpassen lassen.
3.6.1 Leichte Anpassbarkeit an neue Inhalte
Ein Leitprinzip, welches hier gelten soll: Es werden möglichst wenige Daten in den Quellcode hart implementiert. Vielmehr sollten fast alle Informationen über externe Dateien
einstellbar sein. Sämtliche Einstellungen können z.B. aus Xml Tabellen eingelesen werden und so leicht modizierbar sein ohne den Quelltext erneut compilieren zu müssen.
Da sich dieses Lobby System sehr leicht an existierende Spiele mit unterschiedlichen
Designs anpassen lassen soll, ist es sinnvoll sämtliche Meshes, Texturen, Animation und
Level Dateien wie z.B. das Routing Mesh zur Navigation, über externe Dateien einstellen
zu können.
3.6.2 Weitgehende Unabhängigkeit vom Design des
Multiplayerspiels
Ebenso wie sich das Lobbysystem durch eine einfache Modizierbarkeit auszeichen soll,
ist es notwendig, dass das eigentliche Spiel nicht durch die Lobby eingeengt wird und nur
über wenige festgelegte Schnittstellen mit der Lobby kommuniziert. So soll die Engine
des Spieles unabhängig von der des Lobby Systems wählbar sein und sich ungefähr wie
in dem in Abb. 3.3 beschriebenen Pseudocode behandeln lassen. Dabei sind folgende
Schnittstellen unerlässlich: Übergabe der Mitspielerdaten, wie z.B. Name oder die IP
Adressen, an das Spiel und die Fenster ID, damit das Spiel in das Lobby Fenster rendern
kann ohne ein neues önen zu müssen.
21
Ein grober Ablauf kann wie folgt aussehen :
1.
Führe die Lobby aus, bis der Benutzer eine Mehrspielerpartie startet
2.
Übergebe sämtliche Daten von der Lobby an das Spiel
3.
Führe das Spiel aus, bis es endet
4.
Reaktiviere die Lobby und gehe zu 1.
Abbildung 3.3: Pseudocode: Übergang zwischen Lobby Client und Spiel
22
3.7 Neuerungen
Im Gegensatz zu bisherigen Lobbysystem, wird hier in erster Linie die Realisierung als
3 dimensionale Umgebung und nicht als Chat verfolgt. Zwar existieren bereits Programme in denen sich Nutzer als Avatare in einer 3D Szene bewegen sowie kommunizieren
können. Jedoch verstehen sich diese nicht als Lobby zu einem Spiel und bieten somit
keine Matchmaking Funktionalitäten, welche jedoch bei unserem Projekt realisiert werden sollen. Das Matchmaking nutzt dabei die 3D Umgebung um vom Nutzer so intutiv
wie möglich durchführbar zu sein. Viele Probleme, die in einer 3D Lobby bei groÿen
Spielerzahlen auftreten können wurden zudem durch ein Instanz/Raum System gelöst.
3.8 Zusammenfassung
In diesem Kapitel haben wir ein Konzept für das Lobby Projekt erstellt. Neben einer
third Person Ansicht haben wir uns für eine Point and Click Maussteuerung entschieden.
Die Nutzer Avatare kollidieren nicht miteinander und kommunizieren über ein Sprechblasen/Chat Dialog System. Das Matchmaking ndet in seperaten Räumen statt und
die Nutzer setzen sich hierzu an virtuelle Tische.
Zudem wurden einige wichtige Punkte für das Codedesign festgelegt, um eine Integration in Spiele zu erleichtern. Im folgenden Abschnitt werden wir nun versuchen, dieses
Konzept umzusetzen und das Ergebnis auswerten.
23
In diesem Kapitel werden zunächst die in der Implementation zusätzlich verwendeten
C++ Bibliotheken kurz vorgestellt. Im Anschluss wird die praktische Umsetzung des
Projektes behandelt sowie auftretende Probleme und die verwendeten Lösungen ausführlich beschrieben. Zum Abschluss dieses Abschnitts wird die implementierte Lobby
mit Hilfe einiger praxisnaher Tests ausgewertet und eine kurze Zusammenfassung gegeben. Bei der Beschreibung der Implementation möchte ich zudem den Programmcode
nur dann direkt angeben, wenn er für das Verständnis der Problemlösung notwendig
erscheint. Falls Interesse an dem Quelltext besteht, liegt dieser kommentiert auf einer
CD im Anhang bei.
Bei der Umsetzung der Lobby wurden die Avatare (Polygonmodelle, Texturen, Animationen) mit Erlaubnis der Zeal GmbH Darmstadt, aus dem PC Spiel Meine Tierklinik,
erschienen im März 2006, verwendet.
4.1 Die verwendeteten C++ Bibliotheken
Nebula Device 2
Das Nebula Device 2, kurz Nebula 2, ist eine von Radeon Labs entwickelte, objektorientierte Open Source Echtzeit 3D Engine mit voller Shader Unterstützung. Nebula 2
arbeitet mit der DirectX API, eine OpenGL Unterstützung ist zur Zeit in Entwicklung.
Als Scriptsprachen werden unter anderem TCL/TK, Lua sowie Python unterstützt. Bei
vielen kommerziellen Projekten, zumeist Spielen, ndet Nebula 2 Verwendung. Nachteile
sind die mangelhafte Dokumentation und eine recht kleine Community, auÿerhalb der
professionellen Entwicklung. Welches sich nicht zuletzt dadurch begründet, dass Weiterentwicklungen und Bugxes der Community nicht in die nachfolgenden, von Radeon
Labs entwickelten, Versionen einieÿen. Nebula 2 wurde aufgrund ihrer Praxisrelevanz,
der Scriptfähigkeiten, als auch aus persönlicher Erfahrung für diese Arbeit ausgewählt.
Zudem wurde die Engine von der Zeal GmbH vorgegeben, da dort viele PC Projekte auf
24
dem Nebula Device 2 und Mangalore basieren. In diesem Projekt wird zumeist Nebula 2
indirekt über das Mangalore Framework angesprochen, welches im Anschluss beschrieben wird.
Das Nebula Device 2 ist verfügbar unter: http://www.nebuladevice.org/
In diesem Projekt wurde folgende Version verwendet: Dezember/2006
Mangalore Game Framework
Das Mangalore Game Framework, entwickelt von Radeon Labs, ist ein objektorientiertes C++ Framework, das die Entwicklung von Echtzeit 3D Spielen vereinfachen soll.
Mangalore zeichnet sich durch die Verwendung von autonomen Spielobjekten sogenannten Entities aus, die erst durch das Anhängen von speziellen Eigenschaften (Properties)
wie z.B. Graphics, Light oder Input Property eine Bedeutung erlangen. Die einzelnen
Objekte können hierbei mit Hilfe eines Message Systems kommunizieren und lassen sich
beliebig durch eigene Properties ergänzen. Zusätzlich sind im Mangalore Framework Teile der Open Dynamics Engine (kurz ODE) integriert. Die ODE ist eine Open Source
Bibliothek zur physikalisierten Echtzeitinteraktion von Objekten und somit in Mangalore für sämtliche Kollisionsabfragen etc. zuständig.
Mangalore erweitert hierbei Nebula 2 und benutzt dessen Low Level Eigenschaften, wie
das Rendern, Audio sowie die Inputabfrage. Das Mangalore Game Framework wurde
von der Zeal GmbH vorgegeben, da dort viele PC Projekte auf dem Nebula Device 2
und Mangalore basieren.
Das Mangalore Game Framework ist verfügbar unter: http://www.nebuladevice.org/
In diesem Projekt wurde folgende Version verwendet: Dezember/2006
Rakknet Multiplayer Network Engine
Für die Netzwerkkommunikation via UDP wurde die Open Source Rakknet Multiplayer
Network Engine (kurz Rakknet) verwendet. Wie im Namen bereits erwähnt, bietet Rakknet eine C++ Bibliothek, die für Multiplayer Spiele über Netzwerk optimiert ist. Sie
besitzt leistungsfähige, einfach zu verwendende Client/Server Interfaces und wurde somit
in dieser Arbeit verwendet. Zusätzlich besitzt sie bereits Testmöglichkeiten, mit denen
sich ein auftreter Ping und/oder Paketloss simulieren lässt.
25
Abbildung 4.1: Kommunikationsschichten
zwi-
schen der Anwendung, Framework,
Engine und System
Die Rakknet Multiplayer Network Engine ist verfügbar unter: http://www.rakkarsoft.com/
In diesem Projekt wurde folgende Version verwendet: 2.444
Haafs Game Engine
Haafs Game Engine (HGE) ist eine kleine, relativ einfach zu handhabende, Open Source
2D Engine. In dieser Arbeit wurde mit ihrer Hilfe ein Multiplayer Netzwerk Dummy
Spiel geschrieben, für welches das Matchmaking stattndet, um zu demonstrieren, dass
die Spiel Engine unabhängig von der Lobby Engine gewählt werden kann. HGE wurde
aufgrund seiner 2D Fähigkeiten und unkomplizierten Handhabung für dieses Projekt
gewählt.
Haafs Game Engine ist verfügbar unter: http://hge.relishgames.com/
In diesem Projekt wurde folgende Version verwendet: 1.6
Tiny Xml
Tiny Xml ist ein kleine, einfach zu handhabende, C++ Bibliothek zum parsen von Xml
Dateien.
Tiny Xml ist verfügbar unter: http://sourceforge.net/projects/tinyxml/
In diesem Projekt wurde folgende Version verwendet: 2.4.0
26
4.2 Grundelemente und Lobbyzustände
Bevor wir detaillierte Implementationslösungen betrachten, möchte ich in diesem Abschnitt den Grundaufbau und die Zustände der realisierten Lobby beschreiben. Von diesen ausgehend können dann die unterschiedlichen Programmteile detailliert betrachtet
werden.
4.2.1 Grundlegendes Design von Client und Server
Client
•
Lobby Client Application Klasse
Das Kernstück des Clients bildet die Lobby Client Application Klasse. Diese wurde
von der Standard Mangalore Application abgeleitet und als Singleton implementiert. Als zentrale Klasse verwaltet sie sämtliche States und deren Wechsel, Zugrie
auf Xml Tabellen via Tiny Xml, den Zugang zur Nebula Engine und intialisiert
die Network Connector Klasse. Sämtliche Systeme werden zudem über eine Run
Schleife in jedem Frame angesprochen.
•
Network Client Connector Klasse
Die Network Client Connector Klasse verwaltet eine Instanz des Rakknet Client
Interfaces, welches von der Rakknet Multiplayer Network Engine zur Verfügung
gestellt wird. Über dieses Interface ist sie für das Senden und Empfangen von
Netzwerk Paketen zuständig. Falls Rakknet nicht als Netzwerk Engine gewünscht
sein sollte, kann die Lobby allein durch Austauschen dieser Klasse auf eine beliebige
andere Art über Netzwerk kommunizieren.
•
Game State Klassen
Die drei wichtigsten Memberfunktionen einer State Klasse sind eine OnStateEnter
Funktion, die beim ersten Aufruf des States ausgeführt wird, eine OnStateLeave,
die dies beim Verlassen des States tut und eine OnFrame Funktion, die jeden Frame
aufgerufen wird und den nächsten State, falls ein Wechsel vollzogen werden soll,
zurückgibt. Die einzelnen Gamestates werden hierzu von der Lobby Client Application Klasse initialisiert, angesprochen und gewechselt. In diesem Projekt besitzt
jeder State einen eigenen Gui Dialog, der jeweils mit initialisiert/deinitialisiert
wird. Die Game State Klassen bieten hierbei verschiedene Arten der Grundinititalisierung und Ausführung je nachdem welche Aufgabe der entsprechende State
wahrnehmen soll. Diese sind bereits durch das Mangalore Framework gegeben und
27
bestimmen die Zugrismöglichkeiten auf die Nebula 3D Engine und ggf. welche
Parameter aus den von Mangalore verwalteten Datenbanken geladen werden sollen. Die einzelnen Arten der Inititialisierung werden im nächsten Abschnitt über
die Client Zustände näher beleuchtet.
•
Gui Dialog Klassen
Da die Gui Dialog Klassen für die einfache Modizierbarkeit der Lobby über Tcl
Scripte gestaltet werden, besteht jeder Gui Dialog aus drei Teilen. Der erste Teil
stellt Funktionen zur Kommunikation mit der Lobby Application bereit, der zweite
Teil stellt die Schnittstelle zu dem Tcl Script dar. Der dritte Teil, das eigentliche
Tcl Script, kann nun mit Hilfe eines von Mangalore verwalteten Script Servers
Widgets erschaen und sie über die Schnittstellen, die in der zugehörigen C++
Klasse deniert sind, mit dem Programm kommunizieren lassen. Sind nun optische Veränderungen gewünscht, kann die Gui verändert werden ohne den C++
Quelltext anpassen zu müssen, da hierzu sämtliche Daten in den TCL Scripten zur
Verfügung stehen.
Server
Der Server wurde im Gegensatz zur Lobby als einfache Konsolenanwendung realisiert
um eine bestmögliche Performance zu bieten. Ebenso wie der Client besitzt er eine
Network Server Connector Klasse, welche die Netzwerkkommunikation übernimmt. Eine
komplexe State Verwaltung, wie dies bei dem Client realisiert worden ist, war hier nicht
nötig, da nach der Initialisierung des Servers kein Statewechsel mehr vollzogen wird.
Die Implementation und Organisation des Servers wird im Abschnitt
System
Das Client/Server
dieses Kapitels näher beschrieben.
4.2.2 Client Zustände und deren Aufgaben
Die Gamestateklasse stellt ihren Instanzen mehrere Möglichkeiten der Grundinitialisierung zur Verfügung, die bestimmen wie weit der Gamestate auf die Nebula Render
Funktionen Zugri hat und welche Daten von Mangalore geladen werden sollen. Folgende
wurden bei der Entwicklung der States in dieser Arbeit verwendet:
•
New Game
Bevor 3D Szenen dargestellt werden können, ist es wichtig Mangalore mit einem
New Game State zu initialisieren. Dieser wiederum veranlasst, dass sämtliche Systeme initialisiert werden, die für ein Rendern mit Nebula notwendig sind.
28
•
Empty World
Falls die Grundinitialisierung eines Gamestates auf Empty World gesetzt wurde,
wird eine leere 3D Szene erschaen. Dies bietet sich für States an, die entweder
nur aus Gui Dialogen bestehen oder falls alle Objekte manuell vom Programmierer
zur Laufzeit erschaen werden sollen. Die Initialisierung mit dem Empty World
Parameter benötigt somit auch keine zusätzlichen Levelparameter.
•
Load Level
Load Level ermöglicht das Laden eines bereits denierten Levels. Mangalore besitzt für das Speichern von Level Daten bereits intern eine Sql Datenbank, in der
sämtliche Levelobjekte, deren Layouts und Parameter eingetragen werden. Die
Layouts bestimmen welche Eigenschaften (Properties) das Mangalore Objekt (Entity) besitzen wird. Die Denition der Layouts wird in einer zusätzlichen Xml Datei
(Blueprints.xml) festgelegt. Wenn der Load Level State mit Angabe des Levelnamens aufgerufen wird, werden nun sämtliche Level Objekte mit ihren Eigenschaften
automatisch erzeugt.
Jeder Game State des Lobby Clients baut auf eine dieser Grundinitalisierungen auf. Die
Lobby kann dabei folgende States erreichen.
Das Programm startet im Initialisierungs State.
Initialisierungs State
Initialisierung:
Aufgaben:
New Game
Der Inititalisierungs State startet sämtliche Nebula und Mangalore Un-
tersysteme. Hierzu werden die Initialisierungsdaten aus einer Script Datei (startup.tcl)
gelesen, die unter anderem die verwendete Grak API und Eekte wie HDR festlegt.
Statewechsel:
Falls alle Subsysteme erfolgreich initialisiert worden sind, begibt sich der
Lobby Client in den Login State. Wenn jedoch ein Fehler aufgetritt, beendet sich das
Programm mit einer entsprechenden Fehlermeldung.
Login State
Initialisierung:
Aufgaben:
Load Level
Im Login State kann der Nutzer sich seinen gewünschten Avatar wählen
sowie seinen Nickname bestimmen. Wenn der Nutzer seine Auswahl getroen hat, kann
mit Hilfe eines Login Buttons die Verbindung zum Server hergestellt werden. Eine weitere
29
Aufgabe besteht darin eine Fehlermeldung anzuzeigen, falls das Programm in diesen
State wechselt, weil z.B. die Serververbindung unterbrochen wurde.
Statewechsel:
Der State wird beendet, wenn der Nutzer mit einem Klick auf den Login
Button seine Angaben bestätigt. Die Lobby wechselt dann in den
Connect to Server
State.
Abbildung 4.2: Im Login State kann der Nutzer
einen Namen und Avatar wählen
Connect to Server State
Initialisierung:
Aufgaben:
Empty World
In diesem State versucht das Programm eine Verbindung zum Server her-
zustellen. Bei einem Fehlschlag wird dies bis zu dreimal wiederholt.
Statewechsel:
Wenn die Verbindung zum Server erfolgreich war, wird das Level auf
Lobby Eingang
gesetzt und in den
Fehlschlag wechselt
Get Level Data State gewechselt. Nach dem dritten
die Lobby in den Login State und zeigt eine entsprechende Fehler-
meldung an.
Get Level Data State
Initialisierung:
Aufgaben:
Empty World
Der State fragt vom Server Daten für ein bestimmtes Level an. Entweder
werden die Daten für den Lobby Eingang oder eine Rauminstanz abgerufen.
30
Statewechsel:
gramm in den
Wenn die Daten erfolgreich übertragen worden sind, wechselt das Pro-
Main Lobby State.
Gab es Fehler bei der Übertragung und schlug diese
bis zu dreimal fehl, wird mit einer entsprechenden Fehlermeldung in den
Login State
gewechselt.
Main Lobby State
Initialisierung:
Aufgaben:
Load Level
Der Main Lobby State stellt den zentralen Lobby Bereich dar. Je nach
gesetztem Level wird hier der Lobby Eingang oder eine Rauminstanz mit Matchmaking
Möglichkeiten angezeigt. Der Nutzer kann hier mit anderen Spielern chatten, sich im
Raum bewegen, üstern oder ein Spiel beginnen.
Statewechsel:
Wenn der Nutzer in ein Multiplayer Spiel einsteigt, werden alle nicht
mehr von der Lobby benötigten Resourcen freigegen und in den
Sleep State
gesprungen.
Falls der Nutzer den Raum (siehe Abb. 3.2) wechseln möchte, wird der entsprechende
Raum als zu ladendes Level gesetzt und in den
Load Level State
gewechselt. Wenn die
Server Verbindung unterbrochen wird, wechselt das Spiel wie üblich in den
Abbildung 4.3: Der Lobby Eingangsbereich mit simulierten
Spielern (Bots)
31
Login State.
Sleep State
Initialisierung:
Aufgaben:
Empty World
Im Sleep State wartet das Programm auf das Spiel. Zusätzlich hält dieser
zum Lobby Server den Netzwerkkontakt.
Statewechsel:
Wenn das Spiel beendet ist, wird das Level auf den Lobby Eingangsbe-
reich gesetzt und in den
Load Level
Zustand gewechselt.
Abbildung 4.4: Übersicht über die Lobby Client States
4.2.3 Modizierbarkeit mit Hilfe von Scripten und Datenbanken
Levelobjekte
Wenn ein Level erzeugt wird, werden zunächst alle Level Objekte (Entities), wie Kamera, Lichquellen und Physikobjekte (Kollision und Routing Meshes) aus der Mangalore
eigenen SQL Datenbank (export/db/world.db3) gelesen. Jedes Objekt besitzt dabei eine eigene Kategorie, die bestimmt durch welche Eigenschaften dieses deniert ist (mehr
dazu im nächsten Abschnitt). Die Grundkategorien werden dabei in einer Xml Tabelle festgehalten (data/tabels/blueprints.xml). Sämtliche simulierten physikalischen und
graschen Eigenschaften wie Grak Meshes, Animationen und Kollisionsverhalten oder
Navigationspunkte werden ebenfalls extern organisiert (Pfad: /data/tables/) und deren
Pfade in einem Initialisierungsscript (startup.tcl) gesetzt, welches beim Start des Mangalore Frameworks ausgeführt wird.
32
Auf diese Art ist es möglich, das komplette Erscheinungsbild zu verändern, ohne auch
nur eine Zeile im Quellcode umschreiben zu müssen. Dies ist notwendig falls die Lobby
ohne groÿen Aufwand an ein vorhandes Projekt angepasst werden soll.
Abbildung 4.5: SQL Level Datenbank
GUI
Wie bereits erwähnt, sind sämtliche GUI Dialoge mit Hilfe von Tcl Scripten realisiert
worden. Konsequenterweise werden auch sämtliche Daten wie Überschriften, Fehlermeldungen etc. aus einer externen Xml Datei geladen, um eine möglichst einfache Lokalisierung zu ermöglichen (LobbyClientLoca.xml).
4.3 Aufbau des Lobby Clients durch Entities und
Properties
Bei der Realisierung des Projektes wird das Design durch die Verwendung von Entities
und deren Eigenschaften (Properties) bestimmt. Entities sind dabei zunächst neutrale Spielobjekte und repräsentieren ein Objekt wie zum Beispiel den Avatar oder eine
Lichtquelle. Jedoch hat die Entity an sich zunächst keine konkrete Funktion. Ihre Funktionalität wird dadurch hergestellt, dass diese mit Eigenschaften verknüpft wird. Soll
sie sichtbar sein, wird zum Beispiel eine entsprechende Graphics Property an diese verknüpft; soll sie als Lichtquelle dienen, erhält sie zusätzlich eine Light Property.
33
Entities kommunizieren hierbei mit Hilfe eines Nachrichtensystems untereinander und
mit sich selbst. Ein Beispiel: Mein Avatar besitzt unter anderem eine Steuerungs- und
eine Physikproperty. Eine Aufgabe der Physikproperty ist die Wegndung und die Bewegung des Avatar Meshes. Wenn der Nutzer mit der Maus einen Bewegungszielpunkt
wählt, wird dies zunächst von der Steuerungsproperty registriert. Im Anschluss sendet
diese eine Nachricht mit dem Bewegungszielpunkt an die eigene Entity, die die Nachricht
(wie jede empfangene Nachricht) wiederum an alle ihre Properties weiterleitet, wie auch
an die Physikproperty, die im Anschluss die Wegndung durchführt.
Abbildung 4.6: Jedes
Spielobjekt
durch
seine
erhält
Eigenschaften
Funktionen
Alle Objekte, die in der Lobby auftreten, sind als Entity mit entsprechenden Properties
realisiert, wie z.B. Avatare und Umgebung. Viele Properties sind bereits im Mangalore
Framework enthalten. Es ist jedoch auch einfach -und notwendig-, abgeleitet von einer
Standard-Property, eigene zu realisieren, die ich in diesem Abschnitt ebenso wie die
Entites vorstellen möchte.
4.3.1 Erzeugung von Entities
In diesem Projekt werden zwei Möglichkeiten zur Erzeugung von Entites genutzt. Die
Hauptlobby, mit allen statischen Objekten, wird mit den Daten aus der Level Datenbank
automatisch beim Eintritt in den
Main Lobby State
erzeugt. Die Art der Entity wird
dabei durch dessen Kategorie bestimmt und die entsprechenden Properties erzeugt und
angehängt.
Sämtliche anderen Level Daten, wie die Avatare, werden zunächst vom Server im
Level State
Load
übertragen und anschlieÿend dynamisch erzeugt, genauso wie Spieler, die
sich nach dem eigenen Beitritt in die Lobby einklinken.
34
4.3.2 Eingesetzte Game Entities
Zunächst werden sämtliche, in der Lobby verwendete Entities, kurz mit ihrer Funktion
und den verbundenen Properties vorgestellt. Im Anschluss werden die Properties, die
die Funktionen der Entities bestimmen, genauer beschrieben.
Avatar Entity
Der Avatar ist das für den Nutzer zentrale Objekt, stellt den Spieler dar, reagiert auf
dessen Maus/Tastatur Eingaben, orientiert die Kamera entsprechend und überträgt seine
Bewegungsdaten über das Netzwerk an den Server. Entsprechend existiert in der Lobby
immer nur eine Avatar Entity.
Sie besitzt folgende Properties: Actor Physics Property, Actor Graphics Property, Actor
Animation Property, Display Chat Property, Network Move Property, Zone Manager
Property und Game Zone Property.
Abbildung 4.7: Die Avatar Entity
Player Entity
Sämtliche anderen Clients, die in die Lobby eingeloggt sind, werden durch Player Entities dargestellt. Diese Entities empfangen über den Server mit einer speziellen Remote
Input Property Bewegungs-, Animations- und Chat-Daten und führen die übermittelten
Aktionen aus. Für jeden zusätzlich zu dem Nutzer eingeloggten Spieler existiert somit
eine Player Entity.
Sie besitzt folgende Properties: Actor Physics Property, Actor Graphics Property, Actor
Animation Property, Display Chat Property und die Remote Input Property.
35
Matchmaking Entity
Die Realisierung des Matchmakings wird, wie bereits im Konzeptentwurf entwickelt,
mittels Spieltischen realisiert, an die sich jeder Spieler setzen kann, sofern ein Platz frei
ist. Diese Tische mit den zugehörigen Sitzmöglichkeiten werden durch die Matchmaking
Enitities dargestellt.
Entsprechend besitzen diese eine Graphics-, eine Physics- und eine speziell entwickelte
Matchmaking-Property.
Abbildung 4.8: Darstellung
der
Matchmaking
Entity
mit einem besetzten Platz
Environment Entity
Sämtliche statischen Umgebungsobjekte, wie z.B. die Bäume oder der Boden, werden in
einer Environment Entity zusammengefasst. Diese hat die Eigenschaft, dass sie zwar für
andere Objekte physikalische Eigenschaften besitzt, jedoch selbst nicht diesen unterliegt.
Falls diese selbst den simulierten physikalischen Gesetzmäÿichkeiten folgen würde, müsste sie mit sämtlichen anderen Objekten nach unten fallen, was natürlich nicht gewünscht
ist. Die Environment Entity besitzt keine manuell festlegbaren Properties, sondern wird
Managlore intern verwaltet.
Light Entity
Die Light Entity ist ein einfaches Lichtquellenobjekt im Spiel. Es besteht aus einer Entity,
an die eine Mangalore Light Property verknüpft wurde.
Simple Graphic Objekt Entity
Um eine Avatar-Auswahl und -Vorschau in dem Login State möglich zu machen, wird
ein einfaches Objekt, bestehend aus einer Entity mit einer Grak Property verwendet.
36
Der Avatar wird gewechselt, indem zunächst der Pfad für das Nebula Grak Objekt auf
die nächste Avatar Grak gesetzt und im Anschluss die Grak Property neu gestartet
wird.
4.3.3 Properties
Network Move Property
Die Network Move Property ist für die Steuerung des Avatars und die Übertragung
der Bewegung an den Server zuständig. Die Steuerung mit der Maus funktioniert auf
folgende Weise: Bei einem Linksklick, wird die 2D Mausposition in 3D Koordinaten
zurücktransformiert. Anschlieÿend wird eine Gerade aus Kameraposition und 3D Mausposition erstellt und diese durch einen in der Physik Bibliothek vorhandenen optimierten
Algorithmus mit allen Entities (die eine Physikproperty besitzen) geschnitten. Falls die
in kleinster Blickrichtung liegende Entity die Environment Entity ist, wird eine GoTo
Message mit dem Schnittpunkt als Ziel erschaen und an die Avatar Entity, sowie an
den Network Connector weitergegeben. Der Network Connector teilt das neue Laufziel
mit dem Ausgangspunkt dem Server mit. Die GoTo Message wird in der Entity wiederrum von der Avatar Physik Property aufgenommen: Es wird ein Pfad berechnet und das
Grak Mesh entsprechend pro Frame manipuliert.
Falls eine andere Entity als die Environment Entity zurückgegeben wird, bekommt diese eine Message gesendet, dass sie angeklickt worden ist. Andere Player Entities önen
dann z.B. einen Flüstern Dialog.
Remote Input Property
Ebenso wie der Spieler seine Bewegungen über die Netzwerk Property weiterleitet, empfangen alle anderen Spieler-Avatare Bewegungs und Chatupdates mit Hilfe des Client
Network Connector über den Server. Bei Empfang einer Bewegungs- oder PositionsVeränderung über das Netzwerk wird dies den zugehörigen Entities mit Hilfe einer Entity Nachricht weitergeleitet. Wie bei allen Nachrichten, die von einer Entity empfangen
werden, wird diese zur Auswertung an ihre Properties weitergegeben. Hierbei übersetzt
dann die Remote Input Property das Positions/Bewegungsupdate in Nachrichten für die
Physikproperty, die im Anschluss das Grak Mesh entsprechend der Bewegung manipuliert.
37
Display Chat Property
Die Display Chat Property verarbeitet Entity-Nachrichten, die eine Chat-Nachricht anzeigen sollen. Die Chat-Nachricht wird anschlieÿend über der Entity in einer Sprechblase angezeigt, die von der Property als Gui Element erzeugt wurde. Falls verschiedene
Sprechblasen gleichzeitig existieren, werden sie nach Kamera Enitity Entfernung sortiert
(Vergleiche Abb. 4.3). Wenn keine Nachricht vorliegt, wird ein festgelegter Name angezeigt. In diesem Projekt ist dies der Spielername. Aus diesem Grund besitzten Avatar
und auch die Player Entity diese Property.
Matchmaking Property
Diese Property weist mit Hilfe der Matchmaking Entity bei einer Platzanfrage durch
den Nutzer (ausgelöst durch einen Linksklick) der Avatar Entity einen Platz zu und
reserviert diesen.
Abbildung 4.9: Kommunikation zwischen Spieler und Matchmaking
Entity
38
Der Linksklick auf die Matchmaking Entity bewirkt zunächst, dass diese eine EntityNachricht mit dem Hinweis erhält, dass sie angewählt wurde. Als Antwort schickt die
Matchmaking Property eine Nachricht an die Avatar Entity mit den Koordinaten des
Platzes, falls der Platz frei ist. Dabei wird der Platz gewählt, der noch frei ist und am
längsten nicht zugewiesen wurde. Dies geschieht, um zu verhindern, dass mehrere Spieler
auf einen Platz gleichzeitig Anspruch erheben und sich so gegenseitig blockieren.
Im Anschluss bekommt die Avatar Physik Property der Avatar Entity die Nachricht
gesendet, dass sie sich an die Koordinaten des zugewiesenen Platzes bewegen soll. Am
Punkt angekommen, sendet die Avatar Entity nun eine Nachricht an die Matchmaking
Entity mit der Anfrage, ob der Platz noch frei ist. Bei einer positiven Antwort der
Matchmaking Entity wird der Platz automatisch auf dem Server reserviert und die Hinsetzen Animation der Avatar Entity abgespielt.
Auf diese Art ist gewährleistet, dass immer nur ein Spieler auf einem Platz sitzen kann.
Die Matchmaking Property fragt hierbei jedesmal den Server mit Hilfe der Network Client Connector Klasse ab, welche Plätze reserviert sind. Gibt der Nutzer während dieses
Prozesses eine anderen Laufbefehl, wird der Dialog abgebrochen und der Platz nicht
reserviert.
Modizierte Mangalore Properties
Neben den oben erwähnten Properties, wurden einige bereits im Mangalore Framework
vorhandene verwendet. Folgende wurden dabei an die Lobby angepasst.
Die Avatar Physik Property wurde dahingehend modiziert, dass über eine Variable
bestimmt werden kann, ob Kollisionen mit anderen Avatar Physik Objekten aktiviert
und deaktiviert sind. Eine Deaktivierung ist notwendig um zu verhindern, dass Spieler
sich gegenseitig blockieren.
Die Chase Camera Property erhielt zudem leichte Modikationen, welche eine bessere
Steuerung des Kamerawinkels ermöglichen.
4.4 Das Client/Server System
In diesem Abschnitt gehen wir zunächst kurz auf die verwendete Netzwerkbibliothek ein.
Im Anschluss wird der Aufbau des Servers erläutert, sowie die Kommunikation zwischen
Client und Server näher betrachtet.
Die Netzwerk Kommunikation wird im Fundament durch die Rakknet Bibliothek festgelegt. Diese wurde jedoch, wie bereits am Anfang dieses Abschnittes besprochen, so
39
gekapselt, dass sie ohne gröÿere Probleme durch ein beliebiges anderes System ersetzt
werden kann. Der Client besitzt die Network Client Connector Klasse, die das Rakknet
Client Interface benutzt, ebenso wie der Server eine Network Server Connector Klasse
hat, der entsprechend eine Instanz des Rakknet Server Interfaces als Member besitzt
(vgl. 4.2.1). Die Kommunikation zwischen den Rakknet Interaces läuft über die Rakknet
Bitstream Klasse, welche die zu sendenden Daten aneinandergereiht als String speichert.
Dieser Datentyp kann im Anschluss mit Hilfe des Rakknet Interface gesendet werden,
die Zerteilung in Netzwerkpakete und das Ordnen dieser in die richtige Reihenfolge, wird
dabei von der Rakknet Bibliothek übernommen. Das Weiterleiten einer Chatnachricht
soll hier zunächst als Beispiel dienen.
Abbildung 4.10: Quelltext: Der Server teilt einem Client mit, dass eine Chatnachricht gesendet wurde
Anhand dieses Quelltextes wird deutlich, wie unkompliziert die Netzwerkkommunikation
mit Hilfe der Rakknet Multiplayer Network Engine realisierbar ist. Ebenso wie das Senden von Daten mit Bitstreams wird das Empfangen dieser verwaltet. Hier ist es zunächst
sinnvoll die erste Stelle eines Bitstreams zu betrachen, da dort immer die Information
zur Identikation des Streams, in diesem Fall als eingehende Chat Nachricht, gespeichert
ist. Ein Quelltext Ausschnitt zeigt hierzu Abb. 4.11.
Zudem ist zu beachten, dass die Kommunikation in der Lobby nur zwischen dem Client
und dem Server verläuft. Eine Kommunikation zwischen den Clients ndet dort nicht
40
Abbildung 4.11: Gekürzter Quelltext: Chat Nachricht wird vom Client empfangen
statt. Erst zum Start des Mehrspielerspieles werden die IPs der Mitspieler untereinander
ausgetauscht, da dieses nicht über den Lobbyserver läuft.
4.4.1 Aufbau des Servers
Die zentrale Aufgabe des Servers besteht darin, die Clients zu verwalten und deren Informationen über die Spielumgebung (Position der anderen Spieler, Chatnachrichten)
aktuell zu halten. Um diese Aufgabe zu erfüllen, enthält der Server neben einer zentralen Server Klasse eine Lobby Server Network Connector Singelton Klasse, die ähnlich
wie beim Client das Senden und Empfangen von Daten über das Netzwerk verwaltet.
Der Lobbyeingang und jede Rauminstanz wird in einer Raum-Klasse verwaltet, sowie
jedes Matchmaking Objekt in einer Game-Klasse. Die Hauptserverklasse besitzt eine
Liste der Raum Klassen. Die Räume wiederum besitzen jeweils eine Liste der möglichen
Spiele innerhalb des Raums.
Jeder eingeloggte Client wird in zwei verschiedenen Bereichen gespeichert. Zum Einen
mit allen verfügbaren Informationen, wie IP Adresse, Port, Nickname, Position etc. in
einer Liste im Server, zum Anderen über einen Key (hier wurde der Nickname gewählt)
in der Raum/Spiel Klasse in der sich der Spieler bendet.
41
Dies ist nötig, damit Informationen, die nur für Spieler, die sich im selben Raum/Spiel
benden interessant sind, schnell an diese weitergegeben werden können. Würde nur eine
Liste exisitieren, müsste bei jeder Chatnachricht oder Bewegungsinformation vor dem
Versenden die komplette Client Liste durchgegangen werden um zu überprüfen, ob sich
die Clients im selben Raum benden wie der Sender der Nachricht.
4.4.2 Übermitteln von Bewegungs- und Positionsdaten
Die intuitivste Möglichkeit zum Abgleichen der Client-Positionsdaten besteht darin, jeden Programmdurchlauf bei einer Positionsänderung, diese an den Server zu senden, der
wiederum alle anderen Clients aktualisiert. Dass dies jedoch eine sehr ineziente Art der
Kommunikation ist, wird sehr schnell sichtbar: Wenn ein Client von einem Punkt zum
anderen läuft, werden hier, bei angenommen durchschnittlichen 60 Programmdurchläufen pro Sekunde, 60 Positionsupdates gesendet, die der Server wiederum an alle anderen
Clients weiterleiten muss. Angenommen zur selben Zeit befänden sich 100 andere Spieler
im gleichen Raum, dann müsste der Server nur für diese eine Bewegung 60 * 100 = 6000
Positionsdaten pro Sekunde (!) senden. Hinzu kommt, dass sich selten immer nur eine
Person gleichzeitig im Raum bewegen wird. Aus diesem Grund würde dieses Verfahren
sehr schnell zu einer Überlastung des Servers und der Netzwerk Kommunikation führen.
Um an einen besseren Ansatz zu gelangen, schauen wir zunächst wie Client intern die
Bewegung realisiert wurde: Durch einen Klick setzt der Nutzer den Bewegungszielpunkt
fest, dies wird per Nachricht an die Physik Property der Spieler Entity übermittelt, die
den Pfad berechnet und die Bewegung durchführt. Die Entity benötigt also zunächst
nur den Bewegungszielpunkt - zusätzlich zur statischen Levelinformation - um die Bewegung von einem zum anderen Punkt zu berechnen. Optimal wäre es dementsprechend
nur den ausgewählten Bewegungszielpunkt an den Server weiterzuleiten, der diesen an
alle anderen Clients weiterverteilt und deren Position somit aktualisiert.
Eine solche Realisierung wäre optimal, aber da die Daten über das Netzwerk ausgetauscht werden müssen und dies Übertragungsverzögerungen mit sich bringt, werden
die Zielpunkte nicht überall gleichzeitig vorhanden sein. Dies kann zum Beispiel dazu führen, dass falls jedesmal nur der Bewegungszielpunkt übermittelt wird, bei einem
Abbruch der Bewegung oder einem neuen Zielpunkt, unterschiedliche Positionsdaten
zwischen den verschiedenen Clients existieren. Die Daten auf den Clients laufen also
leicht Gefahr nicht mehr identisch zu sein.
Aus diesem Grund wird bei jeder Nachricht, die die Position des Clients verändert,
42
zusätzlich zum Bewegungszielpunkt, die aktuelle Position und Ausrichtung der Entity
gesendet. Falls nun die Nachrichten zu spät oder verzögert ankommen, wäre im schlimmsten Fall eine kleine Verzögerung zu spüren, jedoch würden die Daten zwischen den Clients
synchron bleiben.
Hierbei existiert natürlich die Vorraussetzung, dass die Levelinformation auf jedem Client indentisch ist, damit überall auch derselbe Bewegungpfad berechnet wird.
Abbildung 4.12: Der Bewegungspfad wird mit Hilfe von Navigationspunkten -hier durch
rote Kugeln visualisiert- berechnet
4.4.3 Übersicht: Verwendete Kommunikationsstreams
Wie bereits beschrieben, wird der Datenaustausch mit Rakknet über Bitstreams realisiert. Jeder in diesem Projekt verwendete Bitstream besitzt an seiner ersten Position
eine Nummer zur Identikation seines Types. In dieser Übersicht sollen die Arten der
implementierten Bitstreams kurz vorgestellt werden, um einen Überblick über die Netzwerkkommunikation zu bekommen.
Nachrichten vom Client an den Server
•
Login Request
Anfrage nach einem möglichen Login
Enthaltende Information: Gewünschter Login Name
43
•
Send Chat Message
Der Client möchte eine Chat Nachricht senden
Enthaltende Information: Chat Nachricht und Name
•
Level Data Request
Anfrage der Spielernamen und Positionen in einem Raum
Enthaltende Information: Gewünschter Raum
•
Move Goto
Der Client bewegt sich zu einer bestimmten Postion
Enthaltende Information: Aktuelle Position und Ausrichtung, sowie der Bewegungszielpunkt
•
Move Stop
Der Client bricht seine aktuelle Bewegung ab und bleibt stehen
Enthaltende Information: Aktuelle Position und Ausrichtung
•
Ask for New Player
Der Client hat Daten zu einem Mitspieler erhalten, der ihm nicht bekannt ist und
fragt dessen Daten zur Darstellung beim Server an
Enthaltende Information: Name des neuen Spielers
•
Change Room
Der Client wechselt den aktuellen Raum
Enthaltende Information: Neuer Raum
•
Room Request
Der Client fragt an welche Räume im Augenblick zu betreten sind
Enthaltene Information: -
•
Free Seat Request
Der Client möchte einen Platz in einem Spiel zugewiesen bekommen
Enthaltende Information: Raum und Spiel
•
Seat Request
Der Client möchte den zugewiesenen Platz fest reservieren
Enthaltende Information: Raum, Spiel und Platz
•
Move Turn
Der Spieler Avatar dreht sich in eine bestimmte Richtung
44
Enthaltende Information: Aktuelle Position und Ausrichtung, gewünschte Ausrichtung
•
Play Animation
Der Avatar spielt eine bestimmte Animation ab
Enthaltende Information: Identikationsnummer der Animation
•
Positions Aktualisierung
Der Avatar aktualisiert (meistens vom Server angefragt) seine Position und Ausrichtung
Enthaltende Information: Position und Ausrichtung
•
Leave Seat Request
Der Client möchte seinen Platz an dem Matchmaking Tisch verlassen
Enthaltende Information: -
•
Accept Game Message
Der Client teilt dem Server mit, dass er bereit ist das Spiel zu starten, erneutes
Senden führt zum Widerruf
•
Send Private Message
Flüsternachricht an einen Mitspieler schicken
Enthaltende Information: Name, Chatnachricht und Name des gewünschten Empfängers
Nachrichten vom Server an den Client
•
Connection Success
Die Verbindung wurde hergestellt, warte auf eine Login Anfrage
•
Login Reply
Dein Loginversuch war erfolgreich/ist fehlgeschlagen
Enthaltene Information: Erfolgreich/Nicht Erfolgreich
•
Level Data
Alle Spielerdaten für einen bestimmten Raum
Enthaltene Information: Spielernamen, Avatare, Position und Ausrichtung von allen Clients in dem angefragten Raum
45
•
Player Time Out
Ein Spieler hat die Lobby verlassen
Enthaltene Information: Spielername
•
New Player
Ein neuer Spieler hat den Raum betreten
Enthaltene Information: Spielername, Avatar, Position und Ausrichtung
•
Move Goto Forward
Ein Spieler bewegt sich zu einem neuen Punkt
Enthaltene Information: Name des Spielers, alte Position und Ausrichtung sowie
der Bewegungszielpunkt
•
Move Stop Forward
Ein Spieler bricht seine Bewegung ab
Enthaltene Information: Name des Spielers, Position und Ausrichtung
•
Leave Room
Ein Spieler verlässt den Raum des Clients
Enthaltene Information: Name des Spielers, der den Raum verlässt
•
Enter Room
Ein Spieler betritt den Raum des Clients
Enthaltene Information: Avatar, Name, Position und Ausrichtung des Spielers
•
Open Rooms
Mögliche zu betretende Räume
Enthaltene Information: Anzahl der verfügbaren Räume
•
Seat Message
Ein Platz in einem Spiel wurde für den Client reserviert
Enthaltene Information: Raum, Spiel und Platz
•
Move Turn Forward
Ein Spieler ändert seine Ausrichtung
Enthaltene Information: Spielername, aktuelle Position und Ausrichtung, gewünschte Ausrichtung
46
•
Play Animation Forward
Ein Spieler möchte eine bestimmte Animation abspielen
Enthaltene Information: Spielername, Animationsnummer
•
Leave Seat Message
Die Reservierung des Clients für einen Spielplatz wurde rückgängig gemacht
Enthaltene Information:-
•
Game Update
Aktualisierung der Bereitschaftszustände in einem Spiel um dieses zu starten
Enthaltene Information: Spielername, Bereitschaftszustand
•
Start Game
Alle Spieler für eine Partie sind bereit, starte Spiel
Enthaltene Information: Mitspielernamen, zugehörige IP Adressen und Ports
•
Get Private Message
Ein Mitspieler hat diesem Client eine Private Nachricht gesendet
Enthaltene Information: Sendername, Nachricht
•
Private Message Failed
Es war nicht möglich die Private Nachricht zu versenden, der Spieler ist nicht
online
Enthaltene Information: Spielername
4.5 Wechsel zwischen Lobby und Multiplayerspiel
Nach erfolgreichem Matchmaking in der Lobby wechselt diese in einen Sleep State, in
dem fast alle Teile des belegten Speichers freigegeben werden und das eigentliche Spiel
startet. Bei der Erstellung des Konzeptes für eine 3D Lobby haben wir als wichtigen
Punkt festgelegt, dass die Realisierung des Spieles weitgehend unabhängig von der Implementation der Lobby sein soll. Das heiÿt unter anderem auch, dass eine andere Engine,
Game Framework oder auch Netzwerk Programmierung vorliegen kann. Um dies zu testen wurde ein kleines Netzwerk Spiel - eine Netzwerk Pong Variante - in einer anderen
2D Engine (Haafs Game Engine s.o.) geschrieben. Bei Start des Spiels, kann dieses seine benötigten Informationen über festgelegte Schnittstellen von der Lobby Anwendung
abrufen:
47
•
GetHwnd()
Liefert die ID des von der Application benutzten Windows Fenster zurück, damit
die neue aufgerufene Engine in dieses rendern kann.
•
GetPlayerNames()
Liefert die Liste der Spielernamen als String Array zurück.
•
IsServer()
Gibt zurück ob der Spieler einen Server önen soll.
•
GetServerId()
Falls der Spieler nicht den Server übernimmt, kann mit dieser Funktion der Port
und die IP Adresse des Servers abgefragt werden.
•
SleepTrigger()
Mindestens jede dritte Sekunde muss ein SleepTrigger bei der Lobby durchgeführt
werden, damit diese nicht den Kontakt zum Server durch einen Timeout verliert
und direkt nach Spielende wieder zu dieser zurückkehren kann.
•
Wakeup()
Das Spiel ist zu Ende, die Lobby wird wieder aktiv.
Der Wechsel zwischen Spiel und Lobby ndet dabei auf folgende Art statt:
1. Die Lobby Anwendung wechselt in den Sleep State und bricht seine Run Schleife,
die sonst jeden Frame aufgerufen wurde, ab.
2. Es wird abgefragt, ob die Lobby in den Sleep State gewechselt ist oder ob sie geschlossen wurde. Wenn die Lobby geschlossen wurde, beendet sich das Programm.
3. Es werden alle für das Spiel benötigten Informationen, wie unter anderem die
Server IP und die Fenster ID abgefragt.
4. Das Spiel wird gestartet und ruft jeden Zyklus einen Sleep Trigger auf die Lobby
Anwendung auf.
5. Nach Beenden des Spiels wird die Lobby mit einem Wakeup() Befehl aus dem
Sleep State in den Load Level State gewechselt und alle Ressourcen wieder in den
Speicher geladen.
6. Die Run Schleife der Lobby Anwendung wird wieder angesprochen.
48
Die Pong Variante wurde hierbei nur sehr einfach implementiert, da sie als Beispiel
dienen soll und nicht das eigentliche Thema ist. Ihr Quelltext ndet sich dokumentiert
in der Datei pong.h.
Abbildung 4.13: Screenshot: Multiplayer Netzwerk Pong
4.6 Zusammenfassung
Die Realisierung dieses Projektes in dem gegebenen Zeitrahmen war nur mit Einsatz
von umfangreichen Programm Bibliotheken möglich. Nebula diente hierbei als 3D Engine und Mangalore, das auf diesem aufbaut, als Game Framework. Ausgehend von dieser
Grundstruktur wurde anhand des Entity und Property Systems die Lobby realisiert.
Auch standen so zahlreiche Möglichkeiten zur Verfügung, um die fertig programmierte
3D Lobby schnell an ein vorhandenes Spiel anpassen zu können ohne Veränderungen in
der Lobby Struktur vornehmen zu müssen. Sämtliche GUI Dialoge können so leicht über
externe TCL Scripte angepasst werden, 3D Level und Navigationsobjekte werden in einer externen SQL Datenbank gespeichert und Animationen sowie lokalisierbare Texte
sind über externe Xml Tabellen anpassbar.
Als Bibliothek zur Netzwerkkommunikation wurde die Rakknet Multiplayer Network
Engine verwendet, über die sämtliche Informationen zwischen Client und Server ausgetauscht werden. Die Kommunikation läuft dabei nur zwischen Client und Server. Dies
bedeutet, dass Daten nicht direkt zwischen zwei Clients ausgetauscht werden, sondern
49
immer indirekt über den Server - der in diesem Fall als Übermittlungs- und KontrollInstanz arbeitet - ausgetauscht werden.
Der Wechsel zwischen der Lobby und dem Multiplayerspiel wurde mit Hilfe von festgelegten Kommunikationsschnittstellen realisiert, die u.a. eine Änderung der Spieleengine
zulassen. Während das Spiel läuft, bendet sich die Lobby in einem Ruhezustand, in
der nur die Netzwerkverbindung zum Server aufrechterhalten wird. Nachdem das Spiel
beendet wurde, wird die Lobby aus dem Ruhezustand geholt und der Spieler bendet
sich wieder im Eingangsraum.
50
5 Test und Auswertung der
Implementation
Im vorherigen Kapitel wurde das zuvor entworfene Konzept des Lobbysystems implementiert. Nun soll dies einigen Test unterzogen werden, um es bezüglich der Zuverlässigkeit
und Praxistauglichkeit bewerten zu können.
5.1 Testsysteme
Für die Tests standen folgende 3 unterschiedliche Testsysteme zur Verfügung:
System 1
Modell: Dell Inspiron 6400 Laptop
CPU: Intel Centrino Duo, 2 Prozessorkerne, Takt: 1,83 Ghz
Arbeitspeicher: 2048MB
Grak: ATI Mobility Radeon X1400 / Speicher: 256MB
Betriebsystem: Windows XP Media Center Edition
Netzwerkanbindung: 100 MBit/s Ethernet
System 2
Modell: Desktop Rechner
CPU: AMD Athlon 64 3500+ Takt: 2,21 Ghz
Arbeitsspeicher: 2048MB
Grak: Nvidia Geforce 7900 GT / Speicher: 256MB
Betriebsystem: Windows XP Professional
51
System 3
Modell: Desktop Rechner
CPU: AMD Athlon XP 2600+ Takt: 2,08 Ghz
Arbeitspeicher: 1024MB
Grak: ATI Radeon 8500 / Speicher: 64MB
Betriebsystem: Windows XP Professional
Die Testsysteme sind in einem LAN über einen Siemens Gigaset Se505 Router verbunden, der sowohl als Gateway zum Internet dient als auch das Lokale Netzwerk mit
seinen Funktionen als Switch zusammenführt.
5.2 Testprogramme und Erweiterungen
5.2.1 Simulation von Wide Area Network Bedingungen
Da die Testsysteme über ein Ethernet Lan vernetzt sind, existieren so für den Programmablauf optimale Bedingungen. Da die Lobby jedoch nicht nur in einem LAN,
sondern auch über das Internet - ein WAN - so gut wie möglich laufen soll, ist es nötig
die Eigenschaften eines WAN's zu simulieren. Denn während in einem LAN die Übertragungszeit eines Netzwerkpaketes im Vergleich zum Internet sehr schnell ist und in der
Regel ohne gröÿere Schwankungen erfolgt, sind die Bedingungen über ein WAN andere.
Die Sendezeit eines Netzwerkpaketes ist höher und schwankt, zudem ist der Verlust eines
Paketes wahrscheinlicher.
Ein Vorteil der verwendeten Rakknet Multiplayer Network Engine ist das Vorhandensein eines Netsimulators, der verschiedene Netzwerkbedingungen simulieren kann. So
kann die Sendezeit eines Paketes erhöht und eine zufällige Ping Schwankung simuliert
werden. Der Netsimulator wird dabei sowohl auf dem Server als auch bei dessen Clients
aktiviert, damit die Verzögerungen beidseitig wirken.
5.2.2 Erzeugung von Pseudo Clients
Da es mit den drei Testsystemen nicht möglich ist genug echte Clients für einen Auslastungstest auf dem Server einzuloggen, wurde ein Programm implementiert, welches
Pseudo Clients erzeugt. Diese Pseudeo Clients verhalten sich für den Server wie ech-
52
te Clients: Sie loggen sich auf dem Server ein und senden zufällig Laufbefehle, sowie
Chatnachrichten. Jedoch ignorieren sie fast alle Netzwerkpakete die vom Server zurückgesendet werden und verzichten auf eine Visualisierung. So ist es mit diesem Programm
möglich, fast beliebig viele Clients von einem Rechner aus auf dem Server einloggen zu
lassen. Das Programm zur Erzeugung von Pseudo Lobby Clients bietet folgende Einstellungsmöglichkeiten: Anzahl der zu erzeugenden Bots, Einstellung eines Zeitfensters
bis zur nächsten Aktion, sowie der zeitliche Abstand, mit dem sich die Clients auf dem
Server einloggen.
5.3 Serverauslastungstests
Zunächst soll die Belastbarkeit und Stabilität des Servers getestet werden.
5.3.1 Maximale Anzahl von Spielern
Testziel/Vorraussetzungen
In dieser Testreihe wird untersucht, wieviele Spieler sich gleichzeitig auf dem Server
benden können. Im schlechtesten Fall sind alle Spieler in einer Rauminstanz eingeloggt,
da so bei der Bewegung eines Clients alle übrigen Spieler darüber informiert werden
müssen und entsprechend eine maximale Anzahl von Netzwerkpaketen gesendet werden
muss. Aus diesem Grund werden alle Clients in den selben Raum gesetzt. System 1
arbeitet als Server, während System 2 Pseudo Clients (Bots) erzeugt, um eine maximale
Auslastung des Servers zu erreichen. Die Bots werden hierzu in einem Abstand von
jeweils 2 Sekunden eingeloggt (Spawn Time) und führen in einem Zeitfenster von 2 4 Sekunden einen Lauf oder einen Chatbefehl aus (Action Time). Das Netzwerk erhält
zusätzlich zu der vorhandenen Verzögerung eine simulierte Latenz von 20-30 ms.
Messungen
Bei den Messungen wurden alle Werte wie Action und Spawn Time identisch belassen
und nur die Anzahl der erzeugten Pseudo Clients erhöht. Wie in der Tabelle zu sehen
ist, wurde die Anzahl der erzeugten Clients schrittweise bis zur Auslastung des Servers
angehoben.
53
Abbildung 5.1: Tabelle: Messergebnisse Auslastungstest 1
Auswertung
Mit bis ca. 200 Spielern in einem Raum läuft der Server mit einer akzeptablen Antwortzeit. Lediglich 6 Spieler benötigten einen zweiten Versuch, um eine Verbindung zum
Server herstellen zu können. Dies wird in der Regel vom Nutzer nicht bemerkt, da jeder
Client automatisch bis zu 3 Verbindungsversuche startet.
Die Anzahl der benötigten Bitstreams zur Initialisierung eines Clients lässt sich dabei auf
folgende Weise berechnen: Sobald der j-te Client verbindet, muss dieser die komplette
Information über alle andere Clients im selben Raum erhalten, ebenso müssen diese die
komplette Information über den grade neu verbundenen Client erhalten. Das heiÿt, es
müssen
2 ∗ (m − 1) Clientzustände ausgetauscht werden. Wenn also m Spieler verbinden,
gilt für die Anzahl der ausgetauschten Clientzustände
m
X
2 ∗ (k − 1) = −2 ∗ m + 2 ∗
k=1
m
X
k = m2 − m = O(m2 )
k=1
Wie wir sehen steigt die Anzahl der allein zur Initialisierung notwendigen Informationen
quadratisch. Dies sind bei 232 eingeloggten Clients 53592 Initialisierungsstreams. Hinzu
kommt, dass bereits verbundene Clients Aktionen durchführen, die den Server zusätzlich
54
belasten.
Um sicherzugehen, dass die Überlastung des Servers nicht auf einem Versagen des Programmes zur Erzeugung von Pseudo Clients beruht, wurde dieses von 2 verschiedenen
Rechnern gestartet. System 1 führte wieder den Server aus, System 2 stellte 150 Pseudo Clients und System 3 erzeugte 100. Das Ergebnis war ähnlich: Bei 220 eingeloggten
Clients verlor ein Groÿteil die Verbindung, während im Anschluss der Server wieder zuverlässig reagierte. Eine Anhebung der Spawn Time führte ebenso nicht zu einer höheren
Stabilität.
Abbildung 5.2: Screenshot: Zusammenbruch des Servers bei sehr
vielen Pseudo Clients
5.3.2 Zusammenhang zwischen Serverreaktionszeit und
Botaktivität
Als wir die Belastbarkeit des Servers bezüglich der Anzahl verbundener Clients gemessen
haben, wurde die Aktivität dieser auÿer acht gelassen. In diesem Test soll nun betrachtet
werden, wie sich die Gröÿe der Aktionsintervalle auf die Serverreaktionszeit auswirkt.
System 1 dient hierbei wieder als Server, System 2 erzeugt sämtliche Pseudo Clients und
führt die Messung der Antwortzeit durch.
55
Messungen
Auswertung
Die Messungen ergeben, dass die Aktivität der Clients bei lediglich 100 eingeloggten
Bots keine gröÿeren Verzögerungen durch ein kürzeres Aktionsintervall erzeugen. Erst
nachdem die Botzahl auf 150 erhöht wurde, machte sich das kürzere Aktionsintervall
stark bemerkbar.
Abbildung 5.4: Diagramm:
Zusammenhang
Aktionsintervall - Latenz
Die Anzahl der versendeten Aktionen pro Sekunde setzt sich auf folgende Art zusammen,
m := Anzahl der Clients, i:=Abstände der Aktionen (s), A:=Durchschnittliche Anzahl
zu sendender Aktionen pro Sekunde
A=
1
∗ m ∗ (m − 1)
i
56
1
bestimmt die Häugkeit, mit der die Clients eine Aktion durchführen, wenn dies gei
schieht führen
m
Clients diese Aktion aus und senden sie jeweils an alle anderen
m−1
Spieler weiter. Wir sehen, dass die Aktions Frequenz die Anzahl zu sendender Daten
lediglich linear beinusst, während die Anzahl der eingeloggten Clients einen quadratischen Faktor darstellt. Dies führt dazu, dass primär die Anzahl der Clients und weniger
die Häugkeit ihrer Aktionen Auswirkung auf die Antwortzeit des Servers besitzen.
5.3.3 Gleichzeitiger Login von vielen Clients
Alle bisherigen Tests lieÿen die Clients schrittweise mit einem Abstand von 2 Sekunden
einloggen. Was passiert jedoch im schlimmstmöglichen Fall, wenn viele Spieler versuchen
sollten sich im selben Augenblick mit dem Server zu verbinden? Wie in den vorherigen
Tests stellt System 1 den Server zur Verfügung, während System 2 versucht möglichst
viele Clients mit Spawn Time 0 einzuloggen.
Messungen
Auswertung
Wie in den Messungen zu sehen, war es möglich bis zu 80 Clients gleichzeitig zu dem
Server zu verbinden. Bei einer gröÿeren Anzahl konnte der Server die Anfragen nicht
57
mehr schnell genug beantworten und wurde von den Clients überfordert, die so implementiert waren, dass sie im Falle eines Fehlschlages versuchen, die Verbindung nochmals
herzustellen. Nachdem der Server länger als 10 Sekunden brauchte, um eine Verbindung
und den Login von allen 80 Clients durchzuführen, wurde die Action Time drastisch
erhöht und es war möglich, dass der Server auch bei 80 gleichzeitigen Loginversuchen
stabil lief. In keinem Fall stürzte der Server komplett ab, sondern kehrte in einen stabilen
Zustand zurück, sobald die Login Anfragen ausblieben.
5.4 FPS Tests
Abbildung 5.6: Screenshot: FPS Tests mit vielen Clients
Alle bisherigen Tests bezogen sich lediglich auf die Reaktionszeit auf dem Server. Doch
wie viele Clients in einem Raum lässt die Framerate überhaupt zu? Hierzu wurde auf
System 1 wieder der Server gestartet, auf System 2 wurde der Lobby Client eingeloggt
und von System 3 aus wurden die Pseudo Clients mit dem Server verbunden. Zusätzlich
lief auf System 2 Fraps, ein Programm das extern die Framerate von 3D Anwendungen
messen kann. Bei der Messung befanden sich alle Clients in einem Raum und die Kamera
wurde so ausgerichtet, dass alle Avatare zu sehen waren. Die Messungen fanden auf
System 2 statt.
58
Abbildung 5.7: Messung: Bilder pro Sekunde bei steigender Client Anzahl
Messungen
Auswertung
Während mit nur einem Client über 160 FPS möglich sind, bricht mit steigender Anzahl sichtbarer Avatare die Framerate spürbar ein. Ab 40 Avatare werden erste Ruckler
bemerkbar, während bei 60 nur noch 10 Bilder pro Sekunde berechnet werden können.
Dies macht sich jedoch erst bemerkbar, wenn alle Avatare gleichzeitig zu sehen sind.
So ist es möglich, dass sich 60 Mitspieler im selben Raum benden und trotzdem eine
üssige Bildfolge über 30 FPS zu erreichen. Hinzu kommt, dass sich im Normalfall nicht
alle Spieler im selben Raum benden, sondern aufgeteilt in den Rauminstanzen. Eine
bessere Framerate könnte zudem erreicht werden, wenn auf weniger komplexe Avatare
zurückgegrien wird.
5.5 Wahrnehmung von steigender Latenz
Ein wichtiger Faktor der Lobby ist die Frage, wie sich eine steigende Latenz auf die
Wahrnehmung des Spielers auswirkt. Ab welchem Ping treten für den Spieler sichtbare
Sprünge, sogenannte Lags, in der Bewegung der Avatare auf ? Dieser Test ist in dieser Hinsicht subjektiv, da dies von jedem Nutzer unterschiedlich wahrgenommen wird.
Während ein geübter Betrachter bereits sehr früh erste Verzögerungen feststellt, sind
59
diese ggf. für weniger erfahrene Spieler noch nicht zu erkennen.
System 1 stellt hierbei wieder den Server, während sich von System 2 und 3 jeweils ein
Client verbindet. Diese lassen ihren Avatar in der Lobby Bewegungen mit schnellen Richtungsänderungen durchführen und beobachten, ob in der Bewegung des anderen Sprünge
zu erkennen sind. Bei jedem Versuch wird mit Hilfe des Netsimulators die Latenz und
entsprechend ihre Schwankung erhöht.
Messungen
Abbildung 5.8: Messung: Wahrnehmung von steigender Latenz
Die einzelnen Unterteilungen sind hierbei nicht als feste Grenzen zu sehen, sondern gehen
ieÿend ineinander über.
Auswertung
Mit steigender Latenz werden für den Spieler zunehmend stärkere Verzögerungen im
Lobby Ablauf sichtbar. Da sich der Ping bei unseren Servertests aber gröÿtenteils unter
70 bewegte, werden für den Spieler nur selten sichtbare Lags auftreten selbst wenn viele
andere Clients eingeloggt sind.
60
6.1 Zusammenfassung
In dieser Arbeit wurde ausgehend von aktuellen Matchmaking Systemen ein 3D Lobbysystem geschaen. Dabei wurde speziell auf ein intuitives Matchmaking und eine einfache
Bedienung wertgelegt, um dieses nicht nur für Core Gamer, sondern auch für Casual Gamer interessant zu machen. Zudem versteht sich dieses Lobbysystem nicht als endgültig,
sondern mehr als ein exibles leicht anpassbares System. Daher ist sie besonders einfach
für zukünftige Spiele anpassbar: Sämtliche Szenen, Avatare, Animationen, Einstellungen
und GUI Dialoge lassen sich ohne Änderung des Quelltextes nur über Scripte, XML
Tabellen und Datenbanken sehr leicht modizieren.
Abbildung 6.1: Screenshot: Weniger aufwändige Avatare können für eine bessere Framerate sorgen
Um ein so komplexes Projekt in kurzer Zeit umzusetzen, war es nicht möglich ohne vorhandene Bibliotheken auszukommen. Aus diesem Grund wurden neben Nebula 2 als 3D
Engine, das Mangalore Game Framework, sowie für die Netzwerktechnik die Rakknet
Multiplayer Network Engine bei der Implementation des Lobbysystems verwendet.
Wie die Tests zeigen bendet sich das entwickelte System in einem einsatzfähigen Zustand. So können sich gleichzeitig in der Lobby bis zu 200 Spieler aufhalten und das
Matchmaking durchführen, ohne mit Lags oder Timeouts vom Server rechnen zu müssen. Lediglich die Framerate der einzelnen Clients kann bei sehr vielen eingeloggten
61
Nutzern unter 20 FPS fallen. Je nach der erwarteten Anzahl von Spielern sollte hier ggf.
auf Avatare mit weniger Polygonen zurückgegrien werden.
6.2 Ausblick
Das implementierte Lobbysystem ist einsatzbereit und kann mit wenigen leichten Modikationen an zukünftige Spiele angepasst werden.
Ein wichtiger Schritt, um die Lobby weiterzuentwickeln, wäre das Ermöglichen von Nutzerprolen. So könnte sich ein Spieler, nach seiner Registrierung im System, mit seinen
Nutzerdaten einloggen und leichter andere Mitspieler, ggf. auch über eine Freundesliste,
wiedererkennen und kontaktieren. Auÿerdem könnten so für jeden Spieler Statisken über
bereits geführte Spiele gespeichert werden. Eine Art Belohnungssystem wäre daraus eine
logische Folge: Sobald der Spieler gewisse Zeile erreicht hat, z.B. 50 Multiplayer Partien
gewonnen hat, werden ihm Punkte gutgeschrieben. Diese könnte er in der Lobby z.B. in
ein Accessoir investieren.
Bisher sind alle verwendeten Avatare statisch, d.h. einzelne Komponenten können nicht
ausgetauscht werden. Daher wäre es für eine weitere Personalisierung und Identikation
des Nutzers mit dem Avatar angebracht, auf individuelle Avatare zurückzugreifen. Diese
individuellen Avatare könnten dann je nach Geschmack des Nutzers in bestimmten Kategorien, wie z.B. Haare, Gesicht, Hautfarbe etc., angepasst werden.
Eine zusätzlich notwendige Erweiterung wäre ein Loginserver auf den sich der Nutzer
vor dem eigentlichen Lobbyserver verbindet. Wie wir gesehen haben, bricht der Server
- wenn auch erst bei einer sehr hohen Anzahl - bei zu vielen Spielern zusammen. Aus
diesem Grund sollte die Anzahl der Spieler auf einem Server limitiert werden. Denkbar
wären mehrere Lobbyserver, auf die der Loginserver die Nutzer bei einem Login verteilt,
damit ein einzelner Server nie mehr als 200 Spieler verwalten muss.
Wie wir sehen kann das Lobbysystem noch in vielen Bereichen ausgebaut werden und
ich hoe, dass eine erweiterte Version in zuküngen Multiplayer Spielen zum Einsatz
kommen wird.
62
7 Glossar
API
API (für engl. application programming interface, deutsch: Schnittstelle zur Anwendungsprogrammierung).
Bei einer Api handelt es sich um eine Schnittstelle, die von einem Softwaresystem anderen Programmen zur Anbindung an das System zur Verfügung gestellt wird. Eine
API deniert hierbei die Schnittstelle auf Quelltextebene. Im weiteren Sinne, wird die
Schnittstelle jeder Bibliothek(Library) als API bezeichnet.
Casual Games
Bei Casual Games handelt es sich um elektronische Spiele, die sich durch eine einfache
- intuitive - Bedienung und schnelle Erfolgserlebnisse auszeichen. Im Gegensatz zu Core
Games ist hier die Einarbeitungszeit sehr kurz. Auf diese Weise werden auch Spieler angesprochen, die nicht zu den klassischen Core Gamern gehören und eine gröÿtmögliche
Immersion in das Spiel suchen. Als erstes Casual Game wird häug das in Microsoft
Windows 3.x enthaltene Solitaire betrachtet.
Chat
Das Wort Chat ist abgeleitet von dem englischen Verb to chat was soviel bedeutet wie
unterhalten oder plaudern.
Chat bezeichnet die elektronische Kommunikation, im Gegensatz zu eMails, in Echtzeit.
Bei einem reinen Textchat werden hierbei Textbotschaften ausgetauscht. Es gibt jedoch
auch Audio und Videochats die eine Kommunikation über Ton und/oder Video erlauben. Eine virtuelle Umgebung, in der sich mehrere Leute zum
chatten
treen wird als
Chatraum bezeichnet.
Core Games
Core Games stehen im Gegensatz zu den Casual Games. Sie bezeichnen die Spiele, die
in erster Linie für den klassischen Zocker, der viel Zeit in ein Spiel investieren kann und
63
7 Glossar
will, entwickelt worden sind. Diese bieten i.d.R komplexere Inhalte und eine gröÿere Immersion in das Spielgeschehen, als die bei Casual Games der Fall ist.
Echtzeit Strategiespiele
Bei Echtzeit Strategiespielen handelt es sich um ein Computerspielgenre, bei denen alle
Spieler/Computergegner gleichzeitig agieren. Im Vordergrund stehen dabei zumeist das
Kommandieren der eigenen Einheiten um ein bestimmtes Ziel zu erreichen. Das klassische Echtzeit Strategiespiel zeigt dabei das -meist rechteckige- Schlachtfeld aus einer
Vogelperspektive.
Ethernet
Unter dem Begri Ethernet wird eine Familie von Netztechnologien für Lokale Datennetze (LANs) zusammengefasst, welche die Adressierung, das Rahmenformat und die
Zugriskontrolle auf das Übertragungsmedium verbindet.
Adressierung
Jede Netzwerkkarte besitzt eine eindeutige Ethernet Adresse. Jede Adresse besteht aus
sechs Bytes. Üblich ist hierbei die Angabe der einzelnen Bytes mit je zwei Hex-Zeichen,
getrennt durch Doppelpunkte. Eine Adresse die nur Einsen besitzt bewirkt, dass alle
Rechner im Netz angesprochen werden, man spricht hierbei von einem Broadcast.
Rahmenformat
Bei einem Ethernet Netzwerk handelt es sich um ein so genanntes Paketbasierendes
Netzwerk: Die Daten werden vor ihrer Übertragung in kleinere Einheiten - sog. Pakete - aufgeteilt und vom Empfänger wieder zusammengesetzt. Die Pakete werden dabei
unabhängig voneinander versendet, was dazu führen kann das einzelne Pakete verloren
gehen oder die Reihenfolge vertauscht wird.
Zugriskontrolle
Das Ethernet wurde für die gemeinsame Nutzung eines Übertragungsmediums (Kabel)
durch viele Stationen entwickelt (Mehrfachzugrisnetz). Dabei hört jede Station permanent die Leitung ab. Ist ein Paket für eine Station interessant, kann sie von dieser
übernommen werden. Soll hingegen ein Paket gesendet werden, wartet der Rechner bis
die Leitung frei ist und sendet dann das Paket. Wenn jedoch zwei oder mehr Stationen
ein Paket zu nahezu selber Zeit schicken, kann es zu sogenannten Paketkollisionen kom-
64
7 Glossar
men, wodurch die gesendeten Daten unbrauchbar werden. Wird eine Kollision von einer
Station erkannt, sendet diese ein 32 Bit langes Stausignal und die Nachrichtensender
versuchen nach einer zufälligen Wartezeit erneut ihr Paket zu übermitteln.
Paketaufbau
Die Präamble besteht aus einer 7 Byte langen, alternierenden Bitfolge (101010...1010)
Abbildung 7.1: Aufbau eines Ethernet Paketes
und dient der Bit-Synchronisation der Netzwerkgeräte. Das SFD markiert das Ende der
Einschwingphase. Die Bus-Netzwerkarchitekturen, die auf derartige Einschwingvorgänge
angewiesen sind, werden heute kaum mehr verwendet, und die Präamble bendet sich
nur noch aus Kompatibilitätsgründen in der Spezikation.
In den nächsten Teilen wird zunächst die Ziel und dann die Quell Ethernet- oder MACAddresse gespeichert.
Das VLAN Tag ist vier Bytes lang und wird nur eingesetzt, falls es sich um ein Virtual
Local Area Network (VLAN) handelt, dies ist ein virtuelles lokales Netz innerhalb eines
physischen Netzes.
Das folgende Type Feld gibt Auskunft über das verwendete Protokoll in der nächsthöheren Schicht der Nutzerdaten, so steht z.B. 0x0800 für das Internet Protkoll (IP).
Die folgenden Nutzdaten können pro Datenblock zwischen 0 und 1500 Bytes lang sein.
Sie sind die eigentlichen Informationen, die übertragen werden sollen. Die Nutzdaten
werden von dem unter Type angegebenen Protokoll interpretiert.
Das Pad Feld wird bei Bedarf verwendet um das Ethernet Frame auf die erforderliche
Minmalgröÿe von 64 Byte aufzufüllen. Das in Type angegebene Protokoll muss dafür
sorgen, dass diese als Pad angefügten Bytes nicht interpretiert werden.Das letzte Feld
65
7 Glossar
gibt schlieÿlich die Prüfsumme über den gesamten Frame an. Anhand dieser kann der
Empfänger überprüfen, ob das Paket korrekt übertragen wurde und es bei Bedarf neu
anfordern.
Hardware
In modernen Netzwerken sind zumeist alle Stationen, über Twisted-Pair-Kabel sternförmig mit einem Hub oder Switch verbunden, der die entsprechenden Signale weiterleitet.
First Person Kamera
Bei der rst person Kamera Ansicht wird die Szene aus der Sicht des Spieler-Avatars
gezeigt. Der Avatar wird also (bis auf ggf. die Arme oder Körperteile) nicht direkt vom
Spieler gesehen, welches eine bessere Identikation mit dem gespielten Charakter ermöglichen soll.
Framework
In der Softwareentwicklung bestimmt ein Framework die Rahmenstruktur und somit die
Archtiektur der Anwendung grundlegend. Hierzu stellt es dem Programmierer Basisbausteine in Form von abstrakten und konkreten Klassen zur Verfügung.
Gateway
Ein Gateway dient als Vermittler zwischen verschiedenen Netzwerken und erlaubt diesen, unabhängig von ihren Protokollen, zu kommunizieren.
Host
Host steht im Englischen für Wirt/Gastgeber und bezeichnet in der Informationstechnik
einen Computer, der in einem Netzwerk ein oder mehrere Server betreibt. Aus diesem
Zusammenhang werden Hosts umgangsprachlich auch oft als Server bezeichnet.
Hub
Hub steht im englischen für Knotenpunkt und bezeichnet in der Telekommunikation
Geräte, die Netzwerk Knoten sternförmig verbinden.
LAN
Siehe Local Area Network
66
7 Glossar
Library
Unter Library, engl. für Bibliothek, versteht man in Informationstechnologie eine Programmbibilothek. Bei diesen handelt es sich um Sammlungen von Programmfunktionen
und Klassen, die kein eigenständiges Programm bilden, sondern Hilfsmodule darstellen
die in anderen Programmen verwendet werden können.
Lobby
Unter einer Lobby versteht man im allgemeinen einen Empfangsraum. Im Zusammenhang mit Computerspielen bezeichnet eine Lobby einen Teil des Programmes, in dem
Mehrspielerpartien gestartet werden können. Hierbei bietet eine Lobby nicht nur eine
Übersicht über vorhandene Spielmöglichkeiten, sondern lässt die Nutzer vor und während dem Matchmaking miteinander kommunizieren.
Local Area Network
Ein Local Area Network (LAN) bezeichnet ein lokales Netz, das es einer Anzahl gleichberechtiger Teilnehmer auf einem räumlich begrenzten Gebiet (üblich sind bis zu 10km)
Nachrichten/Daten auszutauschen. LANs können hierbei drahtgebunden arbeiten, wie
z.B. die standartisierten Verfahren Ethernet und Token Ring, aber auch drahtlos wie
dies bei WLANs der Fall ist.
Matchmaking
Im Zusammenhang mit Multiplayer Spielen bezeichnet Matchmaking, den Prozess in
dem sich Nutzer zu einer gemeinsamen Partie zusammenschliessen und diese starten.
Massively Multiplayer Online Role-Playing Game(MMORPG)
Der Begri des Massively Multiplayer Online Role-Playing Game (wörtlich übersetzt:
Massen-Mehrspieler-Online-Rollenspiel) beschreibt ein Computerrollenspiel, bei dem gleichzeitig bis zu einige tausend Spieler eine dauerhaft bestehnde virtuelle Welt mit ihren
Avataren betreten können. Dies geschieht üblicherweise, indem sich die Nutzer mit Hilfe
eines Clients auf dem Rollenspielserver einloggen.
Open Source
Open Source bedeutet wörtlich übersetzt Quelloenheit. Im Zusammenhang mit Software heiÿt dies, dass es jedem möglich ist den Quelltext des Open Source Programmes
67
7 Glossar
Abbildung 7.2: Screenshot aus Stendhal einem Open
Source MMORPG
einzusehen. Auch wird damit die Erlaubnis verbunden diesen zu ändern und weiterzugeben.
Packet Loss
Packet Loss beschreibt den Verlust von Paketen bei einer paketbasierenden Datenübertragung in einem Netzwerk (siehe Ethernet).
RTS
Abkürzung für Real Time Strategy, siehe Echtzeitstrategie Spiele.
Script
Bei einem Script handelt es sich um ein Programm oder eine Befehlsfolge, die erst bei
ihrer Ausführung durch einen Interpreter in Maschinencode umgewandelt wird. Dadurch
sind Scriptsprachen im allgemeinen nicht so performant wie Programmiersprachen, deren
Code vor der Ausführung komplett durch einen Compiler in Maschinencode übersetzt
wird.
Switch
Ein Switch (engl. Schalter oder Weiche), ist ähnlich dem Hub eine Netzwerk Komponente zum sternförmigen Verbinden von Netzwerkkomponenten. Zusätzlich analysieren
Switches den Netzwerkverkehr und treen logische Entscheidungen, so dass die Daten
68
7 Glossar
nicht wie bei klassischen Hub an jeden Teilnehmer weitergeleitet werden, sondern möglichst nur an den Rechner, der als Empfänger bestimmt ist. Aus diesem Grund entlastet
die Verwendung von Switches das Netzwerk erheblich.
Abbildung 7.3: Mit Hilfe eines Switches werden Rechner
sternförmig vernetzt
Structured Query Language (SQL)
SQL bezeichnet eine Sprache zur Ansicht und Manipulation von Daten in relationellen
Datenbanken.
Szenengraph
Ein Szenengraph ist eine Datenstruktur, die häug bei der Entwicklung computergrascher Anwendungen eingesetzt wird. In der graphentheoretischen Sicht handelt es sich
bei einem Szenegraphen um einen Baum, dessen Wurzelknoten die Gesamtszene bildet.
Diesem untergeordnet sind Objekte der Szene, die wiederrum selbst Objekte als Kinder enthalten können. Man unterscheidet in diesem zwischen Objektkoordinaten und
Weltkoordinaten. Objektkoordinaten bezeichnen die Position eines Objektes zu seinem
übergeordneten Objekt/Knoten, Weltkoordinaten hingegen bezeichnen die Position im
Bezug zur Position der Wurzel (Gesamtszene). Bei der Transformation eines Knotens
werden dabei sowohl der Knoten, als auch alle seine Kinder transformiert.
Third Person Kamera
Die
third person
Kamera zeigt die Szene aus der dritten Person, meist leicht schräg von
oben, der Sichtwinkel kann dabei oft vom Nutzer gesteuert werden. Ein Vorteil dieser
69
7 Glossar
Ansicht ist eine gröÿere Übersicht über die Szene, da der Spieler auch Bereiche einsehen
kann, die unmittelbar neben und hinter seinem Avatar liegen.
User Datagram Protocol (UDP)
Das User Datagram Protocol -kurz UDP- ist ein Netzprotokoll, dass zur Transportschicht der Internetprotokollfamilie gehört. Hierbei handelt es sich um verbindungsloses
Protokoll, d.h. dass vor Übertragungsbeginn keine Verbindung aufgebaut werden muss,
wie dies z.B. bei TCP der Fall ist. UDP stellt jedoch keinen Mechanismus bereit um
verlorengegangene oder vertauschte Pakete zu erkennen. Daher sollte eine Anwendung,
die UDP als Netzprotokoll verwendet unempndlich gegenüber diesen sein.
70
8 Screenshots
Abbildung 8.1: Screenshot: Lobby Client
71
8 Screenshots
72
8 Screenshots
73
8 Screenshots
74
1.1
Screenshot aus Microsoft: Solitaire
. . . . . . . . . . . . . . . . . . . . .
5
2.1
Screenshot aus CC: Generäle - Die Stunde Null, Publisher: EA Games . .
8
2.2
Screenshot aus CC: Generäle - Die Stunde Null, Publisher: EA Games . .
9
2.3
Screenshot aus World of Warcraft: Burning Crusade, Publisher: Blizzard
11
2.4
Screenshot aus World of Warcraft: Burning Crusade, Publisher: Blizzard
12
3.1
Grundzustände des Lobbysystems . . . . . . . . . . . . . . . . . . . . . .
15
3.2
Zustände eines Clients innerhalb der Lobby . . . . . . . . . . . . . . . . .
19
3.3
Pseudocode: Übergang zwischen Lobby Client und Spiel
. . . . . . . . .
22
4.1
Kommunikation mit Nebula Mangalore . . . . . . . . . . . . . . . . . . .
26
4.2
Screenshot aus dem Projekt: Login Screen
30
4.3
Screenshot aus dem Projekt: Main Lobby State mit Bots
. . . . . . . . .
31
4.4
Übersicht über die Lobby Client States . . . . . . . . . . . . . . . . . . .
32
4.5
SQL Level Datenbank
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
4.6
Jedes Spielobjekt erhält durch seine Eigenschaften Funktionen . . . . . .
34
4.7
Avatar Entity: Screenshot aus dem Lobby Client . . . . . . . . . . . . . .
35
4.8
Avatar Entity: Screenshot aus dem Lobby Client . . . . . . . . . . . . . .
36
4.9
Kommunikation zwischen Spieler und Matchmaking Entity . . . . . . . .
38
. . . . . . . . . . . . . . . . .
4.10 Quelltext: Lobby Server - LSNetworkCon.cpp Zeile 226
. . . . . . . . . .
40
. . . . . . . . .
41
4.12 Screenshot: Darstellung mit als Kugeln visualisierten Navigationsmesh . .
43
4.13 Screenshot: Netzwerk Pong Variante
49
4.11 Gekürzter Quelltext: Lobby Client - LCNetworkCon.cpp
. . . . . . . . . . . . . . . . . . . .
5.1
Tabelle: Messergebnisse Auslastungstest 1
5.2
Screenshot: Zusammenbruch des Servers bei sehr vielen Pseudo Clients
5.3
5.4
Diagramm: Zusammenhang Aktionsintervall - Latenz
75
. . . . . . . . . . . . . . . . .
54
.
55
. . . . . . . . . . . . . . . . .
56
. . . . . . . . . . .
56
5.5
. . . . . . . . . . . . . . . . .
57
5.6
Screenshot: FPS Tests mit vielen Clients
. . . . . . . . . . . . . . . . . .
58
5.7
Messung: Bilder pro Sekunde bei steigender Client Anzahl
. . . . . . . .
59
5.8
Messung: Wahrnehmung von steigender Latenz . . . . . . . . . . . . . . .
60
6.1
Screenshot: Weniger aufwändige Avatare können für eine bessere Framerate sorgen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
61
7.1
Aufbau eines Ethernet Paketes, Quelle: http://de.wikipedia.org/wiki/Ethernet 65
7.2
Screenshot: Stendhal, Quelle: http://arianne.sourceforge.net/screens/stendhal/20050605stendh
7.3
Stern Architektur in Netzwerken, Quelle: http://de.wikipedia.org/wiki/Switch
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
69
8.1
Screenshot: Lobby Client . . . . . . . . . . . . . . . . . . . . . . . . . . .
71
8.2
72
8.3
73
8.4
74
76
[1] Bericht über die Game Developer Converence 2005, Version: November 2006
http://www.heise.de/tp/r4/artikel/20/20776/1.html
[2] Online
Gaming.
Markets
to
2007.
The
New
Growth
Opportunities,
Version
November 2006 https://www.markt-studie.de/studien/onlinespiele-marktausblick2007-online-gaming-markets-2007-growth-opportunities-inh-2741.html
[3] Casual
games
-
good,
clean,
cheap
fun
online
Version
November
2006
http://www.cnn.com/2006/TECH/fun.games/02/28/casual.games/
[4] Game Programming Gems edited by Mark DeLoura - erschienen 2000 im Charles
River Media Verlag ISBN: 1-58450-049-2
[5] 3D Spiele Programmierung von David Scherfgen - erschienen 2004 im Hanser Verlag
ISBN: 3-3446-22869
[6] The
Nebula
Device:
What
ist
the
Nebula
2
Device?
Version
Januar
2007
http://nebuladevice.cubik.org/what-is-n2/
[7] The
Nebula
Device
2:
Engine
Version
Januar
2007
Details
http://www.devmaster.net/engines/engine-details.php?id=69
[8] The
Rakknet
Multiplayer
Network
Engine
Version
Januar
2007
http://www.rakkarsoft.com
[9] Wikipedia: Ethernet, März 2007 http://de.wikipedia.org/wiki/Ethernet
[10] Tecchannel:
Ethernet
Grundlagen
und
Co,
März
2007
http://www.tecchannel.de/netzwerk/grundlagen/431828/
[11] Tecchannel:
Ethernet
im
Überblick,
http://www.tecchannel.de/netzwerk/grundlagen/401674/
77
März
2007
[12] Wikipedia: LAN, März 2007 http://de.wikipedia.org/wiki/LAN
[13] Wikipedia: Hub, März 2007 http://de.wikipedia.org/wiki/Hub
[14] Wikipedia: http://de.wikipedia.org/wiki/TokenRing
[15] ItWissen: Denition LAN, März 2007 http://www.itwissen.info/denition/lexikon/lanlanlanlocal
[16] Wikipedia: Programmbibliothek, März 2007 http://de.wikipedia.org/wiki/Library
[17] Studie: EA Games - Spielplatz Deutschland, Typologie der Spieler; März 2007
http://publish.electronic-arts.de/publish/page204280515468314.php3
[18] Gert Fischer, Lineare Algebra 13 Auage - erschienen Juli 2002 im Vieweg Verlag
ISBN: 3-528-97217-3
[19] Studie: Computer und Videospiele - Einstellungen und Nutzungsverhalten in
Deutschland, Frankreich und Groÿbritannien; März 2007 http://publish.electronicarts.de/publish/page204280515468314.php3
78
Erklärung
Ich versichere hiermit, dass ich die Arbeit selbstständig verfasst, keine anderen, als
die angegebenen Hilfsmittel verwendet und die Stellen, die anderen Werken im Wortlaut
oder dem Sinne nach entnommen sind, mit Quellenangaben kenntlich gemacht habe.
Dies gilt auch für Zeichnungen, Skizzen, Notenbeispiele, Ton- und Bildträger sowie bildliche Darstellungen.
Ort, Datum
Johannes Bufe
79

Examensarbeit

Transcription

Similar documents

Gelaendespiel-2015 - Kirchenkreisjugenddienst

Spezialisten seit 1984 - VONI

SUMMERFLAME - Србија PORTRAIT – MARTIN

Evil-Twin-Accesspoint - Chair of Network Architectures and Services

Mediadaten - SwissClassics Revue

Matrix - Filmmusikanalyse

Wirtschaftswandel statt Kosmetik

400 ParkPro PistenBully 400 ParkPro Kreativität und Perfektion im

SQL Server 2008 R2 - Administration - HERDT

Turtle Entertainment GmbH ESL Eltern Begrüßung Sehr

© 1999 Innonics Publishing und Distributions GmbH, Hannover. Alle

Junge Frauen haben keine Ahnung (stern.de)