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.

Features in Need of More Use

Another interlude, I know. A lot is going on but there isn't much to write home about at the moment. So I'll take this chance to discuss some great features I'd seen in some applications. This post was mostly inspired by Dia which I've been using to draw diagrams today.

The first feature is snap to grid which is present in Dia. The idea of this feature is not very radical. The editing area has a grid on it. If snap to grid is turned on, whenever objects are moved, their corners and sizes will snap to the grid. So my box for example will be exactly 6 times 4 grid squares, and is strictly lined up with the grid. This makes two things easy: creating boxes with the same size is easy, and lining up multiple boxes is super easy. Oh and drawing straight lines is almost too easy. This feature's relative is snap to object but I don't find it nearly as useful. What it does? If objects are moved close to each other, they are snapped together. Snap to grid on the other hand should be available in every program where objects can be positioned. Every. Program.

Dia also reminded me of another feature I really like: customizable keyboard shortcuts. Dia doesn't have those, but all KDE applications do. I don't think there's any limit as to how far this should go. I would consider it optimal if every single action in the application could be given a shortcut. KDE apps don't manage this, but their customization is easy. Pick an action from a list, assign a shortcut. My only gripe with them is that some actions I'd really like to assign a shortcut to are not on that list. The biggest "why?" of all: only 12 tab shortcuts available for browsers. Not quite enough. A lot of heavier programs have macros (but they can't fix everything). But: customizable shortcuts - not that hard to program. So where are they?

While on the topic of customization, how about customizable menus. Much like shortcuts, except instead of assigning actions to keys, they are assigned to user-defined menus. This is actually a feature I haven't seen much in applications and can't really name one. I have seen it in some operating systems. Most notably, my current Nokia phone. The phone itself is horrible. Can't remember the model number, but it's their current low end. It has the worst keypad I've ever used. What it has, is a "go to" menu behind one button on the main screen. It's a menu for collecting shortcuts. I don't need to navigate the stupid menu system to get to the most important things.

Sure enough, these features are mostly what could be called "power user features", especially the customizations. Actually, both of these features are very often available in games. Especially PC games. Which is yet another reason for UI designers to go and play some games. The power of these features is largely understood, so nothing revolutionary here. What I just wanted to say is: use them more! Use them everywhere. They're some of the extra features you actually can't go wrong with.

Introducing STAGE

It's been a while since the last entry. There are things going on, and interesting stuff is about to happen. Results will follow. In the meanwhile, I'd like to talk about STAGE (backronym under discussion). In short, it's a game development club primarily for students in the Oulu region. The ball was set rolling by me and Ari Kangasniemi (Games Research Center, University of Oulu) earlier this Autumn.

The point of STAGE is to offer students interested in any aspect of game development a local community. We don't have that much gamedev studying options in Oulu (next to none at the uni, some at other schools) but apparently we do have lots of students interested in it. Bringing them together is a logical step, one that should have been taken some time ago. Now it's under way. We will provide information about work and study possibilities, self-study resources and a channel of communication for starting projects and getting people to work on them.

For my own research, the club is an important channel to gamedev. It is also a limited possibility to work on some game projects that might support my research, assuming I can make them interesting enough to get people participate in them. But that is definitely in the future. For now, I think the most important aspect is being able to contact other people interested in gamedev. Throw around ideas and, of course, make some games. Stuff I'm really looking forward to are game jams. First our local practice jam, then Global Game Jam next January. I think I'll focus on programming there, unless I come up with some really impressive design and decide to pitch it.

I think that's it for this interlude. Expect updates on STAGE after said jams, and possibly other stuff as well. In the meanwhile, if you are interested, go take a look at our forums (they are in Finnish though).

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.

Goal Forming

The last aspect I'll explore in the flow series of posts is goals. This writing has a companion article I have written for Tiny Universes, which explores how rewarding certain kinds of behavior can change how a game is played entirely, using two games as examples. In general, goal forming is an important aspect of user experience, and on lower level also pure usability. The usability aspect is explained well enough on The Design of Everyday Things (Don Norman) - in short, the user needs to be able to understand what goals can be set when using a given interface, and how to use that interface to achieve those goals.

When discussing achievements a couple of posts back, I mentioned they have more to do with goal forming than anything else. When a player plays a game, her first goals are typically to learn the game, proceed through its levels (or whatever) and finish it. There are of course various sub-goals while playing. Achievements or trophies often come into play afterwards and collecting them is another goal. It can also be argued that good trophies are ones that give the player some clear additional goals, which will increase the longevity of the game and therefore improve its value for money ratio. Case in point, before we had these modern consoles with their trophy or achievement systems, Star Ocean 3 had built-in battle trophies. It took me about 50 hours to finish the game, and then I spent another 250 or more hours collecting trophies (I'm still missing 7 out of 300).

In general, a good trophy challenges the player to play the game differently, introducing more difficulty. In Mirror's Edge there is a trophy that requires you to not shoot a single shot during the game. BioShock rewards the player for playing without resurrection chambers turned on. And of course Star Ocean 3 rewarded so many different and interesting things that it kept me hooked for a long time. Typically the only reward is a reminder in your account that you've gotten the trophy, although some games (like Final Fantasy XIII) hand out some minor gifts like operating system themes for getting trophies. Bad trophies are the kind that just require the player to do some repetitive thing a lot of times. More of the same is not very interesting, but doing the same thing differently can be.

Now, let's exit games for a while. With interfaces, especially in interactive spaces where interfaces can be abundant, it is important to get the users to form the right goals. By this I of course mean we need to assist them in forming goals that are relevant to them, assuming they are using our interfaces at leisure. In a work situation on the other hand we might want to introduce reward schemes that support effective work. Regardless of situation though, it's useful to keep the requirements of flow in mind: the user cannot achieve flow if he cannot set goals. So even before thinking what kinds of goals our interface should support, it needs to support goal forming in general. It can then be useful to do some research on what kinds of goals a prototype inspires in people, and then think how they could be adjusted, if necessary.

When the overall goal of an activity is fixed, the system should aid users in forming sub-goals that help them move towards the overall goal and stay motivated. If the activity can be split into a plethora of short-term goals, progress is easy to measure, and if there is flexibility in task order, users can also select short-term goals that are a good match for their current skills. In general, people split activities into short-term goals all the time when working but it definitely cannot hurt to make systems that support keeping track of these goals, and that can also suggest goals.

Before achievements and trophies entered the life of gamers, people used to make up their own challenges. These were definitely no less interesting, but of course no one was certain whether a challenge would be possible at all until someone completed it. With formal trophies, game developers can design the challenges and ensure that they are indeed possible to reach (although, some of the craziest ones are almost unreachable). So for example, in order to improve my writing, I could use a text editor that has various trophies for using language in special ways, like "use 5 different synonyms for a common word in one article". Of course I can make up all these challenges myself, or search the internet, but if it is in fact built into my interface, they are constantly present and easily available for viewing.

Overall, goal forming is a highly relevant topic for user experience. I have once again just scratched the surface, but already discovered at least two important aspects of it. The first one is to gain an understanding of what goals users can form when using your interface. The second one is guiding users to form goals that are constructive towards the overall goal of a larger activity. If every phase of an activity can has its own short-term goal, the user experience is likely to improve. This is too often not the case when viewing the learning curves of more complex applications.