Lesson from Games: Discarding

This is something I have occasionally thought about, so I'll write it down now. I'll get back to the relationship of games and places next week. It applies especially to board games that require strategic thinking.

In board games, players are typically faced with a certain set of options, and they hold a certain set of resources. Good design principles state that games are designed in such a way that playing them is a series of interesting choices with relevance, and this is especially true of board games where play time is typically limited. This is different from e.g. single player digital games where it is more often possible to explore all the options by spending more time playing. A board game always has a limited duration. To win, each player tries to make the best of each of their turns. One really important strategical decision in many board games is to choose what to pursue. It is often necessary to also commit to this strategy, and this is the important thing. The old proverb about two hares is often very true.

Reiner Knizia, a famous designer, has a particular habit of making games where it is highly important to recognize when something is no longer worth holding on to. In one of his best games, Tigris & Euphrates, the best advice that can be given to new players is "there is no such thing as 'my kingdom'", meaning players should not desperately defend a particular kingdom, even though they have built it (in T&E, players get points for building and destroying kingdoms, not for holding kingdoms). Board games often force players to decide what is least relevant to them by forcing them to sacrifice some resources of their choice. In general, to make the most of their turns and resources, players need to recognize options that are not highly relevant to their strategy and promptly discard those options (e.g. choosing to not produce certain resources in 7 Wonders, effectively closing the opportunity to play certain cards).

The lesson of discarding the slightly less relevant is important for many aspects of life. Especially design. New game designers are always advised to simplify, and then simplify some more. In game design, it's a necessary skill to be able to let go anything that doesn't directly support gameplay of the game. This is no different from, say, user interface design. Simplify, discard, don't fall in love with anything. In programming, this can translate into realizing when a piece of code has to be discarded and written again from scratch to improve the overall code structure. In life it's typically better to find a small amount of things to really focus on.

The reason why I find it cool that games teach this stuff is that we humans often behave against this strategy. In Predictably Irrational, Dan Ariely has devoted one chapter to our irrational behavior of trying to keep all of our options open. It is psychologically hard to let go of an option, as long as there is a at least a chance that something might come of it. Of course, games are different in this sense, because it is much easier to accurately know whether an option is going to be any good - still, it's not for certain. If we think rationally, we can assess the potential of our options in real life as well. It's beneficial if we can do this and discard things that are not really relevant.

This is of course part of a larger context of strategic thinking that games, especially board games, teach us.

Education: The Game

Just a short post. If we think of typical university education as a game, it is horribly flawed. I'm going to use one abstract course as a test unit for this analysis.

The game starts with the player having some resources (including skills etc.) which they have earned from previous games. Hopefully they can remember all that stuff, because this game is not going to re-iterate over that material. Often they are at least told what resources they should have before starting this game. When the game starts, it's level after level situations where the player gains resources. They just are not told what these resources do and how much they actually have them, because this information is completely invisible. Often these levels feel like grinding. Grinding for random drops, but the player doesn't even know what is dropped.

Skip to the end of the game. The infamous boss monster, The Exam. Now the player is rewarded for having all those bits of resources they have gained. Most players go grind for resources in completed levels just to be sure. Some just run through the levels, and only start getting resources a few days before the boss fight. After the boss dies, the player has to wait a while. Then they are told whether the boss actually died.

Our education system is like a game where all meaning is packed to the very end. We just grind through the levels until we get to the end and only then it is revealed to us whether that grinding was useful or not. Would you play this game? If it takes 40 hours? Or you could just skip the grinding for permanent resources, do a quick grind for some one-time items and defeat the boss. You get the same reward but your character has gained next to nothing. The game doesn't really reward you for having a better character, only defeating bosses.

I think this needs to go.

Cooperation in Games (and Elsewhere)

Last week on Friday I and a few fellow researchers were taking part in a cooperative game session. The purpose of that particular game is to improve communication inside teams. We tried it out for more research-oriented reasons. There is a lot we already know about playing together and cooperation but this doesn't prevent me from thinking it a bit. So here we go: another game-related blog topic. Just some general thoughts about cooperation.

Lately I have mostly cooperated with other players in board games. Recently cooperative board games have been on the rise. They are a good concept for a couple of reasons. First of all, in cooperative games it is less important for the players to be evenly matched. They are competing against the game after all, not each other (although some of them have one or two players as traitors trying to undermine the others!) This makes them more accessible to less than hardcore players. The other reason is just that thinking together is Fun (yes with a capital F). I also do believe these kinds of games are good for improving communication skills (there is most likely research done on this subject, something I'll have to dig up later).

Board games also integrate the benefit of bringing people together into the same physical space. However, cooperation in digital games over the internet is no less fun. One quite important difference worth notice is what skills each player brings to the game. In board games, players mostly bring just their brain. Manual dexterity, hand-eye coordination and so on are not really important because the games are not played in real time*. In digital games played on consoles or computers, players typically need to be familiar with appropriate input devices. Real-time games typically also require reflexes. First-person shooters require good hand-eye coordination. Put simply, they are somewhat less accessible for non-experienced players.

Digital games do have a benefit over most cooperative board games. In board games, where thinking time is theoretically infinite one player can, in theory, play the game by himself. This causes a situation where less experienced players find themselves being told exactly what they should do on their turns. This is seen as a problem among the board gaming community, largely because in board games carrying out actions is trivial. Fun is in the thinking. In digital games it is much easier for game developers to make games where one experienced player cannot play for the whole team. Experienced players can still be leaders, giving out directions or even orders (in more organized play) but overall success is much more dependent on everyone's skills.

Assuming the aim is to improve everyone's communication skills, some tricks can be employed. Many board games employ rules that somehow limit communication. For instance, in many cooperative board games players are not allowed to show their cards to others. Often it is even forbidden to talk about one's cards in detail. Another thing that can be done in board games is enforcing time limits. If time is limited, one experienced player simply doesn't have enough time to mind everyone else's playing. Basically any kind of knowledge distribution scheme works wonders.

In digital games critical resources can be distributed among the players. When everyone can do something others can not, everyone needs to be involved. In most games, location can be considered a resource. Information visible from one particular place can be valuable and therefore require one player to stay there and report said information to others. Generally speaking, dividing the game to multiple terminals (computers or consoles) allows more player specific information which is also harder to convey to others. In the spirit of time limits, the game could even enforce microphone time limits. Speak too much, and your mic goes silent leaving leading for someone else to do.

Ahem. Looks like I sidetracked quite a bit. But hey, at least now you might know more about the specifics of cooperative games. Cooperative play is motivating. Winning or losing is no longer just about yourself but the whole team. It also makes many seemingly less interesting games much more interesting (try and play some coop board games solo, they are quite boring). Cooperation is also generally important at work. Most people these days don't work solo. As usual, there are two angles when looking at games and real life cooperation. The first angle is improving communication skills via suitable cooperative games or game-like activities. The second angle is making tasks more motivating by increasing game-like cooperation.

The second angle is a matter of tools. Cooperation generally leads to better results and is therefore already desirable. Many applications on the other do not support cooperation. Means of remote communicating need more improvement. Voice and text are often insufficient. It is much more powerful to show things. Solutions have been developed and will be developed in the future. One important requirement for communication and cooperation is that it needs to be effortless. Cooperating with people on the other side of the globe should be as effective as with people in the same office. At the moment this clearly is not so. Perhaps games can help us here. That is one more question for me to think about.

* There is at least one really good exception. Space Alert is a game where players together as a team have exactly ten minutes to plan all of their actions for the game. These are then carried out afterwards to see how the plan holds together. The time limit demands quick thinking and really good coordination from players.

The Design of Fuzzy Things

Another book-related post. This time I'm going to approach the topic of playful usability via The Design of Everyday Things (Don Norman). I don't think I this book needs any more recommendations, so let's just go ahead with some thoughts of my own*.

I'd like to start with the three models. There's designer's model, which is how the interface is designed to work. On the other end, the user's model, is how the user thinks the interface works. And in the middle is the system image, responsible for communicating how the interface works. In other words, the user's model is dependent on the system model. In fuzzy usability, the system image is intentionally non-obvious. The idea is not to directly communicate the workings of the system but rather present an interface that raises curiosity and allows the user to discover the workings. By obscuring knowledge we make it more desirable to attain.

My hypothesis for the benefits is that interfaces constructed this way are easier to learn. In a typical desktop interface such as the Firefox web browser I'm currently looking at, the user is immediately presented with a lot of actions. Wizards are often used to guide beginners. The downside is that wizards are separate interfaces for doing specific tasks and do not teach the user to use the program's interface. In a purposefully obscured interface, it is easy to start by presenting the most basic of tasks and reveal advanced features when the user "levels up". The application can reveal the presence of features when they become relevant.

We can think of interfaces separated into zones. Anything the user is already familiar with is in the safe zone, and the message is clear "you know these things, it is safe to work with them". On the borders of the safe zone, there is the uncertain zone. The user has an idea of what is there, and it's kind of saying "you might feel uncomfortable here, but these things can make you more powerful". Finally, there is the great unknown, beyond the uncertain zone. When the application realizes that the user is doing something that could be done better with an advanced feature, it can assign quests, sending the user to explore a particular uncertain zone or even an unknown zone. If the user wishes to find a particular feature, the help system can provide directions of how to get to that feature.

Unsurprisingly, this bears high similarity with playing openworld or sandbox games like Grand Theft Auto. The player can explore quite freely, discovering new areas progressively while learning new skills. But when the player wishes to get on with the story, there are certain things that are required, and hence the game sends the player on quests to meet these requirements. Add rewards for mastering new skills. One further way to think of this comparison is that of task. In a game, the task is to complete the story. In an application, the task is to complete some external goal. Typically the difference between these two tasks is their definer: in a game, the task is defined by its designer while in an application the task is defined by the user. The point remains the same though: why shouldn't the user/player have fun while learning the skills required to complete the task?

In terms of affordances, safe zones afford safe using of features with predictable outcomes; uncertain zones afford experimentation with features; unknown zones afford exploration. Restrictions can also be used by requiring certain features to be in the safe zone before the user is allowed to use particular advanced features. This will ensure that the user has grasped some important basic concept before trying to use a feature that heavily builds upon that concept. The restriction also comes quite naturally - the user needs to traverse through the prerequired features on his way towards the advanced feature.

Implementing an interface that conforms to this model should be an interesting task. Some key considerations in functionality are to ensure that 1) the safe zone really is safe and 2) the uncertain zone clearly supports experimentation. Predictability is key in the first consideration, while proper undo support is key in the second. Another implementation question is analysing user actions in a way that the application can decide when it is appropriate to advertise a feature.

* Similar thoughts can be encountered in several HCI articles, and I'll return to them later. Difficulty regulation is a good key word if you're looking for one.

Foundations of Digital Games 2010

Another busy week behind. Exactly a week ago I was on my way to California, and more precisely the Foundations of Digital Games 2010 conference in Monterey. Here comes the aftermath.

Considering my own research, FDG2010 was mostly useful for the game design point of view but not that much actually. There were some interesting presentations and conversations with people about experimental game control methods, and finally some proper information about Kineckt. However, considering teaching game-related anything or game-aided education, the conference was much more useful for me. The details about the conference will be available later somewhere in the internet, so I'll just post some collected thoughts.

There was a plethora of sessions about inspiring more interest for computer science by using games and game design as part of CS education as well as to make potential students familiar with game development before college. I'm not exactly sure as to what the situation is here in Finland but I guess we can always use more interest. Probably the single most interesting session was about Microsoft Kodu, which is a visual game programming language, easy enough for children to learn. In the II City project, we are interested in using focus groups to create ideas for games, so you can probably see where this might be going. Yes, we can use Kodu to familiarize non-programmers with game dev.

Another thing I picked up were a lot of ideas for teaching a more serious game development course for post-grad students. This topic was presented in several sessions, and also discussed randomly throughout the conference. I'm mostly interested in doing this as a project-based course, and if possible, as a cooperation between our university and the department of industrial design in the University of Lapland. Bringing in artists from another university can get around the problem that CS students are not expected to have artistic abilities (and therefore we can't require them). This was how I had thought to do it to begin with, but discussions in the conference made me more confident. We can do this.

It was also nice to see a good glimpse of all the work being done in educational games, the Holy Grail of e-learning. There were quite a lot of projects presented that taught students computer science concepts in ways more interesting than plain programming practice. Using these kinds of games for teaching the basics of programming is an idea worth contemplation, especially if people are having a hard time grasping some of the concepts in our introductory course (I haven't asked yet, but in August I'll probably see for myself anyway). Of course, many a presented game taught other concepts than CS, such as how cats see the world.

Finally, game design was definitely not a forgotten topic. However, since there were always two sessions in parallel, I had to make choices, and because of my job, I ended up selecting all the education related sessions. So, like other people, I will have to check the interesting game design presentations when the presentation videos become available.

Jetlag and all that jazz aside, it was a good experience for a first conference trip. Although I definitely didn't expect that it would actually be cold in California. The wind was a real killer, especially on Saturday. In addition to huge amount of inspiration, I got to meet a lot of awesome people. Hopefully I'll be able to visit FDG2011 if it gets organized, wherever it might be. Oh, and the conference center had some serious Norman Doors - I took one pic, which I'll try to post later when I get it on my computer.

(During the trip I also had a lot of time to read books, so book reading report is up next)

Irrationality and What Should We Do with it

Time to discuss some stuff I've read from books recently. The first book is Dan Ariely's Predictably Irrational. It's actually a book for behavioral economics, but can tell a lot about how we humans are wired for anyone in any field. Because it's also quite fun, not too long and well-written, I can recommend it to anyone even remotely interested in human behavior.

In the book, Ariely discusses a lot of different types of circumstances where humans repeatedly fail in rational thinking. Hence the name. A lot of the stuff is actually really familiar for most of us, because we've been down those roads. The book does a good job of pointing out the circumstances where people make bad decisions. If people became more aware of these things, maybe they could make better decisions in the future. Who knows, right? For someone in the HCI field, and game design as well, every tidbit of knowledge about human behavior is valuable. Here are some thoughts I gathered while reading:

Actually my first thoughts were whether we could actually use this kind of irrational behavior to purposefully "deceive" the users. For game design, it's also helpful to know how people form their decisions in different circumstances. This way players could be guided implicitly instead of explicitly when the designer would really like the them to pick a certain option. Most players would likely end up picking the intended option, but they would still think they are firmly on the driver's seat. Actually I think it would be an interesting for game researches to analyze how decision making situations are staged in games (although they may have also done this kind of research already).

And what about interfaces? It's kind of a harder case. Here the designer doesn't want to guide the user into doing something. The idea is for users to get what they want, which is something we really cannot predict. I don't have any particular ideas yet, but I'd like to explore the concept of purposeful deception in usability to produce outcomes that make for a better user experience. Maybe it's a dead end but you never know before you try.

Then again, should we exploit irrationality? After all, it causes people to make bad decisions that can be really damaging to themselves in the long run. Perhaps it would actually be better to make games and applications that highlight our irrationality and make us aware of how it affects us even in situations we consider "too important to fail". Some games do require players to abandon certain types of irrational behavior. A lot of board games for example encourage players to make hard decisions instead of keeping all the options open. In order to win, players need to commit to a strategy sooner or later. It promotes simple folklore wisdom; "if you run after two hares you will catch neither".

This I think is another interesting topic where games could be used for teaching people, more effectively than most learning methods. After all, games are good for experimentation, because players don't lose anything permanently (in most games anyway). Of course therein lies a problem as well: we think differently when we know there is nothing to lose. So even if we learn to avoid our irrational behavior in a virtual world, does this wisdom transfer into real life, where losses are also real? It might be a tough challenge to come up with something that produces real benefit, but something that should be considered.

We are already coming up with games and applications that encourage people to exercise and look after their health etc. Should improving our thinking be the next step? After all, it is our thinking that's the root of everything else.

(I've also re-read Donald Norman's The Design of Everyday Things but it's something I'll get back to later.)

Of Word Processors and Context-Awareness

I hate word processors. In my opinion, they are an excellent example of something, that is really natural and easy for humans to do with pen and paper, done so hard that it baffles me every single time I need to do something I previously didn't need. Or indeed, do something I do rarely. Sure, the people who've been using these unnatural abominations for years and years know how to operate them, but if the casual user wants to do something as radical as putting an image somewhere in the document and wrap text around it they can be in for a world of pain. Or, let's say I want page numbers, starting from the very first page but not displaying them for the first ten pages.

It's all in the help of course, but knowing where to look is not always obvious. Open up your word processor's help and look at the size of that thing for a quick reference of what I'm talking about. This is basically understandable, as word processors have (and I guess they need to have) a plethora of features. A lot of these features are stuff needed only by selected few of us - each user group needs only a fraction of the entire feature set. The problem is, with this many features, finding the one you're looking for is difficult. Everything is organized, but before you can make any use of that, understanding the categorization logic is necessary. Simply put, they are not context-aware.

What games (good ones anyway) do effectively and word processors do not, is providing information on how to use them when you actually need that information. Sure, Microsoft tried with the Paper Clip of Mighty Annoyance, and that didn't turn out well, but is also no reason to stop trying. One problem of course is that it's quite hard for the application to understand what the user is doing, due to its monolithic design. Still, the application should at least provide a help shortcut on each and every one of its dialog windows, to open up a list of help topic relevant to that particular dialog. Help should also be action-oriented. When I want those page numbers, I don't want to know what each and every gadget on the dialog goes, I just want to know how to get my page numbers exactly where I want them.

Of course, games have the definite advantage of much better understanding about what the player is about to do, due to their predetermined nature. Games with linear progression are obvious, but also sandbox-games where the player can go where he pleases can still usually have some idea what the player might need to know next. But it's not like we can't make word processors context-aware. Perhaps it'd be best to actually break down their monolithic design, and try an object oriented approach, something programmers should be very familiar with, but which strangely doesn't find its way to user interfaces too often. I think it's better to provide an example scenario.

I start writing a document, and at the moment the word processor only provides the very basic features for writing text and positioning it intelligently. This is all the word processor itself does: manages positioning and text input. Then I realize I want a picture, so I paste in a picture component. When I click on this component, I only see tools for picture management, which is again something I don't need to see when I'm not setting properties for my picture. I write again for a while, until I need to paste in a table component. Lo and behold, there's a table, and when I select it, I have all the table-editing tools at my fingertip, and nothing else. Finally, when I'm done I realize I want to alter the positioning. So I summon up a grid, tell my components and text paragraphs to snap to it (to keep them neatly lined) and drag them around until I'm happy with the results.

See? Context-aware word processor. I actually quite recently found out that Word 2007 (been using Open Office in Linux) does a lot of this, so perhaps there is still hope for word processors as well. The last part of my example scenario on the other hand is something I can do in Excel or similar programs, but not in word processors. There could be a very good reason for this, but it's also a real possibility that there isn't, because software generally tends to follow old conventions. Of course, it is nice that all the new software works somewhat like the one's we've been using before, but if no one breaks this cycle, we're stuck with usability models that have been outdated for a long time, and bringing new people, with little experience using computers, becomes harder and harder as time goes by and feature numbers creep up.

So, perhaps it is indeed time to rethink everything from scratch.

Games are Complex - A Case in Point

The purpose of this post is to just take a moment and consider how much complexity can there be in a game that looks quite simple from the outside. Of course I could always take a game that looks and is complex, like a simulator or heavy strategy game, but for those you can really tell their complexity by just looking at them (or their manuals). Besides, I have relatively little experience with them, especially recently. Instead, I'll tackle something I'm quite familiar with, and something that might surprise at least some readers. Let's just call it the Monday morning shock effect.

I'm going to talk about fighting games, a genre which includes quite popular titles such as Street Fighter, Tekken and Soul Calibur. On the outside, these games look relatively simple and straightforward. Each player controls a character on the screen, moving and performing attacks using their controllers and trying to deplete the other player's life bar before losing their own. But let's take a look under the hood. Just poking around inside the game (using Tekken 6 as an example) we can see that each character has in fact more than forty different entries on their command list. These are the button combinations the player needs to press to perform a particular move or canned series of moves. Before you can even consider becoming a good player with one character, you need to know these combinations.

This is hardly mastery though. Moves in fighting games have lots of properties that are not listed in the game. One of the things serious players quickly need to become familiar with is frame data. First of all, frame data tells how many frames (1 / 60th of a second) a particular move needs to come out. Second, it tells frame advantage or disadvantage in three situations: the move is blocked by the opponent, the move hits the opponent or the move hits the opponent who is also performing a move (think of it is interrupting). Just so you have the basic idea, if I do a move that puts me at a disadvantage of 12 frames if it's blocked, then I cannot do anything during those 12 frames, meaning you can get a free hit with a move that comes out in 12 frames or less. So that's four additional numbers for each of the 40+ moves (in reality, you don't need to know the exact numbers for all moves) to learn.

Of course, all this stuff is learned not by reading and memorizing, but by reading, applying in practice, then reading some more and applying, until all the relevant information sticks. Oh, and in addition, you also need to figure out how far a given move reaches and is it circular or semi-circular (i.e. can the opponent avoid it by moving sideways). For argument's sake, let's assume you have learned all this stuff for one character. Then what? Well, there are 39 other characters in the game, and if you play competitively, you can run into any one of them. And yes, in order to be a competitive player, you need to know their moves, frame data and all, as well. Granted, you don't need to know everything about a character to fight against him effectively, but knowing at least the most important moves really helps.

The best way to do this is to first play against someone, then read, then play again, and read some more, until you get the hang of it. This can take a lot of hours for just one character, and the only way to do it is to play against a human opponent. These days you can play online, but as a reminder, when talking about games where fractions of seconds are of importance, even small amount of network lag can make a big difference in how the game is played. So in order to really play the game, traveling becomes a necessity. All this for what gain? Well, most of us just gain the thrill of competition out of it. Of course if you are really, really good you can even make a living, at least if you live in South Korea, the world capital of eSports.

To summarize, to fully understand the system in Tekken 6 (yes, just one game), you need to know the properties of about 20 moves or more for each of the 40 characters - that's around 800 datasets to learn - and of course you still need to figure out how to make use of all this information. Oh yeah, when they update the game to the next version, this information changes, so you need to keep up. So, how hard did you say your college math course was again? Naturally not that many players want to achieve this level of mastery - they just want to mash some buttons and never understand what's going on in the game. Then again, some people just memorize the facts the night before a test, to forget everything in the next week.

This kind of complexity and infinite learning curve is in fact pretty typical for really competitive multiplayer games (for a classic example, think Chess). Their learning curve is in fact pretty exemplary: starting to play is easy, and new things are learned when you need them - when you lose to someone, you need to either figure out new tricks for yourself, or research their tricks and learn some counter techniques (best do both!). Finally, playing competitive games like this is a strongly social activity. Once I have a hard copy of What Video Games Have to Teach Us About Learning and Literacy (I've read it via ebrary, which I must say is a good example of horrible usability) I might run an even more through analysis of how the learning principles in that book match with competitive playing of fighting games.

It's Easy - All You Need is the Holy Grail

The first two books I decided to read for my post-graduate studies were A Theory of Fun for Game Design (by Raph Koster) and What Video Games Have to Teach us About Learning and Literacy (by James Paul Gee). I chose these for two reasons: First of all, they both deal with the very fundamental basics of why people play games and what games can give us, and well, they were available through the university library as ebooks, while the rest of the books I wanted to read were not. Anyway, no matter the reason, they turned out to be really good reads, and I can recommend them to anyone slightly interested, especially the first one since it's really short, lightly written but has a lot of good points. Gee's book is a bit heavier, but still easy to read and not too long.

The main points are related to learning, which for the second book should not be such a big surprise. In the first book, Koster takes the view that games are fun because we are learning when we play. It is at least very hard to deny the learning part. Gee on the other hand writes about how good teachers games (and game designers through their work) actually are. The claim that we learn things when we play games is hardly revolutionary. Most games are not in fact easy. And quite a lot of them are actually very complex, so when you pick up the controller for the first time, you can't just suddenly do everything in the game. Actually, you might need to learn more things to play some particularly heavy games than you would need to pass a high school course of any given subject (I'm going to give an example in a later post, for now just take my word for it).

Of course, the problem from education's point of view is that games mostly teach skills that are only relevant inside the gameworld (and probably in gameworlds inside the same genre). Although this is not exactly true, as there are several very common abilities that playing games can enhance, there are a lot of school subjects that you really cannot learn from modern games. Of course, educational games can be, at least in theory, created for any subject. However, and hence the title of this post, it is often seen particularly difficult to disguise the learning in such a way that the player doesn't feel he's studying some boring school subject while playing, but just happens to need those skills to proceed in the game. That's the Holy Grail of educational games in my opinion.

If you read through Gee's book, you'll find that we don't actually need this Holy Grail to combine the way games teach us to learning something that is actually useful (I'm not going to argue about the usefulness of school subjects). Gee introduces 36 learning principles that we could just take and try out in school education. I'm not going to repeat them, but one of the general impressions you get from them is that games are effective in teaching how to play them because (at least good games) put all the information into a relevant context, and they allow us to safely explore options and make choices, as well as form opinions. And when playing games, the best performance can only be achieved by understanding how the game works, and by forming connections between facts.

So what about Koster's claim, games are fun because we learn when we play? From the above we can definitely conclude that we are learning, and actually really efficiently, while playing games. From experience or just statistics we can conclude that games are indeed most likely fun. Not always easy fun, but there has to be something going on, because games are so popular. Games are not just passive entertainment. Playing a good game and improving in it gives a sense of achievement, which is also the high point of learning. Not convinced? Well, you just have to read through both of these books and decide for yourself.

So bottom line? Teachers and usability researchers should take a good like at game design. This is one of the central things I'm going to explore in my studies. Finding that Holy Grail, I'll probably leave to others.