Posts Tagged ‘Heuristics’
Game Usability: Advancing the Player Experience Book Review
I’ve recently finished reading Game Usability: Advancing the Player Experience, edited by Noah Schaffer and Katherine Isbister, which (as its title may suggest) tries to give a complete overview of the field of usability within computer games. Game usability is a relatively new topic, yet all the key figures of the field are included in the book, including contributions from Microsoft’s User Experience labs, Sauli Laitinen and the Super Mario Club and interviews with figures from many major companies. Game Usability recognises that this field is new, and aims to provide an introduction for complete novices to how usability is developing within computer games, and the shift from ‘hardcore’ games, towards a friendlier user experience.
The topics are widely spread, and try to cover every aspect of usability and UX within computer games, including an introduction to heuristics, how to perform an expert evaluation, and guides to many of the processes of user experience testing. Since the topic is relatively new, there is a wide range of material than can be drawn upon – maybe this book wouldn’t be so useful in ten years time, after a greater degree of precision is applied to each area of usability testing.
Where this book excels is when it covers the actual ‘how to’ of usability processes. If the reader had never performed an expert evaluation before, this book would give them a great introduction and allow them to get started. Similarly for running user tests, articles in the book tell you what to do (and what not to do), common problems encountered, and what results you should be looking for. This is supplemented well by concrete examples, such as Microsoft telling us how they use heat mapping to work out which areas of Halo are causing problems, and what actions they took to fix it.
now try to capture the flag
It also covers the difference between ‘casual’ and ‘power’ gamers, and how games should adapt to the shift towards casual games that can be seen through the success of the Wii. Unlike Alan Cooper (whose book Inmates says that the divide between casual and power users should not exist), this book recognises that ‘power-gamers’ have grown up developing a different skill set to casual gamers, and are more prepared to put up with issues like dying repeatedly, and a higher degree of challenge. By addressing the differences between gamers, and what their expectations are, this book would be a useful aid in the design of personae, and at targeting your game to an intended audience.
Some aspects of the books seemed a tad odd however: An interview with Georgios Yannakakis of Copenhagen University asks only three (very brief) questions (maybe Georgios wasn’t aware it was an interview). Another interview is with someone who shares Schaffer’s last name, and looks to be the author’s dad. Schaffer’s dad has been established in the field of usability, but has little to add with regards to games.
Perhaps the main issue not covered by the book is that all the contributors to the game are established in companies that accept the value of their work. The book briefly covers some counter arguments to common complaints about performing user testing (“It’s too expensive = It’s cheaper than shipping a rubbish product”, or “It takes too long = It’s integrated with the design process so doesn’t take much longer”). However it’s getting into a position where UX is a consideration at all within a company that will be a consideration for many (and is the subject of John Rhodes’ book Selling Usability ). Maybe future revisions of this book will include techniques for making usability a priority within your company.
The focus of the book is maybe sometimes too wide, and only lightly touches each subject before moving on. If you were already familiar with the topics covered in this book, there will be nothing new for you here.
These oversights are only minor though, compared to the large amount of ground the book covers as an introduction to usability. It offers more in terms of practical “how-to” guides than Alan Cooper’s Inmates, and its focus on Games means it can offer fairly comprehensive coverage of the main topics of the field. If you are new to the subject, or a non-usability specialist looking to understand the subject, or can only afford one book, Game Usability would be a great introduction to the theory and practice.
Also, to finish, my quick Usability fail discovery, from Sussex University.
Instead of letting the user break it, how about… not offering the ability to make mistakes (See: Macs)
Conducting an Expert Review
Within our HCI classes, we have started reviewing the UX of an upcoming multi-platform game from a prominent client, and are performing an expert review on it. An expert review, as opposed to a user-based study, involves having usability experts play the game themselves, and uses tools and their expertise to find faults. This is different to a user-based study, where the expert would observe another player playing the game. Because of the time constraints involved, we selected an expert review as the most effective method to review the UX of this game.
To get the best results possible, and be as helpful as possible to the client, we had to choose our methodology carefully. In this blog post, I’ll discuss how we chose to approach this task, why we chose these methods, and what the alternatives are.
The first rule placed on us is that we are to work in groups of 3. As described in an article by Laitinen on performing expert evaluations, the evaluation reaches its optimal group size between 3 and 4. Less experts than this may miss things. More experts than this fail to find a significantly larger number of faults.
plus too many cooks spoil the broth
The other restraint placed upon us is that we would only have a short amount of time with the game. We decided to use this time to play and evaluate the games separately, and then come together to discuss our findings. The alternatives to this would have been having one person play, and the other two take notes, or to have each person play for a bit (as we did), but the experts not playing would take notes then. All of these sessions would involve filming the game screen, and the participant.
Two experts watching one player
Advantages:
- One longer complete play through, so can see player development
- Experts can ask the player questions during their play session
Disadvantages:
- Only one play through, so difficult to see if issues are common or just for this user
- Questions asked during play through may distract/alter playing experience
Three experts playing together, in turns
Advantages:
- Three sessions played through, so can see reoccurring issues
- Experts can get a greater understanding of the game mechanics through playing it
Disadvantages:
- Players wouldn’t get as far as they would with a long session from one player
- Second and third experts play experience will be biased from the experience of the first
Three experts playing separately
Advantages:
- Each player gets an authentic ‘new player’ experience
- Comparing after can show what issues naturally arose for all
Disadvantages:
- Players wouldn’t get as far as in one long play through
- Have to perform expert evaluation after the game play, rather than during.
Since the sessions were all being recorded, we opted to do the last one, and hence have the ‘purest’ play experience recorded for each. There is, of course, no right answer – many other groups chose different approaches, and I’m sure they found equally valid issues. I’d welcome comments below if anyone has reasons for a preference with how to perform an expert evaluation.
Now having a video of a play test, we are individually analyzing them. I’m approaching it using heuristics, such as those made by Nielsen, Nokia, and the work of Federoff as a guide. Having identified the issues, I will then attempt to rate them by severity – the extent to which they will hinder the user’s enjoyment of the game. Then, in a group session with my team members, we will evaluate which issues we all agreed where particularly prominent and severe, and amalgamate our results, ending up with a list of issues with the game.
We will then have to present our data to the client. I posted before about writing a UX report, but the circumstances for this report will differ – Geographical location, and time constraints mean that this report will be an in-person presentation, with some take-aways. I will blog about these soon….!
Shh! iPhone gaming should respect your sound settings
This one may be hard to illustrate, but it should be one of the first items on the checklist for developers, and is often missed. Let’s use a scenario to illustrate it, painting vivid pictures in your mind!
You’re sat in a lecture, and the topic is domestic life in 14th Century Catalonia (We don’t know why you’re here, you are a computing student. Maybe you thought there would be sandwiches). It’s dull. You’ve tried to check twitter, no internet connection. Time to play a game on the iPhone then, I guess. Check the phones on silent, yep the switch is flicked. Ok, time to rock!
Oh no – its playing the Marble Zone theme at full volume! We’ve been foiled, and you’ll never get the sandwiches now!
So what went wrong? Despite having the phone set to silent, the game still had sound. Depending on how diligent the coders were, this has been an issue with the iPhone for a while, as the iPhone won’t automatically silence apps when set to silent – this has to be manually coded. Quick ports or just forgetful coders (usually working in small teams) can miss this.
This becomes an issue because of user expectations – they’d expect the silent switch to work globally, and will be surprised and frustrated when this isn’t the case. As seen in the scenario above, it can lead to the user being embarrassed and worse of all (according to Alan Cooper) feeling stupid!
It’s not simply a ‘design choice’, as a logical look at the situation will tell us. Not only would manually setting the desired volume settings inside an application duplicate functionality that is already implemented in a much more functional manner on the device itself, but I can also think of no scenario where a user would want their phone on silent, but their game to make sounds. It’s just poor design.
So in summary… just don’t do it app designers!
(Also while you’re at it, let me listen to my own music in game!)
Who does this well?
A lot of games to be honest, as its not really a ‘do well’ thing, rather its just done or not done. So lets talk about Doom Classic, as it does do this. John Carmack’s finally (6 months after it was “almost ready”) released his port of the original Doom for the iPhone. Control issues aside, it’s a faithful port, and includes WiFi multiplayer. Its Doom, so you know what you’re getting, and its just as fun as it was 15 years ago. More relevant, it does respect the silent switch on your iPhone, so I’m justified in talking about it here! We’re all looking forward to when Carmack starts on his port of Quake.
Who does this badly?
Hook Champ, from Rocket Cat Games, is a fun platformer where the only means of getting anywhere fast involves swinging from the ceiling, over lava, through brick walls and away from the scary cursed..fish thing. Its fun, recreating the opening scene from Raiders of the Lost Ark. It’s just a pity that the game ignores your silent switch, and so plays at full volume regardless of your iPhone’s settings. You can set the volume in game. But you shouldn’t have too. A disappointing oversight!
Another offender is Sonic 1, but I didn’t feature that as I’ve already talked about it in a previous post (link to previous post). Oh dear!
Also, just quickly, thanks to Brian Franklin from WebHostingSearch for featuring this blog in their ’20 Great UX blogs’. Rather unexpected, but thanks!
Mobile Games should start quickly (lets get down to business!)
Part of a series on iPhone Game Design Issues. For an introduction see here, or use the categories on the right.
PopCap, they of Peggle and Plants Vs Zombies, commissioned a survey on where most people play mobile games. Results showed that men play more at work (28%) than women (17%). They were also asked when do they play these games. “while waiting for an appointment” came first for both genders, although I imagine this is because “on the toilet” wasn’t an option in the survey (I’m not judging… just saying!).
waiting for an appointment
What these results show is that people want mobile games to be ‘pick up and play’, and use them to fill time, as opposed to committing a large amount of time to playing them. It is therefore important that game designers facilitate this method of game playing, and make it easy to pick up and play games. The main elements of this are:
- fast start up time (from app load to actually playing)
- low number of extraneous menus to navigate before playing
- app resumes from where it left off
- app shuts down quickly, but doesn’t lose progress
A previous blog post touched on the issue of apps resuming your progress after an exit, and so this topic will focus on the user experience starting (or resuming) a game.
The player, when they start the game, wants to play as soon as possible. Initially they have to sit through a load screen, which beyond the abilities to reduce this by programming optimization is a necessary evil. However, as developers interested in ux, steps should be taken to reduce the number of steps a user has to go through after this to reach the game.
There is a trade off that has to be made here, based on our assumptions of what the user wants to do. With many types of games we can assume that the user will already be on their right profile, will want to resume a current game, or start a new game. More complex games may have a wider degree of options that they need to present the user (particularly on a first boot). So how do we decide what options the majority of users will require? More effective than experts’ ‘educated guesses’ would be qualitative testing – either through a limited release prior to the app store (I believe apple allows you to distribute your app to 100 people, enough for a good sample group), or through ‘hooks’ in the code of early releases, which will log, and send back, details on user activity. If you then found that 87% of users, on loading a game, went straight to ‘resume game’, you could make the game do this automatically, and reduce their wait.
The design of an effective ‘entry method’ into the game is incredibly well suited to large user tests, based on qualitative tests of user behaviour, and can have an enormous effect on a player’s good will and ‘feeling’ about a game. Put simply, if player’s know that they can load your game quickly, compared to one with a 30 second wait, and 5 menu screens to navigate, they are more likely to pick your game when waiting in a queue or for a meeting.
"anyone for peggle?"
Who does it well?
Textropolis
Textropolis, the word guessing game by Ian Marsh. Click on the app, and after a short load screen you’re playing the game – no menu options (obviously you can get back to the menu, but the game assumes, correctly, that most players will not need this). The nature of the game (no time crucial element), lend the game to a quick start, so this is also a fine example of a game design being suited to its platform. The game isn’t lacking in features too – the ability to sign in as separate user profiles exists, the game assumes that you will be less likely to want to do this than just play. Textropolis’ quick start up time would make this game a suitable choice for the sort of quick gaming that Popcap’s user survey says mobile gamers are into.
NB: I was going to feature Geared, the puzzle game by Bryan Mitchell here, as it loads quickly, and I cant remember having seen the title screen (it throws you straight into the game). However when writing this, I realised it doesn’t save your progress on a puzzle when you exit/re-enter, and hence it loses user experience points!
Who does it badly?
hero of sparta
Hero of Sparta, the (rather epic) hack and slash game by Gameloft (Think those PS2 Star Wars/LOTR games).
So, we’ve got five minutes before the meeting starts, lets play. App started. A load screen, then a one minute cut scene, ok, I’ve seen it before, so I’ll skip this. Another load screen. A title screen. Touch the screen to continue, ok, I’ll do this. New game, or Continue. Obviously I want continue, so I select this. Select a chapter. Well, I’ll select the one I’ve been playing on. Great. Another load screen. And I’m in.
That’s a lot of stuff to get through between deciding I want to play, and actually getting to play. Probably one of the reasons why I haven’t devoted much time to playing this game.
How could it be improved?
After the first load, I’ll be unlikely to want to watch the opening cutscene again (despite the flashy graphics). The title screen adds needless clicking to my experience. Although I haven’t verified this with testing, I believe the player is likely to select ‘continue’ rather than ‘new game’ after they’ve started playing. And th
Controls should be appropriate to the iPhone’s input methods (shake now!)
Part of a series on iPhone Game Design Issues. For an introduction see here, or use the categories on the right.
Looking at an iPhone, the immediate thing that strikes most users – compared to other mobile devices – is the lack of buttons. There are 4 in total, and all have very set roles – the power button, the silent switch, the volume control, and the ‘home button’. The home button is the most prominent of these, and sits on the front of the device, below the screen.
All of these buttons are useless for gaming – three have very specific roles, and the home button is exclusively used in the iPhone OS to exit programs and return the user to their ‘home screen’. What this means for gaming is that the device is lacking a critical element that users of consoles have come to rely on – tactile feedback when pressing a button.
Buttons on controllers are important for many reasons.
An Ergonomic Masterpiece
The physical shape and size of buttons are ideally ergonomically placed to make the controller comfortable, and prevent gaming being a painful experience. They should also be placed in places that become intuitive to the user – gamers, like touch typers, should be able to forget about the controller’s physical presence between them and the game, and react naturally to events on the screen without having to think about how to translate their actions through a control pad.
And then theres the iPhone. Game developers aren’t allowed access to any physical buttons for players of their game. They have to innovate (uh-oh!). Or not. Some developers, whether its due to the style of game they are trying to present, or just laziness, have just plastered on a ‘on screen joypad’ ontop of their game, with virtual buttons. See, for example, the iPhone port of Duke Nukem 3D.
Lots of buttons!
So that’s 5 virtual buttons, and 4 virtual… test tubes?.. acting as directional controls (two for movement direction, and two for aiming). Obviously the medium of the game (a First Person Shooter), does need a large degree of complex manoeuvres to be performed, but it seems both lazy and ineffective to have these as virtual buttons. Not only does it take up a very large proportion of the small screen’s real estate, but without the physical presence of the buttons, it seems very likely that the wrong buttons will be pressed constantly. This causes the constant need for the player to think about the controls, and will prevent playing from ever becoming truly intuitive. The iPhone does contain tilt sensors, as used in other games as the primary control method, and this could well have been incorporated into the aiming or walking mechanics (although not if you don’t want to draw stares on the bus).
Instead of lazily placing endless virtual directional pads and buttons, developers should be taking the medium into consideration when implementing controls. The iPhone has capability for tilt sensor input, and multi touch (so multiple elements can be selected at once). This has been used successfully to produce games of most formats – in particular Rolando, a tilt platformer, and Doom Resurrection, a tilt FPS being examples of successful implementation of formats traditionally considered to rely on control pads. Moving from a control pad to the iPhone requires novelty and implementing new methods of controlling the games, rather than a simple port. Buttons just don’t work as well without tactile feedback, and totally disregard the other control methods the iPhone allows. As before, I’ll end with an in focus look at two games available on the iPhone, both platformers, one of which successfully implements a suitable control method, one of which fails.
Who does it right?
Rolando, by Handcircus, has been described as the ‘Mario of the iPhone’ (by someone). At heart it’s a traditional platformer, with goals such as getting to the end of the level while overcoming traps, obstacles and enemies. All standard stuff for the genre. However what it does correct is the implementation of this, taking into consideration that it is on the iPhone. To move left or right, the phone is tilted, removing the need for directional controls. A swipe on the screen will cause your character to jump – again no button here. Elements on the screen, such as the lift in the picture, can be manipulated with your finger, which of course your hand is free to do, as you are not restricted by using them to move. So, with Rolando, moving is intuitive, jumping can be done anywhere on the screen, and there is no need for virtual buttons and the problems we’ve identified surrounding them.
Rolando!
Who does it wrong?
Sorry, but its Sonic. Obviously it’s a classic platformer, and an exact port of the version on the master system (so no spin dash!). However the port itself seems lazy – controls being implemented by simply placing a virtual d-pad and jump button on the screen. For a game that involves precision jumping, such as Sonic, this is a huge mistake. Lacking tactile feedback on which direction you are pressing, or whether you have your finger above the jump button, can (and often does) lead to missing jumps, and frustrating deaths. And, with no level-select, three deaths will mean starting the game from the beginning. Ultimately it makes the gaming experience frustrating and removes a lot of the fun that the sonic series used to be about! A design failure.
Sonic for iPhone
I think app store reviewer Mr Intesity puts it best:
Score: 2/5
Subject: I am cooking chicken and rice
Review: It’s alright. Its Sonic as you would expect but with dodgy controls. I’ve played it twice, too fiddly to sit and enjoy I found.
