This is part two of the series. You may want to check out part 1 first.

User Interface Design

Praise be Web 2.0! The term “Web 2.0″ is pretty loaded and that’s because it incorporates a lot of ideas. One of the core tenets of Web 2.0 is a revolution in user interfaces. The visual aesthetic of Web 2.0 is simple intelligent user interfaces that focus on ease of use over power of expression. The impact has been felt everywhere, both on and off the web. It’s not difficult to see how much of an impact “Web 2.0″ has had on modern operating system and software design either. Every new application release looks suspiciously more and more like the Web we’ve all gotten used to.

In our games this user interface design shift means that a lot of the times our game is going to resonate more with the player if the user interface stays out of his way. A loud clumsy user interface is going to constantly remind our player that they are simply playing a game. A simpler, intelligent user interface is going to go along way towards making a more enjoyable gaming experience.

Case 1: Battalion

One of the first games I released was a turn-based multiplayer Flash game. It was just meant to be a prototype, so I made dozens of mistakes along the way and never really had the experience or time to fix them while I was still actively developing the game. Among the plethora of tragic mistakes I made, one players constantly whined about was the chat box that would always get in their way. I thought I was helping players by having more real estate dedicated to the game, and then just overlaying the chat box on the game and letting the users move it around. I delegated the placement to the user, and the result is not pretty:

In most Battalion games, there are areas of the map that are not really used much by the player. I didn’t even need to dedicate space to the chat box, if I was just smart about making sure the chat stayed out of the way of the player. Eventually I got it usable enough that players stopped complaining. The reality is that I didn’t spend the time to make the right choice and the game was more frustrating than it should have been as a result.

Case 2: Matchmaking

I don’t know if you’ve had the pleasure of trying to coordinate an internet game of Counter-Strike with a friend. It starts with a huge list of possible pubic servers, each with their own custom rules, maps, pings, team sizes and all sorts of other options. If you find one you like, then hopefully you and your buddy can join before the empty slots fill up. I know that after awhile, I stopped trying to organize games of Counter-Strike over the internet, because it was easier just to lug all our computers over to a buddy’s house and set it up over a lan.

Contrast that to the party matchmaking that’s available in Bungie’s Halo 3. You fire up the game and within a few button presses, you have formed a party with your buddy and you are automatically matchmaking with other players looking for similar games. When the matchmaking service has found a suitable game for you to join, it gives you the option to veto the game map and mode. If the other players in the game agree, then a new one is picked. The matchmaking system doesn’t try to let you filter by map type or anything like that. It just asks you what type of game you’d like to play and gets you playing one with other people as soon as possible.

User Interface Trumps

I’m not sure there are any situations where a more complicated user interface is going to be better than a simpler one. Even in the most complex in-depth simulator we can think of, we still want to make sure that the user interface is as simple as possible for the player and make the smart choices so that the user isn’t forced to.

Follow Ups

Last up in the series is how we can apply this principle to API design to make libraries that are easier to use (and reuse).