Since my recent post on using mechanics from games to make dull tasks fun, a couple of upcoming applications have taken the step of applying some of the lessons from gaming, to make work fun. Epic Win is a ‘to-do’ list disguised as an RPG, and Dev Hub is a website creation tool with points. I’ll look at what these applications are, how they apply game mechanics, and how successful we can expect them to be at making dull tasks fun.

Epic Win

The new iPhone ‘game’ Epic Win is a productivity application (essentially a to-do list?) mixed with an RPG. After inputting your list of tasks (such as wash the dishes, or write a blog post), the game will reward you with XP for completing each task, allowing you to level up your character, as well as granting special items and other rewards.

Achievement Unlocked: Made Dog Useful

There is a trailer for Epic Win here, which may explain the theory better.

Essentially, through giving you points for achieving tasks in the real world, the game aims to incentivise the player to perform the real world tasks, by applying a common game mechanic.

DevHub

DevHub is a website creation tool, focusing on automating the process for creating blogs for niche topics (like this one?) and allowing authors to monetize their site (maybe I should be interested…)

Me, writing this blog

In the initial implementation, they found they had a problem. People were making only the simplest sites, using a small range of DevHub’s features. So to incentivise people to use a fuller range of features, they added game mechanics.

Now tasks like blogging, or linking your site to your facebook profile accrue points, which can then be spent on improvements to the site, such as new templates or widgets. This gives a gradual reveal of the site’s features, and gives the owner (player?) a sense of progression.

Thus game mechanics help DevHub’s users discover, and utilize a wider range of features than before.

Are they fun?

The game mechanics in both of these new applications seem to be simpler than those outlined as successful in the ‘Just Add Points’ presentation I covered recently. Both use points as a mechanic to incentivize players to repeat actions, or go further than they normally would. Points allow the clear construction of goals, and for progress to be measured. I imagine competition will become a key part of these two applications, as social media will allow players to compare and compete on points.

However many of the problems outlined in Sebastian Deterding’s presentation still apply.

• Epic Win doesn’t change the player’s goal (wash the dishes), it just monetises it, meaning the ‘fun’ derives from gaining points
• I cannot see how the validity of the points value can be enforced. Since the goals are self-assigned, and self-reviewed, players who want points will just set tasks such as ‘sit down’, and reward themselves (or just lie altogether).
• This makes points valueless, and hence points don’t help the game add ‘fun’ to achieving tasks.
• Also, this makes social comparison, a key factor in the success of points, flawed or impossible (so no high score tables)

DevHub may also run into trouble, since withholding features that can be found on other competing sites for no effort will only work if your site has a strong unique selling point. We’ll have to see what other monetizing blog hosts do.

It’ll be interesting to see how these applications do over the next few months. Deterding’s presentation implies that neither have a successful model for applying fun to dull tasks. I’m looking forward to seeing what the players think.

Related posts:

1. Applying Games UX lessons makes dull tasks fun!
2. Selling UX in games – everyone else is doing it.
3. Get Lost! – Improving player experience through signposting and map design in games.

An iPad Nano

Jakob Nielsen admits that the study is not as thorough as a typical usability study. However has decided to share it anyway, due to the over-inflated impact that usability studies produced early in a devices’ lifecycle have been seen to have. As an aside, this is an interesting contrary viewpoint to the disadvantages of being first-to-market noted in ‘Inmates’, which argues that being first to market is irrelevant compared to being ‘best’.

The report has some interesting key findings, including that the apps seen on the iPad and the iPhone suffer from the re-emergence of a problem not seen since the early 90’s. Unlike web browsers and desktop software, which has established graphical conventions to highlight buttons and GUI elements, iPhone and iPad software has not implemented standard conventions, such as making a clickable button appear 3D. Hence there is no consistent manner of designating important aspects of the UI, and users just didn’t know what they could click on. Nielsen likens this to the first emergence of graphical interfaces of the early 90s, when anything and everything could be a button.

Its therefore clear that the main recommendation of the study is to standardize common elements, like navigation, among first and third party applications, such as “swipe to turn page”, or “press and hold to delete”. This also links with the studies’ findings that users were unsure what reaction their action would cause, as the apps have yet to find a consistent manner in which to work.

Not just a big iPhone

The study highlights how the iPad is not just a big iPhone, and different usability issues emerged on the larger device – most pertinent is that navigation elements on the bottom of the page, as seen in many iPhone applications, will not work on the iPad. The larger screen means that these elements are too far from the user’s field of vision to be noticed – and hence are not appropriate. What this means for people who make apps is that a custom iPad version is needed, not just relying on the ‘universal’ up scaling of iPhone apps.

The full report is linked below, and worth a look if you’re interested in the usability, the iPad, or designing an application!

Read the full report, here.

Related posts:

1. Five essential iPhone apps for usability professionals
2. Usability Issues in Sharepoint
3. How real-world game usability testing is changing

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 20^th 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.

Related posts:

1. Conducting an Expert Review
2. Game Usability: Advancing the Player Experience Book Review
3. iPhone Game Design Heuristics

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!

Related posts:

1. Mobile Games should start quickly (lets get down to business!)
2. Games Usability Testing is not QA!
3. The thirty minute facebook game usability test

What is a social gaming network?

As seen with Xbox Live, or Playstation Home, social gaming networks essentially all do similar things:

• Store high scores, often with leader boards for comparison with other players, by day/week/all time.
• Gives, and records achievements (or trophies) from within the game: meta-objectives which are publically listed on the player’s profile
• Contains a ‘friends’ list, of other players, with messaging facilities so that multiplayer games with these players can be arranged.
• Match finding, allowing the player to find suitable games that match their criteria, or games with friends.

Admittedly not terribly useful in solitaire...

Problems with social gaming networks on the iPhone.

The problems so far with implementation of these networks on the iPhone are caused by the wide number of competing systems.

Unlike the PS3 and Xbox, which each has one social gaming network on their device, Apple had (until last week) refused to act on implementing their own system, which has lead to the rise of many independent systems. Currently popular are: Crystal, Plus+, Openfeint, Agon and a recently announced competing network by Namco. Even ignoring the smaller, less widely implemented systems, there is still too much diffusion here.

Having a large number of competing systems offers an inconsistent user experience, with similar tasks (i.e. adding a friend) being handled differently on each system, which is ultimately detrimental to the player’s experience. Instead of playing the game, players have to spend too much time setting up accounts and adding the same friends from their other iPhone games.

The lack of a centrally imposed quality control means the implementation of these networks into games is rather haphazard. This can be seen with the free version of the iPhone ‘x-ray’ app, which emulates x-raying the player’s hand. The app has recently added Openfeint support, and so has achievements, leaderboards, a friend list, etc. These features don’t correlate with a single player, non-game. What sort of competition can a faux-x-ray have?

Achievement Unlocked: Found Keys

A closer inspection shows that the achievement points are all given for purchasing the paid version of the game. The social gaming network integration just serves to bribe the player with the chance to pay for points and inflate an artificial score (which can be compared to your friend’s score, see Farmville!).

What will Apple’s new system have to do

Apple’s system will have to improve the disjointed player experience that these systems currently give. To properly emulate the success, and ‘flow’ of the PS3 and Xbox’s networks, Apple should be aiming to entirely replace these competing systems.

The advantages of this would include:

• unifying all players under one system to ensure that friends can find each other, play against each other, without being spread across multiple systems
• The players only need to understand one workflow for each task (i.e. adding a friend), rather than learning the process for each system
• The player will only need to sign up once

• Achievement points earned in one game can be shared across all games, rather than just those on the same network, as currently.

Care would also have to be taken to enforce rules to ensure achievement points remain meaningful, by introducing a form of quality control to prevent poor apps from bribing people to download by handing out points cheaply.

When I ran user tests for an iPhone game last year, the openfeint login/sign up screens confused new users, who were just interested in playing the game. Apple will need to make the network invisible to uninterested parties, to prevent this. Perhaps this can link with their itunes ID, but the implementation of this is not obvious:- families often share an itunes ID across many devices

By introducing their own network, Apple have the opportunity to achieve a consistent, and hence improved, user experience when playing using the iPhone’s social gaming networks, and can only help things get better!

Related posts:

1. Make work fun – examples of applying the UX of games
2. Shh! iPhone gaming should respect your sound settings
3. User Experience or Player Experience?

Working with usability requires a wide range of abilities, and hence these tools reflect the wide range of roles a usability professional may be performing. When talking about each app, I’ll try to cover where in the usability process it may come in useful, and how it can help you to increase efficiency and get better results.

but don't forget lo-fi alternatives

1. Pidoco°

Starting off, this isn’t strictly an iPhone app, but Pidoco’s software has been developed to be compatible with mobile browsers and the iPhone. I saw them demo the software at a recent UX Brighton event, and they impressed upon me that it was built with usability in mind. Pidoco offers a quick way to collaborate on the design of wire frames, and quickly show these to the user or client, without the need to be in the same geographic location as them. The easy to use nature of the system means it’d be ideal when iteratively testing an interface with users, and is a mid-fi alternative to paper prototyping. Currently offering a month’s free trial, there’s no excuse not to give it a go!

Pidoco°’s website: https://pidoco.com/en/

2. Mocha VNC

Need to mock up a mid-fi prototype of an iPhone App? You obviously don’t have time to make the app in Xcode, buy the iPhone developers license, link the customer’s phone to the computer and copy the app over. Instead, how about making a prototype on your Mac, or PC and using a VNC client to make the iPhone look at the prototype. The user will still be able to interact with the prototype by clicking, or navigating around, and the ‘controller’ sat at the server can display the correct pages to the user. Easy mid-fi prototyping, on an iPhone, without the long set up costs and investments required to actually have the app running on the iPhone.

Mocha VNC’s website: http://www.mochasoft.dk/iphone_vnc.htm
 

3. Camera

Watching someone perform a task is an important part qualitative usability testing. What about those moments where you weren’t looking, or noticed something that you wanted to ask about later, but forgot about? Looks like you need to be recording your user tests. Camera comes with all iPhones, but is only available for video recording on the 3GS. Since you are always likely to have your phone with you, it’s a handy mobile solution that allows you to record your usability sessions without requiring any additional equipment, so that they can be analysed later. Maybe buy a stand for it though!

4. exZact Data Collection

Quantitative research is also an important part of establishing user requirements, and working towards a design that meets their goals. The Data Collection iPhone app aims to allow you to create, and answer, custom surveys on the iPhone, collecting information like geographic location, and responses in a variety of forms (1-10 ratings, drop down lists, yes/no responses, and comment boxes). They then offer real time analysis, so you can see the results as they come in, and claim to be massively scalable. Offering a month’s free trial, it seems an effective solution if you require your data collection method to be mobile, and accessible anywhere.

exZact’s website: http://www.iformbuilder.com

5. Insight – Basecamp on iPhone

You’ve seen from the diversity of the apps above that a usability specialist has to be experienced in a lot of areas, and its often hard to keep on top of these. A tool that I have found invaluable in project management is Basecamp, which allows you to collaborate on projects, assign tasks and see what everyone is up to. Insight is a mobile version of Basecamp, and will allow you to keep up to date with how everyone working with you on the usability project is progressing from one easy interface, and keep on top of projects. As a busy person, it’s likely to be an invaluable tool to any usability specialist or contractor!

Insight’s website: http://www.encampapp.com/

Conclusion

Its clear from looking for the most useful usability apps for the iPhone that this is a largely untapped market – although there are tools available to help with the individual steps in the process, there is no one ‘go-to’ app for usability and UX professionals. What is needed is a more holistic solution, one that can work with a usability professional in every step of the process, from the initial requirement gathering stage, through building up personas of the customers, to the iterative design process and beyond. Until then we’ll have to make use of the wide range of apps covered today to achieve these tasks.

Related posts:

1. iPad Usability Study
2. The importance of usability in Mobile Geolocation games.
3. 7 aspects of successful usability questionnaires

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!

Related posts:

1. Controls should be appropriate to the iPhone’s input methods (shake now!)
2. iPhone games should not be interrupted by calls.
3. iPhone Game Design Heuristics

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

Related posts:

1. The importance of usability in Mobile Geolocation games.
2. iPhone games should not be interrupted by calls.
3. 100 Rogues – Playability Heuristics Review

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.

Related posts:

1. Shh! iPhone gaming should respect your sound settings
2. iPhone games should not be interrupted by calls.
3. iPhone Game Design Heuristics

The most obvious thing that can be said about iPhone gaming, and yet a factor developers commonly miss,  is that it appears on a phone. There are many ramifications from this, such as where a player is likely to be playing (the bathroom?). The focus today though is on the important factor that a phone is likely to receive calls.

Receiving a call

Text messages are handled by the iPhone OS, and appear as a pop up box that can be dismissed, with minimal interruption of the game (and hence needs no input from a developer). However receiving a call will shut down the game and run the phone program regardless whether the call is answered. This is where good design is required to avoid a usability disaster.

 From a technical perspective receiving a call is essentially the same exit process as if the ‘home’ button (the only button on the main page) is pressed. However from a usability perspective, the important difference is that the user has no control over whether they receive calls or not, and so the software has to accommodate this. If the app just ‘drops’ you, without saving the state of play, and then starts the app from fresh when the call is finished/rejected, this is going to negatively effect the user’s experience. They will be unlikely to want to play again, since they will be redoing aspects of the game they thought had been completed earlier. Furthermore the fear that they will receive more calls, and thus lose progress, is going to be a lasting factor, and prevent the user from investing time to continue.

 It is therefore important for iPhone game designers to consider that the medium is going to lead to unexpected interruptions to game play, and provide a solution which will accommodate this.

Who does this right?

Scoops

Scoops, the casual ice cream tower building game, successfully implemented this in a later version of their game.

In the initial release a call (or ending the game) would cause the game to restart from the beginning (without saving the high score). Despite being a short game (a typical session would probably be under ten minutes), the game’s only measure of progress is a high score table, and so losing progress like this can easily anger players. This was recognised, and fixed in later versions so that now the game will resume from where it left off after returning from a call. Further to this, the game will start paused so that players returning from a phone call can adequately prepare to resume their gaming session. The designer, Ian Marsh, has ensured that interruptions to game play will not hinder player’s progress in the game.

Who does this wrong?

Alive4ever, the zombie survival game ‘inspired’ by Left4Dead, has recently added a ‘horde’ mode, where users must survive waves of enemies of increasing difficulty in order to unlock additional bonuses.

Unlike Alive4ever’s other modes, where games would be in <5 minute intervals, successfully unlocking all the weapons in the new mode would require playing for over an hour without interruption. If the user intentionally exits the game, or receives a call, their progress in this mode is lost, and the user has to start the hour long session from the beginning. The implications of this are that the user will be unlikely to retry this, and the real enemy becomes not the zombies on screen, but the challenge of not receiving calls for an hour!

Alive 4 Ever. Not Left 4 Dead.

As a little bonus to finish on, here is a gem of an app review, for Scoops.

User: FredsYourUncle 
Score: 1/5
Subject: Fool
Review:  “ Tomatos arnt vegetables “

Related posts:

1. Shh! iPhone gaming should respect your sound settings
2. Mobile Games should start quickly (lets get down to business!)
3. Controls should be appropriate to the iPhone’s input methods (shake now!)