Global Game Jam 2011

Last weekend was made of small amount of sleep and lots of game development. In about thirty hours we designed and implemented a game, Hamsters and Plague. It's a tile-based puzzle game about the survival of hamsters after a plague. You can find information on the game from our project page. I have also started a blog for future development and other related discussion.

Making a game in such a short time is awesome in many ways. Especially learning. I will try to make a proper post mortem on our project when I'm less tired (later this week) and post it to the Hamsters and Plague blog. Naturally it's also important for my research to have actual game development experience. I once again realized how hard it is to evaluate learnability of something made by yourself and our game definitely could do a better job. Which I hope it will do in the future if I have the time to develop it further.

I'm also thinking that something like this would be a really good way to teach programming and team development. A rather tight time limit does wonders to motivation, at least when the topic is one that interests everyone. While school environment doesn't support over-the-weekend courses very well, something similar should be possible. Maybe we could give students credit points for participating in next year's Global Game Jam.

Digging into References

For those among my readers (assuming I have any) who are interested enough in this field to read scientific articles, I'm throwing you a bone. Several bones actually. I've been recently digging into research related to my own as I'm preparing to write my first article and an initial literature review for my thesis.

Aesthetic interaction - a pragmatist's aesthetics of interactive systems (Marianne Graves Petersen, Ole Sejer Iversen, Peter Gall Krogh; 2004). This paper discusses different approaches to aesthetics in the design of interactive systems, analytic aesthetics and pragmatist aesthetics. Furthermore, the authors discuss aesthetic interaction, which is in many ways similar to what I call playful interaction. The authors introduce aesthetics as the fifth element of interaction design (the four others being system, tool, dialogue and media). Artistic interaction goes beyond so called added value.

Ambiguity as a Resource for Design (William Gaver, Jacob Beaver, Steve Benford; 2003). The authors of this article question the HCI convention of designing for one correct interpretation of a system. Instead, they suggest, ambiguity can be used in various ways to enhance user experience. The article points out that if users are left to figure out a system for themselves, they will be more affectionate towards it, and are more likely to accept it as is, and find surprising uses for it. They present three example systems that use ambiguity and three types of ambiguity: of information, of context and of relationship.

Designing Interaction, not Interfaces (Michel Beaudouin-Lafon, 2004). In this article, the author suggests a paradigm shift from designing interfaces to designing interaction. Interaction paradigms and interactions models are introduced. The article delves into the computer-as-tool paradigm. Interaction models are frameworks for guiding designers. Interaction design, in contrast to interface design, means considering the how of interaction more deeply than simply constructing interfaces that are easy to understand and efficient. For example, considering how is tool selection done instead of designing an efficient toolbar.

Heuristics for Designing Enjoyable User Interfaces: Lessons from Computer Games (Thomas W Malone, 1981). The first paper I was able to find that suggests taking influences from computer games in designing user interfaces. It suggests heuristics in three categories: challenge, fantasy and curiosity. These same heuristics have been presented first for instructional activities (also by Malone). Heuristics included under challenge are goal and uncertain outcome. Under fantasy there are emotional appeal and metaphors. Finally under curiosity there are the concepts of optimal level of information complexity and "well-formed" knowledge structures. Overall this paper is a good starting point.

Making by Making Strange: Defamiliarization and the Design of Domestic Technologies (Genevieve Bell, Mark Blythe, Phoebe Sengers; 2005). The authors of this article criticize how we can only improve upon current design unless we defamiliarize ourselves from the subject. To stress their point, the authors present examples of three studies that look at homes and domestic life outside our (western) field of familiarity. They present twelve statements to defamiliarize certain standard HCI design goals. I couldn't agree more - compare this article to some of my earlier blog posts and you'll see what I mean.

Staying Open to Interpretation: Engaging Multiple Meanings in Design and Evaluation (Phoebe Sengers, Bill Gaver; 2006). This article questions one of the core HCI principles: single authoritative interpretation. Already stated in The Design of Everyday Things (Don Norman), the goal is to make the designer's model understandable to the user. The authors here present six different strategies to make designs that are open to interpretation. Examples for each strategy are provided. This paper continues along the same lines as the ambiguity paper above.

So there, some of the papers that will most likely influence my research.

Context-Awareness, Data Collection and Privacy

One huge issue in ubiquitous computing is privacy. Envisioned ubicomp applications are context-aware, i.e. they infer what the use context is from collected data. Smarteverythings know what you are doing and can offer services just when you need them. This is all cool but has some serious potential problems. Namely, how do these smart things know the context? They collect data. A lot of web applications are already doing this, as are loyalty systems in grocery store chains. It's actually quite frightening how much people are willing to share.

There are two issues with data collection: misuse and theft. Misuse encompasses cases where data is used for purposes it was not given for. Theft encompasses cases where data is stolen by a third party. Legal agreements and software security are the means deployed against these issues. Guidelines exist for ethic use of data. However, the consequences of agreed upon use of data can also be highly unpredictable. These definitely do not get advertised.

The point is that ubicomp will require us to give up more and more data so that context-aware applications can make our lives better. I will now proceed to argue against heavy data collection for a bit and provide my ideas of how to achieve context-awareness without massive amounts of sensor (etc.) data.

The focus of interactive spaces has been outlined in this blog before, but I'll summarize it briefly so you can all make guesses of where this argument is going. In our work, we seek to create environments that advertise services to users but ultimate selection and use of services is left to their own judgement. We emphasize intelligent user interaction in lieu of system intelligence. While I do believe some applications need to infer context from data using artificial intelligence, I feel it necessary to point out that more often than not it should be quite enough to simply make it known that a service is available. The user is in charge - our job is to make decision making and interaction effortless.

My view is that a lot of context-awareness problems could be also solved by using highly modular applications. Like in the word processor example earlier the user's actions indicate the context. If the user launches a particular application component, this action alone can tell the system a lot without knowing anything about the user. Take one example, mobile applications launched by touching RFID tags in an interactive space. Without identifying the user in any way, a lot can be said of their location and intention nevertheless simply by the fact that they touched the tag.

This does not necessarily lead to simple applications. With a proper framework, switching between different application components (in this example, touching another tag) should be made effortless. To achieve this, one important aspect is ensuring compatibility between applications. Simple example: I can pick up a magazine from an RFID tag to my mobile phone. When I'm taking a coffee break, I can touch a tag on the table to send the magazine into the table's built-in display for reading (also capable of displaying the book I'm currently reading). The applications are simple, but the system can easily expand. Most importantly, at no point is there any need to identify me as the user, or submit any data about me into the system. Unless my phone is stolen, no one knows what magazines I read.

Of course my example is quite ideal. Free magazine, so no payment issues (which are always more complicated). In many applications there will be need to identify users. But the point is to always consider if using data could be avoided by intelligent system design. My other, ongoing, point is that automatic does not equal better. Certainly the coffee table in my example could have recognized me as the sitter and immediately present magazines based on my preferences. Personally I consider this kind of creepy.

Technology should provide us with options. We should be able to use those options as anonymously as possible. Just Sayin'

Interaction Conventions - A Local Maximum?

The desktop metaphor was introduced in the Xerox Star in 1981. This year it will be 30 years old. The desktop metaphor lives on. Of course it has evolved during these 30 years, but how much exactly? Not having used the Star, I'm still bound to guess "not much". Following conventions is one fundamental usability principle but if we optimize usability by following the same conventions, effectively iterating over same things again and again, are we bound to reach a local maximum instead of global (in terms of user experience)?

With desktop software, usability is largely operating with WIMP (Windows, Icons, Menus and Pointers). Generally graphical user interface toolkits always share certain conventions. Following conventions in itself is not a bad thing - after all, familiarity acts as great leverage for learning new things. However, it might become troublesome if the conventions themselves become outdated by new technology. WIMP is not designed to deal with tangible interfaces, voice input or gestures.

This has been noted by HCI researches in at least several papers, most likely more, using different names for things. One fundamental limitation in our current applications is that they are designed for exactly one pointer. Multitouch screens on recent smartphones and PCs are slowly paving the way for multiple pointers, allowing a user to touch several points at once. Tangibles, researched since mid 90's, will move beyond touch screens, allowing virtual objects to be controlled by multiple physical objects. Which is faster: dragging objects on the screen with a mouse or moving multiple physical objects on a flat surface?

Technologies for tangible input have been here for some time. Same can be said of voice input. Gestures are making their way, receiving a huge boost from Microsoft Kinect. Combining these technologies with the traditional keyboard (still king for typing) should result in better interaction overall. I'm not ready to kill the mouse either, it is still pretty good for pointing. Sometimes touch screen can replace it, but I don't think there are too many as effective instruments for certain tasks (especially certain games).

So, point? I don't think that our current conventions are able to adapt to these new technologies. Trying to fit these new possibilities within known conventions is more likely to hindrance improvements in overall user experience. Learning new things cannot be avoided forever. Of course in creating new interaction models it is our responsibility to make them easy to learn. Conventions from the physical world should be useful for us.

Changing the desktop world is probably too late though. That is why I've set my sights to ubicomp, where conventions don't really exist yet. It should also be easier for people to accept learning new ways of doing new things, than it is replacing their comfortable old ways of doing things with new ways. Tear down the wall, let creativity reign!

On Controllers - Is the Keyboard Evil?

In this post I am presenting just some random feelings I have about controllers - mainly gaming controllers. These days it is not uncommon for a game to be released on multiple platforms: PC, PlayStation 3 and Xbox 360. One key difference between the PC and the latter two is the way games are controlled. PC games have been using keyboard and mouse for ages already. Console games have been using gaming pads with varying number of buttons (and later analog thumb sticks).

NES controllers had a whopping four buttons and the iconic digital directional controller (aka D-pad). Back then, console games had relatively simple interaction. These days gaming pads have quite a bit more. The D-pad is still there but its use for movement is diminishing and has been largely replaced by an analog thumb stick which allows more accurate control. Another analog thumb stick has been added to the right hand side. Four digital buttons under the right thumb. One digital and one analog shoulder button on each side (for index and middle fingers). Start and select buttons in the middle. A total of 10 buttons and three directional controllers. Out of these, only the start and select buttons are not within instant reach.

On the other side of the fence, a keyboard has at least 102 keys. By using combinations of shift and alt keys, a plethora of characters can be produced with a keyboard. In gaming it is typical to use just one hand on the keyboard (assuming the game requires a mouse). If I place my hand in the classic WASD position (used by gamers for movement, although I actually use WAXD), I can reach about twenty buttons with my fingers quite easily. A typical mouse has three buttons and a wheel these days. Mouse movement typically controls a cursor, camera movement or looking (in fps games). While the difference is not as dramatic as it was in the NES era, the PC gamer still has a lot more buttons available.

So is the keyboard evil? In terms of learning, I am leaning towards yes. Figuring out what key does what is a huge task as there are many to try (remember, sometimes alt, ctrl and shift combinations do different things!) without a reference. Remembering them is another thing. On a pad it doesn't take that long to try each button to see what it does. With modern games it's not exactly as straightforward, but I'll come to that in a bit. A large amount of possibilities is also not always best for interaction design. A pad is a constrained design space - once you run out of buttons to assign actions to it's time to optimize your control scheme. On a keyboard it might be a bit too easy to just add another key.

On the other hand, PC gamers have high customization options for their control layouts. If one thing is seriously wrong with console game makers, it's this: too few games allow remapping of controls. Even if this would be almost trivial to implement. This is not a problem until we run into button combinations. 8 actions in a modern game is often not enough. On pads, developers are overcoming the problem by assigning actions to button combinations - typically combined presses of shoulder and thumb buttons. What I personally don't understand is putting actions behind combinations of two thumb buttons. Hello, I only have one thumb to press these buttons with. Pressing two buttons with one thumb ranges from okay (buttons that are on the same diagonal direction the thumb points to - for example triangle and circle on the PS3 pad) to anatomically impossible (the buttons are on opposite corners of the pad layout - for example, square and circle on the PS3 pad).

Some games handle large amount of actions on a pad gracefully (recent example: Darksiders). Some games on the other hand clearly do not (recent example: Prototype). I've heard (I don't have a modern PC, so I haven't tried) that a modern problem with multi-platform PC games is that their controls have been poorly implemented. The developers have designed console control first (because they are more restrictive) and then made as direct a port as possible to the PC, resulting in game play that is clearly not optimized for the keyboard + mouse combination. While 20 keys are reachable when using WASD, it's worthwhile to remember that at least two fingers are reserved for movement buttons most of the time. It takes some training to use all 20 reachable keys without fluidly.

So what does this random train of thought have to do with usability? For starters, design for your controller. If it easily affords only ten actions, don't try to put twelve in your application. Combinations of keys are typically bad because they make actions "invisible". This can be overcome with clever modifier design. In the console version of Assassin's Creed, thumb buttons are mapped to body parts with spatial association: top button is for eyes, left for left hand, right for right hand and bottom button for legs. When a modifier button is pressed, the action changes accordingly. If the character is in stealth mode, the actions will be subtle - if he is not, they will be more rash. The button for one hand can make the character push crowds aside gently, or throw them aside while rushing through.

Another way to go is visual feedback: when a modifier is pressed, display what buttons do on the screen. This is especially good for learning your controller and interface combination. Packing too much information into the buttons should be avoided - a lot of people might not realize that the spatial arrangement of symbols on a key on a keyboard indicate which modifier should be pressed along with that key to get a particular symbol. When the controller is relatively small, this kind of visual feedback on the display is feasible. For keyboards it would be way too much information.

Coming back to the keyboard, typing is what it affords best. If your application needs a lot of typing, using a keyboard is a necessity and coming up with a replacement that is as easy to learn and as efficient (chord keyboards are more effective but difficult to learn) might provide a rather interesting challenge. However, when binding other actions than typing to the keyboard, defining a good scheme becomes important. Shortcuts for example feel rather arbitrary in most modern applications (which is why I called for customizable shortcuts earlier) . There aren't even any standards between vendors which is a disaster.

Short version? I guess it's "pads rule!"

Teaching Experiences - Revised

I have now given evaluations for my game programming course, and also finished my part of teaching normal elementary programming. That means I have also received feedback.

As stated earlier, the course was structured to be somewhat game-like. I had prepared one large example and taken snapshots of its development phases. It started out simple, with just drawing a ball on the screen, and expanded slowly towards a complete game. On lectures we followed the progress of this example, with each new concept adding new features to our game. Much like each new ability in a game allows a player to face new kinds of challenges. Each concept was introduced using carefully selected or made lolcats and sometimes simple diagrams. Then I proceeded to explain the concept, using a whiteboard to visualize what I was talking about. Then we looked at the cool things that can be done to our game using that concept. The final step with each topic was to give the students a new feature they should implement to the game.

This was repeated with most topics. Some topics like comments, which are not very cool, I just explained and demonstrated. The pace was set so that during any given hour there would be at least some programming for the students to do. This method of teaching was appreciated in the feedback I got for the course. Feedback in general was positive. The things I should pay more attention to in the future were the order of some concepts, and overall pacing of the course. I could have also documented the example code a bit more. For some reason the students really liked my lolcat-infested lecture slides. I don't know if the slides were very useful, but if they were memorable, there's always a chance they helped in remembering the actual concepts as well.

Like games, the course gave the students their first success early - I had them make something interesting and impressive (yet simple) on the very first lecture. Similarly, the course structure was very gamey. Students were given new "abilities" and then immediately presented a chance to use them. Need to make game objects interact? Here's collision detection to help you! This way they progressively leveled up as game programmers. Course work assignment was also one long project instead of isolated homework exercises. Relatively long anyway, 100 hours was reserved for working with it. Most of the students who passed the course reported less hours though. The work was divided into phases, but I timed them a bit poorly. The first deadline was too late into the course, and the remaining two were both after lectures had finished.

If I get the chance to teach more game development courses, I think I should look for ideas to make them even more game-like. I had one quite good interactive lecture experience while teaching elementary programming. Our topic was designing programs. I chose a fairly simple problem, one that was easy to represent and understand, and then started asking the students how they would make a computer program to solve it, step by step. So instead of telling students how programs are typically designed, I went through the process with them instead. This is something I should do with a future course. Present initial conditions and then work with the students to make something of them.

Hopefully our department sees the value of game programming in teaching programming. My current evidence suggests it can be very helpful in motivating people. I also think teaching is valuable experience towards making applications that are easy and fun to learn.

Learning Game Design - Introduction

Yesterday we had our first game design learning project meeting. The project goal is to learn the basics of game design and put them into practice. It's a project I started for members of STAGE. For me, it's also an important project to get more familiar with game design. I mean sure, I've read some books on game design, and done some designing and even prototyping myself, but getting more practice is key. I don't think I can credibly bring game design concepts into usability design if I haven't designed a lot of games myself.

The plan is to use Ian Schreiber's online course material from last year. The course is called Game Design Concepts, and should take us twenty to thirty weeks. Our study group is something like five people - a suitable size to keep meetings sane. Each of us will do reading and exercises on our own time, and then we will meet weekly to discuss the week's topics and exercises. Once the exercises start to be about actually designing something, we will include play testing into our meeting agendas. The course is about non-digital games, as these are much easier to do solo.

So, I will probably write more about the course, especially about the things I have learned, in the future.