Difficulty Regulation

Lumines got me again. I hadn't played it for a while, and then yesterday I decided to sink my teeth in once again. It had one mode I hadn't really tackled before: a puzzle mode where the aim is not to score points, but to form various shapes of one color from the blocks. The reason I hadn't tried it before was that I had to actually check the internet to understand how I'm supposed to form those shapes. So there's a quick lesson: sometimes instructions are simply needed. But that is not the topic today. There is a reason I mentioned Lumines and the puzzle mode though, and we'll get to it soon enough.

Difficulty regulation strategies in games are important tools for keeping the player in flow. One quite obvious strategy is to simply include multiple difficulty modes to play the game in, allowing the player to choose a mode he deems suitable for himself. Of course, one problem is: how can the player know which one to pick? Sometimes descriptions can help, such as BioShock's "Choose this if you have never played first person shooters before" description for its easy mode. This is a relatively simple strategy to implement and has the benefit of hugely improving a game's life cycle for advanced players. The only thing a game designer needs to worry about is making the correct adjustments to make the feel more difficult but not unfair. Also, players might need some encouragement that after finishing the game, their skills are on the level needed to tackle the more difficult mode.

Difficulty increase built into progression in the game is most likely the most common way. The next level is typically more difficult than the one before it. Yet it is not always easy to design a suitable difficulty ramp. In many games, some of the most challenging moments are somewhere in the middle - towards the end, player skills and character powers are becoming too big for the challenge. Another thing is that the difficulty curve should not be a ramp. I think it's important to drop in tasks that are a bit more lenient than the previous ones. This way the player, after mastering some tough challenge, can actually feel that he has gotten better, as problems that are still much harder than the first ones are becoming easy. This is exactly how the puzzle mode in Lumines got me so addicted. Every time I succeeded at a hard problem, the next ones felt like a breeze and got me to play more and more. When the next harder problem hit, I already had felt the satisfaction of success, and I was mentally prepared to face it.

Finally there's dynamic difficulty regulation. In this case, the game uses some mechanism to figure out when the player is not doing too good, and then proceeds to make the game easier. Sometimes this difficulty reduction is invisible, affecting only numbers inside the game's engine or reducing the effectiveness of artificial intelligence - other times it is more visible, when the game reduces the challenge itself by introducing fewer enemies for example. So essentially the game cheats for the player's advantage. This is quite typical in tabletop role-playing games as well when the game master makes his die rolls in secret, and can then freely adjust the result to keep the game more enjoyable. The problem with this approach is that some players might indeed feel cheated out of the challenge. Frankly, they don't appreciate your concern. Personally I think there should always be the option to turn dynamic difficulty regulation off.

Finally, multi-player games where players compete with each other are difficulty regulated by player skill. In these games, one important aspect is to try and match players with somewhat equal skill levels to keep everyone in the flow zone (i.e. not bored and not frustrated).

So, these are the most typical ways games do their best to keep players in flow. Can these strategies be used for real-life applications and tasks? It does seem to highly depend on the task. Difficulty is typically in the task itself, so we really cannot touch it. What applications can do though is to suggest a good task order for the user, based on past performance and statistics. This way users can more easily find tasks that match their skills. This approach does seem more suitable for tasks that are part of hobbies - at work the list of available tasks is often narrow, and there is not much choice in what to do and when.

One other way applications can do difficulty regulation is the level of automation, which I have already discussed in an earlier post. At first, tasks can be done in less detail, relying more on the application to work its best guess magic. When the user becomes more familiar with the application and tasks, more and more control is placed in the user's hands. Of course, the user will need full capability to override the machine's decision at any time, regardless of "difficulty mode".

I guess that's it for today.

Achieving Something... But What?

In going through the three topics I mentioned in the post on Flow, I'll start with the last one. Today, I'm going to talk about achievements - a particular kind of feedback present in both real life and games. Truth be told, I'm mostly going to talk about games, but you probably already guessed that anyway.

These days, games feature quite literal achievements in form of, well, achievements (XBox Live) or trophies (PlayStation Network) etc. These are built-in goals attached to the games, which can be pursued in addition to simply finishing the game. Some are quite trivial to get and usually gotten without any extra effort. These are not of much interest, as they do not motivate the player to do any extra work. The interesting ones are those that give players more reason to play the game beyond finishing it such as "Finish the game without firing a single shot", "Collect all secret items", "Defeat ultrahardbossmonsterofthemonth" and so on. However, it does seem that these kinds of achievements have more to do with setting goals than feedback. They are of limited use in measuring progress, but it's strictly on/off.

For the purposes of this topic, high scores and time attacks are of more interest. Both are ways of getting feedback immediately after the fact, and even during playing (if score/time is displayed). Hitting a better score or time is a clear sign of improvement - especially if you are improving your average result over time. Another quite similar way to measure one's own progress in a game is to see how far you get before game over. This is especially true in games that never really end, and the only real goal is to get better/faster/further (like Lumines Supernova, discussed in detail earlier). Similar measuring of real world tasks is possible as well, and at least one example was even mentioned in Flow. Of course, this kind of progress measurement works best with tasks that are repeated more than once. My job, for example, has little repetition. I don't write the same software twice or write the same article twice (unless I miserably fail with backups). I can optimize my software though.

Another quite similar method is measuring success in relation to others. Ranking lists, or in activities that support competition, win rates against different opponents work similarly. Of course, this way you are measuring your progress in relation to others and theoretically it's possible not to notice any improvement, assuming everyone progresses at the same rate (but of course in real life this is never the case). Competition also has some possible negative side effects (not everyone likes to compete), which is not the case when using scores or times to simply measure your own progress (of course, if you start comparing results with others, enter competition). I definitely do think everyone should have the benefit of privacy in measuring their progress.

The first step to take advantage of scoring-based feedback is to apply it to interfaces that are used for repeated tasks. The key is to make feedback easily accessible for those who want it. It is once again important to recognize that not everyone wants to be measured in this way. Another important point is to create a scoring system that encourages the best ways of doing the task. For other tasks that are not so easy to score (or time), providing statistics that can help the user make up his own scoring system could still be a useful way of providing more feedback. I for example am among people who are interested in the statistics of their own actions. Which word I use most in my blog? Do I have some preferred programming habits? Maybe I'd like to improve my vocabulary and start using more synonyms - getting statistics could empower me to do this.

So extending feedback beyond what the system is using, including statistics or measurements of user behavior into the application, is one direction I think should be explored more widely than it currently is. I also do think it is one step towards applications that are more supportive of flow activities.

A Look at Games - Flower

Before moving to more serious matters considering flow and user interfaces, let's take a look at a one particular flow experience. In other words a game, and more precisely, Flower. The game has received high acclaim all around, so I too had to see for myself what it's all about.

In Flower, you control a single petal, and your objective is to collect more petals by guiding yourself into flowers, at the same time bringing life back to the world. Some flowers open the way forward, allowing you to move into new areas. The basic concept might not sound very impressive but playing the game is a highly immerse experience for many reasons. First of all, audiovisual presentation of the game is really artistic and well-thought. Go on, find a game play video from YouTube and come back here. Disagree in the comments if you feel like it. Either way, for me the key point is how lifelike everything feels when you, as a stream of petals, are flying through the landscape, parting tall grass as you go.

Much like Lumines, which I discussed in my previous look at games, Flower also combines background music and sound effects as a for of composition. Guiding yourself through a line of flowers successfully creates a pleasant musical piece which further enhances the thrill from visual effects. Flower rewards success instantly - and not with points, better weapons or anything like that - but rather with a powerful feeling of satisfaction. This is a good sign that flow is happening. Of course, it's not just the feedback that makes immersion in Flower so strong. So, what is the key?

The fact I've been withholding is the way Flower is controlled. It uses just one button in combination with the PlayStation 3 controller's motion detecting capabilities. To change direction, just tilt the controller. Of course it's not a new idea, the Wii has been around for quite a long time already, but in Flower it really really works. You see, it's actually not very easy to control a flying stream of petals using motion detection, especially when they are flying quite fast. There is challenge, and the beauty here is that much of the challenge comes from the controls; the game challenges the player in a very physical way. And of course, the levels in the game do get harder.

Harder in a sense at least. I'm not sure if you can actually fail in Flower. No matter how long it takes to get that winding flower path collected, whether you get it on a single pass or twenty passes, the game itself does neither reward or penalize you. The player can set his own goals, getting better and better all the time, and there is almost always a longer path of flowers to collect on a single pass. That is, if you want to do that. It's entirely possible to just enjoy Flower as an experience, and sense of achievement can always be found. When you do a sharp turn, you can see the tail of your petal stream, in all its colorful glory, and realize that it is your creation.

Flower does a good job of inspiring flow. The challenge always fits the player's skills, as long as you're willing to set your goals (which happens almost automatically anyway). The game provides instant feedback and sense of achievement. Finally, the game allows you to marvel at what you've just created. That said, it's not without flaws. I didn't like the second half nearly as much as the first half, as it becomes more challenge-oriented. But it's not a long game, so go ahead and just play it now, if you own a PlayStation 3.

But wait! What can interface designers learn from it? Everything. If I could make a user interface as elegant and beautiful as Flower, I think I could stop my research right there.

And That's how I Flow

Guess which book I've been reading lately. I've accumulated some topics for blog posts lately, so I'll try and put them into writing in the near future. Starting with this one obviously. So the book I just finished was, if you didn't guess already, Flow - The Psychology of Optimal Experience (Mihaly Csikszentmihalyi) which is a book that gets mentioned constantly when discussing game design. There is, of course, a very good reason for that. In Flow, the fundamental guidelines to enjoyable game play are laid out, although it's not a book about games. The book in itself is not particularly lengthy, and if you just want the fundamentals, reading the first three or so chapters should do the trick (the rest is for you who want to know how to enjoy life to the fullest), but I'll go through the fundamentals very quickly.

Flow is the most enjoyable state of the mind, and flow is a very descriptive word for this state of mind as well. You remember those hours you spent solving that really hard problem at work? They did seem to go past awfully quick, right? That's flow, basically. When we are really focusing on a task that is challenging enough for our skills, that's when we reach flow. While in flow, we can forget about everything unrelated to the task at hand and avoid what is called psychic entropy, or disorder in consciousness. The activity and the person become one entity. Flow exists between boredom and frustration; if the activity becomes too easy, it's boring, and if it becomes too difficult, enter frustration. To stay in flow, the challenge of the activity needs to grow along with the person's skills.

Of course, some people can turn any activity into flow by designing their own goals within the activity while some people can't find flow even in the best circumstances. However, if the activity itself is designed with flow in mind, the state should be far easier to reach. This is why the concept of flow is extremely important for game designers. Games provide a continuous series of challenges and associated long (e.g. finish the game) and short term goals (e.g. defeat the boss). I will go over goals and goal forming in a later entry. In the optimal situation, a game can continuously provide interesting challenges to the player as her skills develop. Reality of course typically falls a bit short of the mark because player skills develop at a different pace. To compensate, difficulty regulation strategies are typically present in games.

The interesting question here is can we use interface or application design to improve the chances of turning tasks into flow activities. I have actually visited this topic earlier in several blog entries, although I didn't use the term flow activity as I hadn't read the book yet. One really simple idea that has been evaluated in at least one research paper* by researchers at Nokia Research and University of Tampere is to add achievements as an additional way to track one's progress. What makes games like Tetris or pinball machines highly addictive is the ability to compare your results to previous achievements of yourself or others. Score keeping is a really powerful feedback machine. When you get more points or break your time record you immediately know that you have improved.

Unsurprisingly, proper feedback is mentioned as one requirement of a flow activity. If we take all the requirements as inputs into a design process of an application and interface, what will come out? Will the outcome make it easier for users to get into flow state when working with that application? I'm thinking these could be among my key research questions. One challenge is to find a way to integrate flow activity requirements into a design process, and another one is to evaluate the results. In this entry I have been merely scratching the surface of things like goal forming, difficulty regulation and achievements. I will delve deeper into these subjects later on and see what interesting things I can dig out. In the meanwhile, I suggest everyone to check out this book. It really is important.

* The paper I'm referring to is "Applying Game Achievement Systems to Enhance User Experience in a Photo Sharing Service" (Markus Montola, Timo Nummenmaa, Andrés Lucero, Marion Boberg, Hannu Korhonen).

A Look at Games - Lumines Supernova

I've been back from vacation for a week now, so I guess it's time to get back to this blog as well. Last weekend I finally got a router and was able to share my internet connection to the PlayStation 3, granting me access to PSN store and some games I've been wanting to play. Some of these are quite relevant to my research, so you will be most likely seeing posts like this one in the future as well. So let's get this series started with Lumines Supernova.

I took initial interest to Lumines when I was doing research about games where audio plays a bigger role than usual. Lumines is a relatively simple block dropping game, where you as the player need to form squares of blocks with the same color. The playing field is constantly swept over by a moving beat line, and full squares are eliminated only when the line passes over them. The more squares you can eliminate in a single sweep, the more points you get. Sounds simple, right? In other words, it belongs to the category of highly addictive games like Tetris and Bejeweled. But Lumines might be even more successful in this. Why?

Audio in the game is not simply just separated into background music and sound effects. Every skin (kind of a level) in the game has its own music and effects, which are in fact part of the background music. The music being played is a relatively simple loop but when things start happening on the screen, the player, through his block manipulating actions, becomes the composer. Rotating blocks creates small sounds, forming squares bring forth a little more dramatic effect, and of course the most notable sounds are generated when the beat line erases complete squares. On the paper it might not sound very impressive, but the gaming experience is from an entirely another dimension.

The game pace changes over time and the blocks start dropping faster and faster. In the beginning everything is quite relaxed, but sooner or later things start to happen so fast that complete planning becomes impossible and towards the end it's all just hectic panic. In the beginning, when the game itself is relaxing, the player can pay more attention to the complete audiovisual experience that is Lumines, enjoying the results of his actions portrayed in the background music. This occupies the player right off the bat. Of course, towards the end, the brain becomes so occupied with dropping blocks that no attention is paid to the music. For me it gets hazy after the fifth or sixth skin, and I have no recollection of what kind of music is played from that point on. Another neat thing is that when the game becomes more hectic, things start to automatically happen more quickly - because those blocks are dropping fast - and the music becomes increasingly more intense.

And now the interesting question: what can we learn from it? It would be interesting to try out something similar in user interfaces. Play background music and tie part of it to user actions. Produce small sounds when typing letters in a word processor, complete with a longer sound when a full line is written. Or a paragraph. Whatever the implementation, the key idea would be to use this kind of music generation to increase motivation. I think it would be most suitable for an application domain where user actions are relatively simple and doing them quickly is possible and desirable. In a way, something like this would make the rhythm and flow of work quite concrete.

While waiting for someone to come up with a working prototype, I recommend you to try Lumines (any version) or another game that uses the same kind of background music system such as Rez or Chime (neither of which I have been able to play yet, but will in the future as soon as I get an Xbox 360).

Vacation & Looking Back

I'm going off on vacation for about two and half weeks. Most likely there will be no updates until I'm back. Unless I feel some strange urge. Anyway, now's a good time to recap what's been going on since I started.

A lot of progress has been done in the reading department. 8 trade books on usability or game design related topics, and I'm now going through Rules of Play (Salen & Zimmerman) I've also been digging through any articles I was able to find about combining games and HCI. There were some, but not that many. So definitely there is still work to be done in this area.

In this blog, I've been outlining things about playful usability, and bits and pieces about interactive spaces as well. The ideas are at this point still all over the place and I haven't landed on an actual topic for my doctoral thesis. But I have time, and I think I should explore a bit of everything just to get a feel of things. I do have a much stronger idea now than I did three months ago, so clearly there's been some progress.

Experimental interfaces are raising their heads. After vacation, I'll try to find some time to work with prototypes using various kinds of controllers. I'm not going to unveil which ones at this point, but I'll be sure to make some noise here once I get to work. At the moment though, these are mostly something I have to do on my own time, and on my own computer at home which is a bit lacking. Probably I'll need to get a new one sooner than later.

At my actual job we're going to finish our prototype in August, and during Autumn there will be user tests and paper writing. And of course, there's the XNA programming course looming ahead, which I'm really looking forward to. If that experiment goes well, we can try and introduce other game related courses. And I do like teaching as well, although I don't have that much experience, yet.

So that's it for the recap. More posts will follow after vacation.

The Emotionality of Fuzzy Things

As you might be able to guess from the title, I've also been reading Emotional Design (Don Norman). Like with the other book, this was my second read-through. What I realized while reading this time around, is that this particular book is perhaps the most essential one for my research. Indeed, most of the things I have been writing about can be derived from what Norman presents in these pages.

Playful usability definitely builds upon the emotional side of human thought. It doesn't even pretend to be functionally optimal. Highly functional interfaces are effective. They take the shortest route. Playful interfaces on the other hand are more creative. Or, using the travel metaphor, they take the scenic route. Or maybe the route that is just more entertaining to drive. Really straight, long roads are effective. They are also really boring to drive, which is why I usually don't pick them. So today, I'll take a look at playful interfaces, through the lenses of the three levels of human thought presented in the book.

I guess before that, a really quick recap of the said levels is in order. For a more complete description, read the book. The three levels of human thought are visceral, behavioral and reflective. The first two are sub-conscious while the last one is conscious thought. Visceral level is the most basic input-output system built into us. It excels at giving out immediate responses. The behavioral level is where activity is performed. It handles any activity that doesn't require conscious thought to perform. While I'm writing this, the movements of my hands on the keyboard are controlled by the behavioral level, leaving my consciousness free to think ahead what I'll write next. And of course, that is what I'm doing on the reflective level. Here I am making decisions how to express myself and my ideas through this text.

Playful interfaces are by nature likely to be more novel than highly functional ones. Sure, functional interfaces can be decorated, but the methods of interaction follow convention. Playful or fuzzy interfaces can surprise the user with more than just visual decorations. At this point, we are clearly working on the visceral level. And I think it's really important to be affective here. It's the wow-effect, "hey, I wanna try that", that should be achieved. Applications and services need to advertise themselves, especially in interactive spaces where high personalization is not affordable (i.e. same services are generally offered for everyone). Often one glimpse at the UI is all you're ever going to get from your potential users, so that glimpse better bring them over. This kind of appeal is especially important to make people aware of services they didn't think they'd need.

As stated, playful interfaces are not even trying to compete in raw functionality. The argument goes: effectiveness can be achieved through enjoyable use, even if the actions themselves are slower. People are not machines, we get bored with uninteresting tasks and our minds wander away. This should not be big news to anyone, hopefully. Take a look at games. Games rarely provide the most effective means to reach a high level goal, which does indeed make them enjoyable. So, in the behavioral level, the aim for playful usability is to make high level goals more enjoyable to work towards. The means towards this end is to make individual tasks not necessarily optimized for speed, but optimized for fun instead.

Of course, making work-related tasks fun while retaining their original purpose is a hard one to tackle. If it was easy, we would most likely have it already. It requires a lot of lateral thinking. Especially in the domain of desktop applications, user interfaces are inside that same old ugly box. I've said this before, but it's worth repeating: that box needs to be tucked away for good. Thinking outside that box is not enough. We must find a new box altogether and then think outside that box. Or, preferably, a lot of boxes solely for the purpose of thinking outside them. Or, well, you get the idea. Just to put things in context, I have picked up the box labeled "game interfaces" and I'm trying to think outside that box.

I'm actually a bit of an optimist in the sense that I firmly believe that for playful interfaces, visceral appeal might be achieved as a side product of good behavioral appeal. At least I'd like to think that most things that are fun to do, also look so. Sure, I can come up with counter examples. However, at least in the beginning novelty is the other factor. Interfaces that are fun to use will most likely look very different from what people are used to, leading into curiosity. There lies a risk though. Control by gestures or speech for example can feel weird to some people. Especially if they have to do it in public. Talking on the phone is easy to accept. Talking to the phone is not.

Finally, we have the reflective level. I'd consider this to be even more important than the other two, but also harder to write about. Certainly, a good user experience is already achieved with enjoyable execution of tasks. On the reflective level, we want users to look back at the experience with positive feelings. Also, we need the user to feel good while using the interface. If we jump back to games, it simply doesn't matter how good playability a game has if it doesn't match the style or theme of the game. Therefore, it is important that a playful interface contributes to the overall experience of performing a higher level goal. And of course, how using the interface sits with the user's self-image.

Taking emotions into the equation raises a whole lot of things to consider when designing playful interaction. User experience is not a simple matter. Even in pure entertainment applications such as games, no one can tell exactly what needs to be done to ensure that ultimate playing experience. Sure, reading a book or ten about game design helps. Reading books on related topics helps more. But in the end, it all comes down to understanding your audience. Even then, sometimes you just have to break the rules, shake people up and bewilder them completely.

Making an experimental interface is easy. Making a successful experimental interface is not. That's what keeps researches like myself ticking.