Friday, September 17, 2010

Audio Mostly in Piteå

Before continuing the Flow-series of posts, I'm presenting you a conference report. Audio Mostly is a conference for interacting with sound, so what was I doing there? Well, coincidentally, the organizing party is collaborating with us in the II City project, and my work just happened to be in demonstrable condition. Of course, now that it's been demoed I guess I can also write a post describing it a bit. Later though.

While I'm no audio expert (in fact, I just know how to listen to music - but I do think I'm fairly good at it!), the conference had much to offer, mostly in the department of game audio. It was also a good glimpse into the field of audio design, something I previously had little or no idea about. So now I know a little bit, and I can put my knowledge to use in game design or elsewhere. Although I will still have to rely on someone else to actually produce the audio - I have vowed to stay off the arts. That is of course a time issue - if I had the time, sure, I'd like to be my own graphics artist and audio producer.

The more interesting papers were about researching how people perceive audio. What kind of audio is suitable for different situations, how well audio expresses something, is it possible to tell stories using non-speech audio only and so on. From game design point of view, this kind of information is highly valuable (there even was one paper about horror game sounds). From the interface point of view, I'm kind of skeptic. As I am writing this, I'm listening to music and I have turned off every single audio signal from my operating system. There is only so much audio that can fit into one environment. Audio feedback is good, but relying on it too heavily can backfire. But that is just my opinion, and I should probably check some papers on the topic.

Since it was a small conference (they're keeping it that way intentionally) the atmosphere was really relaxed and enjoyable. I met a lot of people who were doing interesting things, and many audio-related conversations were had. Overall, Audio Mostly was more fun than Foundations of Digital Games, but not as useful for my research. Also, the chances of me going there again are kind of slim, especially now that I'm slowly transferring my work to a new project from II City (which also ends before Audio Mostly is next held in Piteå, which would be 2012 - they're having it in some more remote location every other year).

Thursday, September 2, 2010

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.

Wednesday, September 1, 2010

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.