Tuesday, December 21, 2010

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!"

Friday, December 10, 2010

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.

Friday, December 3, 2010

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.