Evaluating User Experience in Games: Concepts and Methods - Lirmm

More documents

Recommendations

Info

78 E. Brown could be simulated on paper; however, the type of experience the player would have would not necessarily be comparable. SingStar (SCEE 2004) is a Karaoke game for the PlayStation. Players sing along to the music and their vocal skills are rated. Paper prototyping the game mechanic in this case would not help understand the potential experience in any meaningful way. On the other hand, a game like SimCity is a different prospect. SimCity (Electronic Arts 2004) allows players to build a city, its roads, and buildings. They decide the layout and where industrial areas will be placed, what departments get funding, and how many fire stations there are. All of their decisions impact the happiness of the SimCity people (e.g., the congestion on the roads). A paper prototype of this game would be able to replicate the core mechanic and allow its evaluation much more easily than with SingStar. At this stage, the core concept of the game is documented. The rules and components mapped out. From this, the designer can develop their prototype, either by creating and printing cards, pieces, and boards or by using existing boards and the new rules. With the example of SimCity a board can be created, the player can be given a limited amount of money and spend it on tiles to build roads, residential areas, and industrial zones. To simulate the time aspect, an egg timer can be used. Each time the timer empties, the player gets money from investments and the city grows. With this simple starting point, the core workings of the game can be explored. Which elements affect each other and how these are made obvious can be examined. Then slowly layers of complexity can be added to the core. Once this prototype is at a playable state, the designer can give it to others to play. They have to explain the rules and resolve any confusion or conflict. In doing so, they quickly find any flaws or loop holes that mean players can’t win or can cheat intolerably (because sometimes cheating is acceptable as long as it doesn’t ruin it for everyone). They find out what makes sense to players (e.g., do they understand how road layouts affect traffic congestion? If not, how does the game teach them this?). The designer not only learns the weaknesses in the game, but also learns how to teach it. They learn how players can break it with unpredictable actions (Henderson 2006). Whether they learn about the enjoyment of the game is up for debate. They learn what is fun in the paper version; however, the difficulty is then trying to transfer that experience to the digital platform. It is a matter of looking at the type of enjoyment taking place. Is the player enjoying the physical element of the game? Or from another perspective, is there something lacking in the paper version that can be enhanced in the digital version? Answering these questions allows them to continue to refine the concept and understand its strengths and limitations. 5.3.1.2 The Tech Demo The tech demo is a very different proposition. It may be that the technology is core to the concept and the game play has to be formed around it. To explore how tech demos are used in aiding the evaluation process, this section will look specifically at EyeToy.
5 The Life and Tools of a Games Designer 79 EyeToy is a USB camera that connects to the PlayStation and faces the player. It allows players to interact with specific games through motion rather than buttons and controller. As a camera, it has several limitations. For example, its ability to detect motion can be hampered by light conditions, such as a dark room. Not only are there technical constraints due to the environment, but there is also the player to consider. There is a huge gulf between the player and the technology. The interface between them has to be extremely responsive to user action. It has to show the user what is possible and reinforce the right kind of actions. The players have to know what the game is looking for. They need to know if the camera is looking for any movement or a specific kind of movement. Not only do players need to understand what is required of them, but the movement required has to be fun. To find this out there needs to be something to play with. So the tech demo is the combined test of the robustness of the technology and its potential for fun. These demos can start as a technical concept, such as a button that detects and reacts to the player’s motion. Or they can be toy concepts, for example each motion detecting “button” is represented as a ball on screen and they are attracted to player when they move. These can be tested, both for their ability to cope with variable light conditions and for their ability to be fun. Designers play with the demos and begin to form game mechanics around them. For example, thinking that if the balls were attracted to motion, then some can be made red and some blue and the game is to separate them. Thoughts like this can be explored and the demos enhanced into more fully featured prototypes. While doing this, designers are starting to decide how to develop the simple tech demos with more fully fledged game mechanics. A majority of the time, they are doing this purely by playing with the demo and imagining the potential experience. Do they have fun while playing with it? Is the experience reminiscent of other games or experiences they have enjoyed? When other team members approach the demo, how do they react? All these aspects contribute to the designers understanding the potential of the experience. Informal user evaluations can take place at this stage, where members of other teams are invited to play and evaluate the experience. These evaluations allow designers to see through the eyes of a new user. How do they make sense of the technical limitations? If the buttons don’t always react as the user expects, how do they rationalize this? From these limited user evaluations, designers can see what actions players can understand, the movements players enjoy making, and which ones frustrate them. They can also see how players react the first time they encounter the demo and the exploration patterns they use. Watching users play with these demos allows designers to start understanding how to communicate the workings of the technology and to consider whether the hurdle is too great for the experience to be fun. Tech demos are just another way of letting designers explore potential game experiences and try to see the experience through the eyes of the player. If you can show a segment of game play to someone for the first time and see them smile and laugh as they explore it, then that is enough to know whether there is potential for something even greater.
Page 2 and 3:
Human-Computer Interaction Series E
Page 4 and 5:
Regina Bernhaupt Editor Evaluating
Page 6:
For Philippe
Page 9 and 10:
viii Foreword Chapter 3, Presence I
Page 11 and 12:
x Foreword personality which evolve
Page 14 and 15:
Contents Part I Introduction to Eva
Page 16 and 17:
Contributors Regina Bernhaupt IRIT,
Page 18:
Contributors xvii Manfred Tscheligi
Page 21 and 22:
xx About the Authors Emily Brown is
Page 23 and 24:
xxii About the Authors a post-docto
Page 25 and 26:
xxiv About the Authors Christina Ko
Page 27 and 28:
xxvi About the Authors MIT Media La
Page 29:
xxviii About the Authors Theft Auto
Page 33 and 34:
Chapter 1 User Experience Evaluatio
Page 35 and 36:
1 User Experience Evaluation in Ent
Page 37:
1 User Experience Evaluation in Ent
Page 41 and 42:
Chapter 2 Enabling Social Play: A F
Page 43 and 44:
2 Enabling Social Play 13 It is als
Page 45 and 46:
2 Enabling Social Play 15 observati
Page 47 and 48:
2 Enabling Social Play 17 for playe
Page 49 and 50:
2 Enabling Social Play 19 to provid
Page 51 and 52:
2 Enabling Social Play 21 Colwell J
Page 53 and 54:
Chapter 3 Presence, Involvement, an
Page 55 and 56:
3 Presence, Involvement, and Flow i
Page 57 and 58: 3 Presence, Involvement, and Flow i
Page 77 and 78: Chapter 4 Assessing the Core Elemen
Page 79 and 80: 4 Assessing the Core Elements of th
Page 101: 4 Assessing the Core Elements of th
Page 104 and 105: 74 E. Brown (2005). Björk and Holo
Page 106 and 107: 76 E. Brown 5.2.3 How We Work Toget
Page 110 and 111: 80 E. Brown 5.3.2 Pre-production At
Page 112 and 113: 82 E. Brown from the code. This is
Page 114 and 115: 84 E. Brown At this point, there is
Page 116 and 117: 86 E. Brown Game developers have be
Page 119 and 120: Chapter 6 Investigating Experiences
Page 121 and 122: 6 Investigating Experiences and Att
Page 135: 6 Investigating Experiences and Att
Page 138 and 139: 108 G. McAllister and G.R. White Th
Page 140 and 141: 110 G. McAllister and G.R. White su
Page 142 and 143: 112 G. McAllister and G.R. White of
Page 144 and 145: 114 G. McAllister and G.R. White te
Page 146 and 147: 116 G. McAllister and G.R. White qu
Page 150 and 151: 120 G. McAllister and G.R. White 7.
Page 154 and 155: 124 G. McAllister and G.R. White an
Page 156 and 157: 126 G. McAllister and G.R. White Al
Page 158 and 159:
128 G. McAllister and G.R. White Ne
Page 161 and 162:
Chapter 8 User Experience Design fo
Page 163 and 164:
8 User Experience Design for Inexpe
Page 165 and 166:
Page 167 and 168:
Page 169 and 170:
Page 171 and 172:
Page 173 and 174:
Page 175 and 176:
Page 177:
Page 180 and 181:
150 K. Poels et al. in games. This
Page 182 and 183:
152 K. Poels et al. their game char
Page 184 and 185:
154 K. Poels et al. If we apply thi
Page 186 and 187:
156 K. Poels et al. Participants ge
Page 188 and 189:
158 K. Poels et al. 9.3.2 Exploring
Page 190 and 191:
160 K. Poels et al. If our train is
Page 192 and 193:
162 K. Poels et al. would be intere
Page 195 and 196:
Chapter 10 Evaluating User Experien
Page 197 and 198:
10 Evaluating User Experience Facto
Page 199 and 200:
Page 201 and 202:
Page 203 and 204:
Page 205 and 206:
Page 207 and 208:
Page 209 and 210:
Page 211 and 212:
Page 213:
Page 217 and 218:
Chapter 11 Evaluating Exertion Game
Page 219 and 220:
11 Evaluating Exertion Games 189 pr
Page 221 and 222:
11 Evaluating Exertion Games 191 th
Page 223 and 224:
11 Evaluating Exertion Games 193 to
Page 225 and 226:
11 Evaluating Exertion Games 195 co
Page 227 and 228:
11 Evaluating Exertion Games 197 11
Page 229 and 230:
11 Evaluating Exertion Games 199 an
Page 231 and 232:
11 Evaluating Exertion Games 201 11
Page 233 and 234:
11 Evaluating Exertion Games 203 to
Page 235 and 236:
11 Evaluating Exertion Games 205 Ac
Page 237:
11 Evaluating Exertion Games 207 Pa
Page 240 and 241:
210 M. Brown et al. challenges that
Page 242 and 243:
212 M. Brown et al. was also happen
Page 244 and 245:
214 M. Brown et al. Another importa
Page 246 and 247:
216 M. Brown et al. Albinsson and Z
Page 248 and 249:
218 M. Brown et al. asked to report
Page 250 and 251:
220 M. Brown et al. Table 12.2 Mean
Page 252 and 253:
222 M. Brown et al. Table 12.7 Cont
Page 254 and 255:
224 M. Brown et al. Table 12.9 Cont
Page 256 and 257:
226 M. Brown et al. Count 450 400 3
Page 258 and 259:
228 M. Brown et al. feedback. Thus,
Page 260 and 261:
230 M. Brown et al. Desurvivre H, C
Page 263 and 264:
Chapter 13 Using Heuristics to Eval
Page 265 and 266:
13 Using Heuristics to Evaluate the
Page 267 and 268:
Page 269 and 270:
Page 271 and 272:
Page 273 and 274:
Page 275 and 276:
Page 277 and 278:
Page 279 and 280:
Page 281 and 282:
Page 283 and 284:
Page 285 and 286:
Page 287 and 288:
Index A Advanced interaction games,
show all

Evaluating User Experience in Games: Concepts and Methods - Lirmm

Create successful ePaper yourself

Delete template?

Save as template?