Gryphonheart Professions

Transcription

Christian Warnecke
Addons for support and improvement of roleplaying
in MMORPGs
Master thesis in Digital Media Engineering
Christian Warnecke
Addons for support and improvement of roleplaying
in MMORPGs
Master thesis in Digital Media Engineering
Report produced by:
Christian Warnecke
Supervisor(s)
Michael Rose
DTU Informatics
Technical University of Denmark
Department of Informatics and Mathematical Modeling
Richard Petersens Plads 321
DK-2800 Kgs. Lyngby
Denmark
www.imm.dtu.dk
Tel:
(+45) 45 25 33 51
Fax:
(+45) 45 88 26 73
E-mail: [email protected]
Date Published:
Class:
13. May 2013
1 (public)
Version:
1. version
Notes:
This report is delivered as a part of the requirement for obtaining of Master of Science in Engineering (MSc)at the Technical
University of Denmark. The report reprecents 30 ECTS points.
License
c
Christian
Warnecke ,2013
Abstract
An interesting minority in MMORPG games are players who
take part of active roleplaying with other players. Active roleplaying distinguish itself from normal RPG behaviour by including more immersion, typically by expressing ones character
through communication with other players, acting as the character. The active roleplaying community is most present in World
of Warcaft (WoW). The roleplayers does however face some issues, as the game does not have mechanics that directly support
the roleplay. Such issues is lack of diversity as well as lack of
realism in the roleplay.
In this report a concept is developed to solve or improve on the
issues. The concept is tested in a rapid prototype and afterwards
implemented as a full prototype inside an AddOn.
During the development of the prototype, several technical issues were handled. Solutions were developed for issues such as
Geographical data storage, client to client data sharing and floor
detection in the game world. A tool for unit testing of AddOns
were also developed.
The final prototype were user tested, in addition to the unit
tests done as part of the test driven development used. The
user test showed that the solution has great potential to solve
the problems of lack of diversity and realism in roleplaying, once
implemented in a full version.
2
Reading instructions
The structure of the report is based on normal development flow.
In the first sections (section 1 and 2) the problem is introduced
and it is further analysed in section 3 Problem Analysis. A solution concept is developed in section 4, which is further developed
and specified into requirements in section 5. A prototype is designed and implemented in section 6, which is then tested in
section 7. The test and the overall implementation is evaluated
in section 8. This section also includes short descriptions of the
technical challenges encountered under the implementation. The
details for thse technical challenges are available in appendix D
- G.
3
Contents
1 Technical problem statement
2 Introduction
2.1 Motivation . . . . . .
2.2 Problem statement . .
2.3 Target group . . . . .
2.4 Development structure
.
.
.
.
.
.
.
.
.
.
.
.
9
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3 Problem analysis
3.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Roleplaying mechanics of MMORPGS . . . . . . . . .
3.3 Passive roleplaying and active roleplaying . . . . . . .
3.4 Roleplaying between players . . . . . . . . . . . . . . .
3.5 MMORPGs with active roleplaying between players .
3.6 Lack of diversity . . . . . . . . . . . . . . . . . . . . .
3.7 Lack of interaction . . . . . . . . . . . . . . . . . . . .
3.8 Problematic interface for roleplaying with many people
3.9 Applied solutions . . . . . . . . . . . . . . . . . . . . .
3.10 Conclusion . . . . . . . . . . . . . . . . . . . . . . . .
4 Concept
4.1 Purpose . . . . . . . . . . . . . . .
4.2 Concept Goals . . . . . . . . . . .
4.3 Solution platform . . . . . . . . . .
4.4 Solution Ideas . . . . . . . . . . . .
4.5 Idea selection . . . . . . . . . . . .
4.6 Relevant aesthetics . . . . . . . . .
4.7 Concept description . . . . . . . .
4.8 Dynamics delivering the aesthetics
4.9 Goals for aesthetics and dynamics
4.10 Conclusion . . . . . . . . . . . . .
5 Prototype Requirements
5.1 Purpose . . . . . . . .
5.2 Basis mechanics . . . .
5.3 Mechanics goals . . . .
5.4 Platform . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
10
10
11
11
11
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
present
. . . .
. . . .
13
13
13
13
14
14
15
19
19
20
21
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
22
22
22
22
22
24
24
25
25
26
26
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
30
30
30
30
32
6 Prototype design and implementation
6.1 Purpose . . . . . . . . . . . . . . . . .
6.2 The basic profession system . . . . . .
6.3 Mechanic terms . . . . . . . . . . . . .
6.4 Nearby objects . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
34
34
34
34
34
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6.5
6.6
6.7
6.8
6.9
6.10
6.11
Perform action system . . . .
Hand item to another player .
Normal usage UI . . . . . . .
Creation UI . . . . . . . . . .
Usage scenario . . . . . . . .
Implementation method . . .
Architecture . . . . . . . . . .
7 Prototype test
7.1 Purpose . . . . . . . . . .
7.2 Technical test . . . . . . .
7.3 First prototype test . . . .
7.4 Final prototype usage test
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
35
36
36
37
37
37
38
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
40
40
40
40
41
8 Prototype evaluation
43
8.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
8.2 Overall evaluation . . . . . . . . . . . . . . . . . . . . . . . . 43
8.3 Technical challenges . . . . . . . . . . . . . . . . . . . . . . . 43
9 Conclusion
46
9.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
9.2 Project delimitation and further development . . . . . . . . . 46
9.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
References
48
Appendix
50
A Number of roleplayers across MMORPGS
51
B UI Design sketches
53
C Usage scenarios
60
C.1 Usage Scenario 1 - Mine foreman . . . . . . . . . . . . . . . . 61
D Tool for unit testing lua code for WoW AddOn development
D.1 Problem description and analysis . . . . . . . . . . . . . . . .
D.2 Solution concept . . . . . . . . . . . . . . . . . . . . . . . . .
D.3 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . .
D.4 Test and evaluation . . . . . . . . . . . . . . . . . . . . . . . .
5
64
65
66
68
70
E Floor level determination
E.1 Problem description and analysis
E.2 Existing solutions . . . . . . . . .
E.3 Solution design . . . . . . . . . .
E.4 Solution Implementation . . . . .
E.5 Test and evaluation . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
F Geographical data storage
F.1 Problem description and analysis
F.2 Relevant data structures . . . . .
F.3 Implementation method . . . . .
F.4 Test and evaluation . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
90
. 91
. 92
. 97
. 105
clients
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
G Syncronization of datasets between
G.1 Problem description and analysis .
G.2 Related Solutions . . . . . . . . . .
G.3 Solution development . . . . . . . .
G.4 Implementation . . . . . . . . . . .
G.5 Test and evaluation . . . . . . . . .
H UML Class diagrams
I
AddOn
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
72
73
74
75
77
85
107
108
110
112
115
118
123
User test of the initial prototype - Chat transcript
125
I.1 Odo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
I.2 Shelnara . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
J Final user test
132
J.1 Lancl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
J.2 Hinkerburry . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
J.3 Eddard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
K Final prototype screenshots
142
L GHG Pitch
145
6
List of Figures
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
Predicted development structure . . . . . . . . . . . . . . . . 12
Concept goals . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Goals for aesthetics and dynamics . . . . . . . . . . . . . . . 27
UI sketch for the quickbar showing equipped and nearby objects 54
UI sketch for the Perform Action UI . . . . . . . . . . . . . . 55
UI sketch for the Profession overview part of the main menu.
Example with a ”skill sum” type project . . . . . . . . . . . . 56
UI sketch for the Profession overview part of the main menu.
Example with a ”unlimited” type project . . . . . . . . . . . 57
UI sketch for the Abilities list in the main menu. . . . . . . . 58
UI sketch for the Custom profession list in the main menu. . 59
Unittest Plugin UI . . . . . . . . . . . . . . . . . . . . . . . . 69
State machine example for a house with 3 zones . . . . . . . . 78
Line intersection example . . . . . . . . . . . . . . . . . . . . 78
Line segment intersection test setup . . . . . . . . . . . . . . 83
Staircase example with 3 floor areas . . . . . . . . . . . . . . 83
Floor determination in action . . . . . . . . . . . . . . . . . . 85
Split rules for kd-trees. Source: Songrit and Mount[9] . . . . 93
Example of a kd-tree . . . . . . . . . . . . . . . . . . . . . . . 97
The standard split (above) and sliding midpoint split (below)
applied to the same dataset. . . . . . . . . . . . . . . . . . . . 98
Performance measurements . . . . . . . . . . . . . . . . . . . 106
DHT inspired solution - Scenario 1 . . . . . . . . . . . . . . . 112
Flowdiagram for scenario 1 . . . . . . . . . . . . . . . . . . . 121
Flowdiagram for scenario 2 . . . . . . . . . . . . . . . . . . . 122
UML class diagram for GHP model . . . . . . . . . . . . . . . 124
The quick bar . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Handing an item to another player from the quick bar . . . . 143
The ability page . . . . . . . . . . . . . . . . . . . . . . . . . 144
The perform action UI. In this example the user have added
one additional expression . . . . . . . . . . . . . . . . . . . . 144
7
List of Tables
1
2
3
4
5
6
7
8
9
10
11
12
13
14
Problem, maintenance and solution goals . . . . . . . . . . .
Problem, maintenance and solution goals . . . . . . . . . . .
Object terms and meanings . . . . . . . . . . . . . . . . . . .
Number of estimated roleplayers across different MMORPG
titles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Bugs and issues located in the plugin . . . . . . . . . . . . . .
Runtime for the native implementation . . . . . . . . . . . . .
Runtime for the kd-tree . . . . . . . . . . . . . . . . . . . . .
Runtime for the M-tree implementation . . . . . . . . . . . .
Runtime of the solutions . . . . . . . . . . . . . . . . . . . . .
Data list function example for AbilityList . . . . . . . . . . .
Bittorent solution measurements - Scenario 1 . . . . . . . . .
Native solution measurements - Scenario 1 . . . . . . . . . . .
Bittorent solution measurements - Scenario 2 . . . . . . . . .
Native solution measurements - Scenario 2 . . . . . . . . . . .
8
28
29
35
52
71
92
93
95
114
115
119
119
120
120
1
Technical problem statement
It is the purpose of this project to develop one or more AddOns to improve
the quality of role-playing between players in MMORPGs. The focus of the
report is on the overall software development of the AddOn and the technical
challenges that rises in the development phase. The challenges are:
• There is currently no tool that supports unit testing of the AddOns
in an easy way. It is necessary to develop such a tool to fit into the
normal AddOn development workflow.
• In World of Warcraft, there is no access to the z-coordinate for the
players location. This is a problem when the player is located inside a
multi storage building, as the AddOns does not know what floor the
player is located at. The challenge is to create a system that can determine the player floor location from the relative limited information.
• Some of the data for the AddOn depends on x and y coordinates, for
each data point. It is necessary to develop/research and implement an
efficient way of searching the dataset for all points located close to a
given point.
• A central issues for the AddOn, and earlier AddOns, is datasets that
are used by multiple clients. The AddOns in World of Warcraft does
not have access to a server to store data on. Due to this, it is necessary
to develop a method for sharing and maintaining a dataset between
the clients.
9
2
Introduction
2.1
Motivation
MMORPG (massive multiplayer online role playing games) are in a rapid
development currently and has been so over the last several years. The
games often include a lot of mechanics for combat, both between the player
and the computer / environment (PvE) and combat between the player and
other players (PvP). Except for these combat mechanics, there is little focus on the mechanics in regards to rolepaying. Some games got mechanics
for role-playing between the player and the environment and there is only
few basic mechanics and features for role-playing between players. These
basic features available for role-playing between players are often only chatsystems.
Over several years I, the author, have observed and experienced several
areas with room for improvement and problematic situations related to roleplaying. Many of these could possibly be improved by more or better game
mechanics or tools. These observations are mainly done in the game World
of Warcraft (WoW). Examples of such problems are:
• Little diversity in the theme of the role-playing, which have lead to
players quitting the game.
• Unrealistic amount of players in role-playing in a powerful or heroic
role, compared to normal people. This has lead to a less immersive
world and reduced the quality of the role-playing.
• Players looking for role-playing are observed standing idle in public
locations in the game without successfully getting involved in roleplaying with other players.
While different tools and game mechanic can help problems like this,
experiences have shown that it is a balance act. If the mechanics are too
much in focus, it could take the focus away from the roleplaying between
players itself.
WoW allows the use of 3rd party developed AddOns to modify the UI
of the game. This allow for development of tools and mechanics that can
improve the game areas and problems in relation to role-playing. I, the
author, have created an AddOn which is a platform for creating virtual items
inside WoW, called Gryphonheart Items (GHI). This is already widely used
by roleplayers to create props, such as books or trinkets, to enhance and
support the roleplaying experience. It is the intention to extend and use the
platform to create better AddOns for enhancing the roleplaying experience
for the users.
10
2.2
Problem statement
To improve the quality of roleplaying between players in MMORPGs, problems and issues for these players should be analysed. An AddOn concept,
that can improve or solve these problems in the roleplaying interactions,
should be developed through a feature analysis and requirement development, based on research of the problems.
2.3
Target group
The target group for the final AddOn is role-players in MMORPG’s. A further specialisation of the target group would be active roleplayers, who have
roleplayed for a while, since they would be most interested in improvements,
in order to keep it interesting.
The target group for the technical challenges solved as part of the development of the prototype is other AddOn developers, as they systems might
be used by other AddOns.
2.4
Development structure
The development of a solution to the problem will depend a lot on user
feedback. Due to that it is favourable to develop prototypes etc in an agile
manner. Spiral development is determined to be a suitable solution for the
initial phases. It results in a rapid prototype, which can relatively quickly
be used to determine how suited the solution is. Figure 1 is an initial sketch
of the predicted activities in the first iterations.
While the development take place in a spiral form, with several iterations,
it is documented as one process gathering the development and results for
all iterations.
11
Figure 1: Predicted development structure
12
3
3.1
Problem analysis
Purpose
The purpose of the problem analysis is to research the scale and magnitude
of the problem, as well as investigate what solutions have been applied that
have minimized or solved the problem.
3.2
Roleplaying mechanics of MMORPGS
Major part of MMORPGS is encounters, which is lead by quests and progression systems of different kinds.
Pen and paper roleplaying games (PnPRPG) can be more focussed on the
character development and roleplaying between players. However computer
RPGs does not have the same flexibility, as described by an analysis of The
quest problem[19].
”But there is a crucial difference with computer games that applies to both cases, and that is, not everything is predetermined.
This might seem a banal observation, but it is very important
to consider that pen&paper roleplaying games have a human
gamemaster that constantly adjusts the adventure to the playerss actions, acts as all the non-playing characters showing their
personalities with real-time dialogue, and can even change the
hard rules if something is not convenient for the adventure.”[19]
The hard rules and thus inflexibility of the MMORPGs contributes to
the issue for the roleplaying players. In some games these mechanics have
been made less hard, giving the players a less linear path through the game.
This allows for a bit better roleplaying between a player and NPCs (non
player characters).
3.3
Passive roleplaying and active roleplaying
Roleplaying in MMORPGs can be parted up into two types: active and
passive roleplayers. Passive roleplaying is when players roleplay with their
environment through game mechanics, such as dialogs with NPCs and doing
quests. Active roleplaying is when a player roleplay with their environment
through typed dialog. In some cases a players roleplaying can also be a mix
of the two. E.g. a few players doing a quick (passive roleplay) while spicing
it up with dialog between their characters (active roleplay). The active
roleplaying often requires the presence of other players, but technically it
can be done alone as well.
”I had always assumed that the RP in MMORPG was ironic.
After all, most MMORPGs have had to deliberately set aside
13
designated role-playing servers, and these have always been in
the minority. This suggested that role-playing wasnt something
most players wanted to do in an MMORPG. At the same time,
it was clear that a role-playing subculture existed that operated
with its own rules and etiquette.”[21]
Active roleplaying often requires more work from the participants to keep
flowing and keep alive. There is very limited content, mechanics and help
given by the game itself to inspire and sustain the active roleplaying.
”Role-playing is almost impossible within MMORPGs, even ones
with such a developed world background as World ofWarcraft.
The game absolves itself of responsibility, sets no rules, and gives
no guidelines on how to role-play within its structure. Roleplaying realms are in the minority, with many players choosing
not to or being unable to assume a character within the game.
There are no gains from role-playing. A priest who holds a roleplaying event in a church does not gain extra points.
...
These conditions makes the act of role-play an act of deviance
within the text of World of Warcraft, one which tries to distrub
the game’s gameplay elements.”[5]
3.4
Roleplaying between players
The quest systems and other mechanics allows for some roleplaying between
the player and the environment (the NPCs). Some roleplayers does however
seek roleplaying with other players, but there is much fewer games and
mechanics for that. Especially active roleplaying (see section 3.3) requires
interaction with other players to work.
3.5
MMORPGs with active roleplaying between players
Some mmorpgs have acknowledged the special focus and interests of the
gamers who prefer to engage in active roleplaying inside the MMORPG and
have created specific realms, servers or in other ways separate world instances for these players. This is often accompanied with special rules that
requires players to respect the roleplaying of other players.
An analysis of which MMORPGs have the largest amount of active roleplayers can be seen in appendix A table 4. From the analysis it can be seen
that the majority of the estimated amount of roleplayers is to be found in
World of Warcraft. It could be interesting to research the presence of the
problems in some of the other games with many roleplayers, such as Star
Wars - the old republic and Rift.
14
3.6
Lack of diversity
While playing World of Warcraft (WoW), I have frequently observed comments from other players that confirmed the problem with lack of diversity
in roleplaying (RP). This is also seen on the official World of Warcraft forum.
A frequent comment or complain from roleplayers is the lack of diversity
in the theme of roleplaying. This can be seen mentioned often on the WoW
forums.
”Have to agree, most guilds come down to a military based concept, some form of fighting unit in armour and with surcoats
and the like. Guards, bandits, soldiers, mercenaries, random
elite dudes. There’s more than that, but makes up the most of
the guilds I see anywhere. All the guilds that include Battalion,
Regiment, Order, Guard, Unit, Company and the like in their
names come down to this and I mean no offense to them, clearly
they are successful and popular, but there is not a lot of diversity
between them.
Stomwind for example is a quite well guarded town, but 90% of
the RPers wear armour and carry large/many weapons. Why are
there so few actual civillians? It feels like some sort of military
fort with everyone walking around like a tin can.”1
”Civilians are generally played as alts or based on short-lived
impulse. Those who play civilians full-time and longer than a
few weeks are rare individuals. No ground sturdy enough to
found a long-lasting guild on.” 2
”Problem is, there’s far less for a civilian to react to. A warrior
has many a unique situation - discussing tactics, engaging the
enemy, conflicting morals, battlefield comradeship.
A civilian has very little to play with that we don’t have in our
everyday life. To properly develop, they need other civilians, to
create drama, stories, interesting situations.
Problem is, nobody roleplays civilians. At least, not what’s defined as ”proper” ones.”3
1
http://eu.battle.net/wow/en/forum/topic/3553606041?page=2#24
http://eu.battle.net/wow/en/forum/topic/5616541745
3
http://eu.battle.net/wow/en/forum/topic/5616541745#3
2
15
The lack of economy/profession/civilian related roleplaying is often mentioned by users on the wow forum. Many of the posts involves different ideas
and proposals for systems that could solve the problem on a community basis.
”The problem with using wow’s gold is that it isn’t gained in a
IC manor. As in a general rich noble isn’t going to learn mining
and go travelling hitting rocks with a piece of metal. This would
also give a opportunity for chars to actually gain the gold by
maybe making a shop or something.” 4
”Anyways, the whole point of this post is to try and perhaps
set some rules reguarding in character money, hopefully making
Roleplay easier and alittle more coherant.” 5
The large presence of hero and military based guilds also seems to have
impact on the realism and immersion of the roleplaying. Some players finds
that a problem.
”Today I would like to ask you why we don’t have commoner
roleplay? In my opinipn such roleplay will bring a lot of ”life”
to capital cities making the immertion much better. It would
be great aeeing merchants around with the goods , drunkards
brawling and rest of commoner stuff.
Why we don’t have such roleplayers? Maybe becouse they prefer
to wear shiny armours and titles? Seeing the social pyramid in
roleplay could be interesting enough to see difference in behaving,
their needs and worries.” 6
Different roleplayers have given their own answer to the about the above
question. Some of these are:
”Sure, would be nice to have, but most people, including me,
don’t find roleplaying commoners as fun.” 7
”I whole-heartedly agree with you - it would bring more life to the
greater cities - yet it seems the majority finds it more worthwhile
to RP the ”hero”/”villain” on a slightly more epic scale” 8
4
http://eu.battle.net/wow/en/forum/topic/4552506600?page=1
http://eu.battle.net/wow/en/forum/topic/3980578108
6
7
8
5
16
”It has been initiated - and still is, all the time, by numerous
guilds. Some guilds, I understand, (such as Gutter Runners,
Fablewind Faire) are based entirely on commoner concepts. But
considering the overall consensus of the server, the majority of
players doesn’t seem to find enough thrill in commoner RP, but
rather drift towards military, magic and those high ranks and
fancy titles.” 9
”The major ’issue’ with commoner rp - people have to create
their own rp at the end of the day. Anyhow - what they bring
to rp? Immersion for rpers! I’m sure a civilian reacts more
impressed on a story told by a soldier then if he/she would tell
it to another soldier, just to give a quick example. They make
the world feel more alive. For example; Stormwind would be
horribly dull if only nobles and military chars would remain no?
Just imagine not having TGR around! Who would you have to
chase trough Stormwind to get your pouch back!?
Promoting civilian rp? Well... It is never wrong to promote a
guild or what so ever, yet I simply think there is a lack in interest
in rping these characters, for the reasons given by me above, and
by others. And still the rper is mostly dependant onto creating
their own rp, whereas a lot of people prefer to join military guilds
to get spoon-fed with it.” 10
Some of the initiatives to promote civilian roleplaying have been creation
of guilds (a grouping of 10 to 200 players) with civilian roleplaying themes.
An example of these is The Heedemark Trading Union on the Argent Dawn
(EU) server. An interview was conducted with Reghall, the leader of this
guild.
Q: What themes and experiences do you think brings/brought
players to your guild?
A: Ah, that is a tricky question right away - well, honestly I
think that ”market” rp is something that a lot of people actually find appealing - I know from experience, having a local
medieval fair every year, in general I feel people are interested in
all aspects of their characters lives, making a living and having
a trade is also part of it.
The idea of traveling with a group of fellow merchants bring
9
10
http://eu.battle.net/wow/en/forum/topic/5058396020?page=2#24
17
one to think of fun and good times, at least they do for me.
Sadly I also think that market RP won’t appeal to everyone,
since it usually lack the.. shall we say ”omph” that military RP
- or similar more conflict ridden RP offers.
While market RP also can offer ”conflict” its usually more subtle, and often involves spoken word rather then sword and wand
tips - as it where.
So in short; I think its the idea of living into your character
”more” that brough in players to the guild.
Q: What lack of themes or experiences would you then think
would keep some players from joining the guild?
A: Like I already discussed - I think the lack of ”action” is
something that turns people away - after having talked to several
potential members that rejected the idea because ”It sounds a
bit tame”, I also think that the market RP can put some people
off as it forces you into a more serious mindsetting - some people
enjoy mindless and a bit more, um ”free spirited” RP.
I think, perhaps having something that could ”spice it up” could
be what would bring more people to the table, making it more
action packed I guess.
Q: What do you think makes players go inactive from the guild
or leave the guild?
A: Honestly? I think its down to people not enjoying themselves, if things were going smoothly - and there were things
that they enjoyed, they’d be active - but people generally tend
to put things away once they get boring, and uninteresting - In
hindsight - perhaps introducing ”rewards” or something similar
would have been a way to keep peoples attention, even if its just
breadcrumbs.
Q: Do you believe that a set of game mechanicals suited to support trade and profession roleplaying would improve the situation for the guild?
A: Well, naturally - GHI and TRP2 offered item creation, and
that alone sparked peoples interest - usually people had items
made long before they started selling, of course the opposite were
18
true, people shunned away from downloading addons in general
and instead refused - and even left because of it.
But in general, adding more options in the game, as in say allowing people to have some manner of way to visually improve
their characters trading skills - or in other ways ”enchant” their
trades.
I found that the trading part was shown to be hard - as in,
people usually felt it a bit clunky to emote and -then- trade an
item via the games trading function.
Q: For closing, is there anything you would like to add?
A: Well, I think I covered the most important really so no.
The interview shows that the attempts on creating more diversity in the
roleplaying have faced several issues. Some of these issues were also mentioned in the forum post about the topic. Overall some of the main issues
that stops players from choosing e.g. the role of a civilian is:
• Not much action such as combat
• Lack of development or feeling of progress
• Lack of reason to interact. E.g. merchants having lack of customers
• Too much like the real life
The issues are counterweighted by several positive sides of the civilian RP,
which causes some to try out the civilian RP and a few to stick with it more
permanently.
3.7
Lack of interaction
An interesting observation from inside the game is that roleplayers tend to
gather in specific roleplaying hotspots. At these hotspots some engage in
roleplay with each other, but a surprising amount of the roleplayers present
there seems to be standing still and not interact with other players. They
are however passively seeking roleplay.
3.8
Problematic interface for roleplaying with many people
present
Over my years of roleplaying in WoW I have faced some problems with the
basic interface of the game as a tool for roleplaying. There is only the basic
19
chat/emote system to perform the roleplay. Jill Walker Rettberg, Professor
at University of Bergen, also describes this problem at her blog.
”I think the main problem is that the interface is not at all optimised for role-playing. The visual and gestural interface works
well for fighting and exploring, but is very limited for interpersonal communication other than attacking each other.”11
She had done her observations in a roleplaying event on a roleplaying
server, involving a lot of players, where the amount of communication around
her made individual roleplaying drown in the sea of others roleplaying chat
messages. The user interface (UI) in WoW allows some standard means
of communication, such as normal talk (/say), yelling and whispering to a
specific person. In addition you can also do an emote, which is either a
predetermined action (such as waving) or a custom text, where the player
can describe to others what he/she is doing. This is the same tools as old
text based roleplaying games. Some of the problems with this system can
be:
• There is a lot to read (and easily missed) when there is a lot of people
in one place (as mentioned above).
• It takes a long time to respond with custom emotes.
• There is limited possibility of making character animation etc fit to
the situation.
• It is not possible to see when others are about to say something, resulting in players talking at the same time, creating a fragmented
conversation.
These issues is the everyday of most roleplayers. It can be assumed that
most players have gotten used to working in the environment with these
problems.
3.9
Applied solutions
Roleplaying have been in WoW since it was launched in february 2005.
Over these 7 years the roleplaying have stabilized into the form described so
far, but meanwhile there have been some solutions, in form of AddOns, to
partly solve some of the problems, improve the situation or in general help
the roleplayers.
• A number of different chat addons, allowing for a more pleasant overview
of all the chat.
11
Jill Walker Rettberg, http://jilltxt.net/?p=1638
20
• Different flag addons, allowing roleplayers to display their character
information. E.g. flavor such as their characters lastname, title, appearance and as well if they are currently looking for roleplaying or
not.
• AddOns allowing users to create their own roleplay items (that does
not influence the official game mechanics) such as books, heirlooms or
other props for roleplaying. One of these addons have been developed
by myself, as previous actions to improve on the roleplaying.
There have so far been very little improvement for active roleplayers from
the game developer of WoW (Blizzard entertainment). However some of the
improvements implemented to the passive roleplaying community, which is
the vast majority, have been an improvement for the active roleplayers as
well.
The flag addons includes a solution for the lack of interaction between inactive roleplayers. In the flag addon, they can show that they are interested
in other roleplayers contact them.
3.10
Conclusion
MMORPGs often contains quest or similar encounter systems as their core
mechanics. These systems are designed for players doing passive roleplaying,
but this results in a lack of game mechanics that supports active roleplaying
between players. This gives some problems for active roleplayers such as:
• Lack of diversity in player roleplaying themes
• Lack of interaction between players
• Problematic game interface for roleplaying
21
4
Concept
4.1
Purpose
The purpose is to determine the precise goals of the concept. This includes
the users goals and needs. This allow to create an overview of how the goals
and needs enforces each other or how if they obstruct each other. A concept
design should then be developed based on the goals determined.
4.2
Concept Goals
From the problem analysis the following goals for an overall solution can be
derived. It is not certain that one solution should solve all problems, but
they should be included in the goals, to analyse if they obstruct each other,
to avoid enlarging another problem when solving one.
Among the goals from the problems are also a few maintenance goals,
which can be improved by the solutions to the other goals, but must not be
worsen. The sturcture of the goals can be seen in figure 2. The goals are
listed in table 1.
4.3
Solution platform
As discovered in the estimates of active roleplayer community size (ref),
WoW seems to be the primary target for a solution to these problems. In
addition to this, WoW offers a large degree of open user interface, which
allows for 3rd party AddOns to modify the UI experience. This is however
limited to modifying the user interface, meaning that the 3D game world
can not be interfered with, except for a limited API for the normal UI
functionality. The AddOn execution area is placed in a sandbox, which
restricts it from communication with anything but the provided API.
4.4
Solution Ideas
Civilian Roleplaying
WoW, as well as most other MMORPGs with dedicated RP realms, is based
on a medieval world, with some degree of steam punk and high fantasy elements12 . Since one of the goals for the solution is to improve or at least
maintain realism, it could be a good start to consider how the everyday life
were in the medieval times.
Overall the everyday life of people in the medieval times can be said to
focus on, obtain or maintain wealth or power. That could be through trade,
12
http://en.wikipedia.org/wiki/World of warcraft
22
Figure 2: Concept goals
social hierarchy or religion13 . Looking at the comments by players in ref,
it can be seen that the majority of guilds are military based, which often
got a social hierachy, which seems to be driving force in that concept. This
element could, together with the two others, could be applied to strengthen
civilian RP.
Derived from this, a solution could be to build a system that supports
trade, social hierarchy and religion. This solution would is estimated to be
able to cover most of the goals, to some degree.
Quick replies
One of the issues contributing to the problem regarding interface for roleplaying is the time it takes for a user to reply to other players emotes. E.g.
if two players, who are roleplaying actively, pass each other on a road, one
could nod towards the other one, as a casual greeting. Normally the other
player would like to nod back to the first player as a response.
A solution to the problem could be to implement a system that allows
for a player to respond to such situation with the click of one button, which
then posts a reply. This could however conflict a bit with goal #6 (Maintain
active roleplay), as these automatic responses resembles passive roleplay
mechanics. This conflict could however be limited by letting the player
predetermine the responses to different situations themselves. This would
also maintain the possibility for creativity from the player.
13
http://www.themiddleages.net/people middle ages.html
23
Voice synthesizing of chat
Another issue in the interface for roleplaying can be the immersion of reading
text, which is in general lower than if the sentences were spoken in voice by
an actor.
”More live, voice over dialogs would certainly be a good thing,
and would help you get into character and the environment much
more quickly then reading dialog would.”14
A great improvement to the immersion for roleplayers (Goal #5) could
be to make a system that automatically voice the text of the roleplayers
using speech synthesis. Such system could also be used to voice the in-game
quests and its flavor texts. That solution holds a large potential, as it could
also be of large interest for passive roleplayers, which is that vast majority.
4.5
Idea selection
For the first iteration of spiral development it would be favorable to select
one solution on work on implementation of this one. It is chosen to first
focus on the civilian roleplay solution, since it have potential to also solve
or partly complete goal #3 and its child goals.
4.6
Relevant aesthetics
Goal #9 states that the player should be given the feeling of progress or
similar aesthetics. This term is based on the MDA (mechanics, dynamics,
aesthetics) framework[13]. This framework describes the that the mechanics
(the components of the game) delivers the dynamics (the behavior of the
game) which then results the aesthetics (the emotional response) from the
player.
This framework allows to develop the concept from the aesthetics point
of view, instead of starting from the game mechanics. This results in the
possibility to control that the chosen dynamics and mechanics results in the
desired aesthetics. This is important for this concept, because the goals
requires that the player maintain specific emotional states. A key example
of this is the goal of maintain the focus on active roleplaying. If the system
is implemented with focus on mechanics, such as skinner box methods, it
could very easily result in the user changing into being passive roleplaying
through the mechanics.
A selection of aesthetics that could be relevant for the system for the
idea is:
14
http://us.battle.net/wow/en/forum/topic/6713012679?page=1
24
• Expression - Self discovery (acting out the character in roleplaying)
• Fellowship - Social interaction with other players
• Discovery - Exploration and discovery of, to the player, unknown
things
• Fantasy - Using imagination and creativity to create
• Dependence - Seeking other players dependence on you and reason to
interact with you
• Action - The feeling of high phased and risky interaction
The listed aesthetics can play a key role in the choice of dynamics, in order
to secure the intended reaction from the players.
4.7
Concept description
The system should support trade, social hierarchy and religion. It should
improve the civilian RP by provide action, give the feeling of progress or
similar aesthetics and give more reason for interaction between active roleplayers. The following concept is developed to fit these goals.
A system that allows players to choose one or more professions
in order to gather materials, craft items or perform services for
other roleplayers. The gathering of wealth allow the player to
progress in a social hierarchy. The professions should be tied
together in an economical system, creating demands for goods
and services from other players in order to progress.
4.8
Dynamics delivering the aesthetics
The following is examples of dynamics that can deliver the desired aesthetics
within the concept.
• Expression:
– The player should be able to choose their own combination of
professions. Being a specialist in one, or a jack of all trades.
– The players should be able to define their own profession to fit
their character
– Let the players chosen background have impact on their strengths
and weaknesses
• Fellowship
25
– Encourage players to use networks to get trade relations and improve income.
– Have competition between players
• Discovery
– Ability to discover new combinations of materials to create or
perfect new goods
• Fantasy
– Ability to define your own profession (see expression)
– Inspiring but realistic fantasy items and professions.
– Create more living cities by civilian RP
• Dependence
– Having the economic system result in demand on goods from
other players.
• Action
– Ability to choose a way to obtain items thats include a risk of
loss, but is also more rewarding.
4.9
Goals for aesthetics and dynamics
The concept goals (table 1) can be expanded using the selected aesthetics
and the suggested dynamics. The result is the goal relation seen in figure
4.8 and goals described in table 2.
4.10
Conclusion
The platform for the solution is selected to be world of warcraft, because it
holds the majority of active roleplayers and allows for implementation of 3rd
party AddOns to modify the UI. Three solutions is suggested to solve the
problem: Civilian roleplay system, quick replies and voice synthesizing. The
civilian roleplay system is selected for further development at this point, as
it holds potential to complete the majority of the goals. A set of relevant
aesthetics is selected in order to deliver the desired emotional reaction from
the player using the system. The concept is described and ideas for dynamics
that is delivering the selected aesthetics is pitched.
26
Figure 3: Goals for aesthetics and dynamics
27
No.
#1
Goal
Improve diversity
in RP
#2
Increase interaction
#3
Improve interface
for RP
#4
Maintain / improve realism
Maintain / improve immersion
#5
#6
Maintain
roleplay
active
#7
Improve
RP
civilian
#8
Provide action
#9
Give the feeling of
progress or similar aesthetics
Give more reason
for interaction
#10
#11
#12
Provide a way to
react fast in RP
Provide a way
to for players to
use gestures and
mimics in RP
Description
There should be more diversity in the themes of roleplaying
Inactive roleplayers should be
given more reason, encouragement and help to interact with
other roleplayers.
Improve the user interface
for better interaction between
roleplayers.
The realism of the fantasy
world must be upheld.
The immersion of the roleplayer must be maintained or
improved
The tool should not change
active roleplay into inactive
roleplay
The quality and attractiveness of civilian RP should be
improved
More action should be provided in civilian RP
Civilian RP should have a
feeling of progress or a similar
aesthetics
There should be more reason
to interact with others when
doing civilian RP
There should be a quick way
to react to things in RP.
It should be possible for players to use more detailed gestures and mimics in RP with
other players
Level
Problem
goal
Problem
goal
Problem
goal
Maintenance
goal
Maintenance
goal
Maintenance
goal
Solution
goal
1
Solution
goal
Solution
goal
7, 5
4, 6
7
6
Solution
goal
2, 6, 7
5
Solution
goal
Solution
goal
3, 4, 5
Table 1: Problem, maintenance and solution goals
28
Supp. Obst.
3,4
No.
#13
Goal
Expression
#14
Action
#15
Discovery
#16
Fantasy
Description
Self discovery (acting out the character in
roleplaying)
The feeling of high phased and risky interaction
Exploration and discovery of, to the
player, unknown things
Using imagination and creativity to create
#17
Fellowship
Social interaction with other players
#18
Dependence
#19
Combine
sions
#20
Impact of character background
Custom professions
Optional
risky
gameplay
Seeking other players dependence on you
and reason to interact with you
The player should be able to choose their
own combination of professions. Being a
specialist in one, or a jack of all trades.
Let the players chosen background have
impact on their strengths and weaknesses
The players should be able to define their
own profession to fit their character
Ability to choose a way to obtain items
thats include a risk of loss, but is also more
rewarding.
Ability to discover new combinations of
materials to create or perfect new goods
#21
#22
#23
#24
#25
#26
#27
#28
profes-
Discover
new
recipes / item
combinations
Inspiring but realistic
Living cities
Network for trade
relations
Competition between players
Other players demanding goods
Inspiring but realistic fantasy items and
professions.
Create more living cities by civilian RP
Encourage players to use networks to get
trade relations and improve income.
Have competition between players
Having the economic system result in demand on goods from other players.
Table 2: Problem, maintenance and solution goals
29
Level
Aesthetics
goal
Aesthetics
goal
Aesthetics
goal
Aesthetics
goal
Aesthetics
goal
Aesthetics
goal
Dynamics
goal
Supp.
5, 6, 9
8, 9
9
5, 9
9, 10
9, 10
13
Dynamics 13
goal
Dynamics 13, 16
goal
Dynamics 14
goal
Dynamics 15
goal
Dynamics
goal
Dynamics
goal
Dynamics
goal
Dynamics
goal
Dynamics
goal
16
16
17
17
18
5
Prototype Requirements
5.1
Purpose
The purpose of the prototype requirements is to specify how the prototype
should result in the suggested dynamics (see section 4), by specifying it
mechanics. It is also included to validate that the mechanics does not conflict
with any of the goals. Attentions should be paid to the potential obstructions
illustrated in figure 2.
5.2
Basis mechanics
The concept description describes a profession system that can hold features
which can complete several of the goals. The basic concept contains a selection of professions that either gather items, or craft items out of other items.
The basic functionality have the following functional / mechanics goals:
• Display the users inventory of items.
• Allow the user to trade items with other users.
• Allow the user to select professions from a list of professions
• Each profession contains several different abilities
• Each ability can consume items, require items and / or produce items.
5.3
Mechanics goals
The concept description suggests dynamics about a profession system that
can be interpreted into mechanics goals, which enforces the dynamics. Mechanics that can enforce the dynamics are selected through a brainstorm as
well as a research in already existing games. Each of these mechanics are
then evaluated using de Bonos 6 thinking hats15 .
Goal #19 - Combine professions
The player should be able to choose their own combination of professions.
Being a specialist in one, or a jack of all trades.
• Two tiers professions. You can chose tier 1 and tier 2 of a profession
or tier 1 of two different professions
• Dynamic points. You have a fixed max sum of skill points
15
http://www.debonothinkingsystems.com/tools/6hats.htm
30
Goal #20 - Impact of character background
Let the players chosen background have impact on their strengths and weaknesses
• Let the player select between different perks in each category, such
as race, origination, social status, childhood etc. These perks can be
selected either all at once or over time,
• Let the player choose e.g. 2 traits. Traits can e.g. be a special talent
your character has or a something for his/her upbringing. This is
inspired by the pen and paper RPG called D&D Pathfinder.
Goal #21 - Custom professions
The players should be able to define their own profession to fit their character
• Allow the user to create their own profession within a set of value
rules. E.g. an item with value X should take Y seconds to gather and
should have a rarity of Z.
Goal #22 - Optional risky gameplay
Ability to choose a way to obtain items thats include a risk of loss, but is
also more rewarding.
• A system for committing criminal activity in the roleplay. This adds
the risk of getting caught.
• Make difficult stuff with the risk of failing and thus losing the materials.
Goal #23 - Discover new recipes / item combinations
Ability to discover new combinations of materials to create or perfect new
goods
• Perfect a craft by adjusting the ingredient ratio.
Goal #24 - Inspiring but realistic
Inspiring but realistic fantasy items and professions.
• Let items in the profession system be inspired by ingame locations,
names, cultures etc
31
Goal #25 - Living cities
Create more living cities by civilian RP
• Let players crafting, trading etc result in emotes. It should be non
automatic emotes to avoid conflict with goal #6.
• Let the transportation of wares be realistic, giving more traffic around
cities and on roads, compared to people running or flying quickly between points.
Goal #26 - Network for trade relations
Encourage players to use networks to get trade relations and improve income.
• Give players a game mechanical for handing out credits or discounts
to other players
.
Goal #27 - Competition between players
Have competition between players
• Allow players to offer discounts to other players.
Goal #28 - Other players demanding goods
Having the economic system result in demand on goods from other players.
• Have the different profession depend on each other enough to ensure
the need for trade
5.4
Platform
Over the last few years, I (the author) have developed an addon that makes
it possible for players or other addons to create custom made items. This
system have been designed as a platform for a profession system like this.
The addon is named Gryphonheart Items (or GHI for short) and currently have an estimated user base of around 20.000 users.
In addition to serve as a good platform for the final system, then the
addon also holds a high level interface, intended to be used by creative players. It is possible to use this interface to implement a lightweight prototype,
which can be distributed to user of GHI without further download. This
32
gives the opportunity to test the concept of the prototype in a test community relatively quickly.
The profession system will be implemented under the name Gryphonheart Professions, or GHP for short.
33
6
6.1
Prototype design and implementation
Purpose
The purpose is to determine how the prototype should be implemented.
This includes design of the implemented systems. The section also includes
the implementation of the system.
6.2
The basic profession system
The core of the designed solution is a profession system. A profession system would allow the user to select a profession for a set of professions. Each
profession can then gather or process materials. The materials are then required by other professions and by that by other players.
In general each profession includes several abilities. An ability can require objects or items to be activated and can then produce or modify item
and objects when activated. Examples of this is to mine a mining node.
This would require an object (the mining node) to be nearby and would
require the player to have an item (such as a pick axe) equipped. When the
ability is done, it have then produced an item (the iron ore).
A very basic example is a profession system in which there are two professions: Mining and Blacksmithing. The miner can provided the blacksmith
with metal, but requires tools. The smith can provide the miner with tools,
but requires metal. This system have great possibilities for being scaled as
the development progress, by adding one or more professions.
6.3
Mechanic terms
The prototype includes a lot of different kind of data objects, such as items
and abilities. In table 3 these objects and their meaning are explained.
6.4
Nearby objects
Since AddOns are limited to only interact and modify the user interface of
the game, then they can not modify the game world. This gives a challenge
in terms of how to display what objects (e.g. mining nodes, an anvil, stuff
on the ground etc.) are close to the player.
A solution for the display of nearby objects as a list of icons, where the
first in the list is the closest object. The distance and direction to the object
is displayed in the object tooltip, as text. E.g. ”10 meters north east”. The
list of nearby objects could be combined in a UI with related information,
34
Name:
Item
Ability
Profession
Object
Profession system
Description:
Physical objects that can be
carried
A physical action
An area of expertice where a
person knows a lot
A physical object in the world
that is not intended to move
A set of professions designed
to interact with each other
Example:
A book, a chuck of iron
ore or a pick axe
Fetch water or Mine a
rock
Blacksmith or miner
A cave rock or a large
wooden table
N/A
Table 3: Object terms and meanings
such as equipped items and a menu button. A sketch for this Quick Bar UI
can be seen in appendix B figure 4.
The Quick Bar UI is designed to be small and light weight, since roleplayers in general prefer as little UI as possible while roleplaying. It is the
intention that all interaction with the profession system should follow the
same design as GHI: simple in the top, but advanced in the bottom. This is
achieved by letting the Quick Bar be opened by pressing a button at the side
of the GHI button. From the Quick Bar the user can then dig deeper into the
AddOn by pressing the menu button. Pressing this button shows the menu
for professions overview, abilities etc. (see section 6.7). From that menu,
there are further access to menus for creating professions, attributes etc.
This method of reviling complexity as the user digs deeper down have been
used in GHI, which users have pointed out as a very successful characteristic
of the AddOn.
6.5
Perform action system
A core element in active roleplaying is the typed and creative descriptions
put into emotes16 and says17 . The idea of semi automating this, as part
of the profession, could be relevant, but it would remove the creativity in
roleplaying too easily, which would counter one the purposes of roleplaying (obstruction with goal #6. A better solution is to tie the expressions
(emotions and things said) together with the progress of doing an ability. In
practise this can be done by requesting an expression from the user in order
to let the ability progress.
16
17
orange messages describing an action to characters around you
white message being said, visible to the characters around you
35
The first prototype tests solves the perform UI with a standard dialog
box. In this the player can type what he want to say or emote. Tests
of the prototype shows that this approx confused the user and that it did
not have the roleplaying feel to it. The UI for these expression requests
should then have a stronger connection to the chat boxes normally used for
expression. In order to achieve this familiarity, the design of the UI is based
on the chat box and its simplicity. A concept sketch for this approach can
be seen in appendix B figure 5. It is the regular chat box, but shown in
the middle of the screen, in order to get the users attention. It got a few
additions, such as the ability to select between emote and say, as well as
adding more expressions to be executed after the first one. All functionality
are implemented with a UI design that matches the lightweightness of the
normal chatbox.
6.6
Hand item to another player
A quite central functionality in the system is to give an item in your possession to another player. The GHI AddOn have been dealing with items and
transferring of items between players for years. It uses the normal ingame
trade system for these transfers. The ingame trade system are designed
around ”something for something” trades, which work less well, when the
case of one player wanting to just give a single item to another player. Due
to this, it would be relevant to design a system for handing a single item
to another player. It should be lightweight and have as few steps as possible.
The result is a system where the user can right click on an item equipped
in their main hand and then choose ”hand to ..”. This brings up a list of
the nearby players and the target player can then be chosen. If the player
is nearby, he will receive a dialogbox, asking if he want to accept the item.
6.7
Normal usage UI
It is necessary to have a UI for the normal usage. The functionality of this
UI is to display information about the professions, such as what professions
the player haves, display a list of his abilities (from where the abilities can
be dragged to the normal ingame actionbars) and allow the user to add new
professions to the profession system (see section 6.8.
The user reaches this menu from the quick bar, which means that it can
hold a larger amount of information, but should still be intuitive to use.
Since the game already have similar menus for the official game abilities and
professions, then it could be a good solution to base these menus off their
official counterparts. This ensures that the users will encounter them with
some degree of familiarity. Sketches can for these UI menus can be seen in
36
appendix B figure 6 to 9.
6.8
Creation UI
A central part of the AddOn is the ability for players to be creative and
contribute with their own profession. This is a functionality that might not
be used by every user, but could be used extensively by some users. Based
on the experience drawn from similar menus in GHI, then it is relevant to
design menus on at least two different abstraction levels: A normal menu,
with submenus with more details and a wizard style menu, which guides the
user in creating professions step by step.
6.9
Usage scenario
As the roleplaying experience is quite central, a usage roleplaying scenario
have been developed. It is an example of usage and gives a shows the
intended flow with dialog and AddOn functionality in the roleplaying session.
The scenario include some of the functionality described in the previous
subsections. The usage scenario developed can be seen in appendix C.
6.10
Implementation method
As many of the concept relies on assumptions of the roleplaying community’s reaction on the system, then it is considered a valuable idea to release
a rapid prototype relatively fast in the process to test if the concept holds.
The system can be implemented into GHI by creating an item for each item
and ability in the profession system. The items then holds one or more
scripts and dynamic actions that can be executed, when interacting with
the item or ability. Interaction between the items and abilities can be done
through the GHI API[20]. In this way, the majority of the coding needed is
already given. This method is however only use full for the fast prototype,
as the system is inflexible when more functionality should be implemented.
After the first concept prototype, further prototypes should be implemented in a more permanent and flexible manner, as an AddOn. Lua is
not OO18 , but it is possible to mimic classes using tables. In this way the
solution can be implemented OO. The UI can best be implemented in the
same way as the official game UI is implemented, in XML. An exception
to this is creation menus, which can be faster to implement using the API
provided in GHM19 .
18
19
object orientated
Gryphonheart Menu. A library for menus included in GHI
37
6.11
Architecture
The general architecture is inspired by the MVC20 pattern and can be
summed down as Model-API-UI. The UI calls an API function, which does
checks and modifies or gets information from the model which is returned
to update the UI. The API also works as a security membrane between the
GUI and the Model. This approach is chosen to in order to let the users
scripts also interact with the API. In this way all the functionality that is
presented to the UI can also be presented to the users who seeks to create
special items, abilities or professions that interact with the system. This
gives even stronger possibilities for creativity in the user generated content.
The UI can not be requesting information from the API on every single
frame update, so it is necessary for it to known when data is changed. There
are two relevant approaches to this problem:
1. Let the UI (or script) supply a callback function in the functions. The
api then calls this callback function when data have changed
2. An event system where the UI (or script) registers a function that
should be called when a certain event occurs. The model then executes
all the functions registered for a given event, when this event happens.
It is chosen to implement the event system, as it scales better than the
callback function solution
Many of the objects used in the system (as listed in table 3 are implemented as data objects. It is however relevant for some of these to exist
multiple times. E.g. there is more than one pick axe in the whole system.
Due to this, it is relevant to have instances of this object. A classic way
of doing that would be to have multiple instances of the object where each
instance can be modified. This can however be optimised by using another
system, since most information across instances of the same object would be
the same. This results in a system called Object(Template) - ObjectInstance
- ObjectList. The object serves as a template and holds all the default information. The object instance holds the information that is specific for the
instance. It typically draws the rest of the information from the object. The
object list is used for the objectInstance and other relevant classes to find
the object template. This system is used for all the objects listed in table
3. The names of the three classes are then X, XInstance and XList, where
X is replaced with the name of the object (e.g. Ability or Item).
20
Model-View-Controller
38
The Template-Instance-List pattern can be seen applied in the UML
class diagram for the model in GHP (see appendix H). The pattern is applied to Profession, Abilities, Profession Systems and Objects.
39
7
Prototype test
7.1
Purpose
The purpose of the prototype test is to gather test data that can be used to
evaluate the prototype. The test data can be gathered through a user test.
7.2
Technical test
The implementation of the AddOn have been done mainly through TDD.
This have helped secure the correctness of the implementation to a large
degree. Errors were discovered while implemented. A raw estimate is that
around 50% of the errors had root in the implementation while the other
50% were errors in the unit test itself. In both cases, these were fixed as
part of the implementation.
Some errors slipped past the unit tests and were first discovered in the
ingame tests and the user tests. This were typically errors related to special
cases in the game, not simulated by the unit tests, such as issues with
retrieving coordinates while the user is actively browsing the ingame maps.
There were also some initialization errors, which got discovered when using
the system ingame, such as the kd-tree module not giving correct errors when
an empty tree was attempted created. There were also some errors related
to the interfacing with GHI. These were a variety of both missunderstanding
of the API and direct errors in the API for special cases. In some cases the
GHI API had to be expanded.
7.3
First prototype test
The purpose of the first prototype test is to see if the concept improves the
roleplaying experience as intended. This is checked through an user test.
The first prototype holds three different aspects:
1. The general gathering profession concept
2. Displaying of nearby objects
3. Use emote messages as part of the profession
Each of these aspects should be evaluated in the user test. The test
can be executed by giving the prototype to a few users, with just the basic
instructions abouts its purpose.
Typical questions to the subjects before the test:
• Are you interested in civilian roleplay. Why / why not?
40
Questions for after the test:
• Do you feel that the solution makes profession roleplay more interesting?
• Did the display of nearby and equipped objects work fluently for you?
• How did you feel about the emote driven abilities?
A user test of the initial prototype were carried out on a few test subjects. The transcription of the interviews conducted with them can be seen
in appendix I. In general the user test can conclude that the system have a
good chance of improving the roleplaying for the players interested in doing
civilian roleplaying. It might be less relevant for players who focus less on
civilian roleplaying, but it could inspire more to try it.
The quick bar seems to work well. The users move it to a part of
the screen where it fits in their UI21 . Expressions being tied together with
progress in the professions also seemed to work quite well. It was noted
that some users did not find the connection between the input in the box
and an expression intuitive. The user test resulted in a number of small
improvement suggestions to the UI in general.
The experience from the initial test have been used in the design in the
earlier sections. E.g. the problem with the expression action box not being
very intuitive have resulted in the design choice for the final Perform action
UI.
7.4
Final prototype usage test
In the end of the development of the final prototype, some user testing is
performed. Its purpose is to confirm if the concept fulfils the desired aesthetics (see appendix 4.8). The focus is also on the usability and intuitiveness
of the UI’s in the solutions. Chat transcripts of the usage tests can be seen
in appendix J.
The overall feedback points towards that the concept is relatively solid
and gives a good flow. Players interested in civilian roleplaying seems to be
very positive towards the solution in practise.
”Usually when you roleplay, you use your character as the tool.
You need other players around you to respond to your actions
and emotes and that’s a good thing, too. But what this AddOn
does, is provide you with an invisible participant. - Finally,
21
Depending on settings and what AddOns a player is using, the UI’s can look very
different in layout
41
your character is actually more than just a tool to the roleplay,
it becomes a vibrant part of the play itself. You play with your
character and the AddOn makes your character play back WITH
you as a companion rather than just an empty vessel.” Lancl Argent Dawn (EU)
It is currently lacking many of the features that can fulfil the desired
aesthetics, but the platform is promising. Currently it does give the player
a sence of discovery and realism. The users have expressed that it inspires
profession roleplay and makes it more interesting.
The perform action concept and UI works good according to the players.
That is an improvement over the first perform action UI, where the users
could not see a clear connection to the UI and the expressions posted. The
additional functionality, such as adding several expressions and giving delays seems to cover all the needs.
The ’hand to’ functionality have gotten very positive reactions from the
users. The functionality seems to be a great improvement over the trade
functionality used in GHI. The players confirm that it works a lot better in
the flow of the roleplaying.
The quickbar UI works quite well. Some minor improvements were suggested, such as making it more clear that it can be moved and is not attached
to the GHI bag. The elements of the UI seems to be clear to the users. The
concept of nearby objects (that are never displayed ingame) works well for
the users as well. The tooltip descriptions for direction and distance have
been able to guide the players to the objects location, with only minor problems the first time. It is suggested to improve the UI with a direction arrow.
The user test reviled that some parts of the UI, such as the list of abilities,
were not easy for the users to find. It were not clear that learning the mining
abilities added abilities as well. This could be solved by adding text messages
stated what abilities is learnt. It was also not clear which nearby objects
can be picked up and which cannot.
Some minor bugs have been discovered during the user test. Examples
of this is that the list of nearby object is not sorted by which one of the
objects is closest.
42
8
Prototype evaluation
8.1
Purpose
The purpose is to evaluate the prototype against the problem description
and the goals developed, using the results from the prototype test.
8.2
Overall evaluation
The final prototype have been validated through its TDD. Overall it is a
solid platform to further expand the solution on. It includes some minor
errors that have been corrected, plus room for improvement in regards to
the UI.
In general the TDD have been a great help and ensured correctness. This
have been valuable in the complex parts of the AddOn. It have however been
rather redundant and a huge time sink for simple functions, such as setters /
getters and functions that are parsing information along from other classes.
Due to this the amount of use case coverage have been dwindling for most
areas of the AddOn, while it have been upheld in the technical modules that
have a higher level of complexity.
The goals for the solution were ambitious and mainly fitting a final solution. Yet the prototype display potential to deliver the aesthetics that
are the goal for a full solution. The solution seem to give better conditions
for civilian roleplaying and would, in a full version, be able to create more
diversity in the general RP scene.
8.3
Technical challenges
In the development of the AddOn implemented prototype several technical
difficulties have risen. The most needed and best suited technical challenges
are then further focused on. The problem in each challenge are analysed,
possible related solutions are researched and a solution to the problem are
developed and evaluated.
As it is the intention to develop and validate the AddOn solution using
TDD22 . It does however require an efficient way of implementing and executing unit tests, which is currently not available. This problem is being
handled in appendix D.
The result is a plugin for the IntelliJ IDEA (the IDE used by the
Gryphonheart Team, and others, for AddOn development) which allows
to run and evaluate unit tests following the API for the busted unit testing
22
test driven development
43
framework.
Another issue that raised while developing the prototype was related
to the location of the player in the game world. The data available to the
AddOns in the game are limited to a x and y coordinate, plus flags regarding
if the user is indoor or outdoors, swimming and flying. This is a problem
when players need to interact with nearby objects e.g. in a house. An
object placed close to the player (in x and y coordinates), but on another
floor would be seen as on the same floor.
The solution developed to solve the problem (see appendix E) build on
a concept of parting the relevant buildings into floor zones. E.g. the ground
floor would be zone A, the staircase would be zone B and the top floor would
be zone C. It is then possible to trace the location of a player by detecting
transition between the zones. The solution have been tested to be relatively
robust and easy to scale, since most of the multistory buildings ingame consists of a relatively small amount of models that are reused over and over.
Placing of objects, to be shown in the nearby object list, holds another
issue than just detecting the correct floor location. The native implementation of the list of nearby objects has some performance issues when scaled
up. Finding all nearby objects requires the solution to look through all
placed objects in the world, which could relatively fast be a lot. In order
to counter this, it is required to find a more optimal solution to store this
geographical dependent data.
A solution to this problem were developed in appendix F. The solution
builds on a kd-tree, which is a tree data structure designed for storing data
with coordinates in d dimensions (in this case only 2). The solution implements an special version of the kd-tree that is optimised towards clustered
data. It can be assumed that the objects stored in the solution will be
heavily clustered around buildings and RP hotspots inside the game, which
makes this solution optimal. Implementation of the solution into the final
AddOn went relatively easy and it worked optimally. Some minor issues
were discovered regarding the reaction to an empty tree, which were not
error handled correctly by the kd-tree implementation.
A central issue in the prototype is the issue of sharing and maintaining a
dataset across the different AddOn clients. This is an issue that have been
relevant in earlier AddOn titles in the Gryphonheart series, but the solution
is not efficient enough. It is a non trivial problem because there is no servers
available for the AddOns to store data on, so data can only be stored on the
participating clients. Development of a solution that solves this technical
challenge have been done in appendix G.
The solution developed is inspired by the bittorent protocol. It bases on a
two scenario system: 1, a player has new information he needs to share with
44
everyone and 2, a player logs on and needs to retrieve updated information
from all other players. The solution works as a great improvement compared
to the native implementation in earlier GH AddOns tackling this issue. The
interface for the module is suited towards being coupled with a list class and
share all its data. Implementing the solution into the AddOn have however
reviled that it can not handle partial data sharing, where it is only relevant
to share specific parts of the set with everyone. In GHP that means that
all profession systems, professions etc would be shared will all who have the
AddOn. While this would be quite optimal for getting players to try out
each others crafted professions, it is however very heavy on the memory
usage.
45
9
9.1
Conclusion
Purpose
The purpose of this section is to round up the loose ends of the project and
conclude on the rests with perspective in the goals, the problem statement
and the technical problem statement.
9.2
Project delimitation and further development
Due to time constrains for the project, it is necessary to perform a project
delimitation. Most technical challenges have been overcome as part of the
development of the prototype. The prototype is however greatly limited and
is not yet at a state where it implement the desired dynamics in order to
fulfil the goals intended (see section 4.8). The prototype and the platform
it implements does hold a potential for carrying many of the dynamics that
can delivers on the desired aesthetics. It is relatively easy to implement
these features in the future, since most of the technical difficulties have been
handled, but it still time consuming to do.
Due to the large amount of time that it would take to finish the implementation, then it could be considered if it is enough to let the project be
finished as a free-time project by, as with the previous AddOns. The rules
for WoW AddOns constrains the AddOns for being sold, have premium versions or include advertisement. Due to this, there is no sustainable business
model for WoW AddOns. An alternative could be to let the project rely on
donations. E.g. by creating a kickstarter campaign for the project.
The solutions that have been developed for the technical challenges holds
further potential for being used by other AddOns as well. An an example
the datasharing solution could be used in a wide selection of applications
that requires data. An idea it could realize is called Gryphonheart Groups
(GHG). A pitch for this AddOn can be seen in appendix L.
9.3
Conclusion
Problems and challenges rising for roleplayers in MMORPG have been analysed and it have become evident that there are several different issues that
relate to roleplayers performing active roleplaying on dedicated servers in
MMORPGs, especially World of Warcraft (WoW). Further research have
shown that many roleplayers face issues that are closely related, such as
lack of diversity in roleplaying roles and lack of realism.
A solution concept were designed to improve the conditions regarding these
issues. This concept builds on a supplying mechanics for profession, in order
to give better conditions for civilian roleplaying. The concept is developed
46
using MDA (mechanics - dynamics - aesthetics), which is a framework for
determine the right mechanics to deliver the intended dynamics.
The developed concept were implemented first as a fast prototype into a
series of scripts inside another AddOn, called GHI (Gryphonheart Items).
A series of user tests with this prototype were able to validate that the
concept could possible be a solution to some of the issues. A larger scale
prototype were afterwards implemented into an AddOn, under the name
GHP (Gryphonheart Professions), as it will be drawing upon some of the
functionality in GHI and will be part of the same AddOn series.
In the development of the AddOn several technical challenges were handled.
The first challenge were the lack of proper tool support for test driven development (TDD) of the AddOns. A plugin to IntelliJ IDEA (an IDE used for
development of AddOns) were developed to serve as such as tool. Another
problem were lack of floor or z coordinate information. For this a detection
system were build, which can track when the player changes from one floor
to another in the game. A challenge that had risen in the prototype development, as well as for other AddOns developed before that, is the lack of
a server to store data on. For this a client to client data sharing system,
inspired by Bittorent, were developed. The resulting solution have great potential for further use in AddOns that uses shared datasets. A last challenge
were regarding optimal storing of geographical data. For this, a tailored kdtree solution were implemented, which optimised the performance greatly
compared to the native solution.
The final prototype solution, as well as the solution to most of the technical
challenges, were implemented using TDD. This ensured a high degree of
correctness, especially in the complex parts.
User tests of the final prototype have shown positive reactions for the users.
The solution shows great potential of solving the problems regarding the lack
of diversity and realism in roleplaying. Users that were already interested in
civilian roleplaying shows a greater motivation for roleplaying civilian professions, when using the AddOn.
Overall the solution got a great potential for creating more diversity in
the RP scene of WoW and improve the roleplaying experience for both its
users and other players interacting with its users.
Christian Warnecke
47
References
[1] Franklin Antonio.
Faster line segment intersection, 1992.
http://tog.acm.org/resources/GraphicsGems/gemsiii/insectc.c.
[2] Barfolomeu.
Flighthud,
http://www.wowace.com/addons/flight-hud/.
2013.
[3] Jon Louis Bentley.
Multidimensional binary search trees
used for associative searching. Communications of the ACM,
18(9):509–517, 1975. http://cgi.di.uoa.gr/%7ead/MDE515/p509bentley.pdf.
[4] Bram Cohen.
The bittorrent protocol specification, 2008.
http://www.bittorrent.org/beps/bep 0003.html.
[5] H.G. Corneliussen and J.W. Rettberg. Digital culture, play, and
identity: a World of Warcraft reader. World of Warcraft Reader
Series. Mit Press, 2008.
[6] Jeff Ericson. Non-lecture f: Line segment intersection, 2002.
http://compgeom.cs.uiuc.edu/
jeffe/teaching/373/notes/x06sweepline.pdf.
[7] David Kirk. Graphics Gems: III. Graphics Gems - IBM Series.
AP Professional, 1992.
[8] Olivine Labs.
busted, elegant lua unit testing,
http://olivinelabs.com/busted.
2013.
[9] Songrit Maneewongvatana and David M. Mount. It’s okay
to be skinny, if your friends are fat.
Proceedings of the
4th Annual CGC Workshop on Computational Geometry, 1999.
http://www.cs.umd.edu/%7emount/Papers/cgc99-smpack.pdf.
[10] M.v. Kreveld Mark de Berg, O. Cheong and M. Overmars. Computational Geometry. Springer, 2008.
[11] Marco Patella Paolo Ciaccia and Pavel Zezula. M-tree: An efficient
access method for similarity search in metric spaces. Proceedings
of the 23rd International Conference on Very Large Data Bases,
1997. http://www.vldb.org/conf/1997/P426.PDF.
[12] Iway
Indoor
Positioning.
Iway,
http://www.iway.nl/index.php/en/indoorpositioning-en.
48
2012.
[13] Robert Zubek Robin Hunicke, Marc LeBlanc.
Mda: A
formal approach to game design and game research, 2010.
https://sakai.rutgers.edu/access/content/group/af43d59b-528f42d0-b8e5-70af85c439dc/reading/hunicke 2004.pdf.
[14] Dan Sunday.
Intersections of a set of segments - bentley ottmann algorithm, 2012. http://geomalgorithms.com/a09intersect-3.html#Bentley-Ottmann-Algorithm.
[15] Sasu Tarkoma. Overlay and p2p networks - structured networks
and dhts, 2013. http://www.cs.helsinki.fi/webfm send/1082.
[16] Sasu Tarkoma. Overlay and p2p networks - unstructured networks
i, 2013. http://www.cs.helsinki.fi/webfm send/1052.
[17] Sasu Tarkoma. Overlay and p2p networks - unstructured networks
ii, 2013. http://www.cs.helsinki.fi/webfm send/1056.
[18] David Hoksza Toms Skopal. Improving the performance of
m-tree family by nearest-neighbor graphs.
ADBIS’07 Proceedings of the 11th East European conference on Advances
in databases and information systems, pages 172–188, 2007.
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.134.8046.
[19] Susana Tosca. The quest problem in computer games, 2003.
http://www.itu.dk/people/tosca/quest.htm.
[20] Chrisitan Warnecke.
Pilus.info wiki:
http://pilus.info/index.php?title=API.
Ghi api,
2012.
[21] Nick Yee.
Introduction to the role-playing series, 2006.
http://www.nickyee.com/daedalus/archives/001524.php.
49
Appendix
50
A
Number of roleplayers across
MMORPGS
The following calculations does not take the play patterns and global
player distribution into account. It also assumes an even player distribution across all realms.
1
http://www.wowwiki.com/Realms list
http://www.ign.com/articles/2012/10/04/mists-of-pandaria-pushes-warcraft-subsover-10-million
3
http://www.swtor.com/server-status
4
http://www.mmodata.net/ - oct 2012
5
http://www.inquisitr.com/331128/guild-wars-2-sales-break-two-million-mark/
6
http://www.guildwars2guru.com/news/856-wvw-rankings-as-of-october-26th/
7
http://forums.darkfallonline.com/
8
http://www.guildwars2guru.com/topic/47745-rp-servers/
9
http://forums.ddo.com/
10
http://aoc.wikia.com/wiki/Servers
11
http://na.aiononline.com/about-aion/servers
12
http://forums.na.aiononline.com/na/showthread.php?t=83528
13
http://eu.riftgame.com/en/shardstatus/index.php
14
http://wiki.eveonline.com/en/wiki/Shard
15
http://na.cityofheroes.com/en/news/server status/server status.php
16
http://darkageofcamelot.com/content/rvr-server-types
17
http://forums.lotro.com/index.php
18
List partly selected from http://www.gameogre.com/topmmorpgs.htm
19
Calculated from the total number of players times the normal server to roleplaying
server ratio (percentage)
2
51
Game:
Total
number of
servers/
realms:
Percentage Number
of
RP of
playservers:
ers18 :
7641
Total
number
of
dedicated RP
servers:
581
Estimates
number of
roleplayers19 :
Note:
World
of
Warcraft
7.5%
10.000.0002
750.000
No
RP
servers in
all
Asian
realms
Star Wars.
the old republic
Guild wars
II
203
73
35.0%
1.400.0004
490.000
516
08
N/A
2.000.0005
N/A
D&D Online
Age of Conan
Aion
Rift
EvE Online
City
of
Heroes
Dark Age of
Camelot
Lord
of
the Rings
Online
Warhammer
Online
89
09
N/A
110.0004
N/A
2110
210
9.5%
75.0004
7.000
811
1813
214
1615
012
313
014
015
N/A
16.6%
N/A
N/A
2.400.0004
250.0004
450.0004
125.0004
N/A
41.000
N/A
N/A
1116
016
N/A
30.0004
N/A
2917
317
9.6%
260.0004
25.000
N/A
N/A
N/A
100.0004
N/A
Table 4: Number of estimated roleplayers across different MMORPG titles
52
Number is
number of
total sales
B
UI Design sketches
53
Figure 4: UI sketch for the quickbar showing equipped and nearby objects
54
Figure 5: UI sketch for the Perform Action UI
55
Figure 6: UI sketch for the Profession overview part of the main menu.
Example with a ”skill sum” type project
56
Figure 7: UI sketch for the Profession overview part of the main menu.
Example with a ”unlimited” type project
57
Figure 8: UI sketch for the Abilities list in the main menu.
58
Figure 9: UI sketch for the Custom profession list in the main menu.
59
C
Usage scenarios
60
C.1
Usage Scenario 1 - Mine foreman
Setting: The Azurelode Mine in Hillsbrad Foothill.
A player (John) approaches the foreman of a mine (Peter), who is
standing just outside the entrance to the mine.
Emote: Peter looks towards John as he approaches.
Emote: John nods at Peter.
Peter says: You must be one of the day labourers for the mine, eh?
John says: Yessum. Ah dont know first thing bout that mines and
whats not, but ah aint a weak sissy.
Peter says: Ah, I see, but do not worry about that. I can teach you
the basics of it.
Emote: John nods at Peter and then picks his nose while looking at
him, without realising.
Peter clicks on the Teaching ability in his action bar, which opens the
teaching UI. He then chooses to teach John mining. The UI requests
one or more emotions from him, describing the teaching action he is
doing. He is given the option to also make one or more emotions for
each ability in the profession that are known as basic (spot minerals
etc). It is optional for him to give expressions for each ability. Peter
chooses emote and fills in some text.
Emote: Peter starts to explain the basic of mining to John.
You have been taught [Mining] (profession) by Peter. (Shown only on
Johns screen)
You have taught John [Mining] (profession). (Shown only on Peters
screen)
Peter says: First you try to try and spot the iron veins inside the mine.
Just look for small areas in the mine wall that looks a bit brighter than
rock.
You have been taught [Spot Minerals] by Peter. (Shown only on Johns
screen)
You have taught John [Spot Minerals]. (Shown only on Peters screen)
Peter says: Then when you have found a good spot, just use a [Mining
Pick] to mine the some of the rock in the wall down.
You have been taught [Mine Iron Vein] by Peter. (John)
You have taught John [Mine Iron Vein]. (Peter)
Peter says: From all the chunks and boulders of rocks you then have
to try and separate the iron.
You have been taught [Separate iron ore] by Peter. (John)
You have taught John [Separate iron ore]. (Peter)
Emote: John nods to Peter.
61
John says: Ah think ah got it.
Peter says: Good. Do you have a pick yourself?
John says: No, ah don’t think ah got any.
Peter says: Okay. I have one you can borrow.
Peter opens his bag (in the nearby objects, because he have placed his
bag on the ground near him) and right clicks on an [Iron Pick]. This
displays a drop down menu, where he select Hand to.. and then selects
John. Peter is then requested to fill in an emote, describing the action.
You attempt to hand [Iron Pick] to John. (Peter)
Emote: Peter attempts to hand [Iron Pick] to you. (John)
Emote: Peter takes an [Iron Pick] from his bag and hands it towards
John.
John gets a dialogbox where he can chose to accept it, or reject it. He
accepts and are requested to make an emote, describing that.
Emote: John accepts the [Iron Pick] and holds it in his hand.
The Iron pick is now placed in Johns main hand slot in the Equipped
items ui at the quick bar. Its icon flashes for a moment after it appears.
John says: Alright. Ill get oan it.
Emote: John walks into the mine while whistling.
When inside the mine, John decides to look for minerals. He presses
the book button on the quickbar. This opens a spellbook, where John
looks for the Spot Minerals ability. It is flashing in the spellbook, because he just learned it. John drags the ability into his action bar for
easy access and clicks it. John is then requested an emote, describing
the action. John fills out the emote.
Emote: John stands and looks at the mine wall, trying to spot any iron
ore in the wall.
A cast bar appears and starts to progress. When the cast bar is done
after 30 seconds, a few Iron ore veins appears in the Nearby objects
list in the quickbar. They flash up for a few seconds. In their tooltip
they describe how far they are away (approximately) and the direction
(approximately in directions, north, northeast etc.).
You have discovered 3 [Iron vein]s nearby.
John says: Aha...
John walks in the direction described in the tooltip until it reaches less
than a meters distance. He then right clicks the iron vein. He is request
an emote describing the mining of the node.
Emote: John takes the [Iron pick] and starts to mine down chunks of
the wall.
The cast bar appears and starts to process. While it is processing mining sounds are playing. After the process bar is done, a new object
appears in the nearby objects lists. It is a [Boulders and chunks of
62
rock]. John clicks it and is again requested an emote describing the
action of searching the boulders for rocks.
Emote: John kneels down and starts to sort the small pieces of rock,
looking for chunks of rock he can identify as iron.
The cast bar appears and rumbling sounds can be heard. After the cast
bar is done A small Iron ore appears in the nearby objects. John picks
up the iron ore and puts it in the back.
After repeating this a few times at different nodes, John have gathered plenty of iron ore. He then returns to Peter outside the mine and
hands him the iron ore. John gives him his day pay, for a job well done.
63
D
Tool for unit testing lua
code for WoW AddOn development
64
D.1
Problem description and analysis
Purpose
The purpose of this section is to describe the problem and analyse it.
Description and analysis
Unit tests are widely used to ensure quality in software as well as aid
in its development. In the development of the Gryphonheart AddOns
and other addons, it is desired to use unit tests to raise the quality
and ensure correct implementation of new technical modules. These
technical modules are intended to be implemented using TDD (test
driven development). Currently there aren’t any tools that supports
this completely.
Development of wow AddOns does not require a compiler, so the
development can be done in any text editor. In the Gryphonheart
Team, the development is done in an IDE (integrated developer environment) called IntelliJ IDEA. Through a plugin, it provides several
helpful features, such as syntax highlight, syntax errors and global
function lookups.
65
D.2
Solution concept
Purpose
The purpose is to design a solution concept basic on combinations of
existing tools.
Existing unit test tools
Lua is used for other things than wow AddOns, but a large degree of
this is console applications or scripts. Due to this, the only existing
unit test framework is console based. It is called Busted and supports
lua tests through an API[8]. E.g. a unit test can be created by calling
a describe function with nested it functions. The api includes various
related functions, such as detailed assert and spy functions. Through
a library the system also supports coverage analysis.
Ingame solution
A relevant and basic solution to the problem could be to implement
some test functions that can be executed in the game. These can then
be triggered after the game is loaded and will run the tests.
Overall the solution holds the following advantages and disadvantages. Advantages:
• It relatively easy to implement
• It got all the ingame special functions
Disadvantages:
• It is not that practical to reload environment
• It requires game to run
• It can be hard to simulate more clients
• Adding a file requires the game to be restarted
IDE Plugin solution
Working with the busted library, it is clear that it can be a bit tedious
to run the unit tests, as it requires several console commands. A solution to that could be to make a batch script that runs the console
commands, but it is a more long sighted solution to make a plugin to
66
the IDE used, which then handles the unit tests.
The plugin solution has the following advantages:
• It is easy to reload the environment
• It is possible to create multiple clients
• It does not require the game to run
• The tests run relatively fast, compared to ingame.
The solution has the following disadvantages:
• It requires mocking of in game functions.
• The environment might preform different than the ingame environment in performance.
Solution selection
Based on the solution descriptions it can be seen that the most advantageous solution would be to implement an IDE plugin to manage the
unit tests, using the Busted library. An obvious target IDE for this
would be IntelliJ IDEA, as this already has plugin that gives many
relevant features for wow AddOn developers. This plugin is developed
using JAVA.
67
D.3
Implementation
Purpose
The purpose is to describe the development of the solution, including
its implementation.
Interface with Busted
It is possible to interface with the busted library using CLI (Command
line interface)[8]. It supports many different options. One of the most
relevant ones is to define additional locations for the system to look for
lua files. The result of the run unit test can also be read in the CLI,
where it will be printed.
The java plugin can interface with Busted through a separate process, created though a ProcessBuilder class. It is passed the command
string and then awaits the results printed. The resulting strings are
relatively easily analyzed, since they all follow the same format: A line
with the result for all the tests in the test file and a line with eventual
errors. There are one error line pr failed test. The results are put into
a RunResult object.
Structure of AddOn and its tests
All AddOns have a .toc file, which is a list of all the files the game is
told to load. This is normally created manually by the AddOn author
while developing. The structure of the files used for the Gryphonheart
AddOns is based on its implementation pattern, which is a slightly
modified version of MVC (model-view-controller), with folders such as
GUI, API, Model and Modules. This is supported by default in the
plugin, by letting the busted library look for the lua files in these folders.
In addition to the mentioned folders, there are also a TEST folder.
In these the test files for a corresponding lua file are located, in a
mirrored structure. That means that a test file for Model
MyClass.lua are TEST
Model
MyClass.lua. This separation have been chosen to make it easier to
exclude all test files when packing and deploying an AddOn for the
users.
The file information from the .toc file are used to create FilePair’s
and FilePairDirectories, which then holds all necesary information about
68
Figure 10: Unittest Plugin UI
the lua files in the AddOn and the corresponding test file they are
paired together with.
User interface
It is chosen to let the user interface of the plugin be focussed around
a treeview. This treeview displays the structure of the tests files as
nodes in the tree and then the results for each file as the leafs.
The tree is implemented as a JTree. This includes implementation
of TreeModel and TreeCellRenderer suited to display the tests.
The UI is also given one button to reload all unit tests. The unit
tests are run when the plugin is started, but pressing this button will
rerun it. It is possible to run a particular set by right clicking it and
press Run test.
69
D.4
Test and evaluation
Purpose
The purpose is to test and evaluate the performance and correctness
of the plugin trough long term use.
Test
The plugin have been tested trough five months of use as part of development of AddOns. Minor errors found while use the solution have
been corrected. It have resulted in an overall acceptable correctness of
the solution. The test have revieled a few minor issues and bugs, which
are described in table 5.
Conclusion
A unittest plugin for the IntellJ IDEA IDE were implemented using
JAVA. This plugin interfaces with the Busted library and makes is
possible to run unit tests, that uses the Busted api, inside the IDE.
The plugin were implemented successfully and tested though extensive
usage. Minor bugs and issues were recorded and fitting resolutions were
documented.
70
Description
Syntax errors in the tests in
the test are not displayed.
Possible resolution
This is an error in the analysis
of the test result by Busted.
The test runner should be
modified to catch these errors.
The model should be modified
make it possible to tie an error
to a file pair.
This error can be corrected in
the view code where the tree
is updated.
Running a test with a syntax
error also results in the next
level directory being folded in
the UI.
Long error reports can be
hard to read, since it is all
on one line, no matter of the
length.
This can be fixed in the view
by either let the node be possible more than one line high
or by displaying the full text
in a mouse over tooltip.
This could be fixed by letting
the tests run in a complete
parallel thread. of the UI.
When running tests that takes
a long time, the whole UI
freezes
Table 5: Bugs and issues located in the plugin
71
E
Floor level determination
72
E.1
Purpose
The purpose is to determine and describe the problem in details,
Problem description
The problem is to determine the floor location, in a building, for a person, derived from only the x and y coordinates. The challenge in the
problem is the missing z/height/altitude information for the subject.
The problem occurs for AddOns in the MMORPG World of Warcraft (wow). They can not obtain information about the players zcoordinate, which can be an issue when determining what floor in an
ingame building the player is currently at.
In the case of wow, the x and y coordinates are available with a great
accuracy, down to millimeters. Furthermore the buildings in wow are
standardized. There are a limited number of different multistory building models in the game. These models are then reused many times in
the game world.
In general indoor movement in the game limited to walking/running
and jumping. This means that the solution should handle eventual
balconies that the player can jump off from. It is however not possible
to jump out of windows in the game.
Conclusion
There are no z-coordinate available for wow AddOns. There are however very accurate x,y coordinates and a relatively static game world.
73
E.2
Existing solutions
Purpose
The purpose is to find existing solutions that relates to the problem.
Existing solutions
Due to the special conditions in the problem, there are no existing
complete solutions to the problem.
Flight HUD
Flight HUD is an AddOn for World of Warcraft that displays that
presents flying related information to the player in form of a overlay
display similar to the HUD (heads up display) in fighter jet planes[2].
The AddOn and its methods are mainly useful for flying in wow. It
retrieves information about the flying angle, the speed and direction.
The AddOn does not take collisions into account or if the user is moving sideways or backwards.
The AddOn states clearly that it can not show the z-coordinate, due
to UI limitations. The Z coordinate could be derived from the angle,
speed and direction, but not when the user is colliding with obstacles.
IWAY
Indoor positioning (in real life) is currently in active development.
Google is profiling their maps with indoor features, such as floor plans.
There are also solutions being developed for more precise indoor positioning, such as IWAY. It uses a combination of the wifi and 3G/4G
networks to determine the users position[12].
Conclusion
There are not any complete solution to the problem, but some of the
existing solutions might serve as inspiration for a solution.
74
E.3
Solution design
Purpose
The purpose is to design one or more possible solutions for the problem.
This is based off the problem analysis and the knowledge of existing
solutions. A solution should be selected and it can then be parted up
into subproblems.
Solution for the problem
Altitude derived from change of velocity
It is possible to use the same information as the Flight HUD addon
regarding position, direction and speed. A player walking up a staircase would make his x,y speed change, in the same way that a planes
ground speed changes when flying upwards without its true air speed
changing.
Note that the vertical direction of the user walking in a building is not
available, since the inputs for controlling vertical direction of flying is
not present here.
This concept can be used without knowledge about the buildings,
but it has a few limitations and issues:
• It can not differ between rising and falling, since both would limit
the ground speed
• It does not take collisions with objects/walls into account
Floor level from linked zones
Using the available accurate x,y coordinates a solution could be to
divide a building into zones. The zone of the player could then be
changed when the player crosses different points of interest. E.g. a
staircase or a doorway. Such point of interests could be detected by
the player crossing one or more transition lines.
The downside of this system is that zones and transition lines should
be defined for the building, but this is a minor downside, as the multistory buildings in WoW is based of the same, relatively few, models.
An issue could be to determine the starting position, if the player
starts inside a building. This could however be solved by saving the
75
zone information between each session. It would then only be a problem the first time a player logs in with the AddOn.
The solution can not give any precise z or height coordinate, but
that is not directly required.
Selection of solution
The solution with the fewest issues is the floor level from linked zones.
This solution is the most suited for further research and development.
Conclusion
Two solution concepts were designed. One based on calculating the
altitude from the change in speed when moving upwards. The other
one based on transition over points of interest, such as staircases. The
later one of the solutions are chosen for further development.
76
E.4
Solution Implementation
Purpose
The purpose is to specify the implementation methods for the linked
zones solution, which can then be used for implementation. It should
also include unit test cases, since the unit tests are required part of the
implementation in TDD23 .
Solution Implementation
State machine
The concept with the player position changing from one zone to another if certain properties is fulfilled resembles the concept of a state
machine. An example of such concept is shown in figure 11.
The state machines for buildings would in the worst case have a
total of 5-10 states. Due to this relatively small size, it will not be
relevant with methods for compromising or otherwise optimising the
state machine.
A way to implement this state machine mechanic is with a table of
states, which each have a transition table.
Line intersection
When the state machines eventual transitions are calculated, it can be
done with information about the current location and the new location
(both with x and y coordinates). This information is two points in a
plane and the connection between these two points form a line segment.
The areas of interest that should trigger the transitions between zones
are defined by one or more line segments each. The transition between
two areas / states should then happen if the line segment between the
two coordinates.crosses with a transition line segment.
Line segment intersection problems is a well documented area. Some
algorithms that have been developed to find all intersections between
all line segments have a logarithmic time pr. intersection[10]. It is
however not relevant for this particular problem to find all line segment intersections, since only required to know if the movement line
segment intersects with any of the other segments.
23
Test driven development
77
Figure 11: State machine example for a house with 3 zones
Figure 12: Line intersection example
There are simple methods and algorithms for determining if two
line segment crosses each other, without the intersection point being
calculated, as stated in the following.
Two segments ab and cd intersect if and only if:
• the endpoints a and b are on opposite sides of the line
cd, and
• the endpoints c and d are on opposite sides of the line
ab.
[6]
This is however not enough to test transition from one zone into
another, since this does not take into account that more lines might be
crossed. It might however still be useful, if it is necessary to detect if
two segments cross.
In the above example sa crosses both segment sb and sc . In this case
there is a transition into the other zone, but then back into the first
zone again. There could theoretically be examples where sc could be
78
places in the transition logic of the 2th zone and lead to a transmission
into yet a 3rd zone. In such case it would be relevant to split sa up
into two segments. One from its start to the intersection with sb and
one from the intersection to sb to the end. This is why it is relevant
for the algorithm to calculate the points of intersection and thus why
this simple solution can not be used alone.
An algorithm for locating all intersection points in a set of line segments is the Bentley-Ottmann Algorithm. It is a line sweep algorithm
that works in logarithmic time[14]. It is however only interesting for
this case to find all intersections between a particular segment and all
other segments. Due to this, it would be a bit excessive to find all segment intersections between all segments in the set. A closer look into
the Bently-Ottmann reveals that it calculates the intersection points of
all intersecting segments, without any improvements to that part. As a
result of that it is not efficient using that algorithm. The best solution
is then to calculate the intersections between the movement segment
and all the transition segments. This narrows the problem down to
calculating the intersection points.
Calculating the intersection points between two line segments can
be done in a relatively fast way, using the ’Faster Line Segment Intersection’ algorithm[7]. This algorithm builds on calculating alpha and
beta (ranging from 0 to 1), which denotes the location of the intersection in on each of the lines. The alpha and beta values would then be
outside of the range 0 to 1, if the lines does not intersect. Formula for
intersection between the line segments P1 to P2 and P3 to P4 can be
seen in formula 1. Solving it results in formula 2 and 3.
0 = (P 1 − P 3) + α(P 2 − P 1) + β(P 3 − P 4)
(P 3 − P 4)y × (P 1 − P 3)x − (P 3 − P 4)x × (P 1 − P 3)y
(P 2 − P 1)y × (P 3 − P 4)x − (P 2 − P 1)x × (P 3 − P 4)y
(P 2 − P 1)x × (P 1 − P 3)y − (P 2 − P 1)y × (P 1 − P 3)x
β=
(P 2 − P 1)y × (P 3 − P 4)x − (P 2 − P 1)x × (P 3 − P 4)y
α=
(1)
(2)
(3)
The offset and position of the intersection can be derived from the
alpha and beta values using the methods implemented in the example
provided with Graphics Gems: III[1]. The algorithm implements the
pseudo code seen in algorith 1.
79
Algorithm 1: Calculation of intersection point
Input: d: the numerator of the alpha equation. See formula
2 and 3
e: the beta numerator
f: the common denominator
1
2
3
4
5
6
7
8
9
10
11
12
numx = d * (P2x - P1x)
if numx have same sign as f then
offsetx = f / 2
else
offsetx = - f / 2
numy = d * (P2y - P1y)
if numy have same sign as f then
offsety = f / 2
else
offsety = - f / 2
x = P1x + (numx + offsetx) / f
y = P1y + (numy + offsety) / f
Notice that this pseudo code does not include checks for if the segments intersect at all. If they are parallel, then f would be 0, which
would result in dividing by 0. In the implementation it can be seen
that the following tests, to determine non intersection, should also be
done in the algorithm (see algorithm 2).
Algorithm 2: Intersection validation X
1
2
3
4
5
6
7
8
9
10
11
12
13
14
if P2x - P1x ¡ 0 then
xLowA = P2x
xHighA = P1x
else
xLowA = P1x
xHighA = P2x
if P4x - P3x ¡ 0 then
xLowB = P4x
xHighB = P3x
else
xLowB = P3x
xHighB = P4x
if xHighA ¡ xLowB or xHighB ¡ xLowA then
return No intersection
Algorithm 2 should also be carried out for the Y values. The alpha
and beta values should also be tested, as stated in the pseudo algorithm
80
3.
Algorithm 3: Intersection validation Alpha - Beta
Input: d: the numerator of the alpha equation. See formula
2 and 3
e: the beta numerator
f: the common denominator
1
2
3
4
5
6
7
8
9
10
11
12
if f == 0 then
return
else if if f ¿ 0 then
if d ¡ 0 or d ¿ f then
return
if e ¡ 0 or e ¿ f then
return
else
if d ¿ 0 or d ¡ f then
return
if e ¿ 0 or e ¡ f then
return
Combined the three pieces of pseudo code forms an algorithm that
can determine if the line intersects. On top of this should be an algorithm that determines which segment is crossed first. To ease determination of that, the alpha and beta values could be returned from
the function. Depending on direction and if the movement segment is
P1P2 or P3P4, then this information can be derived from the alpha or
beta value. Note that the crossing direction can be determined from
weather f is positive or negative.
Building location
As mentioned in the solution design, most models for multi-storage
buildings in the game is the same. Due to that, it could be a good solution to have the information stored for each building model, and then
deploy them dynamically for each location / rotation of the building
model ingame.
Determining the model location and rotation in game can be done
by measuring 2-3 easy recognisable points inside the building.
The set of transition segments for the building model can be transposed to fit the building instance ingame by using the location (offset)
81
and rotation. This can be applied using the matrix algebra seen in
formula 4.
0 cos θ − sin θ x
of fx
x
=
+
y0
sin θ cos θ
y
of fy
(4)
This is a quite optimal solution because the information for the
building instance can be narrowed down to the offset (x and y), the
rotation and the building reference, 4 values total. A rotation matrix
can then be calculated just once for all segments in the building. The
rotation matrix and the offset vector can then be applied to all segments
for the building.
Unit test cases
As unit tests are a necessity to start development in TDD, then test
cases should be considered as part of the solution design.
GetLineSegmentIntersection
The function for finding line segment intersections should be unit tested
with variety of different inputs. This includes both positive tests, where
the segments does collide, and negative tests where the segments does
not collide. A structured way to test a lot of possible and relevant
combinations of inputs could be to divide the area around a segment
into subareas and place point of interests there.
Figure 13 is an setup with a segment and points of interest. The
function can be tested extensively. The complete truth table for that
setup can be seen in appendix A. An x denotes a nil value (no intersection). A value describes the estimated alpha/beta value (from 0 to
1) of where the intersection would happen.
FloorDeterminationStateLogic
The state machine for determining the current floor can be tested using
a relatively simple example. This is because the transitions can happen
in relatively few ways. The only special cases is to consider situations
where more than one segment is crossed.
82
Figure 13: Line segment intersection test setup
Figure 14: Staircase example with 3 floor areas
83
The example in figure 14 is based off the looks of staircase in a
building inside the game. There are two special things to notice about
this example:
• It is possible for the player to jump over the railing in the lower
part of the staircase, crossing either from Floor A and onto the
staircase (Floor B) or the other direction. This is represented by
the transition lines between P2 and P4.
• It is possible for the player to jump from a balcony area on top of
the staircase (Floor C) and onto the staircase (Floor C). This is
the reason why the transition line is P1 - P3 instead of P1 - P2.
84
Figure 15: Floor determination in action
E.5
Test and evaluation
Purpose
The purpose is to test and evaluate the implemented concept for floor
determination.
Test results
The solution were implemented into the GHP AddOn as a module using TDD. This places a large portion of the testing into the unit tests.
As described in description of the unit test cases, the tests have a large
coverage for the segment intersection function. It results in a total of
678 unit tests. The state machine implementation also got a reasonable
amount of unit tests. All the unit tests have passed successfully.
Inside the game, the system have been tested with implementation
of a common tavern (of the human race). This building holds two separate staircases, leading from the ground floor to the first floor and to
the basement. The coordinates for the transition points were measured
in-game and it were noted down in the building data. This building
data were tested by inserting two instances of the building in-game and
measure the calculated floor level as the character were moved around
in the building.
85
The tests showed that the floor information does not change at once
after crossing a transition line, but after up to 1 second. That is due to
the chosen delta time. This could easily be increased to create a more
precise tracking.
Conclusion
The solution to the floor detection problem were implemented successfully. The test results are positive and it works as intended, which have
been validated through a relatively large amount of unit tests.
86
Appendix A
Truth table for segment intersection test
1
2
3
4
5
6
7
8
9
10
11
12
13
1
x
x
x
x
x
x
x
x
0
x
x
x
x
2
x
x
x
x
x
x
x
x
0
x
x
x
x
3
x
x
x
x
x
x
x
x
0
x
x
x
x
4
x
x
x
x
x
x
x
x
0
x
x
x
x
5
x
x
x
x
x
x
x
x
0
x
x
x
x
6
x
x
x
x
x
x
x
x
0
0.2
x
x
x
7
x
x
x
x
x
x
x
x
0
0.25
x
x
x
8
x
x
x
x
x
x
x
x
0
0.33
x
x
x
9
1
1
1
1
1
1
1
1
x
1
1
1
1
10
x
x
x
x
x
0.8
0.75
0.67
0
x
0.71
0.52
0.56
11
x
x
x
x
x
x
x
x
0
0.29
x
x
x
12
x
x
x
x
x
x
x
x
0
0.48
x
x
x
13
x
x
x
x
x
x
x
x
0
0.44
x
x
x
14
1
1
1
1
1
1
1
1
x
1
1
1
1
15
0.88
0.81
0.74
0.5
x
0.81
0.78
0.57
0
x
0.71
0.6
0.5
16
0.77
0.65
0.68
0.5
x
0.71
0.69
0.5
0
x
0.63
0.5
0.4
17
0.69
0.64
0.53
x
x
0.63
0.55
0.36
0
x
0.5
0.38
0.29
18
x
x
x
x
x
x
x
x
0
0.5
x
x
x
19
1
1
1
1
1
1
1
1
x
1
1
1
1
20
0.75
0.76
0.66
0.5
x
0.72
0.68
0.5
0
x
0.64
0.5
0.43
21
0.63
0.6
0.48
0.33
x
0.58
0.5
0.32
0
x
0.45
0.31
0.22
22
0.58
0.54
0.45
x
x
0.5
0.42
0.28
0
x
0.37
0.29
0.19
23
x
x
x
0.77
0.5
x
x
x
0
x
x
x
x
24
x
0.75
0.7
0.5
0.25
x
0.67
0.5
0
x
x
0.5
0.5
25
0.6
0.6
0.5
0.3
x
0.55
0.5
0.34
0
x
0.47
0.32
0.26
26
0.55
0.5
0.4
0.25
x
0.46
0.4
0.24
0
x
0.36
0.35
0.19
27
0.5
0.45
0.4
x
x
0.42
0.37
0.25
0
x
0.31
0.23
0.12
27
1
4
15
16
17
18
19 20
21
22
23
24
25
26
1
0
0.12
0.23
0.31
x
0
0.25
0.37
0.42
x
x
0.4
0.45 0.5
2
0
0.19
0.35
0.36
x
0
0.24
0.4
0.46
x
0.25
0.4
0.5
0.55
3
0
0.26
0.32
0.47
x
0
0.34
0.52
0.55
x
0.3
0.5
0.6
0.6
4
0
0.5
0.5
x
x
0
0.5
0.67
x
0.23
0.5
0.7
0.75 x
5
0
x
x
x
x
0
x
x
x
0.5
0.75
x
x
6
0
0.19
0.29
0.37
x
0
0.28
0.42
0.5
x
x
0.45 0.54 0.58
7
0
0.22
0.31
0.45
x
0
0.32
0.5
0.58
x
0.33
0.5
8
0
0.43
0.5
0.64
x
0
0.5
0.68
0.72
x
0.5
0.66 0.76 0.75
9
x
1
1
1
1
x
1
1
1
1
1
1
1
1
10
0
x
x
x
0.5
0
x
x
x
x
x
x
x
x
11
0
0.29
0.38
0.5
x
0
0.36
0.55
0.63
x
x
0.53 0.64 0.69
12
0
0.4
0.5
0.63
x
0
0.5
0.69
0.71
x
0.5
0.68 0.65 0.77
13
0
0.5
0.6
0.71
x
0
0.57
0.78
0.81
x
0.5
0.74 0.81 0.88
14
x
1
1
1
1
x
1
1
1
1
1
1
1
1
15
0
x
x
x
0.44
0
x
x
x
x
x
x
x
x
0.6
x
0.63
16
0
x
x
x
0.48
0
x
x
x
x
x
x
x
x
17
0
x
x
x
0.29
0
x
x
x
x
x
x
x
x
18
0
0.56
0.52
0.71
x
0
0.67
0.75
0.8
x
x
x
x
x
19
x
1
1
1
1
x
1
1
1
1
1
1
1
1
20
0
x
x
x
0.33
0
x
x
x
x
x
x
x
x
21
0
x
x
x
0.25
0
x
x
x
x
x
x
x
x
22
0
x
x
x
0.2
0
x
x
x
x
x
x
x
x
23
0
x
x
x
x
0
x
x
x
x
x
x
x
x
24
0
x
x
x
x
0
x
x
x
x
x
x
x
x
25
0
x
x
x
x
0
x
x
x
x
x
x
x
x
26
0
x
x
x
x
0
x
x
x
x
x
x
x
x
27
0
x
x
x
x
0
x
x
x
x
x
x
x
x
F
Geographical data storage
90
F.1
Purpose
The purpose is to determine and describe the problem in details.
Problem description
The problem is focused on determine the most optimal data structure
for geographical data storage of points. It is desired to storage a large
number of points, with coordinates in two dimensions. The points are
inhomogeneous distributed and have a likelihood of generally being
clustered together around points of interest. It can be assumed that
the majority of the points is known at the point of initialization of the
data structure. New points could be added over time and known points
could be removed or change position. The only query interfacing with
the data structure is to get all points that are within a given radius of
a given vantage point.
An additional optional requirement includes the ability to let each
point have a non-static interaction radius. The query for getting interaction points for the vantage point would in that case result in all
points where the vantage point are within the points interaction radius.
91
F.2
Relevant data structures
purpose
It is the purpose to research relevant data structures that fulfills the
requirements in F.1 relatively efficient.
Native implementation
A native way of solving the data problem is considered as a mark
to compare other solutions to. This native solution builds on looping
trough all points in the set and then return all points that are within the
interaction radius to the vantage point. This method has the following
runtime:
Setup
Insertion
Deletion
Query
Dept
Size
O(1)
O(1)
O(1)
O(n)
N/A
n
Table 6: Runtime for the native implementation
KD-Trees
The KD-Tree is a widely used data structure for storing data in multidimensional spaces. The structure splits the set of points following a
split rule and then handles each of these subsets in the same way as
the original tree. For a two dimensional space, this results in a average
search speed of O(log(n))[3]. A central part of the data structure is
the split rule.
• The standard split works by sorting the points of the cell by
coordinates and then let the lowest half be the left subtree and
the other half be the right subtree. With a two dimensional data
set the odd levels of splitting is sorted by the x-coordinate and
the even is sorted by the y-coordinate. This creates a split that
is most optimal for a homogeneous spread of points.
• The midpoint split splits the given cell by its middle, independent of the location of the points. This gives some empty leafs,
for the fields that does not hold any points.
92
• The sliding midpoint split is an improvement of the midpoint
split, suggested by Songrit and Mount[9]. It works like the midpoint split, except that it places the split, not at the middle of
the cell, but at the point closest to the middle of the cell. This
method is particular efficient for sets of data points that are spread
inhomogeneous.
Figure 16: Split rules for kd-trees. Source: Songrit and Mount[9]
As mentioned, the standard split method is the most optimal for
a homogeneous spread of points, but the typical dataset given has a
inhomogeneous spread of points, as specified in F.1. For a dataset with
these characteristics the sliding midpoint split would be more optimal.
In figure 16 it can be seen how the three different methods splits the cell
in a inhomogeneous dataset. In the areas far from the vantage point,
a query call could very fast conclude that there is no nearby objects.
With the sliding midpoint split rule in a kd-tree, a solution would
still only be able to return all points within a given two dimensional
range. It is required to check which one of these points is within the
request radius afterward, but that does not effect the runtime much. In
total this can be implemented to have to following average performance:
Setup
Insertion
Deletion
Query
Dept
Size
O(n)
O(log(n))
O(log(n))
O(log(n))
log(n)
n
Table 7: Runtime for the kd-tree
93
M-Trees
The M-tree is balanced tree for storing and quiring on data based
metrics (distance functions)[11]. The concept of the tree builds on
dividing the points into M circular areas. The areas is set as nodes
as the first tree. Each of these circular areas has its center in one of
the points. This division is then repeated on each of these circular
areas, creating yet another level in the tree. Some points might serve
as center of a circular areas on more than one level in this structure.
The data structure of each area / subtree holds the following information:
• The pivot point
• The covering radius of the sub tree
• The distance from the point to the parent point
• A pointer to the subtree
The leafs of the tree follows a different structure. It only holds the
point, distance to the parent point and a reference to the data object.
Since the internal nodes are all auxiliary points, the number of leaf
notes are always N.
The amount of subtrees in each internal node is, as mentioned, M,
hence the name M-tree. A typical M value is 3 or 4, as this reduces the
dept of the tree a lot, compared to a M value of 2, but does not effect
the query time for each node a lot, as a high M value would.
If the tree is balanced optimally, the dept of the tree can be expressed by the following:
N = M d−1 ⇔
d = ceiling(
log(N ) + log(M )
)
log(M )
Derived from the layout of the tree, the total amount of notes in an
optimal tree can be calculated from the dept as:
s=N+
d−1
X
M d−2
i=2
The range query, which finds all points within a given range to a
given point, can be done in log(N). This is the query that is most relevant for the solution to the given problem.
94
The setup of the M-tree is performed with recursive insertion over
the given dataset. Insertion into the M-tree can be performed with
O(log n) [18]. Due to that, the setup of the tree can be done in O(log
n * n * 0.5), which can be approximated to O(n log n) or O(log n!).
The query time is approximately O(n) [18]. It is faster than O(n), but
its runtime is rounded down to O(n), since it is not O(log(n)).
In conclusion the M-tree implementation would have the following
average performance:
Setup
Insertion
Deletion
Query
Dept
Size
O(n log n)
O(log n)
O(log n)
O(n)
log(N ) + log(M )
ceiling(
)
log(M )
dept−1
X
N+
M d−2
i=2
Table 8: Runtime for the M-tree implementation
Other solutions
Several other data structure have been researched as possible solutions.
This includes tree structures such as the APD and LSH, who are both
discarded as they are improvements for high dimension problems, while
the given problem only holds 2 dimensions. The VP (vantage point)
tree have also been analyzed, but it is only usable for stationary vantage
point. This is rarely the case in the given problem. A similar structure
to the M-tree, is the ball-tree. It is however optimized for solving the
nearest neighbor problem. This optimization is of little interest to the
solution of the problem.
Solution selection
Based on the gathered information and analysis, the best suiting solution should be selected. The main concern for the evaluation is the
speed of the Query. Secondly it is the Setup, Insertion and Deletion.
Third the memory usage (and thus size of the tree) is considered.
Comparing the native solution6 to the kd-tree7 and the M-tree8,
the following can be concluded.
95
• In query, the kd-tree solution is running in logarithmic time,
which is faster than both the m-tree and native solutions.
• In setup, insertion and deletion the native solution will always be
fastest, as it is running in constant time, due to its simplicity.
• In insertion and deletion both the kd-tree and m-tree solutions
are running at logarithmic speed.
• In the setup the kd-tree is much faster than the m-tree, with linear
speed over an n-logarithmic speed.
Through this comparison it is clear that the kd-tree is the most
efficient implementation. The best suited kd-tree implementation for
this is using the sliding midpoint split.
Conclusion
Several different solutions were researched and the best were proposed
for comparison. This were a kd-tree and a m-tree solution. The two solutions were analyzed in details and compared to each other and to the
native solution. It could be concluded that the kd-tree implementation
has the fastest performance.
96
F.3
Implementation method
Purpose
The purpose is to describe the implementation method of the kd-tree
with sliding midpoint split.
Concept of the kd-tree
As mentioned in F.2, the basic workings of the kd-trees is splitting the
dataset following the first dimension on the first level, second on second
etc. until the number of used dimensions is reached. In a kd-tree for
a two dimensional dataset, that results in all odd levels splits on the
first (x) dimension and all the even on the second (y) dimension. After
the split the lower part of the split is placed in the left subtree and the
higher nodes in the right subtree. This split is repeated recursively.
An example of a kd-tree for 7 nodes can be seen in figure 17.
Figure 17: Example of a kd-tree
Split methods
The basic split is, as mentioned, to sort the points by one dimension.
If the data points are clustered, then it can result in cells from the
clustered areas also covering large amounts of the empty area. As a
result of that, a query in the empty area would have to go trough a
long set of trees, before concluding that there is nothing near that area.
97
In F.2 an alternative split method, the sliding midpoint split method,
where shortly described. This split method focuses on optimization for
clustered data points. The split on a set of points in a cell works as
follows [9]:
1. Consider a median going trough the middle of the cell in the
longest of its sides.
2. If there are points on both sides of the median, then this is the
splitting line. No point is set in the node. The points from the
two sides of the median is set as its two subtrees.
3. If there are only points on one side of the median, then the median
slides toward the first/closest point. This point is set as the node.
The points left are set as its subtree (to the left or right, depending
on where the points are located).
An example of this split algorithm applied can be seen in figure 18.
It can be observed that the tree will become deeper in the clustered
areas. For this impact in a large dataset, see the visualization in figure
16. The sliding midpoint implementation can include that the diagonal
is placed in the direction, so it slices the cell on the longest dimension.
Figure 18: The standard split (above) and sliding midpoint split (below)
applied to the same dataset.
98
Building the kd-tree
Following the given description for the sliding midpoint split, an algorithm for building the kd-tree can be designed. This is described as
psuedo code in algorithm 4.
99
Algorithm 4: BuildKdTree
Input: P: points for the subtree.
cStart: start coordinates for the cell.
cEnd: end coordinates for the cell.
Output: The tree/subtree in kd-Tree format
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
if P contains only one point then
return a leaf with the info from P[1].
if the cell x size is larger than its y size then
sort P by x coordinates
m = the x coordinate of the median of the cell
else
sort P by y coordinates
m = the y coordinate of the median of the cell
if m is on the left of P[1] then
Let the node be P[1]
Let pLeft be nothing
Let pRight be all the points, except P[1]
Let the right cell (cRightStart and cRightEnd) be the area on
the right of the median line trough P[1]
else if m is on the right of P[#(P)] then
Let the node be P[#(P)]
Let pLeft be all the points, except P[#(P)]
Let pRight be nothing
Let the left cell (cLeftStart and cLeftEnd be the area on the
left of the median line trough P[#(P)]
else
Let i be the index of the point closest to the median line on
the right side
Let the node nothing
Let pLeft be points P[1 to i-1]
Let pRight be points P[i to #(P)]
Let the left cell be the area on the left of the median
Let the right cell be the area on the right side of the median
if pLeft then
v.l = BuildKdTree(pLeft,cLeftStart,cLeftEnd)
if pRight then
v.l = BuildKdTree(pRight,cRightStart,cRightEnd)
return v
100
Querying the kd-tree
The structure of the kd-tree is optimized for querying. The common
query function for a kd-tree is the query of a range interval for each
dimension. For two dimensions, this is the x and y range interval from
which the points queried should be.
As the data required depends on a circle rather than on a square area,
the query function can be optimized for this purpose. It is given a
center point and a range, rather than an x and a y range interval. The
check for a given coordinate is then performed by analyzing if the point
is with the given range to the given point. This algorithm is described
Algorithm 5: SearchKdTree
1
2
3
4
as pseudo code in algorithm 5.
5
6
7
8
9
10
11
12
13
14
15
Input: v: kd subtree
p: search pivot point
r: search range
T: Table of the results so far.
Output: Table of the the data fitting the range
if v contains a point then
if coordinates is within range then
table.insert(T,v)
if v is not a leaf then
if the median is parallel to the y axis then
if p.x - r < v.x then
T = SearchKDTree(v.l,p,r,T)
if p.x + r >= v.x then
T = SearchKDTree(v.r,p,r,T)
else
if p.y - r < v.y then
T = SearchKDTree(v.l,p,r,T)
if p.y + r >= v.y then
T = SearchKDTree(v.r,p,r,T)
return T
101
Insert node
Nodes can be inserted in the tree in similar fashion to how nodes are
inserted in other search trees. The algorithm is to search down into
the tree, to find the location best fitting and the insert the node when
reaching a leaf. The insertion run in logarithmic time, since the average
dept of the kd-tree. This insertion mode can result in a non optimal
balanced tree.
A pseudo code implementation of the algorithm can be seen in Algorithm 6.
Algorithm 6: InsertKdTree
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
Input: v: current point in the tree or its root
p: point to insert
Output:
if the median is parallel to the y axis then
if p.x <= v.x then
if v.l then
InsertKdTree(v.l,p)
else
v.l = p
else
if v.r then
InsertKdTree(v.r,p)
else
v.r = p
else
if p.y <= v.y then
if v.l then
InsertKdTree(v.l,p)
else
v.l = p
else
if v.r then
InsertKdTree(v.r,p)
else
v.r = p
102
Remove node
Nodes can be removed from the tree in two ways. The node data can
be stripped from the node that should be removed, while the node is
kept as an auxiliary node, if it is not a leaf. This method is fast, but the
tree does not get smaller in size when the middle notes are removed.
The other method is to completely remove the node and then rebuild
the subtree of the cell. This method takes longer time, but it optimizes
the structure of the subtree.
As stated in the requirements in F.1, some nodes might change position.
If this is done by Remove and Insertion, using the first mentioned
removal method, it could result in an explosion of the size of the tree.
Due to this, it is best to implement it using the rebuilding method,
which is done in psuedo code in algorithm 7 and algorithm 8.
Algorithm 7: GetAllKdNodes
1
2
3
4
5
Input: v: current point in the tree or its root
T: table of nodes so far
Output:
insert v in T
if v.l then
GetAllKdNodes(v.l,T)
if v.r then
GetAllKdNodes(v.r,T)
Algorithm 8: RemoveKDTree
1
2
3
4
5
6
7
8
9
10
Input: p: the point to remove
Output:
parent = p.p
initialize table T
if p.l then
GetAllKDNodes(p.l,T)
if p.r then
GetAllKDNodes(p.r,T)
if parent.l = p then
parent.l = BuildKDTree(T)
else
parent.r = BuildKDTree(T)
Implementation
The kd-tree is described in the algorithms as functions, but it can
however be implemented as either functions or as a class. Since the
103
functions are relevant to be applied on all nodes in a kd tree, then it
is best implemented as global functions.
The functions can be implemented using Test driven development. It
is relatively easy to predict how the tree would look for a small dataset
and then check that the output tree is as expected. The tests can then
also be expanded to larger datasets, where the results can be validated
using the query functions.
104
F.4
Test and evaluation
Purpose
The correctness and performance of the implementation should be
tested and validated trough a series of tests.
Test trough TDD
The solution is implemented using TDD (Test driven development).
This includes design of a series of test cases for the unit tests used in
TDD. These unit tests are written while the code is developed. Several unit tests is created for each function implemented. A general
structure in these tests is to first test the functionality on a leaf, implement that functionality, and then test against a simple tree example.
All the unit tests created are run successfully in the end. Some of
the unit tests have uncovered minor, but vital errors in the code. An
example there off is checks that stops the BuildKdTree function from
running recursive, when there is no more points left to insert.
Performance test
In order to verify the performance improvement by the solution, the
kd-tree solution is run in a performance test. This is held up against
the native implementation, run in the same test. The test is run on
different number of points, but all in the same area (1000x1000). The
performance is measured by the runtime of 10000 query calls.
The measurements confirms the huge difference between the native
and the kd-tree implementation. It also confirms that the expected
run times are correct. The native implementation runs in O(n) and
the kd-tree implementation runs in O(log(n)). The results of the measurements are shown in figure 19.
Conclusion
The solution have been tested under the implementated and minor
errors found have been corrected. The solution have been performancetested in a large scale scenario. This have revealed that the
KD-tree implementation runs in O(log(n)) time, which is much faster
105
Figure 19: Performance measurements
than the O(n) native implementation. The solution is a huge improvement and a solution that fulfills all the given requirements.
106
G
Syncronization of datasets
between AddOn clients
107
G.1
Purpose
The purpose is to determine and describe the problem in details.
Problem description
Sharing and maintaining of datasets for AddOns in World of Warcraft
(wow) holds some problems and challenges. AddOns are given two
different ways of communicating: Directly from one player to another
and from one player to all other players in the same channel. There
is no way to that all communication has to be between client, with no
central server.
The communication is limited to a fixed limit of 4 KB/s when the
performance of the game is above 20 fps and 2 KB/s when it is bellow 20 fps. This limitation is applied to both communication from one
player to another and from one player to all players in the communication channel. The fixed limitation is implemented inside a widely
used 3rd party library for AddOns called ”ChatThrottleLib”. This is
done for security reasons, as there exists a currently unknown limit, set
by the client. If a player exceeds this limit, they will be disconnected
at once. There is currently no known limit to how many messages a
player can receive, but the receiving players AddOns will have to process all received messages. A large amount of messages received can
then potentially slow down the client. Due to this channel communication (from one player to all), should be kept at a minimum.
Even though all traffic from one player to another goes via the central server for the game (or for the game realm), there can be some
minor difference between the communication latency between players.
This measurement of this latency are available to the AddOns trough
the ingame API.
The majority of AddOn communication is small notifications or
flags, send between two players or from one players to many. Some of
these can be in a longer chain of communication similar to handshaking.
A typical need for addon datasets, relevant to several clients for an
AddOn, is to synchronise a relatively large datasets between multiple
players. This need exists as a consequence of the lack of a server to store
these datasets. These datasets typically got a version for each subset,
allowing concurrent changes to different subsets. A typical dataset can
108
be up to 2 MB of size.
A worst case scenario is a player who got new versions of all subdatasets and comes online on a realm with many users. This can result
in him having to send the data to each other player that requests the
data. If the dataset is 2 MB, then this would take 500 sec (8.3 minutes)
pr player. This is an unacceptable scenario, since it would render that
players client completely useless, in terms of other AddOn communication, while the requests are taken care of.
The typical usage described above has two typical scenarios.
1. PlayerA changes several nodes in a central dataset. 100+ other
players are interested in getting this new information.
2. PlayerB comes online and has an out of date dataset. There are
100+ other players who has the up to date dataset.
The two scenarios covers most of the common usage, but it can be
more complicated, as it is realistic that the two scenarios happens at
the almost same time.
109
G.2
Related Solutions
purpose
It is the purpose to research relevant solution concepts that can be used
to solve the problem with synchronization of datasets between AddOn
clients.
BitTorrent
Data communication between AddOn clients have a lot in common
with peer to peer (P2P) communication, which makes the bittorrent
protocol and concepts a relevant system to draw solutions from.
The basics of the bittorent is that one client, who holds the data,
first creates a torrent file. This file holds different necessary information, including a list of the data to be shared, which is separated into
pieces of typically 256K bytes[4]. The user with the data and first client
then uploads a torrent file to a tracker (server). This server only function is to supply a list of the clients that takes part in sharing of this
torrent. Clients (peers) gets the pieces from the seeders (the client that
have the whole data and others who have completed the download).
The peers can also get pieces from other peers, but that happens in a
”tit for tat” manner, where they exchange pieces that the other part
need[17].
Gnutella
Gnutella is a different P2P network type. It is an overlay network,
where the client discovers other client in the network trough Pings
(and Pong responses). In the same way it sends out queries in the
network, which then are returned from the first other client who got
the information queried[16].
The relevant parts of this system is that it is send between clients,
where not all knows each other. A system like this can then reach
players that are not in the common communication channel.
DHT
The DHT (distributed hash table) overlay network is a different approach, where the responsibility and data for each subset is distributed
out to different clients. In order to do a query or a set call, the client
110
must then connect to the client responsible for the subset[15]. It provides a solution that have a low memory usage, as most data is only
present at the client when requested. It does however come at the cost
of the network usage, which is relatively high. In addition, the system
is vulnerable to clients being offline.
111
G.3
Solution development
Purpose
The purpose of the solution development is to develop and evaluate
solution designs based on the related research described in section G.2.
DHT inspired solution
One possible solution works by creating an overlay network, which is
inspired by DHT. In scenario 1 this can be done by sharing the updated
data to the other players in a leaf like structure. First player 1 sends
information to player 2, then player 1 sends information to player 3,
while player 2 sends the information on to player 4. This is illustrated
in figure 20.
Figure 20: DHT inspired solution - Scenario 1
The sharing can, as seen in the figure, happen in logarithmic time.
It has the runtime of O(s * (log(n) + 1) ) where s is the size of the
data set or subset and n is the number of players to send the data to.
A solution to scenario two is relatively easy, as the data is known to
many. The new arriving player just have to request the dataset from
any player that got it. This gives a linear transfer time of O(s + 1 ).
Bittorent inspired solution
It is relevant to work on a solution that is inspired by the bittorrent
protocol and the concept of how it works. Bittorent is strongest when
there is a lot of seeders, which imply that this solution might work
better for scenario 2 than scenario 1.
112
The dataset / subset is split up into parts of fitting size (e.g. half
the size of the bandwidth).
In scenario 1, it is possible to do the sharing from one player (the
seeder) to all the other players trough relay sharing. The seeder sends
the parts one by one to the first player. Each time a player receives a
part, they relay this part on to the next player. This solution solves
the scenario in the time O(n + p - 1 ), where n is the number of players
to share the data to and p is the number of pieces to send.
Scenario 2 can be solved in an efficient manner by letting all the
players with the information parts send specific parts to the requesting
player. These specific parts are chosen in a determent fashion from
the known number of parts and the known list of players participating.
This solution utilises the strongest side of bittorrent: fast transfer by
receiving the data from multiple sources. This strength is even more
visible for wow AddOns, as there is a limit on how much a player can
send, but there is no known limit to how much data a player can receive. This solution solves scenario 2 in the time O(p / n).
The solutions does have some issues in certain problematic situations, but these can also be solved. In scenario 2, it is a realistic
situation that a player goes offline while participating in this predetermined sharing pattern. A solution for that is that the receiving player
can request missing pieces from the players that it have received messages from, once the others are received. This would only give a minor
delay.
A problem in scenario 1 could be if a player has a long message
queue (evt. from other AddOns temporarily using all the bandwidth).
This can be done by letting a client with high queue return a negative
message to the previous sender, who then just relay the data to the
next on the list.
Solution selection
Both of the suggested solutions are related in their designs. The expected performance are however very different, as seen in table 9. It
can be seen that the bittorent solution preforms a lot faster in both
scenarios. It is especially fast in scenario 2, if there is many users.
113
Scenario 1
Scenario 2
DHT
O(s * (log(n) + 1))
O(s + 1 )
Bittorent
O(n + p - 1 )
O(p / n)
Table 9: Runtime of the solutions
114
G.4
Implementation
Purpose
The purpose is to describe the implementation of the datasharing solution. This includes analysis of its desired interface, as well as development of the communication flow.
Usage and interface
It is relevant to analyse the intended usage of the solution, in order
to make the most fitting interface to the solution. Typically data is
managed by a data list class, which can be interfaced with a selection
of functions. The functions that are in common with all of these data
lists are described in an example in table 10. Note that the get and
set functions change names depending on the data list, but follows the
syntax GetX and SetX, where X is the name of the object type the list
handles. The objects typically has a version number which can also be
retrieved trough the functions. This number is either incremented or
set to a time stamp every time it is edited.
Considering the interface of the list functions, then the most dynamic interface would be to let the Get, Set and GetAllGuids functions
be supplied as the constructor arguments to the datasharing module.
This allows the module to be compatible with changes to the list class
structure.
Distribution flow
As described in section G.3, the solution builds on splitting the data
into pieces. The pieces are distributed following two scenarios, as deFunction:
Functionality:
list.GetAbility(guid)
Gets the ability object by the given guid.
list.SetAbility(guid,data) Sets the object for a given guid with an
object created upon the given data.
list.GetAllGuids()
Returns a table with the guids of all objects in the list.
obj.Serialize()
Returns the data from the object.
obj.GetVersion()
Returns the version of the data in the object.
Table 10: Data list function example for AbilityList
115
scribed in section G.1.
Scenario 1 is a mass distribution scenario, where one player’s client
has updated data and needs to distribute it to all the other player’s
clients. The selected solution works on sending the pieces trough a
chain of clients. The flow for this distribution can be seen as a flow
diagram in Appendix ?. In addition to the described chain sending of
pieces, then the flow also handles two other special cases.
1. If a receiving player got a even newer version of the data. This
should however not happen in normal use.
2. If a receiving player has too low bandwidth capacity available to
relay the data on to the next player.
The second case (for player B) is handled sending back a notification
to the sender (player A), which then relays the old messages to the
next player (player C). All data pieces after this are then send from
player A, to both player B and C, but only the data to player C has
information about what players to relay the data on to further.
Scenario 2 happens when a user comes online with outdated data.
The solution uses the strength of bittorrent by receiving pieces from
many other clients concurrently. Since it can not be known for sure
that all clients in the network are able to send, up to date and available,
then it is troublesome to send all pieces in a predetermined pattern.
Due to this, the player coming online sends his versions to the common
channel. All the other clients then responds to the versions and sends
eventual offers and requests back to that player. The flow for this can
be seen in the flowdiagram in appendix ?. An interesting detail in the
design is an optimization for the case where the player comes online
and has an updated dateset compared to all other users. This could be
the case if the user have edited a subset while nobody else were online.
The clients waits and gathers both requests and offers. If there is more
than one request for a given set, then it sends this set out in the same
way as it is done in scenario 1. Regarding the offers, then it finds the
newest offers and then spreads out the requests on multiple player who
have given the newest offer.
Depending on the data list and the data being handled, it can be a
relevant scenario that multiple users/players attempts to edit the same
subset at the same time. This problem can be avoided by creating
a lock system, inspired by the semaphore practice used in concurrent
programming. This can be implemented by sending a lock flag to the
116
chat channel. If the player receives his own message in the channel
before he receives a lock message from any other player attempting the
same, then it can be considered successfully locked.
117
G.5
Test and evaluation
Purpose
The correctness and performance of the implementation should be
tested and validated trough a series of tests.
Test trough TDD
The solution is implemented using TDD (Test driven development),
which results in a great coverage in unit tests. Following the TDD
rules, the tests are created for all pieces of functionality, before this
functionality is implemented, one at the time. This ensures a high
level of correctness of the implementation. Since all unit tests create
have passed successfully, then the implementation can be concluded to
be correct.
Performance test
The performance of the system, especially the sharing speed, is quite
important. Due to this, a performance test is done to measure the
performance of the final system. The test is executed in a simulated
environment, rather than in the game environment, since it would require relatively complex coordinate or a large amount of game accounts
and computers, in order to carry out a full scale performance test. A
native solution have also been implemented, which will serve as reference in the performance tests.
The initial tests and comparison with the performance of the native
solution showed an unexpected result: The performance fell rapidly in
the case of small datasets and a large amount of players. This was
due to the auxiliary data send with the data stream, namely the list
of players. In these cases, the list of players could be multiple times
larger than the actual data, which gave the bad performance. This
problem were solved by sending the ripples of data out several times to
separate lists of players. The number of times to do that would then
be ceiling(n / p * k), where k is the time for a piece to go from one
player in the list to the next. In the simulation, the latency factor is
not included and thus this constant would be 1. This change solves the
problem and results in a more expected development when the amount
of players is rise on a small dataset, as seen in table 11.
In the initial tests it were also observed that the solution were quite
inefficient in small datasets, regardless of the amount of players. Analyses shows that this is due to the pieces being typically only 1 at these
118
Players:
Data size:
1
10
50
100
500
10
50
100
200
400
0.09
1.08
3.1
6
38
4.1
6
15
27
130
9
14
31
54
245
21
29
64
110
476
44
60
130
220
937
Table 11: Bittorent solution measurements - Scenario 1
Players:
Data size:
1
10
50
100
500
10
50
100
200
400
0.02
4.01
20
39
198
3.01
23
109
216
1078
7.01
46
220
438
2178
14
93
443
880
4378
30
187
889
1765
8779
Table 12: Native solution measurements - Scenario 1
sets. If the piece size is lowered, then it improves the performance for
small datasets, but it decreases the performance for large datasets. Due
to this, the piece size is set to change dynamically to be a 10th of the
data size. This results in there always being 10 pieces when sending
out data in scenario 1. The change effected both the small and large
data set tests positively.
Overall the final performance test results, seen in table 11 for scenario 1 shows that the solution is a great improvement compared to
the results for the native solution (see table 12).
Performance tests similar to those for scenario 1 were also carried
out for scenario 2. The measurements showed that it is an improvement, but it has the same performance as the native solution until
a certain data size is reached. As seen in table 13 and table 14 the
improvement is relatively large for larger datasets.
Conclusion
The solution were implemented as a class that requires some basic
functions from the data handling class. This method of implementation
allows for the system to be used dynamically and easily by most data
classes. An implementation trough TDD have verified the correctness
of the solution.
The solution have resulted in the expected performance improve119
Players:
Data size:
1
10
50
100
500
10
50
100
200
400
0.001
0.001
0.93
0.95
2.99
0.001
0.001
0.93
0.95
1.99
0.001
0.001
0.93
0.95
1.99
0.001
0.001
0.93
0.95
1.99
0.001
0.001
0.93
0.95
1.99
Table 13: Bittorent solution measurements - Scenario 2
Players:
Data size:
1
10
50
100
500
10
50
100
200
400
0.001
0.001
2
4
22
0.001
0.001
2
4
22
0.001
0.001
2
4
22
0.001
0.001
2
4
22
0.001
0.001
2
4
22
Table 14: Native solution measurements - Scenario 2
ment. The effect of the improvement is largest for scenario 1 (sharing
from one client to multiple clients), where it is a relatively large improvement for both increases in amount of participating clients and
the size of the dataset. The improvements in scenario 2 (sharing from
multiple clients to one client) are mainly visible for increases in the
dataset size, rather than in the increase of participating clients.
120
Appendix A
Figure 21: Flowdiagram for scenario 1
121
Appendix B
Figure 22: Flowdiagram for scenario 2
122
H
UML Class diagrams
123
Figure 23: UML class diagram for GHP model
124
I
User test of the initial prototype - Chat transcript
I.1
Odo
Character name: Odo Forum name: CMD.exe
Pre test questions
14:36:36 [Pilus]: Okay. First a few questions before we start the acual
test
14:36:59 [Pilus]: Have you done civilian / profession related RP before?
14:37:16 [Odo]: Does Stormwind City Guard-RP count?
14:37:35 [Pilus]: I would catagorize that as militiary myself.
14:38:15 [Odo]: Well, I’ve done civilian... Not that much though.
14:38:38 [Pilus]: Great. Are there any particular reason why you have
not done much of it?
14:38:45 [Odo]: Yea. Server died out.
14:38:56 [Odo]: All the RP left. ;-;
14:39:42 [Pilus]: Indeed sad. I am trying to develop a platform and
some tools to make the civilian / profession related RP more interesting and flowing.
14:40:24 [Pilus]: Do you think that tools can improve your experience
enough to engage in more cilivian RP?
14:40:49 [Odo]: A GHI-Currency would be too much of a hassle...
14:41:11 [Pilus]: Too much a hassle in what way?
14:41:52 [Odo]: Not for you. From my point of view, people would
most likely force it to some degree.
14:42:14 [Odo]: That is, if I know people corretcly.
14:42:33 [Pilus]: What do you mean by force it?
14:42:46 [Odo]: Okay, imagine this.
14:45:15 [Odo]: Guy A walks into a bar. The bartender, Guy B, is in
a guild that runs/owns the bar and the guild leader wants everyone to
use GHI because of the currency. However, Guy A doesn’t have GHI
for one reason or another and thus can’t give Guy B the money (c)
14:45:17 [Odo]: for the ale.
14:45:40 [Odo]: Yes, I’ve met people that are that fanatic...
14:46:09 [Pilus]: Indeed. Issues with people not wanting to have or
download the addon.
14:46:47 [Odo]: Indeed... Too much of an hassle for them and in some
cases, might deny people RP because of it.
125
14:47:08 [Pilus]: In regards to yourself, could you imagine that profession RP would be more interesting with mechanics that supports the
gathering, crafting and trade with other people?
14:48:06 [Odo]: Well, that would most certanly give me a very good
reason to start doing civilian/profession RP, so yea. Though wouldn’t
it kinda end up like Minecraft in some ways?
14:48:43 [Pilus]: You mean that the mechanic get focus over the acual
RP?
14:49:22 [Odo]: For some, yes. For others, no. It would depent on the
person in question.
14:50:07 [Pilus]: Indeed. And that is also why I am testing a concept.
Trying to see if it enhances the active roleplaying rather than enhance
passive roleplaying trough mehanics
During testing
14:53:06 [Pilus]: You can go into the mine and try them. Feel free to
14:53:19 [Pilus]: * think out loud and post what comes to your mind
14:54:02 [Odo]: Alrighty then.
14:55:36 [Odo]: Hmmmm...
14:56:36 [Odo]: Time to test this Spot-thingy.
14:56:54 [Odo]: Maybe an emote or something to let you know that
you didn’t find anything...
14:57:09 [Pilus]: Good idea
14:57:35 [Odo]: Okay. So I found two ores...Thing.
14:57:38 [Odo]: Where are they?
14:58:04 [Odo]: Ah, 2 meters towards northwest...
14:58:07 [Pilus]: They are not shown in the game world but they can
be interacted with in the menu.
14:58:51 [Odo]: It would be great to have something to messure meters
with. Since the Americans use ”Feets” and other nonsense.
14:59:35 [Pilus]: An option to show units in feets etc is a good idea
indeed
15:00:29 [Odo]: So I have 4 ores... And no idea if it’s twice the same
ore or not...
15:00:42 [Odo]: Does it stack ontop of each other after each spot?
15:00:49 [Odo]: Each new spot*
15:00:53 [Pilus]: They should, but they dont stack yet
15:01:05 [Odo]: Alright.
15:01:23 [Pilus]: Is it veins or Iron ore that you got?
15:01:35 [Odo]: All of them are Iron Ore Vein.
15:01:49 [Odo]: And one just dissappeared.
126
15:01:57 [Pilus]: They are nearby objects. Try and interact with them
by clicking on them
15:02:09 [Pilus]: In the menu that is
15:02:48 [Odo]: Too far away... Maybe a text to say how far away it is.
15:02:56 [Odo]: Kinda like the ARcheoligy on retail.
15:03:16 [Pilus]: Noted.
15:03:27 [Odo]: Oh, so it does update how far its away...
15:03:38 [Pilus]: Indeed
15:04:48 [Odo]: Two things.
15:05:28 [Odo]: The animation would be awesome and why is there a
cap in the perform-emote?
15:06:25 [Pilus]: Good idea about the cap. Regarding the animation,
then addons does sadly not have access to modify your character or
the game world
15:06:43 [Pilus]: AddOns can only do what can be done with emotes.
E.g. wave/kneel/sit.
15:07:09 [Odo]: Kneeling would be nice here.
15:07:53 [Odo]: And maybe that sound from the Link-Game when he
gains a new item if you successfully find the ore.
15:08:26 [Pilus]: So some kind of UI sound when the new item shows
up?
15:09:10 [Odo]: That or some text-announcement like ”You found a
ore!” or ”You found lots of ore!” or maybe ”You didn’t find anything...”
15:09:31 [Odo]: Is there a fail-chance with this?
15:09:33 [Pilus]: Indeed. More info feedback.
15:09:55 [Pilus]: Not currently, but there is rich options for adding stuff
like that.
15:10:07 [Pilus]: Anyhow, the test ends around here, so I got a few
questions for you
After test questions
15:12:07 [Pilus]: First off, as we talked about earlier, the mechanics
should not take focus away from the text roleplaying. How did you
think that the emote driven abilities in this prototype worked?
15:12:42 [Odo]: Hmmm... About that, let me test something before I
answer.
15:13:02 [Odo]: Yea, there should be a minimum-text-amount...
15:13:28 [Pilus]: Did it feel natural to you to roleplay trough a menu
like that?
127
15:14:07 [Odo]: Other then that, I quite liked it, really. It was kinda,
though not by much, immersion breaking but other then that, it was
really nice.
15:14:44 [Odo]: Maybe give pop-up window regarding examples on how
to keep the emote...
15:14:55 [Odo]: For the ill-experienced, that is.
15:15:15 [Pilus]: Could you elaborate that?
15:17:35 [Odo]: Sure. Have a little ”?” button that says ”Hints” or
”Examples”, going somewhere along the lines of either ”Hint: Look
for some specific color/patern in the stone wall” or ”Example: Bob
carefully eyes the stone walls of the mining tunnel, trying to (c)
15:17:47 [Odo]: find hints or clues of any veins to mine.”
15:18:40 [Pilus]: Do you mean in addition to the example in the ”Abilitity details” in the menu, or should it be that, just easier to spot?
15:19:55 [Odo]: Just a simple emote example to show/act as a guideline
on how to write the emote.
15:20:15 [Pilus]: Ah, as direct examples. Good idea.
15:20:24 [Odo]: Yup.
15:20:51 [Odo]: Because, quite frankly... I had no idea what the box
wanted me to do at one point. ;P
15:21:32 [Pilus]: Regarding the little UI with the nearby and the equipped
objects. How do you think that worked out?
15:24:11 [Odo]: The UI is nice and I find it to be easily understandable.
Though I had no idea where to put the ”Spot Minerals” item/skill...
So I threw one into my actionbar and the other on the left hand. An
explanation regarding the ”Equipped”-part would be grand.
15:24:29 [Odo]: Also, regarding the UI...
15:24:40 [Odo]: Where can I see what skills I’ve learned?
15:25:22 [Pilus]: You can see skills you have learned by pressing the
book icon in the menu. (That button is indeed missing a tooltip)
15:26:05 [Pilus]: And regarding the skill. It is indeed intended that you
can just drag it into an action bar
15:26:34 [Odo]: I pressed the book... Found the ”Spot Minerals” and
then dragged it off into the LeftHand slot... And the book is empty
now.
15:27:10 [Pilus]: Ah, that is a bug and should not be possible.
15:27:31 [Odo]: Huh. Got the item for less then 2 minutes and already
broke it.
15:27:31 [Pilus]: It is the idea that you should need to have a pickaxe
equipped later on.
15:27:50 [Pilus]: Well, this is a prototype test, so it is quite bugged.
128
15:28:02 [Odo]: It doesn’t seem that much bugged.
15:28:47 [Pilus]: Another thing regarding the UI. Did you move it away
from the middle of the screen and did you close it at any point?
15:29:51 [Odo]: Yea, I moved it down to the bottom right-half so I
could see where I was going. And I think I closed it once or twice,
though it was just to test it.
15:30:02 [Pilus]: Okay.
15:30:45 [Pilus]: Overall, do you think that a large scale system build
like this would make profession / civilian RP more appealing?
15:32:31 [Odo]: If it’s accessable, yea. Though there would ”need” to
be a group/community based around it. People can’t really bother to
solo-RP these days.
15:35:40 [Pilus]: Were you able to orientate yourself in regards to what
direction the ”nearby objects” were located?
15:36:58 [Odo]: With the aid of the ingame map, yea. And the update
regarding on how far away the vein was is really nice. An arrow that
points to the direction of the ore would be fantastic though.
15:37:36 [Pilus]: Would it work with an icon on the minimap? (like
with real mining notes)
15:38:59 [Odo]: That’d be great too. Just to show the general area
where the ore is, though it’s not really needed, it just makes it easier
to find it.
15:39:25 [Pilus]: Noted. Just one last thing then.
15:40:29 [Pilus]: I am developing this concept and AddOn as past of
a master thesis at the Technical University of Denmark. May I quote
parts of the feedback in the report if nescesary?
15:41:13 [Odo]: ... ”Master Thesis”?
15:41:37 [Pilus]: The final project at a master / candidate education.
15:41:43 [Odo]: Aaaah.
15:41:44 [Odo]: Gratz.
15:42:13 [Pilus]: Thanks. May I quote you in it?
15:42:13 [Odo]: But yea, since you’re doing more effort then me to
support WoW RP, you can use anything you want.
15:42:23 [Pilus]: Great.
15:42:34 [Pilus]: That was all. Thanks a lot for your help.
15:43:02 [Odo]: By the way...
15:43:14 [Pilus]: Yes?
15:43:31 [Odo]: You’re awesome. :3
15:43:37 [Pilus]: hehe, thanks.
15:43:44 [Odo]: Felt like adding that to your essay.
129
I.2
Shelnara
Character name: Shelnara
Pre test questions
Pilus: First I would like to ask you a question before the test.
Shelnara: Alright.
Pilus: Do you normally like doing civilian roleplaying
Shelnara: Not really! Unless my character is disguising as one.
Shelnara: Or possible as a side-character but those i’d usually RP IM
or forum style.
Pilus: Are there any particular reason why you would not roleplay as
a citizen e.g. a farmer or miner?
Shelnara: It’s just too mundane for my liking. I understand that sometimes people get upset when all they see are ”heroes” and ”villains”
but I’m over that already. I don’t mind. I think it’s a small price to
pay.
Shelnara: There are other games more suited for simple civilians roles
as well.
Pilus: Do you believe that game mechanicals tailored to the professions
(e.g. detailed mechanics for mining) could inspire you towards liking
civilian RP more?
Shelnara: Well, the problem is I’ve usually played on private RP servers
where you did not have systems like on here and you could easily port
around to get to RP as well as add items through GM commands so the
professions were completely redundant and people trying to RP simple roles were often ignored since the ’heroes’ always had their armor
and weapons already and whatnot. Here those professions are actually
useful because of how the game was made. I could perhaps see myself
rolling an old grizzled human blacksmith alt but not as a main character.
Pilus: Great. Thanks for the detailed answers
During testing
Pilus: First off, how did the menu showing your equipment and the
nearby objects feel to you? What were your initial thoughts?
Shelnara: Clean and neat, fits into WoW and everything is clear. No
complains.
Pilus: Did you move it away from the middle of the screen?
Shelnara: Well yes. I moved it near my mini-map, otherwise it was
130
getting in the way but since its moveable, its fine.
Pilus: Is the menu something that you could imagine having open all
the time while doing profession roleplaying?
Shelnara: Well honestly, my roleplay experience depends almost solely
on literacy and writing, not any kind of systems, as neat as they may be.
After test questions
Pilus: Very well, that leads me well to the next question. How do you
feel about abilities that are tied together with emotes, like one you
experienced with ’search for minerals’ ?
Shelnara: I think it reminded me of some Neverwinter Nights servers
that I used to frequent. Roleplaying servers. So, somewhat nostalgic.
I’d say it felt good so if there were roleplayers that would actually want
to that advantage of this, theyd like it too.
Pilus: You spoke earlier about that you were not very interested in doing profession roleplaying. Do you think that a system like this would
make you more interested in doing such roleplaying?
Shelnara: Like I said, my roleplaying experience is never tied to systems. It is useually purely based on text and imagination alone. That
is my personal opinion, of cause, it may vary.
Pilus: Thank you for that. The development of the AddOn / Solution
is part of a master thesis I am doing at the Technical University of
Denmark. Do you mind if I quote you in the report if needed?
Shelnara: No. I do not mind
Pilus: Thank you for your time :)
131
J
J.1
Final user test
Lancl
Party Pilus: First I got some questions before the tests.
Party Pilus: Do you normally do civilian roleplaying?
Party Lancl: I do enjoy civilian roleplay, yes.
Party Pilus: Are there any particular reasons why you enjoy it?
Party Lancl: Civilian roleplay provides a far more relaxed atmosphere.
Ironically you have the ability to stand out more and socialize in a far
more relaxed enviroment.
Party Pilus: Do you feel that the civilian roleplaying get the acceptance, support and aknowledge from other roleplayers at it should?
Party Lancl: I’d say it largely depends on the roleplayer. There’ll
always be mixed receptions to the roleplay you provide and support.
Overall, I think it’s quite fair.
Party Pilus: Are there any particular roles that you persue in civilian
roleplaying?
Party Lancl: Ofcourse. While some enjoy playing the more entitled or
noble classes of roleplay, I prefer to get ’down and dirty’ if so to say.
The working class or downtrodden branch is of particular interrest to
me.
Party Pilus: When playing a role in the working class, do you normally
play the part of the worker in an off work situation or in work related
situations?
Party Lancl: It’s a wide combination depending on my mood and circumstances. I would, however, claim that it is more often in a working
scenario. I’ll often roleplay all alone by myself in certain enviroments.
This can be rewarding as you entertain yourself with whatParty Lancl: - tools you have available while also bring some marvel
to any random passer-by who may approach. It makes the world feel
more living for others while providing you lots of fun.
Party Pilus: Do you believe that mechanics tailored towards roleplaying professions could improve the value and entertainment gained in
while roleplaying a worker in a professional scenario?
Party Lancl: Most certainly. While the game provides its’ own tools
and means, there will always be ways which can enhance the experience. Usually you have to imagine those tools or make-believe they
exist. If they could be provided in a constructive manner to helpParty Lancl: - improve the experience and provide something that feels
more ’real’ than the ”because I said so” ethic, it would be absolutely
marvellous.
132
Party Pilus: Thanks. I would like you to come to me in the game and
then we can try out a little scenario. The setting is a mine worker in
the Jasperlode mine.
Party Lancl: Ofcourse! I’ll be right there.
You smile at Lancl.
Lancl waves at you.
Malbridge says: Afternoon and welcome to the Jasperlode Mine
Lancl raises his brow lightly at the well dressed gentleman.
Lancl says: Howdy, Sah. And thanks fer’ the invitation.
Tuvae has defeated Elisia in a duel
Malbridge says: Are you ready to give a hand in the mine?
Lancl says: I’d been under the impression this’ere mine’d been closed
off for a dang while. When I heard t’was opened back up’n’such.. Well,
I’d to take the chance, eh?
Malbridge says: That is great. Have you mined before?
Lancl says: Oh, yessah! But I’m a little rusty, I’d say. An’ I’ve ain’t
ever been to this here mine b’fore.
Malbridge says: Ah, I got some few notes noted down that might help
you. It is quite crude and simple
Malbridge gets some notes from his pocket and hands them to Lancl.
Party Lancl: Uhhhh...
Lancl accepts the notes from Malbridge and smiles warmly.
Lancl says: Thanks, tha’s mighty kind of ye’.
Lancl opens the notes to read through them. His facial expression display a clear interrest.
Party Pilus: What is your first impression on the ”Hand to” functionality?
Party Lancl: Very simple and easy to understand. The sound was really what had me interrested as the familiar sound that we have become
programmed to understand means ”trade” was played.
Party Lancl: Subconciously that meant I easilly understood exactly
what was going on despite it being the first time I experience the GHI
trading system.
Party Pilus: Great
Party Pilus: What is your impression on the quickbar (the one showing
nearby objects and equipped objects)?
Party Lancl: Small and simple. As with all new things, you have a
sense of curiousity to find out what the buttons mean and what the
slots do. It’s encouraging that it’s not an overwhelming mess of option
boxes, but rather a simple and encouraging design.
Party Pilus: Do you think it is an UI you could like to have open while
doing profession related RP?
133
Party Lancl: Naturally. It’s pretty neat and makes you aware of its’
presence without seeming imposing or dominant.
Party Pilus: Good.
Lancl says: I’ll be. This venture jus’ keeps givin’ huh?
Malbridge says: It is just for borrowing
Lancl accepts the mining pick from Malbridge. He takes a quick glance
across the surface of the wood to determine the sturdiness. Upon the
inspection his eyes also casually glance past the head as he examines
the metallic composition.
Lancl says: Did sound too good t’ be true, too, aye. This’s a fine pick.
Lancl grins warmly as he nods encouragingly.
Malbridge says: Glad you think. Off you go then
Lancl says: Alrighty!
Malbridge says: Find yourself a good vein and hack away.
Lancl swings the Mining Pick over his shoulder as he looks up into the
sky. With a determined gaze in his eyes he smiles as his lips curve to
form a gentle circle. A merry tune is soon heard escape his lips as he
ventures into the mine!
Kobold Miner says: You no take candle!
Lancl looks around curiously to see if he can locate any minerals.
Party Pilus: What is your first impression on the action UI you just
encountered?
Lancl says: Oh my, I’s already spotted me’self two Iron veins! Yippee!!
Party Lancl: Very nifty. Actively searching for veins is a smart idea.
What steals the cake is how the game expects me to type in an emote
to trigger the action. It makes it feel more alive.
Party Pilus: Great. Did you take any notice to the blue (!) button in
the action UI?
Party Lancl: Oh, no. I did’nt notice that.
Party Pilus: Noted.
Lancl Swings the pick from his back and nods. This must be where the
Iron vein is located!
Lancl says: I’ve got a hunch that there’s plenty of Iron under this’ere
vein, yep.
Lancl says: Seems I’s got myself some chunks of raw Iron Ore on me
left.
Lancl says: Better pick ’em up!
Lancl says: ...Once I’ve broken it down a bit.
Lancl begins breaking the iron ore. He wipes his brow lightly while
working and his whistling tune has turned to groans.
Lancl says: ’ere we go. Some Raw Iron Ore’s always good, ayep!
Party Pilus: This concludes the demonstration. I got a few ending
134
questions for you
Party Lancl: Ofcourse. Ask away.
Party Pilus: Did the solution improve your profession roleplay of a
miner compared to doing it without the AddOn?
Party Lancl: Oh absolutely! It was a pretty cool experience, like a
game within the game. It gave the entire situration a well needed flavor. Walking around as a miner is fun in and of itself, but this made
me feel like I was ACTUALY doing something worthwhile.
Party Pilus: What do you think about the lenght of each action? (They
are after all quite a bit longer than their normal game profession counterparts)
Party Lancl: Hm. I actualy did not pay much attention to it. I mean,
ofcourse I realized it took longer, but it was more satisfactory than punishing. I mean, the action was a reward for my emote, so the lenght
was not an issue, quite contrary.
Party Pilus: What do you think about the detail level and the amount
of steps in your way from spotting the mineral to getting some raw iron
ore?
Party Lancl: I loved that part. I did’nt want to break character to
explain it, but I have to say it was fantastic. When it comes to rewarding players for actions there are two extremes that are easilly reached.
There’s the instant grattification which immidiately Party Lancl: - rewards the player for simply clicking a button but it
becomes tideous and grindy very quickly. And then there’s the extreme
where a player is forced through tonnes of unwanted texts and steps
that they would really rather skip to get to the results. Party Lancl: The way this was implemented in the experiment was
absolutely fantastic. It struck a fine balance between rewarding and
encouraging. Not many games manage to find such a balance, but
within this short test I can say without a doubt that I was both Party Lancl: - encouraged to continue but likewise also rewarded for
my efforts.
Party Pilus: Thanks for your replied. Do you have any comments to
add yourself?
Party Lancl: Usually when you roleplay, you use your character as the
tool. You need other players around you to respond to your actions
and emotes and that’s a good thing, too. But what this AddOn does,
is provide you with an invisible participant. Party Lancl: - Finally, your character is actualy more than just a tool
to the roleplay, it becomes a vibrant part of the play itself. You play
with your character and the AddOn makes your character play back
WITH you as a companion rather than just an empty vessel.
135
Party Lancl: And I really appreciated that.
Party Pilus: Thanks
J.2
Hinkerburry
Party Pilus: First off, I would like to ask you a few questions before
the test
Party Pilus: Are you generally interested in civilian roleplay?
Party Hinkerburry: Generally I do - its my favorite type of RP, I do
enjoy being able to RP out the ”whole” kit when it come to it - I mean
sure there are the standard adventures, and warriors etc - but they
need to have village to defend or a city to fight for - and there are
people there, those indivudals live in a fantasy world with no ”special”
things about them, mirrowing our own world in a unique way, I adore
really sinking into a character like that becouse I can -really- relate to
them.
Party Pilus: Do you feel that the game mechanics and focus of the
game gives you good oppotunities to live out simple civilian roles?
Party Hinkerburry: Well, the game is not very focused on any type of
RP to be fair - its never offered us the simplest tools like plonking down
a box or what-not, or having any ”real impact” on the world around
us, in particular the cities and villages where there can be various of
things in the way to ensure the PvE aspects are lived out - invisible
walls, not being able to toss out smoke screens.
Party Hinkerburry: Short: No I don’t think so.
Party Pilus: Do you currently feel acceptance, backup and/or interest
from other RPers when taken on a simple civilian role?
Party Hinkerburry: It all depends on the circle of people I am with but I’ll presume we mean the ”public” RP scene.
Party Pilus: Let me hear about it for both cases
Party Hinkerburry: In that case - well generally we are often met with
optimism - people are often veiwing us as ”cool” becouse we do something diffrent, but we are often ignored aswell since its often quite
”heavy” rp we do, and generally could be concidered bland if you Party
Hinkerburry: more focused on killing dragons and rescuing maidens as
opposed to living into a character.
Party Hinkerburry: As for private circles? Well yeah, its my friends.
Party Pilus: Thanks. Do you have anything to add before we move on
to the testing?
Party Hinkerburry: Hrm, well I’d like to add that I feel that if we
could get people to develop their RP - start thinking deeping into
136
their actions and relaitons we might improve upon it somewhat. Party
Hinkerburry: And civilian RP and the things it brings to the table as culture, realtions, circomstances, nations - are all great basis for it
to grow.
Party Pilus: Thanks.
Party Pilus: Regarding the addon. Have you noticed where you open
it yet?
Party Hinkerburry: Aye the arrows there.
Party Pilus: Great.
Party Hinkerburry: No nearby objects, and I’ve got no equippments.
Party Pilus: Have you moved that UI anywhere on the screen?
Party Hinkerburry: No, but I just did - works just fine.
Party Pilus: Were it clear to you that you could move it, or should
that be more clear?
Party Hinkerburry: I think that potentially moving it away from the
bag a bit might make it clearer - I figured it was attached to the bag
untill you told me I could move it.
Party Pilus: Noted.
Party Pilus: Is it clear to you what the UI does?
Party Hinkerburry: I would presume that the nerby objects would light
up as I move into them - as for the bag, I guess its for gathering things
in to later move to your big bag.
Party Hinkerburry: Sheated item, not quite sure - gusseing a tool of
some sort.
Party Hinkerburry: Which then goes into the offhand or mainhand.
Party Hinkerburry: And the arrows I’d guess are to move everything
around if there are several items about.
Party Hinkerburry: Then the box open the proffetion screen.
Party Pilus: Indeed
Party Hinkerburry: Which is currently empty.
Party Pilus: Now for the next part of the test, I would like us to stage
a bit of an RP setting
Party Hinkerburry: Very well.
Party Pilus: I am a mine foreman and I would like for you to take upon
yourself the role of a labourer comming here to seek work at the mine.
You smile at Hinkerburry.
Pilus says: Greetings.
Hinkerburry says: ’aum sir? I be guessin’ yer the foreman? You nod
at Hinkerburry.
Pilus says: That is indeed correct. Welcome to the Jasperlode mine
Hinkerburry says: Hinkerbury at ye service sir. First day at work.
Hinkerburry salutes you with respect.
137
Pilus says: Ah great. Do you know anything about mining?
Hinkerburry says: Ah.. well I was in.. ye kno’ them kids school.. No,
nay really sir - I know ye suppose to use em pickaxe, right?
Pilus says: Ah, dont worry. I got a few things noted down that could
get you started
Hinkerburry says: Much obligted sir.
Pilus hands some notes to Hinkerburry.
Hinkerburry gingerly accepts the notes...
Hinkerburry says: Think I am getting the hang of this sir.
Party Pilus: Sounds good
Pilus says: Sounds good
Party Pilus: You can find the abilities in the abilities tab in the menu
Hinkerburry says: Want me to try it out then? I am eager to earn my
paycheck!
Pilus says: Sure thing. Knock yourself out
Party Hinkerburry: Sure
Hinkerburry salutes you with respect.
You salute Hinkerburry with respect.
Hinkerburry says: On my way then sir, thanks for all the help.
Hinkerburry looks for the minerals around the cave!
Party Pilus: feel free to think out loud with your impressions
Party Hinkerburry: I liked the forced emote.
Party Hinkerburry: Makes sense.
Party Hinkerburry: Right standing here where I think its telling me it
is.
Party Pilus: Good
Hinkerburry looks for minerals!
Hinkerburry tried out the extra mineral tab!
Party Hinkerburry: A note: Tried to ”move” the spot minerals and it
stuck to me untill I moved outside the spellbook.
Party Hinkerburry: Minor annoyance.
Party Hinkerburry: Hrm, can’t seem to use the iron picks.
Party Hinkerburry: Do I have to be closer then 0 meter?
Party Pilus: Noted. A hint: try to use the iron ore vein
Party Hinkerburry: Both are iron!
Party Hinkerburry: Perhaps adding in a compass might be a good
thing?
Party Pilus: Ah, I see what you mean now
Party Pilus: And that is a good point
Party Hinkerburry: Can’t use this one either.
Party Pilus: Well, it is sadly because it is the end of the demonstration
setup I made
138
Party Hinkerburry: Ah fair enough ;3
Party Pilus: What is your impressions so far?
Party Hinkerburry: First impression:
Party Hinkerburry: Its fucking cool - a bit confusion in finding the
nodes - since there is no visual aid, sugges a compas other otherwise.
Party Hinkerburry: I like the simple design - not to impossing, the
spellbook might be a tad alrge, perhaps a resize button might be good?
Party Hinkerburry: Other then that its the top down design from GHI
and it fits well with its overall theme.
Party Pilus: Would a direction error in the tooptip of the nearby object
be sufficient?
Party Hinkerburry: Well, anything to give you a ”warmer” ”colder”
feel might be good.
Party Hinkerburry: Right: So to compile my toughts.
Party Hinkerburry: First off all, like I’ve mentioned I enjoyed the sleek
design - but that the spellbook might be just a tad large, I would have
enjoyed some manner of resizing option, or at least three or so sizes:
Small medium big - what ever.
Party Hinkerburry: Secondly - the looking for nodes was fine, but for a
first time user it was somewhat of a pain to properly find some things
- it did give directions in south -west etc, but without an easy to reach
compass its easy to get turned about, had to look at the minimap its nothing ”big” thats for certain, but I know some people don’t have
minimaps left on their UI’s, even if its rare - I’d suggests a togable compass of some sort to allow you a better and more direct visual stimuli perhaps even have it go ”This way” at one of its points - the emote system was neat, especially that you could add several windows - would it
be possible to have a delay option, perhaps just a little dropbox saying
1-2-3-4-5 sec delays to allow for several emotes, instead of having them
drop directly after each other?
Party Hinkerburry: As for the useage of items - never got to try it, but
I’d imagen if you have several proffetions looking into the proffetion
screen that it may be clutered just like the spellbox - a search function
or similar would be nice!
Party Hinkerburry: To summerice: I firmly belive its a soild core, there
is nothing major that sticks out as flawed, (aside from well, thats its
not finished) overall the design is enjoyably simple and straight forward, and I rather quickly got a hang of it - quicker actually then my
first time opening GHI.
Party Pilus: It is the goal for the system to create professions that have
many steps in making things. E.g. getting from finding a iron ore to
having the final iron bar would be 10-15 steps. Do you think that this
139
would be more helpfull and inspirering for RPing a miner?
Party Hinkerburry: Well yeah - it would encourage deeper thinking
then ”Lulz I am blacksmith” - adding in the various steps of making
things into a final iron bar would be cool - and probably encourage
people to actually go out into the woods find their ore and make it into
bars - perhaps even togheter with friends.
Party Hinkerburry: You know, spend a day making a blade had been
neat.
Party Hinkerburry: Honestly I am quite exited to see what people
might create with this addon.
J.3
Eddard
Party Pilus: First, before the test, I would like to ask you a few questions
Party Pilus: Do you do civilian roleplaying?
Party Eddard: Not in a long time.
Party Eddard: I’m more or so an adventurer/military role-player.
Party Pilus: Are there any particular reasons why you prefer those
types of roleplaying over civilian roleplaying?
Party Eddard: I usually prefer being a lone-wolf adventurer, usually
because I’m able to explore a lot of hubs and such.
Party Eddard: As a citizen you’re restricted in your own area.
Party Eddard: And I’m not fond of staying in the same terrain all the
time. I like change.
Party Pilus: Understandable.
Party Pilus: Do you in general feel that civilian roles get appriciated
enough?
Party Eddard: No. In Partys, they are usually neglected. Dalaran
tried, and Dalaran failed. However, Pyrewood is a very good Party for
such roles.
Party Eddard: I had fun role-playing as a paranoid citizen there.
Party Pilus: So it would be correct to say that Pyrewood is successfull
for citizens due to the threads and by that the Action there?
Party Eddard: Nah, more or so the lack of 24/7 war/conflict. It’s a
small town, and so everyone will know eachother. It’s a friendly community, and citizens usually get to take part in every event as well.
Party Pilus: That sounds nice
Party Pilus: For the next things I would like for you to come to me.
Party Pilus: As you might know, I am the foreman of the Azurelode
mine and IC’ly I could use some help with the mining
140
Party Eddard: All right. One moment.
Eddard says: The Cap’n sent me, sir! There’s work to be done?
Pilus says: Ah, yes, indeed.
Eddard nods at you.
Pilus says: First off, do you know how to mine?
Eddard says: Aye, ’course.
Pilus says: Great.
Pilus says: There is a few things we do different here, but I got it noted
down in some simple words.
Eddard says: Spent me days serving as a mason - an’ the others workin’
in the mines, sir!
Pilus hands Eddard some notes
Party Eddard: That’s bad ass.
Pilus says: And ofcause a mining pick
Pilus picks up a mining pick and hands it to Eddard.
Eddard grabs it, nodding.
Eddard says: Well, shall we, sir?
Eddard bows down graciously.
Party Pilus: Does the menu with nearby objects and equipped items
seems intuitive for you so far?
Pilus says: indeed. Just follow me.
Party Eddard: Yeah, it seems pretty cool.
Party Eddard: I like what you’ve done with it so far.
Pilus says: Try and see if you can spot a good place to mine yourself
Eddard nods.
Party Eddard: The other Party I am associated with is having an
event right now, so I’m going to have to switch characters. I’ll download patch-c and have it all ready the next time you need it tested, if
that’s all right.
Party Pilus: Sure
Party Eddard: All right, it looks good so far. I like the new additions.
Were books fixed?
Party Pilus: So far I am notified, yes
Party Pilus: I just have a final question before you leave
Party Eddard: Neat! Sure, what is it?
Party Pilus: Do you think that a system with more details in e.g. professions would make civilian roleplaying more interesting for you?
Party Eddard: Yeah, sure. It would be neat to to do this with a couple
friends and such.
Party Pilus: Thanks.
Party Pilus: It is all for now :)
141
K
Final prototype screenshots
The following is screenshots from the final prototype.
142
Figure 24: The quick bar
Figure 25: Handing an item to another player from the quick bar
143
Figure 26: The ability page
Figure 27: The perform action UI. In this example the user have added one
additional expression
144
L
GHG Pitch
I would like to get some feedback on a little addon idea i got, which
have the working title Gryphonheart Groups or GHG.
The addon allows you to join one or more groups. These groups
works like guilds, except that they are not visible to others. It can
be used to form a secret lodge, a craftsmans guild, a subguild in an
existing guild or whatever other guild fits your need.
The group UI includes many of the normal guild features.
Planned features:
• List of members
• ustomize member ranks ( not limited to only 10).
• Seperate channel (like guilds. It does not take a channel slot).
• Member item / insignia. An insignia that automatically updates
to display your group membership and rank. These can be customized freely by the group leader.
• Message of the day.
• Group info.
• Group events in the calendar.
• Customizeable group icon.
Note that some of the data (like the message and info) can be a bit
out of date if you are online without any other GHG users are online.
I expect the implementation time to be quite small compared to
e.g. GHI.
145
www.imm.dtu.dk
DTU Informatics
Department of Informatics and Mathematical Modeling
Technical University of Denmark
Richard Petersens Plads 321
DK-2800 Kgs. Lyngby
Denmark
Tel:
(+45) 45 25 33 51
Fax:
(+45) 45 88 26 73
E-mail: [email protected]

Gryphonheart Professions

Transcription

Similar documents

Untitled - West Ham United

GestureXtreme

Step by step instructions for players registering for Pelada FA

ExamView Player

Land Before Time Make A Match Rules

October 1st - Registration Opens

Welcome to CARHA Hockey`s online registration. Below you will find

to learn more

Publisher: DMD 2500 Target Rating: Teen Developer: Mytosis Jones

Creation of the event and analysis