Analyse von Entwurfsmustern in Mehrbenutzerspielen

Transcription

Bachelorarbeit
Analyse von Entwurfsmustern in
Mehrbenutzerspielen
von
Thomas Jarmer
Liegnitzer Strasse 6
65779 Kelkheim
(Matrikel 6074359)
angefertigt am
Lehrgebiet Praktische Informatik VI
-Verteilte SystemeProf. Dr. Jörg Haake
der FernUniversität Hagen
Betreuer:
Dr. Till Schümmer
Oktober 2006
Hiermit versichere ich, dass ich diese Arbeit selbstständig verfasst
und keine anderen als die angegebenen Quellen und Hilfsmittel benutzt sowie Zitate kenntlich gemacht habe.
Frankfurt, im Oktober 2006
Datum
Unterschrift
Inhaltsverzeichnis
Abbildungsverzeichnis
v
Tabellenverzeichnis
viii
1. Einleitung
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2. Aufgabenstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1
1
2. Grundlagen
2.1. Entwurfsmuster . . . . . . . . . . . . . . . . . . .
2.2. Mehrbenutzerspiele . . . . . . . . . . . . . . . . .
2.2.1. Charakteristika von Mehrbenutzerspielen
2.2.2. Mehrbenutzerspieltypen . . . . . . . . . .
2.3. Pattern Mining . . . . . . . . . . . . . . . . . . .
2.4. Theoretischer Ansatz . . . . . . . . . . . . . . . .
.
.
.
.
.
.
3
3
5
5
6
8
9
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
14
14
15
18
18
18
20
22
23
23
26
27
28
30
31
31
32
33
35
3. Analyse der Benutzerschnittstelle
3.1. Auswahl der Spiele . . . . . .
3.2. Analysierte Spiele . . . . . . .
3.3. Ergebnisse der Analyse . . . .
3.3.1. Abbreviation . . . . .
3.3.2. Active Map . . . . . .
3.3.3. Attention Screen . . .
3.3.4. Away Message . . . .
3.3.5. Buddy List . . . . . .
3.3.6. Embedded Chat . . .
3.3.7. Emote . . . . . . . . .
3.3.8. Interactive User Info .
3.3.9. Invitation . . . . . . .
3.3.10. Local Awareness . . .
3.3.11. Login . . . . . . . . .
3.3.12. Navigation . . . . . .
3.3.13. User List . . . . . . .
3.3.14. Virtual Me . . . . . .
3.4. Zusammenfassung . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4. Analyse der Quelltexte
4.1. Auswahl der Spiele . . . .
4.2. Analysierte Spiele . . . . .
4.3. Ergebnisse der Analyse . .
4.3.1. Active Map . . . .
4.3.2. Buddy List . . . .
4.3.3. Embedded Chat .
4.3.4. Invitation . . . . .
4.3.5. Login . . . . . . .
4.3.6. Mediated Updates
4.3.7. User List . . . . .
4.3.8. What’s up . . . . .
4.3.9. Who’s that girl . .
4.4. Zusammenfassung . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5. Neue Entwurfsmuster
5.1. Automatic Software Update
.
5.2. Blind Date
. . . . . . . . . . . .
5.3. Name Generator
. . . . . . . . .
5.4. Navigator
. . . . . . . . . . . . .
5.5. Role Indicator
. . . . . . . . . .
5.6. Spectator
. . . . . . . . . . . . .
5.7. Waiting Queue
. . . . . . . . . .
5.8. Known Uses in seriösen Anwendungen
5.9. Zusammenfassung . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
39
39
40
40
41
42
45
47
48
49
50
50
51
51
.
.
.
.
.
.
.
.
.
58
58
62
66
70
74
77
81
84
85
6. Zusammenfassung
88
Literaturverzeichnis
89
A. Liste der Entwurfsmuster aus P4CMI
91
Inhaltsverzeichnis
iv
2.1.
2.2.
2.3.
2.4.
Netzwerkstruktur von MMOGs. . . . . . . . . . . . . . . . . . . . . . . .
Netzwerkstruktur von MUGs und TBGs. . . . . . . . . . . . . . . . . . .
Abbildung zwischen PL1 und PL2, die weder injektiv noch surjektiv ist.
Bijektive Abbildung zwischen den einelementigen Teilmengen P Lx und
P Ly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.5. Monomorphe Abbildung von der Menge PLT auf die Menge PL1 . . . .
3.1.
3.2.
3.3.
3.4.
3.5.
3.6.
3.7.
. 7
. 7
. 10
. 11
. 12
Abbreviation in Guild Wars. . . . . . . . . . . . . . . . . . . . . . . . .
Active Map in Counter Strike Source. . . . . . . . . . . . . . . . . . . .
Active Map mit Landschaftdetails in Guild Wars. . . . . . . . . . . . . .
Active Map in World of Warcraft. . . . . . . . . . . . . . . . . . . . . .
Ignore List in World of Warcraft. . . . . . . . . . . . . . . . . . . . . . . .
Attention Screen in Everquest 2. . . . . . . . . . . . . . . . . . . . . .
Ein Spieler wird in Dungeon & Dragons Online über den Wechsel in den
afk -Status informiert. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.8. Benutzerdefinierte Away Message in Anarchy Online. . . . . . . . . . .
3.9. Visualisierung der Abwesenheit eines Spielers in Star Wars Galaxies. . . .
3.10. Buddy List in World of Warcraft. . . . . . . . . . . . . . . . . . . . . . .
3.11. On- und Offline-Buddies werden in Guild Wars getrennt angezeigt. . . . .
3.12. Embedded Chat in Star Wars Galaxies: Unten befindet sich das Eingabefeld und darüber die Ausgabe. . . . . . . . . . . . . . . . . . . . . . . .
3.13. Farblich Abhebung von unterschiedlichen Chat-Nachrichtentypen in World
of Warcraft. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.14. Filterung von Chat-Nachrichten mit Checkboxen in Guild Wars. . . . . .
3.15. Visualisierung von Emote in Ragnarok Online. . . . . . . . . . . . . . . .
3.16. Unterschiedliche Emotes in Guild Wars: a) die Spielfigur krümmt sich
vor Lachen b) die Spielfigur klopft sich auf den Schenkel c) die Spielfigur
gähnt. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.17. In World of Warcraft werden in dem Embedded Chat zusätzliche Informationen zu Emote angezeigt. . . . . . . . . . . . . . . . . . . . . . . . .
3.18. In Everquest 2 wird die Interactive User Info über die Spielfigur
aufgerufen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.19. Interactive User Info in Guild Wars. . . . . . . . . . . . . . . . . . .
3.20. In Guild Wars werden Mitspieler über ein Plus-Zeichen in eine Gruppe
eingeladen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.21. Ein Spieler in Ragnarok Online erhält eine Einladung in eine Gruppe . . .
18
19
20
20
21
21
22
22
23
24
24
25
25
26
26
27
27
28
28
29
29
3.22. Zwei Spieler aus dem gleichen Team kooperieren in Counter Strike Source,
nachdem sie sich gegenseitig durch Local Awareness wahrgenommen
haben. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.23. Login-Fenster in Dungeons & Dragons Online. . . . . . . . . . . . . . .
3.24. User List in Unreal Tournament 2004. . . . . . . . . . . . . . . . . . .
3.25. User List in World of Warcraft. . . . . . . . . . . . . . . . . . . . . . .
3.26. Erstellen der Spielfigur in Guild Wars. . . . . . . . . . . . . . . . . . . .
3.27. Kleidungsstücke in Guild Wars verändern das Aussehen der Spielfigur. .
3.28. 2D-Grafik der Spielfigur in World of Warcraft. . . . . . . . . . . . . . .
3.29. Ein Virtual ME im Inventarfenster von Guild Wars. . . . . . . . . . .
3.30. Beziehungen zwischen den identifizierten Entwurfsmustern . . . . . . . .
.
.
.
.
.
.
.
.
.
30
31
32
33
34
35
35
36
37
Active Map in BZFlag . . . . . . . . . . . . . . . . . . . . . . . . . . .
Objekte für die Erzeugung der Active Map in BZFlag . . . . . . . . .
Interaktionsdiagramm für die Buddy List in Planeshift . . . . . . . . .
Planeshift - Embedded Chat Klassendiagramm . . . . . . . . . . . . . .
Erzeugen einer Chat-Nachricht in Quake 3 Arena . . . . . . . . . . . . .
Interaktionsdiagramm zu Invitation von Planeshift. . . . . . . . . . . .
Login-Fenster in Planeshift . . . . . . . . . . . . . . . . . . . . . . . . .
Klassendiagram für das Pattern Login von Planeshift . . . . . . . . . .
Interaktionsdiagramm zur Verteilung von Chat-Nachrichten über Mediated Updates in Quake 3 Arena . . . . . . . . . . . . . . . . . . . . . .
4.10. Erzeugen einer User List in Planeshift . . . . . . . . . . . . . . . . . .
4.11. Identifizierung eines Clients in Planeshift anhand der IP-Adresse . . . .
4.12. Identifizierung des Autors der Nachricht in Quake 3 Arena anhand der
Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.13. Beziehungen zwischen den identifizierten Entwurfsmustern. . . . . . . .
.
.
.
.
.
.
.
.
41
42
43
45
46
53
54
54
5.1. Automatic Software Upate in Guild Wars. . . . . . . . . . . . . . .
5.2. Automatic Software Upate in Entropia Universe. . . . . . . . . . .
5.3. Ein Meeting Stone als Implementierung einer Meeting Area in dem Spiel
World of Wacraft . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.4. Name Generator in Anarchy Online. . . . . . . . . . . . . . . . . . .
5.5. Name Generator in Star Wars Galaxies. . . . . . . . . . . . . . . . .
5.6. Navigator in Everquest 2. . . . . . . . . . . . . . . . . . . . . . . . . .
5.7. Navigator in Star Wars Galaxies. . . . . . . . . . . . . . . . . . . . . .
5.8. In World of Warcraft werden Gruppenleiter mit einer Krone am Avatar
visualisiert. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.9. Spectator in Counter StrikeSource. . . . . . . . . . . . . . . . . . . . .
5.10. In Guild Wars können Spieler Meisterschaften beobachten. . . . . . . . .
5.11. Waiting Loop in World of Warcraft. . . . . . . . . . . . . . . . . . . .
5.12. Konfiguration des Microsoft Windows Update. . . . . . . . . . . . . . .
5.13. Konfiguration von Automatic Software Update in Firefox. . . . . .
5.14. Konfiguration von Automatic Software Update in Thunderbird. . .
. 60
. 61
4.1.
4.2.
4.3.
4.4.
4.5.
4.6.
4.7.
4.8.
4.9.
. 55
. 56
. 56
. 57
. 57
.
.
.
.
.
65
68
69
72
72
.
.
.
.
.
.
.
75
79
80
83
84
85
86
vi
5.15. Realisierung von Name Generator in der Internetauktionsplattform Ebay. 87
5.16. Waiting Queue in einem Portal für Computerspiele. . . . . . . . . . . . . 87
vii
Tabellenverzeichnis
2.1. Zusätzliche Beschreibungslemente eines Entwurfsmusters in P4CMI. . . .
2.2. Die Charakteristiken der einzelnen Spieltypen. . . . . . . . . . . . . . . .
4
8
3.3. Charakteristische Eigenschaften der analysierten Spiele. . . . . . . . . . . 17
3.5. Identifizierte Entwurfsmuster anhand der Benutzerschnittstelle. . . . . . . 38
4.2. Identifizierte Entwurfsmuster anhand der Quelltexte. . . . . . . . . . . . . 52
1. Einleitung
1.1. Motivation
Die Spielbranche hat in den letzten Jahren enorme Zuwächse zu verzeichnen. Das ist
insbesondere den Mehrbenutzerspielen zu verdanken, die sich einer großen Beliebtheit
erfreuen. Durch sie werden Computerspiele solchen Zielgruppen nähergebracht, die bisher kein oder wenig Interesse an diesem Medium hatten [Die06]. Die Spielbranche hat
mittlerweile andere etablierte Wirtschaftsbereiche, wie zum Beispiel die Filmindustrie,
was den jährlichen Umsatz und Gewinn betrifft, überholt [Rau05]. Die Entwicklung von
Computerspielen zählt damit zu einem ernstzunehmenden Wirtschaftsbereich.
Trotzdem besteht immer noch ein Graben zwischen der Entwicklung von seriösen
Anwendungen und der Entwicklung von Computerspielen. Die Philosophie beider Welten
scheint nach wie vor unvereinbar zu sein. Diese Arbeit versucht den Graben zu verringern,
in dem sie mit Hilfe von Entwurfsmustern zeigt, dass es sehr wohl Gemeinsamkeiten
zwischen diesen vermeintlich völlig unterschiedlichen Bereichen gibt.
1.2. Aufgabenstellung
Im Rahmen dieser Bachelorarbeit sollen Entwurfsmuster anhand von Mehrbenutzerspielen analysiert werden. Als Referenz ist hierfür, die von T. Schümmer und S. Lukosch
entwickelte Pattern Language P4CMI1 [SLht] seitens der seriösen Anwendungen vorgegeben. Zu beachten ist hierbei, dass die Pattern Language sich während der Erstellung
dieser Arbeit noch in Entwicklung befand. Die fertige Version dieser Pattern Language
wird deshalb von der hier verwendeten Version abweichen. Aus diesem Grund werden
im Anhang alle Namen der Entwurfsmuster und ihr Zweck aufgeführt.
Zu den Zielen dieser Arbeit gehören zum einen die Identifizierung von Entwurfsmustern aus P4CMI in Mehrbenutzerspielen und zum anderen das Auffinden neuer Entwurfsmuster in Mehrbenutzerspielen, wobei diese wiederum im gleichen Kontext wie die
Entwurfsmuster aus P4CMI anwendbar sein müssen.
Im nächsten Kapitel werden zunächst fachliche Begriffe wie Entwurfsmuster und Pattern Mining erörtert. Außerdem werden Mehrbenutzerspiele kategorisiert. Schließlich
wird eine Theorie vorgestellt, die mit den Ergebnissen dieser Arbeit bewiesen werden
soll. In Kapitel 3 werden Entwurfsmuster, die in Spielen identifiziert worden sind, gemeinsam mit den Known Uses (vgl. Abschnitt 2.1) beschrieben. Anschließend wird der
gleiche Prozess wiederholt, dann allerdings mit dem Quellcode von Mehrbenutzerspielen.
1
Patterns for Computer Mediated Interaction
Die Ergebnisse werden am Ende jedes Kapitels kurz diskutiert. Danach werden die im
Rahmen der Analyse gefundenen Entwurfsmuster in der Form, wie sie in P4CMI beschrieben sind, präsentiert. Zum Schluss wird noch ein Ausblick auf weitere Forschungsansätze
im Kontext von Mehrbenutzerspielen und Entwurfsmuster gegeben.
1. Einleitung
2
2. Grundlagen
2.1. Entwurfsmuster
Ursprünglich stammt die Idee der Entwurfsmuster von dem Architekten Christopher
Alexander. Im Kontext seiner Arbeiten zur Stadtplanung und zur Konstruktion von
Gebäuden entwickelte er den Begriff des Entwurfsmusters, das er wie folgt definiert:
Each pattern describes a problem that occurs over and over again in our environment
an then describes the core of the solution to that problem in such a way that you can use
this solution a million times over without ever doing it the same way twice.[Ale77]
Auch wenn Softwareentwicklung bei weitem nicht so lange praktiziert wird, wie die
Konstruktion von Gebäuden oder die Planung von Städten, so hat doch die Komplexität dieses Prozesses das Bedürfnis geweckt, nach Methoden zu suchen, die diese Komplexität beherrschbarer machen. Im Schlepptau des objektorientierten Paradigmas und
dem damit verbundenen Wunsch nach wiederverwendbaren Quellcode, wurde die Idee
Alexanders von vier objektorientierten Software-Entwicklern, die man auch als GOF1
bezeichnet, aufgegriffen, um sie im Kontext von Softwareentwicklung einzusetzen und
die Wiederverwendbarkeit nicht nur auf eine abstraktere Ebene zu heben, sondern auch
im Sinne einer gezielten Problemlösung zu verwenden. Heute steht es außer Zweifel,
dass durch den Schritt der GOF die Welt der Softwareentwicklung nachhaltig verändert
wurde. Entwurfsmuster gibt es in der Entwicklung von Software in nahezu jedem Bereich sowie auf unterschiedlichen Abstraktionsebenen. Russel nennt in [Cor98] drei unterschiedliche Kategorien von Entwurfsmustern:
– sprachspezifische Entwurfsmuster (idioms)
– Entwurfsmuster (Design Patterns)
– architektonische Muster (High-Level Design Patterns)
Sprachspezifische Entwurfsmuster geben die Lösung eines Problems in einer bestimmten Sprache an. Als Beispiele für Entwurfsmuster dieser Art nennt Russel das C++
Orthodox Canonical Class Form idiom und das Handle/body class idiom von J. Coplien
[Cop92]. Die Form der Entwurfsmuster entsprechen der Form, wie sie von der GOF in
[GHJV97] beschrieben werden. Im Gegensatz zu den sprachspezifischen Mustern sind
diese prinzipiell unabhängig von einer konkreten Sprache, wobei es nicht ausgeschlossen ist, dass die Implementierung je nach Entwurfsmuster in einer bestimmten Sprache
1
Gang of Four: Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides
Element
opener
intent
scenario
symptoms
solution
collaboration
rationale
check
danger spots
known uses
related patterns
Inhalt
Ein Bild, welches das Entwurfsmuster illustriert.
Das Ziel, welches mit dem Entwurfsmuster verfolgt wird
bzw. der Zweck des Entwurfsmusters.
Ein praktisches Beispiel für Laien.
Typische Anzeichen, die darauf hindeuten, dass das Pattern
angewendet werden sollte.
Lösung für das Problem.
Beschreibung des Ablaufs der Lösung.
Eine Begründung, weshalb das Entwurfsmuster eine Lösung
für das Problem darstellt.
Implementierungsaspekte, die mit der Anwendung des Entwurfsmusters zusammenhängen, aber über den Kern des
Problems hinausgehen.
Probleme, die auftreten können, wenn man das Entwurfsmuster implementiert.
Anwendungen, die das Entwurfsmuster implementieren.
Andere Entwurfsmuster, die mit diesem in irgendeiner Form
in Beziehung stehen.
Tabelle 2.1.: Zusätzliche Beschreibungslemente eines Entwurfsmusters in P4CMI.
leichter fällt. Auf der abstraktesten Ebene befinden sich die architektonischen Entwurfsmuster, die man auch als High-Level Design Patterns bezeichnet. Beispiele hierfür sind
das Entwurfsmuster MVC und die in P4CMI beschriebenen Entwurfsmuster.
Die Form der Beschreibung eines Entwurfsmusters ist nicht beliebig. Alexander hat
bereits in [Ale79] neben dem Namen des Entwurfsmusters hierfür folgende Elemente
festgelegt:
– Context
– System of Forces (die in dem Kontext auftreten)
– Configuration (die diese Kräfte auflöst)
Der Kontext stellt den Bereich, in dem das Entwurfsmuster angewandt werden kann,
dar. In unserem Fall ist zum Beispiel das Mehrbenutzerspiel ein Kontext. Die System
of Forces sind die Probleme oder Symptome, die es zu lösen gilt und eine bestimmte
Konfiguration führt zur Auflösung dieser Forces und wird dementsprechend in Entwurfsmustern durch das Element Lösung dargestellt.
Diese Elemente entsprechen einer minimalen Beschreibung eines Entwurfsmusters.
Sie wird häufig durch andere Elemente erweitert. Entwurfsmuster in P4CMI werden
zusätzlich durch Elemente beschrieben, die in Tabelle 2.1 aufgelistet sind.
2. Grundlagen
4
Fasst man eine Menge von Entwurfsmustern, die alle den gleichen Kontext haben
zusammen, dann erhält man eine Pattern Language.
2.2. Mehrbenutzerspiele
2.2.1. Charakteristika von Mehrbenutzerspielen
Gegenstand der Untersuchungen in dieser Arbeit sind neben Entwurfsmuster Mehrbenutzerspiele in elektronischer Form.
Ein Mehrbenutzerspiel wird hierbei als ein Computerspiel definiert, in dem mindestens zwei Personen, von jeweils unterschiedlichen Rechner aus, miteinander interagieren
können. Nach Zagal et al. unterscheiden sich Mehrbenutzerspiele durch sechs charakteristische Eigenschaften von Einzelbenutzerspielen [ZNR00], wobei zu beachten ist, dass
diese Eigenschaften nicht nur für elektronische Spiele gelten:
– Soziale Interaktion
– Wettstreit and Kooperation
– Synchronität
– Koordination
– Abhängigkeit von Eigenschaft und Hilfsmittel
– Existenz eines Meta-Spiels.
Zagal et al. teilen den Grad der sozialen Interaktion in drei Bereiche ein: Mehrbenutzerspiele die ohne soziale Interaktion auskommen, Mehrbenutzerspiele mit starker
Interaktion, sowie Mehrbenutzerspiele in denen soziale Interaktion möglich, aber nicht
zwingend notwendig ist. Zu welchem Bereich ein Mehrbenutzerspiel zählt, hängt nach
Zagal et al. von den Spielregeln, den Eigenschaften und Hilfsmitteln des Spiels ab. Dabei entsprechen die Benutzeroberfläche den Eigenschaften und die Funktionalität den
Hilfsmitteln des Mehrbenutzerspiels. Weiterhin unterscheiden Zagal et al. zwischen stimulierter und natürlicher sozialer Interaktion, wobei stimulierte soziale Interaktion durch
Spielregeln hervorgerufen wird und natürliche soziale Interaktion spontan während eines
Spiels entsteht.
Wettstreit und Kooperation ist die zweite genannte charakteristische Eigenschaft.
Spiele, in denen die Spieler konkurrieren zeichnen sich durch Gewinner und Verlierer aus,
wohingegen kooperative Spiele durch das Erreichen eines gemeinsamen Ziels bestimmt
werden. Kooperation und Wettstreit schließen sich nicht gegenseitig aus. Spiele können
gleichzeitig konkurrenzbetont und kooperativ sein, wenn die Spieler in Teams gegeneinander antreten. Für die Analyse haben Spiele, in denen Kooperation gefordert wird,
eine größere Bedeutung, da dadurch die Interaktion zwischen den Spielern gefordert wird,
was wiederum die Wahrscheinlichkeit einer Implementierung eines Entwurfsmusters aus
P4CMI erhöht.
2. Grundlagen
5
Die Synchronität, die dritte charakteristische Eigenschaft, beschreibt den Ablauf eines
Spiels. Zagal et al. definieren drei verschiedene Formen der Synchronität. Ein Spiel ist
nebenläufig, falls alle Spieler gleichzeitig am Spiel teilnehmen müssen und parallel Aktionen ausführen können. Das gleiche gilt für synchrone Spiele, allerdings kann zu einem
Zeitpunkt nur ein Spieler Aktionen ausführen. Dann gibt es noch die asynchronen Spiele,
wo die Spieler nicht zur gleichen Zeit am Spiel teilnehmen müssen, sondern unabhängig
von der Präsenz anderer Spieler ihre Aktionen ausführen können.
Die Koordination beschreibt, wer den Ablauf eines Spiels kontrolliert. Bei zentral koordinierten Spielen liegt die Kontrolle bei einem Spieler oder Computer, und bei verteilt
koordinierten Spielen wird die Kontrolle auf mehrere oder alle Teilnehmer verteilt.
Der vorletzte Punkt beschreibt, inwieweit ein Spiel von den Eigenschaften des Spiels
(wie zum Beispiel Farbe und Größe eines Spielgegenstands) und dem Hilfsmittel (zum
Beispiel ein Computer) abhängig ist. Diese Eigenschaft ist für uns dahingehend nebensächlich, da das Hilfsmittel in unserem Fall immer ein Computer ist.
In Mehrbenutzerspielen können Meta-Spiele bestehen. Meta-Spiele zeichnen sich dadurch aus, dass sie zwar parallel zu einem Spiel mit einem definierten Regelwerk auf
einem informellen Level ablaufen, aber trotzdem für den Ablauf eines Spiels entscheidend sind. Zagal et al. nennen das Bluffen beim Pokern als ein solches Meta-Spiel. Diese
Eigenschaft wurde bei keinem der Spiele festgestellt und hat insofern keine Relevanz für
die Analyse.
2.2.2. Mehrbenutzerspieltypen
Aktuelle Mehrbenutzerspiele lassen sich in folgende Typen einordnen:
– MMOG2
– MUG3
– TBG4
MMOGs zählt derzeit wohl zur populärsten Art der Mehrbenutzerspiele. Es handelt
sich hierbei um reine Online-Spiele, dass heißt die Spieler müssen sich via Internet mit einem zentralen Server, der in der Regel von dem Hersteller bereitgestellt wird, verbinden,
um an einem Spiel teilzunehmen (siehe Abbildung 2.1).
Die Dauer eines Spiels ist offen, da es vom Regelwerk her kein definiertes Ende gibt.
Außerdem läuft ein Spiel rund um die Uhr, und die Spieler haben die Wahl, dem Spiel
beizutreten oder es wieder zu verlassen, unabhängig von der Präsenz anderer Mitspieler.
Der Spielstand eines Spielers wird über die Abmeldung hinaus gespeichert. Kooperation
wird in dieser Art von Spielen häufig belohnt, ist aber für den Ablauf des Spiels nicht
zwingend notwendig. Das gleiche gilt auch für die Wettkämpfe zwischen den Spielern.
2
Massive Multiplayer Online Game
Multi User Game
4
Turn-Based Game
3
2. Grundlagen
6
Abbildung 2.1.: Netzwerkstruktur von MMOGs.
MUGs sind Computerspiele, die sowohl alleine, als auch gemeinsam mit anderen Personen gespielt werden können. Im Gegensatz zu den MMOGs können Spieler nicht nur
über das Internet, sondern auch in lokalen Netzwerken miteinander spielen. Zwar wird
auch in MUGs ein Spiel über einen zentralen Server koordiniert, dieser wird aber in der
Regel von einem der Mitspieler gehostet (siehe Abbildung 2.2).
Abbildung 2.2.: Netzwerkstruktur von MUGs und TBGs.
Die Spiele sind immer konkurrenzbetont, können bei Team-Spielen aber auch kooperativ sein. Die Spieler sind immer auf die Anwesenheit anderer Spieler angewiesen, weshalb
MUGs zu den nebenläufigen Spielen zählen.
2. Grundlagen
7
Charakteristik
soziale Interaktion
Synchronität
Wettstreit und Kooperation
Koordination
MMOG
möglich
asynchron
beides
zentral
MUG
möglich
nebenläufig
beides
zentral
TBG
möglich
synchron
Wettstreit
dezentral
Tabelle 2.2.: Die Charakteristiken der einzelnen Spieltypen.
TBGs sind nichts anderes als MUGs. Sie werden aber deshalb getrennt von den MUGs
erwähnt, weil sie sich von den übrigen MUGs in zwei Charakteristiken klar unterscheiden. Zum einen sind sie nicht nebenläufig, sondern synchron, denn Spieler können nicht
gleichzeitig agieren. Sie müssen ihre Aktionen nacheinander ausführen. Zum anderen
ist das Spiel aus diesem Grund dezentral. Jeder Spieler kann, sobald er am Zug ist,
entscheiden, wann er seine Aktionen abschließt und das Spiel fortgeführt wird.
Die Charakteristiken aller Spieltypen sind nochmal in Tabelle 2.2 zusammengefasst.
Hier sieht man auch, dass es derzeit keine kommerziellen Mehrbenutzerspiele gibt, in
denen soziale Interaktion zwingend vorausgesetzt wird.
2.3. Pattern Mining
Die Entwurfsmuster in Kapitel 5 sind die Ergebnisse eines Prozesses, den man als Pattern
Mining bezeichnet. Genauer gesagt, handelt es sich hierbei um die gezielte Suche nach
neuen Entwurfsmustern, wobei diese Suche stets im Rahmen eines bestimmten Kontextes
erfolgt.
Entwurfsmuster lassen sich auf verschiedene Weise ausgraben. Adrian E. DeLano
nennt hierzu sechs Typen von Pattern Mining und teilt sie in die folgenden drei Kategorien ein [DeL98]:
– persönliche Beiträge
. persönliche Beiträge basierend auf Fachwissen
. persönliche Beiträge basierend auf Erfahrung
– fremde Beiträge
. Graben nach fremden Beiträgen in Interviews mit Experten
. Graben nach fremden Beiträgen in den Erfahrungen von anderen
. Graben als Unterstützer nach fremden Beiträgen
– Pattern Mining Workshop
Bei den persönlichen Beiträgen sind der Autor des Entwurfsmusters und die Quelle des
Entwurfsmusters dieselbe Person. Während Beiträge basierend auf Fachwissen als Quelle
2. Grundlagen
8
den Autor des Entwurfsmusters besitzen, weiten Beiträge,die auf Erfahrung basieren, die
Suche auf Kollegen des Autors aus.
Die fremden Beiträgen zeichnen sich dadurch aus, dass Autor und Quelle des Entwurfsmusters unterschiedliche Personen sind. Bei dem ersten Typ dieser Kategorie werden
Experten, bei denen man entsprechendes Wissen vermutet, interviewt und anschließend
die Entwurfsmuster aus den Aufzeichnungen extrahiert. Bei dem zweiten Typ dieser Kategorie dienen im Prinzip alle Personen, mit denen der Entwurfsmusterausgrabende in
Kontakt kommt, als Quelle für ein neues Entwurfsmuster. Diese Methode hat im Gegensatz zu allen anderen Typen von Pattern Mining einen zufälligen Charakter. Die letzte
Methode der fremden Beiträge besteht darin, dass ein Entwurfsmusterausgrabender einer anderen Person, die meint selbst ein Entwurfsmuster gefunden zu haben, bei der
Bergung des Entwurfsmusters hilft.
Die dritte und letzte Kategorie ist auch gleichzeitig die letzte Methode des Pattern
Mining. Im Pattern Mining Workshop wird eine Gruppe von Personen, die alle eine gemeinsames Basiswissen besitzen, dass für das Pattern Mining erfolgversprechend scheint,
gemeinsam mit einem Moderator und ein oder mehreren Entwurfsmusterausgrabenden
versammelt. Diejenigen, die die Entwurfsmuster ausgraben wollen, sind lediglich Zuhörer
und notieren, was die Gruppe unter der Leitung des Moderators diskutiert. Eventuell
wird nach dem Workshop der ein oder andere Teilnehmer nochmal interviewt, falls für
die Entwurfsmusterausgrabenden noch Fragen offen sind. Anschließend werden so weit
möglich die Entwurfsmuster aus den Aufzeichnungen extrahiert.
In dieser Arbeit wurde eine Methode verwendet, die nicht eindeutig einer der genannten Typen von Pattern Mining zuzuordnen ist. Und zwar wurden die Anwendungen
dahingehend analysiert, ob sie eine Funktion oder ein Feature besitzen, welches die
Lösung eines Problems bezüglich des Kontextes von P4CMI darstellt. Das Auffinden
einer derartigen Funktion führte dann zu einer Suche nach weiteren Known Uses und
der anschließenden Formulierung des Entwurfsmusters, wie sie in Kapitel 5 aufgeführt
sind.
Man kann aber die Anwendung als Wissen eines Experten interpretieren. Dieser Experte stellt ein fremde Person dar. Deshalb können wir unsere Methode zwar nicht einem
der genannten Typen, aber dennoch der Kategorie fremde Beiträge zuordnen.
2.4. Theoretischer Ansatz
In Abschnitt 1.1 wurde angedeutet, dass die Welt der seriösen Anwendungen und die
Welt der Computerspiele voneinander lernen bzw. profitieren können. Hier soll diese Idee
anhand einer Theorie konkretisiert werden.
Wir nehmen an, dass zwischen den Entwurfsmustern beider Welten ein Homomorphismus besteht. Um festzustellen, ob diese Vermutung zutrifft, vergleichen wir zunächst
zwei Pattern Languages aus den beiden Welten miteinander. Als Pattern Language für
die Welt der seriösen Anwendungen wird die bereits in der Aufgabenstellung erwähnte
P4CMI verwendet. Aus Mangel an Alternativen wird sie mit der Pattern Language aus
2. Grundlagen
9
[Bjö04] verglichen, die wir der Einfachheit halber im weiteren mit PIGD bezeichnen wollen. PIGD beinhaltet im Gegensatz zu P4CMI eine vereinfachte Form der Beschreibung
von Entwurfsmustern. So werden die in jeder Pattern Language üblichen Problem und
Solution Beschreibungen, wenn dann nur implizit, in Core Definition genannt. Außerdem
haben sich unter den Entwurfsmustern in PIGD auch Klassifikationen gemischt, denn
einige der dort aufgeführten Entwurfsmuster wie Single-Player Games und MultiPlayer Games sind eher Klassifikationen als Entwurfsmuster im eigentlichen Sinne.
Trotzdem halten wir aus genanntem Grund an dieser Pattern Language fest, werden sie
aber aufgrund der Defizite später durch eigene Entwurfsmuster aufwerten.
Betrachten wir die beiden Pattern Languages, so stellen wir fest, dass auf beiden
Seiten Entwurfsmuster existieren, die in der jeweils anderen Pattern Language nicht
vorkommen (siehe Abbildung 2.3).
Abbildung 2.3.: Abbildung zwischen PL1 und PL2, die weder injektiv noch surjektiv
ist.
So existiert zum Entwurfsmuster Embedded Chat kein Pendant in PIGD und umgekehrt kein vergleichbares Entwurfsmuster von Luck aus PIGD in P4CMI. Somit kann
weder eine injektive noch surjektive Abbildung zwischen beiden Mengen von Entwurfsmustern bestehen. Ein Homomorphismus zwischen P4CMI und PIGD wäre damit entgegen unserer Vermutung zunächst einmal widerlegt.
Auch wenn kein Homomorphismus zwischen beiden Pattern Languages besteht, so
können wir immer noch annehmen, dass zwischen Teilmengen der Pattern Languages
eine homomorphe Abbildung existiert. Da die kleinste Teilmenge, die hierfür in Frage
kommt, die einelementige Menge ist, reicht es aus, zwei Entwurfsmuster zu finden, die
aufeinander abgebildet werden können.
Entwurfsmuster die diese Eigenschaft besitzen, sind Virtual Me aus P4CMI und
Avatars aus PIGD. So wird Virtual Me in P4CMI folgendermaßen beschrieben:
Create a virtual representation of the users’ self that is seen by other users before
”
and during interaction.“
und Avatars in PIGD:
2. Grundlagen
10
The players are represented as personalized Avatars in Massively Multiplayer Online
”
Roleplaying Games . . .“
Beide Entwurfsmuster beschreiben demnach die Repräsentation des Anwenders durch
ein Objekt in der virtuellen Welt. Da sowohl Avatars auf Virtual Me abgebildet werden kann, also auch umgekehrt Virtual Me auf Avatars, ist die Abbildung zwischen
den beiden einelementigen Mengen bijektiv und wir erhalten den vermuteten Homomorphismus in Form einer isomorphen Abbildung (siehe Abbildung 2.4).
Abbildung 2.4.: Bijektive Abbildung zwischen den einelementigen Teilmengen P Lx und
P Ly .
Da uns der Isomorphismus bezüglich der einelementigen Mengen nicht signifikant genug erscheint, ändern wir den Vergleich zwischen beiden Welten insofern ab, dass wir
die Entwurfsmuster, die in Kapitel 5 beschrieben werden, hinzunehmen und sie in einer neuen Pattern Language PLT zusammenfassen. Die Menge dieser Entwurfsmuster
bezeichnen wir mit PT . Ferner sei P1 die Menge der Entwurfsmuster von P4CMI und
P2 die Menge der Entwurfsmuster von PIGD. Da die Entwurfsmuster aus PLT für die
Kontexte von CMI5 und Mehrbenutzerspiele gelten, kann man die Mengen von P1 und
P2 auf folgende Weise erweitern:
P1 := P1 ∪ PT
P2 := P2 ∪ PT
5
Computer Mediated Interaction
2. Grundlagen
11
Da nun gilt:
∀p ∈ PT : p ∈ P1 ∧ p ∈ P2 ⇒ PT 7→ P1 ∧ PT 7→ P2 sind injektiv
∃p ∈ P1 ∧ ∃p ∈ P2 : p ∈
/ PT ⇒ PT 7→ P1 ∧ PT 7→ P2 nicht surjektiv
haben wir einen weiteren Homomorphismus, denn die Abbildung zwischen PLT und
den anderen beiden Pattern Languages is monomorph (siehe Abbildung 2.5).
Abbildung 2.5.: Monomorphe Abbildung von der Menge PLT auf die Menge PL1
Das es einen Homomorphismus zwischen den Entwurfsmustern beider Welten gibt, haben wir bewiesen. Gilt dies auch für Beziehungen zwischen Entwurfsmustern? Wir wollen
hier nur den Fall diskutieren, dass eine Beziehung von P4CMI nach PIGD abgebildet
werden kann.
Sei die Menge RP der in Beziehungen stehenden Entwurfsmustern innerhalb einer
Menge P wie folgt:
RP := {(pi , pj )|pi , pj ∈ P ∧ pi related pj }
dann sprechen wir von einer starken Beziehung, wenn gilt:
(pi , pj ) ∈ RP1 ∧ pi ∈ P2 ⇒ pj ∈ P2
und von einer schwachen Beziehung wenn gilt:
(pi , pj ) ∈ RP1 ∧ pi ∈ P2 ⇒ pj ∈
/ P2
Um zu zeigen, dass starke Beziehungen existieren, erweitern wir PIGD durch Entwurfsmuster aus P4CMI, die anhand von Known Uses in Mehrbenutzerspielen identifiziert
2. Grundlagen
12
werden können. Im folgenden Kapitel beginnen wir die Identifikation durch die Analyse
der Benutzerschnittstellen von Mehrbenutzerspielen und führen anschließend den gleichen Prozess mit der Analyse des Quelltextes von Mehrbenutzerspielen durch. Am Ende
des Kapitels diskutieren wir dann die Ergebnisse.
Abschließend soll noch die Frage beantwortet werden, welcher Vorteil durch die Kenntnis über einen vorhandenen Homomorphismus gewonnen wird. Identifiziert man nämlich
ein Entwurfsmuster aus dem Bereich der seriösen Anwendungen anhand von Known Uses
in Mehrbenutzerspielen, dann lässt sich daraus schlussfolgern, dass dort auch die gleichen
Forces bestehen wie in dem Bereich der seriösen Anwendungen. Das bedeutet wiederum, dass wenn man diese Forces in anderen Spielen vorfindet, dort auch das gleiche
Entwurfsmuster anwenden kann.
Dafür ist es aber wie bereits erwähnt erforderlich, nachzuweisen, dass auch in den
Mehrbenutzerspielen die gleichen Forces vorhanden sind. Da die PIGD die Forces nicht
explizit beschreibt, kann jedoch an dieser Stelle nicht näher auf diesen Aspekt eingegangen werden.
2. Grundlagen
13
3.1. Auswahl der Spiele
Bei der Auswahl der Spiele wurde darauf geachtet, dass mindestens ein Spiel zu jedem
in Kapitel 2.2.2 genannten Typ gehört. Es wurde auch Wert auf die Aktualität der
Spiele gelegt. Von den charakteristischen Eigenschaften aus Kapitel 2.2.1 waren nicht
alle erwünscht. Spiele ohne soziale Interaktion wurden beispielsweise nicht berücksichtigt,
weil dort weniger Entwurfsmuster gefunden wurden. Die Anforderungen ließen sich zum
Teil nicht immer erfüllen. So musste bei der Auswahl von TBGs auf deren Aktualität
verzichtet werden. Ob die fehlende Aktualität bei den TBGs die Ursache für die gerade
dort besonders geringe Anzahl an identifizierten Entwurfsmustern ist, kann nur vermutet
werden. Der Vollständigkeit halber sollen sie aber trotzdem erwähnt werden. Zu den
charakteristischen Eigenschaften aller analysierten Spiele findet man eine Übersicht in
Tabelle 3.3, am Ende dieses Kapitels.
Bevor wir zu den Ergebnissen der Analyse kommen, soll noch erwähnt werden, dass es
sich bei aktuellen MMOGs zum großen Teil um MMORPGs1 handelt [KLXH04]. Bei den
hier analysierten MMOGs handelt es sich sogar ausnahmslos um MMORPGs. Deshalb
werden wir den Begriff MMORPG im folgenden synonym für MMOG verwenden.
1
Massive Multiplayer Online Roleplaying Game
3.2. Analysierte Spiele
Spiel
Beschreibung
Bei Anarchy Online handelt es sich um ein MMORPG [Fun01]. Das
Spiel ist asynchron. Es müssen demnach nicht alle Spieler gleichzeitg an
einem Spiel teilnehmen. Soziale Interaktion ist ebenfalls möglich, wird
aber nicht vorausgesetzt. Die Koordination erfolgt über einen Server und
ist daher zentriert. Kooperation entsteht zum einen dadurch, dass der
Spieler sich einer von zwei verfeindeten Fraktionen anschließen kann. Die
Spieler einer Fraktion kämpfen gemeinsam gegen die Spieler der anderen Fraktion, wodurch das Spiel auch konkurrenzbetont wird. Außerdem
können die Aufgaben von den Spielern gemeinsam in einer Gruppe gelöst
werden, was wiederum kooperativ ist.
Carcasonne [Koc04] ist die elektronische Umsetzung des gleichnamigen
Brettspiels. Das Spiel ist ein TBG. Die Spieler können über ein lokales
Netzwerk oder via Internet gegen andere Spieler antreten. Die Koordination ist, trotz der Durchführung über einen zentralen Server, dezentral,
da ein Spieler der aktuell am Zug ist, entscheidet wann er seinen Zug
bestätigt und das Spiel damit fortgesetzt wird. Das Spiel ist konkurrenzbetont und kooperativ. Soziale Interaktion ist möglich, jedoch nicht
zwingend notwendig.
Counter Strike Source ist ein MUG [Val05]. Soziale Interaktion ist
möglich, jedoch nicht zwingend notwendig. Das Spiel läuft über einen
Server, weshalb die Koordination zentriert ist. Da Teams gegeneinander
antreten ist das Spiel konkurrenzbetont und kooperativ. Der Ablauf des
Spiels ist nebenläufig.
Dungeon & Dragons Online zählt zu den MMORPGs [Tur06]. Der Ablauf des Spiels ist asynchron. Soziale Interaktion ist möglich, aber nicht
zwingend notwendig. Das Spiel ist kooperativ, da die Spieler gemeinsam
Aufgaben lösen können. Außerdem ist die Koordination zentriert, da die
Steuerung über einen zentralen Server erfolgt.
Bei Everquest 2 handelt es sich um ein MMORPG [Son04]. Das Spiel
ist asynchron und die Koordination ist zentriert. Das Spiel ist darüber
hinaus konkurrenzbetont, da die Spieler gegeneinander kämpfen oder die
Aufgaben gemeinsam lösen können. Soziale Interaktion ist möglich, aber
nicht zwingend notwendig.
15
Spiel
Beschreibung
Entropia Universe2 [Min03] ist ein MMORPG. Die Koordination ist zentriert und der Ablauf des Spiels ist asynchron. Es ist das einzige Spiel mit
einer Real Cash Economy. Dass heißt, die Währung im Spiel wird von
dem Hersteller und Betreiber in reale Währung umgetauscht und umgekehrt. Das fördert den Handel und die soziale Interaktion innerhalb des
Spiels, trotzdem wird soziale Interaktion nicht zwingend vorausgesetzt.
Spieler können Teams bilden und kollaborieren.
Guild Wars [Are05] ist ein MMORPG. Soziale Interaktion ist möglich
aber nicht notwendig. Das Spiel selbst besteht aus zwei Teilen. Der Rollenspielteil ist kooperativ, da Spieler gemeinsam Aufgaben lösen können.
In dem konkurrenzbetonten und kooperativen Teil, treten die Spieler wie
Counter Strike Source in Teams gegeneinander an Der Rollenspielteil ist
asynchron und der Teamspielteil ist nebenläufig. Das Spiel läuft über
einen Server und ist damit zentral koordiniert.
Ragnarok Online [Gra04] ist ein koreanisches MMORPG. Soziale Interaktion ist möglich, aber nicht zwingend notwendig. Gruppen oder Gilden
fördern die Kooperation von Spielern. Durch einen Server wird das Spiel
zentral koordiniert. Der Spielverlauf ist asynchron.
Scrabble [Ubi03] ist ein TBG, welches das gleichnamige Gesellschaftsspiel in eine elektronische Version umsetzt. Einer der Spieler hostet das
Spiel. Da das Spiel aber synchron ist, ist die Koordination dezentral. Die
Spieler können nur konkurrieren. Eine Kollaboration ist nicht möglich.
Star Wars Galaxies [Son03] ist ein MMORPG. Soziale Interaktion ist
möglich, wird jedoch nicht vorausgesetzt. Der Spielverlauf ist asynchron
und wird von einem Server zentral koordiniert. Die Spieler können in
Gruppen kooperieren.
Unreal Tournament 2004 [Epi04] ist ein MUG. Die Spieler können via
LAN oder Internet in Teams oder einzeln konkurrieren. Hierbei ist soziale Interaktion möglich aber nicht zwingend notwendig. Das Spiel wird
immer zentral von einem Server koordiniert und der Spielverlauf ist synchron. Das Spiel ist grundsätzlich konkurrenzbetont, aber durch den
Team-Modus auch kooperativ.
World of Warcraft [Bli06] ist ein MMORPG. Das Spiel erlaubt eine soziale Interaktion, setzt diese aber nicht voraus. Die Spieler können in
Gruppen oder Gilden kollaborieren. Durch so genannte Duelle zwischen
einzelnen Spielern ist das Spiel aber auch konkurrenzbetont. Koordiniert wird World of Warcraft durch einen zentralen Server. Das Spiel ist
asynchron.
2
ehemals Project Entropia
16
17
beides
beides
zentral
zentral
zentral
zentral
MMOG
asynchron
möglich
Kollaboration
Entropia
Universe
zentral
MMOG
asynchron
möglich
Kollaboration
Everquest
2
zentral
MMOG
asynchron
möglich
Kollaboration
Guild
Wars
zentral
MMOG
asynchron
möglich
Kollaboration
TBG
synchron
möglich
Konkurrenzbetont
verteilt
Ragna- Scrabrok
ble
Online
Tabelle 3.3.: Charakteristische Eigenschaften der analysierten Spiele.
verteilt
möglich
möglich
Kollaboration
MMOG
asynchron
MUG
synchron
TBG
nebenläufig
möglich
Spieltyp
Synchronität
Soziale Interaktion
Konkurrenzbetont
Kollaboration
Koordination
Carcas- Counter Dungeon
sonne
Strike
& DraSource
gons
Online
MMOG
asynchron
möglich
beides
Anarchy
Online
Entwurfsmuster
zentral
MMOG
asynchron
möglich
beides
Star
Wars
Galaxies
zentral
MUG
nebenläufig
möglich
beides
Unreal
Tournament
2004
zentral
MMOG
asynchron
möglich
beides
World
of
Warcraft
3.3. Ergebnisse der Analyse
Im folgenden werden die Ergebnisse der Analyse der Benutzerschnittstellen beschrieben. Dabei werden die identifizierten Entwurfsmuster in alphabetischer Reihenfolge aufgezählt. Zu jedem Entwurfsmuster wird zunächst dessen Zweck beschrieben. Anschließend werden die Spiele, bei denen das Entwurfsmuster gefunden wurde, sowie die Besonderheiten und Unterschiede der Implementierungen besprochen. Als Beleg werden
Screenhots, die während der Ausführung eines Spiels angefertigt wurden, verwendet.
3.3.1. Abbreviation
Der Zweck des Entwurfsmusters Abbreviation ist es, den Aufwand, der mit der textuellen Kommunikation verbunden ist, durch Abkürzungen oder übliche Phrasen zu reduzieren.
Abbreviation ist eines der wenigen Entwurfsmuster, die in allen Spielen identifiziert
werden konnten. Die Voraussetzung für Abbreviaton ist das Entwurfsmuster Embedded Chat (vgl. Abschnitt 3.3.6), das deshalb auch in allen Spielen identifiziert werden
konnte.
Neben den Abkürzungen wie imo 3 , die man aus der seriösen“Anwendungswelt kennt,
”
fällt bei der Analyse auf, dass sich offensichtlich neben den bekannten Abkürzungen auch
spielspezifische Abkürzungen entwickelt haben.
In Guild Wars zum Beispiel können sich Spieler gegenseitig zu whispern4 . Dadurch
können sich Spieler gegenseitig private Chat-Nachrichten senden. Es kommt häufig vor,
dass Spieler, die von anderen Spielern angeflüstert werden wollen, wsp abkürzend für
whispern verwenden (siehe Abbildung 3.1).
Abbildung 3.1.: Abbreviation in Guild Wars.
3.3.2. Active Map
Der Zweck des Entwurfsmusters Active Map ist die skalierte grafische Darstellung des
Anwendungsraumes. Zusätzlich soll diese Karte mit Bewusstseinsinformationen gefüllt
werden.
3
4
Abgekürzt für: in my opinion
deutsch: flüstern
18
Active Map wird bis auf Unreal Tournament 2004 und Anarchy Online von allen
anderen analysierten Spielen implementiert. Alle Implementierungen erlauben es dem
Spieler über die Active Map Positionen von Objekten, wie die Spielfiguren der Mitspieler, erkennen zu können.
Die eigene Position befindet sich stets in der Mitte der Karte und wird häufig durch
einen kleinen Pfeil symbolisiert. Die Spitze des Pfeils zeigt in die Blickrichtung der Spielfigur. Die Karte stellt einen kleinen Ausschnitt der Spielwelt, innerhalb eines bestimmten
Radius um die Spielfigur herum, dar. Bei einigen Spielen kann die Active Map auf
Wunsch des Spielers ein- und ausgeblendet werden.
Die einfachste Implementierung ist zweifelsfrei die von Counter Strike Source (siehe
Abbildung 3.2).
Abbildung 3.2.: Active Map in Counter Strike Source.
Der Spieler erhält hier lediglich Informationen über die Position seiner Teammitglieder.
Die Teammitglieder werden auf der Karte durch Punkte in der Teamfarbe visualisiert.
Zusätzlich wird das Gebiet, in dem sich der Spieler innerhalb der virtuellen Umgebung
befindet, unterhalb der Active Map in textueller Form angezeigt.
Da ein Spielfeld in Counter Strike Source FPS-typisch5 klein ist und in wenigen Minuten komplett erkundet werden kann, ist die Darstellung von mehr Details nicht notwendig.
Im Gegensatz zu MUGs, braucht ein Spieler von MMORPGs häufig Monate um die
virtuelle Welt mit der Spielfigur zu erkunden. Dies ist auch der Grund, warum die
Implementierungen von Active Map hier zum Teil wesentlich detaillierter ausfallen.
In Guild Wars, Dungeons & Dragons Online, Ragnarok Online und World of Warcraft
können Spieler auf der Karte Wiesen, Hügel, Seen, Wege und weitere landschaftlichen
Details der Spielwelt erkennen (siehe Abbildung 3.3).
Dies bietet dem Spieler zusätzliche Orientierungsmöglichkeiten. Noch einen Schritt
weiter geht World of Warcraft. Objekte wie Städte, die zu weit vom Aufenthaltsort der
eigenen Spielfigur entfernt sind, und deshalb nicht mehr innerhalb des Ausschnitts in der
Active Map dargestellt werden können, werden durch einen Pfeil am Rand der Active
Map visualisiert. Der Spieler kann dadurch erkennen in welche Richtung er sich bewegen
muss, um zu diesem Objekt zu gelangen (siehe Abbildung 3.4).
5
First Person Shooter
19
Abbildung 3.3.: Active Map mit Landschaftdetails in Guild Wars.
Abbildung 3.4.: Active Map in World of Warcraft.
Damit der Spieler auch erfährt, um welche Stadt es sich jeweils handelt, wird der
Name der Stadt eingeblendet, sobald der Spieler die Maus über den zugeordneten Pfeil
bewegt (siehe Abbildung 3.4).
In Dungeons & Dragons Online, Ragnarok Online, Star Wars Galaxies und World of
Warcraft lässt sich der Ausschnitt, den die Active Map von der virtuellen Welt zeigt,
in circa 3-4 Stufen vergrößern bzw. verkleinern. In World of Warcraft gibt es hierfür
zwei Buttons am unteren rechten Rand, die mit einem + und - Zeichen versehen sind
(siehe Abbildung 3.4). Bei langen Reisen durch die virtuelle Umgebung erhält der Spieler
mit einem größeren Ausschnitt einen besseren Überlick, wohingegen in kleinen Höhlen
oder Burgen ein kleiner Ausschnitt für mehr Übersicht sorgt. Der Spieler hat so die
Möglichkeit die Active Map an die jeweilige Spielsituation anzupassen.
3.3.3. Attention Screen
Der Zweck dieses Entwurfsmusters ist festzulegen, wer oder was die Aufmerksamkeit des
Anwenders in Anspruch nehmen darf.
Dieses Entwurfsmuster findet man in den Spielen Guild Wars, Star Wars Galaxies,
World of Warcraft, Ragnarok Online und Everquest 2 implementiert. Jedes der drei erst
genannten Spiele verwendet für Attention Screen ein Oberflächenelement, welches
nahezu identisch mit der jeweils implementierten Buddy List (vgl. 3.3.5) ist. In World
of Warcraft und Star Wars Galaxies wird diese Liste auch Ignore List genannt (siehe
Abbildung 3.5).
Ein Spieler kann nach belieben Namen von Mitspielern dieser Liste hinzufügen bzw.
20
Abbildung 3.5.: Ignore List in World of Warcraft.
entfernen. Der ignorierende Spieler bekommt keine direkte Chat-Nachricht von einem
dieser Spieler zugestellt. Die Nachricht wird, nachdem der ignorierte Spieler sie gesendet
hat, von dem Server nicht zugestellt.
Alle anderen Interaktionen, die direkt zwischen zwei Spielern ausgeführt werden können,
wie der Handel von Gegenständen, eine Aufforderung zum Duell und die Einladung in
eine Gruppe, bleiben von der Ignore List unberührt.
Die gleiche Funktionalität bietet Ragnarok Online seinen Spielern. Der Spieler muss
sich hier allerdings damit begnügen, die Block List, welche den oben genannten Ignore
Lists entspricht, via Chat-Befehl zu verwalten.
Die Entwickler von Star Wars Galaxies gehen noch einen Schritt weiter. Der Spieler
kann in Star Wars Galaxies nicht nur bestimmte andere Spieler ignorieren. Es lassen sich
außerdem Interaktionen unabhängig vom Mitspieler unterbinden (siehe Abbildung 3.6).
Der Spieler kann zum Beispiel entscheiden, ob er generell über Einladungen zu einem
Duell benachrichtigt werden soll.
Abbildung 3.6.: Attention Screen in Everquest 2.
21
3.3.4. Away Message
Das Entwurfsmuster Away Message hat den Zweck aktive Anwender darüber zu informieren, dass sie Antworten auf ihre Nachfragen verspätet erreichen werden.
In den analysierten MMORPGs Anarchy Online, Dungeons & Dragons Online, Everquest 2, Guild Wars, Star Wars Galaxies und World of Warcraft wird Away Message
implementiert. Bei diesen Spielen wird der Status des Spielers durch das Ausführen des
Chat-Befehls afk auf abwesend gesetzt. Bei World of Warcraft wird der Spieler automatisch in den Status afk versetzt, wenn in einem vorgegebenen Zeitintervall keine Eingabe
von der Maus oder der Tastatur erfolgt.
Um den Status aufzuheben, reicht es bei nahezu allen Spielen aus, wenn von dem
Spieler eine Eingabe über Maus oder Tastatur ausgeführt wird. In einigen Spielen wie
Guild Wars ist es allerdings notwendig, die Spielfigur zu bewegen (vgl. Abschnitt 3.3.12)
und in Anarchy Online wird der Status durch eine zweite Ausführung des Befehls afk
aufgehoben. Eine spezielle Nachricht im Chat-Ausgabetextfeld informiert den Spieler
über den erfolgten Wechsel in den afk -Status (siehe Abbildung 3.7).
Abbildung 3.7.: Ein Spieler wird in Dungeon & Dragons Online über den Wechsel in
den afk -Status informiert.
Sendet ein Spieler einem Mitspieler, der sich im afk -Status befindet, eine Nachricht,
informiert ihn das Spiel mit der schlichten Aussage, dass sich der Adressat im afk -Status
befindet. Anarchy Online bietet als einziges Spiel darüber hinaus die Möglichkeit, den
Antwort-Text selbst festzulegen (siehe Abbildung 3.8).
Abbildung 3.8.: Benutzerdefinierte Away Message in Anarchy Online.
Spielfiguren in World of Warcraft und Star Wars Galaxies werden zusätzlich mit dem
Text afk versehen, so lange sich der Spieler im Status afk befindet (siehe Abbildung 3.9).
22
Abbildung 3.9.: Visualisierung der Abwesenheit eines Spielers in Star Wars Galaxies.
3.3.5. Buddy List
Die Buddy List hat den Zweck, ausschließlich ausgewählte bekannte Anwender anzuzeigen.
Buddy Lists sind bei allen Spielen, sowohl bei den MUGs als auch bei den MMORPGs, implementiert. Jede Buddy List zeigt mindestens den Nickname des Spielers und
seinen Online-Status an. In Unreal Tournament 2004 und Counter Strike Source sind die
Buddy Lists nicht direkt im Spiel integriert. Das heißt, der Spieler kann nicht während
einer Session auf die Buddy List zugreifen, sondern muss sich zuerst aus der Session
ausloggen und kann dann über das Hauptmenü des Spiels die Buddy List aufrufen.
Während alle anderen Implementierungen über die Buddy List den Start von Interaktionen mit dem Buddy erlauben, lassen sich in Unreal Tournament 2004 lediglich die
oben genannten Informationen, wie Nickname und Status abrufen.
World of Warcraft und Everquest 2 zeigen dem Spieler, falls dessen Buddy online ist,
zusätzlich seinen Aufenthaltsort innerhalb der virtuellen Welt an. Allein in World of
Warcraft erhält der Spieler weitere Informationen wie die Klasse des Charakters und
welche Erfahrungsstufe er bis jetzt erreicht hat (siehe Abbildung 3.10).
In Everquest 2 und Star Wars Galaxies lassen sich die Buddies mit dem Status offline
aus der Buddy List herausfiltern. Counter Strike Source und Guild Wars zeigen Onund Offline-Buddies grundsätzlich getrennt voneinander in der Buddy List an (siehe
Abbildung 3.11).
Wie weiter oben bereits erwähnt, können Spieler Interaktionen über die Buddy List
starten. Alle Spiele unterstützen das Versenden einer Nachricht an einen Buddy. In
Dungeons & Dragons Online und World of Warcraft können Spieler den Buddy in eine
Gruppe einladen (siehe Abbildung 3.10).
Nur Ragnarok Online verlangt von einem Mitspieler die Erlaubnis, bevor ein anderer
Spieler ihn zu seiner Buddy List hinzufügen kann.
3.3.6. Embedded Chat
Der Zweck des Entwurfsmusters Embedded Chat ist es, dem Anwender eine synchrone
Kommunikation mit einfacher Technikunterstützung zu ermöglichen. Im Gegensatz zu
23
Abbildung 3.10.: Buddy List in World of Warcraft.
Abbildung 3.11.: On- und Offline-Buddies werden in Guild Wars getrennt angezeigt.
einem gewöhnlichen Chat ist der Embedded Chat, wie der Name schon sagt, in der
Anwendung direkt integriert und keine eigenständige Anwendung.
In [SLht] werden zwei Textfelder für die Implementierung von Embedded Chat vorgeschlagen. Ein Textfeld für die Eingabe der Nachricht und ein zweites für die Ausgabe der
Nachrichten. Diesem Prinzip folgen alle hier aufgeführten Spiele mit ihrer Implementierung des Embedded Chats. Ein Beispiel hierzu ist in Abbildung 3.12 zu sehen.
Die Teilnahme von hunderten von Spielern in MMORPGs führt in Embedded Chats
zu einer sehr großen Menge an Nachrichten. Um diese Menge an Informationen für den
Spieler handhabbar zu machen, wenden die Entwickler ähnliche Strategien an.
Bei der ersten Strategie gehen die Entwickler davon aus, dass zwischen Spielern mit
großer räumlicher Distanz innerhalb der virtuellen Umgebung, der Wunsch nach Kommunikation gering ist. Deshalb werden die Adressaten von Nachrichten grundsätzlich
nach Gebieten unterteilt, was bedeutet, dass Spieler nur Nachrichten von Spielern aus
dem selben Gebiet erhalten. In World of Warcraft und Anarchy Online gehen die Entwickler noch einen Schritt weiter. Wenn ein Spieler eine Nachricht mittels des Befehls
24
Abbildung 3.12.: Embedded Chat in Star Wars Galaxies: Unten befindet sich das
Eingabefeld und darüber die Ausgabe.
say sendet, erhalten nur Spieler in unmittelbarer Umgebung die Nachricht. Möchte ein
Spieler aber dennoch die Nachricht an alle Spieler in seinem Gebiet senden, muss er
den Befehl yell verwenden. Weitere Ausnahmen sind Gruppen-Nachrichten oder direkte
Chat-Nachrichten. Beide Nachrichten werden unabhängig vom Aufenthaltsort der Spieler
zugestellt.
Eine andere Strategie ist die farbliche Unterscheidung von unterschiedlichen Nachrichtenarten. In World of Warcraft werden zum Beispiel Nachrichten, die direkt an einen
Spieler adressiert sind, in violettem Text angezeigt. Gruppennachrichten hingegen haben
die Farbe blau und Systemnachrichten gelb (siehe Abbildung 3.13).
Abbildung 3.13.: Farblich Abhebung von unterschiedlichen Chat-Nachrichtentypen in
World of Warcraft.
Außerdem wird in allen Spielen der Adressat und der Sender der Chat-Nachricht vorangestellt. In Abbildung 3.13 kann man dadurch erkennen, dass sich die letzte Nachricht
an eine Gruppe richtet, die in World of Warcraft mit Party bezeichnet wird.
Die genannten Strategien reichen aber für Gebiete, in denen sich viele Spieler aufhalten nicht aus, da das Nachrichtenaufkommen hier immer zu hoch ist. Deshalb bieten
alle Embedded Chats einen zusätzlichen Filter an, der es ermöglicht bestimmte Typen
von Nachrichten auszublenden. In Guild Wars lässt sich ganz einfach über Checkboxen oberhalb des Ausgabetextfeldes festlegen, ob das Ausgabefenster Team-Nachrichten,
Gilde-Nachrichten etc. ausgeben soll oder nicht (siehe Abbildung 3.14).
Die MUGs Unreal Tournament 2004 und Counter Strike Source implementieren hinge-
25
Abbildung 3.14.: Filterung von Chat-Nachrichten mit Checkboxen in Guild Wars.
gen nur eine sehr einfache Ausgabe für den Embedded Chat. In Counter Strike Source
ist die Ausgabe auf sechs Zeilen limitiert, bei Unreal Tournament 2004 sind es sogar nur
vier Zeilen. Außerdem fehlt bei beiden Spielen ein Scrollbalken, um alte Nachrichten zu
einem späteren Zeitpunkt noch einmal lesen zu können.
3.3.7. Emote
Der Zweck des Entwurfsmusters Emote ist es, dem Spieler die Darstellung von Emotionen zu ermöglichen.
Bis auf die Ego-Shooter Unreal Tournament 2004 und Counter Strike Source implementieren alle anderen Spiele dieses Entwurfsmuster. Bei Ragnarok Online werden zur
Visualisierung von Emotionen Luftblasen oder Bilder mit Text oberhalb der Spielfigur
visualisiert (siehe Abbildung 3.15).
Abbildung 3.15.: Visualisierung von Emote in Ragnarok Online.
In allen anderen MMORPGs werden die Emotionen durch Animationen der Spielfigur
dargestellt. Dabei sind die Animationen denen von realen Menschen nachempfunden.
Führt ein Spieler in Guild Wars die Emotion lachen aus, dann krümmt sich die Spielfigur
vor lachen und klopft sich dabei auf die Schenkel (siehe Abbildung 3.16). Möchte der
Spieler zeigen, dass er müde ist, führt er das Emote gähnen aus, wodurch die Spielfigur
sich streckt, den Mund öffnet und gleichzeitig die Hand davor hält (siehe Abbildung
3.16).
In Dungeons & Dragons Online, Everquest 2, Guild Wars, Star Wars Galaxies und
World of Warcraft werden, neben den Animationen der Spielfiguren, Emotionen durch
eine Nachricht im Embedded Chat (vgl. 3.3.6) angezeigt. Richtig sinnvoll ist diese Methode, wenn sie wie in Dungeons & Dragons Online, Everquest 2, Star Wars Galaxies
und World of Warcraft Emotion und Objekte in Zusammenhang bringt. Als Beispiel
26
Abbildung 3.16.: Unterschiedliche Emotes in Guild Wars: a) die Spielfigur krümmt
sich vor Lachen b) die Spielfigur klopft sich auf den Schenkel c) die Spielfigur gähnt.
sei hier kurz die Begrüßung eines Mitspielers erwähnt. Startet der Spieler diese Aktion,
beginnt die Spielfigur zu winken. Mitspieler können nun zwar erkennen, dass der Spieler winkt, befinden sich in diesem Moment jedoch mehrere Mitspieler in unmittelbarer
Umgebung, ist eine eindeutige Zuordnung schwierig. Um dieses Problem zu lösen, kann
man in World of Warcraft, sowie auch in den anderen genannten Spielen, bevor man eine
Aktion ausführt, die Spielfigur eines Mitspielers markieren. In dem Embedded Chat
wird dann die Aktion mit der markierten Spielfigur im Zusammenhang gebracht (siehe
Abbildung 3.17).
Abbildung 3.17.: In World of Warcraft werden in dem Embedded Chat zusätzliche
Informationen zu Emote angezeigt.
3.3.8. Interactive User Info
Der Zweck des Interactive User Info Entwurfsmusters ist es, Informationen über
andere Anwender durch deren Benutzerrepräsentation aktivierbar zu machen, und sie
mit Mitteln zur Kommunikation und Kollaboration zu verknüpfen.
Dieses Entwurfsmuster wird von dem Großteil der MMORPGs angewendet. Entropia
Universe, Everquest 2, Ragnarok Online und Star Wars Galaxies verwenden zur Interactive User Info ein Kontextmenü, dass sich durch Rechtsklick auf die Spielfigur
öffnen lässt (siehe Abbildung 3.18).
In Dungeons & Dragons Online, Guild Wars und World of Warcraft erscheint, nach-
27
Abbildung 3.18.: In Everquest 2 wird die Interactive User Info über die Spielfigur
aufgerufen .
dem man die Spielfigur eines anderen Spielers angeklickt hat, an anderer Stelle eine
Repräsentation des Spielers. Die Repräsentation ist entweder der Nickname des Spielers,
ein Bild des Kopfes seiner Spielfigur oder beides (siehe Abbildung 3.19).
Abbildung 3.19.: Interactive User Info in Guild Wars.
Nicht alle Spiele bieten über die Interactive User Info Kommunikation und Kollaboration an. In Ragnarok Online kann der Spieler einen 1:1-Chat darüber starten. In
Dungeons & Dragons Online und Guild Wars lässt sich zwar keine Kommunikation über
die Interactive User Info starten, dafür aber die Einladung in eine Gruppe und der
Austausch von Gegenständen (siehe Abbildung 3.19).
Nur die beiden Spiele Everquest 2 und World of Warcraft bieten sowohl Kommunikation als auch Kollaboration über die Interactive User Info an (siehe Abbildung
3.18).
3.3.9. Invitation
Das Entwurfsmuster Invitation hat den Zweck, dass Anwender Interaktionen mit anderen Anwendern planen können.
In den MUGs Unreal Tournament 2004 und Counter Strike Source wird dieses Entwurfsmuster nicht implementiert. Zwar können Spieler dort ein Spiel starten und andere
28
Spieler können diesen Spielen beitreten. Die Spiele bieten jedoch keine Möglichkeit ausgesuchte Mitspieler explizit zu dem gestarteten Spiel einzuladen.
In den MMORPGs können Spieler Gruppen bilden. Ein Spieler oder eine Gruppe
können andere Spieler in eine Gruppe einladen. Bei den Spielen Dungeons & Dragons
Online, Everquest 2, Star Wars Galaxies und World of Warcraft erfolgt die Einladung
über die Interactive User Info (vgl. 3.3.8). In World of Warcraft kann die Einladung
auch über die Buddy List erfolgen (vgl. 3.3.5). Bei Ragnarok Online kann die Einladung
auch über einen Chat-Befehl ausgeführt werden, in Anarchy Online und Guild Wars
hingegen über ein Team-Widget (siehe Abbildung 3.20). Der Spieler muss zunächst die
betreffende Spielfigur per Mausklick auswählen, anschließend wird die Einladung über
einen Button im Team-Widget ausgelöst.
Abbildung 3.20.: In Guild Wars werden Mitspieler über ein Plus-Zeichen in eine
Gruppe eingeladen.
Sobald ein Spieler eine Einladung versendet hat, erscheint bei dem eingeladenen Spieler ein Meldung, in der er über die Einladung informiert wird. Dort wird neben der
Einladung der Nickname des Einladenden angezeigt. Der Eingeladene Spieler hat dann
die Wahl, die Einladung anzunehmen oder abzulehnen (siehe Abbildung 3.21). Dieser
Ablauf ist bei allen Spielen bis auf visuelle Details identisch.
Abbildung 3.21.: Ein Spieler in Ragnarok Online erhält eine Einladung in eine Gruppe
29
3.3.10. Local Awareness
Das Entwurfsmuster Local Awareness hat den Zweck Bewusstseinsinformationen in
dem Kontext von Artefakten bereitzustellen, die sich im Fokus des lokalen Anwenders
befinden. Dies hört sich zunächst einmal sehr kompliziert an. Im Grunde genommen ist
damit nichts anderes gemeint, als dass der Anwender über Aktivitäten anderer Anwender, deren Kontext mit seinem im Zusammenhang stehen, informiert werden soll, so dass
eine spontane Kollaboration möglich wird.
Die Implementierung dieses Entwurfsmusters in Spielen erschließt sich nicht auf den
ersten Blick, da dessen Vorhandensein sich erst durch eine Spielsituation ergibt. Ein erstes Beispiel hierzu: Nimmt in Counter Strike Source ein Spieler einen anderen Mitspieler
in der Active Map war, weiß er, dass es sich dabei um ein Mitglied seines Teams handeln muss. Da er nun die Position des Mitspielers kennt, kann er sich zu diesem Spieler
bewegen, so dass er dessen Aktivitäten innerhalb der Spielwelt wahrnehmen kann. Da
sich beide Spieler bewusst sind, dass ihre Aktivitäten den gleichen Kontext besitzen,
nämlich das Besiegen des gegnerischen Teams, werden sie spontan kollaborieren, in dem
sie zum Beispiel gemeinsam vorrücken, wie in Abbildung 3.22 zu erkennen ist.
Abbildung 3.22.: Zwei Spieler aus dem gleichen Team kooperieren in Counter Strike
Source, nachdem sie sich gegenseitig durch Local Awareness wahrgenommen haben.
Ein zweites Beispiel aus dem Spiel World of Warcraft: Spieler erhalten an fest definierten Stellen Aufgaben, deren Lösung die Weiterentwicklung der Spielfigur ermöglicht. In
der Regel führen unterschiedliche Aufgaben die Spieler an unterschiedliche Orte. Wenn
ein Spieler sich nun an einen Ort begibt, um dort eine Aufgabe zu lösen, wird er dort
Spieler vorfinden, die mit hoher Wahrscheinlichkeit die gleichen Ziele haben wie er. Der
Kontext der Spieleraktivitäten hängt dementsprechend vom Ort ab. Darüber hinaus
kann der Spieler die Absichten des Mitspielers durch dessen Aktivitäten deuten. Ein
Beispiel: ein Spieler wird durch eine Aufgabe an einen bestimmten Ort geführt, wo er
eine bestimmte Art von Monstern töten soll. Dort angekommen sieht er einen anderen
Spieler die Monster töten, die er für seinen Auftrag auch töten muss. Die Aktivität des
Mitspielers ist in diesem Fall das Töten der Monster. Die Artefakte sind die Monster
und der Kontext ist das Erfüllen des Auftrags.
30
3.3.11. Login
Der Zweck des Entwurfsmusters Login ist der,dass Benutzer sich selbst identifizieren
müssen, bevor sie die Anwendung benutzen können.
Bei den MUGs ist das Entwurfsmuster nicht implementiert, da die Server hier von den
Spielern selbst gestellt werden und die Daten der Sessions nicht persistent gespeichert
werden.
Die MMORPGs implementieren alle das Entwurfsmuster Login. Hier werden die Daten der Session persistent gespeichert. Die Implementierung selbst ist bis auf visuelle
Details bei allen MMORPGs identisch. Jedes Spiel fragt nach dem Start des Spiels
zunächst den Benutzernamen und Passwort ab (siehe Abbildung 3.23), bevor es den
Zugang zu der Session erlaubt.
Abbildung 3.23.: Login-Fenster in Dungeons & Dragons Online.
3.3.12. Navigation
Der Zweck des Entwurfsmusters Navigation ist es, einen Mechanismus bereitzustellen,
der es erlaubt, sich innerhalb der virtuellen Umgebung zu bewegen.
Die Bewegung von Spielfiguren ist den Computerspielen inhärent. Alle hier analysierten Spiele implementieren dieses Entwurfsmuster. In Ragnarok Online bewegt der Spieler
die Spielfigur ausschließlich mit der Maus. Dazu klickt der Spieler auf den gewünschten
Zielort, worauf sich die Spielfigur dorthin bewegt. Da die Sicht auf die virtuelle Umgebung stets auf die Spielfigur zentriert ist, bewegt sich dementsprechend auch der sichtbare
Ausschnitt der Spielwelt. Diese gilt übrigens auch für alle anderen Spiele.
Befinden sich in Ragnarok Online zwischen der aktuellen Position der Spielfigur und
dem Zielort Hindernisse, weicht die Spielfigur diesen automatisch aus.
Die meisten der analysierten Spiele setzen bei der Bewegung der Spielfiguren auf eine
Kombination von Tastatur und Maus. Dabei übernimmt die Tastatur die Bewegungen
in Form von Translation und die Maus, die der Rotation.
31
3.3.13. User List
Eine User List hat den Zweck, alle aktuell an einer Session teilnehmenden Anwender
darzustellen.
User Lists sind sowohl in den MUGs als auch in den MMORPGs implementiert.
Jedoch haben die User Lists der MUGs weniger Funktionalität als die der MMORPGs.
Dabei unterscheiden sich die User Lists der MUGs kaum voneinander. In beiden Spielen
können die User Lists per Hotkey aufgerufen werden (siehe Abbildung 3.24). Der
Spieler erfährt darin die Nicknames seiner Mitspieler, die bisher erreichte Punktzahl und
die Latenzen zum Server.
Abbildung 3.24.: User List in Unreal Tournament 2004.
Bis auf Guild Wars und Ragnarok Online bieten alle anderen MMORPGs eine User
List an. Bei Anarchy Online kann der Spieler nur über den Embedded Chat (vlg.
Abschnitt 3.3.6) die User List anschauen. Die anderen Spiele bieten dagegen ein Widget
für die User List an. Diese sind dann auch etwas komfortabler als die textbasierte User
List.
Ausgesprochen umfangreich, was die Funktionalität betrifft, ist die User List von World
of Warcraft (siehe Abbildung 3.25).
Neben dem Nickname sind weitere Informationen, wie aktueller Aufenthaltsort, gewählte
Klasse sowie erreichter Level enthalten. Die Informationen sind in Spalten angeordnet.
Die Ausgabe kann nach Spalten sortiert ausgegeben werden. Möchte der Spieler nach
gezielten Informationen suchen, gibt er in dem Textfeld unterhalb der User List den
Befehl who mit den gewünschten Argumenten ein.
Außerdem kann der Spieler über zwei Buttons Spieler direkt aus der User List seiner
Buddy List hinzufügen (vgl. 3.3.5), oder in eine Gruppe einladen (vgl. 3.3.9).
32
Abbildung 3.25.: User List in World of Warcraft.
3.3.14. Virtual Me
Der Zweck des Virtual Me ist es, eine virtuelle Repräsentation des Anwenders, die vor
und während der Interaktion von anderen Anwendern wahrgenommen werden kann, zu
bieten.
In allen hier analysierten Spielen wird der Spieler innerhalb der Spielwelt durch eine
Spielfigur repräsentiert. Den Spielfiguren sind die Nicknames, die die Spieler ausgewählt
haben zugeordnet und innerhalb der Spielwelt mit den Spielfiguren verknüpft.
Sowohl bei den MUGs als auch bei den MMORPGs kann sich der Spieler eine Spielfigur
aus einer vorgegebenen Menge an Spielfiguren auswählen. Allerdings ist bei den MUGs
die Auswahl sehr gering, und damit auch die Individualität, so dass man hier nicht von
einer Implementierung des Entwurfsmusters Virtual Me sprechen kann. In Counter
Strike Source sind es gerade mal vier Spielfiguren pro Team, aus denen sich der Spieler
eine aussuchen kann. Bei Unreal Tournament 2004 sind es mit 84 Spielfiguren zwar
deutlich mehr, aber auch hier sind die Spielfiguren von dem Spieler nicht individuell
veränderbar.
In MMORPGs hat die Gestaltung und Individualität der Spielfigur aufgrund des Rollenspielkonzepts eine besondere Bedeutung. Die Erscheinung der Spielfigur wird dabei
von den Entwicklern durch zwei unterschiedliche Konzepte beeinflusst. Das erste Kon-
33
zept erlaubt es dem Spieler beim Erstellen einer neuen Spielfigur das Aussehen auf
verschiedene Weise an seine Wünsche anzupassen (siehe Abbildung 3.26).
Abbildung 3.26.: Erstellen der Spielfigur in Guild Wars.
Häufig können die Spieler unter Rasse, Klasse und Geschlecht auswählen, wobei jede
einzelne Auswahl das Aussehen beeinflusst und die Darstellung eine Kombination der
einzelnen Auswahlmöglichkeiten ist. Daneben kann die Spielfigur durch Änderungen der
Hautfarbe, Haarfarbe, Frisur, Augenfarbe, Bartgröße und Körpergröße an die individuellen Wünsche des Spielers angepasst werden. Hat der Spieler die Auswahl bestätigt, bleibt
diese Grundform der Spielfigur über das ganze Spiel hinweg unveränderbar. Um dennoch
das Aussehen zu verändern, bleibt dem Spieler nur noch übrig, eine neue Spielfigur zu
erstellen.
Durch das zweite Konzept kann der Spieler das Aussehen der Spielfigur während des
Spiels beeinflussen. In den MMORPGs kann der Spieler die Spielfigur mit Gegenständen,
die er im Spiel gefunden, gekauft oder als Belohnung erhalten hat, ausstatten (siehe
Abbildung 3.27).
Das Repertoire reicht von Helmen, Mäntel bis hin zu Hosen und Handschuhen. Die
Möglichkeit der Kombinationen und die Anzahl der Objekte ist so groß, dass sich zwei
Spielfiguren im Prinzip nie gleichen.
Neben der Darstellung in der Spielwelt selbst, bieten die MMORPGs häufig eine
zusätzliche Visualisierung der Spielfigur als zweidimensionales Bild an (siehe Abbildung 3.28).
Wählt der Spieler eine Spielfigur mit der Maus aus, wird die Spielfigur an einer bestimmten Stelle der Oberfläche als Bild und mit zusätzlichen Informationen, wie den
Namen, visualisiert. Oft kann der Spieler über diese Darstellung Interaktionen mit dem
Mitspieler ausführen (vgl. 3.3.8).
Eine weitere Möglichkeit die Spielfigur des Spielers zu betrachten, ist das Inventaroder Charakterfenster, in dem der Spieler auch die Änderungen an der Ausstattung
vornehmen kann. Die Spielfigur wird in dem dreidimensionalen Bild, mit dem gleichen
3D-Modell wie in der Spielwelt, dargestellt (siehe Abbildung 3.29).
34
Abbildung 3.27.: Kleidungsstücke in Guild Wars verändern das Aussehen der Spielfigur.
Abbildung 3.28.: 2D-Grafik der Spielfigur in World of Warcraft.
3.4. Zusammenfassung
Wenn man die Ergebnisse der Analyse der Benutzerschnittstelle anhand der Tabelle
3.5 betrachtet, stellt man fest, dass jedes der untersuchten Spiele Entwurfsmuster von
P4CMI implementiert hat. Da jedes identifizierte Entwurfsmuster von mindestens drei
Spielen implementiert wird, haben wir genug Known Uses, um die Pattern Language
PIGD, mit diesen Entwurfsmustern zu erweitern. Mit dieser erweiterten Pattern Language und P4CMI kann jetzt auch die Frage beantwortet werden, ob es starke Beziehungen zwischen den beiden Welten gibt. Die Antwort kann direkt aus Abbildung 3.30
abgelesen werden. Dort sehen wir alle Patterns, die identifiziert wurden, und welche
Beziehungen sie in P4CMI untereinander besitzen. Offensichtlich existieren starke Beziehungen, denn bei neun der vierzehn abgebildeten Entwurfsmustern führt ein Pfeil zu
einem anderen Entwurfsmuster. Darüber hinaus lässt sich ablesen, dass Kommunikation in Spielen ebenso eine große Bedeutung hat wie in seriösen Anwendungen. Gerade
das Entwurfsmuster Embedded Chat konnte in ausnahmslos allen Spielen identifiziert
werden und besitzt auch die meisten starken Beziehungen (siehe Abbildung 3.30).
Des Weiteren lässt sich erkennen, dass die Anzahl der Implementierungen abhängig
vom Spieltyp ist. Während die MUGs im Durchschnitt gerade mal sechs von vierzehn
identifizierten Entwurfsmustern implementiert haben, werden von den MMORPGs im
35
Abbildung 3.29.: Ein Virtual ME im Inventarfenster von Guild Wars.
Durchschnitt rund dreizehn der vierzehn Entwurfsmuster verwendet. Die TBGs sind hier
mit nur jeweils zwei und drei implementierten Entwurfsmustern kaum erwähnenswert.
Hier muss man berücksichtigen, dass sie zum einen nicht aktuell sind und zum anderen,
dass das Budget zur Entwicklung vermutlich weitaus geringer war als bei den anderen
Titeln. Scrabble ist auch das einzige Spiel, dass nur über ein lokales Netzwerk ausgeführt
werden kann. In lokalen Netzwerken haben die Anwender in der Regel Sichtkontakt, was
natürlich viele Awareness-Funktionen6 überflüssig macht.
6
Awareness-Funktionen geben dem Anwender die Möglichkeit andere Anwender und deren Aktionen
innerhalb der Anwendung wahrzunehmen.
36
Abbildung 3.30.: Beziehungen zwischen den identifizierten Entwurfsmustern
37
38
ja
nein
nein
nein
ja
nein
nein
nein
ja
nein
ja
ja
nein
ja
nein
ja
ja
ja
ja
nein
ja
ja
ja
ja
ja
ja
ja
ja
ja
ja
ja
ja
ja
ja
ja
ja
ja
ja
ja
ja
ja
nein
ja
ja
ja
ja
ja
ja
ja
nein
ja
ja
Entropia
Universe
ja
ja
ja
ja
ja
ja
ja
nein
ja
ja
ja
nein
ja
ja
Everquest
2
ja
ja
ja
ja
ja
ja
ja
ja
ja
ja
nein
nein
ja
ja
ja
ja
ja
ja
ja
ja
ja
ja
ja
ja
ja
nein
ja
ja
nein
nein
ja
nein
nein
nein
nein
nein
nein
nein
nein
nein
nein
nein
Guild Ragna- ScrabWars rok
ble
Online
Tabelle 3.5.: Identifizierte Entwurfsmuster anhand der Benutzerschnittstelle.
nein
nein
ja
nein
nein
nein
nein
nein
ja
nein
nein
nein
nein
ja
ja
ja
ja
Abbreviation
Active
Map
Attention
Screen
Away
Message
Buddy
List
Embedded
Chat
Emote
Interactive User
Info
Invitation
Local
Awareness
Login
Navigation
User List
Virtual
Me
ja
Dungeon
& Dragons
Online
Anar- Carcas- Counter
chy
sonne
Strike
OnliSource
ne
Entwurfsmuster
ja
ja
ja
ja
ja
ja
ja
nein
ja
ja
ja
ja
ja
ja
Star
Wars
Galaxies
nein
ja
ja
nein
nein
ja
nein
ja
ja
nein
nein
nein
nein
ja
Unreal
Tournament
2004
ja
ja
ja
ja
ja
ja
ja
ja
ja
ja
ja
ja
ja
ja
World
of
Warcraft
4.1. Auswahl der Spiele
Der Quelltext von kommerziellen Anwendungen ist das Kapital der Software-Entwickler.
Das Gleiche gilt auch für Software-Entwickler von Computerspielen . Aus diesem Grund
war es nicht möglich, ähnlich aktuelle Spiele für diese Analyse zu bekommen wie für
die Analyse der Benutzerschnittstelle. Selbst der Quelltext von älteren kommerziellen
Spielen wird eher selten unter eine freie Lizenz wie die GPL1 gestellt. Eine der wenigen
Ausnahmen stellt das kommerzielle Spiel Quake 3 Arena [Id 99a] dar, dessen Quelltext
[Id 99b] auch in dieser Arbeit analysiert wurde. Die beiden anderen Mehrbenutzerspiele
stammen deshalb von nicht-kommerziellen Projekten.
1
http://www.gnu.org/licenses/gpl.html
4.2. Analysierte Spiele
Spiel
Beschreibung
Bei Quake 3 Arena handelt es sich um ein MUG. Die Spieler
verbinden sich mit einem Server, der von einem der Spieler gehostet werden kann und das Spiel zentral koordiniert.
Kooperation ist nicht möglich. Es ist ein rein konkurrenzbetontes Spiel. Die Spieler müssen gleichzeitig agieren, weshalb
das Spiel nebenläufig ist.
Planeshift ist ein MMORPG [Ato06a]. Die Spieler müssen
sich, wie für ein MMORPG üblich an einem Server anmelden und authentifizieren. Das Spiel wird ebenfalls von einem Server zentral koordiniert. Es müssen nicht alle Spieler
gleichzeitig am Spiel teilnehmen. Das Spiel ist also, wie wir
es von anderen MMORPGs kennen, asynchron. Kooperation ist zum Beispiel durch das Bilden von Gruppen möglich.
Das Spiel ist nicht konkurrenzbetont. Der Quelltext von Planeshift kann unter [Ato06b] eingesehen werden.
BZFlag ist genau wie Quake 3 Arena ein MUG [Rik06a]. Es
unterscheidet sich hinsichtlich der charakteristischen Eigenschaften nicht wesentlich von Quake 3 Arena. Da in diesem
Spiel aber auch Teams konkurrieren können, ist es nicht nur
konkurrenzbetont sondern auch kooperativ. Der Quelltext
von BZFlag kann unter [Rik06b] eingesehen werden.
4.3. Ergebnisse der Analyse
Im folgenden werden die Ergebnisse der Quelltext-Analyse präsentiert. Wie im Kapitel
zuvor werden die identifizierten Entwurfsmuster in alphabetischer Reihenfolge vorgestellt. Der Zweck von Entwurfsmustern, die schon in Kapitel 3 aufgeführt wurden, ist
hier weggelassen worden.
Die Entwurfsmuster wurden in der Regel wie in der Analyse zur Benutzerschnittstelle
während der Ausführung des Spiels identifiziert, was die anschließende Suche im Quelltext erleichterte. Bei der zweiten Vorgehensweise wurden die Objekte oder Dateien innerhalb des Quelltextes gesucht, bei der man eine Implementierung des Entwurfsmusters
vermutet. Dies trifft vor allem auf Entwurfsmuster aus dem Kapitel Base Technology von
[SLht] zu.
Um die Implementierung der Entwurfsmuster zu verdeutlichen, werden Klassen- bzw.
Interaktionsdiagramme und Teile aus dem Quelltext verwendet. Bei den QuelltextZitaten sind die für das Verständnis unwichtigen Teile durch jeweils drei Punkte ersetzt
worden.
40
Abbildung 4.1.: Active Map in BZFlag
4.3.1. Active Map
Von den analysierten Spielen bietet lediglich BZFlag eine Active Map an. In Abbildung
4.1 sind Screenshots der Active Map aus zwei verschiedenen Spielszenen zu sehen.
Wie man leicht erkennen kann, hat die Active Map eine quadratische Form, begrenzt durch rosafarbene Linien. Durch sie wird eine verkleinerte Sicht von oben auf
die dreidimensionale Spielwelt dargestellt. Unterschiedlich große, grau-grüne Quadrate
visualisieren Hindernisse wie Pyramiden oder Quader. Die weißen Kreuze symbolisieren
Flaggen, die der Spieler aufnehmen kann, um sein Fahrzeug zu modifizieren. Die bunten
kleinen Quadrate zeigen die Position der Mitspieler in den Teamfarben an. Das weiße
kleine Quadrat im Zentrum der Active Map ist die Position des Spielers. Von diesem
Quadrat führen zwei orangefarbene Linien weg. Die Fläche zwischen diesen beiden Linien
entspricht dem Sichtfeld des Spielers. Dementsprechend befindet sich ein Mitspieler des
gelben Teams im Sichtfeld unseres Spieler. Der Rest der Spielwelt wird nicht gezeichnet
und bleibt transparent.
Wenn man beide Active Maps miteinander vergleicht, fällt auf, dass der Spieler
sich in jeder Szene in der Mitte befindet und die Blickrichtung nach oben führt. Der
Grund dafür liegt darin, dass die Blickrichtung und Position des Spielers innerhalb der
Active Map festgelegt ist. Deshalb bewegt sich die Spielwelt innerhalb der Active
Map, sobald sich der Spieler in der Spielwelt bewegt oder dreht. Dies wird deutlich,
wenn man sich die beiden Screenshots in Abbildung 4.1 anschaut. Auf dem linken Bild
befindet sich Norden2 in der unteren rechten Ecke der Active Map. In dem rechten
Bild von Abbildung 4.2 liegt Norden hingegen unterhalb der Position des Spielers. Die
Karte hat sich demnach gedreht.
Zur Realisierung dieser Active Map dient die Klasse RadarRender und deren Me2
im Bild mit N gekennzeichnet
41
thoden, die in Abbildung 4.2 zu sehen sind. Die Methode drawShot zeichnet die Schüsse
der Spieler, die Methode drawTank die Positionen der Mitspieler und drawFlag die Flaggen. Hindernisse und Spielfeldbegrenzung werden von den Methoden renderObstacles
und renderWalls gezeichnet. Alle genannten Methoden werden innerhalb der Methode
render aufgerufen, die auf die Methoden der Klasse World zugreift, um die aktuellen
Daten der Objekte zu erhalten.
Abbildung 4.2.: Objekte für die Erzeugung der Active Map in BZFlag
Um die Objekte relativ zur Spielwelt in der Active Map darzustellen werden die
Objekte dann von den jeweiligen draw-Methoden der Klasse RadarRenderer in die xyEbene projeziert. Um das zu erreichen vernachlässigt Planeshift die z-Koordinate, da
bei einer Active Map die Tiefe der Objekte nicht von Bedeutung ist.
4.3.2. Buddy List
Das Pattern Buddy List wird von Planeshift implementiert. Die Realisierung erfolgt
entsprechend dem in Abbildung 4.3 dargestellten Interaktionsdiagramm.
Clientseitig ist die Klasse pawsBuddyWindow für die Darstellung der Buddy List
zuständig. Öffnet der Spieler das Buddy List Widget, erzeugt die Methode Show der
Klasse pawsBuddyWindow ein Objekt vom Typ psUserCmdMessage, die den Befehl buddylist und den Typ des Befehls MSGTYPE_USERCMD für die Versendung zum Server vorbereitet. Anschließend wird die Nachricht3 an den Server gesendet.
Auf dem Server wird der Typ der Nachricht ausgelesen und ein Objekt vom Typ
psUserCmdMessage erzeugt. Diesmal wird allerdings der Konstruktor von psUserCmdMessage aufgerufen, der die Nachricht wieder in ihre Befehle und Argumente zerlegt. Anschließend kümmert sich die Methode BuddyList der Klasse UserManager um die Bearbeitung des Inhalts der Nachricht. Diese liest die Buddies des Spielers aus der buddyList
Member-Variablen der Klasse psCharacter aus. Mit Hilfe der Klasse psBuddyListMsg
3
Da die Buddy List auf dem Server und nicht auf dem Client liegt, handelt es sich vermutlich um die
Implementierung von Centralized Objects.
42
Abbildung 4.3.: Interaktionsdiagramm für die Buddy List in Planeshift
wird die Nachricht für den Client generiert und mit deren Methode SendMessage an den
Client gesendet. Die Nachricht enthält folgende Informationen, die für die Buddy List
relevant sind:
– Nachrichtentyp (in diesem Fall BuddyList)
– Anzahl der Buddies
– Nicknames der Buddies
– Online-Status der Buddies
Im Client erhält wieder die Klasse pawsBuddyWindow die Nachricht des Servers. Dort
wird sie von der Methode HandleMessage ausgewertet. Diese extrahiert die relevan-
43
ten Informationen mit Hilfe der Klasse psBuddyListMsg. Einer der beiden Konstruktoren der Klasse speichert die Daten hierzu in seine Feldvariablen, die anschließend
von der Methode HandleMessage in die beiden Member-Variablen onlinebuddies und
offlinebuddies vom Typ csStringArray kopiert werden. Buddies die gerade online
sind, werden dementsprechend in das Array onlinebuddies eingefügt, alle anderen Buddies in das Array offlinebuddies. Nachdem beide Arrays alphabetisch sortiert worden
sind, werden Sie im Widget ausgegeben.
Bevor Buddies in der Buddy List aufgelistet werden, muss sie der Spieler zuvor hinzufügen. Dazu gibt er in einem dafür vorgesehenen Textfeld den Namen eines Mitspielers
ein. Sobald der Name bestätigt wird, erstellt die Methode OnStringEntered der Klasse
pawsBuddyWindow die Nachricht für den Server. Als Parameter bekommt die Nachricht
den Namen des Spielers und den Befehl zum Hinzufügen zur Buddy List.
Anschließend erfolgt die Übertragung der Nachricht an den Server, wo sie von der
Methode Buddy verarbeitet wird. Diese überprüft zunächst, ob ein Spieler mit dem
übergebenen Namen existiert, und erhält dabei die ID, die auf dem Server mit dem
Spieler assoziiert ist. Danach werden ID und Name der Buddy List den Spielfigurendaten in einem Objekt vom Typ psCharacter durch die Methode AddBuddy hinzugefügt.
Jetzt wird das Client-Objekt des Buddys gesucht und die ID des Spielers in dessen
BuddyOf-Liste eingetragen. Wie wir später noch sehen werden, ist diese Vorgehensweise
für die Benachrichtigung, ob ein Buddy sich einbzw. ausgeloggt hat, wichtig.
Damit der Spieler nicht nach jedem Ausloggen seine Buddy List erneut anlegen
muss, werden die Buddy List Daten persistent gespeichert. Hierfür wird die Methode
AddBuddy der Klasse psServer mit den IDs des Spielers und des Buddys aufgerufen.
Zuletzt wird noch die geänderte Buddy List an den Client gesendet. Dies erfolgt,wie
eben beschrieben, über den Aufruf der Methode BuddyList der Klasse UserManager .
Der Spieler hat auch die Möglichkeit Spieler aus der Buddy List zu entfernen. Da
der Mechanismus analog zu dem des Hinzufügens abläuft, wird hier nicht näher darauf
eingegangen.
Loggt sich der Spieler ein, wird seine Buddy List aus der Datenbank in das Buddy
List-Array der Klasse psCharacter durch die Methode LoadBuddies geladen.
Beim Ein- und Ausloggen des Spielers wird die Methode NotifiyBuddies der Klasse
UserManager aufgerufen. In dieser Methode werden, wie weiter oben bereits angesprochen, mittels des Feldes BuddyOf alle Mitspieler, auf deren Buddy List der gerade einbzw. ausgeloggte Spieler steht, über den Vorgang informiert werden. Dazu wird zum Beispiel beim Einloggen des Spielers die Methode NotifiyBuddies mit dem Wert true für
den Parameter logged_in aufgerufen. Nun werden alle Spieler, die sich in der BuddyOf
Liste befinden und gerade online sind, darüber informiert, dass der Buddy sich eingeloggt
hat. Die Methode NotifyBuddies sendet hierzu zwei Nachrichten an den Client. Zum
einen wird mit Hilfe der Klasse psBuddyStatus eine Nachricht über die Statusänderung
des Buddys generiert, die vom Client in der Methode HandleMessage verarbeitet wird,
und dafür sorgt, dass der Buddy von der Offline Liste in die Online Liste verschoben
wird. Zum anderen wird eine Chat-Nachricht an den Client des Spielers gesendet. Sie
44
informiert den Spieler darüber, dass der Buddy dem Spiel gerade beigetreten ist.
4.3.3. Embedded Chat
Das Entwurfsmuster Embedded Chat haben wir bereits in Kapitel 3 kennengelernt.
Hier werden wir anhand der Quelltexte zeigen, wie die Spiele Chat-Nachrichten von
Spielern erfassen, wie sie die Nachrichten den Empfängergruppen zuordnen, und wie von
ihnen die Ausgabe formatiert wird. In Abschnitt 4.3.6 wird mit dem Entwurfsmuster
Mediated Updates gezeigt, auf welche Weise die Chat-Nachrichten an alle Empfänger
verteilt werden.
Generell ist die Funktionalität des Embedded Chat in Planeshift umfangreicher als
in den beiden anderen Spielen. Dies deckt sich mit den Erfahrungen der Analyse aus
Kapitel 3. Dort waren ebenfalls die Embedded Chats der MMORPGs umfangreicher
ausgestattet, als die Embedded Chats der MUGs.
Abbildung 4.4.: Planeshift - Embedded Chat Klassendiagramm
Sowohl bei Planeshift, als auch bei den beiden MUGs, gibt der Spieler zunächst die
Nachricht ein. In Planeshift ist dafür ein Texteingabefeld vorgesehen, dass durch die
Klasse pawsEditTextBox realisiert wird und gemeinsam mit dem Ausgabefeld permanent
während dem Spiel angezeigt werden kann.
Quake 3 Arena und BZFlag bieten hingegen kein Widget für die Eingabe der Nachrichten an. Die Eingabe wird zum Beispiel in Quake 3 Arena mit einem Hotkey initiiert,
woraufhin alle Tastatureingaben an die Methode Message_Key weitergeleitet werden,
bis die Aktion beendet oder abgebrochen wird (siehe Abbildung 4.5). Der geschriebene
Nachrichtentext wird dann einfach über dem Spielfeld visualisiert.
Nach dem Senden der Nachricht wird der Inhalt des Eingabetextfeldes gelöscht und
der Tastaturfokus wieder freigegeben.
45
{
void Message Key ( int key ) {
...
i f ( key == K ESCAPE) {
c l s . k e y C a t c h e r s &= ˜KEYCATCH MESSAGE;
F i e l d C l e a r ( &c h a t F i e l d ) ;
return ;
}
i f ( key == K ENTER | | key == K KP ENTER )
{
...
}
c l s . k e y C a t c h e r s &= ˜KEYCATCH MESSAGE;
F i e l d C l e a r ( &c h a t F i e l d ) ;
return ;
}
Field KeyDownEvent ( &c h a t F i e l d , key ) ;
}
Abbildung 4.5.: Erzeugen einer Chat-Nachricht in Quake 3 Arena
46
Die Embedded Chats erlauben das Senden der Nachricht an bestimmte Gruppen
von Mitspielern. Die MUGs unterscheiden hierbei folgende Adressaten:
– ein Mitspieler
– Mitspieler des eigenen Teams
– alle Mitspieler
Planeshift ermöglicht darüber hinaus Nachrichten an folgende Spielergruppen zu senden:
– Mitspieler der eigenen Gilde4
– Mitspieler innerhalb einer begrenzten Entfernung zum Autor der Nachricht
Damit das System die Adressaten erfährt, gibt der Spieler vor der Nachricht ein Kommando wie guild ein. Dieses Kommando wird von der Methode HandleCommand interpretiert und gemeinsam mit der Nachricht an den Server weitergeleitet. Auf dem Server
liest die Methode HandleMessage den Befehl aus und gibt dann die Nachricht an die
zuständige send-Methode weiter. In diesem Fall wäre das die SendGuild-Methode.
Anstelle von Kommandos zur Unterscheidung der Adressaten, verwenden die MUGs
unterschiedliche Hotkeys für das Öffnen des Eingabetextfeldes. Der Hotkey initiiert also
nicht nur die Eingabe der Nachricht, sondern legt auch gleichzeitig den Nachrichten-Typ
fest. Die Zuteilung auf dem Server läuft dann genauso wie in Planeshift ab.
Ein weiterer Unterschied ist die Formatierung der Nachrichten. Alle Spiele stellen
Nachrichten an unterschiedliche Adressaten in unterschiedlichen Farben dar. Bei den
MUGs wird das Mapping der Farben auf dem Server erledigt, in Planeshift ist der Client
dafür verantwortlich.
4.3.4. Invitation
Invitation gehört ebenfalls zu den Entwurfsmustern, die ausschließlich von Planeshift
realisiert werden. Der Ablauf ist im Interaktionsdiagramm in Abbildung 4.6 illustriert.
Um einen Mitspieler einzuladen, muss der Spieler zunächst das Gruppen-Widget, welches durch die Klasse pawsGroupWindow realisiert wird, öffnen. Durch einen Klick auf
den Button Invite wird die Methode OnButtonPressed aufgerufen, welche ein Widget
mit einem Textfeld öffnet, in dem der Name des Einzuladenden eingetragen wird. Die
Bestätigung des eingegebenen Namens startet die Methode OnStringEntered, die eine
Nachricht mit dem Namen des eingeladenen Mitspielers und den Befehl invite enthält.
Auf dem Server wird die Nachricht von der Methode HandleMessage der Klasse
GroupManager behandelt. Der Befehl invite führt hier zum Aufruf der Methode invite
derselben Klasse. In dieser Methode wird erst einmal überprüft, ob folgende Voraussetzungen für eine Einladung erfüllt sind:
4
Gilden stellen in MMORPGs persistente Gruppen dar.
47
– Der Einladende muss in einer Gruppe sein. Falls nicht wird eine Gruppe mit ihm
als Gruppenleiter erstellt.
– Der Eingeladene darf nicht in einer anderen Gruppe Mitglied sein.
– Der Einladende muss Gruppenleiter sein.
– Der Einladende darf nicht mit dem Eingeladenem identisch sein.
Sind die Voraussetzungen erfüllt, wird ein Objekt der Klasse PendingGroupInvite erzeugt. Diese Klasse speichert die Daten der Einladung und verarbeitet später die Antwort
des Eingeladenen. Darauf erstellt der GroupManager mit Hilfe des QuestionManagers die
Nachricht vom psQuestionMessage und ruft anschließend deren Methode SendMessage
auf, um sie an den Client des Eingeladenen zu senden.
Auf dem Client des Eingeladenen kümmert sich die Klasse psQuestionClient um alle
Anfragen an den Spieler. Dies betrifft auch Einladungen. In der Methode HandleMessage
werden die einzelnen Informationen der Nachricht mit Hilfe der Klasse psQuestionMessage ausgelesen. Da eine Einladung in Planeshift eine grundsätzlich einer Bestätigung
bedarf, wird dann die Methode HandleConfirm aufgerufen, die wiederum ein Objekt der
Klasse psConfirm erzeugt. In dem Konstruktor von psConfirm wird ein Widget geöffnet,
das dem Eingeladenen die Einladung visualisiert. Der Spieler hat nun die Möglichkeit
entweder anzunehmen oder abzulehnen. In beiden Fällen wird die Nachricht wieder an
den Server gesendet, wo sie an die Methode HandleMessage der Klasse QuestionManager
weitergeleitet wird. Diese Methode ermittelt zunächst anhand der eindeutigen QuestionID, welches PendingQuestion-Objekt zu dieser Nachricht gehört. Anschließend ruft sie
die HandleAnswer-Methode des gefundenen PendingQuestion-Objekts auf. Falls der
Eingeladene der Einladung zugestimmt hat, wird nun die Methode HandleJoinGroup
der Klasse GroupManager ausgeführt, die schließlich den Eingeladenen durch den Aufruf
der Methode AddPlayerToGroup der Gruppe hinzufügt.
4.3.5. Login
Das Entwurfsmuster Login wird von dem Spiel Planeshift implementiert. In Abbildung
4.7 ist ein Screenshot des Login-Fensters von Planeshift abgebildet.
In dem Textfeld unter Account gibt der Spieler seinen Benutzernamen ein, das Passwort
in das Textfeld darunter. Auf der rechten Seite sieht man eine Liste der Server, in der
aber beim derzeitigen Entwicklungsstand des Projekts lediglich ein Server zur Auswahl
steht. Um die Anmeldung auszuführen, klickt der Spieler auf den OK-Button, was dazu
führt, dass die Methode OnButtonPressed der Klasse pawsLoginWindow aufgerufen wird
(siehe Abbildung 4.8). Diese prüft zunächst, ob der Benutzernamen und das Passwort
angegeben worden sind, und ruft dann die Methode ConnectToServer derselben Klasse
auf.
Diese Methode versucht eine Verbindung zum Server aufzubauen und ruft, falls die
Verbindung hergestellt werden konnte, die Methode Authenticate der Klasse psNet-
48
Manager auf und übergibt dabei den Benutzernamen und das Passwort als Parameter. Die Authenticate-Methode macht nichts anderes als die Authenticate-Methode
der Klasse psAuthenticateClient aufzurufen. Diese Methode erstellt dann ein Objekt
vom Typ psPreAuthenticateMessage und sendet mit deren Methode SendMessage eine
Nachricht zum Server, um die Authentifizierung zu initiieren.
Auf dem Server wird diese Nachricht von der Methode HandlePreAuthent der Klasse
psAuthenticationServer verarbeitet. Hier wird geprüft, ob der Client die korrekte
Version besitzt und ob der Server für die Annahme von Clients bereit ist. Ist die Version
korrekt und der Server bereit, wird ein Objekt vom Typ psPreAuthApprovedMessage
erzeugt und mit dessen Methode SendMessage dem Client einen Bestätigung geschickt.
Auf dem Client erhält die Methode HandlePreAuth der Klasse psAuthenticationClient die Nachricht und sendet daraufhin dem Server mit der Methode SendMessage
der Klasse psAuthenticationMessage eine Nachricht mit dem Benutzernamen und dem
Passwort.
Auf dem Server überprüft die Methode HandleAuthent der Klasse psAuthenticationServer zuerst den Benutzernamen. Falls dieser existiert, wird anschließend das übermittelte Passwort mit dem zum Benutzernamen abgespeicherten Passwort verglichen. Sind
beide Passwörter identisch, wird eine Nachricht vom Typ psAuthApprovedMessage erzeugt und zum Client gesendet.
4.3.6. Mediated Updates
Der Zweck des Entwurfsmusters Mediated Updates ist es, den administrativen Aufwand für Updates zu minimieren, in dem man ein zentrale Instanz zur Verteilung der
Updates verwendet.
Alle Spiele verwenden das Entwurfsmuster Update your friends. Wie dies implementiert wird, soll an Quake 3 Arena und dem Austausch von Chat-Nachrichten
demonstriert werden.
In Abbildung 4.9 sehen wir dazu ein Interaktionsdiagramm, in dem drei Objekte, der
Client des Senders, der Server und der Client des Empfängers untereinander Nachrichten
austauschen. Zu beachten ist, dass hier mehrere Empfänger existieren können.
Gibt der Spieler eine Chat-Nachricht ein, wird bei jedem Tastendruck die Methode
Message_Key ausgerufen. Sobald die Enter-Taste gedrückt wird, bedeutet das, dass der
Spieler die eingegebene Nachricht jetzt absenden möchte. Dann wird die eingegebene
Nachricht mithilfe der Funktion AddReliableCommand an die Liste der Befehlsnachrichten des Server gehängt. Wenn die Nachricht an der Reihe ist, sendet sie der Client zum
Server. Dort angekommen wird die Nachricht an die Funktion G_SAY übergeben, die
den Inhalt und den Adressaten der Nachricht ermittelt und anschließend die Funktion
G_SayTo, welche die Nachricht an die Empfänger sendet, n-mal für n Empfänger aufruft.
Nachdem die Nachricht an alle Empfänger verteilt wurde, wird bei jedem Empfänger
die Funktion CG_ServerCommand aufgerufen, die die Nachricht des Servers verarbeitet.
Stellt die Funktion fest, dass es sich um eine Chat-Nachricht handelt, ruft sie die Funktion
49
CG_Printf auf, welche die Nachricht auf dem Client ausgibt.
Dieser Verteilungsmechanismus ist bei den anderen Spielen ähnlich implementiert,
weshalb auf diese hier nicht auch noch eingegangen wird.
4.3.7. User List
Eine User List existiert in allen drei Spielen. Bei den beiden MUGs kann die User List
per Hotkey während des Spiels aufgerufen und über die Spielwelt gezeichnet wird. Da die
Anwendungsinformation hier höher als die Bewusstseinsinformation bewertet wird, wird
auf eine permanente Einblendung der User List verzichtet. In Planeshift lässt sich die
User List per Button oder mit einem Befehl im Chat-Eingabetextfeld abfragen. Die
User List wird dann in beiden Fällen nach Namen sortiert im Ausgabetextfeld des
Chats ausgegeben. Die Ausgabe beschränkt sich dabei auf maximal 30 Spielernamen.
Zusätzlich wird die Anzahl der aktuell teilnehmenden Spieler angezeigt.
Auf dem Server nimmt die Klasse UserManager und deren Methode Who den Befehl
zur Ausgabe der User List entgegen (siehe Abbildung 4.10). Die Methode iteriert mit
einem Iterator vom Typ ClientIterator über maximal 30 Clients, die gerade online
sind. Die Limitierung ist damit zu erklären, dass eine Nachricht in einem 1024 Byte
großen Array gespeichert wird. Warum bei mehr als 30 Clientnamen die Nachrichten
nicht einfach in mehrere Pakete der maximalen Größe aufgeteilt werden ist nicht klar,
denn diese Methode verwendet Planeshift auch, um die Namen von weniger als 30 Clients
zu versenden.
In jedem Durchlauf wird in die Variable temp der Nickname des referenzierten Clients
kopiert und an die Variable message vom Typ String angehängt. Nach der Iteration wird
mit clients->Count die Gesamtzahl der Spieler an die Nachricht gehängt.
Zum Schluss wird eine Nachricht vom Typ psSystemMessageSafe erzeugt, die aus
den aufrufenden Client, dem Befehlstyp Who und der User List, die Nachricht für den
Client erzeugt. Mit der Methode SendMessage wird schließlich die Nachricht an den
Client gesendet.
Auf die anderen beiden Frameworks wird hier nicht näher eingegangen, da die Implementierung ähnlich ist.
4.3.8. What’s up
Das Entwurfsmuster What’s up hat den Zweck Anwender, die zu einem späteren Zeitpunkt zu einer Interaktion hinzukommen, zu integrieren.
In BZFLag werden die Spielweltdaten vor dem Beitritt zu einem Spiel geladen. Die
Spielweltdaten sind in der Klasse World enthalten, die sowohl vom Client, als auch vom
Server verwendet wird. Die Spielweltdaten bestehen aus den Informationen über den
Aufbau der 3D-Umgebung, der Konfiguration der Karte und die aktuellen Spielerinformationen.
Bevor der Client sich in das Spiel einklinken kann, werden die Daten auf den Client
50
kopiert. Es beginnt mit dem Aufruf der Methode start der Klasse WorldDownLoader.
Hier wird zunächst geprüft, ob die Spielinformationen bereits lokal vorhanden sind. Wenn
dies nicht der Fall ist, wird die Methode askBZFS aufgerufen, die dem Spieler anzeigt, dass
die Spielweltdaten runtergeladen werden und den Server mit einer Nachricht auffordert,
die Spielweltdaten zu senden. Zum Schluss wird in dieser Methode noch eine Datei als
Cache für die Spielweltdaten angelegt.
Die Funktion sendWorldChunk des Servers sendet dem Client nun so lange Teile des
Objekt World, bis das ganze Objekt auf dem Client kopiert ist.
Anschließend werden auf dem Client die Daten aus dem Cache in das Laufzeitobjekt
gelesen.
4.3.9. Who’s that girl
Der Zweck des Entwurfsmusters Who’s that girl ist es, Nachrichten in einem GroupwareSystem mit einem Anwender zu verbinden.
Dieses Entwurfsmuster wird von allen analysierten Spielen implementiert. Sie erzeugen
zu jedem verbundenen Client ein Client-Objekt, in dem unter anderem die IP-Adresse
des Clients gespeichert wird. Erhält ein Server eine Nachricht eines Clients, dann wird
die übermittelte IP-Adresse mit denen der Client-Objekte verglichen. In Planeshift bearbeitet die Methode CheckIn der Klasse NetBase ankommende Pakete (siehe Abbildung
4.11). Die IP-Adresse wird aus der Nachricht ausgelesen und in eine Variable vom Typ
SOCKADDR_IN gespeichert. Diese Variable wird der Methode GetConnByIP der Klasse
Netmanager übergeben, die zu der IP-Adresse das passende Connection-Objekt ermittelt und zurückgibt. In diesem Connection-Objekt ist die Nummer des Client-Objekts
gespeichert, wodurch die Zuordnung Client und Nachricht damit erreicht ist.
Im Gegensatz zu den anderen Spielen behandelt Q3A den Fall, dass auf einem Rechner mehrere Clients laufen. In diesem Fall gewährleistet die IP-Adresse alleine keine
eindeutige Zuordnung zum Client. Deshalb wird in Q3A neben der IP-Adresse auch der
Port geprüft, auf dem der Client die Nachrichten sendet. Diese werden in die Nachricht
gepackt und auf dem Server von der Variablen qport ausgelesen und anschließend mit
den Ports der Clients verglichen (siehe Abbildung 4.12).
Leider erwiesen sich die Quelltexte als sehr schlecht dokumentiert. Auch die Form des
Quelltextes trägt nicht besonders zum Verständnis der Implementierungsdetails bei. Die
Methode main5 von BZFlag erstreckt sich zum Beispiel über mehr als tausend Zeilen.
Selbst das ehemals kommerzielle Produkt Quake 3 Arena macht hier keine Ausnahme. Dennoch konnte eine Reihe von Entwurfsmustern ausgegraben werden. Und wie
erwartet befinden sich darunter jetzt auch technische Entwurfsmuster, wie zum Beispiel
Mediated Updates. In Abbildung 4.13 sehen wir das Diagramm von Abbildung 3.30
5
Diese Methode befindet sich in der Datei bzfs.cxx in dem Verzeichnis /src/bzfs
51
Entwurfsmuster
Active Map
Buddy List
Embedded Chat
Invitation
Login
Mediated Updates
User List
What’s up
Who’s that girl
BZFlag
Planeshift
Quake 3 Arena
ja
nein
ja
nein
ja
ja
ja
ja
ja
nein
ja
ja
ja
ja
ja
ja
nein
ja
nein
nein
ja
nein
nein
ja
ja
nein
ja
Tabelle 4.2.: Identifizierte Entwurfsmuster anhand der Quelltexte.
um die hier identifizierten Entwurfsmuster erweitert. Diese Entwurfsmuster und deren
Beziehungen sind in dem Diagramm orangefarben dargestellt.
Die Ergebnisse bestätigen letztlich nochmal das, was wir in Kapitel 3 feststellen konnten. Es gibt eine signifikante Menge an Entwurfsmustern die sowohl in seriösen Anwendungen als auch in Computerspielen anwendbar sind.
52
Abbildung 4.6.: Interaktionsdiagramm zu Invitation von Planeshift.
53
Abbildung 4.7.: Login-Fenster in Planeshift
Abbildung 4.8.: Klassendiagram für das Pattern Login von Planeshift
54
Abbildung 4.9.: Interaktionsdiagramm zur Verteilung von Chat-Nachrichten über
Mediated Updates in Quake 3 Arena
55
void UserManager : : Who( psUserCmdMessage& msg ,
Client ∗ client , intclientnum ) {
c s S t r i n g message ( ( s i z e t ) 1 0 2 4 ) ;
c s S t r i n g temp ( ( s i z e t ) 1 0 2 4 ) ;
...
C l i e n t I t e r a t o r i (∗ c l i e n t s ) ;
f o r ( C l i e n t ∗ c u r r = i . F i r s t ( ) ; c u r r && count <30;
c u r r = i . Next ( ) )
{
...
temp . Format ( format . GetData ( ) , c u r r −>GetName ( ) ,
g u i l d T i t l e . GetData ( ) , guildName . GetData ( ) ) ;
...
message . Append ( temp ) ;
...
}
...
temp . Format ( ”\%u shown from \%u p l a y e r s o n l i n e \n” ,
count , c l i e n t s −>Count ( ) ) ;
...
psSystemMessageSafe newmsg ( c l i e n t n u m ,MSG WHO, message ) ;
newmsg . SendMessage ( ) ;
}
Abbildung 4.10.: Erzeugen einer User List in Planeshift
bool NetBase : : CheckIn ( ) {
//
check
for
incoming
packets
SOCKADDR IN addr ;
...
p a c k e t l e n = RecvFrom (&addr , &l e n ,
( void ∗ ) i n p u t b u f f e r , MAXPACKETSIZE) ;
...
//
Identify
the
connection
Connection ∗ c o n n e c t i o n = GetConnByIP(&addr ) ;
...
}
Abbildung 4.11.: Identifizierung eines Clients in Planeshift anhand der IP-Adresse
56
void SV PacketEvent ( n e t a d r t from , msg t ∗msg ) {
...
q p o r t = MSG ReadShort ( msg ) & 0 x f f f f ;
...
f or ( i =0, c l=s v s . c l i e n t s ; i < s v m a x c l i e n t s −>i n t e g e r ;
i ++, c l ++) {
...
i f ( c l −>netchan . q p o r t != q p o r t ) {
continue ;
}
...
}
...
}
Abbildung 4.12.: Identifizierung des Autors der Nachricht in Quake 3 Arena anhand
der Ports
Abbildung 4.13.: Beziehungen zwischen den identifizierten Entwurfsmustern.
57
Nachfolgend werden die sieben Entwurfsmuster, die während der Analyse der Mehrbenutzerspiele ausgegraben wurden, beschrieben. Dabei lehnt sich das Schema der Beschreibung an die Form, wie sie in [SLht] verwendet wird, an.
5.1. Automatic Software Update
Intent
Context
http://www.flickr.com/photos/gokidgo/74678689/
Informiere den Benutzer, sobald eine neue Version seiner ClientSoftware verfügbar ist.
Sie entwickeln Client-Software für ein verteiltes System. Das System
und die Client-Software werden von ihnen ständig weiterentwickelt
und es werden immer wieder Fehler in der Software behoben. Jetzt
überlegen sie, wie sie Benutzer dazu bringen, die neueste Version der
Anwendung zu verwenden.
4 4 4
Problem
Software
erhält
auch
nach
ihrer
Veröffentlichung
Änderungen, die entweder durch neue Funktionalitäten
oder Fehlerbeseitigung bedingt sind. Verwendet ein Benutzer eine veraltete Version einer Client-Software sind die
neuen Funktionen für ihn nicht zugänglich oder beseitigte
Fehler treten weiterhin auf. Die Client-Software auf dem
aktuellen Stand zu halten, ist für den Benutzer mit hohem
Aufwand verbunden.
Scenario
Durch Rechtschreibreformen ändern sich die Grammatikregeln der
deutschen Sprache. Für Schüler stellt das ein Problem dar, denn
ihre Klausurnoten hängen unter anderem davon ab, dass sie ihre
Sätze nach den aktuellen Grammatikregeln bilden. Deshalb werden
die Schulbücher neu aufgelegt, sobald sich die Rechtschreibung ändert.
Diese neuen Schulbücher werden automatisch an die Schüler ohne deren Zutun verteilt.
Symptoms
Sie sollten es in Betracht ziehen dieses Entwurfsmuster anzuwenden,
wenn . . .
– sich die Client-Software oft ändert.
Solution
Deshalb: Lassen Sie nur Verbindungen zum System mit aktuellen Clients zu. Bringen Sie ältere Clients, die sich mit
dem System verbinden wollen, auf den aktuellen Stand der
Client-Software.
Collaborations
Bei dem Verbindungsaufbau sendet der Client seine Versionsnummer
zum Server. Auf dem Server ist die aktuelle Versionsnummer des Clients gespeichert. Der Server vergleicht beide Versionsnummern miteinander. Ist die Versionsnummer des anfragenden Clients niedriger als
die gespeicherte Versionsnummer, muss der Client aktualisiert werden.
Dazu wird der Verbindungsaufbau unterbrochen und die notwendigen
Dateien auf den Client übertragen. Anschließend wird der Client neu
gestartet und der Verbindungsaufbau zum Server wiederholt. Der Client sendet erneut sein Versionsnummer, die jetzt der aktuellen Versionsnummer entspricht. Die Verbindung wird zum System hergestellt.
Rationale
Ohne Automatic Software Update muss sich der Benutzer selbst
um die Aktualität seiner Client-Software kümmern. In der Regel
können Benutzer mittels Web-Client Updates von der Website des
Herstellers herunterladen. Führt der Benutzer diese Aktion in kurzen
regelmäßigen Abständen durch, wird er zwar seine Software immer auf
dem aktuellen Stand halten können, ein Teil seiner Bemühungen zur
Aktualisierung sind aber nutzlos, da nicht immer ein Update verfügbar
ist. Wählt der Benutzer aber recht lange und unregelmäßige Abstände
zwischen den Aktualisierungen, sind dabei häufiger Updates verfügbar,
seine Software ist dafür nicht immer auf dem aktuellen Stand.
Check
Wenn Sie dieses Entwurfsmuster anwenden, sollten sie folgende Fragen beantworten:
– Wird die Software sofort bei der Verbindung zum System aktualisiert, oder erst wenn der Benutzer einer Aktualisierung zustimmt?
59
Danger Spots
Müssen bei einem Update viele Dateien geändert werden, kann die
Übertragung zum Client sehr lange dauern. Geben Sie dem Anwender die Möglichkeit, die Aktualisierung abzubrechen um sie zu einem
späteren Zeitpunkt zu wiederholen.
Achten Sie darauf, die Updates auf dem Client des Benutzers so
zu speichern, dass der Benutzer sie auch von seinem lokalen Speichermedium ausführen kann. Muss der Benutzer aus irgendeinem Grund
die Software neu installieren, wird dadurch vermieden, dass die Updates über die in der Regel wesentlich langsamere Internet-Verbindung
wiederholt heruntergeladen werden müssen.
Known Uses
Guild Wars ist ein MMORPG, bei dem sich der Spieler mittels ClientSoftware zu einem Server verbindet. Nach dem Start des Clients,
wird zunächst der Client auf Aktualität überprüft.
Abbildung 5.1.: Automatic Software Upate in Guild Wars.
Ist der Client nicht aktuell, werden die Dateien des Clients auf den
neuesten Stand gebracht, wobei das Fenster aus Abbildung 5.1
erscheint. In diesem Fenster wird dem Spieler der Fortschritt der
Aktualisierung angezeigt. Auf Wunsch des Benutzers kann der
Vorgang auch abgebrochen werden, was zur Folge hat, dass der
Client ebenfalls beendet wird.
Entropia Universe ist ebenfalls ein MMORPG. Wie in Guild Wars
wird bei dem Verbinden mit dem Server die Version des Clients
überprüft, da nur Clients mit der aktuellsten Client-Version an
dem Spiel teilnehmen dürfen. Muss der Client aktualisiert werden,
erscheint ein Fenster wie in 5.2 abgebildet, in dem die zu aktualisierende Datei und der Fortschritt des Aktualisierungsprozesses
angezeigt wird. Der Spieler hat auch die Möglichkeit den Vorgang
60
abzubrechen, in dem er den Abort-Button benutzt. Dies führt aus
genanntem Grund aber auch zum Abbruch der Verbindung zum
Server.
Abbildung 5.2.: Automatic Software Upate in Entropia
Universe.
4 4 4
Related Patterns Update your Friends sorgt dafür, dass die Daten, auf die die Benutzer
gemeinsam zugreifen, konsistent sind.
61
5.2. Blind Date
http://www.flickr.com/photos/berencsy/49434057/
Alternative name(s): Meeting Stone
Intent
Erleichtere die Gruppenbildung zur Lösung von kollaborativen Aufgaben.
Context
Sie entwickeln ein System, in dem Anwender Aufgaben nur gemeinsam lösen können. Dabei spielt es keine Rolle, welche Anwender im
konkreten Fall kollaborieren.
4 4 4
Problem
Sollen Anwender eine Aufgabe gemeinsam lösen, dann
müssen sich mindestens zwei Anwender zusammentun. Kennt
der Anwender jedoch niemanden, der für diese Aufgabe
verfügbar ist, ist es schwer für ihn den geeigneten Anwender zu finden.
Scenario
Stellen sie sich ein Entwicklerteam vor, dass die Extreme Programming Methode verwendet. Eine Anwendung dieser Methode ist die
Programmierung in Paaren. Aber wie bilden sich diese Paare? Bei
Extreme Programming an einem Ort ist die Antwort einfach: Wann
immer etwas implementiert werden soll, fragt der Entwickler andere
Programmierer im Raum nach einem Partner für diese Aufgabe. Das
signalisiert den anderen Entwicklern, dass der fragende Entwickler eine Session starten möchte. Sobald ein anderer Entwickler verfügbar
ist, trifft er sich mit dem fragenden Entwickler und die Kollaboration
beginnt.
Symptoms
wenn . . .
– ihre Gruppen eher homogen sind, was bedeutet, dass unterschied-
62
liche Benutzer eine Gruppe bilden können, um die Aufgabe zu
lösen.
– das Bedürfnis zur Zusammenarbeit durch einen speziellen Kontext einer Systembenutzung ausgelöst wird (z.B. wenn ein Benutzer spezielle Erfahrungen gesammelt hat).
Solution
Deshalb: Verbinde die Aufgabe mit einer Meeting Area. Lassen Sie Benutzern ihre Repräsentationen bei dem Treffpunkt
platzieren, um zu signalisieren, dass sie die Aufgabe lösen
möchten. Informieren Sie alle wartenden Benutzer, sobald
sich genügend Anwender an der Meeting Area befinden und
erlauben Sie den wartenden Benutzern die Kollaboration zu
starten.
Collaborations
Der Benutzer navigiert zunächst zur Meeting Area. Die Meeting Area
ist eine Beschreibung der Aufgabe. In den meisten Fällen steht sie
in Beziehung zu einem bestimmten Anwendungskontext. Beispiele für
einen Kontext könnten eine Lehrstunde im Verlauf eines Kurses oder
eine spezielle Erfahrungsstufe in einem Mehrbenutzerspiel sein.
Wenn der Benutzer sich entscheidet, die Aufgabe zu lösen, stellt er
seinen Avatar in die Meeting Area. Technisch gesehen wird das Objekt
des Benutzer in eine Liste mit Benutzern, die bereit sind, gestellt.
Sobald sich genügend Benutzer an der Meeting Area befinden (d.h.,
die Liste der wartenden Benutzer hat eine ausreichende Größe) initiiert das Systeme eine kollaborative Session und fügt alle wartenden
Benutzer zu dieser hinzu.
Rationale
Verglichen mit anderen Mitteln der Gruppenbildung, in denen Benutzer ihre Partner unter Berücksichtigung der Persönlichkeiten (oder
Fähigkeiten) auswählen, bringt das Entwurfsmuster Blind Date Benutzer, abhängig von ihrer zeitlichen Verfügbarkeit zur Lösung einer
bestimmten Aufgabe, zusammen.
Der Vorteil dabei ist, dass Benutzer sich nicht kennen müssen.
Check
– Wie soll die Meeting Area visualisiert werden?
– Wird die kollaborative Session initiiert sobald genügend Benutzer verfügbar sind, oder sollen die Benutzer lediglich informiert
werden und die Entscheidung ob eine Gruppe gebildet wird, dem
Benutzer, der sich zuerst in der Meeting Area eingetragen hat,
überlassen werden?
63
Danger Spots
Falls es länger dauert bis andere Benutzer der Meeting Area beitreten, kann der Benutzer vergessen, dass er seine Benutzerrepräsentation
an der Meeting Area platziert hat. Deshalb sollten Sie in Erwägung
ziehen, die Absicht des Benutzers in seiner Benutzerschnittstelle zu
visualisieren.
Es gibt keine Garantie, dass die Gruppe gut zusammenarbeitet. Sie
sollten über Mittel zum Verlassen der Gruppe nachdenken.
Known Uses
World of Warcraft ist ein MMORPG in dem manche Aufgaben nur
gemeinschaftlich bewältigt werden können. In dem linken Teil von
Abbildung 5.3 erreicht ein Spieler eine Meeting Area (der Stein
vor dem Spieler). Durch Anwendung des meeting stones bringt
der Spieler sein Interesse zum Ausdruck und wird in die Liste
der wartenden Spieler aufgenommen. Danach kann er fortfahren
die virtuelle Welt zu erkunden. Der Umstand, dass er weiter nach
Partnern für die Aufgabe sucht, wird durch die Verwendung eines
Icons an der Active Map angezeigt (siehe Abbildung 5.3).
4 4 4
Related Patterns Birds of a feather kann verwendet werden, um potentielle Gruppenmitglieder, basierend auf gemeinsame Interessen, zu finden.
Invitation kann verwendet werden, um einen bestimmten Benutzer
explizit zu einer kollaborativen Session einzuladen.
Collaborative Session: Das Blind Date wird dazu verwendet,
die Mitgliedschaft für eine Collaborative Session bereitzustellen.
64
Abbildung 5.3.: Ein Meeting Stone als Implementierung einer
Meeting Area in dem Spiel World of Wacraft
65
5.3. Name Generator
Intent
Generiere für den Benutzer einen gültigen, noch nicht vergebenen Namen.
Context
Sie entwickeln ein kollaboratives System, in dem Benutzer durch eindeutige Namen identifiziert werden.
4 4 4
Problem
Um seine Registrierung für das System abzuschließen muss
der Anwender einen eindeutigen Namen wählen. Je mehr Benutzer angemeldet sind desto mehr Namen sind vergeben. Da
ein Benutzer aber nicht weiß, welche Namen bereits vergeben
sind, bleibt ihm nichts anderes übrig, als einen Namen nach
dem anderen auszuprobieren, bis er einen gefunden hat, der
noch nicht verwendet wird.
Scenario
Peter hat sich sein erstes Auto gekauft und ist ganz stolz darauf. Jetzt
muss er noch zur Zulassungsstelle, um sein Auto anzumelden. Dort angekommen übergibt er dem Schalterbeamten die erforderlichen Unterlagen und teilt ihm auch den Wunsch auf ein besonderes Kennzeichen
mit. Der Schalterbeamte stellt nach einer kurzen Überprüfung in seinem System fest, dass dieses Kennzeichen bereits vergeben ist. Peter
ist enttäuscht, da er sich sehr auf das Kennzeichen gefreut hatte. Jetzt
fällt ihm keine Alternative ein, und wenn doch, wer garantiert ihm,
dass dieses Kennzeichen nicht auch schon vergeben ist? Dann werden
seine Gedanken vom Schalterbeamten unterbrochen. Dieser nennt ihm
ein paar Kennzeichen, die seinem Wunschkennzeichen sehr ähnlich sind
und versichert ihm, dass diese alle noch zu haben sind. Nach kurzem
Zögern, entscheidet sich Peter für eines dieser Kennzeichen. Zwar ist
es nicht genau das Kennzeichen, welches er sich gewünscht hat, aber
er muss sich nicht mehr weiter über die Auswahl eines Kennzeichens
den Kopf zerbrechen.
66
Symptoms
wenn . . .
– das System eine sehr große Anzahl an Benutzern erreicht hat.
Solution
Deshalb: Generieren Sie einen Namen der noch nicht verwendet wird. Schlagen Sie diesen Namen dem Benutzer vor.
Collaborations
Innerhalb des Formulars für eine Registrierung existiert ein Textfeld,
in dem der Benutzer seinen gewünschten Benutzernamen einträgt. Sobald der Benutzer den Namen bestätigt, prüft das System, ob der
Name noch nicht verwendet wird. Ist der Name bereits vergeben, generiert das System einen Benutzernamen, der noch nicht verwendet
wird, und schlägt diesen Namen dem Benutzer als Alternative zu dessen gewünschten Namen vor. Dabei weist das System darauf hin, dass
der andere Name bereits vergeben ist. Auf Wunsch kann der Anwender
sich weitere Namen generieren lassen.
Rationale
Ob beruflich oder privat, Benutzer müssen für Anwendungen oft einen
eindeutigen Benutzernamen angeben. Es ist umständlich für die Benutzer sich immer wieder neue Benutzernamen auszudenken. Deswegen verwenden sie häufig ihren eigenen Namen. In Systemen mit großer
Benutzerzahl sind solche Namen in der Regel bereits vergeben. Dem
Benutzer bleibt in diesem Fall nichts anderes übrig, als nach einem
neuen Namen zu suchen, falls er die Dienste des Systems in Anspruch
nehmen will. Ein Generator, der einen neuen Namen generiert, erspart
dem Benutzer diesen Aufwand.
Check
– Kann der Benutzer einen Teil des Namens vorgeben und das System erweitert den Namen, so dass er eindeutig ist?
– Sollen generierte Namen von dem Benutzer abgeändert werden
können?
– Sollen nur Namen generiert werden, die auch wie Namen klingen,
oder sind auch Namen wie rfhtjfjf“ erlaubt?
”
Danger Spots
Werden Namen vom System per Zufall generiert, besteht die
Möglichkeit, dass der generierte Name politisch nicht korrekt ist. Sorgen sie dafür, dass politisch nicht korrekte Namen herausgefiltert werden.
Werden die gleichen Namen immer in der gleichen Reihenfolge vorgeschlagen, besteht die Möglichkeit, dass vermeintlich freie Namen von
67
Benutzern verwendet werden, die sich unmittelbar davor registriert haben.
Known Uses
Anarchy Online ist ein MMORPG, in dem der Spieler mit unterschiedlichen Spielfiguren spielen kann. Bevor er mit einer Spielfigur spielen kann, muss er für jede Spielfigur einige Parameter
auswählen und der Spielfigur einen Namen geben. Dieser Name
muss in der Spielwelt eindeutig sein. Der Spieler hat aber auch
die Möglichkeit sich einen Namen generieren zu lassen (siehe Abbildung 5.4).
Abbildung 5.4.: Name Generator in Anarchy Online.
Star Wars Galaxies ist ein MMORPG, in dem der Spieler, wie in Anarchy Online, Spielfiguren erstellt und ihnen einen eindeutigen
Namen zuweist. Auch hier erhält der Spieler die Möglichkeit, den
Namen generieren zu lassen (siehe Abbildung 5.5).
4 4 4
Related Patterns Quick Registration: Innerhalb einer Quick Registration wählt
der Benutzer seinen eindeutigen Benutzernamen aus.
User Gallery listet alle registrierten Benutzer mit deren Benutzernamen auf.
User List zeigt alle Benutzer einer Session mit deren Benutzernamen
an.
User Profile zeigt persönliche Daten mit dem Benutzernamen eines
Benutzers an.
68
Abbildung 5.5.: Name Generator in Star Wars Galaxies.
69
5.4. Navigator
http://www.flickr.com/photos/elliotzhangyd/69025594/
Alternative name(s): Waypoints
Intent
Visualisiere den Weg zu einem unbekannten Ziel.
Context
Sie entwickeln ein kollaboratives System, in dem sich Anwender innerhalb einer virtuellen Welt bewegen. Um den Anwendern das Gefühl
von einer realen Welt zu geben, verwehren Sie ihnen die Möglichkeit,
sich an beliebige Orte in der virtuellen Welt zu teleportieren.
4 4 4
Problem
Eine Aufgabe erfordert es, dass sich der Benutzer zu einem
bestimmten Zielort begibt, der weder von seiner aktuellen
Position aus sichtbar ist, noch nah genug ist, um in einer
Active Map dargestellt zu werden. Kennt der Benutzer nicht
den Weg zum Zielort, ist es nicht leicht für ihn dorthin zu
finden.
Scenario
Der Entwickler Ralf wird zu einer Vortragsreihe über Extreme Programming nach Berlin eingeladen. Dies ist Ralfs erste Reise nach Berlin, und er kennt nur die Adresse des Veranstaltungsortes. Wie er nach
Berlin gelangt, weiß er, aber wie er in Berlin zu dem Veranstaltungsort kommen soll, weiß er nicht. Deshalb beschließt er, als er in Berlin
angekommen ist, Berliner, die sich dort auskennen, nach dem Weg zu
fragen. Einer der angesprochenen Personen ist so nett und zeichnet
ihm den Weg von seinem Standort bis zum Veranstaltungsort auf ein
Blatt Papier auf. Das einzige was jetzt Ralf noch tun muss, ist diesem
Weg zu folgen.
Symptoms
wenn . . .
70
– Der virtuelle Raum ist so groß, dass es Benutzern schwer fällt,
sich zu orientieren.
– Aufgaben führen Benutzer in einer virtuellen Umgebung an ihnen
unbekannte Orte.
Solution
Deshalb: Visualisieren Sie einen virtuellen Pfad an dem der
Benutzer sich entlang bewegen muss, um an den Zielort zu
gelangen.
Collaborations
Der Benutzer wählt einen Zielort aus. Dadurch wird dem Benutzer ein
Pfad, der von dem Standort des Benutzer bis zum Zielort hin führt,
visualisiert. Für andere Benutzer ist dieser Pfad unsichtbar. Nur der
Punkt des Zielortes bleibt konstant. Der Rest des Pfades ändert sich
mit der Bewegung des Benutzers. Gelangt der Benutzer an den Zielort
wird der Pfad aus der virtuellen Umgebung entfernt.
Rationale
Menschen haben das Bedürfnis auf direktem Weg zu einem Ziel zu
gelangen. Damit Ziele, deren Wege dorthin dem Menschen unbekannt
sind, ohne Umwege erreicht werden können, verwenden Sie Hilfsmittel
wie Strassenkarten, die die Navigation erleichtern oder moderne Navigationsgeräte, die sie komplett übernehmen. Das gleiche Bedürfnis
haben auch Benutzer in virtuellen Umgebungen.
Check
– Wie soll die Navigationshilfe visualisiert werden?
– Für welche Lokationen soll der Benutzer eine Navigationshilfe
erhalten?
Danger Spots
Manche Anwender benötigen keine Orientierungshilfe und empfinden die Navigationshilfe eher als störend. Geben Sie Benutzern die
Möglichkeit, die Navigationshilfe zu deaktivieren.
Known Uses
Everquest 2 ist ein MMORPG mit einer dreidimensionalen virtuellen
Welt. Einige Objekte im Spiel sind als Wegpunkte definiert. Diese
Objekte können Orte oder NPCs1 sein. Wählt der Spieler einen
Wegpunkt aus, führt ein Strahl innerhalb der Spielwelt von der
Spielfigur zum Zielpunkt hin (siehe Abbildung 5.6).
Der Strahl wird permanent angezeigt bis der Spieler das Ziel erreicht hat.
Star Wars Galaxies ist ein MMORPG mit einer dreidimensionalen viruellen Welt. Im Laufe des Spiels erhält der Spieler Aufgaben, die
1
Non-Player-Character: Eine Spielfigur, die von der künstlichen Intelligenz des Spiels gesteuert wird.
71
Abbildung 5.6.: Navigator in Everquest 2.
es zu lösen gilt. Die Aufgaben führen den Spieler an unterschiedliche Orte innerhalb der virtuellen Welt. Ein Strahl ähnlich wie
in Everquest 2 führt den Spieler zu diesen Orten (siehe Abbildung 5.7).
Abbildung 5.7.: Navigator in Star Wars Galaxies.
4 4 4
Related Patterns Travel together ermöglicht den Benutzern gemeinsam den Informationsraum zu erkunden.
72
Virtual Me kann verwendet werden, um dem Benutzer die Bewegung innerhalb einer virtuellen Umgebung zu visualisieren.
73
5.5. Role Indicator
Intent
Context
http://www.flickr.com/photos/gail/131371472/
Visualisieren Sie die Rollen der Benutzer.
Sie entwickeln ein kollaboratives System, in dem Benutzer Rollen zugeordnet werden können.
4 4 4
Problem
Ein Benutzer möchte eine Aktion ausführen. Seine Rolle erlaubt ihm aber nicht die Durchführung dieser Aktion. Da er
auch niemanden kennt, der die geeignete Rolle besitzt, ist es
schwierig für ihn, sein Ziel, die Aktion auszuführen, zeitnah
zu erreichen.
Scenario
Militärische Organisationen haben einen Verhaltenskodex, der unter
anderem beinhaltet, dass rangniedrigere Soldaten vor ranghöheren Soldaten salutieren müssen. Die Soldaten kennen sich aber aufgrund der
hohen Anzahl nur selten persönlich. Damit sie trotzdem den Rang eines
anderen Soldaten erkennen können, besitzt jeder Soldat ein Rangabzeichen auf der Schulter, der den Rang des Soldaten visualisiert. Der
Rang entspricht der Rolle des Soldaten und das Rangabzeichen dem
Role Indicator.
Symptoms
wenn . . .
– Benutzer auf andere Benutzer mit bestimmten Rollen angewiesen
sind.
Solution
Deshalb: Zeigen Sie die Rolle des Benutzers in unmittelbarer
Nähe seines Avatars an, so dass andere Benutzer die Rolle
mit dem Benutzer assoziieren können.
74
Collaborations
Wird ein Avatar eines Benutzers für eine User Gallery, Buddy
List oder in einem anderen Kontext visualisiert, dann wird ebenfalls
festgestellt, welche Rolle der Benutzer hat. Anschließend wird das Symbol, welches der Rolle zugeordnet ist, geladen. Das Symbol wird dann
gemeinsam mit dem Avatar visualisiert.
Rationale
Inhaber von bestimmten Rollen können von anderen Benutzer als Rolleninhaber eindeutig identifiziert werden. Das hat den Vorteil, dass die
Suche nach diesen Benutzern weniger Zeit in Anspruch nimmt. Benutzer gelangen dadurch schneller an ihr Ziel.
Check
– Mit welchen Symbolen sollen die Rollen visualisiert werden?
– Wenn der Benutzer mehr als eine Rolle haben kann, welche Rolle
soll dann visualisiert werden?
Danger Spots
In Systemen, wo wenige Benutzer Rollen besitzen, die Aktionen erlauben, welche von vielen Benutzern nachgefragt werden, kann die Implementierung des Entwurfsmusters Role Indicator dazu führen,
dass sich die Benutzer durch viele Anfragen anderer Benutzer in ihrer
Nutzung des Systems gestört fühlen. Sorgen sie zum Beispiel mit einem Entwurfsmuster wie Attention Screen dafür, dass diese Benutzer Ereignisse, die ihre Aufmerksamkeit beanspruchen, einschränken
können.
Known Uses
World of Warcraft ist ein MMORPG, in dem Spieler in einer kollaborativen Session gemeinsam eine Gruppe bilden können. Einer der
Spieler einer Gruppe ist der Gruppenleiter. Dies wird den anderen
Spieler der Gruppe durch eine Krone am Avatar des Benutzers
visualisiert (siehe Abbildung 5.8).
Abbildung 5.8.: In World of Warcraft werden Gruppenleiter mit
einer Krone am Avatar visualisiert.
75
4 4 4
Related Patterns Role [Fry06] weist Benutzern Rollen zu, die von Role Indicator
anderen Benutzern angezeigt werden.
Attention Screen ermöglicht es dem Benutzer festzulegen, welcher
Typ von Nachricht seine Aufmerksamkeit erhält.
User Gallery: In der User Gallery werden alle Benutzer mit deren Avatare angezeigt.
Hall of fame zeigt die wertvollsten Benutzer des System mit deren
Avataren an.
76
5.6. Spectator
http://www.flickr.com/photos/noqontrol/78000368/
Alternative name(s): Observer
Intent
Erlaube dem Benutzer die Aktivitäten anderer Benutzer zu beobachten.
Context
In einem kollaborativen synchronen System arbeiten Anwender gemeinsam an einem Ziel.
4 4 4
Problem
Neue Benutzer wissen mit der Anwendung nicht richtig umzugehen. Sie führen Aktionen aus, die den Ablauf einer Session in negativer Weise beeinträchtigt.
Scenario
Der kleine Kevin möchte in der lokalen Jugendmannschaft Fußball
spielen. Er ist ein wenig unsicher, weil er nicht weiß, was ihn erwartet.
Sein Vater gibt ihm den Tipp, er solle sich vor einer Anmeldung, einfach mal ein Training anschauen. Es stehe jedem frei, von einer kleine
Tribünen das Training der Mannschaft zu beobachten. Daraufhin besucht Kevin das nächste Training der Mannschaft. Keiner der Spieler
nimmt Notiz von Kevin, der von der Tribüne aus das Training beobachtet. Kevins Anwesenheit hat keinen Einfluss auf das Training, aber
er kann beobachten wie das Training abläuft und sieht wie sich Trainer
und Spieler verhalten. Beim nächsten Training ist er auch dabei und
macht für einen Anfänger verhältnismäßig wenig Fehler.
Symptoms
wenn . . .
– Unerfahrene Benutzer erhalten wenig oder gar keine Akzeptanz
von erfahrenen Anwendern.
77
Solution
Deshalb: Geben Sie dem Anwender die Möglichkeit einer laufenden Session als Beobachter beizutreten, ohne dass seine
Anwesenheit Einfluss auf die Session nehmen kann. Dadurch
erhält er einen Einblick in den Ablauf einer Session, ohne dass
erfahrene Benutzer durch Anfänger-Fehler gestört werden.
Collaborations
Ein Anwender wählt zunächst eine kollaborative Session aus einer Liste laufender kollaborativer Sessions aus. Bevor der Anwender seiner
ausgewählten Session beitritt, erhält er die Möglichkeit zu entscheiden,
ob er der Session regulär beitritt oder als Beobachter. Nachdem er als
Beobachter der Session beigetreten ist, kann er innerhalb der Session
frei navigieren und die Aktionen der Anwender verfolgen.
Rationale
Die Rolle Spectator lässt es nicht zu, dass ein Benutzer Änderungen
im System durchführt. Benutzer, die mit der Anwendung noch nicht
vertraut sind, können sich mit dieser Rolle ein Bild von dem Ablauf
einer Session machen, ohne Gefahr zu laufen, mit falschen Aktionen
die Session negativ zu beeinflussen. Dies führt dazu, dass Anfänger bei
ihrer ersten echten“ Teilnahme weniger Fehler machen, was wiederum
”
bei erfahrenen Anwendern zu mehr Akzeptanz von Anfängern führt.
Check
– Sollten Anwender darüber informiert werden, dass sie jemand beobachtet?
– Dürfen Beobachter mit den Anwendern der Session Kontakt aufnehmen?
– Sollen die Aktionen der Anwender, die zu einem anderen Zustand
der Session führen, dem Spectator explizit angezeigt werden?
Dies könnte den Lerneffekt eines unerfahrenen Benutzers erhöhen.
Danger Spots
Achten Sie darauf, dass Beobachter keine geheimen Objekte anderer
Benutzer sehen können.
Known Uses
Counter Strike Source ist ein MUG, in dem Spieler in einer synchronen kollaborativen Session in Teams gegeneinander antreten. Bevor der Spieler an einem Spiel partizipiert, muss er sich für eines
der beiden Teams entscheiden. Oder aber er schließt sich dem
Spiel als Beobachter an (siehe Abbildung 5.9). In diesem Fall
kann er sich wie ein regulärer Spieler auf dem Spielfeld bewegen,
bekommt aber keine Spielfigur zugewiesen und kann damit auch
keinen Einfluss auf das aktuelle Spiel nehmen.
Entscheidet sich der Spieler dem Spiel als regulärer Spieler beizutreten, wird er als Beobachter entfernt und dem Spiel als regulärer
78
Abbildung 5.9.: Spectator in Counter StrikeSource.
Spieler hinzugefügt, sofern die maximale Spielerzahl nicht erreicht
ist.
Guild Wars ist ein MMORPG, in dem die Spieler neben dem Rollenspiel die Möglichkeit haben in Teams gegeneinander anzutreten.
Die besten Teams können in Meisterschaftsspielen Wettkämpfe
austragen. Die Meisterschaftsspiele können ähnlich wie in Counter Strike Source von anderen Spielern beobachtet werden (siehe
Abbildung 5.10). Allerdings kann ein Beobachter dem Spiel nicht
nachträglich als regulärer Spieler beitreten.
4 4 4
Related Patterns Collaborative Session: In einer Collaborative Session
können Benutzer synchrone Kollaboration planen und koordinieren.
Navigation: Ermöglicht dem Anwender mittels Eingabegeräten
durch die Anwendung zu navigieren.
Role [Fry06] wird einem Anwender zugeordnet. Dieser erhält dann
nur Zugriff auf die Objekte, die für diese Benutzerrolle freigegeben
sind.
79
Abbildung 5.10.: In Guild Wars können Spieler Meisterschaften
beobachten.
80
5.7. Waiting Queue
Intent
Context
http://www.flickr.com/photos/pinelife/161506281/
Stellen Sie Benutzer, die an einer kollaborativen Session teilnehmen
möchte, in eine Warteschlange.
Sie entwickeln ein System, in dem synchrone kollaborative Sessions
teilnehmerbegrenzt sind.
4 4 4
Problem
Ist die maximale Teilnehmerzahl einer kollaborativen Session
erreicht, ist es für den Aspirant schwierig, den richtigen Moment zum Beitritt zur Session zu finden, denn er weiß nicht,
wann einer der Teilnehmer die Session verlässt.
Scenario
An Wochenenden besuchen viele junge Menschen Diskotheken. Bei besonders beliebten Diskotheken ist der Andrang oft größer, als die maximale erlaubte Besucherzahl. Ist die Disco voll, warten neue Aspiranten
vor der Disco darauf, dass Gäste die Discothek verlassen. Hierdurch
bildet sich vor der Diskothek eine Warteschlange, wobei später eintreffende Besucher sich ans Ende der Warteschlange einreihen. Verlässt
ein Gast die Disco darf der Erste aus der Warteschlange die Diskothek
betreten (d.h., je länger ein Aspirant wartet, desto höher steigt die
Wahrscheinlichkeit, dass er die Disco betreten kann).
Symptoms
wenn . . .
– die Anzahl der registrierten Benutzer des Systems die maximale
Teilnehmerzahl einer Session überschreitet.
– die Teilnehmerzahl einer Session häufig die maximale Teilnehmerzahl erreicht.
Solution
Deshalb: Stellen Sie wartende Benutzer in eine Warteschlan-
81
ge. Sobald ein anderer Benutzer die Session verlässt, fügen
Sie den Benutzer, der sich am längsten in der Warteschlange
befindet, der Session hinzu.
Collaborations
Äußert ein Benutzer den Wunsch einer kollaborativen Session beizutreten, prüft das System zunächst ob die maximale Teilnehmerzahl der
Session erreicht ist. Trifft dies zu, wird der Beitritt zur Session unterbrochen und der Benutzer in eine Warteschlange gestellt. Anschließend
wird dem Client des Benutzers, eine Nachricht gesendet, dass er sich
in einer Warteschlange für den Beitritt zu der Session befindet. Der
Benutzer wird automatisch in die Session aufgenommen, wenn alle
Benutzer, die sich vor ihm in Warteschlange befinden, den Zutritt zur
Session erhalten haben und ein weiterer Benutzer die Session verlässt.
Rationale
Wenn sich Benutzer zu einer kollaborativen Session anmelden, möchten
Sie in der Regel unmittelbar mit ihrer Aktivität beginnen. Wiederholt
ergebnislose Versuche zur Anmeldung aufgrund einer überfüllten Session, führen hingegen zur Frustration bei dem Benutzer. Eine Warteschlange gibt ihm das Gefühl gegenüber anderen wartenden Benutzern
eine faire Chance zu bekommen, der Session beizutreten. Außerdem
muss er nicht wiederholt dieselben Aktionen ausführen und kann so
lange er in der Warteschlange ist, andere Dinge erledigen.
Check
– Ist es sinnvoll die Waiting Queue beliebig groß werden zu lassen?
– Gibt es eine Möglichkeit die Dauer bis zum Beitritt in die Session
zuverlässig hochzurechnen?
Danger Spots
Abhängig von der Fluktuation der Benutzer kann eventuell viel Zeit
vergehen, bis der Benutzer von der Waiting Queue in die kollaborative
Session wechseln kann. Darüber hinaus besteht die Möglichkeit, dass
der Benutzer generell nicht auf den Beitritt warten möchte. Geben
Sie deshalb dem Benutzer die Möglichkeit, die Waiting Queue zu
verlassen und den Beitritt abzubrechen.
Known Uses
World of Warcraft ist ein MMORPG, in dem mehrere 1000 Spieler in
einer synchronen kollaborativen Session spielen. Hin und wieder
kann es vorkommen, dass eine kollaborative Session ausgelastet
ist. Meldet sich dann ein Spieler im System an erhält er eine
Nachricht wie sie in Abbildung 5.11 zu sehen ist.
In der ersten Zeile wird der Grund angegeben, warum sich der
82
Abbildung 5.11.: Waiting Loop in World of Warcraft.
Spieler in der Warteschlange befindet. Darauf folgt seine Position
innerhalb der Warteschlange. Zuletzt folgt eine Hochrechnung wie
lange der Spieler warten muss, bis er der Session beitreten kann.
4 4 4
Related Patterns Collaborative Session: Das Entwurfsmuster Waiting Queue
wird dazu verwendet, den Beitritt zu einer Collaborative Session zu koordinieren.
83
5.8. Known Uses in seriösen Anwendungen
Trotzdem die Beschreibung der gefundenen Entwurfsmuster ausreicht, um sie auch in
seriösen Anwendungen zu verwenden, fehlt uns für den Beweis des in Abschnitt 2.4
hergeleiteten Monomorphismus letztendlich noch die Known Uses der Entwurfsmuster in
seriösen Anwendungen. Dies soll nun beispielhaft für einige Entwurfsmuster nachgeholt
werden.
Automatic Software Update hat mit dem Windows Update [Mic06] der aktuellen Betriebssystemversionen von Microsoft einen besonders prominenten Known Use.
Bekannt ist dieser Known Use vor allem deswegen, weil er dazu verwendet wird, Updates
zu installieren, die kritische Sicherheitslücken der Windows Betriebssysteme schließen
sollen. Außerdem lässt sich damit auch die Aktualisierung der Betriebssystemversion
durchführen. Allerdings ist das Window Update nicht mit dem gleichen Zwang verbunden, wie es in den genannten Spielen der Fall ist. Viel mehr hat der Anwender die
Möglichkeit die Funktion das Windows Updates innerhalb eines vorgegebenen Rahmens
zu konfigurieren (siehe Abbildung 5.12). Auf Wunsch lässt es sich auch komplett deaktivieren.
Abbildung 5.12.: Konfiguration des Microsoft Windows Update.
84
Weitere Known Uses von Automatic Software Update findet man in dem WebClient Firefox [Moz02] und in dem Email-Client Thunderbird [Moz05]. Beide bieten
ebenfalls eine Konfiguration des implementierten Entwurfsmusters an (siehe Abbildung
5.13 und 5.14).
Abbildung 5.13.: Konfiguration von Automatic Software Update in Firefox.
Für das Entwurfsmuster Name Generator findet man in der Internetauktionsplattform Ebay [eBa06] einen Known Use. Ebay bietet diesen Service seinen Benutzer bei der
Registierung an. Dort kann der Benutzer überprüfen lassen, ob sein gewünschter Name
vergeben ist. In diesem Fall bietet Ebay dem Benutzer eine Reihe alternativer Namen
an (siehe Abbildung 5.15).
Für das Entwurfsmuster Waiting Queue findet man einen Known Use auf dem
Internet-Portal von IGN Entertainment [IGN06]. Das Portal bietet Informationen rund
um das Thema Computerspiele an. Daneben können auch die Demoversionen der neuesten Spiele heruntergeladen werden. Sind bereits alle Download-Slots einer Demo in
Benutzung, wird man in eine Warteschlange aufgenommen. Gleichzeitig wird angezeigt,
an welcher Position man sich innerhalb der Warteschlange aktuell befindet und eine
Hochrechnung der Zeit bis zum Start des Downloads vergehen wird.
An den aufgeführten Entwurfsmustern zeigt sich, dass Mehrbenutzerspiele durchaus Orte
sind, an dem es sich lohnt nach Entwurfsmustern zu graben.
Die genannten Known Uses aus den seriösen Anwendungen bestätigen die Annahme,
dass ein Monomorphismus zwischen der Pattern Language PLT (die Menge der hier
ausgegrabenen Entwurfsmuster) und den beiden Pattern Languages P4CMI und PIGD
besteht.
Bedenkt man nun, dass die ausgegrabenen Entwurfsmuster ausschließlich aus der Ana-
85
Abbildung 5.14.: Konfiguration von Automatic Software Update in Thunderbird.
lyse der Benutzerschnittstelle gewonnen wurden, die Quelltexte aufgrund der genannten
Mängel für das Ausgraben nicht geeignet sind, weil es dort schon schwierig genug war,
allein bekannte Entwurfsmuster zu identifizieren, und es noch eine handvoll weitere Methoden gibt Entwurfsmuster auszugraben, die hier gar nicht zur Anwendung kommen
konnten, dann wird einem deutlich, welches Potenzial bei der Ausgrabung von neuen
Entwurfsmuster in Computerspielen steckt.
86
Abbildung 5.15.: Realisierung von Name Generator in der Internetauktionsplattform
Ebay.
Abbildung 5.16.: Waiting Queue in einem Portal für Computerspiele.
87
6. Zusammenfassung
Diese Arbeit sollte zeigen, dass es Gemeinsamkeiten zwischen seriösen Anwendungen
und Computerspielen gibt. Der Beweis dieser Theorie sollte dadurch erfolgen, dass man
Entwurfsmuster findet, die in beiden Bereichen anwendbar sind.
Zunächst wurden die zwei Pattern Languages P4CMI und PIGD miteinander verglichen. Dabei stellte sich heraus, dass mindestens zwischen einem Entwurfsmuster aus
jeder der beiden Pattern Languages ein Isomorphismus besteht.
Dann wurde dazu übergangen, Known Uses von Entwurfsmustern aus P4CMI in einer
Reihe von Mehrbenutzerspielen anhand der Benutzerschnittstelle zu identifizieren. Auch
hier gab es ein positives Ergebnis. Es konnte eine signifikante Anzahl an Entwurfsmustern in Mehrbenutzerspielen entdeckt werden. Das Gleiche wurde dann noch einmal
mit Quelltexten von Mehrbenutzerspielen durchgeführt, und erneut bestätigte sich die
Annahme, dass es Gemeinsamkeiten gibt. In beiden Fällen konnten darüber hinaus auch
starke Beziehungen bezüglich der gemeinsamen Entwurfsmuster festgestellt werden.
Schließlich wurde eine handvoll neuer Entwurfsmuster vorgestellt, die während der
Analyse in den Mehrbenutzerspielen ausgegraben wurden, und für die auch Known Uses
in seriösen Anwendungen existieren.
Die Ergebnisse sind doch sehr deutlich und zeigen, dass es Gemeinsamkeiten gibt, und
dass es sich für die Entwickler von seriösen Anwendungen lohnen kann, in Mehrbenutzerspielen nach Entwurfsmuster zu suchen. Umgekehrt gilt natürlich das Gleiche für die
Entwickler von Mehrbenutzerspielen.
In dieser Arbeit wurde lediglich eine Methode zur Ausgrabung von Entwurfsmustern
in Mehrbenutzerspielen angewendet. Wie wir gesehen haben, existieren aber noch eine Reihe anderer Methoden. Zum Beispiel würde es sich anbieten, die Spielentwickler
zu interviewen oder gleich ein Pattern Mining Workshop mit den Spielentwicklern zu
organisieren.
Außerdem konnte ein Großteil der Entwurfsmuster von P4CMI nicht in den Mehrbenutzerspielen identifiziert werden. Hier wäre zum Beispiel eine Prüfung der Anwendbarkeit in den Mehrbenutzerspielen sinnvoll.
Letztlich zeigen die Ergebnisse dieser Arbeit, dass es für die Entwickler beider Welten
sinnvoll ist, nach den Lösungsmöglichkeiten für Probleme in dem jeweils anderen Bereich
zu suchen.
[Ale77]
Alexander, C.: A pattern language. Oxford University Press, 1977
[Ale79]
Alexander, C.: The timeless way of building. Oxford University Press, 1979
[Are05]
ArenaNet: Guild Wars. 2005. – http://de.guildwars.com/
[Ato06a] Atomic Blue Corporation: Planeshift. 2006. – http://www.planeshift.it
[Ato06b] Atomic Blue Corporation: Planeshift. Quelltextversion vom 04.05.2006.
– http://planeshift.cvs.sourceforge.net/planeshift/planeshift/
[Bjö04]
Björk, Staffan: Patterns in Game Design. Charles River Media, 2004
[Bli06]
Blizzard Entertainment: World of Warcraft. (europäische Server) 2006. –
http://www.wow-europe.com/de/
[Cop92] Coplien, James O.: Advance C++ programming styles and idioms. Reading,
MA : Addison-Wesley, 1992
[Cor98]
Corfman, Russel: An overview of Patterns, Cambridge University Press, 1998,
S. 19–29
[DeL98] DeLano, David E.: Patterns Mining, Cambridge University Press, 1998, S.
87–95
[Die06]
Die Welt: Computerspiele-Branche entdeckt die Alten als Zielgruppe. 2006.
– http://www.welt.de/data/2006/08/24/1008151.html
[eBa06]
eBay: eBay. 2006. – http://www.ebay.de
[Epi04]
Epic:
Unreal
Tournament
2004.
http://www.unrealtournament.com/ut2004/index.html
[Fry06]
Frysch, Stephan: Patterns in CSCL Systems. 2006
2004.
–
[Fun01] Funcom: Anarchy Online. 2001. – http://www.anarchy-online.com/
[GHJV97] Gamma, Erich ; Helm, Richard ; Johnson, Ralph ; Vlissides, John: Entwurfsmuster : Elemente wiederverwendbarer objektorientierter Software. Bonn
: Addison-Wesley, 1997
[Gra04] Gravity Corp:
Ragnarok Online.
http://www.euro-ro.net/
(europäische Server) 2004. –
[Id 99a] Id
Software:
Quake
3
Arena.
http://www.idsoftware.com/games/quake/quake3-arena
1999.
–
[Id 99b] Id
Software:
Quake
3
Arena.
ftp://ftp.idsoftware.com/idstuff/source/quake3-1.32b-source.zip
1999.
–
[IGN06] IGN Entertainment: 3DGamers. 2006. – http://www.3dgamers.com/
[KLXH04] Knutsson, B. ; Lu, H. ; Xu, W. ; Hopkins, B. Peer-to-peer support for
massively multiplayer games. 2004
[Koc04] Koch Media:
Carcassonne.
online.de/index2.shtml
[Mic06]
2004. –
http://www.carcassonne-
Microsoft: Windows Update. 2006. – http://update.microsoft.com
[Min03] Mindark: Entropia Universe. 2003. – http://www.project-entropia.com/
[Moz02] Mozilla Foundation:
Firefox.
europe.org/de/products/firefox/
2002. –
[Moz05] Mozilla Foundation:
Thunderbird.
europe.org/de/products/thunderbird/
2005. –
http://www.mozillahttp://www.mozilla-
[Rau05] von Rauchhaupt, Jens: Die Werbung der Zukunft ist embedded“. 2005. –
”
http://www.adzine.de/1.html
[Rik06a] Riker, Tim: BZFlag. 2006. – http://www.bzflag.org/
[Rik06b] Riker, Tim: BZFlag. 2006. – http://prdownloads.sourceforge.net/bzflag/bzflag2.0.6-20060409.zip?download
[SLht]
Schümmer, T. ; Lukosch, S.: Patterns for computer mediated interaction.
Wiley, noch nicht veröffentlicht
[Son03]
Sony Online Entertainment:
Star Wars Galaxies.
http://starwarsgalaxies.station.sony.com/
[Son04]
Sony Online Entertainment:
http://everquest2.station.sony.com/
[Tur06]
Turbine Games: Dungeon & Dragons Online. 2006. – http://ddo.com
[Ubi03]
Ubi Soft: Scrabble. 2003. – http://www.ubi.com/DE/Games/Info.aspx?pId=966
[Val05]
Valve:
Counter
Strike
Source.
2005.
–
http://storefront.steampowered.com/v2/index.php?area=game&AppId=240
Everquest
2.
2003. –
2004.
–
[ZNR00] Zagal, J. ; Nussbaum, M. ; Rosas, R. A Model to Support the Design of
MultiPlayer Games. 2000
90
Die Namen und Ziele der hier aufgeführten Entwurfsmuster sind wortwörtlich aus einer
nicht finalen Version von [SLht] zitiert. Der Namen befindet sich auf der linken Seite und
rechts davon das Ziel bzw. der Zweck. Entwurfsmuster, bei denen weder ein Problemnoch Solution-Element bestand, wurden weggelassen.
Abbreviation
Reduce the effort involved in written communication by
using short forms for common phrases.
Active Map
Shows a graphical and scaled representation of the space and
enrich this with awareness information.
Active Neighbors
Visualize activities not only on the local user’s current artifact, but also on related artifacts.
Activity Counter
Show how many users interact with a specific unit of
information.
Activity Status Bar
Provide an explanation about other user’s activities while
not yet showing the activity’s intermediate result.
Ask the Author
Support readers in clarifying the author’s intention.
Attention Screen
Define, who and what may take the user’s attention.
Authoritative
stance
In-
Allow expert users to act as an authoritative instance and
rate information in the collaboration space.
Availability Status
Indicate to what extent you may be interrupted.
Awareness Proxy
Hook into a client server system to monitor and display awareness information.
Away Message
Inform an active user that a reply to his request will be
delayed.
Believe
Group
in
Your
Change data optimistically and undo the operations if users
performed conflicting changes.
Bell
Inform participants of a session that a user would like to join
the group.
Birds of a Feather
Find the users who have most in common with the requesting user.
Buddy List
Show only selected known users.
Centralized Objects
Allow users to access data objects remotely.
Change Warning
Indicate that the version used by the local user has been
changed by another user.
Collaborative Session
Allow users
collaboration.
Daily Report
Inform the user about changes on relevant artifacts in a user
defined frequency (e.g., once a day).
Detect A Conflicting
Change
Distributed
Command
Don’t Trust Your
Friends
Detect conflicting changes.
Door
Suggest navigation paths and enforce spatial distribution.
Ease to say Goodbye
Make it easy for a user to leave a group.
Elephant’s Brain
Store information on the users’ activities in a log to allow
the users to understand (other) users’ activities and the artifacts’ evolution.
Embedded Chat
Allow users to communicate synchronously with low technology support.
Emote
Let users express personal feelings.
to
plan
and
coordinate
synchronous
Keep all replicas of shared object consistent.
Allow only one user at a time to change a specific part of
the shared state.
92
External Awareness
View
Provide an external awareness information in case that the
visualization of the application cannot (or should not) be
changed.
FAQ
Reduce noise produced by repeated questions.
Feed Facts
Stimulate discussions by adding facts.
Find the Guru
Contact the user who is most likely able to help with a specific artifact.
Flag
Use a flag to recognize important content.
Floor Control
Provide one user with the floor for a set of shared objects
so that he can manipulate the objects while other users are
not allowed to manipulate the objects.
Forum
Provide means
communication.
Hall of Fame
Honor the most helpful participants in the system by showing them in a Hall of Fame.
Hello Hello
List new members of a group or community at a prominent
place and introduce them to other members.
Gaze
Over
Shoulder
Group Award
the
for
persistent
asynchronous
group
Detect the users’ interaction with shared artifacts.
Honor all group members for a result achieved by the group.
Guess What I Need
Reduce network communication costs and response time by
replicating only selected shared objects.
Immutable Versions
Store different versions as a version tree that allows only
additive changes and therefore provides a maximum of concurrent changes.
In-Place Awareness
View
Show the awareness information in a close proximity to the
related artifact to ease the process of connecting awareness information with the semantic context of the referred
artifact.
93
Intelligent Human
Distinguish between automated responses and a real user by
sending him an intellectual challenge.
Interaction Directory
Interactive User Info
List potential interaction contexts.
Interest Agent
Collect relevant group activities for an absent user.
Intimacy Gradient
Structure interaction between people in a way that they can
distinguish between close and loose interaction.
Invitation
Allow users to plan interaction with other users.
Leave Me Alone
Let the user manipulate data without being locally disturbed
by other users who might want to change the same data.
Letter of
mendation
Let the users rate other users regarding their reliability or
expertise.
Recom-
Make the information about other users clickable and
connect it with means for communication and collaboration.
Local Awareness
Provide awareness information in the context of the artifact,
which is in the local user’s focus.
Lock and Key
Provide access to an object or place only if the user can
present a matching key or answering a specific question.
Login
Let users identify themselves before they can use an
application.
Lovely Bags
Use bags for storing shared objects in a container because
they provide the best concurrency behavior.
Mailing List
Provide means for discussion in a geographically distributed
group.
Masquerade
Control how much private information you reveal to other
users when interacting in a collaborative environment.
Mediated Updates
Minimize the administrative load for updates by using a
central instance that dispatches the updates.
94
Mentor
Pair a novice with an experienced member to ease the novice’s integration.
Moderator
Raise the quality of a discussion.
More
Words
than
Multiple
ties
1000
Share graphical content during communication to foster mutual understanding.
Personali-
Allow users to interact with the system even though they
technically look different.
Navigation
Provide mechanisms for moving around in the virtual
environment.
Neighborhood
Watch
Pay Back
Regulate the community using member feedback.
Persistent Session
Make results achieved in a collaborative session available for
re- viewing or resuming collaborative activities.
Personalized Attributes
Presence Indicator
Store different state for each user in a shared object’s state.
Quick Registration
Make it as easy as possible for a user to join a community.
Reciprocity
Ensure that the users benefit, if they contribute to the system. Let the benefit grow, when the user contributes more.
Red Card
Allow users to remove another user from the community.
Remember to Forget
Do not consider activities from the Elephant’s brain, that
are no longer relevant to the users.
Remote Selection
Let remote users know what the local user has selected.
Remote
on
Let the server notify clients about state changes of shared
data.
Reimburse the users’ services in the community by means of
a virtual currency.
Subscripti-
Indicate that remote users look at an artifact, which is visible
on the local user’s screen.
95
Remote Viewport
Provide information to a user in a shared space about the
part of the space that is seen by other users.
Replicate for Freedom
Replicate for Speed
Provide wire- and waveless data access.
Role Reversal
Swap the roles between client and server in a client server
interaction.
Room
Provide the group with a place, where they can meet for
collaboration.
Semantic Net
Use a semantic net, which contains all artifacts and the relations between artifacts to make semantic relations explicit.
Shared Annotation
Provide means for sharing comments for a specific content.
Shared Folder
Allow users to organize their shared data.
Spontaneous
boration
Colla-
Allow users to access data objects without network delay.
Support users to collaborate based on the awareness of other
users.
Team Narrative
Allows users to attach their comments to artifacts.
Telecursor
Allow remote gestures and let remote users know where local
users are working on.
Timeline
Visualize who has been active at a specific point in time.
Threaded
ons
Train the
mender
Discussi-
Recom-
Structure contributions to a discussion in an interaction
space in threads.
Improve recommendations
information.
by
rating
the
proposed
Transform a Conflicting Change
Do not execute a change in the same way as it was performed
by the initiating user but in a way that reflects the replaying
user’s current system state.
Travel Together
Explore an information space together with a team mate.
96
Translator
Automatically translate messages to ease multi-lingual
communication.
Unit of Work
Keep track of all changes during a user’s transaction so that
the changes can be replayed and undone by other clients.
Update Your Friends
Distribute local state changes to the other users to achieve
consistency.
User Gallery
Show who is using a collaborative application.
User List
Show who is currently participating in a session.
Virtual Me
Create a virtual representation of the users’ self that is seen
by other users before and during interaction.
Vote
Quickly test the group’s mood with respect to a specific
question.
What Has Happened
Here?
Replay how the current state of a Collaborative Session
has evolved to update latecomers.
What’s up?
Integrate latecomers in already started interaction.
Who am I
Help a user to understand with which account he is currently
connected to a collaborative system.
Who’s Listening
Show, who received information produced by local user.
Who’s that Girl
Associate a user with messages in your groupware system.
97

Analyse von Entwurfsmustern in Mehrbenutzerspielen

Transcription

Similar documents

Programmieren in Java - oth

Studienarbeit - Institut für Betriebssysteme und Rechnerverbund

Mobilkommunikation

Leopold – Franzens - Universität Analyse des Netzwerkverkehrs von

Kapitel 1