Posts Tagged ‘iPhone’
Make work fun – examples of applying the UX of games
I write this blog out of personal interest. It never really seems like work, and so I’d be unlikely to blog more often if I received points for doing so (although I do like free things!). However this isn’t always the case – sometimes there are jobs you just have to do, regardless of how you feel about them..
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.
iPad Usability Study
Just a short update this week, sharing some thoughts on the recent Nielsen-Norman report on usability for the iPad. The recently published study was based research from a combination of both expert evaluation and user-testing, and aimed to discover how people interact with the iPad, and what issues typical users would encounter that prevent them from achieving their goals.
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.
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!
All Change – Apple’s new social gaming network
Been playing iPhone games recently? Then you’ve probably been bothered by pop-ups asking you to sign in with OpenFeint, Plus+, Crystal, or one of the other many social gaming networks on the iPhone. When I started writing this post, I was going to cover the problems that having many rival social gaming networks causes, and what Apple needs to do to fix it. However, I’m too late. Last week, Apple announced they are going to launch their own social gaming network, called ‘Game Center’. So instead, we’ll be looking at what this new social gaming network needs to do, and what player experience issues it needs to address.
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!
