Solving Usability Problems in Video Games with User Input Heuristics

Transcription

1 Solving Usability Problems in Video Games with User Input Heuristics Honours Project Carleton University School of Computer Science Course: COMP 4905 Author: Sikhan Ariel Lee Supervisor: David Mould Date: April 15th, 2010

2 ABSTRACT There are common problems that exist in video games today which limit positive game play. Even with a large team of tester, it is difficult to find all relevant issues. Additionally, some of these problems may be based on user preference or skill level. Usability problems can turn a challenging game from fun to frustrating. This honours project focuses on finding problems that the system could resolve if it knew that the player was experiencing them. This report lists and explains a set of these problems, suggests possible solutions to these problems, and explains the implementation of a small subset of these solutions to an existing game as a proof of concept. This involves the game system predicting or detecting what aspect of the game the player is confused by, and then having the system modify the game to fix the predicament. The development of these solutions involved first investigating player input and generating a set of heuristics, implementing these heuristics within the game, and then performing a final test to refine the heuristics. 2 P a g e

3 ACKKNOWLEDGEMENTS For all of the kind assistance that was provided to me for my honours project, I would like to thank David Mould for his guidance and support. For providing the XNA tutorials for this project, I would like to thank Nick Gravelyn for Alien Aggressors, and Riemer Grootjans for Flightsim. Last but not least, I wish to thank all independent testers for their input, as this project would not have been possible without their contributions. 3 P a g e

4 TABLE OF CONTENTS ABSTRACT...2 ACKKNOWLEDGEMENTS...3 LIST OF FIGURES...5 INTRODUCTION...6 USABILITY PROBLEMS AND USER INPUT HEURISTICS...7 Usability Problems...7 User Input Heuristics... 7 A list of usability problems...8 PROJECT DEVELOPMENT...10 Finding a Suitable Game...10 Testing...11 Problem Investigation #1: Game difficulty is unsuitable for the current player...12 Initial Testing...12 Development of Solution...12 Final Testing...13 Problem Investigation #2: Not sure which direction to go...14 Initial Testing...14 Development of Solution...14 Final Testing...15 CONCLUSION...15 REFERENCES...17 APPENDIX...18 Questionnaire given to testers...18 Sample of data collected from game P a g e

5 LIST OF FIGURES Figure 1: Screenshot of Flight with compass...11 Figure 2: Compass and compass needle P a g e

6 INTRODUCTION There are common problems that exist in video games today which limit the positive experiences of a user when playing through a game, adding confusion as to how to proceed. A video game should be challenging for the player, but usability problems which are irrelevant to the actual game, such as a character getting stuck to a wall, or a player not know where to go next, can turn a challenge from fun to wearisome. There are heuristics available which garner general design principles that developers may use for designing a game [Nielsen, 1994], but even with a large team of testers, it is often difficult to predict all the usability issues which will arise. This honours project focuses on finding problems that the system could resolve if it knew that the player was experiencing them. This report lists and explains a set of these problems, suggest possible solutions to these problems, and implement a small subset of these solutions to an existing game as a proof of concept. This involves the game system predicting or detecting what aspect of the game the player is confused by, and then the system modifying the game to release the user from the frustrating predicament. Of the list of problems mentioned in this report, two of the problems have been implemented for this project. They are the problems of the game being too difficult for the player, and the user not knowing which direction to go. The development of these solutions involved first investigating player input and generating a set of heuristics, implementing these heuristics within the game, and then performing a final test to refine the heuristics. 6 P a g e

7 USABILITY PROBLEMS AND USER INPUT HEURISTICS Usability Problems Usability problems are problems that impede the player in learning, controlling, or understanding a game [Pinelle et al., 2008]. Frustration can be fun, but confusion is not fun [Clanton, 1998]. Game developers should do their best to ensure that the problems players are facing during game play are the problems that the developers intended for the game. Challenge is one thing, but when the user cannot move beyond a point in the game, the enjoyment of the game greatly decreases [Pinelle et al., 2008]. Heuristics based on literature and reviewed by playability experts are certainly helpful for discovering usability issues, but as Desurvire et al. observed, general user testing of a game has the advantage of highlight specific issues such as "boredom, challenge and pace level" that may not be uncovered by design principles [2004]. An additional difficulty to this problem is that each individual user may have different preferences, or different tolerances as to what is difficult and what is enjoyable. Initial testing may provide important heuristics as to what the general usability problems of a game are, but what better input to use than the end user's? There are usability problems that can be solved by predicting the rise of the problem, and thus preventative measure can be put in place to trigger a solution response when the problem happens. An examples of this is the player getting stuck to a wall (#1). There are also usability problems where the solutions are due to the preference of the player and should be more dynamic, such as the game difficulty being unsuitable for the current player (#5). By detecting the player's activities within the game, these problems can be solved, although the former has a clear solution (freeing the player), while the latter is much more subjective. A balance much be struck between making the game too difficulty versus making the game too easy. For both, though, the challenge is in discovering heuristics. User Input Heuristics User input may involve any form of user input device, such as the user pressing a button on a controller. It may involve the results of a player's action during a game (i.e. crashing into a building). It may also involve information gathered from the hardware that the player has connected to the game console prior to the game (i.e. monitor resolution). All these forms of inputs can be used to detect when a usability problem arises, and can be used to create the solution to the problem. The heuristics generated from user input may deal with heuristics for detecting the problem, heuristics for solving the problem, or both. 7 P a g e

8 A list of usability problems The following is a list of usability problems and some basic, possible solutions for each problem. This list was collected from various gamers as well as from literature, and is not definitive. Listed are problems in which a player is frustrated by or confused by the game; they are problems that may be solved by the game system by evaluating user input. In no particular order: 1. Player getting stuck to an object or wall Problem: The player model becomes trapped inside an inanimate object due to faulty collision detection. Solution: If the player appears to be attempting to move in many directions, but is not actually moving, trigger a check to see if anything is being drawn at the same location as the player model. If so, move the player model over accordingly. 2. Objectives or missions of game are not clear Problem: The player is unsure of the next step they must make to further the game, or is unsure of how to proceed with the next step. Solution: If the player has not completed the desired objective in x amount of time, display a hint helps them to figure out what they need to do. The hint could be text at the bottom of the screen, or suggested by another character of the game. 3. Player unaware of the need to use a special item Problem: The player does not realize that to continue with the game, they must use a special item, or must acquire a special item in order to use it. Solution: If a special item is required and in the player's inventory, prompt for its use, or have the system use it automatically. If it is not found in the player's inventory, the player is informed of the item they require and/or where to find it. 4. Player unsure of which direction to go Problem: Player is aware of where they must go, but is unsure of how to get there. Solution: If the player is x distance from the desired target area for y amount of time, display an arrow indicating where to go. 5. Game difficulty is unsuitable for the current player Problem: Player either finds the game too difficult, or too easy. Solution: If the player loses life x times within y amount of time, or is not able to hit a target after z amount of attempts, either prompt the player and ask if they wish to lower the difficulty, or automatically change the difficulty to suit the player. 6. Player shooting at target and continually missing Problem: Player is shooting at an enemy target, but keeps missing the target. Solution: If a player consistently misses enemy targets for x amount of time, and autotarget is available, prompt user to enable an auto-target. If auto target is not available, change the enemy by making it bigger, slower, or easier to hit somehow. 7. Objects that can be interacted with look the same as objects that can't Problem: Player may become confuse by interacting with objects that don't do anything, or miss interacting with objects that are crucial, because they look the same. Solution: If the player is x distance from an object for y amount of time, place an effect such as an outline around the object to give the player a cue that they can interact with it, and keep this consistency throughout the game. 8 P a g e

9 8. Tiny text that player cannot read Problem: Player may become stuck when they are unsure of or cannot read what is written on screen as it needs a special resolution to read. Solution: When the game starts, the game should pre-emptively detect the resolution of the monitor it is outputting in and scale text accordingly. 9. Puzzles that require technically precise movements Problem: Occasionally for certain puzzle games, users will have the right idea of how to solve a particular puzzle but may have trouble executing the precise actions. Solution: After the user performs correct key combinations x times, or after y length of time, a prompt should come up asking if the user would like to skip the puzzle. 10. No collision detection for animations Problem: If a walking animation plays when character is against a wall, this may lead to confusion if the player believes that they may be able to keep walking. Solution: When the player collides with an object, switch to a different animation such as one of the character standing still or performing an animation such as pushing if appropriate. 11. Drawing glitches and clipping when objects overlap Problem: Player may be confused as to what to do or how to react when the glitches and clippings occur. Solution: This can be solved by having collision detection based on several shapes making up the model, or on individual vertices of the models, but this may be too resource intensive to do. If it is necessary, a bounding box based collision detecting can be used, and if a bounding box collides with something, then switch to checking for collision by each vertex. 12. Player forgetting what has occurred in a game Problem: If a player has not played the game for a long time, they may forget how to proceed. Solution: A timestamp is associated with each save file. When the user attempts to load a file, If the user has not loaded that save for x amount of time, display a brief overview of the game's story preceding the save point to refresh the player's memory. 13. Player missing important audio cues due to ambient noise Problem: Player may miss important audio cues from other characters due to ambient noise. Solution: If the player is located x amount away from an audio cue, tone down the ambient noise by y amount and raise the other character's audio by z amount. 9 P a g e

10 PROJECT DEVELOPMENT Finding a Suitable Game Flightsim, A 3D target shooting flight simulation game, and Alien Aggressors, a 2D space invader type shooter game, were used as the base source code for my project. Flightsim is a game where the aircraft is perpetually in motion, and the player has to try to find and hit at many regenerating stationary targets as possible and avoid hitting the buildings at the same time. As for Alien Aggressors, the game was used for its game states and menus, as Flightsim is always in playing mode (no states or menus). Originally, every time the aircraft crashed into a building the player would die. This was adjusted so that the player had to crash into a building multiple times to die. Further adjustments included restraining the rotations of the aircraft to suit the nature of this project. Additionally, the building heights and locations were modified to heighten the level of difficulty for search. After all initial adjustments, the game, from now on referred to as Flight, involved shooting at a defined number of targets for each level of the game (3 levels total), generated at random locations. The player must navigating thought a maze of buildings in order to find the targets and destroy them. 10 P a g e

11 Figure 1: Screenshot of Flight with compass Testing Testing involved various players at 3 skill levels: novice, intermediate, and expert. The players were required to play the game in its initial state, then one again with the adjustments made. For each version of the game, a file was outputted with the various statistics of the game, and additionally a questionnaire was filled out in which the user had to rate the difficulty and enjoyment level of various factors of the games. For difficulty, the scale was from 1 to 5, 1 being the easiest and 5 being hardest. For enjoyment, the scale was one again from 1 to 5, 1 being boring or frustrating and 5 being exciting (see Appendix for sample of user input and questionnaire). 11 P a g e

12 Problem Investigation #1: Game difficulty is unsuitable for the current player For the first investigation of the "game difficulty being unsuitable for the player" (#5), the problem with Flight was that it was not flexible in its difficulty. The problem involved the player continually crashing into buildings, and continually missing the targets, which were red spheres. The game being too difficult was essentially narrowed down to two problems: changing the speed that aircraft was moving at, and changing the difficulty of hitting the targets. This problem actually ended up including problem #6, "player shooting at target and continually missing". Initial Testing The first test consisted of the investigation of how many times a user crashed into a building or target per minute over the period of the game. The number of crashes throughout a game was recorded. Observations as to how players missed targets was, which mainly involved passing them due to speed. This would happen on an average of 1-2 times on targets, sometimes none. The number of bullets fired was originally recorded to determine whether the player missed the target, but it was discovered that a couple of testers would simply hold down the space key for an extended period of time. The results were skewed and are not included. The number of targets hit was also recorded. Initial: Building Crashes: 3.4 buildings/minute Target Hits: 1.8 targets/minute Speed of flight: Difficulty = 4.2, Enjoyment = 3 Hitting Target: Difficulty = 3.4, Enjoyment = 3.4 Development of Solution The solution involved two major parts: adjusting the speed, and adjusting the difficulty of hitting a target. The solution developed in regards to speed involved decreasing the speed whenever the user hit a building. The aircraft had the potential of becoming very slow, so to counteract this, every 15 seconds the speed was increased by multiplying by 1.06, with the speed varying between approximately 0.5 and 1.5. The development for adjusting the difficulty of hitting the targets has two components: adjusting the radii of the targets, and detecting whether to change the size of the target. Adjusting the radii of the targets was simply a matter of running through the target array and changing all their sizes. When a player hits a target with a bullet, the size of all the targets are decreased to make the game more 12 P a g e

13 challenging. It was discovered that the targets were much harder to hit when they became smaller though, and the difficult part was detecting when to increase the size of the target. The radius of the target varies between approximately 0.08 and 0.5. A fairly decent indicator for whether the player passed a target was whether a player had been very close to the target. This itself was not sufficient though, as some players pass a target without seeing it (it may be close, but hidden from view), and this would generate a false size increase. Therefore, an additional check was added to make sure that the user had attempted to fire a bullet to hit the target. If a player had fired bullets, and was close to the target, then a pass count is added to the target. This check happens once every second. After a certain number of passes (2), the target size increases. TargetDistance, ChangeTargetSize, OnTargetTimerEvent, and OnSpeedTimerEvent were a few of the functions created to solve the problem. Final Testing Players were generally satisfied with the incremental speed increase, though most said the final speed was too fast. It is now changed to 1.2. No one had complaints about the target size, and this may have been skewed due to their focus on speed. As the results show, the building crashes decreased but the target hits stayed about the same. It may be worth it to test speed and target size separately to see if it garnered a larger different, rather than lumping them both in "difficulty is unsuitable for player". Overall, enjoyment stayed the same of increased. Final: Building Crashes: 2.3 buildings/minute Target Hits: 1.9 targets/minute Speed of flight: Difficulty = 3.1, Enjoyment = 3.9 Hitting Target: Difficulty = 3, Enjoyment = P a g e

14 Problem Investigation #2: Not sure which direction to go The second investigation involved the problem of the player being unsure of which direction to go, or the user being unsure of the location of the targets. The game involves working through the maze of buildings to find targets to shoot at, and while targets are initially found easily, the last couple of targets are usually harder to find. (#4) Initial Testing Initial testing consisted of timing how long it took the users to become frustrated at not finding a target. Average time to get frustrated looking for target: 1.2 minutes Initial: Finding Target: Difficulty = 4.4, Enjoyment = 2.2 Development of Solution The solution for this problem involves 2 parts. The workings of the compass, and the timing behind when the compass appears. The compass works using the basic NESW system. In game, the "N" (see Figure 2) always points towards "north", and when the aircraft rotates, so does the compass. The compass needle (see Figure 3) points towards the nearest target. This is done by running through all the targets on update, and upon finding the nearest target, calculating its orientation relative to the aircraft. The aircraft's rotation is then addedd to the rotation of the needle. Figure 2: Compass and compass needle As for the timing behind the compass, the compass is originally hidden for view. If a certain amount of time has passed without the player hitting a target, then the compass will appear. This was set to 1.2 minutes in accordance with initial testing. However, if a player finds and hits a target before 1.2 minutes is up, the timer will reset itself. 14 P a g e

15 OnCompassTimerEvent, ClosestTargetLocation, and TargetDistance are a few of the functions added in to support this solution. Final Testing After final testing, users stated that they preferred the time to wait for the compass to appear to be shorter (less than 1 minute was stated by several testers, and it is now set at 30 seconds). The result is that the enjoyment of the task has increased. Final: Finding Target: Difficulty = 3, Enjoyment = 3.7 RESULTS The results was that with the implementation of varying speed from 0.5 to 1.5 (later changed to 1.2), the user's satisfaction increased from 3 to 3.9. Implementation of the timed compass showing up 1.2 minutes (later changed to 30 seconds) also increase the user's enjoyment from 2.2 to 3.7. As the difficulty rating of both these factors decreased, it may be appropriate to say that within certain bounds, decreasing difficulty could increase enjoyment. In the case of speed, initially it was going too fast for most people, and when the solution was implemented players enjoyed it. For the timed compass, finding the target took too long initially. As for the target change size, and being measured for the number of times it was passed, the enjoyment stayed about the same. It could be that the results were skewed because it was lumped with speed in the category of the difficulty not suiting the user, it could be the way it solution was implemented, or perhaps this is a factor that isn't important to players. CONCLUSION In video games, the positive experiences of a user is affected by the usability problems that are encountered. There are general design principles available, but even with a large team of testers, it is often difficult to predict all the usability issues which will arise. Therefore, if a game had factors implemented to find problems that the system could resolve if it knew that the player was experiencing these problems, the enjoyment level of the game would increase. This project focused on finding problems that the system could resolve if it knew that the player was experiencing them, provided a sample of these problems, and suggested some solutions and heuristics that may be of use. While this project is on a small scale, it has proven to be a success, although the 15 P a g e

16 project also shows that there are some factors that a player's enjoyment of a game may be more sensitive to. Testing is a cornerstone in game development, and if resources are available, having the system resolve issues based on user input will add value to the player's experience. 16 P a g e

17 REFERENCES Clanton, C. (1998) An interpreted demonstration of computer game design, CHI 98 conference summary on Human factors in computing systems, p.1-2, April 18-23, 1998, Los Angeles, California, United States Caplan, M., Desurvire, H., Toth, A.T. (2004) Using heuristics to evaluate the playability of games, CHI '04 extended abstracts on Human factors in computing systems, p , April 24-29, 2004, Vienna, Austria Gravelyn, N. (2010, April 14) Alien Aggressors: The Making of a Complete Game with XNA Game Studio 2.0. Retrieved from Grootjans, R. (2010, April 14) Riemer's XNA Tutorials for C# - 3D Series 2: Flightsim. Retrieved from Nielsen, J. (1994) Enhancing the explanatory power of usability heuristics, Proceedings of the SIGCHI conference on Human factors in computing systems: celebrating interdependence, p , April 24-28, 1994, Boston, Massachusetts, United States Pinelle, D., Stach, T., Wong, N. (2008) Heuristic evaluation for games: usability principles for video game design, Proceeding of the twenty-sixth annual SIGCHI conference on Human factors in computing systems, p , April 05-10, 2008, Florence, Italy XNA Creators Club. (2010, April 14) XNA Creators Club Online. Retrieved from 17 P a g e

18 APPENDIX Questionnaire given to testers Please rate the following: Controlling the craft at the speed in the game: Difficulty easy hard Enjoyment boring/frustrating exciting Effort spent in finding a target: Difficulty easy hard Enjoyment boring/frustrating exciting Effort spent in hitting a target: Difficulty easy hard Enjoyment boring/frustrating exciting Sample of data collected from game Note: the first number behind the event (i.e. bullet) is the time the event occurred at Bullet Bullet Target Passcount: Target Hit Target changed radius: Bullet Target Hit Target changed radius: GameSpeed: GameSpeed: Compass on: GameSpeed: Bullet Building/Target Crash Building/Target Crash Building/Target Crash Bullet Bullet Target Hit Bullet Target Passcount: Bullet Target Passcount: P a g e

19 Target changed radius: Target Hit Target changed radius: Bullet GameSpeed: GameSpeed: Target Passcount: Target Hit GameSpeed: GameSpeed: Building/Target Crash Compass on: Compass on: Bullet Target Passcount: Target Hit GameSpeed: GameSpeed: Bullet Target Passcount: Target Hit GameSpeed: GameSpeed: Bullet Bullet GameSpeed: GameSpeed: Bullet Target Hit Building/Target Crash P a g e