First Case Study 1 Setting

An unreleased commercial single player first person shooter console game was subjected to single player user testing for approximately one hour per player. At the request of the

development team, 9 players were recruited from two informally identified demographic groups: 5 self-identified mainstream gamers (more casual gamers who play occasionally) and 4 core gamers (experienced gamers who play FPS games frequently). Only a portion of the game was completed to a level of quality indicative of the final product, and only these sections were tested. Testing was conducted over 3 days in a GUR lab. Participants played the game on an Xbox 360 connected to a HD (high-definition) television. Video cameras recording the player sitting positions, biometrics kit capturing the player’s GSR and real-time footage from the game console was simultaneously streamed to the observation room next door. All feeds were

composited together on a single display and recorded for later analysis. The games producer, and GURs monitored the participants’ play from the observation room. The GURs had spent some time familiarising themselves with the game before the test sessions, and the producer was able to identify when players were not playing the game as intended.

Each session was conducted by one player at a time; before the session started, the players received a brief explanation on the session, signed the consent form and NDAs, GRS sensors were fitted and they were asked to relax for few minutes in order for the signals to be tested and stabilised. They then played the game for about one hour. After the gameplay, GSR sensors were detached, and the players were asked to draw their experience diagram. The GURs then interviewed the players (e.g., asking about their likes and dislikes), and after this short interview the players were asked to review their gameplay video on the GSR selected events; the GURs noted player’s verbal explanation on those selected events.

Following the user testing, a text report was produced by the GURs who ran the session. The report listed gameplay issues encountered by each participant, as well as some additional design recommendations. As for the focus of this thesis, a BioSt was also drawn manually (by the thesis author), visualising issues identified and reported in the text report. At this stage, the interest was to evaluate how game developers interpret and use the BioSt. The next section provides a brief overview of gameplay issues identified from the user testing, followed by an explanation of the first BioSt prototype.

1 The three case studies detailed in this chapter were conducted on commercial under-development titles. Due to the NDA (non-disclosure agreement) requirements the names of the titles and any recognisable information has been removed. For the purpose of this thesis, the focus of these case studies was to evaluate the BioSt prototypes in real-case scenarios and not on the quality of identified gameplay issues as a result of user testing.

Although the focus of this chapter is not on quantifying the gameplay issues uncovered during the user testing, the overall identified gameplay issues are briefly mentioned for each case study to give context to BioSt prototypes.

Results from the user testing show that both casual and core gamers reported similar

experiences of the game, both groups found the enemies AI (artificial intelligence) were quite easy to beat and players often set their own challenges (e.g. only use headshots). Hence, players played the game like any other FPS and didn't feel the need to use unique features of the game. In the build tested, there were several events when gameplay became frustrating and led to boredom, these sections were consistent for both core and casual gamers. Overall 61 gameplay issues were identified.

Key Positives:

• Open world combat - the ability for players to take their own route enhanced the tactical feel.

• Enemy variety - different types of enemies helped make the game feel unique. • Atmosphere - audio and music seems effective at inducing excitement or tension. • Pacing - regular periods of combat (once past the initial tutorial section).

Key Issues:

• Feature X - players did not use the feature X and ended up treating the game like a standard FPS.

• Clear objectives - players became frustrated when they were not sure where to navigate or their objectives were not clear.

• Tutorial - the tutorial covered the basic movement mechanics, but the unique features of the game (such as feature X) were not thoroughly introduced.

• Level readability - several key areas of level design were identified as causing frustration, players could not determine where to go or what to do.

4.3.3 Biometric Storyboards First Prototype

Following the user test sessions, a BioSt was created of each level for two random players. Figure 4-5 shows an example of BioSt’s first prototype. Each vertical line is one minute of gameplay, peaks in the graph line can be positive or negative (e.g. enjoyment or frustration), comments have been coloured in green or red respectively to help identify the player reaction. For example, if the word ‘combat’ is written in green and is associated with a peak in the graph then this would indicate the player was aroused by fighting. However, if ‘combat’ is written in

Therefore, positive comments are in green and negative are in red. In-game screenshots are shown beneath the graph as visual cues of where the player is in-game (the screenshots are also removed to the game developer’s NDA).

Figure 4-5 Example of BioSt’s first prototype

This first prototype was divided by time. The feedback from the game development team suggested that this design of BioSt was difficult to compare between players. Time is not always meaningful for some games, and segments (or thematic areas) were considered more representative, as used in the second prototype. The game development team also commented that the use of in-game screenshots did not provide any useful information, as the team is familiar with game/level events and there was no need for visual cues of where the player was in the level.