Evaluating User Experience in Games: Concepts and Methods - Lirmm

More documents

Recommendations

Info

114 G. McAllister and G.R. White tentatively called ATV Pure, which avoided realistic sports simulation in favour of informal, social, off-road racing. The final concept, called simply Pure, was only settled upon by the time the team were halfway through pre-production. Each of the preceding versions contributed some design features to the final game, but many were prioritised so low that they were never included in the released title. The design strategy for Pure was to focus on implementing a few core features to a very high standard, rather than attempting many features to a lesser standard. By 12 months into the development cycle, the team had fixed their vision for the game and were only addressing issues that supported four key aspects: massive airborne tricks, customisable vehicles, 16-player online games and so-called “FHMs” (which for the purposes of this chapter we will describe as “Flying High” Moments). These FHMs represent the core experience of Pure: When the player drives round a corner at high speed, only to realise that what they thought was just a bump in the road turns out to be the edge of a cliff face, leaving them flying thousands of feet up in the air. This is not only a highly exciting part of the game, but also a key mechanic as it allows the player plenty of time to perform tricks in the air, which eventually results in a higher score and other rewards. These concepts were graphically documented in a number of ways specific to Black Rock, but which have similar implementations in other studios. An important tool for summarising the concept of the game and keeping the team on track is the X-Movie, used by some of the world’s largest games publishers such as Electronic Arts. The X-Movie for Pure was a video showing a bike rider on an off-road race track jumping high into the air. Black Rock maintained the idea of “X marks the spot” when it came to their “Core Idea Sheets”. These were large display boards hung around the team’s development area showing the four key game aspects superimposed onto a bull’s-eye target. At the centre of the target was the FHM feature, as this was intended to represent the essence of the entire game. It is worth highlighting that this essentially puts the user experience (or excitement), as the single most important criteria for the game. 7.4.1.4 Alpha to Release For Pure, Black Rock did not employ a QA team throughout the entirety of the project, instead they used only one or two testers in the month leading up to Alpha. From Alpha, this was increased to five staff to deal with both the Xbox 360 and PS3 versions of the game (which were simultaneously developed). Furthermore, the QA team were only concerned with addressing functional testing rather than questions of usability or user experience. 7.4.1.5 Post-launch The publisher’s marketing team conducted studies after the game had been released and sold most of its units. The purpose of these studies was to identify what consumers liked or did not like about the game and what made them purchase it. Similar themes were discussed with consumers who did not purchase the game.
7 Video Game Development and User Experience 115 After release of the game, some informal analysis was conducted on official reviews and user comments on forums. Avent asserts that with the exception of some aspects of the garage, few usability issues were mentioned in game reviews. Most users’ comments related to features that were intentionally excluded by the team for practical reasons (such as the excessive technical overhead of including replays and split-screen multiplayer). 7.4.1.6 Understanding the User Pure was the first title on which Black Rock employed usability tests. They began running tests with company staff, careful to choose people who were not in the development team. They then expanded to recruit other people who worked in the same building as them, but who were not part of their own company. Finally, the most substantial tests began with members of the public, recruited directly from the streets and local universities. In total, around 100 participants were involved over the course of 4 months, of which the final month was only concerned with quantitative analysis of the game’s difficulty level and any issues that would prevent players from completing the game. The only requirements for recruitment were that participants were 14–24 years old, male, and owned at least one of the current generations of console, i.e. they were likely candidates to make a purchase. Tests were run in-house, in regular office space separated from the development teams. Up to eight players would be present simultaneously, with one supervisor for every two to three players. One of the supervisors was responsible for taking notes, and no video data were captured as this was considered too difficult to analyse due to the very large volumes produced. Black Rock conducted “blind testing”, meaning that testers had never played the game before, and several different categories of testing were devised: – Free flow: This is an unguided test where the player is encouraged to play the game however they wish. This is particularly useful for giving an impression of how much fun the game is, because as soon as the game becomes boring they would be inclined to stop playing. – Narrow specific: In this mode, the player would only play a single level and they might play it multiple times in order to measure their improvement with familiarity. This appears to be similar to vertical prototype testing employed in usability evaluations. – Broad specific: Similar to the narrow specific test, but playing over many levels. This seems similar to horizontal prototype testing in usability evaluations. Most of the development team also had visibility of the playtests, but generally it was only designers who observed the sessions. Avent reflects that it may have been helpful for more programmers and artists to also have been involved with observation earlier on. Despite the absence of video data, one of the programmers in the team had implemented “instrumentation” for the usability tests. This is the process of recording
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:
Page 59 and 60:
Page 61 and 62:
Page 63 and 64:
Page 65 and 66:
Page 67 and 68:
Page 69 and 70:
Page 71 and 72:
Page 73 and 74:
Page 75 and 76:
Page 77 and 78:
Chapter 4 Assessing the Core Elemen
Page 79 and 80:
4 Assessing the Core Elements of th
Page 81 and 82:
Page 83 and 84:
Page 85 and 86:
Page 87 and 88:
Page 89 and 90:
Page 91 and 92:
Page 93 and 94: 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 108 and 109: 78 E. Brown could be simulated on p
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 146 and 147: 116 G. McAllister and G.R. White qu
Page 148 and 149: 118 G. McAllister and G.R. White te
Page 150 and 151: 120 G. McAllister and G.R. White 7.
Page 152 and 153: 122 G. McAllister and G.R. White te
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 177: 8 User Experience Design for Inexpe
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?