Designing a persistent online strategy game - Department of ...

Designing a persistent online
strategy game
Anders Engqvist (dit04aet@cs.umu.se)
Andreas Wikström (dit04awm@cs.umu.se)
March 9, 2009
Master’s Thesis in Computing Science, 2*30 ECTS credits
Supervisor at CS-UmU: Daniel Sjölie
Examiner: Per Lindström
Umeå University
Department of Computing Science
SE-901 87 UMEÅ
SWEDEN

Abstract
Persistent online strategy games is a fairly new genre and there is still room for experimentation
and new ideas. The goal of this project was to create a design document
for the gameplay of such a game. A concept for the game was developed by involving
potential players. This was done using qualitative methods such as focus groups and
brainstorming sessions. Based on this concept a working prototype has been implemented.
This prototype was tested by the target audience and both the initial concept
and the prototype have been evaluated. The evaluation showed that the players involved
in the process believed in the potential of the game, but that there are several issues that
need to be resolved. The resulting working design document, describing the gameplay
of the game, is included in this report.

Contents
1 Introduction 1
1.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4 Task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Methods 5
2.1 The design process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Questionnaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3 Focus groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4 Brainstorming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.5 Prototyping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.6 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3 Requirements engineering with non-functional requirements 11
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2 Non-functional requirements . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.3 The Non-Functional Requirements Framework . . . . . . . . . . . . . . . 13
3.3.1 Softgoals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3.2 Interdependencies . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3.3 Evaluation procedure . . . . . . . . . . . . . . . . . . . . . . . . 18
3.3.4 Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.3.5 Correlations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.4 Eliciting requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.4.1 Questionnaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.4.2 Interviews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.4.3 Focus groups and workshops . . . . . . . . . . . . . . . . . . . . 25
3.4.4 Observing users . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4 Models & methods for evaluating games 27
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
iii

iv
CONTENTS
4.2 Beyond usability in the design and evaluation of video games . . . . . . 29
4.3 Differences between productivity software and video games . . . . . . . 30
4.4 Playability and gameplay . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.5 Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.6 Immersion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.7 Player experiences in games . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.8 Methods for the evaluation of video games . . . . . . . . . . . . . . . . . 38
4.8.1 Usability testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.8.2 Playtesting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.8.3 Consumer Playtest . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.8.4 Heuristic evaluation . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.8.5 Physiological measurements . . . . . . . . . . . . . . . . . . . . . 41
5 Pre-study 43
5.1 Initial idea generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.2 Result of the idea generation . . . . . . . . . . . . . . . . . . . . . . . . 43
5.3 Questionnaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.4 Result of the questionnaire . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.5 Brainstorming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.6 Result of the brainstorming . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.7 Focus groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.8 Result of the focus groups . . . . . . . . . . . . . . . . . . . . . . . . . . 47
6 Result of the pre-study 51
6.1 Overview of the working design document . . . . . . . . . . . . . . . . . 51
6.1.1 Cities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6.1.2 Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6.1.3 Family and family members . . . . . . . . . . . . . . . . . . . . . 52
6.1.4 Armies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6.1.5 Research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6.1.6 Trade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
6.1.7 Diplomacy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
6.1.8 Battles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
6.2 Examples of dropped ideas . . . . . . . . . . . . . . . . . . . . . . . . . 53
7 Implementation of the functional prototype 57
7.1 Scope of the prototype . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
7.2 Development environment . . . . . . . . . . . . . . . . . . . . . . . . . . 58
7.3 System architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

CONTENTS
v
8 Result of the implementation 63
8.1 Overview of the prototype . . . . . . . . . . . . . . . . . . . . . . . . . . 63
8.1.1 The game interface . . . . . . . . . . . . . . . . . . . . . . . . . . 63
8.1.2 Family members . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
8.1.3 Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
8.1.4 Trade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
8.1.5 Messaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
8.1.6 Resource reserves . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
8.1.7 Manpower . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
8.1.8 Research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
8.1.9 The map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
8.1.10 Resource stations . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
8.1.11 Cities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
8.1.12 Armies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
8.1.13 Warfare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
8.2 Errors and limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
9 Evaluation 77
9.1 Heuristic evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
9.2 Result of the heuristic evaluation . . . . . . . . . . . . . . . . . . . . . . 78
9.3 Focus group evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
9.4 Result of the focus group evaluation . . . . . . . . . . . . . . . . . . . . 79
10 Resulting design document 83
10.1 Basic concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
10.2 The world . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
10.3 Constructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
10.4 Timescale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
10.5 Seeing & Fog of War . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
10.6 Movement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
10.7 Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
10.8 Encounters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
10.9 Goals & endings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
10.10Highscore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
10.11Manpower . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
10.12Cities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
10.12.1 Buildings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
10.12.2 Population . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
10.12.3 Influence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
10.13Races . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
10.13.1 Race attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
10.13.2 Race exclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

vi
CONTENTS
10.14Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
10.15Family and family members . . . . . . . . . . . . . . . . . . . . . . . . . 92
10.15.1 Prestige . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
10.15.2 Reputation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
10.15.3 Life and death . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
10.15.4 Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
10.15.5 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
10.15.6 Marriage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
10.15.7 Family history . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
10.16Armies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
10.16.1 Leaders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
10.16.2 Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
10.17Conquest and expansion . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
10.17.1 Conquering land . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
10.17.2 Conquering cities . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
10.18Battles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
10.18.1 Capturing family members . . . . . . . . . . . . . . . . . . . . . 96
10.18.2 Battle orders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
10.18.3 Attacking cities . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
10.18.4 Attacking resource stations . . . . . . . . . . . . . . . . . . . . . 98
10.19Research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
10.20Trade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
10.21Diplomacy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
10.21.1 Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
10.21.2 Alliances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
10.22Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
10.23Beginning of the game . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
10.24Issues that needs to be resolved . . . . . . . . . . . . . . . . . . . . . . . 101
11 Discussion & Conclusion 103
11.1 Restrictions & limitations . . . . . . . . . . . . . . . . . . . . . . . . . . 104
11.2 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
12 Acknowledgements 107
References 109
Appendices 113
Appendix A Pre-prototype game specification 115
Appendix B Enkät 129

CONTENTS
vii
Appendix C Manus till brainstormingsession 131
Appendix D Resultat - brainstorm 1 133
Appendix E Resultat - brainstorm 2 137
Appendix F Manus för diskussionsession 141
Appendix G Frågor som måste behandlas 143
Appendix H Annoterade idéer till spelet 147
Appendix I Heuristiker för utvärdering 165
Appendix J Found issues in heuristic evaluation 167
Appendix K Utvärderingsmanus för fokusgrupper 177
Appendix L Resultat av utvärdering, fokusgrupp 1 181
Appendix M Resultat av utvärdering, fokusgrupp 2 187
Appendix N Resultat av utvärdering, intervju 195

viii
CONTENTS

Chapter 1
Introduction
The purpose of this master thesis project is to create a design document for the gameplay
of a persistent online strategy game. This chapter starts with an outline of the report. It
then defines some of the words and expressions being used, gives a bit of background to
this type of game (and strategy games in general) and introduces the goals and purposes
of the project.
Following the introduction the report presents a chapter about methods used throughout
the project. It then presents in-depth studies on non-functional requirements and game
evaluation. The rest of the report is dedicated to the work with developing the design
document. It regards the pre-study, the implementation of a functional prototype,
the evaluation and the results of each of these processes. Finally the resulting design
document is presented followed by a discussion about the results and future work.
1.1 Definitions
In this report the following definitions are used:
Persistent game: In a persistent game the world always exists regardless of who or
how many players that are logged in. The entities that a player controls also
continue to exist in the game world after the player has logged out. This means
that these entities can be affected by the game world and other players even though
the player is not currently playing the game. A related term is persistent world,
which means a virtual world that continues to exist after a user has exited the
world (just as in a persistent game). It is not however certain that the entities
(such as a player avatar) are still present in the world when the user has logged
out. Most massively multiplayer online role-playing games are persistent worlds
(for example World of Warcraft and Warhammer online).
Real-time and turn-based games: In a real-time game time flows continuously, as
opposed to turn-based games where time is divided into well defined discrete turns.
In real-time games a player can perform actions at any given time. Generally
in turn-based games, one player performs one or several actions while the other
1

2 Chapter 1. Introduction
players wait. When the first player is done, the next player performs his/her
actions. One turn is over when all players have performed their actions. Soccer is
for example a real-time game while chess is turn-based.
Gameplay: Gameplay is defined by the rules and components of a game as well as how
players interact with them. There are for example different rules and components
for a racing game and a roleplaying game. Because of this the games are also
played in different ways, giving the games different gameplay.
1.2 Background
Strategy games have been around since the early board games (such as chess) and the
computer strategy games today still hold to the same basic principles. The player is
supposed to make decisions to gain a strategic advantage and in the end beat his/her
opponent. Common parts of computer strategy games are the gathering of resources,
building of armies and the manoeuvring of these armies (although there are games that
contain other or not all of these aspects). There are quite a few different approaches to
strategy game. The most basic difference is perhaps the one between turn-based games
and real-time games. Turn based games have a slower pace and thus allow the player
to think through his/her actions more thoroughly than real-time games.
Since a turn-based game gets quite troublesome if a lot of players were to play it (if
there are 100 players and each player has to wait for all the other players to make
their decisions before he/she can play his/her turn the wait would be unbearable) most
online games are played in real-time. Fast paced real-time action is not desirable in a
persistent online strategy game on a grand scale, mainly because too much would have
time to happen during the time a player is logged out (i.e. a player that has a mighty
empire might be logged off for a couple of hours and when he/she returns nothing is
left). Because of this there are several hybrids of real-time and turn-based approaches
in persistent online strategy games. One way is simply to have a slow moving real-time
game where every action takes a lot of time. Another is to give the player a limited
amount of “actions” for a given time frame.
Non-persistent strategy games are usually played on a map where positions have different
strategical importance. To include a map in a persistant strategy game raises some
issues. Fixed positions make balancing difficult since all players should have equal (or
at least similar) opportunities in the beginning of the game. All positions in the game
cannot however be exactly equal since it would take away the strategic aspect of the
positions. A player’s neighbour would also most likely be his/her first opponent and
this can make the challenge uneven for different players (i.e. a new player who starts
the game next to a very aggressive player will have a different experience than a player
starting next to a peaceful player). There is also an issue of the risk of players being
completely defeated. If a player owns a fixed position on a map, there is no obvious
logical reason for why this position cannot be conquered. These problems can affect the
user experience. In present games there are mainly two ways of handling this. One way
is to have the players own abstract land and losing battles thus results in the player
loosing a certain percentage of his/her land. This is very common in non-graphical
games. A similar solution is to allow positions for cities, villages etc., but giving the
position no strategical importance. The other way is to separate battles from the rest

1.3. Goals 3
of the gameplay and only allowing players that are online to fight against each other.
Battles are then usually performed in a real-time fast-paced mode. In this case the
battles do not directly affect the land that the player owns but only gives an indirect
bonus or penalty to the player. An example could be to gain resources from winning a
battle, but not risking losing any land. This approach also makes it possible to “matchmake”
players of similar strength. There are of course other solutions and hybrids of
these two.
1.3 Goals
The goals of this master thesis are to gather requirements from the target audience,
develop a working prototype, evaluate the prototype and finally generate a design document
for a persistent online strategy game.
The design document will focus on the gameplay and mechanics of the game. It will not
consider software architecture and design, interface design or graphics.
The target audience for the game is people who are interested in strategy games. Because
the game will be fairly complex the age will probably be around 15 and up. The target
audience could thus be described as teenagers and young adults with an interest in
strategy games.
1.4 Task
The first part of the project is a pre-study aimed at eliciting requirements and wishes
for the game by involving potential users. This will be done using mainly qualitative
methods.
The second part is to develop a working prototype of the game based on the result from
the pre-study. The prototype will contain the basic gameplay mechanics and certain
features that require evaluation. It will not have all the functionality that will be found
in the final version of the game. The graphics and the interface in the prototype will be
simple and should not be seen as representative for the final game.
The third part is to evaluate the prototype empirically and analytically. The focus of
the evaluation is the gameplay of the prototype.

4 Chapter 1. Introduction

Chapter 2
Methods
This chapter explains some of the methods that will be used throughout the work. This
is mainly an overview of the techniques and does not go into any specific details or
implementations. Some of the techniques are further explained in chapter 3 and 4 while
the actual implementations that will be used are described in chapter 5.
2.1 The design process
The design process can look different depending on what type of system that is designed.
There are many different theories and models that try to explain the process. Löwgren
& Stolterman [37] identifies three different levels of abstraction in the early stages of the
design process; vision, operative view and specification.
The vision is the designer’s principle of the design. It is not a complete design, rather
an idea of a solution, structure or feature. A vision exists in the designers head and
is both diffuse and contradictious. This is the visions weakness but also its strength
because it makes it possible to work in situations that are complex and the vision gives
the designer something to strive for.
The operative view is more concrete than the vision and is usually captured in simple
sketches and pictures. This gives the designer opportunity to communicate ideas with
other stakeholders. After some time the operative view evolves and becomes more
detailed and specific. It then risks being separated from the vision, partly because
the operative view changes depending on outer influence and partly because the vision
changes.
At some time the operative view becomes a specification that defines the final product.
Implementation can then be initiated. These three stages are dynamic and influence
each other throughout the design process. The external situation influences the vision.
The vision affects the operative view which in turn changes the specification.
One model for the design process (shown in Figure 2.1), described by Preece, Rogers
& Sharp [52], is called the lifecycle model for interaction design. It is a descriptive
and simple model based on observations and models for Human-Computer Interaction
5

6 Chapter 2. Methods
and software engineering. The model encourages iteration and evaluation. The only
limitation to the number of iterations is the resources available.
Figure 2.1: The lifecycle model for interaction design. Adapted from Preece, Rogers &
Sharp [52].
Because the user experience cannot be predicted when designing interactive systems,
an iterative approach is preferable. To create a good user experience it is important to
identify needs and requirements upon which an initial design can be based. Prototypes
for the design are then built and evaluated. Data from these evaluations motivates
changes in the requirements and the design. New prototypes are then constructed and
evaluated to make sure that the redesign had the intended effect. It is always possible
to revisit each of these steps during the process.
2.2 Questionnaires
The basic layout of a questionnaire is a series of questions that can be answered in
different ways depending on the questionnaire. The questions can be open or closed.
An open question prompts the participants to answer with their own words while a
closed question presents a question followed by alternatives for answers (for example as
checkboxes) [52]. It is of course possible to combine both open and closed questions in a
questionnaire. Because a questionnaire can be distributed on paper or over the internet
it can gather responses from a wide variety of people located in different places in a cheap
way. If used in this way it can be used to statistically analyse general opinions [28]. Since

2.3. Focus groups 7
questionnaires are generally answered without any observer present the questions has
to be well defined and unambiguous.
2.3 Focus groups
The data gathering technique called “Focus groups” is quite loosely defined and could
very well be described as group interviews. One definition (although still quite loose) is
that focus groups are defined by three identifying statements:
1. It is a method for gathering data.
2. The interaction within the group is the source of the data.
3. There is an active part that creates the group discussion with the purpose of
collecting the data.
It is, in other words, a discussion within a group of people that someone has initialized
with the intention of collecting data. This broad definition allows for a variety of different
approaches to the method and it is therefore used in many different fields [40].
The greatest advantage of a focus group in contrast to a one-on-one interview is that it
might be simpler to gather attitudes and ideas and to explore these further. It might also
produce very unexpected and interesting data [29]. As with other qualitative methods
it is not suitable for making statistical conclusions [16]. Neither is it suitable for making
final decisions but should rather be seen as a way of collecting opinions and ideas.
2.4 Brainstorming
The basic idea of a brainstorming session is to gather people and have them generate
ideas for the solution of a problem [55]. The focus lies on generating many ideas rather
than a few good ideas, simply put “quantity, not quality”. Later some of the ideas
are selected to be further developed; this can be done using several different selection
techniques. The reason for why the goal is the quantity of ideas rather than the quality
is that there is evidence that a larger quantity of ideas actually leads to better quality
of ideas [49]. This may be because the first ideas a person comes up with are often
unoriginal and simple. If a person does not settle for the first ideas then more creative
ideas appear as the imagination has to be stretched. Because of this the criticism of
ideas is not allowed during the idea generating phase. They should not even be discussed
until the phase where the ideas are further developed [37]. This also means that the
ideas that people come up with during the idea generation phase should be presented
quickly and without too much detail. Excessive information that aims at supporting
the quality of the ideas should not be presented [55].
There are several different approaches to and variations of brainstorming. For example in
brainwriting, ideas are written down instead of being presented verbally as in traditional
brainstorming. By doing this the risk of interrupting other peoples train of thought is
minimized. This might increase the quantity of ideas. There are different ways to

8 Chapter 2. Methods
perform brainwriting as well, such as passing ideas on to the next person who then
develops the idea further [55].
2.5 Prototyping
Prototyping is used to test and communicate a design. With prototypes different designs
can be examined more closely. They can also be used to evaluate usability and clarify
requirements [52].
A prototype can be anything from a sketch on a piece of paper to complex software. Two
main kinds of prototyping are high-fidelity (hi-fi) and low-fidelity prototyping (lo-fi).
Hi-fi prototypes are similar in look and feel to the final product, but they do not have
the same functionality. Hi-fi prototypes can for example be used to test the usability
with end users. A problem with hi-fi prototypes is that the users may expect too much
of them, because it looks like a real product. They may also be reluctant to suggest too
drastic changes in the design.
Lo-fi prototypes are simple and cheap prototypes, often made in paper. They can be
sketches of the user interface or a usage scenario of the product. Lo-fi prototypes are
used to explore different design ideas. One disadvantage of lo-fi prototypes is that it
might be hard to predict how the users will interact with the final system [52].
2.6 Evaluation
Evaluating the design is a very important part of designing an interactive system. It
can be performed to make sure that all requirements are met, that the product is usable
and to determine if users like to use the product. Evaluation has traditionally concerned
users’ objective performance, such as time to complete a task, but there is a growing
trend towards also evaluating users’ subjective experience [52].
Evaluation can be performed in a lab or in a natural environment. In the lab interaction
can be observed as an isolated event and the evaluator has more control over the
situation. Some aspects are however best evaluated in their natural environment. In
real life, interaction can be interrupted by telephone calls, people and other tasks, which
makes it harder to perform a task from the beginning to the end. Some systems are also
meant to be used by several people. If it is important to see how a system is used in
real life, it can be better to evaluate it where it is actually meant to be used.
Evaluation can roughly be divided into two sets of methods; those that involve users
and those that do not. A widely used method that does not involve users is heuristic
evaluation. In heuristic evaluation an evaluator checks the system against a list of design
guidelines. The purpose is to find areas where the system violates the guidelines and
correct them. Heuristic evaluation can be performed early in the design when there is
no real system to test with users.
Involving users in evaluation can be performed in different ways. One way is to interview
them, this way the evaluator can learn their thoughts and feelings about a system. But
the evaluator can not see how the users interact with the system. Another way is to

2.6. Evaluation 9
observe users interacting with the system being evaluated. This can be performed in
a lab or at the natural environment. The users can have a list of tasks that are to
be performed, or they can interact with the system the way they feel suitable. The
evaluator observes what the users do and when interaction breaks down. Often some
sort of recording is performed.

10 Chapter 2. Methods

Chapter 3
Requirements engineering with
non-functional requirements
This chapter is written by Andreas Wikström. It is an in-depth study of requirements
engineering with focus on non-functional requirements. The chapter begins by introducing
requirements engineering and then moves on to explain non-functional requirements.
Later it explains The Non-Functional Requirements Framework which is used for handling
non-functional requirements. In the end some of the different techniques used for
eliciting requirements are presented.
3.1 Introduction
In a study where 38 IT professionals were asked about the reasons for IT projects success
and failures “unclear objectives and requirements” was the single most mentioned cause
of failure [53]. At the same time “clear, detailed requirements” was the single most
mentioned critical success factor. In an early article [4] Bell and Thayer state that
“The requirements for a system, in enough detail for its development, do not arise
naturally. Instead, they need to be engineered and have continuing review and revision”
suggesting that it is not easy to get “clear, detailed requirements”. This is where
requirements engineering (RE) comes in as it is, as its name implies, aimed at handling
the requirements for a project. In general one could say that RE is the process of
discovering what purpose a software system has. This is done by identifying stakeholders
and their needs and goals as well as documenting it in a fashion that makes it possible
to analyse and communicate these needs. It is not as simple as that however as there
are several difficulties with the very concepts of stakeholders and needs. For one, there
might be many stakeholders and it is not certain that they are aware of all their needs
or goals. The different needs and goals of different stakeholders might also conflict and
in general be difficult to fulfil [46]. These and several other factors, especially the scope
of the field, make RE fairly complex [54].
Since the activities of RE overlap, are iterative and can span the entire development
cycle there are several different ideas of what RE actually consists of. One description
11

12 Chapter 3. Requirements engineering with non-functional requirements
[46] states the following as the main activities that RE consists of:
– Eliciting requirements This activity focuses on finding, preferably a complete
set of, requirements. This is however a complex task and not just a matter of going
out and finding requirements that are already defined and articulated. Therefore
the word “eliciting” is preferred instead of “finding”.
– Modelling requirements Modelling or “the construction of abstract descriptions
that are amenable to interpretation” can be used both to elicit requirements, where
it prompts to gather more information, and to analyse systems.
– Communicating requirements The ability to communicate (and document)
requirements so they can be read, analysed, (re)-written and validated is very important.
Since there has to be a communication with the stakeholders in these
processes an understandable documentation of the requirements becomes vital.
Communication is especially important for validation since it is the process of
making sure that the elicited requirements actually match up with the requirements
of the stakeholders.
– Agreeing requirements Managing the sometimes conflicting requirements of
different stakeholders is another part of the process. Negotiating and resolving
these conflicts thus becomes very important.
– Evolving requirements As the environment in which the system operates changes,
so do the requirements. It is therefore important to be able to handle these changes.
This typically means that it has to be possible to add, remove and correct requirements.
The reasons for having to do this can vary, but changes in the stakeholders
needs or simply that a requirement has been overlooked are some examples.
Each of these activities is comprised of numerous of methods and techniques, some of
which will be discussed later.
3.2 Non-functional requirements
There are essentially two types of requirements, functional requirements and non-functional
requirements. Functional requirements states what the system should do while the nonfunctional
requirements states constraints on how the system, or the development of
the system, should do things [52]. A functional requirement could for example be that
a system should support input of user information while a non-functional requirement
could be that the inputted information cannot exceed a certain amount of storage space.
These requirements can then be refined into lower levels of requirements specifying the
requirement in greater detail. The non-functional requirements will be the focus of the
report from here on.
Because non-functional requirements can be a vast amount of different things there is
a need to explain this in greater detail. Below follows some of the different things that
can be seen as non-functional requirements (even though they might actually become
functional through refinement) [52, 47]. This is however not in any way a complete list,
since such a list does not exist:

3.3. The Non-Functional Requirements Framework 13
– Security
– Safety
– Reliability
– Usability
– Performance
– Satisfaction
– Portability and Maintainability
– Look and Feel
All of these requirements can of course be refined, for example can the security-requirement
include several lower-level requirements such as confidentiality, integrity and accuracy
(which also could be a lower-level of reliability) [10]. All of the mentioned requirements
are quite intuitively connected to the system, but there are also requirements that are
more connected to the development project itself [52]. These can all be categorized
under a refined requirement type; the project-requirement type. An example of such a
requirement could be that the project has a specific budget or time frame in which it
has to be completed.
3.3 The Non-Functional Requirements Framework
There are several approaches to handling non-functional requirements [10, 13, 24], but
most seem to build on the non-functional requirements framework (NFR framework)
laid out by Chung et al. [8]. The NFR framework is a process-oriented approach. This
means that rather than focusing on the finished product and evaluating this, as is done
in a product-oriented approach, the NFR framework aims at supporting the development
process by aiding the justification of design decisions. The framework consists of
five components that together aim at enabling representations of non-functional requirements
and the relations between them. The components are softgoals, interdependencies,
an evaluation procedure, methods and correlations. This section will explain these in
greater detail. The framework also presents something called softgoal interdependency
graphs where the softgoals and their interdependencies are represented in a graphical
form. These graphs support design rationale and contains a complete representation of
the design decisions.
3.3.1 Softgoals
Non-functional requirements (NFRs) can be seen as goals, it is for example possible to
see the requirement that a system should be user friendly as a goal. A goal is however
classically seen as something that is strictly solvable or satisfiable, or unsolvable or
unsatisfiable. This is however not the case with NFRs as they, by their very nature,
are subjective. A system might for example be considered user friendly by one user and
extremely difficult to use by another. The NFRs can also be considered accomplished

14 Chapter 3. Requirements engineering with non-functional requirements
at one time and unaccomplished at another time. An example of this could be that a
system might have great response time when just a few users are using it, but become
slow if many users interact with it at the same time. Yet another problem is that NFRs
are relative, that is, they can be accomplished to different degrees (for example an
accurate system or a very accurate system). Because of these kinds of difficulties with
determining whether a NFR is accomplished or not, the notion of softgoals is introduced
in the NFR framework. Softgoals, as opposed to ordinary goals, do not have to have
any specific criteria as to whether or not it is satisfied. Instead they can be evaluated
qualitatively. Therefore the word “satisficing”, meaning that something is satisfactory
to a sufficient degree, is used instead of “satisfying”.
The NFR framework presents three types of softgoals [41, 8]. Each of which has an
associated type and a number of topics (one or more). The type describes what the goal
is about and the topics define what it actually implies. For example: a softgoal to have
good performance for a system would be of the type “performance” and have the topic
“system” (generally the declaration would be as follows: “Performance[System]”). The
three different softgoals, all of which appear in the softgoal interdependency graphs, are:
– Non-functional requirements softgoals These describe the general NFRs and
the types thus range over all the types that non-functional requirements can be
(for example, accuracy, performance, security and so on). These work as global
constraints on the system as they can have an impact on the entire system rather
than just small parts. Later the NFR softgoals must be satisficed by the operationalizing
goals.
– Operationalizing softgoals The operationalizing softgoals declare solutions as
to how to satisfice the NFR softgoals. For example: to satisfice a NFR softgoal
stating that an operation cannot take longer than a certain amount of time, an
operationalizing softgoal might state that the operation should be cancelled if the
time limit has been exceeded (this might not be a good solution, but nonetheless
it would satisfice the NFR softgoal). These softgoals also have types and topics in
the same way that NFR softgoals has.
– Claim softgoals These softgoals are always of the type “Claims” and their topics
are “statements” in the form of declaring arguments. They can be both formal and
informal and an informal claim with an argument for choosing a certain solution
might for example look like this: Claim[“data storage performance is more vital
than time performance”]. Thus they represent design rationale as they serve as
argumentation for different solutions.
All of these softgoals can, and really are encouraged to, in turn be refined by forming
subtypes that specifies special cases of the original softgoal. The refinement of softgoals
is called decomposition. More specifically: NFR decomposition, operationalization
decomposition and argumentation decomposition (for NFR softgoals, operationalizing
softgoals and claim softgoals respectively). The softgoals are represented by different
figures in the softgoal interdependencies graphs, these figures along with examples are
shown in Figure 3.1, 3.2 and 3.3.
The difference between the different softgoal representations is, as can be seen in the
figures, that NFR softgoal is a regular cloud, operationalizing softgoals is a cloud drawn
with a thicker line and claim softgoals are drawn with a dashed line.

3.3. The Non-Functional Requirements Framework 15
Figure 3.1: NFR softgoal example.
Figure 3.2: Operationalizing softgoal example.
3.3.2 Interdependencies
When refining softgoals the need to represent their relations to other softgoals arise and
this is where interdependencies come in. Essentially there are two types of interdependencies,
AND- and OR-contributions. These denote if all children or just one child of
a particular softgoal has to be satisficed in order to satisfice the parent softgoal. “Children”
in this case are simply decompositions of any particular softgoal (which will be
displayed under and connected to a parent softgoal via an interdepency). The ANDand
OR-contributions are not however sufficient as child softgoals can influence the parent
softgoal to varying degrees. There are therefore a few other different contributions.
These are:
– MAKE: A strong positive contribution, sufficient to satisfice the parent softgoal if
the child softgoal is satisficed.
– BREAK: A strong negative contribution, sufficient to deny the parent softgoal if
the child softgoal is satisficed.
– HELP: A positive contribution. If a child softgoal is satisficed it provides partial
support for the satisficing of the parent.
– HURT: A negative contribution. If a child softgoal is satisficed it provides partial
support for denying the parent.
– SOME+: Some positive contribution, either HELP or MAKE.
– SOME-: Some negative contribution, either HURT or BREAK.
– UNKNOWN: Some contribution of an unknown type and importance.
The different kinds of contributions and how they are depicted in the softgoal interdependencies
graphs are shown in Figure 3.4 and 3.5.
Figure 3.6 shows how a graph can look when it has been somewhat refined and many
of the softgoals and interdependencies are used (this is however not a complete graph
for an entire system but rather just for a small part). The example is based on the

16 Chapter 3. Requirements engineering with non-functional requirements
Figure 3.3: Claim softgoal example.
Figure 3.4: Different types of contribution (adapted from Chung et al. [8]).
Figure 3.5: AND- and OR-contributions (adapted from Chung et al. [7]).

3.3. The Non-Functional Requirements Framework 17
requirements for a credit card system, but the actual requirements are not the focus.
The focus instead lies on the graph and how it is composed. Notable in the graph is
the exclamation mark that has not been introduced before. This is simply a way to
represent a prioritized softgoal. As can be seen in the figure, this is done by adding
a child with the same type and topic as the parent and with the notation “{critical}”
at the end. The claim in the graph is aimed at a link and thus acts as an argument
for why the refinement (the prioritization in this case) is made. As such it is not an
offspring to a softgoal, although claims can be this too, but rather an offspring of the
interdependency itself. At the bottom of the graph are some operationalizing softgoals
where the “FlexibleUserInterface” seems to support denying of the prioritized softgoal
“Accuracy[GoldAccount.highSpending]” while the other operationalizing softgoals seem
to support satisficing of the parent. A AND-contribution is shown at the top of the
graph showing how the NFR softgoal “Accuracy[Account]” has been decomposed into
“Accuracy[GoldAccount]” and “Accuracy[RegularAccount]”. This shows that both gold
accounts and regular accounts have to be accurate if accounts in general are to be
considered accurate.
Figure 3.6: Softgoal interdependencies graph. An example for a credit card system
(adapted from Chung et al. [8]).

18 Chapter 3. Requirements engineering with non-functional requirements
3.3.3 Evaluation procedure
When a softgoal interdependencies graph has been established it is time to determine
whether or not the top requirements are satisfied. This is done by taking a proposal for a
design, or feature, and using the evaluation procedure to see how that design would affect
the rest of the system. These decisions are generally “leaf” nodes in the graph. What is
done is that the node gets a label applied to it and the procedure could then be seen as
an algorithm that “calculates” what consequences this has. The label describes to what
extent a node has been satisficed, typically the label should be denied or satisficed though
there are more labels which will be introduced later. When a label has been applied to a
leaf-node the interdependency towards its parent then determines how the label should
be propagated upwards. If for example the “Validation[GoldAccount.highSpending]”
softgoal (as seen in Figure 3.6) would be labelled satisficed the MAKE contribution
towards its parent would result in the parent also being satisficed (though there could be
a conflict if the softgoal “FlexibleUserInterface...” also would be satisficed). This process
then continues until all nodes upwards are calculated. This is not enough however as
uncertainties and conflicts might appear in the graph. To handle this four basic labels
are introduced. These labels are (the graphical representations to be used in the softgoal
interdependencies graphs are shown in Figure 3.7):
– Satisficed (S) - denotes a goal or link that is satisficeable and not deniable.
– Denied (D) - denotes a goal or link that is deniable and not satisficeable.
– Conflicting (C) - denotes a goal or link that is both satisficeable and deniable.
– Undetermined (U) - denotes a goal or link that is neither satisficable nor deniable.
There is however also the possibility that a softgoal might have some support, but not
enough, for it to be either satisficed or denied. If only the previously mentioned labels
were used that would result in the softgoal being undetermined, but it would be better
if the developer could step in and determine if the softgoal actually was satisficed or
not. Therefore two more labels are introduced:
– Weak positive (W+) - represents positive, but inconclusive support
– Weak negative (W-) - represents negative, but inconclusive support
These labels should however be replaced by one of the four basic labels by the developer
and thus not be present in the graph when the procedure is finished (they should not
contribute to the parent label either). In case of the “conflicting label” the developer
can also step in and determine the label that should contribute to its parent.
There is also the issue of how the labels should be propagated through the graph. When
a satisficed label should be propagated through MAKE or BREAK contributions it is
pretty straight forward, but if the label is denied or undecided or if the contribution is
of another type it becomes more difficult. Table 3.1 shows how different labels should
be propagated through various types of contributions.

3.3. The Non-Functional Requirements Framework 19
Figure 3.7: Effect of the source label on the parent label (adapted from Chung et al.
[8, 41]).
For example if the “Validation[GoldAccount.highSpending]” softgoal from Figure 3.6
was assumed satisficed the result would then look like the one in Figure 3.8. At least if
all other softgoals are undefined (as they by default are) and that the developer steps
in and sets the result for !Accuracy[GoldAccount.highSpending]{critical} to satisficed
despite any negative influence from its child nodes. Notice that the claim softgoal in
the figure is also set to satisficed. This is the default value for claims as they commonly
provide arguments. Notice also that the “Accuracy[GoldAccount]” is set to W+, which
should not actually be present in a final graph, but is rather just a notation that the
developer should step in and determine whether or not the softgoal has been satisficed.
(The UNDEFINED labels could also be omitted, since the default labels of NFR and
operationalizing softgoals are UNDEFINED).
3.3.4 Methods
Methods, or refinement methods, helps the engineer to create the interdependencies
graphs. This is done mainly by aiding the capture, reuse and improvement of the
interdependencies between softgoals. Since further information about the softgoals can,
and often has to, be drawn from industrial experience or academic studies it would
be good to be able to catalogue and store this information, which is exactly what the
refinement methods do. Simply put, they provide the engineer with predefined ways
in which a softgoal can be refined. A method might for example look like this: “In
order to have good performance both space performance and time performance must be
Table 3.1: Effect of the source label on the parent label (adapted from Chung et al.
[8, 41]).
Contribution type
Label BREAK SOME- HURT UNKNOWN HELP SOME+ MAKE
source
D W+ W+ W+ U W- W- D
C C C C U C C C
U U U U U U U U
S D W- W- U W+ W+ S

20 Chapter 3. Requirements engineering with non-functional requirements
Figure 3.8: Softgoal interdependencies graph in the middle of the evaluation procedure
(where the label for the softgoal “Accuracy[GoldAccount]” has not yet been definitively
determined by the developer). Adapted from Chung et al. [8].

3.3. The Non-Functional Requirements Framework 21
good” (based on that the performance type has these subtypes [45], which in turn can
be refined even further). Methods can however be more general, such as for example
“In order to have good performance, all sub-types of performances must be good”. This
methods can in turn be illustrated using the interdependency type AND as shown in
Figure 3.9.
Figure 3.9: Method (adapted from Chung et al. [7]).
The mentioned methods are just examples however and there are more specific ways to
use refinement methods. The basic idea is that there are refinement methods for each
type of softgoal and the methods are [8]:
– NFR decomposition methods
– Operationalization methods
– Argumentation methods
To summarize the use of these methods one could say that the NFR decomposition methods
are used to refine the NFR softgoals to a sufficient extent, then the operationalization
methods are used to satisfice the generated softgoals while the argumentation methods
provide motivation for certain design decisions. We can thus see that the example in
Figure 3.8 is a NFR decomposition method since it refines the softgoal Performance
which in itself is a NFR softgoal. More specifically it refines the NFR softgoal based
on its type. Refinements can also be based on the topic and they can be NFR-specific,
generic or developer defined, but all of these variations will not be developed any further
here. There are also similar variations for the operationalization and argumentation
methods, but these will not be discussed here either. Chung et al. [8] delves deeper into
the specifics and details regarding methods.
3.3.5 Correlations
Just like the methods the correlation rules are an aid to capture and reuse information.
Correlations however represent the effect in terms of synergies or conflicts that different
softgoals have on each other. Thus these rules is in a sense the collected knowledge and
experience about certain correlations between different softgoals. These can be put into
tables or “correlation catalogues” that show the correlations and can thus be used by the
engineer when choosing between different alternatives [41, 7, 8]. The correlations can be

22 Chapter 3. Requirements engineering with non-functional requirements
of different importance, in the same way as the interdependencies discussed earlier. An
example of such a correlation catalogue is shown in table 3.2. It presents the correlation
between a few NFR softgoals and operationalizing softgoals where the operationalizing
softgoals are presented on the top of the table and the NFR softgoals are represented to
the left.
Table 3.2: Correlation catalogue (adapted from Chung et al. [8]).
Non-functional
requirements
softgoal
Accuracy[Info]
Compressed-
Format-
[Info]
Confidentiality[Info]
HELPS
ResponseTime[Info] HURTS HURTS
Space[Info]
HELPS
Operationalizing softgoal
Validation- Flexible-
[Info] User-
Interface-
[Employee,
Info]
HURTS
WHEN
[condition]
Perform-
First[Info]
HELPS
As seen in table 3.2 there can be empty cells in the catalogues, this simply represent
an undefined correlation. It is also possible to have conditions in the correlation rules,
these are represented by a “WHEN [condition]” clause.
3.4 Eliciting requirements
To define the requirements for a system it is important to gather initial information about
the system one is about to design. The information gathered can then be used in different
methods and frameworks, such as the Non-Functional Framework described earlier, to
further define and specify the requirements. The need to gather more information during
the process might of course also arise. This is a natural part of the design process.
There are several techniques for finding, or gathering, information about a system. The
most basic one is perhaps introspection, where the designer simply tries to imagine what
a system has to accomplish and in what way it has to do it [23]. This might actually
give quite a lot of information, but of course has its drawbacks since the designer does
not have the same idea of a system that the user might have. It can differ in many ways,
experience, skill, goals and so on. There are therefore several data-gathering techniques
that can be used to find information about a system. The actual amount of techniques
is hard to say, but most of them build on the following basic techniques [52]:
– Questionnaires
– Interviews

3.4. Eliciting requirements 23
– Focus groups and workshops
– Observing users
– Studying documentation
Common for all of the mentioned techniques is that one technique in itself is probably
never enough. One might focus on a single technique but the results almost always
have to be complemented in order to cover even a part of the interesting needs and
requirements. The different techniques also give different perspectives of the information
gathered.
3.4.1 Questionnaires
As mentioned earlier in the Methods chapter questionnaires are a good way to reach
a wide population, but to do so effectively it is important that the questionnaires are
designed in a good way. Some good tips for designing questionnaires are [52]:
– The questions should be clear and specific.
– Place general questions before more specific ones.
– Use closed questions with alternatives rather than open questions if it is possible.
– Complex multiple questions should be avoided.
– The scales, if such are being used, should not overlap.
– Be consistent and avoid negatives when using scales.
– Instructions on how to fill in the questionnaire should be provided.
– Avoid too long questionnaires.
There are several different scales that can be used; one frequently occurring one is the
Likert scale which is used to elicit opinions, attitudes and beliefs [52]. Likert scales
work by presenting a statement and a scale on which the statement should be rated (see
Figure 3.10 for an example). The rating can be done with either numbers or words.
Figure 3.10: Example of the use of a Likert scale.

24 Chapter 3. Requirements engineering with non-functional requirements
As seen in Figure 3.10 the rating of the scale is based upon the agreement or disagreement
to the statement.
When designing Likert scales one must first decide which statements should be evaluated.
A good way of doing this is to have a brainstorm session. One also has to decide on
how to phrase the questions, positively or negatively. There is no real consensus on
how this should be done, both entirely negative and positive questionnaires as well as
mixed questionnaires are being used, but it all comes down to the complexity of the
questionnaire. If the questionnaire has both negatively and positively phrased questions
it becomes more complex. Finally one must decide which scale to use. Once again
there is no real consensus on which is best, but 5- and 7-point scales are quite common,
though it is possible to use even numbered scales as well. By doing this the neutral
central point is removed and the participants are thus forced to make a decision.
When the design of the questionnaire is finished it is just a matter of getting participants
to answer it. It is quite common to use small numbers of participants and in these
cases it is quite possible to get everyone to fill out the questionnaire. If however more
participants are required there are a few things to think about to get a good return rate.
The most basic is of course to have a well designed questionnaire, but here follows some
additional tips [52]:
– Provide a short overview section to make sure that at least some information is
returned.
– If the questionnaire has to be returned by mail, include a self-addressed and
stamped envelope.
– Guarantee the anonymity of the participants.
– Explain to what end the questionnaire is being used.
– If possible offer some sort of incentive for participating.
– Consider using some follow-up or reminder.
3.4.2 Interviews
Interviews can be compared to a normal conversation; the only difference is that in
an interview the interviewer has a purpose to gather information from the interviewee.
This is of course quite a crude definition, and how similar an interview is to a regular
conversation depends on how the interview is performed. There are basically four types
of interviews: open-ended (or unstructured), semi-structured, structured and group
interviews [52]. Group interviews will not be discussed here since it is so similar to focus
groups (in fact the terms are often used interchangeably). Structured interviews will
not be discussed in any great detail either since they consist of a set of predetermined
questions very much like a questionnaire. That leaves open-ended and semi-structured
interviews. In an open-ended interview the interviewer asks a question and then lets
the interviewee answer it in any way he/she wishes. The interviewer is then free to
probe for fuller responses. Since both the interviewer and the interviewee can affect and
steer the interview in any direction or take it to any level of detail it can result in a
lot of information that the interviewer have not considered, but of course such rich and

3.4. Eliciting requirements 25
unstructured information can also be difficult to handle. There are also problems with
the type of questions that can be answered; it is for example very difficult to answer
questions on how one performs a certain task that one is not used to describing. A
rule of thumb is thus to avoid questions that regard such issues [23]. An open-ended
interview also demands that the interviewer is structured and well prepared [52]. Some
good tips are:
– Have a well defined goal for the interview.
– Make sure that the interviewee is comfortable.
– Avoid influencing the ideas of the interviewee too much (ideally not at all).
– Analyse the data as soon as possible after the interview is over.
Semi-structured interviews share some principles with both open-ended interviews and
structured interviews, mainly it is a combination of them to be able to produce as
much information as possible for certain topics. This is done by having a basic script
to assure that certain topics are being covered. Then the interviewer tries to gather
as much information as possible for each topic by probing for deeper information until
there is no more relevant information regarding that topic to gather. The interview then
proceeds to the next topic and so on. As with all forms of interviews it is important
not to introduce bias and questions should therefore be asked in a neutral way. Body
language is also something that the interviewer needs to have control over as a smile
or frown can easily influence the interviewee. Probes and prompts are things that can
be used to keep the interview flowing, but when using them it is once again important
to avoid introducing biases. Probes are used to gather more information and can be
questions such as “do you want to add anything?” while prompts are used to help the
interviewee to remember something (for example if the interviewee cannot remember the
name of a certain feature, the prompt can then be to mention the name of the feature).
It is however important to allow the interviewee time to think and thus the interviewer
should not interrupt silences too soon during the interview.
3.4.3 Focus groups and workshops
Focus groups are best suited when it is desirable to evaluate a new idea or to test a
concept. It can also be used to design quantitative studies, such as questionnaires,
where the focus group functions by determining certain issues regarding a topic that
might be interesting to research quantitatively. Finally focus groups might also be used
to qualitatively develop data gathered earlier using quantitative techniques [16].
Focus groups normally consist of three to ten people; basically it must be large enough to
allow discussion and small enough so that everyone gets a chance to speak [52, 32]. Even
though selecting people for focus groups seems simple enough there are some difficulties.
The most common problem is perhaps that it is difficult to gather enough people in a
particular place and time simple because people cannot get there or do not have the time
[52]. Additionally the composition of a focus group is not self evident. The idea is to
have a homogenous group of people that can answer the questions that needs answering
[32]. The problem with this is the classification, if one classifies stakeholders as one

26 Chapter 3. Requirements engineering with non-functional requirements
homogenous group there is no differentiating aspect to the types of stakeholders (i.e.
customers, developers, their age etc.). If the classification is too fine however, it becomes
impossible to cover all stakeholders. An example of a too fine classification could be
to have a group consist of only male developers between the age of 21 and 23 with a
certain income etc. In this case there would simply become too many groups to handle.
About four to six groups is generally a good amount for a project, but of course, if there
is a distinction between several different types of stakeholders and one wants to include
them all in separate groups this number will increase [40].
To handle a focus group it is necessary to have a moderator that guides the discussion.
The moderator is also responsible for making everyone a part of the discussion
by encouraging silent people to speak and stopping other people from taking over the
discussion completely. Another important aspect of the moderator’s task is to follow
up on interesting issues. The moderator must handle all of this and at the same time
avoid interfering with the interaction between the participants too much which makes
for a very demanding task indeed. This is also one of the problems with focus groups
as it demands quite a lot from the moderator [52]. Even if there is a good moderator
available it is also important that he/she does not have influence over the participators
or that he/she is not biased regarding the questions and answers. A moderator can not
for example make judgement on the opinions of the participators [32].
3.4.4 Observing users
All the previously mentioned techniques are of course very useful, but when it comes to
how people perform a certain task none of them is really that good. This is because of
the problems people have with describing what they do. So to be able to gather this
kind of information observations can be used. Observation of course is quite a wide
notion and there are several ways to conduct such research. First of all it is possible
to observe in a controlled environment or in the actual environment that the observed
situation usually takes place. There is also a range of involvement; from the “outside
observation” where the researcher is not involved at all in observed persons work to the
“participant observation” where the researcher is fully involved. While the observation
performed in a controlled environment is focused more on the details of how tasks are
being performed the field-studies are more holistic and thus can capture more of the
context of the work. This is again something that can be difficult to capture using other
techniques [52]. There are several different techniques for observing users, too many to
go into here, but overall the aim is to gather information about what and how the users
do things.

Chapter 4
Models & methods for
evaluating games
This chapter is written by Anders Engqvist. It examines theories, models and methods
that can be used in the evaluation of video games. The chapter begins with a short introduction
to usability and usability evaluation. Then it examines some of the differences
between video games and other types of software. Later some models and theories that
can be useful in the evaluation of games are presented. Finally this chapter describes
some evaluation techniques for games.
4.1 Introduction
Usability is a term that concerns how easy a product is to use. The exact definition of
usability varies, but it involves a user’s objective performance and subjective satisfaction
with a system. Jacob Nielsen have identified the following five components of usability
[43]:
– Learnability. The system should be easy to learn so that a user can rapidly start
working.
– Efficiency. The system should be efficient to use, so that the user can achieve a
high level of productivity.
– Memorability. The system should be easy to remember, so that the user does
not have to learn it again after a period of absence.
– Errors. The system should have low error rate, and the user should be able to
recover from errors when they occur.
– Satisfaction. The system should be subjectively pleasant to use.
The focus of usability is on the user rather than the product. It concerns the quality of a
user’s experience when interacting with a product or system. One related concept is usercentred
design. User-centred design means early focus on users, empirical measurement
27

28 Chapter 4. Models & methods for evaluating games
of product usage and iterative design [3, page 7]. The process of incorporating usercentred
design into product development is sometimes called usability engineering [3].
The usability engineering lifecycle is shown in table 4.1 below [19, page 15]:
Table 4.1: The usability engineering lifecycle model. Adapted from Faulkner [19].
Task
Know the user
Know the task
User requirements capture
Setting usability goals
Design process
Apply guidelines heuristics
Prototyping
Evaluating with users
Redesign and evaluate with users
Evaluate with users and report
Information produced
User Characteristics, user background
User’s current task, task analysis
User requirements
Usability specification
Design
Feedback for design
Prototype for user testing
Feedback for redesign
Finished product
Feedback on product for future systems
A large and important part of the usability engineering lifecycle is the evaluation. The
purpose of usability evaluation is to analyze how usable a chosen design of a product is.
There are several usability evaluation techniques and they can be divided into usability
inspection, testing and inquiry [21].
Usability inspection is a group of methods where experts inspects, or examines the usability
of a product. The most popular method is Heuristic evaluation [3, page 35].
Heuristics for usability are properties and principles that positively affect usability.
Heuristic evaluation is performed by an expert evaluator which spends some time alone
with the system and tries to find occurrences where a particular principle is broken.
There are several different heuristic principles available that an evaluator can use.
Heuristic evaluation can be performed early in the development process, before a working
prototype is implemented. This is because the evaluator only needs the specification
of the design to be able to evaluate it.
Usability testing provides direct information on how users are using a system and what
problems they have. Testing for usability means to directly involve end users and observe
where problems arise. The session is usually recorded for future analysis, so that the
evaluator can see how the user is performing a task. But only recording does not answer
why a user does specific actions, so they are often encouraged externalize their thoughts.
This procedure is called the think out loud protocol. To think out loud is unnatural for
most users and the evaluator may have to remind them throughout the evaluation [3,
pages 235-238].
Usability inquiry concerns learning the likes, dislikes and needs of the users. This can
be achieved by field studies or more or less structured interviews. Another method that
can be used early in the design process is focus groups.
Satisfaction is one of the components of usability, but it is least understood. The
methods for evaluating satisfaction tend to be quite crude and vague and only limited

4.2. Beyond usability in the design and evaluation of video games 29
to what users think of a product. A usual assumption is that with great usability follow
user satisfaction. But the motives for playing games are different then using productivity
software, so it is not certain that this assumption is true [36].
4.2 Beyond usability in the design and evaluation of
video games
While usability evaluation methods and techniques can detect issues in the design and
evaluation of video games, they are usually quite bad at capturing the “gameness” of
games [34]. Usability techniques were designed to maximize productivity, while games
are not productive in themselves [25]. There are similarities between them, both have
for example interfaces and the user have to form a mental map of their functionality
[14], but there are several differences between them, something we will take a closer look
later on.
The goal with usability design and evaluation is to decrease and remove obstacles for the
user when performing a task. One can argue that the most usable game is a big button
that says “Press here”. When the player then presses the button, a big sign pops up
that says “You won”, but this would be a rather dull and boring game [48]. The goal
with game design is (among others) to create obstacles that are fun and challenging for
the player, so the goal of usability evaluation in game development must be to remove
the obstacles that are not fun or not even meant to be obstacles. In a strategic game
for example, the main obstacle is to beat the opponent with a superior tactic. Moving
the troops over the battlefield is most likely a main part of the game, but if the player
has to individually select every instance of a soldier and go through five submenus to
move a company from point A to point B, this obstacle would quickly overshadow the
obstacle the designer intended.
Chuck Clanton [9] identified three levels of a game where usability issues can arise. The
game interface is the input/output devices of the game. It is the controls and what
is displayed on the screen. It is associated with the motor and perceptual skills of the
player. The game mechanics is the “physics” of the game, how the game world works
and what the player avatar and other inhabitants can do in that world. Most games
have goals, subgoals and challenges. The process of discovering and overcoming them is
called the game play. All of these three levels of a game require evaluation [20].
During user evaluation of a video game, two types of problems can arise; usability
problems and “fun problems” [2]. A fun problem is not a problem that is fun; it is
a problem that might lessen the joy of playing a game. It can for example be that a
challenge is too hard. There are heuristics for both evaluating usability (e.g. Nielsens ten
usability heuristics [43]) and fun problems (e.g. [20]), and sometimes the evaluator might
have difficulties choosing the right set of heuristics. Barendregt et al. [2] have developed
a procedure to distinguish fun problems from usability problems, see figure 4.1. The
procedure consists of the following questions:
1. Could the problem be solved with verbal explanation? If yes it is probably
a usability problem, go to 2. If no it is probably a fun problem, go to 3.

30 Chapter 4. Models & methods for evaluating games
Figure 4.1: The procedure to separate fun and usability problems. Adapted from Barendregt
et al. [2].
2. Was it meant to be difficult? If yes it is a fun problem, if no a usability
problem.
3. Can taking over the device (mouse, gamepad etc.) solve the problem?
If yes it is a motor skill problem that can either be a fun or a usability problem,
go to 4. If no it is a fun problem, for example that the game is too scary and the
player does not want to continue.
4. Was it meant to be difficult? If yes it is a fun problem because the game is
too hard, if no it is a usability problem.
4.3 Differences between productivity software and video
games
Usability methods were designed for productivity software, but games are not productive
in themselves. It is important, when choosing methods for evaluating games, to
understand how they differ from other types of software. Knowing the differences can
also help in designing new methods for evaluation. Pagulayan et al. [48] have identified
several differences between video games and productivity software that will be presented
below.
Productivity software is used as a tool to accomplish a task. The only thing that
separates it from a hammer is the domain and the purpose for usage. Games, on the
other hand, should be fun; they have no other purpose than entertainment. They are
more like movies or books in that sense. Games should also stimulate thoughts and
emotions. Other types of software also require thinking, but that is not the purpose.
Games define their own goals. Other types of software are used to achieve external goals.
Some applications have easily defined goals, like an online store. Other types of software
can have more complex and variable goals, like a spreadsheet program. The challenge

4.4. Playability and gameplay 31
is to design an interface that let the user achieve her goals as easy as possible. This
is harder when the software is more general. Games define goals in the world that the
game creates, and they are only valid in that context. This can make it easier because
the evaluator exactly knows which goals the player has. The challenge is to convey the
goals to the player and making sure that the player is aware of the resources accessible
to reach the goals.
Users want consistency when using productivity applications. Menus should work the
same way even between different types of applications. Games have to create a different
experience every time to prevent the player from becoming bored. They should offer
alterative strategies and new rules to learn. The pressure to all the time create new
experiences can make game designers abandon used and tested interface solutions and
standards.
Most productivity applications are controlled in the same way. The user often uses a
keyboard and mouse. Games have different controls for different types of games and
platforms. They are often innovative and solve many different issues, but they can also
introduce entirely new challenges.
Productivity software offer just as much sound and graphic as necessary to convey
functionality. In games the environment is created by using sound and graphics. It can
also be used to set the mood and create tension in a game. This could lead to that
usability becomes sacrificed for the sake of aesthetics.
4.4 Playability and gameplay
Playability is usually understood as usability in the domain of games [18]. Järvinen et
al. [27] tries to further define the term. They define playability as “a qualitative term
for the uses of both design and evaluation. It refers, on the one hand, to the guidelines
regarding how to implement the necessary elements (such as rules) to give birth to a
desired sort of gameplay...”.
Gameplay is basically what defines a game as a game. It concerns both the formal
elements of a game, i.e. the rules and components, and the player. Gameplay and
interaction are the same, but the term gameplay is used when a player interacts with a
game (with rules and goals). Different types of games offer remarkably different types
of gameplay. Anyone that plays games long enough forms their own concept of good
and bad gameplay based on their experience [17].
Evaluating playability means to analyze how well a game conforms to a desired sort of
gameplay. Playability can be divided into the four components functional, structural,
audiovisual and social playability [27].
Functional playability refers to the functional aspects that affect gameplay. It relates
to the controls of the game and is close to traditional usability. Analysing functional
playability means for example to evaluate how well the input-device is configured to give
the desired gameplay.
Structural playability concerns the mechanics of games. One thing that gives structure
to a game is the rules of the game and the patterns that emerge from these rules.

32 Chapter 4. Models & methods for evaluating games
The rules define the game, and actions in the game are only relevant when they are understood
in the context of these rules. The actions form patterns that look the same in
several sessions of the game. One particular instance of a game play has variations, but
after several sessions’ patterns emerges. These patterns evolve into structures. Some
structures are common in several games; move - change of game state - countermove is a
structure that could be found in many games, particularly in strategy and sport games.
Here one player makes a move that changes the state of the game, and then the other
player evaluates this new state and makes a move according to it. In sport games this
happens in real-time. In evaluation, it is important to find the structure of the game to
be able to tell if it gives the desired player experience.
Changes in audiovisual playability can drastically change gameplay. The visual spectrum
goes from photorealism to cartoonish style and can drastically change what kind of
customers the game appeals to. By analysing audiovisual playability you can tell if the
sound and graphic is the best to mediate the desired gameplay, or if there are confusing
elements in the game world.
Social playability regards the desired context of use (computer or on television and
single player or multiplayer) and player communication. Communication can take place
both in-game (in multiplayer games) and off-game. Off-game communication includes
for example forums, mailing-lists and the official game website where players can share
and discuss their experiences of the game. It is important to offer both in-game and
off-game communication.
Playability is greater than the sum of the four parts presented here, but for the purpose
of evaluation it has to be divided into components. Even if the four components are
all part of the concept of playability, there can also be conflicts between them. High
functional playability can contradict high structural playability. In some games designers
want many options so that the player can meaningfully interact with the game world.
This often means to make the control complex and less intuitive [33].
The concept of playability can give structure in the design and evaluation of games, but
the concept is mostly focused at the game itself. It does not say much about the player
experience or the player motivations for playing a particular game. To be able to truly
understand, and thus evaluate, the act of playing, we have to look at the player and her
motivations and experiences while playing a game. Therefore we will look at some of
the theories that can give an understanding of player experience and motivation.
4.5 Flow
Csikszentmihalyi [12] studied what made experiences pleasurable for humans. He was
interested in what made a person do a hard/difficult task when the only motivation was
in the task itself, i.e. the reward was in the task. He asked people to describe their
experience when they were doing what they liked most. He called this experience flow,
an optimal state of enjoyment where people were totally absorbed in an activity. This
experience was similar to all people, no matter of age, sex or culture.
Csikszentmihalyi found that there were two variables that determined the type and
intensity that an individual experienced during an activity. These were the perceived

4.5. Flow 33
difficulty of the task and the skill level of the individual [35]. These two variables can
give rise to nine different experiences (see 4.2):
Figure 4.2: The two dimensions of flow experience. Adapted from Lemay [35].
1. apathy: low challenge and low competence
2. worry: average challenge and low competence
3. anxiety: high challenge and low competence
4. relaxation: low challenge and average competence
5. neutral: average challenge and average competence
6. arousal: high challenge and average competence
7. boredom: low challenge and high competence
8. control: average challenge and high competence
9. flow: high challenge and high competence
To experience flow, both challenge and skills must be above average, i.e. the challenge
has to be so hard that it takes all the players attention and skill to overcome. Flow
can emerge from any kind of experience; from a ten minutes game of Tetris to a five
year research project. The flow experience is characterized by the following criteria [12,
pages 49-67]:
1. A challenging activity that requires skills. More often than not the activity is goal
directed and bounded by rules. The activity requires investment in psychic energy.
2. A task that has clear goals and offers immediate feedback. The goals can not be
too easy or too hard to achieve. If the activity in itself does not offer a clear goal
or feedback, people engaging in that activity has to formulate their own goals and
learn to recognize good and bad feedback. Writing and painting are examples of
such activities.

34 Chapter 4. Models & methods for evaluating games
3. An ability to concentrate on the task at hand. In everyday life, all sorts of thoughts
and worries constantly attract attention. During flow experience, all attention is
concentrated at the task at hand, so there is no room for irrelevant information.
4. A perceived sense of control over actions, and lack of a sense of worry about
loosing control. Failing an activity in real life can have consequences that are hard
to predict beforehand. It is also hard to predict the long term outcome of different
actions. In games, the consequences of failing are known or can be predicted in
advance.
5. The merging of action and awareness. All relevant skills are needed to cope with
the challenge. There is no psychic energy left to process any other information.
All attention is directed to the relevant stimuli. As a result people stop being
aware of themselves as being separate from the actions they are performing.
6. A loss of self-consciousness or preoccupation with self. This means to loose the
image, or concept, of self, not a loss of self. Often people are highly aware of their
bodies during the state of flow. An athlete is aware of all muscles in the body
during exercise. The loos of self-consciousness can lead to a feeling of union with
the environment and thus pushing the boundaries of being forward.
7. The transformation of time. During flow the time does not pass like it normally
does. Hours can fly by like minutes, but sometimes the opposite is true; an hard
passage that in real time is over in seconds can feel like going on for minutes.
One important aspect in the flow model that is also important in games is the balance
between skill and challenge [25]. When a player first start playing a game, her skills
are basic and she does not know how to overcome all the challenges in the game. It is
therefore important to have easy challenges in the beginning of the game. As the game
progress, the player skills become greater and greater and challenges that before were
hard are now easy. Therefore the game has to offer greater and harder challenges to
keep the player the “flow zone” (see figure 4.3). This is the ideal of how a game should
be designed. Unfortunately, players have different skills and expectations of the game
experience, some want to enjoy a moderately easy game and some want to devote all
their skill in the game [6] (figure 4.4).
One way to solve this problem is to offer levels off difficulty that the player can choose
from in the beginning of the game (easy, medium and hard). The disadvantage with this
approach is that the player is stuck with this choice for the rest of the game. Different
players also develop their skills at different pace, so what is medium challenging for a
player at the beginning of the game can be too easy or too hard at the end [6].
Some games let the player adjust the level of difficulty throughout the game by offering
several choices to the player. The player can for example be given several alternatives
with variable difficulty to complete a mission. The problem with this approach is that
it can be costly to implement. Too many alternatives could also confuse the player, and
so disturb the sense of flow [6].
According to Chen [6] the best way to provide an enjoyable experience for all types of
users is to embed all choices in the core activities. That means that when the player
becomes more experienced she can perform more actions and therefore choose how to
play herself. This is how it often works in the real world, whether it is skating, sewing

4.5. Flow 35
Figure 4.3: The optimal flow zone. Adapted from Chen [6].
Figure 4.4: Different zones for different players. Adapted from Chen [6].

36 Chapter 4. Models & methods for evaluating games
or skiing. The more experienced you are the more choices you have to engage in greater
challenges.
4.6 Immersion
Both players and researchers agree that immersion is an important quality when playing
a game. Immersion is often used to refer to the degree of involvement or engagement one
experiences with a game [25], but the exact definition varies between researchers and
disciplines. Many players also have their own definition of immersion, so Brown & Cairns
interviewed seven gamers in an attempt to define immersion [5]. They identified the
three levels of immersion; engagement, engrossment and total immersion. Each
level has a number of barriers associated with it. A player can not reach a particular
level until all barriers for that level has been breached. Removing these barriers does
not, however, guarantee that the player becomes immersed at that level; they are only
preconditions for the experience. Below follow a description of the three levels and the
barriers associated:
Engagement. This is the first stage of immersion and must occur before any other
stage. The barriers here are access and investment of time, effort and attention. Access
relates to that the player must feel that she can control the game and know the actions
and consequences. For a player to invest in a game she must first of all like the type of
game, if not she would not even try to engage in it. When these two barriers are down
the player can feel engagement in a game, she is interested and wants to keep playing,
but she is not yet emotionally involved in the game.
Engrossment. Engagement can evolve into engrossment. The barrier here is game
construction. A good constructed game combines (among other) visuals, interesting
tasks and plot in a way that the player’s emotions are directly affected by the game.
The emotional involvement can make the player feel “emotionally drained” when they
stop playing.
Total immersion. In this level the player devotes all attention to the game and it
feels as if she “is there”. What happens in the game is the only thing that occupies
the player’s thoughts. The only problem is that this is only a fleeting experience. The
barriers for total immersion are empathy and atmosphere. The player must be attached
o the main character or team and must empathise with their situation. Atmosphere is
created by the sound, plot and graphics of the game. These parts require attention, and
the more attention a player invests, the more immersed she can feel. In the case of total
immersion, these aspects also have to feel relevant to the player.
One problem with this classification is that it excludes certain types of games. To be
totally immersed the game needs to have a story and characters that the player can
sympathize with. Many games do not have either a story or characters, or offer them
only as a background that do not affect gameplay, but the player can still feel totally
immersed in the game [1]. Ermi & Mäyrä suggests that immersion is a multidimensional
phenomena [17]. They have identified three different types of immersion; sensory,
challenge-based and imaginative immersion.
Sensory immersion relates to the audiovisual experience of a game. Good graphics
and sound and a big screen easily overtakes impressions from the real world and the

4.7. Player experiences in games 37
player becomes entirely focused on the game world. This form of immersion is not only
found in games. Virtual environments such as CAVE [11] offer total sensory immersion.
Challenge-based immersion is fundamental for games and is found in the interaction
between player and game. This flow-like experience is most powerful when the balance
between the player’s abilities and the level of challenge matches. A challenge can require
motor-skill or mental-skill such as strategic or logical thinking. Many games usually
involve both types of challenges to some degree.
Imaginative immersion concerns the story and characters in the game. Many contemporary
games offer some sort of story that the player can get involved with, either by
actively take part of or just enjoy the development of the plot. This type of immersion
can be experienced when for example reading a good book.
Imaginative and sensory immersion is not only confined to games, but challenge-based
immersion is crucial in games because it demands active participation. When playing a
game, a player experiences a mix of these three types of immersion. They can also affect
one another, e.g. the types of challenges in a game effect the audiovisual experience of
that game.
4.7 Player experiences in games
While the theories of flow and immersion seem highly relevant in the design and evaluation
of games, they do not cover all emotions and experiences that a player can feel
when playing a game. The same game session can give rise to all types of emotions in
a spectrum spanning from frustration and anger to joy and euphoria.
Poels et al. [51] explored different types of player experience by using focus groups. They
found that many player experiences could be described as flow or as different types of
immersion. But they also found that for some it was not important to feel immersed
in a game world. Instead they enjoyed the freedom to be able to explore the world at
their own pace. While exploring they did not want to meet any challenge or pursue any
particular goal. They were more spectators of the game world than immersed in it.
Many players reported that when the game was too easy or too hard, they became
irritated and frustrated. If that happened there was a big risk that they would quit
playing the game. Some players however viewed some frustration as something positive.
If they had tried to overcome a challenge for a long time and finally succeeded, the
feeling of success became euphoric. In this way a negative feeling had transformed into
a positive.
To play with other people, either as a team or competing against each other strongly
affects the experience of a game. The emotions, both negative and positive, become
greater when competing against other people instead of the computer or other players
online. The feeling of being connected was also important when cooperating with other
players.
From the data gathered in the focus group and theoretical finings Poels et al. [51] tried
to categorize the gameplay experience into several core dimensions. Every dimension
contains both in-game and post-game experiences and is presented in table 4.2 below:

38 Chapter 4. Models & methods for evaluating games
4.8 Methods for the evaluation of video games
Games can be evaluated in the same way as other types of interactive software. The interface
of a game can for example be evaluated by using traditional usability techniques.
To account for the differences between games and other types of software new methods
has also been created. Some techniques for evaluating games are explained below.
The methods described do not cover all types and aspects of games. In games where the
social aspect is important (music, party, quiz) it is important to consider that and test
the game with a group of people instead of one and one. Other games like MMORPG’S
are played during a substantial period of time and it could therefore be hard to balance
the difficulty and pace of progress in such a game. Many companies therefore release
open betas for the public to play before the actual release of the game. In this way they
can see the long term effects and then balance the game.
4.8.1 Usability testing
Usability testing is performed in a lab or similar controlled environment. The goal is to
get objective data about users’ performance and no distractions are allowed. Usability
testing can answer questions such as time to complete a task, number of errors when
performing a task and number of users that succeeded in completing a task [52].
Before testing is performed a set of tasks that the participants should perform are
constructed. The tasks should be designed so that they generate valid data about the
Table 4.2: Dimensions of game experience. Adapted from Poels et al. [51].
Dimension In-game experiences Post-game experiences
Enjoyment Fun, amusement, pleasure, Energised, satisfaction, relaxation
relaxation
Flow Concentration, absorption, Jetlag, lost track of time,
detachment
alienation
Imaginative immersiothy,
Absorbed in the story, empa-
Returning to the real world
identification
Sensory immersion Presence Returning to the real world
Suspence
Challenge, tension, pressure,
hope, anxiety, thrill
Release, relief, exhausted, euphoria
Competence Pride, euphoria, accomplishment
Pride, euphoria, accomplishment,
satisfaction
Negative affect Frustration, disappointment, Regret, guilt, disappointment,
irritation, anger
anger, revenge
Control Autonomy, power, freedom Power, status
Social presence Enjoyment with others, being
connected with others, empathy,
cooperation
Accomplishment in a team,
bonding

4.8. Methods for the evaluation of video games 39
product being evaluated. Usability testing should be performed with users from the
intended target group for the system. If the system is to be used with both novice and
experts, it is important to include both groups [52]. It can be hard to select the number
of participants in a test, too few may not catch all issues and too many would waste
resources. The recommended number of users in a test varies, but generally it is better
to perform several tests in an iterative way than to test a large group once [44].
During usability testing a moderator is sitting beside a user and guides the interaction.
It is important that the observer influences the user as little as possible. The moderator
may also take notes during the session but this can also be handled by a second observer.
The session is also commonly recorded for later analysis. Recording can typically be
done with video, audio and key logging [52].
Often it is interesting to know why a user selected a specific menu or pressed a button.
Just watching users when they interact does not answer these sorts of questions. Therefore
users can be encouraged to think out loud when they use the system. Thinking out
loud while performing a task can feel quite unnatural, so often the moderator need to
encourage the users to keep talking [52].
The disadvantage with thinking out loud is that it could change the behaviour of the
user. When performing usability testing on games thinking out loud while playing can
also be too intrusive to the overall experience and disturb immersion and flow. One
approach, mostly used when testing with children, is to let two people play together.
When playing together discussing solutions to problems comes more naturally and less
interventions from a moderator is needed. Another approach is to use retrospective
think aloud, where users directly after the session watch recordings of their interaction
and verbalizes the thoughts they had. One disadvantage with retrospective think aloud
is that the users are given more time to think through their answers and may say what
they think the observer wants to hear [26].
The RITE (Rapid Iterative Testing and Evaluation) method is developed and used by
Microsoft Games Studios [39]. It is executed like usability testing, but changes are made
as soon as issues are identified, sometimes after just testing one participant. In this way
evaluators and designers can get immediate feedback if the change has solved the issue.
The method requires some time and resources for design and implementation between
sessions. It also requires enough users to perform a usability test at the end when no
new changes will be made. This to ensure that all changes has indeed fixed the issues
and not introduced new.
4.8.2 Playtesting
Playtesting [22] is another method that resembles usability testing, but it is less formal
and more focused on finding playability issues rather than usability issues. Playtesting
can start as soon as there is a working prototype of the game. At that time playtesting
can be performed with friends and colleges. They can provide fresh insight into the
game early on, but it is important to involve end users eventually. The end users should
not have any personal ties with the game to ensure their objectivity.
A playtest session can be performed at a home or an office, with one player or a group.
There are no predefined tasks that should be performed; the players are just asked to
play as they would do at home. They are also encouraged to talk out loud while they are

40 Chapter 4. Models & methods for evaluating games
playing and comment on their experience. A moderator observes their play and takes
notes, but should try not to influence their play. To find areas where players are stuck
or have problems as little help as possible should be given.
After the session the players are interviewed about their experience. Other methods
that can be used are feedback forms or open ended discussions.
4.8.3 Consumer Playtest
The Consumer Playtest (CP) [14] is a quantitative method which purpose is to identify
gameplay issues with a game. The focus is to gather players’ attitudes towards different
aspects of a game. CP is performed with 25-35 participants in a lab. The first step
is to answer a questionnaire that is designed to ensure that they belong to the target
group of the game. Step two is to let them play the game for a period of time, they
are instructed to play it as they would do at home and are also given all material that
they would have if they bought it. In step three players answers a questionnaire about
their experience. The questions can concern aspects such as perceived graphics, sound,
controls, and overall fun. Some questions are game specific, such as for example the
puzzle elements in a puzzle game.
With a small sample of users in evaluation it is hard to generalise their opinions and
experiences to the whole target group. The data gathered there is only representative
for the users in the evaluation. In CP the sample of players is large enough to enable
statistical analysis on the data gathered. This allows for the comparison between different
CP sessions. Different games and different version of the same game can thus
be compared statistically. This encourages iteration when designers can see how the
changes affect players’ opinions and experience of a game.
4.8.4 Heuristic evaluation
Heuristic evaluation is one of the discount methods described by Nielsen [43]. When
using discount methods evaluators sacrifice some degree of certainty and statistical significance
in favor of a low cost. The argument for using discount methods is that some
usability evaluation is better than none [43]. People do not have to be usability experts
to do a heuristic evaluation; novices can also identify some usability issues. It however
requires some expertise to know how to apply the heuristics so experienced evaluators
usually finds more issues than novices.
In heuristic evaluation one or several experts review the system with the help of the
heuristics. Every occurrence where the system violates the heuristics is noted down and
graded. Usually the expert also gives an example of a solution to the problem. If there
are several experts it is important that the evaluation is performed separately. This is
to ensure that as many problems as possible are identified. After evaluation the experts
meet to discuss the problems they found before they write a report for the designers
[43].
Games can also benefit from heuristic evaluation. Usability heuristics has been shown
to provide new and useful data in game development [34]. But the differences between

4.8. Methods for the evaluation of video games 41
games and productivity software have lead to several new sets of heuristics being developed.
These new heuristics have been tailored to accommodate the more explorative
nature of games. Some of the set of heuristics is shown in table 4.3 with a description
of their scope of use.
Table 4.3: Table of set of heuristics.
Heuristic
Federoff’s heuristics and usability
guidelines [20]
Heuristic Evaluation for Playability
(HEP) by Desurvire, Caplan &
Toth [15]
Playability heuristics for mobile
games. By Korhonen & Koivisto
[30, 31]
Usability heuristics by Pinelle,
Wong & Stach [50]
Description
Divided into Clanton’s three areas; Game interface,
mechanics and game play. Generally more
related to finding fun problems than usability
problems.
Categorized in the four areas game play, game
story, mechanics and usability.
For evaluating mobile games. Consists of three
modules: game usability, mobility and gameplay.
A fourth module has later been added for
mobile multi-player games.
Focused on finding usability issues in several
major game genres.
None of the set of heuristics described in the list claims to be a complete set of heuristics
that fits every type or aspect of a game. Therefore it can be an alternative to combine
heuristics from several sets when evaluating a specific game. If there is an area where
no heuristic can be found that describe a specific problem, new ones can be added.
Heuristics that are not relevant for the game can also be removed, but it is important
that they are removed for the right reason, not in an attempt to hide a usability problem
[26]
Heuristic evaluation can be used early in game design. There is no need to have a
working prototype of the game as there is in usability testing. This is an advantage
because it can be too late or costly to do any major changes in a game when it is
stable enough to be tested with players. Implementing changes early is cheaper than
implementing them late [26, page 83]. But heuristic evaluation should not be seen as a
substitute for testing with users. Testing with users can reveal problems that heuristic
evaluation completely misses [26, page 84]. Testing with users is also better at finding
problems related to challenge, boredom, pace and terminology [15]
4.8.5 Physiological measurements
The methods described above are good for finding usability and playability issues in a
game, but many of them do not say much about the experience of playing. Interviews
and questionnaires can identify some attitudes and experiences towards a game, but
they take place after the gaming experience. Asking a player about their experience
during playtesting interrupts the player and can alter the experience. One solution is

42 Chapter 4. Models & methods for evaluating games
to directly measure physical reactions to physiological states. These reactions can for
example be a change of heart rate, sweat, and breathing and are relatively easy to
measure. Interpreting the collected data can however be hard and it requires training
to analyze it correctly [26].

Chapter 5
Pre-study
This chapter presents the initial work of the project. The pre-study was aimed at
gathering ideas for the game. It begins with the initial idea generation and then moves
on to the work with questionnaires, brainstorms and focus groups, all of which involved
the people from the target audience.
5.1 Initial idea generation
Initially the ideas about the game came from us, the two designers. There was no real
method for the idea generation, rather just a series of discussions regarding what kind
of game we wanted to create. Throughout the discussions the focus was mostly on what
sort of features and aspects that should be included. It was also important to avoid
going into too much detail as the goal was to compose an overarching structure and
concept of the game.
5.2 Result of the idea generation
The initial idea generation resulted in a basic idea of what the game should consist of.
Perhaps the most important aspect was that the game should allow the player to own
land that could be placed on a map. Army movement was another important part. The
armies should not move abstractly only to appear in cities or other critical positions,
but instead be present in the world and be able to move over the map. Along with these
basic principles it was decided that the actual gameplay should not be focused solely
on warfare. Suggestions for what could be included along with warfare were trade and
diplomacy. It was also decided that the world should be tile-based.
5.3 Questionnaire
In order to gather information about interesting aspects of similar games a questionnaire
was used. The focus was more on getting ideas for the game than on getting a true image
43

44 Chapter 5. Pre-study
of the general consensus. The questionnaire was comprised of a couple of open questions
aimed at capturing interesting aspects of online and strategy games. Each question in
the questionnaire was divided into two parts, one part regarding online games and one
part regarding strategy games (i.e. the participants answered each question two times,
one time for strategy games and one time for online games). Approximately twenty
questionnaires were distributed. The questionnaire can be found in Appendix B.
5.4 Result of the questionnaire
Unfortunately the questionnaires did not yield a lot of information. There can be many
reasons for this, but poor questionnaire design, too few participants and lack of time to
find members of the target audience are some of the reasons. Most significant though
was that the questionnaire as such might not be an ideal form to gather the desired
information. Interviews might have been a better approach, but there was simply not
enough time for this.
What the questionnaire did show was that the developing of skills and characters was
one of the main reasons why people played online games (online roleplaying games in
particular). The need for thinking things through and using strategy to win was (not
surprisingly) mentioned as an important part of strategy games.
5.5 Brainstorming
Two brainstorming sessions were conducted. The method used was a modified version
of brainwriting. The main goal was to find what the target audience would like to see
in the game in terms of looks, features and gameplay. The two groups consisted of four
people each.
First the participants were given an introduction (see Appendix C) to the task. They
were not however given any details on the game but rather just that the game should be
a “multiuser strategy game in a persistent world”. The basic components of the game
were also listed for all to see. The following items were on the list:
– Strategic game
– Online
– Persistent world
– Several players
– Players who are logged out are still present
After the introduction the participants were given approximately 5 minutes in which to
generate ideas. This was done by describing (by writing, sketching etc.) the ideas on
post-it notes. When the idea generation seemed to slow down (about halfway through)
the participants were presented with a list of formulations of questions that could be
used as inspiration. The questions were listed as follows:

5.6. Result of the brainstorming 45
– What should the game look like?
– What should a player be able to do?
– What is the goal of the game?
– Should there be a way to win/lose?
– How should you win/lose?
– How do you play?
– How many players should there be?
– How do you communicate with other players?
– How much do you communicate with other players?
– From what perspective do you see the game (are you a god, king, chief etc.)?
Following the idea generation all the ideas were presented, put up on the whiteboard and
further explained if necessary. The ideas were grouped so that similar ideas were put
close to each other. Any additional information about the ideas was written alongside
the notes on the whiteboard.
In one of the sessions an additional idea generation phase was then conducted to develop
the ideas further. This time the participants got approximately three minutes to come
up with ideas and then the procedure of putting the post-its up on the whiteboard was
repeated. In the other session this phase was skipped due to lack of time.
In the end the questions listed on the whiteboard that had not been addressed previously
where discussed along with the following additional topics:
– For how long should you play the game each day?
– What would you be willing to pay in order to play the game?
– How many players should play in the same “world”?
– For how long should the game last?
– What should happen if a player is absent?
5.6 Result of the brainstorming
The brainstorming sessions generated a vast amount of ideas. All the gathered information
from the brainstorming sessions can be found in Appendix D and E. A lot of work
then went into sorting them and trying to extract what was feasible and not. The most
fundamental principles that was elicited from the sessions were:
– Choices should be possible to change (at a certain cost). It should always be
possible to “change direction”.

46 Chapter 5. Pre-study
– The game should allow for different playing styles. The players should control how
they play (evil, good, focus on battles, trade etc.).
– Players should not be helpless while they are logged off (a player should not return
to see that she has lost too much).
– Players should not be able to completely die (or lose).
– It should not be possible to harass weaker players.
– It should not be possible to be the best (or to do everything) in each area of the
game (i.e. a player should only be able to be quite good in many areas or very
good in a few areas).
These principles were used as design guidelines throughout the rest of the project.
Some of the things that came up during the brainstorming sessions were the concept of
races (or cultures), family, family members and councils. The idea with races is that
there should be a variety of races that the players can choose to have in their land.
The races should have different statistics and thus be good at different things. Though
there was no real mention of which races that should be included the idea seemed to be
rooted in classical fantasy. This should provide some insight into what kind of differences
there could be between the races. A classical example would be strong but slow dwarfs,
intellectual and magically inclined elves and a sort of jack-of-all-trades human.
Family and family members were mentioned as a set of heroes available to the player.
It should be possible for the player to improve the family members, giving them a
“roleplaying” feeling (by for example distributing experience in certain areas that the
player wants the family member to become better in). Another idea related to the
family members was that they should determine the score of the player. For example
if a family member conquers a lot of land the player would then receive points. Such
deeds would give the family member prestige which would contribute to the player’s
score. Prestige could be used to keep the highscores in constant change since the family
members should only have a certain lifespan. So when a family member dies, the prestige
and score disappears with him/her.
Councils were basically brought up as an idea for limiting players’ ability to harass
weaker players. The council should be able to step in and provide a logical reason for
why the stronger player could not attack or continue to attack the weaker player. It was
also mentioned as a forum for the players to discuss and make political decisions in the
world as well as contributing with several different ways for the administrators to add
more content to the game. The council could for example be a way of giving players
assignments and quests, set up bounties on evil players and informing players of events
going on in the world.
5.7 Focus groups
To further elaborate on the results from the brainstorming sessions two focus groups
were put together. One group consisted of only two people due to unforeseen events.

5.8. Result of the focus groups 47
Despite of this some interesting data could still be gathered. The other group consisted
of six people.
The participants were first presented with a short version of the concept for the game at
this stage; see Appendix F. Then questions regarding different aspects of the game were
presented. The group discussed each question before the next question was presented
and in turn discussed. The questions regarded the topics presented below (examples of
questions for each topic are shown in parenthesis). For a complete list of the questions
see Appendix G.
– The scale of the game (how long battles should take, how often players could be
expected to log in).
– The world (if it should be a fantasy world or sci-fi etc.).
– Races and culture (how many and what the differences should be).
– Marriage and families (how should it work, who should be included in the family).
– Alliances (how they should be handled, what types there should be).
– Council (if it should be included, what it should do, how it should be done).
– Events (if they are important).
– Aspects regarding the mechanics of the game (should all options be visible even if
they are not currently possible).
– Highscore (what and who should be visible in the highscores).
– Resources (how should it work, in particular, how should food work).
– Conquering (how should it work when conquering neutral land or the land belonging
to enemies).
5.8 Result of the focus groups
The focus group sessions resulted in a lot new ideas. A lot of the ideas from the
brainstorming sessions were also modified and improved. Some of the ideas for each of
the different aspects of the game are presented below (though there is no regard to the
importance or significance of the ideas):
Scale:
– It is reasonable to expect players to log in once a day.
– A player should be able to play for at least half an hour each day.
– The possibility for a family member dying increases each year (in-game).
– More time should be required for large battles to end (i.e. a battle with a lot of
units in it would take a longer time to finish than a battle between just a few
units).

48 Chapter 5. Pre-study
– Half a year in game time should be approximately one day in real time.
– There should be a minimum to how long a family member lives.
– It should require less time for armies to move around in areas that the player
controls.
Game world:
– It should be a fantasy world
– There should be different races rather than cultures in the game (since it is more
fun with a more distinct difference in their appearance).
– There should be more than three different races, at least five.
– There should be race specific army units.
– The player should be able to choose a race for the family.
Marriage and family members: No real consensus could be found in how marriage
between different families should be handled, but some of the ideas were:
– There should be a sort of trade for marriages (i.e. a player can list a family member
as eligible for marriage and require a certain amount of resources or an alliance to
marry the family member off).
– There should be a possibility to marry automatically generated characters to ensure
that a player does not end up without heirs for her family.
– There should be a bonus if marrying other players’ family members.
Alliances:
– It should be possible to break alliances.
– A player who breaks an alliance should be punished in some way (for example by
losing prestige).
– There should be a general alliance where the players set the rules themselves.
– There should be alliances limited in time (for example a non-aggression pact that
lasts for a couple of in-game years).
Council and events:
– The council could work as a tutorial.
– The concept of a council seems awkward.
– Quests and events are “cool”, this should be included.
Game mechanics:

5.8. Result of the focus groups 49
– The family members should not become less powerful when losing battles.
– Not having a family member in a city should result in corruption and might lead
to anarchy.
– There should be some sort of blocking so that players cannot repeatedly attack a
city.
– Large battles or other player initiated events should result in “holy places” which
in turn would give a lot of prestige to the player owning the place.
– Experience for units or armies should be included.
– Armies and units should become stronger if the player invests more time and/or
resources in their training.
– Some way of balancing the research so that new players can “catch up”.
– To conquer a city should take a significant amount of time.
– Trade could be handled without a currency (i.e. trading a resource for another
resource).
– Alliances should result in less loss when trading.
– The possibility to raid trade routs should be included.
– Unavailable alternatives should not be visible (at least not all).
– Resources that cannot be used yet are not visible.
– Different highscore lists. One for the overall score and several for the different
prestige categories.
Resources:
– The surroundings should affect the limit to the population for cities.
– The surroundings should affect the food cost per population for cities.
– To be able to gather resources the player should need to build a resource station
and connect it to a city via a road.
Conquering:
– Cities have an area within which it is possible to own and use land.
– If the “city area” expands all neutral areas are automatically conquered.
– Areas owned by other players are conquered when an army enters the area (if there
are no other armies there).
– Some things, such as walls, should be possible to build on neutral areas.

50 Chapter 5. Pre-study

Chapter 6
Result of the pre-study
Since the activities in the pre-study generated a vast amount of ideas, quite a lot of
work went into categorizing, sorting and grading the ideas. A complete and commented
compilation of ideas are found in Appendix H. When all ideas had been graded a working
design document based on these ideas was put together. This document contains the
concept of the game and details about features etc. as it was after the pre-study. The
document can be found in Appendix A.
6.1 Overview of the working design document
The working design document states the following items as the most fundamental parts
that the players can interact with (the entire document can be found in Appendix A:
– Cities
– Resources
– Family and family members
– Armies
– Research
– Trade
– Diplomacy
These items along with battles will be explained briefly in the following sub-sections.
51

52 Chapter 6. Result of the pre-study
6.1.1 Cities
The primary purpose of a city is to provide the player with manpower. Manpower can
then be used to create armies, gather resources and conduct research. Buildings can
be constructed within the cities, and these buildings give a bonus to the city. The
bonuses can affect different areas, such as making research more efficient or increasing
the attraction of the city (which results in more manpower).
6.1.2 Resources
Resources are the basis for all development. By using resources players can build buildings,
train armies, etc. There are several different resources, some of which are very
common and can be found all over the world while some are rarer and can only be found
in certain areas. To be able to gather the resources, players have to build a building on
the site of the resource and assign manpower to the building.
6.1.3 Family and family members
Family and family members work as a restraint on the growth of the player’s empire.
A player needs to have a “free” family member to be able to build or conquer a new
city. Since there is a limit to how many family members a player can have, there is also
a limit to the number of cities the player can have. Each family member has prestige.
The collective prestige for the entire family along with some general prestige (based on
the player’s wealth, scientific achievements etc.) is what determines the players score.
In this way the highscore lists will always “be in motion” since family members have a
limited lifetime (and when a family member dies, the score disappears with him/her).
Each family member can also be developed to become better in different areas. This is
done by giving experience to the family members over time, this experience can then be
used to develop certain skills. Family members can also gain experience if the accomplish
something significant (such as being a part of discovering a new technology, winning a
great battle, raising the population of a city and so on).
6.1.4 Armies
Armies are quite self-explanatory as they simply are the means which a player uses to
conduct warfare. They can be used to defend cities, attack other armies and plunder or
taking over cities or land. Each army consists of a number of units which in turn are
“built” (or trained) in cities. This costs a certain amount of resources and manpower
depending on the type of unit.
6.1.5 Research
By assigning manpower to research (this is done in cities) the player can improve his/her
empire in different areas. There are several different areas in which research is possible.
Each area can be seen as a stem (with branches) in a technology tree. To assure that

6.2. Examples of dropped ideas 53
new players do not get left too far behind, the time required to discover a technology in
a stem depends on how many players that have already discovered it. The time required
thus decreases with each player who has discovered the technology.
6.1.6 Trade
To get access to all resources the player will have to trade. The trade works by setting
up deals specifying what to buy and sell (for example [buy 1000 wood for 100 gold]). It
is of course also possible to accept deals that other players have set up. There is however
a loss for each trade. The loss increases with the distance between players’ trade posts
(which can be built in cities). It is possible to reduce loss through research and by using
family members’ abilities.
6.1.7 Diplomacy
Diplomacy is an integral part of the game and there are essentially three different states
between players: neutral, alliance and war. There is always a loss in prestige when
declaring war (with a greater loss if the player who declares war is much stronger than
the player upon whom war is declared), but there is prestige to gain when conquering
more land etc. Alliances can be of three different types: non-aggression pacts, military
alliances and “guilds”. If two players have agreed to a non-aggression pact it means that
a player that attacks the other player suffers a significant prestige loss. If two players
are in a military alliance and one player gets attacked by a third player it means that
both players in the alliance will become in a state of war (without any loss of prestige)
towards the attacking player (as opposed to only the attacked player becoming in a
state of war towards the attacker if there is no alliance in play). A Guild is a more
loosely defined alliance where the players themselves can define the rules for the alliance
(though the rules for non-aggression pacts and military alliances may still be used).
6.1.8 Battles
Another big part of the game is battles. The battles are played out between AI and it
is not possible for players to directly influence the battles. The player can however set
“battle orders” for the army, specifying how the army should behave in battle as well
as how the initial formation should be. The AI is then in charge of trying to “make the
best of the situation” given the initial orders set by the player and the size, composition
and tactics of the opposing force.
6.2 Examples of dropped ideas
This section presents examples of ideas that came up during the pre-study but have
been dropped for varying reasons (all ideas generated in the pre-study can be found in
Appendix H). Each idea is commented on the positive and/or negative aspects of it.

54 Chapter 6. Result of the pre-study
– The player should be able to design her own troops by for example giving them
different armours and weapons. This affects the properties for the unit. Could
be fun, but will become very complex. Requires that it is possible to build/buy the
different weapons and armours.
– A player can hand over responsibilities for her cities, soldiers etc. to another
player. Good if a player is going to be absent for a long time. It might however
be difficult to implement. There is also an issue to determine what and how much
that should be handled by the other player.
– Family members can revolt against the rest of the family. Players will most likely
be frustrated if family members cannot be controlled directly (and of course losing
a family member would be a very hard blow).
– Family members can move around and kill monsters etc. This can result in the
player getting items that can help the family/country/family member. When the
family member moves around the map he/she can move “within” a tile (a tile could
for example be divided into nine small tiles). Would become very disconnected from
the rest of the game. Items could be acquired in other ways. Though achievements
for the family members that can be presented for other players might be interesting.
– A council could be present for each race. The council decides if a player should be
punished for harassing weaker players etc. This can be done by for example having
the council announce that “Player X has been evil, every player should send two
soldiers to attack player X”. The council can present questions that players can
vote on (such as crusades or higher taxes). The council can, among other things,
also provide military help or resources to weaker players.
• Positive aspects: Help to weak players, natural way for admins to affect the
world, provides a forum for players to interact in, could be a natural way to
include a tutorial for new players.
• Negative aspects: Might feel unnatural, results in odd restrictions such as the
players having to be included in a council against their wish.
– Along with the other alliance types there could also be “realms” where a player
is the leader and has some control over the other players. This player could for
example demand taxes or control over a certain number of soldiers. Could be
interesting, but would have to contribute with something unique that is not present
in ordinary alliances. Restrictive and not necessary.
– To be able to conduct trade, the player must have some sort of unit travelling back
and forth to the place to trade with. Could be fun and realistic, but would result
in the trade being slow.
– Different races can have different research trees. This could for example be “evolution”
for one race and “technology” for one race. Might be difficult to balance
and does not add all that much to the game. Unique branches on the research tree
might add depth for the different races.
– Messages sent to players who are a long way away should take time to arrive. Communication
should not take time, especially since communication can be handled
outside of the game without any time loss.

6.2. Examples of dropped ideas 55
– The highscore is calculated from the beginning of the game (so that a player’s
score always increases). Can result in the players who started playing first always
being on top.

56 Chapter 6. Result of the pre-study

Chapter 7
Implementation of the
functional prototype
This chapter deals with the functional prototype. It explains what was included in
the prototype, describes the environment in which the prototype was implemented and
finally gives an overview over the system architecture of the functional prototype. No
detailed information about the system architecture is included since it is only a prototype
and thus should only be used for testing and then be discarded.
7.1 Scope of the prototype
The functional prototype was aimed to test the concept of the game with focus on the
gameplay rather than graphics, balancing issues, interface design etc. Because of this
developing graphics etc. was not prioritized and all such features are very crude and
simple in the prototype.
Due to time constraints not all features from the working design document (see Appendix
A) were included in the prototype. Some features were changed and some were
removed completely. Below is a list of the most important changes:
– Players are given three family members. The family members do not die or reproduce.
It is also not possible to marry family members or create “family trees”.
– Family members can focus on warfare, building or research. Focusing on warfare
gives higher morale to the units in the army, focusing on building reduces the
building time and focusing on research increases the research efficiency.
– Family members do not have prestige or reputation.
– It is not possible to capture family members.
– No events.
– Buildings do not require any upkeep.
57

58 Chapter 7. Implementation of the functional prototype
– Simplified population and attraction for cities. No simulation of migration or
population growth.
– There are only three races; humans, elves and trolls.
– Trade is simplified with a global market.
– There are no forms of alliances.
– The amount of time it takes to complete a research is not dependent on the number
of players that already know that research.
– Armies do not have any behaviour. This means that a player can not choose if
the army should attack other armies or if it should guard a place. Armies stand
still if they are not explicitly moved by a player.
– Cities can only be plundered or besieged.
– Units have three different stats; health, damage and morale. Damage determines
the maximum amount of damage a unit can deal. A unit that deals damage to
another unit reduces the health and morale of that unit. If the life reaches zero,
the unit dies. Morale determines the chances that the unit will flee, lower morale
means higher chance.
– Battles are simulated in a turn-based manner and without regard to the position
or movement of troops. Instead the type of the unit determines the behaviour.
Archers can attack once each round, cavalry once each third round and infantry
once every round after the fourth round. To prevent the advantage of one side
attacking first, all sides attack simultaneously. This means that the damage all
units make in each army is calculated before any damage is dealt. If a unit receives
any damage there is a chance that it flees. When enough units have fled the entire
army becomes fleeing and is taken out of battle.
It was decided not to introduce any currency in the prototype. A currency makes
trading easier when it is possible to trade any sort of resource against in-game currency.
To only allow recourses to be traded can make trading more interesting, but it can
get too complicated. Therefore it was decided not to introduce any currency in the
prototype in order to evaluate this approach.
Each city has a radius that determines the land area a player can own. The radius can
be expanded by building certain buildings in the city. There are two alternatives to
what will happen with neutral land within a city’s radius; it automatically becomes the
player’s land or the player has to take over the land with an army. For the prototype
the first alternative was chosen.
7.2 Development environment
The prototype was developed using the programming language Java and Eclipse was used
as developing environment. Flash was also considered as an alternative. It was however
not selected because the developers were more comfortable with Java. PostgreSQL was
used to store data about players and the game world.

7.3. System architecture 59
7.3 System architecture
The prototype consists of two parts; a server and a client. The server stores all data
about the game world and also holds all rules and behaviour of the world. The client
presents a graphical view for the player. All requests that a player makes via a client
go to the server where they are processed, see figure 7.1.
Figure 7.1: Client request and server response.
One of the requirements established for the server was that there could not be any
continuously updating loop. Normally in a game there is a loop that handles all input
from players and updates the game world [38]. This loop exists as long as the game
exists and if there are a lot of updates it can demand much processing power. In the
prototype the loop should for example be responsible for updating all players’ resources.
Because the server was to be run on a public server at Umeå University there was a
risk that the updating loop would slow down all other work on the server. Therefore
another approach was selected; resource reserves were given a time stamp containing
the last time of update. It was only when a player needed to use a resource that the
server would calculate the amount in the resource reserves.
The game server consists of several modules. Each module runs in an individual thread.
An illustration can be seen in Figure 7.2 where each module is shown as a box and the
database as a cylinder. The arrows represent the communication between modules.
Figure 7.2: Conceptual model of the game server.
The message system handles all communication between modules. All communication is
performed with messages labelled with an address. The message system has an in-queue
and several out-queues. Every out-queue represents a unique address. Every module

60 Chapter 7. Implementation of the functional prototype
interested in a specific type of message can register for its address. The reason for this
is that not all modules may be interested in every type of message. The battle simulator
is for example not interested in commands from the user. It is only when the logic has
determined that there should be a battle that it sends a message to the battle simulator.
The network module handles all communication with clients. It receives commands from
players and sends updates to players. When a command is received it is transported to
the logic for processing. Usually the command results in one or several changes in the
game world that needs to be communicated to the player. The logic sends the updates
to the network module which in turn sends them to the players they concern.
The battle simulator simulates ongoing battles. It receives a notification from the logic
that a battle has begun. It then simulates one round in the battle and sends the result
to the logic. If the battle is not over the battle simulator sleeps for a specified amount
of time before it simulates the next round.
The order system keeps track of all orders in the game. An order is something that
requires a certain amount of time to complete. It can for example be that an army should
move one step, a building should be constructed or a technology should be discovered.
The reason it is called an order is to differentiate it from the events described in the
working design document. All orders have a timestamp telling when the order should
be executed. The orders are sorted in a queue so that orders that should happen first
are first in the queue. When the order system receives an order it places it in the queue,
then it looks at the first order in the queue. If the order is to be executed the order
system pops the order and sends it to the logic. If not it sleeps until it is time to execute
the order.
The logic module is the biggest part of the server. It contains all the rules of the game
and it is there all information is processed. When a player issues a command the logic
is responsible for investigating if the command is valid. The logic needs all information
about the game state to be able to do that. Therefore the logic has access to the database
where such information is stored.
The client is constructed in a similar manner as the server. It has a message system and
a network module that handles communication with the server. The difference is that
the client has no real logic, only a simplified module that stores all data, for example a
players cities and armies. The client has no battle simulator or an order system since
all those calculations are performed on the server. One module that is only found in the
client is the graphics module. It is responsible for presenting the game on the screen for
the player. See Figure 7.3 for an illustration of the client.

7.3. System architecture 61
Figure 7.3: Conceptual model of the game client.

62 Chapter 7. Implementation of the functional prototype

Chapter 8
Result of the implementation
This chapter will present an overview of the functional prototype and the features included.
It will also mention errors, bugs and limitations of the prototype.
8.1 Overview of the prototype
This section presents an overview of the prototype. Most of the features available to
interact with are explained and illustrated with screenshots in the following sub-sections.
8.1.1 The game interface
Figure 8.1 shows how the game could look like when a new account has just been
created. The map is shown in the centre of the game area. The left panel displays
the current game time, the player’s family members as well as different alternatives for
interacting with other players. The top panel shows the players resources, manpower
and current research. The right panel holds the tile info area that shows information
about the current selected tile. A question mark in figure 8.1 is displayed because no
tile is currently selected. Below the tile info area is the army info area. If a tile would
have been selected it would have displayed a list of all armies located on the tile.
8.1.2 Family members
A player has three family members in the prototype. By double clicking on the portrait of
a family member in the left panel a new window is displayed that shows more information
about the family member, see figure 8.2.
All family members must be connected to a city, though it is possible to have several
members in the same city. It is not possible to move a member from a city if it is the
only member in that city. At the beginning of the game the player has only one city so
it is not possible to move any family member.
63

64 Chapter 8. Result of the implementation
Figure 8.1: Overview of the game interface.
Figure 8.2: Family member window.

8.1. Overview of the prototype 65
A family member gains experience continuously that the player can distribute to any of
the three focus areas. When the sum of the distributable experience and the experience
in an area exceeds the required experience to level up in that area, the button “Raise
a level” becomes enabled. If a player presses that button the family member gains a
level in that area. The experience in an area is automatically increased if a family
member contributes to an achievement for the particular focus area. A family member
who focuses on building thus gets experience in that focus area when a building is
completed.
8.1.3 Log
When a player is offline things can still occur in the game, another player might for
example declare war. The log button in the left panel (as seen in figure 8.1) brings up
a window with all such events that has occurred since the player last was online.
8.1.4 Trade
Trading is done on a global market in the prototype. This means that the distance
between players does not matter, a player can trade with all other players in the game
no matter the location on the map. The trade window (figure 8.3) can be accessed by
pressing the “Trade” button (as seen in the left panel in figure 8.1).
Figure 8.3: In the trade window a player can set up trade deals and view other players’
trade deals.
To the left is the player’s own trade deals. By pressing the “New” button a player
can create a new trade deal. A player can only trade resources that he/she has in the
reserves. It is not possible to sell more of a resource than the player currently has
available. The “Cancel” button next to a trade deal cancels it.
All other players’ trade deals are displayed to the right. A trade deal can only be
accepted if a player has enough of the resource that the other player wants to by.

66 Chapter 8. Result of the implementation
8.1.5 Messaging
The prototype has a simple mail system. It is possible to send messages to all other
players in the game. The button “Compose mail” opens up the write-mail window (see
the left of figure 8.4). The recipient’s name can be selected from the list to the left. The
message can be written in the area to the right.
Figure 8.4: The left part shows the write-mail window and the right shows the inbox.
The Inbox can be accessed through the button labelled “Inbox (*)” (as seen in the left
panel in figure 8.1). The digit in the parenthesis on the button displays the number of
messages in the inbox. The inbox window is shown to the right of Figure 8.4. From there
it is possible to select a message from the list to the left. When a message is selected it is
possible to respond to the message. When pressing the “Respond” button the write-mail
window is displayed with the senders name marked as recipient. A selected message can
also be deleted, but it is not possible to retrieve deleted messages.
8.1.6 Resource reserves
The resource reserves (shown in figure 8.5) are displayed to the left in the top panel.
Each reserve has a picture of the resource it stores as well as the available amount, max
amount and gain. Hovering with the mouse cursor over a reserve displays the name of
the resource stored in that reserve. A player gains the ability to store more resources
by research and constructing buildings.
Figure 8.5: Resource reserves are displayed in the format: available / total (gain).
8.1.7 Manpower
With manpower a player can build armies, gather resources and conduct research. Manpower
(see figure 8.6) is displayed in the middle of the top panel. There are four digits
that represent the manpower of a certain race. They are displayed in the format: available
/ used / max (gain). The available manpower represents how much of a race that
is free to use and used manpower represents all that is currently working (either in
armies, resource stations or in cities doing research). A player gains more manpower
continuously at a certain rate shown in the parenthesis in figure 8.6.

8.1. Overview of the prototype 67
Figure 8.6: Manpower is displayed on the format available / used / max (gain).
8.1.8 Research
The current research and the date when the research is finished are displayed to the
right in the top panel (see figure 8.1). When a research is finished a player “owns” that
research. The button “Change research” displays the research window, see figure 8.7.
In the research window all undiscovered technologies are displayed. Some technologies
require other technologies, meaning that it is only possible to research it if a player
already owns the required technologies. An example of this is seen in figure 8.7 where
only axe can be selected. This is because all other technologies require technologies that
the player has not discovered.
Figure 8.7: The only possible alternative is at the moment the axe.
8.1.9 The map
The map is the players view into the game world, see figure 8.8. The black part is areas
that are unexplored. In the middle of the map a city and an army can be seen. The thin
green line marks the border of what the player owns. A player owns all the land within
that green line. The blue thin line marks the border to other players. It is possible to
scroll the map by using the arrow keys on the keyboard.
The map is composed of a grid of tiles. Each tile can be of a different terrain type. When
a tile is marked the tile info area shows information about the tile type, the resource
and the owner of that tile, see figure 8.9. A terrain type can have a default resource.
Wheat is the default resource for grass as shown in the upper part of figure 8.9. If a
terrain type contains a resource that is not its default; it is marked on the map by a
small icon as shown in the lower part of figure 8.9.
In the tile info area in figure 8.9 there is a button labelled “Go to build menu”. The
button is displayed if it is possible to build anything on the currently selected tile. When
it is pressed the build window is displayed. In the build window the player can build
roads, resource stations and cities. These alternatives are displayed in tabs in the build

68 Chapter 8. Result of the implementation
Figure 8.8: The view to the game world.
Figure 8.9: In the left upper part a tile of the terrain type grass is marked. The right
upper part shows the appearance of the tile info area when the tile is marked. There it
can be seen that the default resource of grass is wheat. In the lower left part the marked
tile has a small icon on it. This means that that tile has a different resource type than
the default. The tile info panel at the lower right shows that the resource is mana.

8.1. Overview of the prototype 69
window. The build road and build resource station alternatives are only displayed if the
player owns the tile that is marked. If the tile that is selected has no resource, the build
resource station alternative will not be visible.
Figure 8.10 shows the appearance of the build road tab in the build window. There
the player can see the build cost in resources and the time it takes to finish the road.
Different terrain can have different build cost and build time. If the player can not
afford to build the road, the “Build” button is disabled.
Figure 8.10: The build road tab in the build window displays the cost in resources and
time to construct a road on the currently selected tile.
Figure 8.11 shows the appearance of the build resource station tab in the build window.
As well as displaying the cost to build, the tab also displays the type of resource station
and the maximum number of manpower that can work there. If the player can not
afford to build the resource station, the “Build” button is disabled.
Figure 8.11: The build resource station tab in the build window displays the cost in
resources and time to construct a resource station. It here shows that it is a level one
farm that harvest wheat that can be constructed. The maximum amount of workers in
the farm is ten.
The build city tab (figure 8.12) is similar to the build road tab. The only addition is
that the player has to choose which family member that has to move to the new city.
During the time a road, resource station or city is being built an “under construction”
icon is displayed on the map. When the construction time is finished that icon disappears
to be replaced by the respective symbol for a road, resource station and city. See
figure 8.13.

70 Chapter 8. Result of the implementation
Figure 8.12: The build city tab shows the cost and building time of a city. The player
has to choose which family member to move to the city .If there is no available family
member no city can be built.
Figure 8.13: a) A road during and after construction. b) A resource station during and
after construction. The icon shows that the station gathers wheat. c) A city during and
after construction.

8.1. Overview of the prototype 71
8.1.10 Resource stations
When a tile with a resource station located on it is marked the tile info area also
displays information about the resource station. If the resource station is not connected
to a city there is a warning message displayed in the tile info area. The resource station
window can be accessed by pressing the “Go to station” button in the tile info area. See
figure 8.14.
Figure 8.14: A tile with a resource station is marked and the tile info area displays
information about the tile as well as the resource station. A road must connect a resource
station to a city; otherwise the resource station will not contribute with any resources.
It is possible to assign manpower to work in resource stations. This can be done in the
resource station window (figure 8.15). There is a limit to how much manpower that
can be assigned to a resource station. By upgrading the resource station it is possible
to increase the manpower limit as well as the efficiency of the station. Upgrading a
resource station costs resources and may require additional research.
Figure 8.15: In the resourse station window it is possible to assign manpower to the
resource station. It is also possible to upgrade it.
8.1.11 Cities
If a city is located on the currently selected tile a button labelled “Go to city” appears
in the tile info area. When it is pressed the city window is displayed. The city window
consists of the four tabs; “Info”, “Buildings”, “Research”, and “Units”.
The “Info” tab (figure 8.16) displays information about the city. It is also possible to
change the name of the city from this tab. A city can get bonuses both from family
members located in the city and buildings in it. The city info panel also displays

72 Chapter 8. Result of the implementation
Figure 8.16: In the “Info” panel it is possible to rename the city and view information
about it.
information about which family members that are located in the city, its population,
the effect it has on other cities and how other cities affect it.
In the “Buildings” tab it is possible to view all buildings in the city. They are listed
to the right in figure 8.17. To the left in the figure are all available buildings listed.
When a present or available building is selected information about it is displayed in the
middle. The current building queue is displayed at the top.
Figure 8.17: Glass reserve level one is selected. It stores 200 pieces of glass. The
cost in wood is displayed in red because the player does not have enough of it. The build
time is displayed without any modifications from family members. It requires the building
“PaperReserve” and the researches “Fire” and “Wheel”. The player has no paper reserve
and neither does he/she know the technology “wheel”. The building “ManaReserve” is
currently being built. The only building currently in the city is a Warehouse level three.
In the “Research” tab the player can assign manpower to work as scientists. Every city
has a maximum amount of researchers. The amount can be increased by building special
buildings in the city.
It is possible to train units in the “Units” tab. It is only possible to train one unit at a
time. When a unit has finished its training it becomes visible on the map as an army.
The different types of units available in the prototype are listed to the left in figure 8.18.

8.1. Overview of the prototype 73
When a unit is selected its information is displayed to the right. It is also possible to
choose the race of the unit in this area. The race affects the damage and life of a unit.
A unit costs both manpower and resources to train and it may require special types of
buildings or research.
Figure 8.18: No unit is currently being trained. The player lacks resources, buildings
and research to train the selected unit.
8.1.12 Armies
Selecting a tile on which armies are located results in a list of those armies being displayed
in the army info area in the right panel. The army list is located under the tile
info area. A player can select any particular army from that list by a single click, see
figure 8.19.
Figure 8.19: Two armies are located on the same tile. When the tile is marked they are
listed in the army info area that is located under the tile info area. The army info area
displays the owner of the army and the number of units in it. An army is selected by
clicking on it in the list.
By double clicking an army in the army list an army window is displayed. The army
window contains detailed information about the army and its units (see figure 8.20). The
behaviour of the army can also be set here. The two possible behaviours are plunder
or siege. Plunder means that the army should plunder a city it has attacked and siege
means that the army should capture it. Siege is only possible if there is a family member
in the army. Family members can join armies if their current focus is warfare.
Every unit has a reinforce cost that depends on how damaged the unit is. Units can join
other armies, but they can only join armies located on the same tile. Units can also be
disbanded, the manpower cost will then be returned to the player but not the resource

74 Chapter 8. Result of the implementation
cost. If all units in an army has joined other armies or been disbanded, the army will
disappear.
Figure 8.20: The army has no family member unit, so the army can not try to siege an
enemy city. It consists of only one infantry unit; human peasants.
A player can move an army by marking the army in the army list and then right click
on the tile the army should move to. The army then initiates a moving animation and
a green animated marker illustrates the end destination. The animated marker is only
visible when the moving army is selected (see figure 8.21).
Figure 8.21: The army is moving.
8.1.13 Warfare
A player can not attack another player without declaring war. To declare war the player
must mark a tile that the other player owns, see the top of figure 8.22. In the tile info
area a button then appears labelled “Declare war!”. If that button is pressed a dialog
window appears asking if the player really wants to declare war. If the player confirms
then the diplomatic state between the players is set to war. The colour of the enemy
border and soldiers then changes from blue to red. The declare war button is also
replaced with a button to offer peace, see the bottom of figure 8.22.
A player can only move soldiers into another players land if the two are in a state of
war. This means that it is only possible to pillage or siege other cities when in war.
Battles occur when two or more armies (owned by different players) occupy the same
tile. A battle can only end if there is just one player’s armies left on the tile. This means
that the other players’ armies have either fled, died or been commanded away from the
battle. A fleeing army can be recognized by its white flag and can not engage in battle
until it has been reinforced in its homeland. Fleeing armies that are attacked flees to
an adjacent tile.
It is possible to remove the state of war by offering peace. The button “Peace offers”
in the left panel (see figure 8.1) displays the diplomacy window where a player can offer

8.1. Overview of the prototype 75
Figure 8.22: A declaration of war.

76 Chapter 8. Result of the implementation
peace to the enemies. It is also possible to view and accept peace offers the enemies has
made. Peace is restored when one side has accepted the other sides offer.
8.2 Errors and limitations
Some features that would have been interesting to test were not included in the prototype
because of lack of time (more changes has been presented in section 7.1 Scope
of the prototype). Running cost for buildings is a feature that was not included and
this of course affects the gameplay. The lack of running costs could have far-reaching
consequences and have an impact on other elements of the game such as trade as well.
This resulted in the prototype being limited to testing an overall concept of the game
along with some features rather than the entire gameplay of the final game. Battles are
another feature that was very simplified and this might have resulted in the gameplay
being less attractive than desired.
Along with the mentioned limitations of the prototype there were also some bugs that
affected the gameplay. Some of the more significant ones are presented below:
– Units that end up “inside” another player’s area when the area expands are stuck.
The only way to get away is to start a war (if there is already a war there is no
problem) or to disband the unit. This was something that had not been considered
and of course has to be resolved before making the final version of the game.
– Archers for some reason seem to deal a lot more damage than other troops. This
results in battles being very unfair and might have deterred players from using
warfare. Even though the battles are very simplified it might have had an effect
on the way players played the game since there might have been to much focus on
building etc.
– When discovering a new technology research does not always change to a new
technology but instead starts over with the already discovered one. This might
have made some players stuck and unable to develop in a satisfying rate (affecting
their opinion of the game).
– In one case fleeing armies have been reported to become invisible. This might of
course affect the gameplay as manpower and armies seemingly disappear.
Along with these bugs there are several minor bugs. For example buildings that are
impossible to build and players being able to see units and/or tiles that should not be
seen. All these limitations have to be kept in mind when evaluating the prototype.

Chapter 9
Evaluation
This chapter describes the evaluation of the functional prototype and the working design
document. First it presents the heuristic evaluation and then it moves on to the focus
group evaluation of the prototype. All who played the functional prototype had access
to a forum where ideas, comments and questions could be posted. The things posted
on the forum were also considered during the evaluation.
9.1 Heuristic evaluation
The scope of the work was to create the gameplay and mechanics of a game, so the focus
of the evaluation was to find gameplay and playability issues. In heuristic evaluation,
three to five evaluators are recommended to find most usability problems [42]. It is
also not recommended that the designers perform the evaluation. This is because the
designers are too close to the game and it can be difficult to review one’s own design
[26, page 95]. The designers however had to take on the role as expert evaluators due
to lack of resources.
The material available for evaluation was the design document and the working prototype.
The simplifications and changes that were made in the prototype were not
evaluated since they were not to be seen as representative of the final version of the
game. The interface of the prototype was also disregarded because of the same reason.
The heuristics that were used in the evaluation were selected from several sources. The
sources can be found in table 4.3. Some of the heuristics were not applicable for the
evaluation and were removed. These were mostly usability and story heuristics. Other
heuristics that were removed related more to single player games or linear games with
multiple levels. All heuristics were labelled and divided into seven topics. The heuristic
“The game does not stagnate” can for example be found under the topic “Progress”.
See Appendix I for a complete list of the heuristics. The topics were:
– Feedback & control
– Goals
77

78 Chapter 9. Evaluation
– Challenges & skills
– Progress
– Balance & Strategies
– Setting & content
– Multiplayer issues
The evaluation was performed by having both evaluators going through the list of heuristics
separately and noting all issues found. To give structure to the work a template
was used when noting the issues. The topic and heuristic that the issue was related
to was noted in the template and the problem was graded on a four level scale; minor,
moderate, important or critical. There was also room for a description of the problem
and any potential solution. When the evaluation session was over the two evaluators
compared and discussed their findings.
9.2 Result of the heuristic evaluation
Several issues were found in the heuristic evaluation. One critical issue was that the
design document did not mention anything about a help or tutorial. The game is fairly
complex and it can be quite overwhelming to see all options presented at once, especially
for new players. An in-game tutorial is therefore a good alternative to introduce new
players to the game. There should also be some sort of help that players can refer to
throughout the game. A similar issue was that there was no “hook” for new players. If
players do not get hooked in the beginning of the game there is a big risk that they will
not continue to play.
Another group of issues was that the game punished mistakes and losses too hard. If a
player for example loses a battle he/she might also lose resources or even a city because
of that. It can then be hard to rise again because there are little resources left to
rebuild. To lose a city can also feel very frustrating when a player has spent a lot of
time developing it. To punish the player too hard can be very demoralizing.
Balancing the game so that new players can coexist with more experienced players is
another issue. In the beginning of the game new players are left defenceless against
stronger ones and it could be hard for them to progress if they get attacked constantly.
This is especially important because it violates the principle that it should not be possible
to harass weaker players.
The design of the game makes it impossible to play consecutive for a long time. Everything
in the world takes a different amount of time and because of that it may require
that players log in several times a day. Exploring is especially tedious because players
can not move soldiers into areas they do not know. An alternative approach to this
is to use “movement points”. Moving an army one step costs a particular amount of
movement points depending on the terrain. A player can move an army instantly as
many steps that the army can afford. The army then regains movement points slowly
over time. This makes it possible to log in for example once a day instead of once every
hour when exploring. Instant movement does however affect the realism of the game.

9.3. Focus group evaluation 79
Another alternative is to make it possible to send armies into unknown areas. The
problem is that the player does not know what type of terrain he/she sends the army
into.
One issue that was identified in the prototype was that a player can get “trapped” in
the game if other players have surrounded the player. In this case the player is not able
to explore the world or expand without the neighbours’ approval. A complete list of the
found issues can be found in Appendix J.
9.3 Focus group evaluation
Two focus group evaluations were conducted in order to evaluate the functional prototype.
The two groups consisted of two and four participants respectively. The participants
in the groups were mostly people who had also participated in the pre-study
brainstorms and focus groups. The participants had also played the prototype. The
setup of the focus groups was fairly simple and could be described as a semi-structured
group interview. A list of questions was compiled in advance and the evaluators then
tried to gather as much information about each question as possible. The questions can
be found in Appendix K. Because of the low number of participants in one of the focus
groups an additional one-on-one interview was also conducted. The interview was based
on the same questions as in the focus groups and was carried out in a similar fashion.
Since the focus of the prototype was on the gameplay of the game the evaluation and
the questions regarded topics such as:
– Economy
– The map and positions
– Family
– Cities
– Battles and armies
– Tempo
Along with these specific topics general questions about the prototype (such as “what
was the best thing about the game?”) were also asked.
9.4 Result of the focus group evaluation
This section presents a summary of the results of the focus groups. The complete
collection of comments from the two focus group sessions can be found in Appendix L
and Appendix M. The comments from the interview can be found in Appendix N.
Even though the interface of the functional prototype was not prioritized (as mentioned
before, it was mainly focused on testing the gameplay) there were some comments about
the flaws in the interface. A bad interface can of course have a negative effect on the

80 Chapter 9. Evaluation
experience of a game and it has to be considered. One example is comments about
difficulties and unclear aspects regarding how to play the game. An example of this
was a participant who had not discovered that family members could level up. This
could perhaps be solved by a better interface, but a lesson learned is that more and
better instructions will most likely have to be included, especially since the game is
fairly complex with quite a lot of features. One way to ease the players into the game
is to provide a tutorial, as mentioned in the results of the heuristic evaluation. Another
thing that was discovered, though not intended for testing, was that no thought had
really gone into how the armies would move when exploring the land. In the prototype
an army could not move into unexplored territory making it possible only to move to the
very edge of what was explored (which would result in a few more additional tiles being
explored). This was also discovered in the heuristic evaluation and is further discussed
in section 9.2. Even though there clearly were issues with the exploration it was still an
appreciated aspect of the game. There were however comments about developing this
aspect further, for example by adding random encounters or similar events. The map
was generally considered a good aspect of the game since it added another dimension
to it.
An aspect of the game that was intended for testing was the system for trade. The
participants in the focus groups agreed that trading without currency worked out well,
though there were some suggestions on how to make it even better. One of the suggestions
was that there could be an option to set up trade deals with alternative for
the payments (for example setting up a trade deal where a player sells 200 wood in
exchange for 50 stone, 50 gold or 75 gems). The amount of resources present in the
game (eighteen in the prototype) was also mentioned as a fun part of the game. That
the players did not have access to all resources in the beginning of the game (but had
to trade or conduct warfare to get to them) was also mentioned as a good aspect, there
were however some concerns of the effects this could have on the game balance. The
most important aspect to resolve these balancing issues is that each player has to have
access to the basic resources directly when they start to play the game, which was not
always the case in the prototype.
Both races and family members were mentioned as interesting parts of the game, but
both needs to be further developed. Several participants commented that there should
be more of a difference between the races. One thing that was mentioned as a way of
making races more diverse was that they could have different efficiencies when working
in different resource stations (for example trolls being better at mining coal and elves
being better at gathering mana). There was no single clear idea of how to make the
family members more interesting, but just making their impact on the game more significant
could be an approach. It is also possible to have them play a part in the random
encounters and events mentioned as a way of making exploration more interesting. Although
the dying of family members was not tested in the prototype there was a general
consensus that this should be included. This could of course both make family members
more interesting as well as be a frustrating part of the game and further testing might
be needed.
The influence between cities should have more of an effect on the game; there were even
mentions of making it possible to conquer cities through influence. Even if this might
be taking it too far (further testing would be good), it is quite obvious that the effect
influence had in the prototype was far too insignificant. A solution mentioned was to
only influence enemy cities negatively (instead of as in the prototype where influence

9.4. Result of the focus group evaluation 81
almost always had both negative and positive effects on different races).
The system of having delayed battles seemed to be received well by the participants and
the only comment (apart from the major bug with overpowered archers) was that there
should be more feedback for the players. This of course supports the ideas of the battle
system with battle reports described in the working design document (see Appendix A).
Some comments about the prototype regarded that the game should have an end instead
of running indefinitely. The possibility for players to create their own instances of the
game where they could play with their friends was also mentioned (and this would most
likely have to be games with a fixed time limit or winning conditions). Another comment
was that some way of keeping track of ones territory should be included. This could be
done with a mini-map or something similar.

82 Chapter 9. Evaluation

Chapter 10
Resulting design document
This section presents the resulting design document. This is the specification of the
game at this stage and even though there are some things left to resolve it gives a quite
detailed description of the gameplay.
10.1 Basic concepts
The game is an online strategy game played in a persistent world with many players. It
consists of a few basic parts that each player can control. These are:
– Cities
– Resources
– Family and family members
– Armies
– Research
– Trade
– Diplomacy
All of these parts are accessible through the games interface. How and what the player
controls for each part will be explained in further detail below.
It is not possible for players to be completely annihilated. Instead, if their last city is
taken, they get the option to move to another location. When doing so they retain their
technological advancements as well as some resources and even all manpower (though
some manpower has probably disappeared since it is likely that a large part of their
army has been wiped out).
83

84 Chapter 10. Resulting design document
10.2 The world
The world is tile based and each tile is of a certain terrain type. At least the following
terrain types should be included:
– Grass
– Hills
– Mountains
– Forest
– Water
– Desert
– Tundra
A terrain type can hold a default resource. The default resource for mountains is for
example stone. Any specific tile can have another more unique resource. If the tile is of
a terrain type with a default resource, it is replaced by the more unique resource.
The game takes place in a fantasy world. This is reflected in the artwork and graphical
style of the game. The world is populated by several fantasy races and magic and
technology can coexist.
10.3 Constructions
Players can build cities and other constructions on tiles. Only one construction per tile
is allowed. The types of constructions are:
– Resource stations. They are used to gather resources. Resources and resource
stations are further described in the “Resources” section.
– Cities. Allows the player to own land and provides the player with manpower.
Cities are further described in the “City” section
– Roads. Roads are used to move units faster and to connect resource stations to
cities. The construction of roads can be performed in different ways:
• A road can be constructed on a tile. This allows the player to build roads
anywhere and everywhere. This can result in an exaggerated construction of
roads that covers the entire map. Increased cost for each road or a running
cost may solve this problem (but introduces new ones such as illogical reasons
for the increased cost and the problem with what happens if a player cannot
afford the running cost).
• Roads are constructed only by connecting different constructions to each
other. This demands that there is a construction on each end of the road.

10.4. Timescale 85
– Forts. Forts allow the player to own land outside of city borders. They can be
built on neutral territory. Forts might have to have manpower assigned to them
to function. If the manpower is removed the land becomes neutral again (if not
another player have claims on it, in which case that player will get control over
the land). Forts give a bonus to any defending army on that tile.
– Watchtowers. Are used to surveil land. They can be built on neutral territory.
Watchtowers may require manpower to function. The difference between watchtowers
and forts is that watchtowers do not allow players to own any additional
land.
All constructions cost time and resources to build. It is possible to demolish constructions
to get some of the (resource) cost back.
10.4 Timescale
The relation between the game time and real time should be easy to adjust. It should
also be possible to adjust different parts of the time system individually. This is very
important if sessions of different duration are to be supported. The following suggestions
are based on the assumption that one game session will last for a long time (more than
a year). All time measurements are in real time unless otherwise specified.
– The timescale of the game is that approximately 24 hours in real life equals 6
months in the game.
– A battle will take approximately 1 hour (though with variations depending on the
size of the smallest side of the battle).
– Taking full control of a city will take approximately 3 days.
– Family members will live for approximately 30 game years, but they will only
be possible to take control of after they have reached the age of 16 making the
playable time with a family member about 1 month. The lifespan can be increased
through research.
– It should take about 4 hours to move through an area in enemy territory (an area
can consist of several tiles). This means that it should take a minimum of 4 hours
from the declaration of war until someone can attack a city.
The time scale in the game should be presented as game time, but it should be easy
for the players to compare it to real time. An option to show real time instead of game
time should be included.
10.5 Seeing & Fog of War
A player sees the land that the player owns plus one tile in any direction. This means
that if a player owns a square made of nine tiles the player sees a square consisting

86 Chapter 10. Resulting design document
of 25 tiles. Armies and some constructions have a “seeing radius”. The seeing radius
makes it possible for a player to see beyond the players land. Constructions that have a
seeing radius are cities, forts and watchtowers. A city can have a smaller seeing radius
than ownership radius (described in the “Cities” section), but the seeing radius is large
enough so that no player can “sneak up” on a city.
The game includes “fog of war” which hides some information about tiles that the player
has previously seen but does not see at the given moment. The terrain of previously
seen tiles is still visible, along with cities and other constructions. Armies and other
movable units can only be seen if there is a unit or construction close enough to actually
see it. New information about a “fogged” tile is not visible (for example the building, or
destruction, of new constructions). The fog of war should fade into the graphical style
of an old map while tiles that can be fully seen are more detailed (with color etc.). Tiles
that the player has not seen at all are blank parts of the map.
10.6 Movement
It requires time to move movable entities between tiles on the map. An alternative is to
use movement points that the entities accumulate over time. These points would then
be used to move entities instantly between tiles. Both systems could be used but for
different types of entities. Fighting entities such as armies would then use movement
time while entities such as explorers would use movement points. This is done to simplify
exploration.
10.7 Events
Events are things that occur in the game that players cannot decide whether or not they
should happen (they could however be triggered by player actions). One must be very
careful to not introduce events that punish players randomly (some sort of heads up is
required). Events could be:
– The birth of a holy person (i.e. making a place more valuable).
– The appearance of a dragon.
– The birth of an island.
– Famine.
– Good years.
– Large battles (or other events) can trigger tiles to become holy (thus making it
more valuable).
Famine could for example occur if a player has more manpower than the maximum
amount. The manpower could then be decimated until it is below the maximum again.
The player must be warned about the event before it occurs. The game has to allow for
the possibility of including events such as this.

10.8. Encounters 87
10.8 Encounters
Encounters should be included in order to make exploring more interesting. Encounters
could be entirely random, with a certain chance of occurring each time a unit enters
a new tile. It could also be locations that hold the events; this could for example be
represented as tribal villages. Both alternatives could be included.
Players should be given different alternatives when an encounter occurs. It could for
example be possible to deal with the encounter with brute force, diplomacy or stealth.
These alternatives are suitable if an explorer is involved in the encounter. If an army is
involved stealth might not be an alternative. Sufficient alternatives might be battle or
leaving the encounter alone.
10.9 Goals & endings
There basically two alternatives for the goals and endings of the game:
– The game is played over an extended period of time and there is no defined end.
To ensure that the game stays interesting expansions are to be released on a
regular basis. These expansions will provide the players with more technologies to
research, resources to gather and so on. Because the game is based on continuous
expansions all options (in terms of research, technologies, resources and so on) can
not be visible for the players when starting out. There should however be a hint
of an end, where each expansion implies that the ending is drawing nearer. Each
expansion also delivers the story of the world to date.
– The game ends after a period of time, or after an end requirement has been reached.
Many instances of the game can then be running at the same time. New instances
can start at a regular interval. Each instance has a certain amount of time in
which players can join after it has been launched. This system minimizes the gap
between old and new players, thus making the game easier to balance.
In addition to these alternatives it is possible to allow players to start their own instances
of the game. These instances will be limited in time and number of players.
10.10 Highscore
The players highscores (based on the prestige of the families, see Family and family
members, Prestige) are stored in two lists. One list represents the combined prestige of
the family; all players are visible in this list. The other list is divided into a list for each
category of prestige; players can only see their own position in this list. The top 10 of
each list is however also visible to all players.
There is also an additional list for each category of prestige where the all time top three
players are listed (that is, the best three scores ever recorded in every category are
listed).

88 Chapter 10. Resulting design document
10.11 Manpower
The player has access to manpower that can be used to:
– Create/reinforce armies
– Gather resources
– Conduct research
The player has manpower of several different races (described later). There is always a
maximum amount of manpower for each race; this is defined by the population in the
player’s cities. The maximum cannot however drop below a certain amount.
The available manpower increases at a certain rate until it reaches the maximum amount
that the player can have. Manpower that is used (in armies, resource stations and
as researchers) is included when determining if the player has reached the maximum
amount. If manpower dies (from the result of battles) it will thus slowly regenerate. If
the maximum manpower for a player is decreased (for example because of the loss of a
city) the manpower available to the player will not be changed, nor will any manpower
used in armies etc. be removed.
10.12 Cities
Each player controls a number of cities. The primary purpose of a city is to provide
the player with manpower. Each city that a player controls has to have at least one
family member connected to it if the player is to be able to fully control the city. If a
family member dies, it is possible that a city will not have a family member connected
to it. This will result in that the city will become far less productive (i.e. constructing
buildings will require more time, research will become less efficient and the running cost
of buildings will be greater).
To get additional cities a player can conquer cities (see Conquest and expansion, conquering
cities) or build cities. In both cases the player needs at least one family member
that can be connected to the new city (i.e. the city, to which the family member in
question is connected to, has to have at least one other family member connected to it).
There is also a cost in time and resources to construct a new city.
A city has an ownership radius that is used to determine which tiles that the owner of
the city can own. All tiles with the center inside the radius can be owned by the owner
of the city, but just because a tile is within the ownership radius it does not mean that
the player owns the tile. If several players ownership radiuses that overlap, the tiles in
the overlap can be owned by any of these players.
A city has a “seeing radius” that determines how long the city “sees”. A city can have
a smaller seeing radius than ownership radius, but the seeing radius is large enough so
that no player can “sneak up” on a city.

10.12. Cities 89
10.12.1 Buildings
It is possible to construct buildings within a city. Each building gives a bonus to some
area or makes new build options available. It is possible to queue the buildings that
are to be built so a player can order the construction of a couple of buildings and then
log out. It is possible to cancel a building in the build queue. To be able to build a
building a player needs the resources it costs in the reserve. The cost in resources is
paid immediately, even if the building is placed in the queue. If a building is cancelled
all resources are returned, but if construction has begun not all resources are returned.
This can result in that a player can store more resources than there is room for in the
reserve. The other alternative is that resources are paid when the actual construction
is begun. Then it will be possible to queue many buildings at once without having the
resources to pay for them. The question is what will happen if the player cannot afford
a building in the queue when it is time to construct it.
Some buildings have a running cost. This means that they will constantly drain a
resource to be able to function. The running cost is always one single resource. It is
possible to set how much of the resource that will be distributed to a building. If the
amount is decreased, the building becomes less effective. Some buildings might only
function if it gets the full amount it requires, making the choice of distribution a matter
of on or off. If the player cannot afford to pay the running cost the buildings using that
resource will become less effective. If there is no gain and nothing left in the reserve the
buildings will cease to function altogether.
Buildings have levels, starting from level one. It is possible to upgrade buildings in
order to increase their effect. Upgrading buildings cost time and resources and can also
increase the running cost that the building may have. Both the building of new buildings
and the upgrading of old ones are placed in the same building queue. It is possible to
downgrade and demolish buildings in a city. This will return some, but not all, of the
resources it costs.
Examples of different effects that buildings can have are (one building can have several
effects):
– Population effect. Affects the population in the city (for one or several races).
The effect can be in a fixed number or in percent. It can be that one race is
increased and another is decreased.
– Influence effect. Affects the population of other cities (in the same way as
population effect).
– Influence radius effect. Increases the influence radius.
– Ownage radius effect. Increases the ownage radius.
– Unit effect. Enables the building of certain units (or certain levels of units).
– Defensive effect. Can give bonus in the defense of a city.
– Research effect. Can affect both the maximum amount of researchers in a city
and their efficiency.
– Manpower gain effect. Increases the rate in which manpower is generated.

90 Chapter 10. Resulting design document
– Storage effect. Increase the amount that can be stored for one or several resources.
– Prestige effect. Increases the prestige for family members or the player.
10.12.2 Population
Each city has a certain population and a large population contributes with a large
amount of manpower. The population determines the maximum amount of manpower a
player can have. The population in each city can consist of one or many of the different
races available in the game. The population depends on how developed the city is.
Population is increased by constructing buildings in the city. Some buildings increase
the population with a fixed number and others give an increase in percent.
10.12.3 Influence
A city has a radius in which it influences other players’ cities. The influence affects the
population of the cities. There are several different ways in which this can work. Some
examples of possible effects are listed as follows:
– Negative effect on the population for enemy cities.
– “Steal” effect on enemy cities (decreasing the population of influenced cities while
increasing the population in the influencing city).
– Positive effect on the population of allied cities.
– Balanced effect on all cities (including the cities owned by the player him-/herself).
All of the mentioned effects can be used or a combination of a few etc. It is however
crucial to test this further as the effects on the game cannot be foretold at this stage!
10.13 Races
The game contains a number of different fantasy races (even though the races are not
decided yet, the classical example would be dwarfs, elves, orcs and so on). The number
is not more than seven and not fewer than three. They all have different strengths
and weaknesses (except maybe for the human race which has no particular strengths
or weaknesses). The player chooses a race for his/her family in the beginning of the
game. Through interracial marriage the players family can change race (although of
course only the child from an interracial marriage is affected). The population in the
cities of the world also consist of these races and thus contribute with different types of
manpower (discussed in Cities).
The races in this game will not be defined as good or evil, but rather just have different
strengths and weaknesses. These differences can be found in all parts where manpower
and family members are represented, for example in battles, resource stations and research.
There are two different alternatives that can represent these differences; race
attributes and race exclusion.

10.14. Resources 91
10.13.1 Race attributes
All races have attributes that define their abilities in the game. This includes both
family members and manpower. The attributes are typical role-playing stats such as
strength, dexterity, intelligence and so on. A race like a troll can have high strength but
low dexterity. All races have the same attributes but have different values. This means
that all races can perform everything but they are differently successful in it.
The attributes define different races efficiency in the resource stations. A resource station
is based on one or several attributes. A quarrel that gathers stone might for example
have strength as its base. Trolls with high strength then gather more stone than humans
with intermediate strength.
Different units are also based on different attributes. For a unit equipped with a club
higher strength means more damage but for archers accuracy is more important than
strength. That means that when building an archer unit high dexterity is more important
than high strength. A race with low dexterity misses with many arrows and thus
inflicts low damage. A unit has a basic damage that is modified with the attribute(s) it
is based on.
Research can also be based on different attributes. There different races can be good at
different branches in the science tree.
Family members’ skill in different focus areas are also determined by their race attributes.
This means that a family member can begin with a higher level in a focus area if it has
a high value in the attribute that the focus is based on. This is a bonus in the beginning
of the family member’s life. Family members can of course gain levels in all focus areas.
10.13.2 Race exclusion
Race exclusion means that some races are excluded from resource stations, units and
research. This could for example be that only trolls, dwarfs and humans can work in a
quarrel and that trolls can never be archers.
Of course a combination of these two alternatives also works. They are not mutually
exclusive. A combination means that a race must have at least a minimum value of an
attribute to not be excluded. Any value above the minimum value can (but not must)
mean a bonus. Units equipped with longbow may for example require strength of 12 or
higher to be able to draw the bow. But it is the dexterity that gives the bonus.
10.14 Resources
To have access to and to be able to gather resources is vital in the game. The resources
feed cities as well as provide the means to be able to build armies and buildings.
There are several different resources. Some are basic resources needed to feed cities
and build basic buildings etc. These can for instance be food, wood, stone and so on,
this kind of resources can be found all over the world. There are however also more
rare resources. These can be used for more advanced buildings and units. The more

92 Chapter 10. Resulting design document
rare resources are also unique (or at least more common) to certain areas (it might for
example only be possible to find diamonds in the south or spices in the east).
To be able to gather resources a player has to assign manpower to a resource station
located on a tile that has the resource. The resource station also has to be connected to a
city via a road. There is a resource station type for each individual resource. A resource
station has a maximum amount of manpower that can be assigned to it. The efficiency
of a resource station determines how much of the resource each manpower gathers. It
is possible top upgrade a resource station to increase efficiency and maximum amount
of manpower.
Resources cannot be depleted, there is however a limitation in the quantity that can be
gathered per time unit (larger stations with more assigned manpower of course gathers
more resources than smaller ones with less assigned manpower).
The resources a player gathers are available to use anywhere, that is, the resources are
not connected to any one city, thus alleviating the need to transport resources between
cities that a player owns.
To be able to use all resources players have to research technology to “understand” the
resources. A resource that a player has not “discovered” yet is not visible to the player.
10.15 Family and family members
Each player plays a unique family, i.e. the player takes control of a family and its
members. The family always has a “head of the family” that is the most powerful and
important character in the family. The city to which the head of the family is connected
is the players’ capital city. The player can choose freely which family member who
should inherit the throne when the head of the family dies.
When beginning the game the player has to chose what race the family should start
out as (though this can change over time through marriage and reproduction). The
race determines the basic attributes of the family members. The player can modify the
attributes to a certain degree by distributing some amount of points.
Since it is impossible to take over or build a new city without a family member that
is not connected to another city the family members work as a limitation to how large
a players’ empire can grow. This works by always having a limit to how many family
members a player can control at any single time (the player can conduct research that
increases the limit on family members). Each family member has to be connected to a
city; there can however be more than one family member in each city.
10.15.1 Prestige
Each player has a score that depends on the collective prestige of the family. Each
family member thus has a prestige score that adds to the collective prestige. The
prestige depends on what the family member accomplishes. A family member that wins
a great battle against a superior army might for example get a lot of prestige. It is also
possible to get prestige while contributing to research or building and so on.

10.15. Family and family members 93
The prestige is categorised. That is, a family member gets high “battle prestige” for
winning many battles. They can also get “science prestige” or “building prestige” where
“science prestige” increases if the family member contributes to scientific discoveries
and “building prestige” increases if the family member contributes to the completion of
buildings.
The player’s prestige is larger than the sum of the family members’ individual prestige.
Such things as the players’ wealth or scientific achievements are not directly coupled to
an individual family member but are still included in the collective prestige.
When declaring war a player looses prestige (the loss is greater if the player attacks
a significantly weaker player), this prestige loss is coupled to the general (i.e. family
member) that leads the army that triggers the declaration of war or, if there is no general
in the army, to the head of the family. This works for each situation where there is no
leader for an army (such as when winning great battles), i.e. the head of the family gets
prestige that a leader should have gotten (though not as much, the amount of prestige
loss for a declaration of war is however the same). Another alternative is that the player
loses prestige when declaring war.
10.15.2 Reputation
Each family member has a reputation that corresponds to his/her actions. This reputation
can then result in different “titles”. If a family member for example is involved in a
lot of victorious battles he/she might get the title “the conqueror”. In contrast, a family
member that spends most of his/her time in a city focusing on building might get the
title “the architect”. A family member’s attributes can also influence the reputation.
10.15.3 Life and death
Each family member has a certain life span. This means that after a while he or she will
die. This ensures that no single player can have the highest score at all times and thus
the leader boards will always be in motion. The player will also get new family members
to control; this is of course represented by the family members having children. This
means that if the highest amount of family members a player can have is five, then the
player might actually have less family members at any given time (though not a lot less
and not for too long a time). It should however not be possible to kill other players
family members as this simply makes too much of an impact.
A family member always has a minimum age that it will live, after that age there will
be a risk that the family member dies for each successive year. This risk also increases
with each successive year.
10.15.4 Development
The family members can become better in different areas over time. This is represented
by experience that the player can distribute on the different attributes that a family
member has. The experience of a family member increases at a certain rate over time.
The family members also get extra experience for their accomplishments (such as being

94 Chapter 10. Resulting design document
a part of discovering new technologies, participating in battles, discovering new tiles and
so on). A family member needs more and more experience to get better.
10.15.5 Usage
The family members can be used in the cities that they are linked to by focusing their
efforts on an area of the players’ choice. This could be to increase the efficiency of
research, shorten the construction time for buildings and so on. The family members
can also be used as generals in an army (they are however still linked to a city and
represented as focusing on military). Here the family member gives a bonus to morale,
strength, defence or even perhaps to the AI (meaning that it is better at adapting to
the current situation on the battle field). Additionally the family members can be used
as explorers.
10.15.6 Marriage
To be able to have children the family members must marry. Players can marry their
family members to other players’ family members, which would result in a prestige
bonus (for the children). If the player does not marry their family member in time
(i.e. if the family member reaches a certain age) it is automatically married to a nonplaying
character (which would result in the child not getting any prestige bonus, but
still enabling the family line to prevail). To be able to marry off family members some
sort of “dating service” or “market” for available family members must be included.
Only humans can marry all races. The other races can only marry a subset of the races.
The marriage between players’ family members is not as desirable if the game is limited
in time (see Goals & endings).
10.15.7 Family history
Throughout the game a family history will be created automatically. All kinds of statistics
and data, such as the great deeds mentioned under Prestige, will be recorded and
described in text. The player can, at any time, access this information. The family
history will also contain a family tree where all family members and their relations to
the family are recorded. The connection to other players’ families (through marriage)
is also shown here.
10.16 Armies
The player can of course have armies at his/her disposal. These can be created by
assigning manpower to the army. Armies can be used to defend cities, attack other
armies and plunder or taking over cities or land. The armies need manpower (which
adds to the overall limitation of how much manpower a player can have) which limits
the amount and the size of the armies.

10.17. Conquest and expansion 95
10.16.1 Leaders
The army can have a leader assigned to it (i.e. a family member). This leader can boost
the stats of the army (such as morale, strength, defence and so on) depending on how
good the general is. It is also possible that the general enhances the AI for the army
(meaning that it is better at adapting to the current situation on the battlefield).
10.16.2 Units
An army can consist of many different units. The units have different strengths and
weaknesses and they are also affected by terrain to different degrees. There are different
types of units for example cavalry, infantry, archers, artillery and so on. These groups
can also be further defined (i.e. cavalry could be heavy or light and so on) by researching
more advanced or varied versions of the unit. The kind of units that are available for a
player is defined by what the player has researched and also what kind of resources the
player has available.
Units are “built” in cities and they cost time, manpower and other resources. The
amount of manpower and resources (as well as which resources are needed) is defined
by the unit type. Each unit has health and morale levels as well as other stats defining
their strength and weaknesses. When the health reaches zero, the unit dies. When the
morale reaches zero the unit flees.
Units cost upkeep to maintain. Both morale and health is reduced if the player cannot
afford the upkeep. If health reaches zero, the unit disbands. If morale reaches zero the
unit remains, but will flee instantly in battles.
Units can get experience from battles and thus become better if they survive many
battles (represented by better morale and other stats). If the entire unit is killed it is
not possible to get it back, but if it only has its strength weakened it can be reinforced.
The cost of reinforcements is cheaper on land owned by the player controlling the army
than in enemy held or neutral territory.
10.17 Conquest and expansion
The players can expand their territory by conquering both land and cities. It is also
possible to construct buildings (forts) and new cities (as long as the player has enough
family members) that expand the territory.
10.17.1 Conquering land
Each city has an area around it that defines what a player can own in terms of land.
The size of the area depends on the size of the city as well as how developed it is (i.e.
certain buildings can give a bonus). If the land in the area is neutral it automatically
becomes the player’s land. All land that is owned by another player must however be
taken over by military force or negotiated/sold. To take over a tile by military force a
player simply moves an army to that tile and defeats any army that stands on that tile.
The tile must also be within the area that a player can own.

96 Chapter 10. Resulting design document
10.17.2 Conquering cities
Cities can only be conquered by military force. This is done by defeating any defending
armies located in the city. It also takes a significant amount of time (much longer than
a normal battle) to get complete control over the city.
When a city is conquered any constructions that are no longer under the area which the
former owner can control (see conquering land) is destroyed. All buildings within the
city are also destroyed.
The player losing a city will not lose any of the manpower that has been acquired
from that city (nor will he lose any other resources available to him), the limitation in
manpower will however decrease (thus it is possible to have more manpower than what
the limit allows, but as long as the manpower is higher than the limit the player will
not get any more manpower).
10.18 Battles
The battles are played out between AI and are thus not possible for players to directly
influence (see Battle orders). The player can however see the result of battles “live” and
through replays. It is also possible to get a summary of the results of the battle. All
battles take some time to actually finish, this ensures that additional armies can join
the battle either to support one side or simply to attack every other army in the battle.
The time required to finish a battle depends on the amount of soldiers in the smallest
army (or side) in the battle.
If an army loses a battle but is not completely annihilated (the complete annihilation
of an army is rare) it will flee to the best possible (in terms of terrain bonuses) adjacent
tile closest to a friendly city.
There are two reasons to why an army could flee. The first is if the health of the army
gets lower than a predefined value (set by the player, this is called retreating) and the
other is if the morale of the army gets lower than a predefined value. The level of
health and morale for an army is the sum of the health and morale of the units within
the army respectively. The morale of units drops when they lose health, when other
units within the army are killed, when they get attacked from the rear or flanks, when
they get attacked by superior units or if the enemy fields an impressive unit (such as
a dragon). An army continues to be fleeing until the owner of the army orders them
to regroup. Units in armies that are not fleeing slowly regenerates lost morale. The
amount of morale regained depends on the units’ health (a unit with 70% remaining
health can thus only reach 70% of its initial morale).
To prevent that players “scout” enemy armies by attacking them with a single weak
and cheap unit, at least one unit has to survive the battle for the player to get any
information about it (more than just that it took place and that the player lost).
10.18.1 Capturing family members
If the unit that a family member is connected to (this would be some sort of elite unit,
for example the family members personal guard) is wiped out the family member gets

10.18. Battles 97
captured. The player who captures the family member can decide what to do with it
(though it is not possible, in any way, to kill an enemy family member). The options
are (followed by what the capturing player gains):
– Set the family member free (prestige, reputation goes toward benevolent)
– Demand ransom (a predefined value of a resource chosen by the capturing player,
reputation goes toward greedy)
– Disgrace (the captured family member loses prestige, reputation goes toward
nasty)
– Torture for information (the capturing player has a chance of gaining a technology
that the captured player has researched, reputation goes toward bloodthirsty)
10.18.2 Battle orders
A player can set battle orders for each army and for each unit within the army. The
battle orders tells the army how it should behave in a battle as well as how their initial
formation should be. This is however not a fixed behaviour but rather an initial idea
of what the army should try to do. The AI is in charge of trying to “make the best of
the situation” given the initial orders set by the player and the size, composition and
tactics of the opposing force.
A player can conduct research to get access to more advanced battle orders and formations.
The more advanced alternatives are however not a certain way to get a better
army but rather just a way for the player to be able to influence the army in more detail.
It is also possible to set the overall behaviour of the army. This could be to hold its
ground, meaning that it will not move for anything, attack any enemy army in sight,
go to a location without attacking, go to a location and attacking everything in its way
and so on.
10.18.3 Attacking cities
When starting an attack on a city a player has a choice of pillaging, burning or taking
control over the city (if there is any family member that can be assigned to the city).
Pillaging is the easiest to accomplish and to take control of the city is the hardest to
accomplish. The following happens if the player succeeds:
– If the player pillages the city some resources are stolen. The attacking player can
chose the preferred resource to steal.
– If the player chooses to burn the city each building within the city also has a quite
large risk of being destroyed.
– If the player chooses to take control over the city the city is besieged by the
attacking army and will eventually fall under the control of the attacking player.
This alternative can only be chosen if there is a free family member in the army.

98 Chapter 10. Resulting design document
If an additional army attacks a city that is already under attack the new army can choose
to support the attacker, the defender, try to attack the city for themselves (any of the
attacking alternatives is possible, but this means that the army has to attack all armies
already battling for the city) or to withdraw. Alliances can affect the alternatives.
10.18.4 Attacking resource stations
It is possible to attack resource stations to pillage the resource that the resource station
gathers. The amount stolen depends on the level of the resource station as well as the
size of the army. After a resource station has been pillaged, it takes some time before it
can be pillaged again.
The possibility to plunder resource stations can replace the alternative to plunder cities,
since they have the same function.
10.19 Research
By assigning manpower to research the player can improve his/her empire in different
areas. There are several different areas in which research is possible. Each area can be
seen as a stem (with branches) in the technology tree. To assure that new players don’t
get left too far behind each player that has researched a certain technology in a stem
makes it easier for the next player to research that technology (i.e. for each player that
has researched a technology in a stem the shorter the research time for that technology
gets). This applies only to technologies in the different stems and not in their branches.
Technologies in the branches are more “applied technology” than the stem technologies
which are more basic research that might not be possible to use directly.
The following things are examples of what can be researched (they are not however
necessarily stems in the technology tree).
– Military (new/improved units, more advanced battle orders)
– Trade (less loss per distance, possibility to trade over longer distances)
– City development (attraction level, capacity and so on)
– Production (resource gathering/refining, shortened building times)
– Research (faster research)
– Family development (longer life span, larger family, more experience)
10.20 Trade
To get access to all resources the player will have to trade. The player has access to a
basic trading post in the beginning of the game. This enables the player to trade with
other players in his/her vicinity. This is done by defining an offer to buy or sell a certain
amount of a resource at a certain price (for example [buy 1000 wood for 100 gold]). It

10.21. Diplomacy 99
is of course also possible to see other players’ offers and accepting them to buy or sell
resources.
The level of researched trade defines how “far” the player is able to trade. Each successive
level of trade research lessens the amount of loss per distance between the two
trading players’ capitals or gives the player access to buildings that lessens this loss. If
the loss is over a certain amount the player cannot see the other players offer to buy
or sell. The loss is always calculated from the perspective of the player with the most
advanced trading technology, but it is always paid by the player who confirms the deal
(i.e. the player that accepts another players offer to buy or sell).
It is also possible to set up running deals with other players. These deals can take the
form of [buy 10 wood/hour for 1 gold/hour for 10 hours]. If war breaks out between the
players this kind of deal would of course cease to function.
Trade works by exchanging resources (i.e. there is no currency for which the players can
trade all resources). There is no cost in time to conduct trade.
It is possible to set up private trade deals. A private trade deal is initiated by a player
that proposes a deal directly to another player. Only these two players can see the trade
deal. Loss functions in the same way as with regular trade deals.
10.21 Diplomacy
As a major part of the game is interaction with other players diplomacy is of course
essential. There are basically three states between players: neutral, alliance and war.
There is always a penalty in prestige to declare war on another player (if the player that
declares war is much stronger than the player upon whom war is declared the prestige
loss is far more significant than if the players are of similar strength), but this can of
course be remedied by conquering land or cities. To be able to attack another player;
war has to be declared.
10.21.1 Communication
There are several ways of communicating between players. If players are not in an
alliance of any sort, the only way of communicating is by sending messages. These
messages can only be sent to one player at a time, but does not require any time to
arrive or any other limitation.
In alliances (though not in non-aggression pacts, see Alliances) there is a form of
“alliance-chat” where players can communicate with all other players within the alliance.
There is also a forum for each alliance.
10.21.2 Alliances
Alliances can be of three types: non-aggression pacts, military alliances and “guilds”.
If two players have agreed to a non-aggression pact it means that a player that attacks
the other player suffers a significant prestige loss. If two players are in a military

100 Chapter 10. Resulting design document
alliance and one player gets attacked by a third player it means that both players in the
alliance will become in a state of war (without any loss of prestige) towards the attacking
player (as opposed to only the attacked player becoming in a state of war towards the
attacker if there is no alliance in play). Of course there will also be a significant prestige
loss if a player attacks another player that he/she is allied with. Guilds are a more
loosely defined alliance where the players themselves can define the rules for the alliance
(the rules for non-aggression pacts and military alliances are possible to use, but not
necessary). Players set the rules by selecting from drop-down lists or checkboxes which
means that the game can keep track of the players and if they break the alliance or not
(the rules can define who can join, who can start wars, if it is a democratic alliance, who
leads the alliance and so on). What this means is that non-aggression pacts and military
alliances are only predefined lighter versions of a guild. It is possible for alliances to be
allied with other alliances.
The basic alliances (non-aggression and military) are possible to limit in time (for example
it might be possible to agree that a non-aggression pact should hold for one
week).
10.22 Log
All significant events that occur in the game should be recorded so that players can
access the information when they log in. A player can only access information that that
would have been visible if that player had been online. The log should store all this
information. Examples of the type of information are:
– Declarations of war
– Battle progress
– Accepted/rejected trade deals
– Discovered technologies
– The completion of buildings/constructions
– Army movements
– Etc.
There should also be messages about such events when the player is online.
10.23 Beginning of the game
When a player begins a game the player gets a city, one exploring unit, one army,
some manpower and some resources. All basic resources are available within the initial
ownership radius of the city. The player also has an initial storage capacity of the basic
resources and manpower of each race. The player also begins with a number of family
members. All family members are located in the city.

10.24. Issues that needs to be resolved 101
Since the game is fairly complex there must be some sort of tutorial included for new
players. It should be possible to skip the tutorial. Help and documentation is also
important and should be accessible at all times from the game. I.e. help should be
available within the game and not only through external manuals.
10.24 Issues that needs to be resolved
Some features are not yet final, here follows a summary of these issues:
– Whether or not plundering should be possible of both resource stations and cities.
– What and how many resources that should be included.
– If and how marriage between players’ family members should be included.
– What categories of prestige for family members that should be included.
– If the game should have an end or not.
– If and what attributes and abilities races (and armies) should have.
– How random encounters should work (i.e. entirely random or with “places” on the
map and what interaction possibilities these should include).
– If movement time or movement points should be used (or if both should be included).
– How to balance the loss of a city (for example if players should be allowed to
rebuild each city that they lose or only their last city).
– How fleeing armies should behave.
– The entire battle system needs to be further defined and tested.
– How conflicting alliances should be handled (i.e. what should happen if player A
is allied, in different alliances, with both player B and C and B and C declares
war on each other).
– How to handle inactive players.

102 Chapter 10. Resulting design document

Chapter 11
Discussion & Conclusion
The project aimed to elicit requirements and wishes, develop a functional prototype,
evaluate the prototype and to comprise a design document for the gameplay of the
game, all of which have been done. The design document is not complete and more
work could of course be done.
Comments from the evaluation showed that there is an interest for a game of this kind.
The prototype also showed that the game is playable. This might sound simple and
obvious but is nonetheless very positive. There is much work left to be done in order to
fill the game with content and to balance it. The evaluation also showed that it might
be difficult to keep this kind of game interesting if the game has no end (such as a
time limit or certain winning conditions), although the conceptual idea of an everlasting
world is very intriguing.
A lot of ideas may be generated when asking potential users what they want (as was
done with focus groups etc.). Since the users might not reflect upon their ideas and
consider the more far-reaching consequences it requires quite a bit of work from the
designers to sort through and evaluate them. This was of course true in this project
as well as the users generated a vast amount of ideas. This resulted in a lot of work
going into the evaluation and compilation of the ideas. There is also the danger of
“feature creep” where features that might not be essential to the gameplay tend to pile
up and “clutter” the game. Some effort has gone into trying to avoid this, but if this
has succeeded or not remains to be seen. Another issue when interviewing potential
users of a game is that there is no clear goal for a game, at least not when compared
to traditional software aimed at being productive. The goal of a game is instead to be
fun and finding requirements for “fun” is indeed a difficult task. This has also resulted
in quite sprawling ideas that have not always been possible to combine into something
that still makes sense. To have a vision of the concept for the game at the beginning
of the project was a great help when sorting through the ideas. The design principles
from the brainstorming sessions also helped a lot when evaluating the generated ideas.
Some design principles were easier to design for than others which of course have an
effect on the design. An example of a principle that has influenced the design is that “It
should not be possible to be the best (or to do everything) in each area of the game”.
This is of course a balancing issue, but the design definitely allows for different ways of
103

104 Chapter 11. Discussion & Conclusion
playing that can be balanced in a way to follow the principle. This is also related to
the principle of “The game should allow for different playing styles. The players should
define how they play”. It was however more difficult to design for the principle of “It
should not be possible to harass weaker players”. Though there are some mechanisms
in the game to counteract harassing (such as the significant loss of prestige to declare
war on weaker players) it is not certain that these are enough. This principle along with
“Players should not be helpless while they are logged off” will require more balancing
and testing. Especially since it is very difficult to determine where “helplessness” and
“harassment” sets in and what levels that can be tolerated by the players. The feeling of
helplessness is something that should be avoided entirely, but at the same time the game
cannot be allowed to replace the player in the decision making etc. The problem with
harassment is that players should be allowed to conduct warfare as a mean to progress
in the game while players who are attacked must not feel too discouraged to continue
playing. The design must also handle the problem of players playing solely to destroy
the experience for other players.
11.1 Restrictions & limitations
Prototyping is important during iterative development. Several prototypes are usually
developed and tested in an iterative way. Lo-fi prototypes are built and evaluated at the
beginning of development and more advanced high-fi prototypes at the end. Video games
can also benefit from being prototyped early in development. Paper prototypes can be
built to examine how different design decisions affect gameplay [22]. Unfortunately there
was not enough time to construct and test both lo-fi paper prototypes and a working
prototype. Therefore only a working prototype was constructed and tested. A working
prototype was chosen because a persistent multi player game would be difficult to test
solely with lo-fi prototypes.
Some features were simplified or not included in the prototype due to time constraints.
This means that they could not be tested with end users. One feature that was left out
was the death of family members. Thus it was only possible to ask players to imagine
what they would feel if any of the family members died. An example of a simplified
feature was the battle system. The simplified version made it possible to test the concept
of battles, but not the battle system itself.
The prototype was developed so that the game could be tested with many players. Few
players played the game for more than a short period of time. A major reason for this
was that the prototype lacked documentation and a tutorial. Without documentation
or tutorial it was hard to understand and feel engaged in the game and some people quit
after only playing for a moment. Other players reported that they quit playing because
they felt the game was too slow and there was not much to do. This affected evaluation
since few players had played the game long enough to explore all aspects of it.
One other thing that affected the validity of the evaluation of the prototype was the
bugs it had. One bug that affected battles was that archers inflicted massive damage,
much more than any other unit. This made it possible for players who knew about the
bug to exploit it and gain an advantage in battles. This bug could also have lead to
players feeling reluctant to engage in battle.

11.2. Future work 105
A forum was launched with the release of the prototype. It allowed people to report
bugs, ask questions, make suggestions and give their opinions about the game. The
opinions and suggestions were taken into consideration during the evaluation of the
prototype. Several bugs were reported but few suggestions or opinions were posted. This
is unfortunate since all active players were not present in the focus group evaluation and
they might have had different opinions.
11.2 Future work
All features in the design document have not been tested. It would therefore be valuable
to continue the iterative process by building more prototypes and evaluate them. It may
not be necessary to build a full working prototype of the game, just small prototypes to
test the parts that has been left out of the current working prototype. The changes that
have been made to the design document after the evaluation needs to be tested further.
One of these changes is the loss of cities to other players. In the heuristic evaluation
one of the issues found was that players might be discouraged and stop playing when
they lose a city. There have been occurrences when people stopped playing when they
lost a city in the prototype. However, in the focus group interviews people requested
the ability to take over other players’ cities. One of the reasons was that they wanted
to be able to expand their land. Further testing is required to make sure that there is
a balance. Taking a city must be rewarding but at the same time cannot punish the
losing player too severely.
When the rules and features of the game are established the game must be filled with
content and balanced. Units, manpower and access to resources are all examples of
things that need to be balanced.
An interface of the game needs to be developed with focus on users and usability. One
of the requests in the brainstorming sessions was an interface that the user could tailor
to his/her specific needs. It would be interesting to investigate how different playing
styles would affect the design of the interface. Other things that were not considered in
the design document also need to be developed. These include graphics, sound, a world
history and software solutions.
It is important to find a suitable business model for the game. Two examples, used
in similar games today, are monthly fees and micro transactions. Monthly fees mean
that a player pays a certain amount of money per month to be able to play the game.
The system of using micro transactions means that the game is usually free to play, but
the player can buy additional items in the game. These items can either be entirely
cosmetic, as a new outfit for the character, or they can give an advantage in gameplay,
as a better weapon or faster vehicle. Another method is to finance games by advertising.
This approach can be seen on many game portals.

106 Chapter 11. Discussion & Conclusion

Chapter 12
Acknowledgements
We would like to thank everyone who has contributed to the project and the work on
the functional prototype.
Thanks to Daniel Sjölie, our supervisor, for his help and comments.
Thanks to everyone who played the game, with special thanks going out to those who
commented the game on the forum. Extra special thanks to our focus groups and
interviewees, who contributed with a lot of good ideas.
We would also like to thank support at the Department of Computing Science for their
help with setting up the database and revision control system among other things.
107

108 Chapter 12. Acknowledgements

References
[1] Arsenault, D. DARK WATERS: SPOTLIGHT ON IMMERSION. In Game-On
North America 2005 Conference Proceedings (2005), pp. 50–52.
[2] Barendregt, W., Bekker, M. M., and Speerstra, M. Empirical evaluation
of usability and fun in computer games for children. In INTERACT-03, Proceedings
of the IFIP 8th International Conference on Human-Computer Interaction (2003),
vol. 3, pp. 705–708.
[3] Barnum, C. M., and Dragga, S. Usability Testing and Research. Longman,
2001.
[4] Bell, T., and Thayer, T. Software requirements: Are they really a problem?
Proceedings of the 2nd international conference on Software engineering (1976),
61–68.
[5] Brown, E., and Cairns, P. A grounded investigation of game immersion. In
CHI ’04: CHI ’04 extended abstracts on Human factors in computing systems (New
York, NY, USA, 2004), ACM, pp. 1297–1300.
[6] Chen, J. Flow in games (and everything else). Communications of the ACM 50,
4 (2007), 31–34.
[7] Chung, L., Nixon, B., and Yu, E. Using Non-Functional Requirements to
Systematically Select Among Alternatives in Architectural Design. Proc. ICSE-
17 Workshop on Architectures for Software Systems, Seattle, Washington, April
(1995), 24–28.
[8] Chung, L., Nixon, B., Yu, E., and Mylopoulos, J. Non-Functional Requirements
in Software Engineering. Kluwer Academic Publishers, 2000.
[9] Clanton, C. An interpreted demonstration of computer game design. In CHI
’98 conference summary on Human factors in computing systems (New York, NY,
USA, 1998), ACM, pp. 1–2.
[10] Cleland-Huang, J., Settimi, R., Zou, X., and Solc, P. The Detection and
Classification of Non-Functional Requirements with Application to Early Aspects.
Proceedings of the 14th IEEE International Requirements Engineering Conference
(RE’06) (2006), 36–45.
[11] Cruz-Neira, C., Sandin, D. J., DeFanti, T. A., Kenyon, R. V., and Hart,
J. C. The CAVE: audio visual experience automatic virtual environment. Communications
of the ACM 35, 6 (1992), 64–72.
109

110 REFERENCES
[12] Csikszentmihalyi, M. Flow: The Psychology of Optimal Experience. Harper &
Row, 1990.
[13] Cysneiros, L., and do Prado Leite, J. Nonfunctional Requirements: From
Elicitation to Conceptual Models. IEEE Transactions On Software Engineering
(2004), 328–350.
[14] Davis, J. P., Steury, K., and Pagulayan, R. A survey method for assessing
perceptions of a game: The consumer playtest in game design. Game Studies: Int.
J. Comput. Game Res 5, 1 (2005).
[15] Desurvire, H., Caplan, M., and Toth, J. A. Using heuristics to evaluate the
playability of games. In CHI ’04 extended abstracts on Human factors in computing
systems (New York, NY, USA, 2004), ACM, pp. 1509–1512.
[16] Edmunds, H. The Focus Group Research Handbook. McGraw-Hill, 2000.
[17] Ermi, L., and Mäyrä, F. Fundamental components of the gameplay experience:
Analysing immersion. Changing views: Worlds in play. Selected papers of the 20005
DiGRA’s Second International Conference (2005), 15–27.
[18] Fabricatore, C., Nussbaum, M., and Rosas, R. Playability in Action
Videogames: A Qualitative Design Model. Human-Computer Interaction 17, 4
(2002), 311–368.
[19] Faulkner, X. Usability Engineering. Palgrave Macmillan, 2000.
[20] Federoff, M. Heuristics and Usability Guidelines for the Creation and Evaluation
of Fun in Video Games. PhD thesis, Indiana University, 2002.
[21] Folmer, E., and Bosch, J. Architecting for usability: a survey. The Journal of
Systems & Software 70, 1-2 (2004), 61–78.
[22] Fullerton, T., Swain, C., and Hoffman, S. Game Design Workshop: Designing,
Prototyping, and Playtesting Games. CMP Books, 2004.
[23] Goguen, J., and Linde, C. Techniques for requirements elicitation. Requirements
Engineering, 1993., Proceedings of IEEE International Symposium on (1993), 152–
164.
[24] Gross, D., and Yu, E. From Non-Functional Requirements to Design through
Patterns. Requirements Engineering 6, 1 (2001), 18–36.
[25] IJsselsteijn, W., de Kort, Y., Poels, K., Jurgelionis, A., and Bellotti,
F. Characterising and Measuring User Experiences in Digital Games. International
Conference on Advances in Computer Entertainment Technology (2007).
[26] Isbister, K., and Schaffer, N. Game Usability: Advancing The Player Experience.
Morgan Kaufmann, 2008.
[27] Järvinen, A., Heliö, S., and Mäyrä, F. Communication and Community in
Digital Entertainment Services. University of Tampere: Hypermedia Laboratory
Net Series (2002).

REFERENCES 111
[28] Johnson, B., and Turner, L. A. Data collection strategies in mixed methods
research. Handbook of mixed methods in social and behavioral research (2003), 297–
319.
[29] Kitzinger, J. Qualitative Research: Introducing focus groups. British Medical
Journal 311 (1995), 299.
[30] Korhonen, H., and Koivisto, E. M. I. Playability heuristics for mobile games.
In MobileHCI ’06: Proceedings of the 8th conference on Human-computer interaction
with mobile devices and services (New York, NY, USA, 2006), ACM, pp. 9–16.
[31] Korhonen, H., and Koivisto, E. M. I. Playability heuristics for mobile multiplayer
games. In DIMEA ’07: Proceedings of the 2nd international conference on
Digital interactive media in entertainment and arts (New York, NY, USA, 2007),
ACM, pp. 28–35.
[32] Krueger, R., and Casey, M. A. Focus Groups: A Practical Guide for Applied
Research. Sage Publications Inc, 2000.
[33] Kücklich, J. Play and Playability as Key Concepts in New Media Studies. Tech.
rep., STeM Centre, Dublin City University, 2004.
[34] Laitinen, S. Do usability expert evaluation and test provide novel and useful data
for game development? Journal of Usability Studies (2006), 64–75.
[35] Lemay, P. Developing a pattern language for flow experiences in video games. In
Situated Play, Proceedings of DiGRA 2007 Conference (2007).
[36] Lindgaard, G., and Dudek, C. What is this evasive beast we call user satisfaction?
Interacting with Computers 15, 3 (2003), 429–452.
[37] Löwgren, J., and Stolterman, E. Design av informationsteknik - materialet
utan egenskaper. Studentlitteratur, 1998.
[38] McShaffry, M. Game Coding Complete. J Wiley & Sons, 2002.
[39] Medlock, M. C., Wixon, D., Terrano, M., Romero, R. L., and Fulton,
B. Using the RITE method to improve products; a definition and a case study. In
Humanizing Design, Usability Professional’s Association 2002 Annual Conference
(2002), UPA.
[40] Morgan, D. L. Focus Groups. Annual Reviews in Sociology 22, 1 (1996), 129–152.
[41] Mylopoulos, J., Chung, L., and Nixon, B. Representing and using nonfunctional
requirements: a process-oriented approach. IEEE Transactions on Software
Engineering 18, 6 (1992), 483–497.
[42] Nielsen, J. How to conduct a heuristic evaluation. This is an electronic document.
Date retrieved: January 12, 2009.
[43] Nielsen, J. Usability Engineering. Academic Press, 1993.
[44] Nielsen, J. Guerrilla hci: Using discount usability engineering to penetrate the
intimidation barrier, 1994. This is an electronic document. Date of publication:
January 1, 1994. Date retrieved: January 12, 2009. Date last modified: January 1,
1994.

112 REFERENCES
[45] Nixon, B. Management of Performance Requirements for Information Systems.
IEEE Transactions On Software Engineering (2000), 1122–1146.
[46] Nuseibeh, B., and Easterbrook, S. Requirements engineering: a roadmap.
Proceedings of the Conference on The Future of Software Engineering (2000), 35–
46.
[47] Paech, B., and Kerkow, D. Non-Functional requirements engineering-Quality is
essential. 10th Anniversary International Workshop on Requirements Engineering:
Foundation for Software Quality (2004).
[48] Pagulayan, R. J., Keeker, K., Wixon, D., Romero, R. L., and Fuller,
T. User-centered design in games. The human-computer interaction handbook:
fundamentals, evolving technologies and emerging applications (2003), 883–906.
[49] Parnes, S. J. Effects of extended effort in creative problem solving. Journal of
Educational Psychology 52, 3 (1961), 117–122.
[50] Pinelle, D., Wong, N., and Stach, T. Heuristic evaluation for games: usability
principles for video game design. In CHI ’08: Proceeding of the twenty-sixth annual
SIGCHI conference on Human factors in computing systems (New York, NY, USA,
2008), ACM, pp. 1453–1462.
[51] Poels, K., de Kort, Y., and Ijsselsteijn, W. ”It is always a lot of fun!”:
exploring dimensions of digital game experience using focus group methodology. In
Proceedings of the 2007 conference on Future Play (2007), pp. 83–89.
[52] Preece, J., Rogers, Y., and Sharp, H. Interaction Design: Beyond Human-
Computer Interaction. Wiley, 2002.
[53] Taylor, A. IT projects: sink or swim. ITNOW 42, 1 (2000), 24–26.
[54] van Lamsweerde, A. Requirements engineering in the year 00: a research perspective.
Proceedings of the 22nd international conference on Software engineering
(2000), 5–19.
[55] Wilson, C. E. Brainstorming pitfalls and best practices. interactions 13, 5 (2006),
50–63.
[56] Yan, J., and Randell, B. A systematic classification of cheating in online games.
In NetGames ’05: Proceedings of 4th ACM SIGCOMM workshop on Network and
system support for games (New York, NY, USA, 2005), ACM, pp. 1–9.

Appendices
113

Appendix A
Pre-prototype game
specification
The game
The game is an online strategy game played in a persistent world by many players. The
world is tile based and each tile is of a certain terrain type which can hold one resource,
city or other constructions (some constructions can share tiles while others cannot).
It is not possible for players to be completely annihilated. Instead, if their last city is
taken, they get the option to move to another location. When doing so they retain their
technological advancements as well as some resources and even all manpower (though
some manpower has probably disappeared since it is likely that a large part of their
army has been wiped out).
The game consists of a few basic parts that each player can control. These are:
– Cities
– Resources
– Family and family members
– Armies
– Research
– Trade
– Diplomacy
All of these parts are accessible through the games interface. How and what the player
controls for each part will be explained in further detail below.
115

116 Chapter A. Pre-prototype game specification
Timescale
The timescale of the game is that approximately 24 hours in real life equals 6 months
in the game.
A battle will take approximately 1 hour (though with variations depending on the size
of the smallest side of the battle).
Taking full control of a city will take approximately 3 days.
Family members will live for approximately 30 years, but they will only be possible to
take control of after they have reached the age of 16 making the playable time with a
family member about 1 month. The lifespan can be increased through research.
It should take about 4 hours to move through an area in enemy territory (an area can
consist of several tiles). This means that it should take a minimum of 4 hours from the
declaration of war until someone can attack a city.
Fog of War
The game includes “fog of war” which in this case only makes tiles that the player are
able to see at any specific time entirely visible (the terrain of previously seen tiles is still
visible, but armies, cities and so on can only be seen if there is a unit or building close
enough to actually see it). The fog of war should fade into the graphical style of an old
map while tiles that can be fully seen is more detailed (with color etc.).
Events
Events are things that occur in the game that players cannot decide whether or not they
should happen (they could however be triggered by player actions). One must be very
careful to not introduce events that punish players randomly (some sort of heads up is
required). Events could be:
– The birth of a holy person (i.e. making a place more valuable).
– The appearance of an evil dragon.
– The birth of an island.
– Famine.
– Good years.
– Large battles (or other events) can trigger tiles to become holy (thus making it
more valuable).
The game has to allow for the possibility of including such events.

117
Goals and endings
The game is played over an extended period of time and there is no defined end. To
ensure that the game stays interesting expansions are to be released on a regular basis.
These expansions will provide the players with more technologies to research, resources
to gather and so on. Because the game is based on continuous expansions all options (in
terms of research, technologies, resources and so on) can not be visible for the players
when starting out. There should however be a hint of an end, where each expansion
implies that the ending is drawing nearer. Each expansion also delivers the story of the
world to date.
Highscore
The players highscores (based on the prestige of the families, see Family and family
members, Prestige) are stored in two lists. One list represents the combined prestige of
the family, all players are visible in this list. The other list is divided into a list for each
category of prestige, players can only see their own position in this list. The top 10 of
each list is however also visible to all players.
There is also an additional list for each category of prestige where the all time top three
players are listed (that is, the best three scores ever recorded in every category is listed).
Cities
Each player controls a number of cities. Each city that a player controls has to have a
family member connected to it if the player is to be able to fully control the city. The
primary purpose of a city is to provide the player with manpower. Manpower can then
be used to:
– Create/reinforce armies
– Gather or refine resources
– Conduct research.
To get additional cities a player can conquer cities (see Conquest and expansion, conquering
cities) or build cities. In both cases the player needs at least one family member
that can be connected to the new city (i.e. the city, to which the family member in
question is connected to, has to have at least one other family member connected to it).
There is also a cost in manpower and resources to construct a new city.
Buildings
It is possible to construct buildings within a city. Each building gives a bonus to some
area or makes new build options available. It is possible to queue the buildings that are
to be built (though the queue has a limited number of buildings that it can hold) so a
player can order the construction of a couple of buildings and then log out.

118 Chapter A. Pre-prototype game specification
Population
Each city has a certain population and a large population contributes with a large
amount of manpower. The population in each city can consist of one or many of the
different races available in the game. The population growth depends on how developed
the city is and how much food and other similar resources the city has available. The
amount of food that a city needs depends on the surrounding environments. If for
example a city is located in the mountains the cost to feed each unit of population is
higher than if the city is located in a more fertile surrounding.
Attraction
Each city has an attraction level for each individual race and this affects how much of
the population growth that comes from each race. Population can also move between
cities if they are close enough to another city that has a higher attraction level than
their current city.
The attraction level for a city is affected by different buildings in the city, these buildings
can however require different luxury items to function. Different luxury items and
building affect different races differently. Some buildings raise the attraction level for
one race and at the same time lower the attraction level for another race.
Demand for resources
To expand the city needs food. If the city has all the food it needs for feeding the current
population, any surplus would generate a population growth (the more surplus in food
there is, the greater the population growth, as long as the population limit has not been
reached). The amount of food a city gets has to be assigned by the player. The amount
of food a city needs is defined by its surrounding terrain. If there are a lot of mountains
etc. the cost to feed the city is higher. This is represented by having a greater demand
for food for each citizen.
The luxury resources work in a similar fashion as the demand for food, but here the
buildings that use the luxury items define how much of the resource is needed. If a
building does not get all the luxury items it needs to keep running, it simply stops and
does no longer give its bonus.
A player can assign more resources than he gets per time unit if he has a stock of the
resource. If the player runs out of that resource however the cities will no longer get
the resources they need. In this case the capital city is always prioritized and thus gets
as much as needed. Any remaining resources will then be distributed between the other
cities.
Races
The game contains seven fantasy races (even though the races are not decided yet,
the classical example would be dwarfs, elves, orcs and so on). They all have different

119
strengths and weaknesses (except for the human race which has no particular strengths
or weaknesses). The player chooses a race for his/her family in the beginning of the
game. Through interracial marriage the players family can change race (although of
course only the child from an interracial marriage is affected). The population in the
cities of the world also consist of these races and thus contribute with different types of
manpower (discussed in Cities).
The races in this game will not be defined as good or evil, but rather just have different
strengths and weaknesses.
Resources
To have access to and to be able to gather resources is vital in the game. The resources
feed cities as well as provide the means to be able to build armies and buildings.
There are several different resources. Some are basic resources needed to feed cities and
build basic buildings etc. These can for instance be food, wood, stone and so on, this
kind of resources can be found all over the world. There are however also more rare
resources. These can be used as luxury items that raise the attraction level for cities as
well as enabling the building of more advanced troops and buildings (including buildings
that give a bonus to research). The more rare resources are also unique (or at least more
common) to certain areas (it might for example only be possible to find diamonds in
the south or spices in the east).
Some resources can be refined or combined with other resources to create better/more
specialised resources. This is done in factories in cities.
To be able to gather resources a player has to assign manpower to a place that has the
resource in question. The player also need to build a building on the site of the resource
to be able to gather it (i.e. build a building that the player assigns manpower to) and
the building has to be connected to a city via a road. Resources cannot be depleted,
there is however a limitation in the quantity that can be gathered per time unit (larger
buildings with more assigned manpower of course gathers more resources than smaller
ones with less assigned manpower).
The resources a player gathers are available to use anywhere, that is, the resources are
not connected to any one city, thus alleviating the need to transport resources between
cities that a player owns.
To be able to use all resources players have to research technology to “understand” the
resources. A resource that a player has not “discovered” yet is not visible to the player.
Family and family members
Each player plays a unique family, i.e. the player takes control of a family and its
members. The family always has a “head of the family” that is the most powerful and
important character in the family. The city to which the head of the family is connected
is the players’ capital city. The player can choose freely which family member who
should inherit the throne when the head of the family dies.

120 Chapter A. Pre-prototype game specification
When beginning the game the player has to chose what race the family should start out
as (though this can change over time through marriage and reproduction).
Since it is impossible to take over or build a new city without a family member that
is not connected to another city the family members work as a limitation to how large
a players’ empire can grow. This works by always having a limit to how many family
members a player can control at any single time (the player can conduct research that
increases the limit on family members). Each family member has to be connected to a
city; there can however be more than one family member in each city.
Prestige
Each player has a score that depends on the collective prestige of the family. Each
family member thus has a prestige score that adds to the collective prestige. The
prestige depends on what the family member accomplishes. A family member that wins
a great battle against a superior army might for example get a lot of prestige. It is also
possible to get prestige while contributing to research or attraction and so on.
The prestige is categorised. That is, a family member gets high “battle prestige” for
winning many battles. They can also get “science prestige” or “cultural prestige” where
“science prestige” increases if the family member contributes to scientific discoveries and
“cultural prestige” increases if the family contributes to a city’s attraction level and the
city attracts a certain amount of people.
The prestige is larger than the sum of the family members’ individual prestige (such
things as the players’ wealth or scientific achievements is not directly coupled to an
individual family member but are still included in the collective prestige).
When declaring war a player looses prestige (the loss is greater if the player attacks
a significantly weaker player), this prestige loss is coupled to the general (i.e. family
member) that leads the army that triggers the declaration of war or, if there is no general
in the army, to the head of the family. This works for each situation where there is no
leader for an army (such as when winning great battles), i.e. the head of the family gets
prestige that a leader should have gotten (though not as much, the amount of prestige
loss for a declaration of war is however the same).
Reputation
Each family member has a reputation that corresponds to his/her actions. This reputation
can then result in different “titles”. If a family member for example is involved
in a lot of victorious battles he/she might get the title “the conqueror”. In contrast, a
family member that spends most of his/her time in a city adding to the attraction level
might get the title “the fair”.
Life and death
Each family member has a certain life span. This means that after a while he or she will
die. This ensures that no single player can have the highest score at all times and thus

121
the leader boards will always be in motion. The player will also get new family members
to control; this is of course represented by the family members having children. This
means that if the highest amount of family members a player can have is five, then the
player might actually have less family members at any given time (though not a lot less
and not for too long a time). It should however not be possible to kill other players
family members as this simply makes too much of an impact.
A family member always has a minimum age that it will live, after that age there will
be a risk that the family member dies for each successive year. This risk also increases
with each successive year.
Development
The family members can become better in different areas over time. This is represented
by experience that the player can distribute on the different attributes that a family
member has. The experience of a family member increases at a certain rate over time.
The family members also gets extra experience if they accomplish something significant
(such as being a part of discovering a new technology, winning a great battle, raising
the population of a city and so on). A family member needs more and more experience
to get better.
Usage
The family members can be used in the cities that they are linked to by focusing their
efforts on an area of the players’ choice. This could be to raise the attraction level,
making the city more productive and so on. The family members can also be used as
generals in an army (they are however still linked to a city and represented as focusing
on military). Here the family member gives a bonus to morale, strength, defence or even
perhaps to the AI (meaning that it is better at adapting to the current situation on the
battle field).
Marriage
To be able to have children the family members must marry. Players can marry their
family members to other players’ family members, which would result in a prestige
bonus (for the children). If the player does not marry their family member in time
(i.e. if the family member reaches a certain age) it is automatically married to a nonplaying
character (which would result in the child not getting any prestige bonus, but
still enabling the family line to prevail). To be able to marry off family members some
sort of “dating service” or “market” for available family members must be included.
Only humans can marry all races. The other races can only marry a subset of the races.
Family history
Throughout the game a family history will be created automatically. All kinds of statistics
and data, such as the great deeds mentioned under Prestige, will be recorded and

122 Chapter A. Pre-prototype game specification
described in text. The player can, at any time, access this information. The family
history will also contain a family tree where each family member and their relation to
the family is recorded. The connection to other players’ families (through marriage) is
also shown here.
Armies
The player can of course have armies at his/her disposal. These can be created by
assigning manpower to the army. Armies can be used to defend cities, attack other
armies and plunder or taking over cities or land. The armies need manpower (which
adds to the overall limitation of how much manpower a player can have) which limits
the amount and the size of the armies.
Leaders
The army can have a leader assigned to it (i.e. a family member). This leader can boost
the stats of the army (such as morale, strength, defence and so on) depending on how
good the general is. It is also possible that the general enhances the AI for the army
(meaning that it is better at adapting to the current situation on the battlefield).
Units
An army can consist of many different units. The units have different strengths and
weaknesses and they are also affected by terrain to different degrees. There are different
types of units for example cavalry, infantry, archers, artillery and so on. These groups
can also be further defined (i.e. cavalry could be heavy or light or dragoons and so on)
by researching more advanced or varied versions of the unit. The kind of units that are
available for a player is defined by what the player has researched and also what kind
of resources the player has available.
Units are “built” in cities and they cost manpower and other resources. The amount
of manpower and resources (as well as which resources are needed) is defined by the
unit type. Each unit has strength and morale levels as well as other stats defining their
strength and weaknesses. When the strength reaches zero, the unit dies. When the
morale reaches zero the unit flees.
Each unit takes some time to finish training. The time required depends on how well
trained the unit should be (that is, how many possible battle orders it can receive as
well as how many terrain types it should get bonuses in and so on).
Some units can be harder to spot than others, this is represented by training units
to make use of camouflage. This is represented by the enemy not being able to see
them until they are very close. If a unit without camouflage abilities is in the same
army as a unit with such abilities, the army becomes visible just as if it was just units
without camouflage in the army. It is not however possible to sneak into enemy territory
without declaring war even though the unit trying to go into the land of the enemy is
camouflaged.

123
Units can get experience from battles and thus become better if they survive many
battles (represented by better morale and other stats). If the entire unit is killed it is
not possible to get it back, but if it only has its strength weakened it can be reinforced.
The cost of reinforcements is cheaper on land owned by the player controlling the army
than in enemy held or neutral territory.
Conquest and expansion
The players can expand their territory by conquering both land and cities. It is also
possible to construct buildings (forts) and new cities (as long as the player has enough
family members) that expand the territory.
Conquering land
Each city has an area around it that defines what a player can own in terms of land.
The size of the area depends on the size of the city as well as how developed it is (i.e.
certain buildings can give a bonus). If the land in the area is neutral it automatically
becomes the player’s land. All land that is owned by another player must however be
taken over by military force or negotiated/sold. To take over a land by military force a
player simply moves an army to that tile and defeats any army that stands on that tile.
The tile must also be within the area that a player can own.
It is possible to own land outside of the city-defined areas. This is done by building
forts that in themselves also have an area within which the player can get control of land
(this works in the same way as with the cities). The areas are however smaller than the
city-areas and there is also a limit to how far from a city a fort can be built. Family
members cannot be assigned to forts. Forts give a bonus to any defending army on that
tile. In the same way as resource gathering buildings (discussed under Resources) the
fort has to be connected to a city via a road to function.
Conquering cities
Cities can only be conquered by military force. This is done by defeating any defending
armies located in the city. It also takes a significant amount of time (much longer than
a normal battle) to get complete control over the city.
When a city is conquered any resource gathering building that is no longer under the area
which the former owner can control (see conquering land) is destroyed. Each building
(built by the player) within the city also has a risk of being destroyed.
The player loosing a city will not loose any of the manpower that has been acquired
from that city (nor will he loose any other resources available to him), the limitation in
manpower will however decrease (thus it is possible to have more manpower than what
the limit allows, but as long as the manpower is higher than the limit the player will
not get any more manpower).

124 Chapter A. Pre-prototype game specification
Battles
The battles are played out between AI and it is thus not possible for players to directly
influence the battles (see Battle orders). The player can however see the result of battles
“live” and through replays. It is also possible to get a summary for the results of the
battle. All battles takes some time to actually finish, this ensures that additional armies
can join the battle either to support one side or simply to attack every other army in
the battle. The time required to finish a battle depends on the amount of soldiers in
the smallest army (or side) in the battle.
If an army looses a battle but is not completely annihilated (the complete annihilation
of an army is rare) it will flee to the best possible (in terms of terrain bonuses) adjacent
tile closest to a friendly city.
There are two reasons to why an army could flee. The first is if the strength of the army
gets lower than a predefined value (set by the player, this is called retreating) and the
other is if the morale of the army drops to low. The level of morale that is required for
the army to stand fast depends on the leader of the army. The morale drops when units
within the army are killed (or looses strength), when units get attacked from the rear or
flanks, when units gets attacked by superior units or if the enemy fields an impressive
unit (such as a dragon).
If the army retreats to a tile that supplies the army with a significant enough bonus it
might fight again if attacked.
To prevent that players “scout” enemy armies by attacking them with a single weak
and cheap unit, at least one unit has to survive the battle for the player to get any
information about it (more than just that it took place and that the player lost).
Capturing family members
If the unit that a family member is connected to (this would be some sort of elite unit,
for example the family members personal guard) is wiped out the family member gets
captured. The player who captures the family member can decide what to do with it
(though it is not possible, in any way, to kill an enemy family member). The options
are (followed by what the capturing player gains):
– Set the family member free (prestige, reputation goes toward benevolent)
– Demand ransom (a predefined value of a resource chosen by the capturing player,
reputation goes toward greedy)
– Disgrace (the captured family member looses prestige, reputation goes toward
nasty)
– Torture for information (the capturing player has a chance of gaining a technology
that the captured player has researched, reputation goes toward bloodthirsty)

125
Battle orders
A player can set battle orders for each army and for each unit within the army. The
battle orders tells the army how it should behave in a battle as well as how their initial
formation should be. This is however not a fixed behaviour but rather an initial idea
of what the army should try to do. The AI is in charge of trying to “make the best of
the situation” given the initial orders set by the player and the size, composition and
tactics of the opposing force.
A player can conduct research to get access to more advanced battle orders and formations.
The more advanced alternatives are however not a certain way to get a better
army but rather just a way for the player to be able to influence the army in more detail.
It is also possible to set the overall behaviour of the army. This could be to hold its
ground, meaning that it will not move for anything, attack any enemy army in sight,
go to a location without attacking, go to a location and attacking everything in its way
and so on.
Attacking cities
When starting an attack on a city a player has a choice of pillaging, burning or taking
control over the city (if there is any family member that can be assigned to the city).
Pillaging is the easiest to accomplish and to take control of the city is the hardest to
accomplish. The following happens if the player succeeds:
– If the player pillages the city the steals some resources.
– If the player chooses to burn the city each building within the city also has a quite
large risk of being destroyed.
– If the player chooses to take control over the city (can only be chosen if there is a
free family member), the defeated player then chooses what will happen:
• The defeated family member(s) stays in the city as vassal and pays tax to
the conquering player.
• The defeated family member(s) become partisans and tries to work against
any productivity within the city (this includes any resource gathering within
the area of the city). If this is continues for long enough and has a large
enough impact the conquering player can give the city back to the defeated
player.
• The defeated family member(s) chooses to abandon the city and settle somewhere
else. In this case the conquering player gets full control over the city
with no limitations.
These options work in the written order so that you can always go down a level but
never up (for example; it’s possible to be a vassal and at any time choose to become a
partisan or abandoning the city, but not the other way around).
If an additional army attacks a city that is already under attack (that is, if someone has
ordered to attack the city and chosen to try to take control over the city) the new army

126 Chapter A. Pre-prototype game specification
can choose to support the attack, the defender, try to attack the city for themselves
(any of the ways of attacking is possible, but this means that the army has to attack all
armies already battling for the city) or to withdraw.
Each successful attack on a city will decrease its population to a certain degree, where
the burning of a city of decreases the population more than the plundering of a city.
To completely take control over a city takes a lot of time. If it is achieved (including
if the conquered player stays as a partisan) the conquered player is presented with the
alternative to burn the city themselves or leave it intact. To burn the city will destroy
a large number of buildings and also kill a lot of the population. This is of course a way
to prevent the conquering player from gaining too much. The chosen action of course
affects the family members’ reputation.
Research
By assigning manpower to research the player can improve his/her empire in different
areas. There are several different areas in which research is possible. Each area can be
seen as a stem (with branches) in the technology tree. To assure that new players don’t
get left to far behind each player that has researched a certain technology in a stem
makes it easier for the next player to research that technology (i.e. for each player that
has researched a technology in a stem the shorter the research time for that technology
gets). This applies only to technologies in the different stems and not in their branches.
Technologies in the branches are more “applied technology” than the stem technologies
which are more basic research that might not be possible to use directly.
The following things are examples of what can be researched (they are not however
necessarily stems in the technology tree):
– Military (new/improved units, more advanced battle orders)
– Trade (less loss per distance, possibility to trade over longer distances)
– City development (attraction level, capacity and so on)
– Production (resource gathering/refining, shortened building times)
– Research (faster research)
– Family development (longer life span, larger family, more experience)
Trade
To get access to all resources the player will have to trade. If a player needs more food
to feed his/her large cities it is of course also possible to trade such resources.
To be able to trade the player has to research the first level of trade in the technology
tree. When this is done the player can build a basic trading post which enables the
player to trade with other players in his/her vicinity. This is done by defining an offer

127
to buy or sell a certain amount of a resource at a certain price (for example [buy 1000
wood for 100 gold]). It is of course also possible to see other players’ offers and accepting
them to buy or sell resources.
The level of researched trade defines how “far” the player is able to trade. Each successive
level of trade research lessens the amount of loss per distance between the two
trading players’ capitals or gives the player access to buildings that lessens this loss. If
the loss is over a certain amount the player cannot see the other players offer to buy
or sell. The loss is always calculated from the perspective of the player with the most
advanced trading technology, but it is always paid by the player who confirms the deal
(i.e. the player that accepts another players offer to buy or sell).
It is also possible to set up running deals with other players. These deals can take the
form of [buy 10 wood/hour for 1 gold/hour for 10 hours]. If war breaks out between the
players this kind of deal would of course cease to function.
In the prototype trade will work by exchanging resources (i.e. there will not be a
currency for which the players can trade all resources). If this becomes too complicated,
there might be a need to introduce currency in the final design of the game. There will
not be any cost in time to conduct trade either.
Diplomacy
As a major part of the game is interaction with other players diplomacy is of course
essential. There are essentially three states between players: neutral, alliance and war.
There is always a penalty in prestige to declare war on another player (if the player that
declares war is much stronger than the player upon whom war is declared the prestige
loss is far more significant than if the players are of similar strength), but this can of
course be remedied by conquering land or cities.
When players are in a state of war (which happens if a player attacks another player)
attacks can be made without any loss of prestige.
Communication
There are several ways of communicating between players. If players are not in an
alliance of any sort, the only way of communicating is by sending messages. These
messages can only be sent to one player at a time, but does not require any time to
arrive or any other limitation.
In alliances (though not in non-aggression pacts, see Alliances) there is a form of
“alliance-chat” where players can communicate with all other players within the alliance.
There is also a forum for each alliance.
Alliances
Alliances can be of three types: non-aggression pacts, military alliances and “guilds”.
If two players have agreed to a non-aggression pact it means that a player that attacks

128 Chapter A. Pre-prototype game specification
the other player suffers a significant prestige loss. If two players are in a military
alliance and one player gets attacked by a third player it means that both players in the
alliance will become in a state of war (without any loss of prestige) towards the attacking
player (as opposed to only the attacked player becoming in a state of war towards the
attacker if there is no alliance in play). Of course there will also be a significant prestige
loss if a player attacks another player that he/she is allied with. Guilds are a more
loosely defined alliance where the players themselves can define the rules for the alliance
(the rules for non-aggression pacts and military alliances are possible to use, but not
necessary). Players set the rules by selecting from drop-down lists or checkboxes which
means that the game can keep track of the players and if they break the alliance or not
(the rules can define who can join, who can start wars, if it is a democratic alliance,
who leads the alliance and so on). What this means is that non-aggression pacts and
military alliances are only predefined lighter versions of a guild.
It is possible for alliances to be allied with other alliances.
The basic alliances (non-aggression and military) are possible to limit in time (for example
it might be possible to agree that a non-aggression pact should hold for one
week).

Appendix B
Enkät
Vi är två Interaktion & Design-studenter som gör ett exjobb där vi ska utveckla en
prototyp för ett datorspel. Denna enkät syftar till att fånga intressanta aspekter kring
liknande spel.
Var gärna så utförlig som möjligt i dina svar.
Nämn ett strategispel som du anser är bra. “Strategispel” kan i det här fallet
vara både turordningsbaserade spel och realtidsspel. Har du ej spelat något strategispel
så kan du lämna delarna som berör sådana spel tomma.
Nämn ett onlinespel som du anser är bra. “Onlinespel” syftar på spel som enbart
spelas online och innehåller någon form av interaktion med andra spelare (behöver ej
vara ett strategispel). Har du ej spelat något onlinespel så kan du lämna delarna som
berör sådana spel tomma.
Vad är de centrala delarna i de spel du angivit, vad går spelen ut på?
Strategi:
Online:
129

130 Chapter B. Enkät
Vad/vilka delar gör spelen bra? Var detaljerad, exemplifiera gärna.
Strategi:
Online:
Finns det några mindre positiva aspekter av spelen?
Strategi:
Online:
Tack för din medverkan!

Appendix C
Manus till
brainstormingsession
Introduktion
Hej vi heter Andreas och Anders, och vi håller på med ett exjobb där vi ska utveckla
och utvärdera en prototyp för ett spel.
Vi har bjudit in er för att vi vill veta vad ni vill ha i ett spel. Ni ska alltså bidra med
idéer och input.
Innan vi börjar tänkte vi berätta lite om hur det hela kommer att gå till. Ni kommer att
brainstorma genom att först sitta i några minuter och skriva ner alla era idéer på post-it
lappar, gärna en idé per lapp. Det är viktigt här att ni skriver ner alla idéer, försök att
inte döma på förhand. Sedan kommer vi att tillsammans titta på alla era idéer och då
får ni en chans att förklara närmare vad de går ut på. Det är även här viktigt att man
inte dömer varandra. I detta skede finns inga dåliga idéer. Det vi är ute efter är många
idéer.
Sedan kommer processen att upprepas i en till kortare brainstorm där vi försöker
utveckla idéerna ytterligare.
I slutet kommer vi att diskutera vad vi kommit fram till samt några andra frågor.
Frågor så långt?
Brainstorm
Då sätter vi igång.
Spelet vi ska utveckla är ett strategiskt spel som utspelar sig i en beständig värld med
flera spelare. Det betyder att även om man är utloggad så kommer världen att finnas
kvar. I många onlinespel så försvinner spelaren från världen när denne loggar ut, men
här ska spelaren finnas kvar även när denne är utloggad.
131

132 Chapter C. Manus till brainstormingsession
Det ni ska skriva ner på lapparna är vad ni vill ha i detta spel (vad ska ingå, hur går
det till). Håll gärna en idé per lapp. Vi kör i ungefär fem minuter.
Frågor?
Sätt igång!

Appendix D
Resultat - brainstorm 1
Spår 1
00.34 - Deltagare 1: Rapportsystem (7000 råttor dödade m.m.). Man ska kolla på
all sorts möjlig “dum” statistik.
02.14 - Deltagare 2: Släktallianser, karaktärerna i ens familj finns med, lite hjälteaktigt.
Kan påverkas av hur spelaren spelar.
06.10 - Deltagare 3: Möjlighet att kombinera servrar. Möjlighet att “resa” mellan.
08.25 - Deltagare 1: Hjältar, i kombination med släkt kanske, dessa ska kunna utvecklas.
09.50 - ... : Öar, samma som 06.10 i princip.
10.25 - Deltagare 3: “Galaktiskt råd”, stort råd (som FN). AI. Politiskt spel, låter
inte folk anfalla eller hjälper till osv. “Jag blev bortbombad, kan ni hjälpa”.
“Pengar på onda spelares huvud”.
13.45 - Deltagare 1: Ej 3D. Ingen lyckas med 3D.
15.20 - Deltagare 2: Möjlighet att välja mellan olika raser, folkslag med olika stats
osv. Kan då kombineras med råd (för olika folk). Välja styrelseskick. Blodslinjen
är en ras (kan mixas), städer kan innehålla olika raser ,men kan också stoppa tex
alver från att komma in.
21.52 - Deltagare 3: Flera “lager”, under jord, ovan jord, luft och omloppsbana.
24.50 - Deltagare 1: Multiplattform, stöd för linux, webbaserat och klientbaserat.
Lite mer “light” på webben.
26.10 - Deltagare 1: Konfigurerbart UI, färger, positioner m.m.
28.02 - Deltagare 2: Bygg och utveckla, resursförvaltning och forskning.
28.55 - Deltagare 3: Politiskt. Inte bara “bråka” med arméer. Stoppa tex tekniker
med politik, ej längre lagligt med viss forskning. Kan finnas hemlig forskning.
133

134 Chapter D. Resultat - brainstorm 1
31.00 - Deltagare 1: Lika utveckling. Skillnader mellan spelare (en med raketer, annan
med klubbor) Olika vägar att gå teknologiskt (teknoligiträd). Lägg in “skum”
forskning, magi tex.
34.45 - Deltagare 3: Sändebud mellan spelare. Chatt med sina vänner, men fördröjning
mellan andra. Stoppbara sändebud, få tillbaka huvud.
35.55 - Deltagare 1: Inga fasta sidor Goda orcher. Hur man spelar definierar om man
är ond eller god. “Ett steg mot god och neutral” (Baldurs Gate).
Paus.
Spår 2
00.00 - Deltagare 1: Konstanta uppdateringar, nytt innehåll, nya områden, bättre
balans. Bra respons till spelare. Håll koll på forum och vad folk vill ha.
01.48 - Deltagare 3: AI tar över när “jag” är borta. Man kan ställa in ungefär hur
det ska reagera. Kan forska fram mer avancerade alternativ - Fler, bättre macron.
Även playorders/battleplans. Långsiktiga mål, sätt prioritet.
06.33 - Deltagare 1: Expandera. “Hus i städer i världen”. Man ska kunna se hur
andras städer ser ut. Gärna kunna gå omkring i dem.
10.04 - Deltagare 3: Ena galaxen. Kan vara spelets mål, mål är viktigt. Få alla
under samma flagga (vilket är uppfyllt när alla samarbetar och det ej längre är
något bråk).
ca 13 Diskussion om skala. Förslag om att man kan “växa ur sin region” (sandlåda
- bakgård - kvarter osv. Varje kvarter innehåller ett antal bakgårdar som i sin
tur innehåller ett antal sandlådor). Man kan aldrig bli av med sista sandlådan
i sin bakgård eller sin sista bakgård när man är i kvartersskalan. Alternativt
partisanverksamhet eller dra vidare till nytt område.
27.12 - Deltagare 2: Handel mellan spelare ska påverka mer än i andra spel. Det ska
vara möjligt att det går bra utan att man strider. Man ska inte ha tillgång till alla
material. Gotland måste tex. importera skog (eller expandera). I princip krav
på handel. Resurser kan kanske “växa” tillbaka långsamt. För hård produktion
tömmer resurser (kalhyggen, utarmad jord osv.). Upkeep på soldater.
34.30 - Deltagare 3: Starcraft/warcraft-grafiskt. Möjlighet att både se strider och att
bara få en sammanfattning (“Battle reports”). Stora strider (med många soldater)
ska ta längre tid. Det ger möjlighet för andra spelare att lägga sig i under tiden.
Möjlighet att zooma in på striderna (och allt annat).
40.27 - Deltagare 1: Nedladdningsbart. Köp inga skivor.
41.10 - Deltagare 1: Inget slut. Lägg till mer tekniker i trädet i expansioner. När
någon nått max ska nästa expansion komma. Först finns slott, sedan nästa steg
osv. Låg nivå först. Döljer även trädet vilket är bra (man kan inte planera exakt
hur man ska göra hur långt fram som helst).

135
47.30 - Deltagare 1: Växande värld beroende på spelarna.
48.44 - Deltagare 3: Fantasy & sci-fi. Börja tidigt och gå mot teknik/magi/osv.
Olika för olika raser. Kan vara evolution för vissa och teknik för andra.
50.30 - Deltagare 1: Möjligt att spela som casual gamers. Teknik och “superskölden
för min hjälte” ska ej försvinna.
52.40 - Deltagare 3: Guilds. Stor fördel av att vara i grupper. Dessa kan hjälpas åt
för försvar och liknande. Bonusar, förvarningar, extra röster för guilds, “Han-ochjag-slåss-mot-den-som-är-allierad-med-den”
(tänk andra världskriget). Mer än en
sorts allians: handels, icke aggressionspakt med mera.
1.00.10 - Deltagare 1: PvE, PvP. Uppror, quest for glory. Om inte annat bra för att
testa. Utbrytarstäder kan också dyka upp osv.
Paus.
Spår 3
00.00 - Deltagare 3: Mycket bakgrund “fluff”. Ska finnas för den som vill veta.
“Döda 10 råttor” och “Det var en gång...”, båda alternativen ska finnas. Uppdrag
skulle vara skoj. Quest inom olika saker, tex. strid, produktion, teknik osv.
Rådet kan ge quests. “Spelare x är griever, rådet säger skicka två soldater och
attackera x till alla”. Spelar- och/eller admin-ledda events. Tex. admin säger
“kl. 17.00 är det världskrig” (kan vara frikopplat från resten av spelet). Vanliga
spelare ska kunna bygga quests. Råd är både AI och spelare.
09.20 - Deltagare 1: Smidiga kontroller. Inte tusen knappar på en gång. Använd
standardgrejer.
11.01 - Deltagare 3: Forskning.
11.12 - Deltagare 1:
Äga och skapa byggnader. Allianser kan äga städer.
13.18 - Deltagare 3: Man ska kunna spela ensam. Man ska ej bli påtvingad något.
18.01 - Deltagare 1: Olika kanaler för chat. Friendslist, guildchat, allianschat osv.
19.16 - Deltagare 1: Det bör inte finnas begränsningar. Spelsätt ska ej bli påtvingade.
21.01 - Deltagare 2: Man ser spelet från “guds perspektiv”. Tillsätter ledare osv.
(man styr familjen “från ovan”). Kanske är en gud. Kan lösa problemet med
spelare som slutar spela (guden dog, folk... brinner upp?).
23.45 - Deltagare 3: Designa sina trupper. Tank - mycket armor + stor kanon = dyr
och långsam.
Eftersnack
00.00: Råd + teknik är centrala. Bygg för expansioner. Lite i taget.
ca 04.00 Hur löser man att man har inget att göra?

136 Chapter D. Resultat - brainstorm 1

Appendix E
Resultat - brainstorm 2
Del 1 - Inledande brainstorm
Spår 1
00.24 - Deltagare 1: Teman. Strid, handel, resor. Man kan köra på olika teman
(samtidigt). Man ska kunna påverka karaktärer, miljön. Borde finnas ett stort mål
man arbetar mot (reset när målet uppnåtts). Exempel på sådant är olika sidor
som kämpar mot varandra. Kan ske genom övertagbara saker (del-/etappmål).
Även spännande för förlorande sida.
05.40 - Deltagare 2: Terräng gör inverkan.
06.30 - Deltagare 3: Micro och macro. Byggnader som ger plus. Mindre och större
mål.
08.35 - Deltagare 4: Tidsbegränsade karaktärer med ålder. Spelet tar slut eller att
det går upp och ner (inte samma personer på toppen hela tiden). Karaktärer dör,
men vissa saker ska man ha kvar (reinkarnation?).
Spår 2
00.00 - Deltagare 1: Ta land, resurser. Necromunda - 10-20 pers per område, hantera
ett lag, karaktärer gör det mer intressant. Något som byggs upp + taktik +
strategi. Guilder, klaner - Gemensamt försvar, territorium. Ansvaret för en
spelares “gubbe” kan tas över av någon annan medan spelaren är borta. Svårare
att ta död på någon som är utloggad.
06.40 - Deltagare 2: Realtidsstrategi / turnbaserat Playorders.
(10.30 - Deltagare 4:) Knåpa ihop strategier. Se hur striderna utspelar sig (replays?).
Begränsa interaktionen med utloggade spelare.
137

138 Chapter E. Resultat - brainstorm 2
12.43 - Deltagare 3: Slump. Lätt system för att förstå striderna, typ tärningssystem.
Synligt hur striderna går till. Mindre enheter ska kunna vinna mot större. Innebär
en risk även för de största. Budgivning på karaktärer, vapen. Marknad för
resurser. Köpa in bra soldater/hjältar. Man ska aldrig kunna dö helt.
17.40 - Deltagare 4: Mycket stats (är roligt). Färdigheter, egenskaper, stats för vapen
osv. Olika trupper är bra i olika terräng och situationer osv. “Har jag fördel och
hur kan jag få fördel?”. Besatthet vid stats (som en bra sak, folk kan ägna mycket
tid till dessa). Bygga upp egenskaper/färdigheter. Allt ska ha stats. Hjältar,
arméer mm. Erfarenhet och ledare för arméer.
22.38 - Deltagare 4: Wikipedia för världen. Uppslagsverk. Som visar stats och allt
(tänk civilopedia).
23.30 - Deltagare 1: Bakgrundshistoria. Möjlighet att påverka framtida historia. Se
hur storyn utvecklas. Både spelare och annat kan påverka. Om två sidor slåss
mot varandra så ska det verkligen puttas över till den enas fördel om dessa är på
väg att vinna, det ska synas i världen.
26.38 - Deltagare 1: Påverka andra spelare/påverka sina egna “grejer” (PvP/PvE).
Påverka andra är roligare. Påverka även världen. Total war “Execute them all”
påverkar karaktärer. Hur man spelar påverkar. Meka mycket med det egna är
också kul. Ska gå att spela på olika sätt.
31.00 - Alla : Handel, krig och annat. Inte bara krig! Skapande och handel är kul.
Res och sälj där de betalar bra. Allt ska inte finnas överallt, men en resurs (eller
liknande) ska ej påverka för mycket.
38.55 - Deltagare 3: RTS-syn. Bygg och utveckla ett område. Mål är att rankas
högst (highscore). Kan få bonus vid reset om man var bra (kan vara endast
visuell). Beskrivningar kan skilja, men stats ska betyda något.
Atombomb kan avsluta spelet. “Logisk reset”, ingen fast reset (dynamiskt). Antingen
“cykliskt” på toppen (ingen kan vara mäktigast jämt) eller reset. Man ska se
vem som är bäst just nu.
Spår 3
00.00 - Deltagare 4: Flera områden på flera olika servrar, interaktion dem emellan.
Världar interagerar med varandra. Land förklarar krig/handlar med andra länder.
Skillnad på förutsättningarna mellan olika världen (tex. olika resurser osv.).
Mångfald. Rymdspel är praktiskt för utforskning. Den som leder på servern
kan styra interaktionen med andra servrar.
05.30 - Deltagare 3: Talar i telefon...
06.16 - Deltagare 4: Guilds. En är kung till dess han/hon dör/avsätts. Röstning/starkast/äger
något särskilt kan avgöra vem som är kung. För stor makt för kungen kan vara
dåligt. Olika roller kan finnas (hierarkier/nivåer). Mycket makt måste innebära
mycket ansvar (“kungen måste kunna lynchas”).

139
Del 2 - Utveckling av idéer
Spår 4
00.00 - Deltagare 4: Olika resurser på olika planeter/världar. Även pengar kan skilja
(valutakurser). Ett antal resurser. Förädling och kombinering (smör + sirap =
(amerikansk) mat, där “+” kanske är en fabrik som kombinerar). Man ska kunna
välja vad man ska sälja för, sedan budgivning. Buy-out -¿ få resursen direkt om
man betalar dyrt. Byta en last x mot vara y. Resa iväg för att köpa/sälja.
06.40 - Deltagare 1: Karaktärsförbättring. Hamna först på highscore innan reset.
Flera sätt att ta sig framåt på. Se vem som ligger först (för att ej stödja). Får
kanske inte stå i detalj (score 39 kan vara både arméer och handelspoäng sammanslaget).
Svårt med direktkontakt för handel, marknad är lättare. “Jag vill
köpa mängd x av vara y om det kostar mindre än z”. Högst karisma kan få handla
först, “shopping skills”.
13.10 - Deltagare 2: Resor. Du måste upptäcka, kommer ej åt alla spelare direkt.
Sälja/byta kartor. Leta resurser, dessa syns ej direkt.
15.35 - Deltagare 3: Uppdrag. Introduktion i form av quests. “Döda x antal monster”.
Strid mot NPC:s som intro. Dessa intro-quests kan finnas för alla saker
(handel, diplomati etc.). Intro gärna utan att vara hotad av andra spelare i början.
Quests kan vara tillgängliga hela tiden. Även stora uppdrag “Drake anfaller stad”.
18.35 - Deltagare 4: Events. Sjukdomar, böldpest, “great year”. Båda bra och dåliga
(men “lagom” inverkan). Kan ske pga. Hårt uttnyttjade resurser eller byggande av
många fabriker/parker. Kan ske pga. hur man spelar. Kan påverka många (man
kan se hur folk beter sig när det dyker upp en gemensam fiende eller liknande).
Kungen kan i princip tvinga folk att skicka iväg soldater/han kan ej tvinga...
Kungen blir straffad för dåliga order.
26.02 - Deltagare 2: Flera karaktärer. En huvudkaraktär, men ha fler. En som styr
en armé, en handlare, en utforskare osv. Gangleader, ranker, hierarki även här.
Statbonus för ledaren. Lite kan föras över från död karaktär. Utveckling för
karaktärer på det dom gör. Hur du spelar ska påverka, “fega” karaktärer ska
överleva lättare, men de blir inte bra. Både strategi och rollspel. Historia bakom
karaktärer. Karaktärsutveckling är intressant.
35.54 - Deltagare 3: Ledarens ansvar att sätta upp tullar, vilka man handlar med
mm. Vapenindustrin kan ägas av “staten” så spelare blir involverade och får
något av staten. Subventionera saker så att han indirekt styr vad som produceras.
Valet att ställa sig utanför och ej stödja kungen.
ca 40: Kan man byta land? Skulle kunna gå, men måste finnas ett straff. Makt över
sitt eget område, men “styrs” av annan (tex. genom att man kan vara vasall).
“Vasall eller dö”. Kan bryta sig ur. Kontakt utan att vara social genom “färdiga
avtal”. Ledaren ställer in “ska få 10% av trupperna”, spelare ställer in “ska ge 5%
av trupperna”. Spelaren får då inte lika mycket av “the spoils of war”.
47.35 - Deltagare 4: Blandar 2d & 3d. Olika nivåer. Ledare och krig på stor skala
kan ha turnbaserat 2d. Varje härskare som skickar med trupper ser mer detaljer

140 Chapter E. Resultat - brainstorm 2
(3d) och styr mer i detalj.
inloggad.
Förvarning om när striderna sker så man kan vara
Spår 5
00.00 - Deltagare 4: Skapa nya byggnader, föremål, vapen. Designa själv så andra
kan se. Användargenererat innehåll. Black & White-stuket (är spelaren ond så
syns det). Inte bara ond eller god utan även mellanting. Bygg olika byggnader.
Kombinera byggnader. Enkla enheter kombineras ihop till mer komplexa.

Appendix F
Manus för diskussionsession
Spelet
– Onlinestrategispel
– Beständig värld
– När en spelare är utloggad finns spelarens rike & enheter kvar
– Många spelare (minst ett hundratal)
– Ska kunna fortsätta under lång tid (långt forskningsträd, genom expansioner)
Världen
– Består av land som är synligt på kartan
– Flera olika raser/kulturer
– Utspelar sig (eller börjar åtminstone) tidigt/fantasy
Spelaren kan interagera och styra
– Städer - skapa arméer, förädla resurser, forska
• Population - Manskap
• Olika raser/kulturer
• Attraktion
– Resurser
• Grundläggande finns överallt
• Lyxresurser på vissa ställen
• Kräver manskap för att utvinnas
141

142 Chapter F. Manus för diskussionsession
– Familj och familjemedlemmar
• Krävs för att styra städer, ger bonusar till städer
• Kan fungera som generaler
• Utvecklas med erfarenhet - ålder och bragder ger erfarenhet
• Prestige - spelarens poäng
• Rykte/titlar (Edward de Geers the bloodthirsty)
• Liv och död
• Giftermål för att få nya familjemedlemmar
• Familjehistoria skrivs automatiskt under spelets gång
– Arméer
• Manskap
• Olika enheter
• Battle orders
• Replays
–
Övertagande av städer
• Anfallaren kan välja att plundra, bränna, ta över osv.
• Den övertagna kan välja på att överge staden, bli partisan eller vasall.
• Om alla städer har blivit övertagna kan man helt enkelt flytta någon annanstans.
– Forskning
– Handel
• Kräver manskap
• Flera stammar med förgreningar
• Stöd för nya spelare, stammen går snabbare
• Trading posts
• Svinn
– Diplomati
• Olika situationer, krig, neutralitet, allians
• Olika kommunikationskanaler

Appendix G
Frågor som måste behandlas
Skala
– Hur ofta kan man förvänta sig att spelare loggar in?
– Vad ska rimligtvis hinna hända medan man är utloggad?
– Hur länge borde familjemedlemmarna leva?
– Hur länge ska en strid pågå?
– Hur lång tid ska en armé behöva för att förflytta sig över en kontinent?
Världen
– Ska det vara fantasy eller vad ska det egentligen vara?
Raser/Kulturer
– Ska det vara raser eller kulturer?
– Hur många olika?
– Vad ska skillnaderna vara?
– Bara populationen eller även familjer?
Giftermål och familjer
– Hur ska det ske?
– Mellan spelares familjemedlemmar (vilket innebär problem) eller bara med NPC:s?
• Om med spelare: Hur kontrollerar man vem som får barnen?
• Förlorar man karaktärer?
143

144 Chapter G. Frågor som måste behandlas
• Ska man kunna “blanda blod/raser”?
– Vilka ska ingå i familjen?
– Hur stor ska familjen vara?
– Hur förhindrar man att spelare får för många familjemedlemmar att styra?
Allianser
– Hur hårt ska de vara styrda? (Tillstånd i spelet vs. Hanterade av spelare)
– Vilka sorter ska finnas?
• Icke aggressions-pakt
• Militära allianser
• Handelsallianser
• Osv...
Råd
– Automatiskt med i (ett enskilt för varje ras/kultur)
– Kan fungera som
• Introduktion
• Bidra med uppdrag och events
• Militär hjälp till svaga spelare
• Resurser till svaga spelare
• Nya spelare kan vara under rådets beskydd
• Starta krig med andra råd/raser/kulturer
Ska detta finnas och vilka delar i så fall?
Händelser/Events
–
Är det viktigt?
Speltekniska aspekter
– Ska man kunna se alla alternativ även om de inte är tillgängliga än (t.ex. i forskningsträdet)?

145
Highscore
– Hur ska detta representeras?
• Ska man se alla spelare och vad de har hög poäng i (kan ge info om vem man
ska anfalla osv)?
• Ska man bara se top 10?
• Ska man bara se samlad poäng för alla “kategorier”?
Resurser
– Mat, hur ska detta fungera (i form av befolkningstillväxt/tak)?
• Som “vanlig” resurs?
• Knutet till staden, ger befolkningstillväxt beroende på hur området kring
staden ser ut?
Övertagande
– Hur ska områden tas över från andra spelare?
– Hur tar en spelare över neutrala områden?
• Markörer/fort (som ger några rutors area) som spelaren placerar ut/bygger
• Städer ger rutor att placera ut
• Ta över med militär
• Ta över med militär, men endast inom en radie definierad av storleken på
städerna (varje stad har ett eget område inom vilket spelaren kan ta över
områden, dessa områden kan överlappa). Städer kan dock tas över ändå,
dessa blir då “nollade” i form av sitt område som kan tas över, staden får
även det grundläggande området (1x1, 3x3 eller 5x5) övertaget. Den som blir
av med staden får behålla allt område som fortfarande är inom områden som
hans kvarvarande städer täcker. Allt annat område blir dock neutralt.

146 Chapter G. Frågor som måste behandlas

Appendix H
Annoterade idéer till spelet
Text i kursiv stil är kommentarer till idéerna. Siffror i parentes är betyg till idéerna där
1 är sämst och 5 är bäst.
Idéer i korthet
– Användning av rapportsystem. Spelarna ska kunna hitta all möjlig statistik om
hur de spelar. (5) Höjer fun-factor.
– “Samma värld”, alla ska kunna spela i samma värld som sina kompisar. Man ska
alltså inte behöva välja värld, eller server, när man börjar spela och vara fast på
den för evigt. För att få detta att fungera kan samma värld ha flera kontinenter
(eller planeter) på olika servrar. Spelare kan resa mellan servrar och även ha
resurser på flera olika servrar. På detta sätt kan man koppla på nya servrar till
samma värld när nya spelare anländer. (4) Stöder princip 1.
– Möjlighet att välja mellan olika raser och folkslag man ska spela med (detta blir
då den familj man spelar med, se nedan). Olika raser och folkslag ska ha olika
stats och ge bonus på olika saker. (3) Måste utvecklas, potentiellt bra.
– Flera “lager” som spelaren kan röra sig mellan. Även om spelet är i 2D så finns
diskreta lager i spelvärlden travade på varandra. Dessa lager skulle kunna vara
under jord, i berg, mark, luft och omloppsbana. (3) Kan vara bra, speciellt om
det kombineras med olika raser (dessa skulle då kunna bo i olika lager), men ej
nödvändigt. Kan bli svårt att överblicka.
– Stöd för flera plattformar. Det skulle även kunna vara så att man kan ladda ned
en tung klient där allt ingår, och är man på jobbet kan man surfa in på webbsidan
för att spela en lätt version av spelet. Denna skulle då vara utan grafik och
spelaren kan inte göra allting, kanske bara skicka och kolla meddelanden mellan
andra spelare. (3-4) Implementationsfråga.
– Konfigurerbart gränssnitt. Man ska själv kunna välja vilka knappar som gör vad.
Man ska även kunna bestämma layouten på elementen (karta, knappar, flikar
147

148 Chapter H. Annoterade idéer till spelet
m.m.) på skärmen. Man kanske också ska kunna välja vilka knappar som syns
i gränssnittet och vilka som finns i undermenyer beroende på spelstil (allt detta
kräver en rejäl inställningsmeny). (4) Kan höja usability. Implementationsfråga.
– Man ska kunna interagera med andra spelare på ett politiska plan, inte bara genom
att skicka arméer på dem. (5) Key feature.
– Det ska inte finnas en ond och en god sida. Olika raser ska bara ha olika egenskaper,
men sättet de spelas på bestäms av spelaren. Eventuellt kan ondska och godhet
representeras, men det är ändå spelarens handlingar som avgör var på skalan den
befinner sig. (5) Stöder princip 2.
– Spelaren är inte hjälplös när den är offline. Då tar en AI över och “spelar”. (3)
Stöder princip 3, men kräver mycket att implementera en AI. En AI kan ej heller
vara jämställd spelaren, dvs. kunna starta krig, rösta, handla mm. Kan dock bara
vara så att AI:n utför playorders och inte tar egna initiativ.
– Man ska kunna ställa in beteende på arméer och byggplaner. (4) Stöder princip
3. Se playorders.
– Skillnader i utseende för olika spelares städer/länder/arméer. Eventuellt genom
att spelaren får göra egna skins eller liknande. (3) Skillnader mellan arméer och
folkslag krävs för att man ska få en överblick, men möjligheten att definiera egna
skins kräver mycket implementation. Om andra spelare ska kunna se dem så krävs
det att någon måste godkänna dem för att inte det ska komma olämpligt material.
– Spelare ska ej kunna dö helt. Det ska ej heller vara möjligt att “mobba ut” svagare
spelare. (5) Se princip 4 och princip 5.
– När man börjar spela ska man inte kunna se alla alternativ och möjligheter som
man ej än kan utnyttja. (3) Höjer användbarheten om spelaren inte kan se alla
alternativ och byggnader som ännu inte är tillgängliga. Kan dock ändra sättet
spelet spelas på om spelaren inte kan planera långt i förväg för att denne inte
vet vad som kan göras senare i spelet. Därför måste man vara försiktig när man
döljer alternativ, även om de ej går att utnyttja. Är dock en balansfråga, om man
ser att man kan bygga dödslasrar under stenåldern så blir det ej heller realistiskt.
Något man också kan göra är att dölja föråldrad teknik, så att alternativet att
bygga blåsrör inte visas när man kan bygga laserkanoner.
– Teknologiträdet ska bara vara synligt en bit. När man börjar närma sig slutet får
man se de nya alternativen. Genom detta så får spelarna någonting nytt att sikta
på hela tiden. (3) Bra att kunna erbjuda kortsiktiga mål, men lider av samma
som ovan. Kan lösas genom att man visar att det finns alternativ bortom det
“sista” alternativet, till exempel genom att ha frågetecken (?) som visar att det
finns något, men inte vad.
– Det ska gå att spela och överleva som “casual gamer”. Det betyder att även om det
finns många parametrar att ställa in så är spelarna inte tvingade till att göra det
(defaultvärden). De är inte heller tvungna att sätta sig in i bakgrundshistorien.
Om man har soldater och inte ger dem “battle orders” så står de ändå inte still om
det blir strid. (4) “Casual gamers” är viktiga. Det handlar om att ge alternativ.
Vill spelaren inte detaljstyra så ska denne inte vara tvingad till det. Stöder princip
2 och princip 3.

149
– Allting får inte försvinna om en hjälte/familjemedlem dör. (4) Det blir för hårt
straff om en karaktär dör och spelarna kan tappa motivationen.
– Det ska vara lätt att kontrollera spelet. Standarder ska följas. (5) Handlar om
användbarhet.
– Spelare som vill ska kunna spela ensamma, de ska inte tvingas att gå med i en
allians eller liknande. Det kan även vara möjligt att ha “färdiga avtal” så spelare
slipper interagera så mycket. (3) Stöder princip 2. Men viss interaktion är alltid
nödvändig, även om den göms bakom färdiga avtal och order.
– Det bör inte finnas begränsningar. Spelsätt ska ej bli påtvingade. (3) Att inte ha
begränsningar är ganska svårt. Men spelaren ska själv kunna välja vilken nivå som
denne ska spela på (detaljstyra playorders eller fokusera på helheten), och även hur
denne ska spela (fokusera på krig, handel osv.). Stöder princip 2.
– Spelaren ska själv kunna designa sina trupper genom att ge dem olika skydd och
vapen. Detta påverkar truppernas egenskaper. (2) Kan vara roligt, men blir väldigt
komplext. Kräver att man kan bygga/köpa de olika vapen och rustningsdelarna.
– Bygg för expansioner, spelare ska aldrig kunna “levla” till max så att de ej kan
komma vidare. (4) Implementationsfråga. Bra för att spelet ej behöver vara
“färdigt” när det släpps.
– Spelare ska kunna påverka miljön i spelet. Till exempel genom att plantera skog,
bygga broar m.m. (4) Roligt, intressant och strategiskt.
– Spelet ska ha en bakgrundshistoria. (4) Ger djup åt spelet.
– Spelarnas handlingar påverkar hur historien i spelet utvecklas. (3) Finns en bakgrundshistoria
som byggs vidare kräver det att man bevakar spelet (kan göras automatiskt)
för att kunna föra historien vidare. Då får spelet en “handling” som kan
föras vidare i olika riktningar beroende på hur spelarna spelar (lite som scriptade
events). Kräver dock implementation och att man har bestämt mycket i förväg.
Kan även betyda att det spelarna gör “skapar” en historia (som även kan dokumenteras).
– Terräng gör inverkan. Olika trupper är olika bra i olika terräng. Viss terräng är mer
gynnsam för att bygga vissa byggnader på. (5) Strategiskt, lätt att implementera,
intressant.
– Det ska gå att ta över områden. Både “neutrala” och andra spelares områden
(krig, kultur, religion). (5) Strategiskt intressant.
– En spelare kan överlåta sina städer, soldater m.m. till en annan spelare när denne
är offline. (2) Bra om en spelare är borta länge. Men knöligt och svårt att implementera.
Frågan är också hur mycket man ska kunna överlåta åt andra spelare.
– Det ska vara svårare att ta död på en spelare som är utloggad. (4) Stöder princip
3.
– Lätt system för att förstå striderna, typ tärningssystem. Synligt hur striderna går
till. Det ska alltså inte bara synas attack och försvar utan även reglerna för hur
stridssystemet fungerar. Man ska förstå vad alla stats innebär. (4) Strategiskt

150 Chapter H. Annoterade idéer till spelet
intressant. Ökar playability om spelarna förstår vilka konsekvenser ett beslut kan
få.
– Mindre enheter ska kunna vinna mot större. Innebär en risk även för de största.
(3) Balanseringsproblem.
– Mycket stats för enheter, byggnader, hjältar, vapen osv. (3) Kan vara roligt att
lära sig reglerna, men kan bli svårt att förstå och innebära en hög tröskel för nya
spelare. Kan göra relationen mellan handling och konsekvens svårare att förstå.
– Arméer, hjältar, familjemedlemmar mm. kan utvecklas och bli bättre (genom erfarenhet).
De blir bättre i det område man använder dem till. Eventuellt skulle
erfarenheten för en armé försvinna med tiden. (5 - karaktärsutveckling och erfarenhet)
Om karaktärer ej utvecklas försvinner en mening med att ha dem. Detta
gör det intressant att specialisera sina karaktärer. (3 - arméerfarenhet) Svårt att
implementera. Enskilda trupper måste ha egen erfarenhet. Dock logiskt och intressant.
– Wikipedia för världen. Uppslagsverk. Som visar stats och allt (tänk civilopedia).
(3) Bra om spelet är avancerat, men är en nödlösning att måsta förklara reglerna
utanför spelet. Är bättre att spelarna kan komma åt dem inne i spelet när de
behöver dem. Kan dock vara ett komplement.
– Det kan finnas möjlighet att köpa/sälja kartor (som håller information om vilket
terräng som finns inom ett visst område). Om en spelare kommer in på området så
får han/hon tillgång till hela kartan för det området, men för de som inte utforskar
allt själva så kan det vara relevant att köpa kartor. (3) Enbart relevant om man
inte kan se hela världen till en början. Dock kan det innebära att alla kan få en
komplett världsbild alltför snabbt. En fråga är vad som ska synas på kartorna, är
det bara terrängen eller även städer, broar och liknande? Om städer syns kan det
bli ett problem med versionshanteringen eftersom sådant kan förändras.
– En spelare som blir övertagen av en annan blir vasall. Detta är i princip en
påtvingad allians. (2) Stöder princip 4, motsäger princip 2. Det finns dock alternativ:
Om en stad blir invaderad av en motspelare och det finns en familjemedlem
i staden så kan spelaren välja om familjemedlemmen ska bli vasall, partisan eller
flytta. Om man väljer att bli vasall så har man kvar staden och betalar skatt till
motspelaren beroende på hur stor staden är. Är man partisan kan man försöka
ta tillbaka staden och väljer man att flytta så får den andra spelaren staden. Den
andra spelaren kan i sin tur välja vid invasionen om staden ska plundras, förstöras
eller tas över samt den andra spelaren ska bli vasall. Om alla städer tas över så
ska spelaren som har tappat alla sina städer ha möjlighet att flytta sitt rike.
– Spelare kan skapa nya byggnader, föremål, vapen. Designa själv så andra kan
se (i.e. användargenererat innehåll). (2) Kan vara roligt men kan bli mycket att
implementera. Måste även övervakas och fyller ej heller någon egentlig funktion.
Om man själv kan välja stats på sina vapen och inte bara göra nya grafiska representationer
på dem så får man även balanseringsproblem.
– Det kan finnas en möjlighet att kombinera byggnader. Enkla enheter kan kombineras
till mer komplexa (detta kan leda till “strömlinjeformad produktion”). (3)
Bra idé om resurser är många och kan kombineras i flera steg för att producera
andra resurser. Automatiserar delar som inte är så roliga att göra.

151
– Synligt om spelare är onda eller goda (men även mellanting måste finnas). (4)
Bra men ett tveeggat svärd. Om man kan se andra spelares spelstil så kan man
kanske räkna ut vilka som är värda att anfalla osv.
Familj, ätt, hjältar
Som spelare styr man en familj eller ätt av en speciell ras och folkslag. Denna familj kan
ses som spelarens största “pjäser” i och med att de har stor inverkan på vad spelaren
kan och inte kan göra. Till exempel så kan det krävas att spelaren placerar en medlem
ur familjen i varje stad som spelaren har. Medlemmar ur familjen blir äldre och dör
alltefter som tiden går i spelet. Detta medför att familjen måste kunna föröka sig för
att inte försvinna. (5) Familj är en central del i spelet. Med dem kan man hindra att
en spelare är bäst hela tiden genom att familjemedlemmar dör.
I familjen finns även ett “överhuvud” som är den viktigaste karaktären i spelet. Denna
karaktär ger mest bonus vad den än används till tack vare dess pondus. (4) Ger mer
djup. Den stad som överhuvudet är kopplad till blir även spelaren huvudstad. När
denna dör måste ett nytt överhuvud väljas. Spelaren kan då välja hur det nya huvudet
ska väljas, till exempel den äldsta sonen, dottern eller det barn med mest av någon
egenskap. Om ingen kandidat finns som uppfyller kriterierna, eller om det finns flera,
kan stridigheter inom familjen uppstå.
Det kan även vara så att en familjemedlem gör uppror mot resten av familjen. Det
beror på hur mycket direkt kontroll spelaren ska utöva över “sin” familj. Antingen är
de viljelösa dockor som lyder och gör allt som spelaren vill (enkelt att implementera),
eller så har de egen vilja och mål (svårare att implementera). Om då spelaren sätter
dem i positioner som går emot deras vilja kan de revoltera. (1 - egen vilja) Spelarna
kommer med största sannolikhet att känna frustration om deras viktigaste pjäser inte
kan kontrolleras direkt.
Under spelets gång så skapas en familjehistoria. Alla relevanta händelser som familjen
är med om registreras och läggs till. Även släktträdet byggs naturligtvis ut allteftersom
spelet fortskrider. Det här skulle kunna representeras i html (eller liknande, med länkar
osv.). Detta blir särskilt intressant om giftermål med andra spelares familjer introduceras
då man kan se “sitt” släktskap med andra spelares familjer. (4) Inte livsviktigt,
men väldigt roligt. Blir mer statistik att titta på.
Giftermål
En spelare kan gifta bort en medlem ur sin familj med en medlem ur en annan spelares
familj. Detta ska då ge någon form av fördel för spelarna. Vem som senare får spela de
gifta samt deras barn finns det flera alternativ för:
– Spelaren med den manliga karaktären “får” den kvinnliga karaktären och även de
barn de får. För detta betalar denna spelare en “hemgift” för att få nytt blod
till sin familj. Hemgiften kan vara i form av resurser, eller en icke-angreppspakt
(om denna bryts så förlorar spelaren väldigt många prestigepoäng). Detta kan
vara ganska realistiskt med tanke på hur det verkligen gick till. Nackdelen är att

152 Chapter H. Annoterade idéer till spelet
det kan bli lite väl realistiskt och kan verka stötande för vissa. Det kan också
verka konstigt om detta sätt är det enda genom historiens gång, från stenålder till
rymdålder.
– Spelarna behåller sina respektive karaktärer och delar på barnen de får. Då bor
och verkar de gifta på olika håll och den enda inverkan det får är att nya barn blir
till. Detta alternativ är inte lika realistiskt.
– Spelarna väljer själva vilken spelare som ska ta över paret. Denna betalar då
hemgift åt den andra.
– Det gifta paret “försvinner” (blir ospelbara). Efter viss tid så anländer barnen
till familjen som spelbara karaktärer. Detta alternativ kan också fungera som
“extraliv” om familjen skulle dö ut. Det kan alltid finnas en kusin som är beredd
att ta över.
Systemet med “extraliv” skulle kunna användas vilket alternativ man än väljer. Det
finns alltid en avlägsen kusin som kan komma och ta över.
Alternativt kan man låta medlemmarna i familjen gifta sig med icke adliga personer
(dvs. NPC:s). Detta kan ge mindre prestige (eventuellt minus), men det skulle även
kunna vara adliga NPC:s från “ett land långt borta” som inte ger någon negativ effekt på
prestigen. Man får dock inte någon allians eller liknande och man får mindre möjlighet
att styra vilka egenskaper friarna har.
Om man tvingar spelarna att gifta sina familjemedlemmar med andra spelares familjemedlemmar
så lägger man stort ansvar på spelarna. Vad händer om de inte gifter sig
och släkten dör ut? Det finns en risk att det blir väldigt komplicerat. Om de bara gifter
sig med NPC:s så försvinner dock roligheten med att se släktskapen mellan familjerna
(det finns inga). Det måste även vara en balans i antalet familjemedlemmar man har,
det ska inte kunna gå att få för många man kan spela. Eventuellt så kan det vara så
att man börjar med några få och allteftersom så kan man ha fler (forska fram eller
liknande).
Den stora frågan är om man måste gifta sig med samma ras och folkslag. Det blir enklare
om det skulle vara så, men det blir (kanske) mer intressant om man kan blanda blod
mellan olika raser. Då skulle avkomman få stats som är en blandning av föräldrarnas.
Om föräldrarna har specialförmågor så kan det slumpas ut om barnet får det också.
Beror på vad som bestäms ovan.
Användningsområden för familjemedlemmar
– Spelaren måste ha en familjemedlem i en stad för att kunna styra över den. Kan
dock vara möjligt att äga en stad utan en familjemedlem (men inte att styra och
det går inte att anlägga eller ta över nya städer om man inte har en familjemedlem
att placera där). (5) Detta leder till att man inte kan bygga hur många städer som
helst och därmed bli hur mäktig som helst. Problemet är vad som händer när
personen som styr staden dör. Detta kan lösas genom att spelaren har reserver
som kan ta över. Om inte spelaren har en reserv så förlorar spelaren viss kontroll
över staden (kan inte bygga nya byggnader, svårare att försvara osv.).

153
– Familjemedlemmarna kan springa omkring och döda monster osv. Detta kan ge
föremål som kan hjälpa familjen/landet/familjemedlemmen. Familjemedlemmen
kan eventuellt också utvecklas och få bättre “stats”, detta kan dock innebära problem
då familjemedlemmar kan dö. När familjemedlemmarna är ute och springer så
kan dom röra sig inom en ruta på kartan (en ruta kan tex. vara uppdelad i nio små
rutor). (2) Blir alltför frikopplat och ett eget spel. Stats och erfarenhet är dock en
god idé, men kan förskaffas på andra sätt, till exempel när ett slag har vunnits.
Det vore också roligt om man hade ett achievements-system där karaktärerna får
priser för att ha utfört vissa uppgifter, dessa kan då visas upp för andra spelare.
– Familjemedlemmar kan ge en bonus till städer eller arméer som de placeras i. Detta
beror på familjemedlemmens egenskaper och eventuella utrustning osv. (5) Detta
är en anledning till att familjen finns. De ska vara något annat än en “tavla” som
man kan titta på men inte ger något rent mekaniskt.
– Familjemedlemmar kan skickas till rådet för rasen (varje spelare får skicka en
familjemedlem var). Familjemedlemmens egenskaper avgör hur mycket genomslagskraft
den röst spelaren lägger får. Vilka egenskap som påverkar kan bero på
ras (en orch med mycket styrka har mycket att säga till om medan en alv med
mycket spiritualitet är inflytelserik osv.). (4) ännu ett användningsområde. Bra
om karaktärerna har betydelser på andra plan än krigiska.
– Familjemedlemmar kan användas som ambassadörer i andra spelares städer. Då
kan spelaren med ambassadör få viss information om den andra spelarens stad.
Det kan vara så att man måste utse en ambassadör som bor i den andra spelarens
huvudstad om man ingår någon form av allians. (3) Enbart applicerbart om det
finns flera familjemedlemmar.
Förmodligen blir det så att man måste koppla en familjemedlem till en stad, men kan
även använda den till andra uppgifter. När personen bor i staden så ger den bonus till
vissa områden som spelaren väljer. Spelaren kan när som helst plocka ur personen ur
staden och stoppa in den i en armé, men då tappar staden bonusen. Även om personen
inte befinner sig i staden så är den ändå kopplad dit.
Områden familjemedlemmar kan fokusera på:
– Krig, familjemedlemmen blir då en enhet som spelaren kan gå omkring med på
kartan. Kan även sätta in denne i en armé. Bragder är slag och ger erfarenhetspoäng.
– Produktion minskar byggnadstiden och ger erfarenhet när byggnader färdigställs.
– Forskning ger uppfinningsbonus och mer erfarenhet vid upptäckter.
– Attraktion ger mer nöjda invånare så att populationen ökar snabbare, erfarenhet
vid folkökning.
Familjemedlemmar får erfarenhet på två olika sätt:
– Ålder ger erfarenhet som spelaren kan placera ut på olika områden.
– Bragder ger bonus på det område där bragden utförts.

154 Chapter H. Annoterade idéer till spelet
Rykte
Varje familj har ett rykte vilket återspeglar hur spelaren har spelat. Ryktet kan vara
flera olika variabler som till exempel blodtörstig, kulturell, välvillig, hederlig mm. Varje
familjemedlem kan även ha ett rykte som bidrar till familjens rykte. Eventuellt är det
endast familjens rykte som spelar in vid rådslag mm (detta för att inte spelaren ska
vara blodtörstig med vissa familjemedlemmar och att det inte märks vid rådslag). (3)
Ger mer djup, men kan utnyttjas om man ej är försiktig. Om alla andra spelare ser an
familjs och individuella medlemmars rykte inom flera områden så kan de även räkna ut
hur de ska bete sig mot den spelaren.
Råd
Ett råd/orakel/en despot osv. kan finnas för varje enskild ras. Rådet är de som avgör
när spelare ska bli straffade när de hackat på mindre starka spelare etc. Detta kan yttra
sig tex. genom att rådet säger “Spelare x har varit ond, alla ska skicka två soldater
för att attackera spelare x”. Rådet kan även lägga fram ämnen för omröstning så
som höjda skatter, eller korståg osv. Rådet är i princip AI när det gäller bestraffning
av spelare, men fungerar även som admins kanal in till spelarna (genom att lägga ut
uppdrag och omröstningar). Omröstningarna påverkas naturligtvis av spelarna. Olika
bestraffningar/belöningar osv. kan användas av de olika rasernas råd. Rådet kan ge
ytterligare hjälp/bestraffningar. Några alternativ listas nedan:
– Militär hjälp till svaga spelare som blir attackerade
– Resurser till någon som blivit nedslagen
– Nya spelare kan vara under rådets beskydd
– Ge quests som spelare kan utföra (korståg, hitta artefakter osv.). Kan vara för
flera länder, ett land eller för enskilda familjemedlemmar/hjältar (se quests).
– Om ovanligt mycket aggression har visats från en ras mot en annan så kan rådet
lägga fram förslaget att det ska startas krig mot den andra rasen (dvs. det blir
ingen prestigeförlust att anfalla spelare av den andra rasen).
Spelare ska kunna ge förslag på omröstningar eller “lagar” till rådet. Dessa lagar skulle
kunna gälla att en typ av forskning är förbjuden, eller att alla måste betala skatt.
(3) Positiva aspekter:
– Hjälp till svaga.
– Naturlig kanal från admin.
– Färdigt forum som spelarna kan använda.
– Introduktion, tutorial till nya spelare.
Negativa aspekter

155
– Krystat.
– Konstiga restriktioner. Spelarna måste tillhöra ett råd, även om de inte vill. Bryter
mot princip 2.
Det skulle kunna vara så att rådet spelar stor roll för nya spelare. När man börjar får
man flera uppdrag av rådet för att man ska lära sig hur spelet fungerar. Allteftersom så
lär sig spelarna och de får inga mer uppdrag av rådet. Då är det bara vid speciella
tillfällen som rådet kan ge uppdrag, annars fungerar det bara som en kanal mellan
spelare.
Allianser
En allians är ett förbund som två eller flera spelare bundit sig till. (5) allianser måste
vara med på ett eller annat sätt. Det ska finnas flera olika typer av allianser, och
en spelare ska kunna ansluta sig till mer än en av dem. En allians är ett “state” i
spelvärlden, det vill säga att man ska kunna se vilka spelare som är i allians med vilka.
Det finns flera sätt man kan göra detta på:
– Det finns bara en typ av allians som en spelare kan skapa. I denna så bestämmer
denna spelare vilka regler som gäller för denna allians. Denna spelare bestämmer
även själv vilka spelare som ansöker om medlemskap som får vara med. Det är
även upp till denna spelare att “kicka” spelare som bryter mot alliansen. Detta
blir väldigt flexibelt, men det är upp till spelarna själva att se till att de inte
bryter alliansen. Detta kan leda till missbruk och orättvisor om till exempel en
alliansledare kickar en spelare på grund av personliga orsaker och inte på grund av
att den spelaren bröt mot några regler i alliansen. Detta kan vara bäst för allianser
som inte explicit betyder någonting (typ Ikariam). (3) Enkelt att implementera,
men ger ingen “koll”.
– Det finns bara en typ av allians, men nu väljer spelaren i listor hur den ska fungera.
Det kan till exempel vara hur man bestämmer i alliansen (omröstning, en ledare,
ett råd av starka spelare m.m.) och vilka regler som gäller (om man får anfalla
andra i alliansen och vad som händer om man gör det, vad man måste betala för
att få vara med m.m.). På detta sätt får “spelet” reda på vilka regler som gäller
för alliansen och kan på detta sätt se till att regler efterföljs. Då kan spelare som
inte sköter sig kickas automatiskt och andra slipper bli kickade på grund av “fel”
orsaker. (3) Ger koll, men oflexibelt. När man försöker skapa en taxonomi över
olika allianser och olika alternativ så kommer man att missa saker. Om en spelare
vill skapa en viss typ av allians, men den inte stöds, så blir spelaren frustrerad.
– Det finns flera olika typer av allianser att välja mellan. De kan vara av typen handelsallians,
icke-angreppspakt eller militär allians. Då är flera regler färdigspecifierade
och spelarna slipper fylla i oändliga listor av regler, de behöver bara justera vissa
värden. Då kan andra spelare även se vilken typ av allians andra spelare har
mellan varandra. Nackdelen är att det kan kännas oflexibelt om spelarna inte kan
bilda sina egna allianser. De kanske vill bilda en ballongallians(?), men det finns
ingen sådan att välja på. (4) Kombinerar man detta alternativ, där vissa typer

156 Chapter H. Annoterade idéer till spelet
av allianser finns att välja på, med en generell allianstyp, så blir det ganska kraftfullt.
Kan spelaren ställa in vissa parametrar (styrelseskick, hur omröstning går
till, hur man kan avsluta sitt medlemskap, hur spelare sparkas, kan individuella
spelare starta krig med andra spelare, hamnar alla i alliansen i krig med en annan
spelare om denne attackerar någon i alliansen, kan alliansen starta krig mm.), så
blir det nästan en kombination av alla typer. De färdigspecificerade allianserna
kan till exempel vara icke angreppspakt mm.
En nackdel med att ha färdiga regler är att det kan krävas lite handpåläggning om
paradoxer uppstår. Om spelare A har en militär allians med spelare B och en annan
militär allians med spelare C, och B och C börjar kriga, vad händer då? Ska man skicka
styrkor till båda sidor? Tvingas man välja sida eller kan man hålla sig neutral i detta
fall utan att bli utesluten i båda allianser?
Om spelet explicit håller reglerna kan man tvinga spelare i en ickeaggressionspakt att
hålla fred genom att ta bort alternativet att anfalla. Man kan även göra så att skatt
dras automatiskt. I ett handelsavtal så kan en viss mängd varor skickas kontinuerligt
utan att spelarna själva måste göra det.
Riken
Med allianser skulle man även kunna skapa “riken” där en spelare är ledare (behöver ej
vara den som startade alliansen) och har viss kontroll över de andra spelarna. Denna
spelare kan till exempel kräva skatt eller kontroll över en viss mängd soldater. Även
tullar och tex. vapenindustrin skulle kunna styras/ägas av ledaren. Mycket makt kräver
dock mycket ansvar. Det ska gå att sätta sig emot kungen och avsätta denne. Det måste
finnas en möjlighet för enskilda spelare att bryta sig ur “riket”, detta ska dock innebära
någon form av straff för att det inte sker alltför lättvindigt (möjligtvis kommer spelarna
själva att skapa sådana bestraffningar). (2) Kan vara häftigt, men måste bidra med något
unikt som inte kan finnas i en vanlig allians (bankverksamhet kanske?). Restriktivt och
ej nödvändigt.
En spelare som väljer att inte bidra med den mängd soldater eller skatt som ledaren
utkräver kan bli straffad (tex. om ledaren vill ha 10% av soldaterna och spelaren bara
ger 5% så får spelaren mindre av bytet från kriget).
En allians kanske kan bilda allians med en annan allians. Då kan riken gå ihop och bli
superriken. Till slut finns det en kung över galaxen. (3) Detta fungerar även om man
bara har “vanliga” allianser. Då skulle man kunna välja när man skapar alliansen om
den ska kunna ingå allians med andra allianser.
Eventuellt kan även allianser äga och sköta städer, soldater m.m.
Städer
Spelaren ska kunna bygga städer och fylla dem med invånare. (5) Nödvändigt. Dessa
invånare behöver inte vara av samma ras eller folkslag som familjen man spelar. Det kan
mycket väl vara så att samma stad både innehåller alver, orcher, människor, lågländare,

157
högländare och lilleputtar. Spelaren ska även ha möjlighet att stoppa vissa raser från
att komma in i staden. (?) Kan bli för avancerat att ha olika raser i en stad, men
behöver inte bli det. Har man olika raser som kan bo i samma stad så kan spelaren välja
om de ska ha en generell stad eller en specialiserad för en specifik ras.
För att locka till sig olika raser i staden kan man behöva bygga olika typer av byggnader
som den rasen tycker om. Det kan då vara så att vissa byggnadstyper även stöter sig
med andra raser. Det kan även vara så att vissa lyxvaraor lockar till sig vissa raser men
stöter sig med andra.
Om städer är olika attraktiva att bo i för olika raser kan man locka till sig en viss ras
från en annan konkurrerande stad genom att göra sin stad mer attraktiv att bo i för
den rasen.
Två bra idéer som ger städer och raser djup.
Handel
Handel ska ha betydelse i spelet. (5) Key feature. För att få tillgång till alla resurser
så måste man handla, alla resurser är ej tillgängliga bara genom att utvinna dem själv.
Antingen så kan man byta varor mot pengar, eller varor mot andra varor. Handel kan
fungera på många olika sätt:
– Man kan bygga trading-posts i en stad. Om två andra spelare använder denna
trading-post så kan denna spelare ta ut tull för denna handel. (3) Avstånd betyder
något, blir mer att göra, ännu en byggnad att bygga/forska fram. Men det kan
bli väldigt rörigt tillslut. Det kan även bli för svårt att få tag på vissa resurser,
säljarens marknad.
– Global marknad. (3) Enkelt att implementera och förstå, men gör att man kan
“se” mer än man borde kunna. Avstånd från det egna riket till en viss resurs
spelar även mindre roll, svårt att få vägar att få betydelse. Köparens marknad.
– Auktionssystem, där man även kan välja att betala ett högt pris för att få varan
direkt. (3) Kan läggas till de andra, eventuellt forskar man fram det.
– Resor för att köpa och sälja. (2) Kan bli roligt och realistiskt, men kommer att bli
trögt.
Man skulle kunna göra en annan version av en tradingpost där man forskar fram handelssystemet.
Ju mer man forskar desto längre bort kan man handla och desto mindre
svinn blir det. Ju större en spelares handelspost är, desto mer av marknaden får spelaren
tillgång till. Storleken på handelsposten avgör hur mycket svinn det blir (större -¿ mindre
svinn). Det är alltid den som avgör affären som drabbas av svinnet. Detta betyder
att om man har en liten handelspost och vill köpa eller sälja, så vill ingen göra affärer
med en därför att de drabbas av svinnet. Om man däremot har en liten handelspost
och ser att en annan spelare vill köpa eller sälja varor, så drabbas man själv av svinn.
Det är alltid varor som försvinner, inte pengar.
Det är avståndet mellan två spelares huvudstäder som avgör avståndet när man ska
beräkna svinnet.

158 Chapter H. Annoterade idéer till spelet
Vägar kan även byggas för att minska svinnet (eventuellt minska transporttiden). En
fråga är om handlandet ska ta tid? Ska man få varorna direkt eller tar det en tid
proportionell till avståndet att få sina varor.
Även hjältar, vapen och andra producerade tillgångar skulle kunna handlas med. Hjältar
som ej tillhör någon spelare kan finna tillgänglig att köpa. Alla spelare har då möjlighet
att ge bud. (3) Hjältar kommer nog inte att finnas i spelet, man ska förmodligen inte
kunna producera vapen, enbart trupper. Eventuellt så skulle man kunna handla med
producerade lyxvaror (och trupper).
Har man trading post eller global marknad så kan själva köpandet och säljandet fungera
på två sätt:
– Man anger att man vill köpa en vara för ett visst pris och andra spelare kan se
det och välja att sälja till en. Man kan även ange att man vill sälja en vara till
ett visst pris och då fungerar det på samma sätt. (4) Det är förhållandevis enkelt
och kan kombineras med svinn.
– Man anger att man vill köpa till ett visst pris maxpris X, en annan spelare anger
att denne vill sälja till ett visst pris minpris Y. Om X ¿ Y så får man varan för ett
pris som är en funktion av X och Y. Om flera spelare vill köpa samma vara så kan
den spelare som får varan bestämmas a antingen den som köat längst eller vars
familjemedlem har högst karisma. (2) Ganska krångligt och går ej att kombinera
med svinn.
Forskning & utveckling
Spelarna ska kunna forska fram ny teknik. (5) Nödvändigt. Denna teknik gör det till
exempel möjligt att bygga nya typer av vapen eller byggnader. Teknologiträdet ska ha
flera grenar och det ska inte vara möjligt att kunna bli bäst på allt. Möjliga områden
är teknik, vapen, magi m.m.
För att förhindra att nya spelare inte har en chans mot äldre, så kan man göra så att
stammen/stammarna på trädet går fort att forska fram när många behärskar tekniken.
Stammen kan då vara de olika åldrarna i världshistorien och viktiga teknologiska genombrott
(papper, hjulet, kugghjulet, mikrochipet mm.). Mikrochipet kan vara fruktansvärt
dyrt att forska fram för den första som kommer på det, men är man först så får man ett
visst försprång under en viss tid. Ju fler som forskar fram mikrochippet desto billigare
blir det. Men stammen gör inte mycket i sig, utan man måste utforska grenarna för att
kunna bygga olika soldater eller byggnader och de är lika dyra oavsett hur många som
kommit på dem. På detta sätt hindrar man att nya spelare befinner sig i stenåldern och
andra i rymdåldern.
Olika raser kan ha olika teknologiträd (eller grenar). Kan vara evolution för vissa och
teknik för andra. (1 - unika träd) Blir svårt att balansera och ger inte så mycket. (3 -
unika grenar) Kan ge mer djup åt de olika raserna. På detta sätt kan man tvinga fram
interaktion mellan de olika raserna om bara dvärgar kan utvinna mithril och alverna
utvinna silverek (men vad hindrar en alvfamilj att anställa dvärgar? Dvs. om man kan
ha olika raser i staden så varför inte i gruvan?). Får fråga.

159
Kommunikation
Det ska vara enkelt att kommunicera med sina grannar och allierade. (5) ett måste för
diplomati. Det finns chatt (som går till alla inom en allians tex.), mejl (till en eller ett
fåtal personer) och forum (Varje allians har ett forum där de kan diskutera). Man ska
kunna ha vänlistor och listor på alla som är med i de olika allianserna/råden/guilden
och kunna kontakta enskilda eller alla. Om man ska skicka meddelanden till spelare
som befinner sig långt borta tar det tid för meddelandet att gå fram. (2) Det bör ej
ta någon tid att kommunicera, kommunikation kan ändå ske utanför spelet och det tar
ingen tid. Hur lång tid beror på kommunikationskanalen. Svar ska kunna representeras
som avhuggna huvuden om man vill.
Ett alternativ är att spelare kan stoppa sändebud mellan andra spelare och på detta
sätt avlyssna kommunikationen (kryptering kanske också då ska finnas). (1) Ingen bra
idé, kommunikationen kommer då bara att flytta utanför spelet.
Playorders
Spelaren kan ge order till AI:n om hur denna ska bete sig när spelaren inte styr själv.
(5) Måste vara med. Stöder princip 3. Detta kan ske på olika nivåer.
Strider
– Ett alternativ för playorders här är att spelaren säger till AI:n hur en armé och
de bataljoner/divisioner/trupper som den består av ska bete sig och vilka uppställningar
den ska utgå från i strid. Alla strider kan i så fall utspelas mellan AI.
(5) Ger djup och fler saker att syssla med, ska dock ej vara ett måste.
– Det är möjligt att säga till en armé hur den ska bete sig i en större skala medan
man är borta. Ska den tex. attackera alla andra arméer som kommer i närheten,
fly undan, återvända och försvara en stad eller bara hålla sin position. (4).
– Det kan finnas möjlighet för spelaren att forska fram bättre AI (dvs. mer avancerade
alternativ; olika formationer eller attacker). (4).
– En duktig general eller liknande i en armé kan göra AI:n bättre. (4) eller höja
moralen.
Byggplaner
Spelaren kan ge instruktioner till vilka byggnader som ska byggas medan spelaren är
borta. Detta kan ske på lite olika sätt.
– Spelaren säger exakt vilka byggnader som ska byggas (dvs. spelaren sätter upp
en kö) (4) Lätt att implementera. Frustrerande om man måste logga in hela tiden
för att göra något nytt.

160 Chapter H. Annoterade idéer till spelet
– Spelaren säger vad AI:n ska prioritera (tex. bygger AI:n mycket baracker eller
liknande om fokus ligger på stridsbyggnader, eller så ligger fokus på att reparera
osv.). (2) Svårt att implementera och har inte så stor poäng.
Mål och slut
Spelet innehåller mål som spelarna kan kämpa mot. Målen kan vara både delmål
och/eller slutgiltiga mål som i princip avslutar spelet (spelet skulle även kunna fortsätta
även när det slutgiltiga målet har uppnåtts, det kanske finns spelare med ett motsatt
mål som fortsätter kämpa för det). Ett exempel på stora mål är:
– “ena galaxen/världen under en flagga”.
– Flera sidor strider och en har vunnit.
Om man hintar om att det finns ett mål, men inte skriver ut det explicit, så kan man
skjuta upp beslutet. Man kan till exempel skriva i bakgrundshistorien om en splittrad
värld som vill enas.
Exempel på delmål är:
– Man ska ta över vissa platser eller artefakter.
– Vinn över påven till din sida.
Det är viktigt med delmål för att belöna spelarna och motivera dem att spela vidare.
Det finns flera alternativ på hur spelet slutar:
– Det finns inte något slut på spelet, men det ska inte vara så att samma spelare
befinner sig på “toppen” hela tiden. Även nya spelare ska ha chans att bli bra.
– Det finns ett slut (ett av flera möjliga slutgiltiga mål har uppnåtts), men spelet
kan fortsätta även efter slutet.
– Spelet slutar efter ett slutgiltigt mål har uppnåtts.
– Spelet tar slut efter en viss tid.
– Ett visst antal spelare släpper bomben och allt dör.
Resurser
Det ska inte vara möjligt att ha tillgång till alla resurser (förutom eventuellt genom
handel eller krig). (4) Ger djup och skapar intressekonflikter. Resurser skulle kunna
förädlas med hjälp av tekniker och fabriker (eller liknande), både genom att slå samman
olika resurser (kol + järn = stål) eller bara förädling av en resurs (timmer -¿ plank).
(3) Beror på hur avancerat man vill göra det.

161
Resurser ska vara mer eller mindre tillgängliga och vanliga. Vissa basresurser (trä och
sten) finns överallt, men andra mer exklusiva finns bara på vissa ställen i världen. Dessa
är dock inte nödvändiga för överlevnad. (5) Tvingar till interaktion.
Vissa resurser är förnyelsebara och växer tillbaka efter en viss tids träda. Spelaren kan
välja hur mycket av en resurs den ska ta ut från en källa per tidsenhet. Om spelaren
överutnyttjar en resurs så kan den ta slut, åtminstone för en tid. Tillväxten för en
resurs är proportionell till hur mycket av resursen som finns i källan. Detta betyder att
om man utvinner för mycket av en resurs så försämras återväxten. Eventuellt skulle
forskning kunna ge bättre återväxt. (2) Kan vara intressant att försöka hitta balansen,
men det finns alltid en bästa nivå så när man hittat den blir valet trivialt.
Alternativt så är resurserna oändliga men spelare kan bara utvinna en viss mängd per
tidsenhet. Genom forskning eller uppgradering så kan man utvinna mer per tidsenhet.
(4) Enklare och mindre frustration.
För att hindra att det blir för mycket inflation så krävs det att resurserna används upp
och försvinner. Detta kan lösas genom att byggnader, soldater m.m. kostar att bygga,
samt att soldater kostar att underhålla. Balanseringsproblem.
Resurser är inte nödvändigtvis synliga direkt, utan spelarna måste medvetet leta efter
dem. Det kan även vara möjligt att vissa resurser inte är synliga om man inte “forskat
fram” dem. (2) Blir ingen strategi om man måste gå på en resurs för att veta att den
finns där. Borde räcka med att man upptäckt ett område för att se vilka resurser som
finns där.
Resurser ska vara globala, det betyder att de inte är kopplade till en viss stad. Behöver
spelaren bygga någonting i en stad så måste denne inte skicka resurser mellan städer.
Det betyder inte att man inte kan bygga förråd i städer, de ger högre tak i det globala
förrådet.
Städer förbrukar vissa resurser, som till exempel vissa lyxvaror, med en viss hastighet
som spelaren bestämmer (mer ger högre attraktion). Om lagret innehåller mindre av en
viss resurs än vad som behövs så kan ett av följande hända:
– Ingen stad får någon resurs.
– Det finns en prioritet mellan städerna, där kvarvarande resurser delas ut efter
prioritet.
– Resurserna delas lika.
– Slump avgör vilka som får hur mycket av en resurs.
Manskap
Manskap är även det en resurs. Städer ger manskap som spelaren kan fördela ut på olika
arbetsområden. Fler och större städer ger mer manskap. Om städerna innehåller olika
raser, syns det även i vilket sorts manskap spelaren får. Olika manskap kan även vara
olika bra på olika arbetsuppgifter. Vissa raser kanske även inte kan utföra vissa sorters
arbete.
Arbetsuppgifter skulle kunna vara:

162 Chapter H. Annoterade idéer till spelet
– Trupp. Ett antal män används för att bygga en trupp soldater av något slag
(trupper kan sedan slås ihop till arméer).
– Matproduktion.
– Gruvdrift.
– Byggnationer.
– Forskning
Städer fyller på med nytt manskap om man skulle tappa det efter till exempel strid.
Men det tar tid att fylla på med nytt (beror på storleken på städerna). Om man tappar
en stad så tappar man inte manskap (skulle vara alltför hårt straff), det fylls bara på
saktare.
Strider
Det ska vara möjligt att både se strider och hur de utspelar/utspelade sig samt att få
en sammanfattning (battle report). Det ska inte vara möjligt att direkt ta kontroll över
striden (se playorders) (nödvändigt), men strider ska ta lång tid (större strider tar längre
tid) så det ska vara möjligt att skicka förstärkning i form av nya trupper. Det är även
möjligt att andra spelare lägger sig i striden (inte nödvändigt).
För att förhindra att man kan skicka en ensam soldat till en armé och på så sätt enkelt
spionera på den andra spelarens laguppställning, krävs det att det finns överlevare som
kan rapportera striden.
När en spelare vunnit ett slag (fältslag eller tagit över en stad) så kan denne välja
vad som ska hända med förlorarna (och staden). Ska alla dödas, skonas, ska staden
brännas eller tas över mm. Vad spelaren väljer påverkar familjens rykte. (4) Påverkar
karaktärerna. Tillfångatagna familjemedlemmar kan krävas lösensumma för, torteras,
skickas hem i förnedring mm. Olika val leder till olika bonusar och påverkar ryktet (för
vinnaren och/eller förloraren).
Förloraren av ett (fält)slag (och inte blir annihilerad) flyr till bästa möjliga ruta närmast
en stad som inte tillhör fienden (egen, allierad eller neutral). Blir man attackerad igen
så backar man automatiskt så länge man är i flykt-tillstånd. Om rutan armén flyr till
är strategiskt bra så kan det hända att den börjar slåss igen. Finns det bara fienderutor
runt om så slåss man till siste man.
Flykttillstånd kan en armé hamna i på två olika sätt: moralen brister och soldaterna
flyr eller antalet levande soldater har hamnat under en (egeninställd) gräns. Moralen
sjunker självklart när soldater dör.
Quests och events
Det kan finnas flera olika sorters quests (uppdrag). De från admin och/eller från andra
spelare. Dessa uppdrag kan gälla för flera länder, raser, allianser, ett land eller enskilda

163
hjältar. Uppdragen kan utspela sig inom olika områden: handel, produktion, politik
eller strid (alla områden som finns inom spelet). Events och quests kan även triggas
av hur spelarna spelar, tex. kan missväxt inträffa om spelarna utnyttjar odling i alltför
stor utsträckning osv.
Quests kan fungera som tutorial, men spelarskapade quests är svåra att implementera.
Hur kan spelet få reda på att en spelare verkligen har utfört ett quest som denne påstår.
Med olika kommunikationskanaler kan dock spelare ge varandra uppdrag utanför spelets
regler.
Events är händelser som skiljer från “vardagen” i spelet. (4) Intressant, skapar mål och
belöningar. Några exempel är:
– En drake kommer och attackerar.
– En ö föds.
– Hungersnöd.
– Jordbävning.
– Goda år (skördar/produktion etc.).
Introduktionen till spelet kan ske i form av quests inom de olika områdena. Under tiden
som spelaren spelar de introducerande questen så bör denne vara skyddad från andra
spelare (eventuellt inte en del av den “riktiga” världen).
Perspektiv
Man styr från “guds” perspektiv (man “är” inte en enskild karaktär) (Så ska det vara).
Men det skulle kunna vara så att man verkligen är en gud som styr sina undersåtar. Då
skulle man kunna förklara spelare som slutar spela med att folkets gud har övergivit
dem. Ett annat alternativ är att hela släkten dör under mystiska omständigheter och
anarki och kalabalik utbryter. (1) Tar fokus från familjen.
Highscore
Familjernas poäng listas i någon sorts highscorelista. (5). Detta kan vara en higscorelista
där familjens poäng i alla områden (strid, handel osv.) räknas samman, eller olika listor
för olika områden. Även familjens blodtörst/godhet skulle kunna listas.
Alternativ för highscorelistor inom olika områden:
– I listor för olika områden listas alla spelare. Det skulle kunna medföra att man
kan avgöra om man ska attackera en spelare eller inte.
– Endast topp tio listas inom de olika områdena.
– Man ser endast sin egen position i listorna (spelaren ser att denne ligger på tex.
position 128 på handelslistan).

164 Chapter H. Annoterade idéer till spelet
Alternativ för hur man räknar:
– Highscoren räknas från tidernas begynnelse (dvs. allt man får poäng för läggs till
det man redan hade, resultatet ökar hela tiden). Kan få effekten att dom som
börjar spela spelet först alltid ligger i topp. (2) Leder till att den som började
spela alltid är bäst.
– Highscoren är knuten till specifika familjemedlemmar. När en familjemedlem dör
så tappar familjen den “score” som familjemedlemmen hade. Kan anses som hårt
straff, men ser till att toppen av highscoren är i konstant rörelse. (4) Har man
vunnit ett stort slag, eller uppfunnit elden så återspegles det i poängen så länge
familjemedlemmen som utförde dådet lever. Man kan även räkna in andra saker i
poängen som till exempel antal städer, landarean, produktion mm (se nedan).
– Highscoren räknas ut för stunden, endast den situation spelaren och dess land
befinner sig i just för stunden är det som visas på highscore. Man slipper räkna
poäng, det kommer vara relativt mycket rörelse på highscore-listan, men det finns
stor risk att spelare kan räkna ut vem som är svag osv. (3) Att bara göra på detta
sätt tar fokus från familjen. Stora bragder räknas inte heller alls.
– Samma som ovan, fast knutet till specifika familjemedlemmar (familjemedlem A
har visst politiskt inflytande och en viss militär makt osv.). (3) Går, men inte
lika intressant som ovan.

Appendix I
Heuristiker för utvärdering
Feedback & control
– Players should perceive a sense of impact onto the game world.
– Feedback should be given immediately to display user control.
– The first-time experience is encouraging.
Goals
– The game provides clear goals or supports player created goals.
– There should be multiple goals.
Challenges & skills
– Get the player involved quickly and easily.
– There should be variable difficulty level.
– “A good game should be easy to learn and hard to master” (Nolan Bushnell).
– Provide instructions, training and help.
– Challenges are positive game experiences, rather than a negative experience (results
in their wanting to play more, rather than quitting).
– There are no repetitive or boring tasks.
– Pace and activities are varied to minimize frustration and fatigue.
165

166 Chapter I. Heuristiker för utvärdering
Progress
– The player sees the progress in the game and can compare the results.
– The players are rewarded and rewards are meaningful.
– The game should give rewards that immerse the player more deeply in the game by
increasing their capabilities (power-up), and expanding their ability to customize.
– The player does not lose any hard-won possessions.
– The game does not stagnate.
– The game must maintain an illusion of “winnability”.
Balance & Strategies
– There must not be any single optimal winning strategy.
– The game supports different playing styles.
– Play should be fair.
– Player should not experience being penalized repetitively for the same failure.
– The player cannot make irreversible errors.
Setting & content
– The game uses orthogonal unit differentiation.
– Include a lot of interactive props for the player to interact with.
– Provide consistency between the game elements and the overarching setting and
story to suspend disbelief.
Multiplayer issues
– The game supports communication.
– There are reasons to communicate.
– The game supports groups and communities.
– The game provides information about other players.
– The design overcomes lack of players and enables soloing.
– The design minimizes deviant behavior.

Appendix J
Found issues in heuristic
evaluation
Topic Feedback & Control
Heuristic Feedback should be given immediately to display user control
Problem Can be a long time between action and consequence
Rating Moderate
Description There is a chance that the consequences of an action are revealed long
after the action. Therefore it will be hard for players to link cause
and effect and therefore feel that the game is randomly punishing or
supporting players.
Solution -
Topic
Heuristic
Problem
Rating
Description
Solution
Feedback & Control
Players should perceive a sense of impact onto the game world
Players might not feel that they can affect the world.
Minor
Depending on the size of the world (and also the time scale) the player
might not feel that it is possible to have any significant impact on
the world as a whole. I.e. if the world is too big the actions of one
single player won’t have any significant effect on the world.
1. Limiting the size of the world. 2. Making it possible to affect a
very large area in the world (though this might be extremely difficult
to balance and make fair).
167

168 Chapter J. Found issues in heuristic evaluation
Topic
Heuristic
Problem
Rating
Description
Solution
Feedback & Control
Feedback should be given immediately to display user control
No action has an immediate effect (The moving of an army is used
as an example).
Important
If the player gives an order to move to an army the army will not move
until the “move time” has ended which provides very little feedback.
1. It is possible to give armies “move points” over time instead of
making them wait for each move. By doing this it is possible to have
the armies move directly but only a given distance during a specific
time. 2. Presenting that the army has been given an order and also
showing clearly how much time it will take for the army to complete
the order.
Topic
Heuristic
Problem
Rating
Description
Solution
Feedback & Control
The first-time experience is encouraging
All actions takes time to finish
Important
Since all actions takes a certain amount of time to finish there is the
risk of players not being able to play for more than a couple of minutes
before they have actually developed their land/country/cities quite a
bit.
1. Having plenty of things to do in the beginning. 2. Not restricting
all actions to take time (for example using movement points instead
of having to wait for each move when ordering armies around). 3.
Make sure that there is a “hook” in the first parts of the game to
make the players want to come back (and also provide good enough
help so the start of the game is not too complex).
Topic
Heuristic
Problem
Rating
Description
Solution
Challenges & skills
Get the player involved quickly and easily
There is a chance that the player will be overwhelmed with all options
at the beginning of the game.
Important
At the beginning of the game the player has a lot of options of things
to do and strategies to use. Because the player does not know the
game world and its rules he/she may not be able to form a strategy
and thus quit playing. If a mistake is made it could also have dire
consequences that the player will have to deal with for a long time
(i.e. building the wrong thing and thus depleting critical resources).
1. Provide an in game tutorial that introduces the player to the world
and explains the rules. 2. Ensure that the gameplay is balanced in a
way that the initial decisions do not have too much effect.

169
Topic
Heuristic
Problem
Rating
Description
Solution
Challenges & skills
“A good game should be easy to learn and hard to master” (Nolan
Bushnell)
Complexity vs. depth.
Important
The game has a lot of rules that can intimidate new players. This is
a transparency issue.
Make the rules simple but that still provides much depth (i.e. several
choices in each situation).
Topic Challenges & Skills
Heuristic There should be variable difficulty level
Problem The opponents set the difficulty.
Rating Moderate
Description It is very difficult to tune the difficulty for different players. All
players will in essence play on the same difficulty, but if a player
happens to start next to a strong and aggressive player the difficulty
will be fairly steep for that individual.
Solution Make the different directions a player can take have an effect on
the difficulty. For example: If a player chooses to focus on science
the difficulty in defending (since warfare is apparently not where the
player wants a challenge) might become easier (so that aggressive
players cannot take advantage of a peaceful player).
Topic Challenges & Skills
Heuristic Provide instructions, training and help
Problem There is no mention of a tutorial or help.
Rating Critical
Description Since it is a fairly complex game some sort of help or tutorial (preferably
both) is probably needed.
Solution -
Topic
Heuristic
Problem
Rating
Description
Solution
Challenges & Skills
There are no repetitive or boring tasks
It is repetitive and tedious to explore.
Important
Players need to give a new order each time a new area is to be explored
(i.e. the armies cannot move into unexplored territory). This makes
the exploration very difficult as it demands that the player is online
for a very long time or logs in very often.
1. Use “movement points” for the armies. 2. Allow the moving of
armies into unexplored areas.

170 Chapter J. Found issues in heuristic evaluation
Topic
Heuristic
Problem
Rating
Description
Solution
Challenges & Skills
Pace and activities are varied to minimize frustration and fatigue
The pace is fixed and the same for all players making it very difficult
to balance the game at the same time as ensuring that the pacing is
good in every situation a player can be in.
Important
In the beginning of the game things should perhaps be fast to accomplish,
but when a player builds an additional city building cannot be
as fast as it would disrupt balance. This is also an issue for new players.
A new player should not be in an “impossible” position because
everyone around her is already much more powerful. Since the pacing
is identical for everyone (?) this becomes very difficult to balance.
Provide different time scales for new players. The faster research for
new players is a good approach, but this might need to be extended
to buildings as well. This solution could however result in the pace
of the game being too fast for new players.
Topic Progress
Heuristic The players are rewarded and rewards are meaningful
Problem Many rewards are of the type that a player can gain by waiting.
Rating Minor
Description Plundering has basically the same effect as trading. This is however
a minor issue when it is the interaction between players that is
important and plundering will affect the relations between players.
Solution Give unique rewards to different play styles (more than reputation,
which is a minor cosmetic issue).
Topic
Heuristic
Problem
Rating
Description
Solution
Progress
The game should give rewards that immerse the player more deeply in
the game by increasing their capabilities (power-up) and expanding
their ability to customize
The rewards (or achievements) are basically very similar.
Minor
Example: Build a building and you get a building allowing you to
build another building and so on. There is no real change to the
options available for the players.
Make more differentiating options available when certain achievements
have been made.

171
Topic
Heuristic
Problem
Rating
Description
Progress
The player does not lose any hard-won possessions
Players can take over cities.
Important
A player can take over a city from another player. Cities are very
important in the game and players spend a lot of time developing
and upgrading them.
Solution 1. Offer “free-zones”, cities that can not be taken over that the
players can spend time on developing. Other players can only take
over forts or similar buildings. 2. Make sure that cities do not have
too much impact on the world (though this can make the game less
interesting). 3. Enable the rebuilding of a city in a new location and
make it much less costly than building an ordinary city from scratch.
4. Make it extremely difficult to lose cities.
Topic
Heuristic
Problem
Rating
Description
Solution
Progress
The game does not stagnate
The game repeats and goals looses their importance.
Moderate
When all cities are built the goal to expand looses its importance.
The only real goal will then be research, which is just waiting. If
a player achieves all resources trading and warfare looses its importance.
Players at the top are not offered any other goals than new
players to keep them motivated to play.
1. Ensure that there is interesting gameplay even after a player has
reached the maximum number of cities. 2. Fill the game with enough
content so that no player ever comes to a situation where “everything
has been done”. This could be done by demanding that cities and
territories constantly change in order to counter the tactics of opponents.
Topic Progress
Heuristic The game must maintain an illusion of “winnability”
Problem The illusion may break.
Rating Minor
Description After a while players may realize that there is no chance to definitely
win over other players.
Solution -

172 Chapter J. Found issues in heuristic evaluation
Topic
Heuristic
Problem
Rating
Description
Solution
Balance & Strategies
The game should be fair
There is a risk that different locations of players make the game more
challenging for some players.
Important
The position of a player’s territory initially determines what resources
the player has available. This can in turn make the game more challenging
for certain players. The most important aspect is of course
to make sure that no player starts in a location that does not allow
for any growth or places the player at the mercy of other players.
1. Give each player equal (or similar) opportunity in the beginning
by giving all players the same starting conditions. 2. Make sure that
all possible starting positions in the game have the same (or similar)
opportunities.
Topic
Heuristic
Problem
Rating
Description
Solution
Balance & Strategies
The game should be fair
Players who have played for a while are superior to new players.
Important
Since the game must give players who has played for a while more
power it might be difficult for new players to catch up.
1. The approach to research (where players research new technology
faster if many of the other players already has the technology) is a
good start, but might need to be extended to buildings, resources
etc. 2. It might be possible to include a “new player” bonus that
gives new players bonuses that over time wears off (this bonus would
then become more and more significant during the game so that players
that join very late get more of a bonus that players who joined
earlier).
Topic
Heuristic
Problem
Rating
Description
Solution
Balance & Strategies
Play should be fair
Events can be considered unfair.
Important
The game allows for events that happen, such as earthquakes,
famines, and good years. If these events happen randomly to only a
few players they can feel unjustly treated. Even if all the players are
affected such (negative) events are not fair because they can not do
anything about them.
Warn players in advance if a negative event is about to happen and
make it possible for the players to avoid negative events. For example
can a player be warned that a famine will break out unless the player
does not build or upgrade the player’s farm.

173
Topic Balance & Strategies
Heuristic Player should not experience being penalized repetitively for the same
failure, Play should be fair
Problem Too much negative feedback for the looser in battles.
Rating Critical
Description In battles over cities, the loosing player will loose his/her army, plus
resources and perhaps the city. This leads to smaller ability to rebuild
an army to defend against later attacks. There is also no possibility
for a loosing player to retreat to rebuild if the war is happening in
his/her land. An attacking player can pillage a city as many times
he/she wants and steal resources before the defender has any chance
to build an army.
Solution -
Topic Balance & strategies
Heuristic The game supports different playing styles
Problem Playing styles is influenced by neighbors.
Rating Moderate
Description Even if a player wants to play peacefully, it will be hard to do if
his/her neighbors are constantly at war. It will also be hard to trade
if no other in the neighborhood is trading.
Solution -
Topic Balance & strategies
Heuristic The game supports different playing styles
Problem Limited effects of different styles
Rating Minor
Description There is a risk that a player’s choices will feel meaningless if he/she
can do everything. A common problem in online strategy games.
Solution -
Topic
Heuristic
Problem
Rating
Description
Solution
Setting & content
Include a lot of interactive props for the player to interact with
Not much to do.
Moderate
Most things in the game take some time to before they are performed,
so when a player has issued all commands there is nothing more to
do than wait.
Provide the player with something to do while he/she waits for an
army to move or a building to be built.

174 Chapter J. Found issues in heuristic evaluation
Topic
Heuristic
Problem
Rating
Description
Solution
Setting & Content
The game uses orthogonal unit differentiation
There is no mention of differences in how different units behave in
the simulated battles.
Critical
There is no description of how different units (archers, cavalry, and
infantry) behave in the simulated battles.
Make sure that the different units actually behave differently in the
simulated battles (archers should for example stay back and be able
to deal damage at a distance while cavalry should be able to use their
speed and weight to charge into enemy units etc.).
Topic
Heuristic
Problem
Rating
Description
Setting & Content
Include a lot of interactive props for the player to interact with
There are quite fixed and limited things that the player can interact
with.
Minor
The game contains a basic number of things that the player can
interact with (cities, armies and so on) and these never change. This
might lead to the player growing tired of the game since there is in
essence nothing new to do.
Solution 1. Give players who have played for a while new options and opportunities
(though this might be very difficult to balance if the new
options are to have an impact on the game). 2. Give the player
more power in terms of customization (that could be only visible).
For example, players might get the option to customize their family
members’ looks.
Topic
Heuristic
Problem
Rating
Description
Multiplayer issues
The game provides information about other players
The score of the players are only shown like an overall score and it is
not possible to see the land of other players (even the ones you are
allied with).
Moderate
Because of these limitations in the information there might be a feeling
of not being connected to the other players.
Solution Include additional information for the players. At least for allies.
Information that could be shown to everyone is origin (country), the
race of the other players family etc. These things would not disrupt
game balance but might still be interesting to know.
Topic
Heuristic
Problem
Rating
Description
Solution
Multiplayer issues
The design overcomes lack of players and enables soloing
One player in the game world is impossible
Minor
If there is only one player in the game it will be pointless to play. The
only challenge is then how long the player can wait before he/she gives
up.
Have many players.

175
Topic Multiplayer issues
Heuristic The design overcomes lack of players and enables soloing
Problem A player that wants to play without interacting with other players
will have a hard time.
Rating Minor
Description The game supports soloing to some extent; players do not have to
be in clans or communicate with each other. To play completely solo
will however be hard.
Solution -
Topic
Heuristic
Problem
Rating
Description
Solution
Multiplayer issues
The design minimizes deviant behavior
Cheating by collusion I, battles to gain experience (described by Yan
& Randell [56]).
Moderate
In the game, family members and units gain experience in battles.
This can lead to that two players constantly fight with each other to
gain an advantage over other players.
Make it more expensive to just fight than the gain will be.
Topic Multiplayer issues
Heuristic The design minimizes deviant behavior
Problem Cheating by collusion II, trading information (described by Yan &
Randell [56]).
Rating Moderate
Description In the game, not all information is known to all players. This can
lead to that players cooperate and trade information or sell it to
other players that should not have access to that information. It is
for examples easy to take a screenshot of an area that one player
knows and sell it to a player that does not know that area.
Solution -
Topic Other
Heuristic -
Problem Players can feel “trapped”
Rating Important
Description A player can get totally surrounded by other players’ land. This
limits his/her ability to explore the game world and he/she might
feel “trapped” in his/her kingdom. He/she is left in the mercy of
his/her neighbors if he she wants to travel their land to explore.
Solution Provide “free-zones” that no player can own so that they have the
ability to move and explore the map. Colonization (with a safe capital).

176 Chapter J. Found issues in heuristic evaluation
Topic Other
Heuristic -
Problem Players can not expand.
Rating Important
Description When a player gains more family members and want to expand with
more cities, there is a risk that his/her kingdom is surrounded with
other players’ cities. This forces the player to break up the kingdom
into several “islands”.
Solution Change kingdoms into colonies (with a safe capital).

Appendix K
Utvärderingsmanus för
fokusgrupper
Positivt/negativt
1. Vad är det bästa med spelet? Varför?
2. Vad är det sämsta med spelet? Varför?
Ekonomi
1. Hur upplever ni det att man som spelare inte har tillgång till alla resurser utan
måste handla eller kriga för att få tillgång till dem?
2. Hur upplevdes det att man ej kunde bygga resursstationer utanför området man
äger?
3. Vad anser ni om att handeln genomfördes utan någon valuta utan bara genom
byteshandel av resurser?
4. Tanken från början var att vissa byggnader skulle ha en löpande kostnad, men
detta kom inte med i prototypen. Vad anser ni om att ha löpande kostnader med
utgångspunkt i hur det fungerade i prototypen (dvs. utan löpande kostnader)?
Alltså: Är det något ni tror skulle bidra till att göra spelet intressantare?
5. Hur upplevdes antalet resurser (för många, för få, etc.)?
6. Andra synpunkter eller idéer om ekonomin och resurserna?
Karta
1. Hur upplevs det att spela ett sådant här spel på en karta (som i prototypen)? Dvs.
Hur upplever ni det när positionen avgör vilka spelare man främst konkurrerar och
177

178 Chapter K. Utvärderingsmanus för fokusgrupper
interagerar med? Abstrakta positioner så att alla spelare “kan komma åt alla” är
det bättre eller sämre?
2. Att gå omkring och utforska, hur upplevs det? Intressant eller inte intressant?
Vad skulle kunna göra detta mer intressant?
3. Andra synpunkter eller idéer om kartan och utforskningen?
Familj
1. Använde ni er av familjemedlemmarna?
2. Hur upplevdes familjemedlemmarna i prototypen?
(a) Erfarenhetssystemet
(b) Fokuseringen
(c) Effekten på spelet
(d) Nyttan eller bördan av dem
3. Om en familjemedlem skulle dö, hur skulle detta upplevas?
4. Andra synpunkter?
Städer
1. Ska man kunna erövra städer av andra spelare? Hur ska detta gå till?
2. Hur upplevdes systemet med population?
3. Hur upplevdes influensen städer emellan?
4. Hur upplevdes det att neutralt område automatiskt blev ens eget område när en
stad expanderade?
5. Andra synpunkter?
Strider och arméer
1. Hur fungerade det att strida med en fördröjd effekt?
2. Övriga synpunkter?

179
Tempo
1. Hur fungerade tempot i spelet? (För snabbt eller för långsamt, vilka delar?)
2. Hur fungerade längden på striderna?
3. Att skalan endast presenterades i “gametime”, hur upplevdes detta? Ska man visa
verklig tid och “gametime”, endast verklig tid eller endast “gametime”?
4. Andra synpunkter?
Extrafrågor
1. Om man utgår från prototypen, vad verkar då roligast eller bäst? Att det kontinuerligt
kommer expansioner med fler forskningar, resurser, byggnader med mera
eller att det finns ett slut på spelet?
2. Hade de olika raserna (och/eller dess antal) någon påverkan på upplevelsen?
3. Skulle ni kunna tänka er att betala för att spela ett liknande spel? Hur mycket?

180 Chapter K. Utvärderingsmanus för fokusgrupper

Appendix L
Resultat av utvärdering,
fokusgrupp 1
Antal deltagare: 2 st.
Positivt/negativt
1. Vad är det bästa med spelet? Varför?
– Bästa med spelet är upptäckandet (fara runt, upptäcka, hitta resurser och
andra spelare) och blandningen av raser på samma lag.
– Bra kompromiss mellan turn-based och real-time.
2. Vad är det sämsta med spelet? Varför?
– Listan med byggnader som kan byggas i staden är för otydlig eller eventuellt
för lång. Den som inte går att bygga än måste åtminstone markeras tydligare.
– Många byggnader i sig är bra, men det måste vara tydligare vilka som går
att bygga.
Ekonomi
1. Hur upplever ni det att man som spelare inte har tillgång till alla resurser utan
måste handla eller kriga för att få tillgång till dem?
– Det är bra att man inte har tillgång till alla resurser. Gör att man ej kan
“gömma sig i sitt hörn”.
– “Först blev jag irriterad”, men trade funkar.
– Trade är ganska anonymt, vilket är bra.
– Bra att messagesystemet finns så man kan förhandla.
181

182 Chapter L. Resultat av utvärdering, fokusgrupp 1
2. Hur upplevdes det att man ej kunde bygga resursstationer utanför området man
äger?
– Naturligt och bra.
– Fort skulle kunna vara bra då det är lite väl dyrt och svårt att expandera en
stad eller att bygga en ny.
3. Vad anser ni om att handeln genomfördes utan någon valuta utan bara genom
byteshandel av resurser?
– Fungerar bra. Det är inte särskilt komplicerat, speciellt då det går så snabbt.
4. Tanken från början var att vissa byggnader skulle ha en löpande kostnad, men
detta kom inte med i prototypen. Vad anser ni om att ha löpande kostnader med
utgångspunkt i hur det fungerade i prototypen (dvs. utan löpande kostnader)?
Alltså: Är det något ni tror skulle bidra till att göra spelet intressantare?
– Detta vore självklart bra, men det måste vara möjligt att kunna riva/stänga
de byggnader som kostar.
– Skulle förmodligen öka handel.
– Man skulle kunna slumpa kostnaden så att en byggnad kan kosta olika sorters
resurser för olika spelare. Det får förstås inte bli orättvist.
5. Hur upplevdes antalet resurser (för många, för få, etc.)?
– Antalet känns bra. Roligt att utforska och hitta nya etc.
– “Skulle nog vilja ha lite mindre”, men många kan nog vara tufft och realistiskt
om man gillar det.
– Om förädling ska vara med så är det här för många resurser.
6. Andra synpunkter eller idéer om ekonomin och resurserna?
– Att ha defaultresurser som ej “målas ut” på kartan fungerade bra.
Karta
1. Hur upplevs det att spela ett sådant här spel på en karta (som i prototypen)? Dvs.
Hur upplever ni det när positionen avgör vilka spelare man främst konkurrerar och
interagerar med? Abstrakta positioner så att alla spelare “kan komma åt alla” är
det bättre eller sämre?
– Mycket bättre med karta! Mer “territoriskt”. Man känner att man måste ha
soldater för att försvara.
– Man blir mer involverad.
– Det blir inte bara en topplista att tävla mot.
2. Att gå omkring och utforska, hur upplevs det? Intressant eller inte intressant?
– Intressant.

183
3. Vad skulle kunna göra utforskning mer intressant?
– Achievements vore kul.
– Någon form av bonus/achievements borde man få för utforskning.
– Events är bra (typ quests “Hjälpa handelsmannen”) Behöver inte vara stort
och häftigt utan kan vara ett enkelt val som resulterar i olika saker.
– Random enqounters.
– Det skulle kunna finnas “en grotta med en drake” i varje land eller andra
“småmysiga” grejer. Detta skulle kunna fungera som en smakprov på krig
utan att man behöver anfalla någon.
4. Att hamna i ett trängt läge, hur känns det?
– Att expandera kräver krig.
–
Är man trängd så måste man använda diplomati.
– Någon sorts frihet måste nästan finnas, det borde gå att ta sig ifrån det
trängda läget.
5. Andra synpunkter eller idéer om kartan och utforskningen?
– Båtar och floder saknas. Någon sorts “fri lejd” vore bra för att ta sig ur
trängda lägen (tex. genom att man alltid kan resa på floder även om de går
genom andras land).
Familj
1. Använde ni er av familjemedlemmarna?
– Lite grann, de är lite småroliga.
– Har döpt dem, skoj för en själv.
2. Hur upplevdes familjemedlemmarna i prototypen?
(a) Erfarenhetssystemet
– Rolig detalj.
– Skönt att det “balanserar ut” den ökande tiden för byggnader.
(b) Fokuseringen
– Ger en möjlighet.
– Det borde hända nått mer när fokus ändras. Porträtten kan tex. ändras.
(c) Effekten på spelet
– Känns som en “oavslutad” gren, men de borde vara kvar.
– Familjemedlemmarna kräver lite mer jobb. Kan utvecklas mer.
– De kan användas i events (det är de som ska utföra uppdrag).
(d) Nyttan eller bördan av dem
– “Har aldrig svurit åt dem i alla fall”.
– Spännande faktor.

184 Chapter L. Resultat av utvärdering, fokusgrupp 1
– Kollar någon gång per dag, lagom mycket tid som krävs.
3. Om en familjemedlem skulle dö, hur skulle detta upplevas?
– Enda sättet att få en personlig relation. Man bryr sig om dem. Annars är de
bara en axelryckning.
– Om de inte kan dö ska de ej heller få kunna röra på sig (och utforska etc.).
– Det ska vara en risk att skicka med dem i arméer.
4. Andra synpunkter?
– De borde ge mindre bonus i större arméer än i små arméer.
Städer
1. Ska man kunna erövra städer av andra spelare? Hur ska detta gå till?
– Ja, det är bättre än “småhackande”.
– Det är en fråga om hur “snällt” spelet ska vara.
– Man vill kunna erövra alla andra!
– Det är ett stort straff att bli av med en stad.
– Man borde få starta på en ny kula när man blir av med sin sista stad, men
man borde få någon bonus. Tex. få med sig research och lite resurser.
– Allianser skulle kunna rädda en om man blir av med sin sista stad.
– Spelet vinner inte på att vara ett evighetsspel, det borde komma till ett slut.
2. Hur upplevdes systemet med population?
– Störande att mana krävs för första nivån av tents.
– Ger inte något att ha det mer avancerat. Mer micromanagement behövs ej.
Tempo
1. Hur fungerade tempot i spelet? (För snabbt eller för långsamt, vilka delar?)
– Tempot var bra.
– “Småspela” är bra.
– Mer att utforska vore bra.
2. Att skalan endast presenterades i “gametime”, hur upplevdes detta? Ska man visa
verklig tid och “gametime”, endast verklig tid eller endast “gametime”?
– Speltid tillsammans med en procentmätare (som visar hur många procent
som är färdigt av tex. en byggnad) skulle räcka.
– En kalender där man kan se när olika saker blir klara skulle vara bra.
3. Andra synpunkter?
– Världen och spelet måste ha ett namn!
– Movement points skulle kunna vara bra.

185
Extrafrågor
1. Hade de olika raserna (och/eller dess antal) någon påverkan på upplevelsen?
– Antalet raser är bra, särskilt om det är så liten skillnad mellan dem.
– Raserna borde skilja sig åt mer.
– Skulle kunna vara fler raser ifall de hade fler olika egenskaper (så att de skiljer
sig åt mera).
– Man skulle kunna använda mindre kända raser (istället för klassiska fantasyraser).
Grafik och interface
– Symbolerna för järn och gems är ej tydliga. Rent allmänt kan ikonerna vara större
(inte på kartan nödvändigtvis, men åtminstone i resursförrådet och den detaljerade
info:n om tile:n).
–
Även textens storlek skulle kunna vara större.
– En “högerklicksmeny” borde inkluderas.
– Varmare färger vore trevligt.
– Vore bra att få ett mail-notify när något sker i spelet.
Buggar
– Man kan bygga det som redan håller på att byggas (tiden det tar att bygga det
en gång till går också åt).

186 Chapter L. Resultat av utvärdering, fokusgrupp 1

Appendix M
Resultat av utvärdering,
fokusgrupp 2
Antal deltagare: 4 st.
Positivt/negativt
1. Vad är det bästa med spelet? Varför?
– Byggandet och samlandet av resurser - kul med micro-management.
– Kul att bygga och använda långsiktigt planerande.
– Många resurser och handel är roligt.
2. Vad är det sämsta med spelet? Varför?
– Svårt att utforska (då varje armé går “ett steg i taget”, ej in i outforskat
område).
– Dålig AI (pathfinding).
– Striderna var ej tillfredsställande. Svåra att förstå.
– Forskningsträdet var svårt att förstå. Vad som behövdes och vad det gav.
Hade varit bra att se vad varje forskning bidrog med.
– Man måste klicka på byggnader (i städer) för att se om de går att bygga.
– Borde kunna dölja de byggnader som inte går att bygga just nu (borde
åtminstone vara tydligare).
– Måste gå att överleva i början (tex. genom en passiv mini-inkomst för de
grundläggande resurserna).
– Familjemedlemmarna hade för liten effekt.
187

188 Chapter M. Resultat av utvärdering, fokusgrupp 2
Ekonomi
1. Hur upplever ni det att man som spelare inte har tillgång till alla resurser utan
måste handla eller kriga för att få tillgång till dem?
– Underbart! Bra incitament för interaktion.
– Finns en viss risk för att det ska bli obalanserat.
– Man måste ha tillgång till trä och sten (de grundläggande resurserna).
2. Hur upplevdes det att man ej kunde bygga resursstationer utanför området man
äger?
– Störande i början.
– Blev bra sen.
– Extra knepigt när handel ej fungerade (i.e. ingen hade eller ville byta det
man behövde).
– Problemet försvinner nog med fler spelare.
3. Vad anser ni om att handeln genomfördes utan någon valuta utan bara genom
byteshandel av resurser?
– Bra.
– Bra när man har svårt att komma åt allt.
– Pengar behöver ej finnas.
– Räcker med byteshandel.
– Kan bli problem utan valuta, men det är charmigt.
– Värdering blir dock lättare om man har en valuta.
– En “trade-history” skulle kunna vara bra (där man ser vad saker sålts för
tidigare).
– Det borde finnas alternativ på vad man ska byta bort (tex., “jag säljer 200
glass för 50 wood, 100 stone eller 35 poppy”).
4. Tanken från början var att vissa byggnader skulle ha en löpande kostnad, men
detta kom inte med i prototypen. Vad anser ni om att ha löpande kostnader med
utgångspunkt i hur det fungerade i prototypen (dvs. utan löpande kostnader)?
Alltså: Är det något ni tror skulle bidra till att göra spelet intressantare?
– Skulle nog vara bra (var annars lätt att få max av många resurser).
– Kan användas för att balansera olika byggnader.
– Alltid bra med “underhåll”.
5. Hur upplevdes antalet resurser (för många, för få, etc.)?
– Bra. De grundläggande resurserna borde alla ha, men de mer speciella kommer
att komma in i spelet till slut.
6. Andra synpunkter eller idéer om ekonomin och resurserna?
– Det borde gå att skicka resurser “gratis”.
– Det borde vara en skillnad på hur bra raserna är på att samla olika resurser.
– En deltagare: Man borde kunna lagra lite av all resurser från början (åtminstone
så att alla resurser är “synliga”).

189
Karta
1. Hur upplevs det att spela ett sådant här spel på en karta (som i prototypen)? Dvs.
Hur upplever ni det när positionen avgör vilka spelare man främst konkurrerar och
interagerar med? Abstrakta positioner så att alla spelare “kan komma åt alla” är
det bättre eller sämre?
– Bra med karta, ger en till dimension.
2. Att gå omkring och utforska, hur upplevs det? Intressant eller inte intressant?
Vad skulle kunna göra detta mer intressant?
– Utforskandet är nu bara till för att hitta resurser och fiender, borde ge något
mer.
– “Tribal villages” vore ett incitament för utforskning.
– Då ownage radius ökar så mycket och gör att man ser mer så är utforskningen
tämligen onödig.
– Man borde kunna gå in i det outforskade (det skulle kunna vara endast scouts
som har den förmågan).
3. Andra synpunkter eller idéer om kartan och utforskningen?
– “Fog of war” borde sparas på servern och inte lokalt (blir problem när man
byter dator).
– Vägar kan “byggas överallt” vilket är onödigt. Alternativ är att man bara
bygger resursstationer och att dessa sedan automatisk kopplas till en stad
med väg.
–
Även outposts vore bra (för att kunna utnyttja resurser utanför sitt område).
– Trading routes till andra spelare skulle kunna vara intressant.
– Man borde kunna bygga vägar även utanför sitt egna område.
Familj
1. Använde ni er av familjemedlemmarna?
– Ja, följde deras “levling” noggrant.
– Lite otydligt vad de ger och man borde se skillnad på vad de gör och på
familjemedlemmarna i sig.
– All fokus låg på “building” (och sen på “research”).
2. Hur upplevdes familjemedlemmarna i prototypen?
(a) Erfarenhetssystemet
– “Hade ingen aning om att de kunde levla”.
– Man borde få ett meddelande/visas en markör när de levlat/kan levla.
(b) Fokuseringen

190 Chapter M. Resultat av utvärdering, fokusgrupp 2
– Det kändes som bra alternativ, men det borde finnas fler områden (tex.
att fokusera på resource gathering genom att ställa sig på en resource
station eller liknande).
(c) Effekten på spelet
– Man borde ha fler familjemedlemmar som det är större skillnad mellan
(tex. en väldigt stark ledare och en svag 5:e brorson).
– Namnfunktionen var kul.
(d) Nyttan eller bördan av dem
– Utan dem hade man blivit galen av de långa byggtiderna.
– Kul när de blev bättre.
– Det borde finnas mer interaktion med familjemedlemmarna (man borde
tex. kunna bygga hus, statyer etc. som gör dem bättre).
– Hus som ger fler familjemedlemmar skulle kunna inkluderas.
3. Om en familjemedlem skulle dö, hur skulle detta upplevas?
– Om det innebär att man även tappar en stad så vore det dåligt.
– Familjemedlemmarna borde kunna dö och blir det tomt i staden så borde den
få minus.
– Familjemedlemmar borde kunna dö.
Städer
1. Ska man kunna erövra städer av andra spelare? Hur ska detta gå till?
– Det är nödvändigt, men det borde finnas byggnader som ger försvarsbonus.
– Man borde kunna ta över städer med hjälp av influens.
2. Hur upplevdes systemet med population?
– Det märktes inte att populationen “tickade upp”. Det borde gå långsammare.
– Manpower var “billigt”.
– Bra system, det var roligt med byggnader som gav både procent och fixa
siffror.
– Soldater borde kosta “upkeep”.
– Det borde vara billigare att reparera trupper än att skaffa nya.
3. Hur upplevdes influensen städer emellan?
– Influensen borde ha mer effekt. Kan fungera som ett “fredligt” sätt att ta
över städer.
– Effekten på populationen skulle kunna vara endast negativ till fiender (och
både negativ och positiv till egna städer).
4. Hur upplevdes det att neutralt område automatiskt blev ens eget område när en
stad expanderade?

191
– Det kändes naturligt.
– Efter Civilization så var det vad som förväntades.
– Utforskandet borde dock ge mer att se (eller någon annan bonus) än att bara
öka ownage radius.
5. Andra synpunkter?
– Det borde synas vilken byggnad som är i kö.
– Köerna för både byggnader och soldater var dåliga.
– Bilder på alla byggnader vore bra.
– Research bör vara något mer (tabben var onödig, det skulle kunna läggas in
i första tabben).
– Soundtracket skulle kunna varieras beroende på befolkningen.
– Musik vore bra, men soundeffects behövs ej.
– Fast ändå skönt med lite “Yes my lord!”.
Strider och arméer
1. Hur fungerade det att strida med en fördröjd effekt?
– Bra, men det måste finnas bättre “reports”.
– Strider ska inte ske direkt, det skulle ge för stor bonus till inloggade spelare.
– Det borde finnas mer inställningar (defensive mode osv).
2. Övriga synpunkter?
– Plundringen var i stort sett onödig. Man borde kunna plundra specifika
resursstationer eller liknande. Väldigt jobbigt när man inte visste vilka
resurser man skulle få.
– Risken vid plundring är ganska stor, men det ger väldigt lite.
– Det skulle kunna finnas andra enheter som är snabba och bra på att plundra.
Tempo
1. Hur fungerade tempot i spelet? (För snabbt eller för långsamt, vilka delar?)
– Soldaternas tempo på att gå osv var ok.
– Forskningen gick för snabbt (eller tog åtminstone slut för snabbt), skulle
kunna delas upp i fler.
– En deltagare: Det fanns lite för lite att göra i början. Loggade in och hade
sen svårt att motivera sig till att komma tillbaka.
– I början spelade man 5 min och sedan hade man inget att göra.
– Borde åtminstone finnas mer info att läsa sig till i början.

192 Chapter M. Resultat av utvärdering, fokusgrupp 2
– När man ej aktivt klickade fanns det inget att göra.
2. Hur fungerade längden på striderna?
– Det får gärna ta ganska lång tid så man hinner se vad som händer.
– Bra att hinna märka vad som händer innan man dör.
3. Att skalan endast presenterades i “gametime”, hur upplevdes detta? Ska man visa
verklig tid och “gametime”, endast verklig tid eller endast “gametime”?
– Det är något man vänjer sig vid, men det vore bra att ha någon referens.
– Får gärna vara presenterat i verklig tid så blir det inga frågetecken, men då
tappar man lite av kopplingen till realismen (“4 dagar för att bygga väg’ blir
“3 timmar” eller liknande).
– Just i början förstod man inte “Vaddå 4 dagar för att bygga en väg?”.
Extrafrågor
1. Om man utgår från prototypen, vad verkar då roligast eller bäst? Att det kontinuerligt
kommer expansioner med fler forskningar, resurser, byggnader med mera
eller att det finns ett slut på spelet?
– Det ska ta slut.
– Saker ska ändras mellan omstarter.
– “Restart med expansioner”.
2. Hade de olika raserna (och/eller dess antal) någon påverkan på upplevelsen?
– Bra att ha olika raser, men de borde ge mer. Borde vara större skillnad
mellan dem.
– Man borde inte kunna få minus i vissa raser.
– Det skulle kunna finnas fler raser.
3. Skulle ni kunna tänka er att betala för att spela ett liknande spel? Hur mycket?
– Om det var mer färdigt så skulle en 20:a i månaden kunna vara acceptabelt.
– Man är dock försiktig med att betala till något obskyrt företag.
– Donationer och reklam kan vara alternativ.
– Det måste vara gratis från början för att få folk “hooked”.
– Man kan betala per omstart, men det kan få effekten att spelare struntar i
att spela mer.
Grafik
– Charmig grafik.
– Vattnet såg ut som “blå hål”.
– Osnyggt, fanns en del “skönhetsfläckar”.
– Mer “realistiska” färger (varmare) vore bra.

193
Övrigt
– Vatten borde ha någon betydelse.
– Första intrycket var lite “vad ska jag göra?”, men man kom in ganska snabbt i det
(det svåraste var kartan och förflyttningen).
– Det borde finnas en “Hall of fame” även efter restarts.
– Olika enheter skulle kunna beordras att gå olika långt (vissa kan gå 10 steg, andra
1 steg i taget).
– Påskägg vore roligt. Skulle kunna vara nya påskägg vid varje omstart.
– Bilder på städer, troll, resursstationer osv. borde inkluderas.
– Spelet måste heta något.

194 Chapter M. Resultat av utvärdering, fokusgrupp 2

Appendix N
Resultat av utvärdering,
intervju
Text inom citattecken är direkta citat.
Positivt/negativt
1. Vad är det bästa med spelet? Varför?
– Upptäckandet & byggandet.
2. Vad är det sämsta med spelet? Varför?
– Saknar en bank. Denna ska vara styrd av spelet och dess uppgift ska vara
att se till att det inte går att vara utan någon resurs. Den ska dock ta ut
ockerpriser så det ska löna sig att handla med andra.
– Interfacet måste göras om.
Ekonomi
1. Hur upplever ni det att man som spelare inte har tillgång till alla resurser utan
måste handla eller kriga för att få tillgång till dem?
– “Får man det att funka så kommer det att funka”.
2. Hur upplevdes det att man ej kunde bygga resursstationer utanför området man
äger?
– Känns naturligt.
3. Vad anser ni om att handeln genomfördes utan någon valuta utan bara genom
byteshandel av resurser?
195

196 Chapter N. Resultat av utvärdering, intervju
– Svårt att säga, men kändes inte konstigt i alla fall.
4. Tanken från början var att vissa byggnader skulle ha en löpande kostnad, men
detta kom inte med i prototypen. Vad anser ni om att ha löpande kostnader med
utgångspunkt i hur det fungerade i prototypen (dvs. utan löpande kostnader)?
Alltså: Är det något ni tror skulle bidra till att göra spelet intressantare?
– Löpande kostnad höjer värdet på resurser och handel.
5. Hur upplevdes antalet resurser (för många, för få, etc.)?
– Svårt att säga, men verkar bra. “Har inte klurat ut vad alla resurser ska
användas till än”.
6. Andra synpunkter eller idéer om ekonomin och resurserna?
– Man ska kunna handla med bara en spelare. Nu kan vem som helst anta ett
erbjudande som man lagt ut. Det ska också vara möjligt att kunna rikta ett
erbjudande till en enskild spelare som bara den spelaren kan acceptera.
– För att kunna bygga vissa byggnader så måste man ha vissa resurser.
– Dyra handelsmän med ockerpriser.
Karta
1. Hur upplevs det att spela ett sådant här spel på en karta (som i prototypen)? Dvs.
Hur upplever ni det när positionen avgör vilka spelare man främst konkurrerar och
interagerar med? Abstrakta positioner så att alla spelare “kan komma åt alla” är
det bättre eller sämre?
– Karta var jättebra, saknar dock en minimap för att kunna hålla reda på alla
enheter.
2. Att gå omkring och utforska, hur upplevs det? Intressant eller inte intressant?
Vad skulle kunna göra detta mer intressant?
– Utforskning är intressant.
– Man ska kunna skicka in folk i outforskat område.
3. Andra synpunkter eller idéer om kartan och utforskningen?
– Speciella utforskartrupper, till exempel kartritare. Dessa ska röra sig mycket
snabbare än en armé men inte kunna slåss.
– Interfacet ska vara kopplat till vilka trupper man har.
Familj
1. Använde ni er av familjemedlemmarna?
– Ja, först som trupp och scouta och sedan som byggherrar.

197
2. Hur upplevdes familjemedlemmarna i prototypen?
(a) Erfarenhetssystemet
– Jättebra. Kul att kunna levla up i områden man fokuserar på. Även
roligt att kunna distribuera erfarenhetspoäng.
(b) Fokuseringen
– Jättebra. Antalet fokus var lagom. Saknar inte något fokusområde.
(c) Effekten på spelet
– Intressant. De har lagom effekt. Har man mer fokus på dem så kommer
spelet att kretsa enbart på dem.
(d) Nyttan eller bördan av dem
– Bra.
3. Om en familjemedlem skulle dö, hur skulle detta upplevas?
– Dör de så sätter man värde på dem.
4. Andra synpunkter?
– Familjemedlemmar ska kunna dö i krig.
– Man ska kunna lönnmörda andra spelares familjemedlemmar. Detta skulle
kunna genomföras genom att man betalar ett speciellt gille. Det ska dock
inte vara lätt och spelare ska kunna skydda sig från lönnmördare.
Städer
1. Ska man kunna erövra städer av andra spelare? Hur ska detta gå till?
– Man ska kunna ta en stad, men den ska vara förstörd. Det vill säga att det
får inte finnas några byggnader i den. Det ska dock vara lätt att bygga upp
en ny stad om man förlorat en.
– I ett annat spel så går befolkningen i “migration mode” när deras sista stad
erövras. Detta betyder att hela befolkningen reser sig med vapen och blir
jättefarlig. De befinner sig i detta tillstånd till de har hittat en plats att
bygga en ny stad på eller tagit någon annans stad. Detta gör att det inte blir
värt att ta någons sista stad.
– Ett annat alternativ är att man bara krigar om resursstationer.
– Man kanske inte tar staden utan bara kan beskatta den under en viss tid.
2. Hur upplevdes systemet med population?
– Känns okej.
3. Hur upplevdes influensen städer emellan?
– Har inte tänkt på det.
4. Hur upplevdes det att neutralt område automatiskt blev ens eget område när en
stad expanderade?

198 Chapter N. Resultat av utvärdering, intervju
– Logiskt.
5. Andra synpunkter?
– Eventuellt så skulle man kunna bygga “watchtowers” som ger en liten area
av ägande även utanför stadsgränsen. Då kan man kanske få en resursstation
även om man inte kan/vill expandera stadsgränsen.
Strider och arméer
1. Hur fungerade det att strida med en fördröjd effekt?
– Fungerar bra. Dock bara stridit en gång så inte riktigt säker.
2. Övriga synpunkter?
– Coolt att arméer kan fly. Då förlorar man inte allt om man skulle förlora en
strid.
Tempo
1. Hur fungerade tempot i spelet? (För snabbt eller för långsamt, vilka delar?)
– Kändes bra.
2. Hur fungerade längden på striderna?
– Bra, men bara stridit en gång.
3. Att skalan endast presenterades i “gametime”, hur upplevdes detta? Ska man visa
verklig tid och “gametime”, endast verklig tid eller endast “gametime”?
– Charmigt med skalan i endast gametime. Presenteras tider i verklig tid så
bryts illusionen.
Extrafrågor
1. Om man utgår från prototypen, vad verkar då roligast eller bäst? Att det kontinuerligt
kommer expansioner med fler forskningar, resurser, byggnader med mera
eller att det finns ett slut på spelet?
– Spelet skulle må bäst av att ta slut. Med ett poängsystem så skulle man
kunna jämföra sig med andra i slutet på spelet.
– En spelare ska kunna initiera ett spel. Denne kan då välja antalet spelare
samt längden på spelet. Då skulle man kunna spela kompismatcher.
2. Hade de olika raserna (och/eller dess antal) någon påverkan på upplevelsen?

199
– Ja, men de borde ha mer inverkan på spelet för att göra nytta. Olika styrkor
och svagheter är bra. Troll kan till exempelvara bra i stenbrott och vara
farliga med klubba, man kan aldrig bli bågskyttar.
– Tre raser räcker.
3. Skulle ni kunna tänka er att betala för att spela ett liknande spel? Hur mycket?
– Tror inte att man skulle betala för spelet. Det är bättre att det är finansierat
med reklambanners.