Teaching Experiences - Game Programming Course

As I mentioned briefly, this Autumn I was teaching a course called Introduction to Programming Through Game Development. It was a short short course consisting of roughly 30 hours of combined lectures and guided practice. The idea of the course was to try out a new method for teaching basic programming. Unsurprisingly it was targeted to students interested in game development. Today I had the last guided session. Final results of the course will be evaluated once the students have turned in their assignments. For now, I will share some thoughts I had about the actual teaching.

Cramming basics of programming and basics of programming into one course is a lot of things to teach. If compared to our department's normal elementary programming course, the amount of topics is most likely doubled. The saving grace is motivation. However, in retrospect I should have probably reserved more time for the basics of basics. This time I got away with it, if only because everyone actually attending the course knew at least something about programming. Although this also means we didn't exactly reach our intended target audience. The first note to self: the course needs to be longer or some topics, no matter how useful they would be, need to be dropped.

The idea that motivation is higher when the topic is truly interesting is not surprising. From some comments, and some impressions I had while teaching, the course did seem to embody this idea. Our topics were more advanced and they were introduced on a quicker pace. Most people were still able to keep up. The course implementation suggests that those who didn't should have come up to speed on their own time (around 10 hours per week were scheduled for independent learning). It is safe to say however that motivation is clearly not enough to make this really really work as an introductory course.

My teaching paradigm can be summarized into a few words: "Provide impressive results early and often". Students on a programming should get their hands dirty within the first hour. This is not unlike games - the player needs to achieve something within the first five minutes or so. Drawing objects on the screen is in fact very easy when using XNA, so this requirement was definitely met. This I found to be in general a good thing when teaching game programming. Results are highly visible. Especially in the beginning. Once they know how to make a sprite move, the students are hooked. Then it is possible to move into the nitty-gritty of programming for a while. When they start to get bored again, it's time for more impressive stuff.

I still need to work a bit on this almost game-like course structure but I do think it definitely works. Starting with the easy stuff might sound like the way to go, but I think it's better to go for the impressive first even if it is a bit harder. Another really good thing about game programming is teaching object oriented programming. It becomes a lot easier if the objects are actual sprites on the screen. You can almost touch them, that's how concrete they become. OOP in general is one of the harder programming concepts to grasp but also one of the most important. Therefore it's really good if we can make it more accessible. In game programming it's also quite impossible to get very far and stay sane without using OOP.

To summarize, I think my teaching ideas are sound in principle but I need more experience. This course was just an experiment, but we're hoping to make it into a real course in the future. This will be my chance to improve it further, and of course improve my teaching at the same time. In the meanwhile, I'm teaching normal elementary programming for the next ten weeks, which will be another chance to improve my teaching abilities.

Next month I can follow up on this after seeing the assignments and feedback from students.

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).

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).