Archive for the ‘Game Usability’ Category
100 Rogues – Playability Heuristics Review
In the words of the Fast Show, this week I’ve mostly been playing 100 Rogues. I’ve never previously been able to get into Rogue-likes, having only played games in this genre briefly, before being scared off by the dungeon crawler’s core mechanics of ‘odds stacked against you’, ‘if you die you lose’, and ‘you will die’. However, 100 Rogues aims to present an accessible Rogue-like, ideal for someone who hasn’t played before. As accessibility is one of their key design goals, a heuristic based playability review seems appropriate.
This review aims to evaluate the playability of the game, including pertinent usability issues, and the effect this has on player experience. This is especially important, given 100 Rogues’ mission of making a difficult genre accessible. I’ve based the review on the heuristic points identified by Heather Desurvire’s paper ‘Using Heuristics to evaluate the playability of games’
What this review doesn’t cover is non-usability or player experience issues. Hence, it’s not a review of the game itself (which I gather is a pretty standard Rogue-like). It’s also not QA, and so doesn’t cover bugs in the game. This is especially important as 100 Rogues has infamously been plagued with a number of bugs since its release last week. The first version would crash if the player equipped a shield. The fix for this introduced several new bugs. And I still haven’t been able to get defeat the first boss without the game killing my player after I’ve defeated the boss. I gather the developers are working on this though.
100 Rogues
Game Play
Game play covers the game’s goals, and player’s involvement in achieving these. 100 Rogues succeeds in many areas here. Crucially, it guides the player through their first steps, and introduces them to the range of actions available to them, by immediately giving them the ability to level up their player, which is reinforced by the low cap for the second level up, allowing the player to practise this mechanic twice within the first 2 minutes of the game.
More complex actions are also introduced to the player, through the game’s challenge mode – a series of short scenarios where only the use of an advanced technique (such as ‘tele-stabbing’) will succeed. These introduce the player to some of the more complex moves available to them, in an intuitive way (rather than just… telling them)
The game handles the inevitable death of your character well, also. As mentioned previously, when playing a Rogue-like, you only have one life, no reprieves, and you will die. They explain this by likening the game to Tetris – the goal with your one life is to see how far you can get, not to reach the ‘end’. However death in any specific situation is never inevitable and the game always seems fair. This isn’t Mario Kart, where the CPU will always cheat at the last moment. Instead, after every death you’ll always believe that you could have done something differently and survived, and hence the game encourages a ‘one more go’ attitude to playing, and challenge comes off as a positive experience.
The only game play element which seems poorly balanced, and takes some of the control away from the player, is the ‘food’ mechanic. If you don’t eat food, your character dies. Makes sense. And sometimes you cannot find anything but rotten food, which will fill you up, but reduce your maximum HP. That’s fine too, if it’s a choice between being weakened, and death. But sometimes the game will spawn no food at all. And then you’re stuck, and nothing you can do will save your character from death. This looks like it needs to be balanced in future games, so the game at least spawns some food (rotten or not) when the player is critically hungry. As it stands, the player doesn’t feel in control of their destiny, and has no ability to prevent their character from dying.
Pictured: 100 Rouges
Story
Story defines how your characters’ actions fit into the world you are presented with and the feeling that the game-space exists as a real world, which you can affect, but which exists without you.
The story in 100 Rogues is simple. Satan is at the bottom of the dungeons, and you must kill him. Why? Because he’s Satan.
This story is introduced by a cut scene at the start of the game, and loading text gives character-related background, however this is where the player’s involvement in the story ends. The in game content, and enemies don’t reflect this final goal (aside from the end boss), and the character development isn’t plot related. Occasional infighting among the enemies gives the potential for further depth within the story, however this is not explored further. Ultimately, like Tetris, the story of ‘why’ you are doing this is not a focal point of the game.
Mechanics
Mechanics covers consistency in how the game reacts, how the AI acts, and how the player controls their character. The AI in the game is a success, with the NPC’s acting consistently, and yet occasionally surprising the player – such as when an archer’s miss-fired arrow will hit another enemy, and they will start battling it out. Hence the game balances allowing the player to understand how NPC’s react, without making them entirely predictable.
The game allows the player to track their own progress, through in game score/stats, and a global high-score table. Although implementation of this isn’t perfect, as I’m not convinced scores are being posted to the internet, the bug has been noted and is being ‘worked on’.
An area where the mechanics of 100 Rogues fails is with its controls. The character is controlled by touching the screen – touch the screen at the top to make the player go up, or touch an enemy to attack them. However, with no confirmation before an action is taken, and no indication of the active areas for each target, I found myself ‘miss-clicking’ numerous times, with often deadly consequences. Hence, when trying to click on an enemy for a ranged attack, I’d instead walk towards them, putting my character in danger. Restricting the range of actions available on a single click, or making ‘attack’ a double click, may help alleviate some of these issues.
Must be my sausage fingers...
Usability
Usability concerns how the game gives feedback for inputting actions, and whether they can achieve their goals. A success for 100 Rogues is how it saves the game state on quit, allowing the game to continue from the last point, as I’ve discussed before
As I discussed above, the game also gives direction to a first time player, by giving them an introduction to levelling up on game start. However, it hinders play the second time you start by… giving the same introduction. Since the game demands multiple play-throughs, I feel that I have grasped this mechanic the 20th time it has been introduced to me.
Conclusion
As has been made clear by a heuristic evaluation of 100 Rogues, the game has a high degree of playability, and provides an accessible entry point to a traditionally difficult genre. As noted, there is room for improvement, yet the game offers significant advances on other games in this genre.
However, I’d be hesitant to recommend the game, as it stands, as a positive player experience. Although, playability shouldn’t include bugs, bugs will undoubtedly have an effect on player experience. Hence, as the game stands, the unexpected crashes and deaths will detract from player’s opinions of the game. What incentive do players have to give the time and effort of playing, when their character could be taken away from them through no fault of their own?
That said, the development team have been dedicated to fixing bugs – having released two patches in the week after the game was released, and are promising up to two-three times more content released periodically, which is an advantage of the iPhone as a platform. Within a few more iterations, I can see this game being the definitive introduction to the Rogue-like genre.
The importance of usability in Mobile Geolocation games.
Mobile geolocation games are a hot topic right now. The popularity of the iPhone, the potential for geolocation in HTML5, the geographic API integration with Twitter, and the rise of games like Gowalla and Foursquare all point to a significant shift in people’s perceptions of the potential of geolocation. I’ve recently been involved in the design of a geolocation game, and have seen the potential of the medium, as well as the usability lessons which must not be forgotten when designing multiplayer games with location in mind.
Working in a small group at the University of Sussex, and in conjunction with the Brighton based mobile games company Locomatrix, we designed and prototyped a game that uses location as a game-play element. Unlike currently popular games, like Gowalla, we wanted the game to be immediate, and played as a short, fixed-term game, not an ongoing campaign. Hence, after evaluating several ideas, we developed a ‘Predator’ style game, where the players are hunted, and turned into hunters, until only one survivor remains.
Pretty much like Willy Wonka & The Chocolate Factory
Into every step of production of the game’s design we aimed to integrate usability and user experience tools. For example, the initial design of the game was based on a survey sent out to a group of prospective players, with their results collated to inform elements such as the game’s multiplayer element, objectives, and artistic style.
In the iterative prototype development cycle, user research was conducted. From the first paper prototypes, to the final JavaScript version of the game, real players were brought in, and asked to play the game. Their reactions and observations were noted by invigilators, and further developed through post-test questions. Hence, even before we had a playable version of the game, it was possible to test player’s reactions, and deal with problems earlier, rather than later, where they would cost a lot more time to resolve.
An early geolocation prototype
So what did we learn about mobile geolocation games? Exactly the same things that should be considered for any sort of product development.
We discovered the issue that was most crucial for the mobile geolocation game is considering the context in which the game will be used. The game we made was designed to be played outdoors, fast paced, and possible in a busy city. Hence the game’s interface needs to make this easy. We ended up with
- Very few buttons (one most of the time, a second one when you can tag a player)
- Large buttons (takes up half the screen)
- Audio cues associated with important activities, such as when the player is in danger, or when the can perform an action.
So, instead of having to stare at the screen all the time, the player is free to look at their surroundings, and only involve the phone when given an audio cue that they can act. They won’t need to hold their phones in front of their face as they play – crucial for not being mugged! And when they need to act, they can do so quickly and easily, not impeding the game-play.
The interface, which could have proved a huge barrier to a ‘fun’ game, has been minimised, as a consideration to the context in which the game is played. This was discovered as the optimal method through iterative prototypes and tests with users, and is heavily dependent on the type of game. A minimal interface may not be ideal for all applications (consider a first person shooter with one button), and yet the context of a geolocation game allowed it to succeed here.
So, what lessons could we take from the development of this game? More important than the discovery that outdoor mobile games work best with a minimal interface is the method used to make this discovery. Involving users brings advantages no matter what product is being made, or what stage production has reached. From the first paper prototypes, we could see the interface players preferred, and hence reduce development time and cost. The time ‘cost’ of involving users is greatly outweighed by the time it saves from redundant coding. And everyone can see the advantage of that!
Understanding players through biometrics
Last week UXBrighton hosted an event focused on Biometrics, which featured an interesting presentation by Vertical Slice. Pejman Mirza-Babaei presented his PhD research on the application of biometrics to help understand a player’s experience when playing games. This was presented as a ‘guerrilla’ method, since it was a speedy and rough implementation, not a definitive and comprehensive methodology.
We’ll be looking at what biometric research is, how it can be applied to games research, and the problems that became apparent with this method.
What is biometric research?
Biometrics are traditionally an automated way of recognising, or recording, peoples physiological data, or characteristics. To apply this to video-games readings were taken by Vertical Slice by hooking players up to machines which record their heart rate, brainwaves, or galvanic skin response (…how sweaty their skin is, presumably). It’s proposed that there is some correlation between how their bodies react, and how the player is feeling – such as how a player’s heart will beat faster while fighting Gunther Hermann’s Skull Gun or scoring a tetris.
Pejman Mirza-Babaei has been investigating how this can be applied to games research. Working with Vertical Slice, he is interested in measuring the player experience – how to know when players are having fun, or becoming frustrated, and so has been performing studies to see the feasibility of measuring this with biometric data. By having players play either Haze, or Modern Warfare 2, while hooked up to this machine, maybe it’s possible to gain a greater insight into the player’s thoughts, and how they feel when playing.
And in a non obtrusive way...
What did biometric research show?
When playing the games, the player’s heart rate and GSR ratings (that sweatiness rating) were recorded along with a video of the player, and of their screen. What was found from the biometric readings, at the simplest level, was when the player’s heart rate went up. The researcher would then conduct an interview after the gaming session, and ask why the heart rate went up at those points, for the player to justify the measurements.
We saw examples of these spikes when the player enjoyed, or was frustrated by, a task (such as using a machine gun, or getting stuck looking for a vehicle), and were given the player’s justifications for feeling like this.
The most obvious advantage of this method is that it allows a more natural environment to be created for the player. Since biometrics doesn’t require distracting the player by asking them to perform a think-aloud, or by interrupting their game by asking questions and yet still having a degree of insight into how they are feeling, a more natural game play experience can be achieved, without stopping useful data from being gathered.
Problems with biometric research on games
However, some limitations on the application of this technology became obvious through the presentation. Biometric data (in its current form) doesn’t give any insight into why the player’s heart rate has spiked, just that it has. This problem is exacerbated by the single range of readings it can give – there is no way to distinguish between stress and happiness (or any other reasons a heart rate can spike).
such as exciting vehicles
Because of this, biometric readings have to be justified by another method, to give some understanding as to why the heart rate spikes at certain moments. Traditional UX methods, such as a post-test interview, are therefore needed in addition to biometric readings. However this reintroduces traditional UX problems. A player may not be able to accurately remember why they felt excited at a certain moment, and as pointed out by Sam Nixon, may simply justify their opinion by what they see on screen.
For example, the player may explain a heart rate spike caused by audio cues as being caused by the enemy visible on screen when the clip is shown later, missing the real reason for their excitement.
Conclusion
So biometric readings alone cannot tell us what a player is thinking. Hence they cannot (currently) be a replacement for traditional UX methods.
What biometric readings can do, is aid the application of current UX methodologies. When combined with tools such as think aloud, or interviews, they can add weight to the findings. For a think aloud, it can tell you which parts of the game particularly affected the player, and hence what comments to pay attention too. Similarly with interviews, biometric research can pinpoint the areas that the player should be asked about. When used in combination with typical UX tools, biometric research can be justified and have some understanding applied to its findings.
There is amazing potential in the application of biometric data to games. Currently, the ‘AI director’ in Left For Dead controls the game based on how the player is doing – giving less zombies to fight if the player is doing poorly, or making the game harder, and giving the player some nasty surprises, if they are doing well. Imagine if a system like this could take biometric data into account, and change the game experience based on how the player was feeling. Vertical Slice have begun to show us the potential of this technology, and I feel we’re at the start of an exciting journey.
Get Lost! – Improving player experience through signposting and map design in games.
Feeling in control is an important part of a player’s experience of the game. This doesn’t solely mean the control methods being used, but also a player’s understanding of where they are, and where they are going. Ensuring that a player isn’t lost is an important part of managing the player experience. Today I’ll be covering some examples of this done well, and badly, some methods that can be used to ensure the player doesn’t feel lost, and the advantages of taking care of the player’s experience.
Games often encompass huge areas, from tetris’s 440×440 pixels to the 2000km² of Second Life. Obviously, when the playing area is so large, effective navigation becomes an issue, with special care being made to ensure the player never feels like they are lost. But its not just massively multiplayer games that need to consider how to lead a player, every game needs to get the player to their goal. Failure to deal with navigation will prevent the player from progressing, and ultimately cause frustration – not a good reaction.
Directions: Go Left
Whose done it well?
Half Life 2 – Valve’s classic FPS Half Life 2 made sure that the player experience was emphasised when designing their levels, and Valve deserve praise for it (though obviously not from Gordon). Despite the expansive nature of the levels, the route was largely linear, and the way to go ‘signposted’, by NPC directions, audio clues (like Dr Breen’s announcements) or visual spectacles which invite investigation. The levels weren’t just corridors, and yet managed to guide the player down a set path invisibly.
The secret to why Half Life 2′s level design gave a positive user experience can be found in the development process. When making the maps, the level was designed first as a blank template, and the artwork was added after. (i.e. the rundown City 17). In contrast to games where the spectacle comes first, at the cost of the player experience, here a blank level ensured that the player’s navigation was clear, and a coherent route was offered to the player, before the artwork was introduced.
Who has done directions badly.
Lego Star Wars – Now I’m not saying the Lego games aren’t fun, but this fun is limited by some user experience flaws. My first experience watching people play Lego Star Wars included a 10 minute section of them being ‘lost’ in an area, with no idea of what to do to progress. The multiplayer nature of the game meant that co-operation was needed to explore, which further slowed down progress.
The problem was that they were lost, the exit was sealed, and they had no idea of how to open it. The players went back a few screens, but still found nothing. The game gave no indication on what was needed for them to progress. (turns out one of the items they’d built was incomplete, and hence progress wasn’t possible).
This is particularly pertinent based on the audience that Lego games typically have, comprised of casual gamers, girlfriends and children. Unlike those who were brought up having dealt with the constant death of plumbers, they’re likely to have less tolerance for standard gameplay mechanics (hence the no-death rule in Lego). Surely having no idea what to do is going to be a massive turn off for these players?
What should the game have done? Maybe explicitly told the players what they needed to do to progress? Or, on noticing they’d been stuck in the same area for 5 minutes, given some sort of hint or direction on where to go? It’s interesting that New Super Mario Bros Wii, a game which (on the surface) has a similar target audience, gives hints when it’s obvious the player is stuck.
Yep... definately stuck!
How to do it right
So, what methods are available to assist a player in navigating the game, and how effective are they?
On Rails
- The most direct, and most restrictive way of ensuring a player knows where they are going is by making the game ‘on rails’. The player is presented with a screen and a task to complete, and then automatically moved on when the task is complete
- Only really practical for some game types, as it prevents the player from investigating areas at their own pace.
- Found in the recent Doom game for iPhone, where the player had to shoot all the demons in each area to progress. When designing a game that is on rails, it’s important to make sure that the tasks needed to be completed to progress are highlighted.
Maps
- Maps are obviously visual representations of where you are in relation to the layout of the level. Commonly used in ‘sandbox’ games like Grand Theft Auto.
- Best used with icons on the map to highlight areas of importance to the player (objectives, save points etc…)
- Obviously, each icon on the map dilutes the overall prominence, so be careful not to overload the map
Signposting
- Not just literal signposts (although these can be useful), signposting can be any sort of visual draw – a prominent building in the distance, a fire-fight, or audio clues to draw a player to a specific player
- These can serve to guide the player to a specific area, without explicitly giving them the instructions, and are often useful in first person shooters.
NPC guides
- Non Player Characters are useful as they can communicate, and interact directly with the player, and hence appear as an ‘in-game’ element, rather than as part of the interface between the player and the game world.
- Can be useful for giving players instructions in game, or can directly lead the player to the objectives, hence ensuring the player has a clear idea of where to go.
- Think Alex in HL2 who guides the player through the levels, providing direction and access to new areas.
Make the areas visually distinctive
- Making each area visually distinctive, through the levels artwork, audio, and features is often a key aspect of ensuring the player knows where they are, and where they want to go.
- For example, in Ocarina of Time, the temple’s themes helped the player to have clear distinctions between each area. You’re instructed to go to the water temple. See fire? You’re probably in the fire temple…
Conclusions
It doesn’t matter what type of game it is you’re making, navigation will still be an issue, and its important to make sure the player never feels like they’re lost (regardless of whether they are on the right track or not). We’ve covered a variety of ways commonly used by games to ensure that the player does feel like they’re in control of where they are going, but the list is by no means exhaustive – novel ways of directing the player are always being tried.
Ensuring the player feels in control, through knowing where they are, and where they are going, are a few of many essential elements to ensuring the player has a positive experience when playing your game. And when it comes down to it, a positive experience is the very thing we’re after.
Improving the Player Experience – How to make great loading screens
Players expect loading times, and recognise that they are a necessary evil. It’s a given that most, if not all games, will have them. Since a loading screen is encountered by the player multiple times, it’s important to think about their experience when they encounter these screens, as it will undoubtedly form part of their impression of your game. This is often forgotten by developers.
Games are leisure activities, and so it’s important to make sure that the player’s impression is positive at all times. Today we’ll be looking at some good ways that developers have handled loading screens, and some failed attempts that have caused players to complain, or turn off games completely, and coming up with guidelines on how to design a good loading screen.
Please wait for the rest of this post...
Good loading screens
Loading screens don’t have to have lead to a bad player experience, and as proved by:
Call of Duty: Modern Warfare 2
Call of Duty doesn’t have loading screens. It has briefings. While the game loads, COD:MW2 uses this necessary ‘lull’ in game play to forward the story, and give the player a description of the back story for the next level. The effect of this on the player is that, instead of being booted out and told them “wait here for more fun”, the player is given the opportunity to continue interacting with the game.
When I played COD:MW2, I had no idea what the story was, or what was going on. But the briefings distracted me enough from the loading screens that I didn’t care, and didn’t notice I was being kept waiting for the next part of the game.
Ridge Racer
What about games that don’t have stories? Ridge Racer, for the PSX, gave you a mini-game to play while the game loaded (Arcade classic Galaxian I believe), hence keeping the player entertained. Namco have repeated this successful formula in other games, such as the Tekken series. Simply giving the player something to do while they wait can mean the difference between a player who gets frustrated and gives up, and one who continues playing.
Bad loading screens
However, some games make fatal mistakes when it comes to loading screens, which detract from the player experience:
Remember me?
Resident Evil
Most people’s memories of the early Resident Evils include the door animations (link to youtube). Every time you exited a room, there would be a short pause, and the same ‘loading’ animation. Every time. No wonder people remember, and got sick of them. Although initially covering the pause that the system needed to load the next room, eventually they just became a ‘feature’, as evident in Resident Evil Nemesis, where the boss character breaks down some doors, effectively destroying the loading times between the joining rooms. The danger of boring a player by forcing them to sit through a repetitive animation is a lesson not yet learnt, as evident in Penny Arcade’s comic on Mass Effect
Sim City 2000
2 minutes to load the start screen? Another loading time after you’ve selected to load an existing game, or start a new one? This may be a technical issue, but superfluous loading screens are going to immediately detract from the player experience
How to make a great loading screen
Loading screens have improved a lot in the past 10 years, and some features of good loading screens are common to many games. To make a good loading screen, consider including some of the following:
- Include tips/facts/story on the loading screens. Instead of just saying ‘loading’ on the loading screen, think of what the player may want to know. Is there a special technique in the game that you could tell the player about? Is there some background story you want to impart? This downtime is ideal for letting them know
- Hide the loading process where possible. Tony Hawk’s Unleashed claimed to have no loading times. It did, but the player never saw them, as it loaded the next level seamlessly as the player passed through some adjoining rooms. By never taking control away from the player, the player doesn’t have to know that the game is loading in the background.
- If you do have to have a loading screen, make sure you keep usability heuristics in mind, and make the loading progress transparent. Show the progress of the load (really show it, not just an infinitely spinning wheel!), so the player doesn’t have to wonder how long they will be waiting, or worse, if its frozen.
- If you’re Namco, put a mini game on the loading screen. If you’re not, I believe Namco have copyrighted this. So better not.
By thinking about a holistic player experience, including the menu system, and loading screens, as opposed to just considering the gameplay, you can improve player’s impression of your game, and make them more likely to enjoy it. The small amoun
