making applications fun
6 April, 2007
Raph Koster did a presentation called ‘the core of fun’ at the Etech 2007 (slides available). The main theme of the talk was about structure; ‘things that work’ have a certain structure. Also fun things, music is full of structure and so are games, art, etc. Often structure is limited within a grammar, understanding grammar can help to design ‘things that work’.
In order to make application fun, some ‘magic’ (which was after all the theme of etech) ingredients are necessary:
- core mechanic (how?) – The action that must be taken to reach on objective is of main importance. It is something repeatable, so it better be good. (E.g. at ebay you keep coming back to bid). However, over time skill should come into play. So the action should be something that can be learned (feedback is necessary) and mastered over time. In the end the action becomes something competitive, thus ratings and metrics underline this competitiveness. (Examples: bidding on ebay is something you can get better at, making a connection at linked-in is different with a CEO or a collegue, etc)
- preperation (when?) – The point in time some action is taken matters. It’s all about context. In games it matters what has happened before you take a certain action at a certain time (e.g. in strategic games). In other words, the context should keep changing based on actions that are taken. This is not only about the system, but also about the user. The user will change during the lifetime of the system, why shouldn’t his context.
- territory (where?) – The location where something happens (another form of context) should also make a difference. This way the user is faced with a ‘fresh ascenario’. For example in Amazon, it should matter where (search results, author page, etc.) a user decides to buy something, this way his experience can stay refreshing and new everytime.
- range of challenges (what?) – Once an action become ‘fun’, it should be able to perform it in many places, with different outcomes. Metaphorically, if the action is a ‘hammer’, there should be a lot of different ‘nails’ around to hit.
- choice of abilities (with?) -Extending the previous metaphor, it’s not about a lot of different ‘nails’ it is also about a lot of different ‘hammers’. There should be different actions that could reach a certain goal. Users should be able to pick their action to rearch that goal. Based on the action they took, they should also be ‘rewarded’ in different ways. This is related to the first point: keep learning.
- variable feedback (for?) – In the end, the question is, why is the user taking the actions? Well, he has a goal to reach. If there is just one goal, the system will be pretty boring. Therefor, there should be different outcomes of the system. Just like in games, sometimes a game ends in a suprise, sometimes is an even bigger challenge. But in the end, what makes a game fun is that someone who reached a goal becomes highly visible (think pinball highscores in arcades). Taking it back to systems, users might be rewarded for the hard work that they have put into learning the systems through discounts, ‘cheats’, new tools, etc.
- bad return on investment (few?) – Games are never fun when it is an endless sequence of very simple actions with high payoffs. Users can only stay interested if they are being challenged just at the edge of their abilities.
- cost of failure (phooey?) – Finally, just as in the real world something cannot be fun if there are no consequences. Looking at extreme sports, like skydiving, supports this idea: it is fun, because there is also some danger involved.