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

More documents

Recommendations

Info

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.
Page 1: Designing a persistent online strat
Page 5 and 6: Contents 1 Introduction 1 1.1 Defin
Page 7 and 8: CONTENTS v 8 Result of the implemen
Page 9 and 10: CONTENTS vii Appendix C Manus till
Page 11 and 12: Chapter 1 Introduction The purpose
Page 13 and 14: 1.3. Goals 3 of the gameplay and on
Page 15 and 16: Chapter 2 Methods This chapter expl
Page 17 and 18: 2.3. Focus groups 7 questionnaires
Page 19 and 20: 2.6. Evaluation 9 observe users int
Page 21 and 22: Chapter 3 Requirements engineering
Page 23 and 24: 3.3. The Non-Functional Requirement
Page 33 and 34: 3.4. Eliciting requirements 23 - Fo
Page 35 and 36: 3.4. Eliciting requirements 25 unst
Page 37: Chapter 4 Models & methods for eval
Page 41 and 42: 4.4. Playability and gameplay 31 is
Page 43 and 44: 4.5. Flow 33 difficulty of the task
Page 45 and 46: 4.5. Flow 35 Figure 4.3: The optima
Page 47 and 48: 4.7. Player experiences in games 37
Page 49 and 50: 4.8. Methods for the evaluation of
Page 51 and 52: 4.8. Methods for the evaluation of
Page 53 and 54: Chapter 5 Pre-study This chapter pr
Page 55 and 56: 5.6. Result of the brainstorming 45
Page 57 and 58: 5.8. Result of the focus groups 47
Page 59 and 60: 5.8. Result of the focus groups 49
Page 61 and 62: Chapter 6 Result of the pre-study S
Page 63 and 64: 6.2. Examples of dropped ideas 53 n
Page 65 and 66: 6.2. Examples of dropped ideas 55 -
Page 67 and 68: Chapter 7 Implementation of the fun
Page 69 and 70: 7.3. System architecture 59 7.3 Sys
Page 71 and 72: 7.3. System architecture 61 Figure
Page 73 and 74: Chapter 8 Result of the implementat
Page 75 and 76: 8.1. Overview of the prototype 65 A
Page 77 and 78: 8.1. Overview of the prototype 67 F
Page 79 and 80: 8.1. Overview of the prototype 69 w
Page 81 and 82: 8.1. Overview of the prototype 71 8
Page 83 and 84: 8.1. Overview of the prototype 73 W
Page 85 and 86: 8.1. Overview of the prototype 75 F
Page 87 and 88: Chapter 9 Evaluation This chapter d
Page 89 and 90:
9.3. Focus group evaluation 79 Anot
Page 91 and 92:
9.4. Result of the focus group eval
Page 93 and 94:
Chapter 10 Resulting design documen
Page 95 and 96:
10.4. Timescale 85 - Forts. Forts a
Page 97 and 98:
10.8. Encounters 87 10.8 Encounters
Page 99 and 100:
10.12. Cities 89 10.12.1 Buildings
Page 101 and 102:
10.14. Resources 91 10.13.1 Race at
Page 103 and 104:
10.15. Family and family members 93
Page 105 and 106:
10.17. Conquest and expansion 95 10
Page 107 and 108:
10.18. Battles 97 captured. The pla
Page 109 and 110:
10.21. Diplomacy 99 is of course al
Page 111 and 112:
10.24. Issues that needs to be reso
Page 113 and 114:
Chapter 11 Discussion & Conclusion
Page 115 and 116:
11.2. Future work 105 A forum was l
Page 117 and 118:
Chapter 12 Acknowledgements We woul
Page 119 and 120:
References [1] Arsenault, D. DARK W
Page 121 and 122:
REFERENCES 111 [28] Johnson, B., an
Page 123:
Appendices 113
Page 126 and 127:
116 Chapter A. Pre-prototype game s
Page 128 and 129:
Page 130 and 131:
Page 132 and 133:
Page 134 and 135:
Page 136 and 137:
Page 138 and 139:
Page 140 and 141:
130 Chapter B. Enkät Vad/vilka del
Page 142 and 143:
132 Chapter C. Manus till brainstor
Page 144 and 145:
134 Chapter D. Resultat - brainstor
Page 146 and 147:
136 Chapter D. Resultat - brainstor
Page 148 and 149:
138 Chapter E. Resultat - brainstor
Page 150 and 151:
140 Chapter E. Resultat - brainstor
Page 152 and 153:
142 Chapter F. Manus för diskussio
Page 154 and 155:
144 Chapter G. Frågor som måste b
Page 156 and 157:
146 Chapter G. Frågor som måste b
Page 158 and 159:
148 Chapter H. Annoterade idéer ti
Page 160 and 161:
Page 162 and 163:
Page 164 and 165:
Page 166 and 167:
Page 168 and 169:
Page 170 and 171:
Page 172 and 173:
Page 174 and 175:
Page 176 and 177:
166 Chapter I. Heuristiker för utv
Page 178 and 179:
168 Chapter J. Found issues in heur
Page 180 and 181:
Page 182 and 183:
Page 184 and 185:
Page 186 and 187:
Page 188 and 189:
178 Chapter K. Utvärderingsmanus f
Page 190 and 191:
180 Chapter K. Utvärderingsmanus f
Page 192 and 193:
182 Chapter L. Resultat av utvärde
Page 194 and 195:
Page 196 and 197:
Page 198 and 199:
188 Chapter M. Resultat av utvärde
Page 200 and 201:
Page 202 and 203:
Page 204 and 205:
Page 206 and 207:
196 Chapter N. Resultat av utvärde
Page 208 and 209:
198 Chapter N. Resultat av utvärde
show all

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

Create successful ePaper yourself

Delete template?

Save as template?