When I first started working at Bungie Studios, my primary assignment was to undertake a full redesign of the studio's four primary websites and design a new community site from the ground up. In 2000 I was asked to take on the responsibility of designing the user interface for our current project—a Microsoft Xbox game by the name of Halo.

Up until this point, my only experience with game UI had been doing the interface for some really bad interactive games on CD-ROMs to help pay the cost of tuition at the Art Center College of Design. In my naive state of mind I figured that the few months I had at my disposal would probably be adequate to throw something suitable that together.

As one of our designers so eloquently put it, the UI quickly came together much like a person jumping out of an airplane with nothing but a needle, thread, and a bunch of silkworms to assemble a parachute as fast as possible or meet a messy end. You just do it, and do it fast—and do it right the first time.

Requirements

To use the sample file, you will need to install the following software:

Director MX 2004

• Try
• Buy

Sample file:

If a Picture Is Worth 1000 Words, Then an Animation Is Worth, Oh, About 17,470

Halo 2 was a different story altogether. I gave up my position on the Bungie.net web team to take on the UI design full-time. This gave me an opportunity to really explore ideas, create concept work, and test my designs with usability studies. I couldn't have accomplished this feat easily if it hadn't been for Macromedia Director (now by Adobe). In a way, the success of the Halo 2 interface design can be attributed to much of the work I was able to do in Director.

In the workflow of our new game design, there were four main ways I used Director:

• Concepting motion and animation used in the UI
• Trying out various ideas with quick and dirty prototypes
• Doing a proof of concept presentation for the team
• Running a usability test to iron out any remaining issues in user experience

In talking to people from other game studios, I found that some developers actually have some form of Shockwave player ported to run as an Xbox executable, allowing them to create their entire interface in Macromedia Flash or Director. This sounds like an excellent solution for studios where this is a viable option.

Our studio, on the other hand, uses a proprietary tool that we've implemented for many of our games. This tool evolves with each release to accommodate the things we require without having to be burdened with things we don't. Because our tool is specifically tailored to meet the needs of our design, we have to "design backwards" in order to establish what it is we need.

Typically, when a designer comes up with a design for anything—whether it's print, web, or interactive media—he starts off with several ideas and then slowly reins them in, reducing the concepts to a single, final state. From there, the design is fleshed out, each piece is fully realized, and then it is prepared for publishing.

What I mean by "designing backwards" is that I needed to come up with a slick, polished, and fully realized visual design that would serve as a style guide before I actually designed a single screen. This allowed our UI programmer to become familiar with all the things we required our tool to do, so he could make sure that our tool met all our needs.

Although Adobe Photoshop is an excellent way to render the final visual design, it was very difficult to convey all the behaviors, transitions, animations, and ambient movement with a static image. Therefore, for each example of an animation behavior that I required, I created a Director movie and assembled them together. These movies had no scripts or event-based behaviors. The score was very linear.

Adobe After Effects is also an excellent tool for this phase of the design, but I found that I could work much quicker in Director because I could quickly watch each iteration in real time and tweak it or toss it where needed. When I was done, I took advantage of Director's ability to export to Apple QuickTime and save out each animation as a separate sequence that people could scrub back and forth in the QuickTime player to analyze the intricacies of the animation easily.

Try It on for Size

When Thomas Edison was experimenting with various filaments in his process of inventing the light bulb, one of his assistants complained that he had failed 1000 times to come up with a solution. Thomas retorted by saying that they were making progress. They simply discovered 1000 ways how to not to make a light bulb.

One of the predominant philosophies at Bungie Studios is to take chances smartly instead of making safe decisions all the time. If you simply do what everyone else has done, you end up only with a mediocre result. I'm not saying you should abandon a good convention if it makes the interface more usable, but if you are reusing a familiar convention without thinking "is this really the best way of doing this?" then maybe you should ask that question.

In most online games, you find a server, get on it, and figure out a way to get your friends to join you. In Halo 2, we came up with a party system in the UI where you and your friends would gather first and then join a game later. Yes, we heard complaints at first that we were deviating from the standard system, but nowadays most of the complaints I hear about playing online are when other games aren't using the convention we established. Another thing we tried in the UI was an ever-present way of seeing your online status and seeing what your friends are doing at any place in the UI with a single press of the Y button on your controller.

With each success like the party system and the Y menu, of course, you also have your dual-thumbstick virtual keyboards. Your dual whatchama-huh? Well...

You see, one idea we had was that if a beginning typist can input at a certain speed with one finger on a keyboard, couldn't that person type twice as fast with two fingers just pecking away? We thought that maybe instead of letting the user input text via a virtual keyboard using a thumbstick and button from their controller, perhaps they could type more efficiently if they had two cursors, each controlled by one of the two thumbsticks on their Xbox controller, essentially giving the user a second finger with which to type.

Of course, building this concept in-game would take quite a bit of time, so it was much more cost-effective to prototype it in Director. It took about two days to create the art and build the prototype to a working stage. It then took another half-day to debug it and get it into a fully functional state.

All of this is fine and dandy, but without being able to send that input to Director using an Xbox controller, it would be very difficult to know if the dual-thumbstick virtual keyboard prototype concept has any merit. At the Microsoft Games User Testing group they had an adapter that allowed me to plug an Xbox controller into a computer's USB port. In addition, there was an internal tool called XID that translated all controller input into keystrokes. With this tool running, a user could wiggle the sticks on his controller and press buttons, which would simulate keystrokes from a standard keyboard.

Once the prototype was finished and the controller was plugged in and running, it didn't take long to realize that the theory behind a virtual keyboard that could receive input from two thumbsticks simultaneously did not translate well in practice. When you have two freely moving cursors controlled independently, they have the ability to cross sides, placing the right cursor on the left of the screen, and vice versa. The amount of thinking involved just to keep the cursors straight offsets the speed and ease of use that traditional virtual keyboards have using just one cursor.

We weren't ready to give up on the concept, however. Because it was easy to try several iterations in Director, we quickly put together a few more ideas before throwing in the towel on the double-thumbstick idea. Without first prototyping in Director, this could have been a costly experiment that involved a lot of time with both a programmer and an artist. But Director allowed us to follow through quickly with the investment of only one designer's time.

This is only one case study. Throughout the course of the production schedule in Halo 2, we were able to test our ideas several times before committing them to the schedule—one of which was our method of changing teams and re-sorting the roster in the lobby. You can see one of these for yourself (see Figure 1); just open the "team change.dir" file in the sample download.

Figure 1. A team change in the lobby

I'm Sold

During the development process, we have weekly meetings to keep all the disciplines abreast of what each team is working on. This allows better collaboration between teams and also helps keep us focused on the entire package. It's also a way of soliciting feedback from others in unrelated workgroups. When we reach particularly large milestones, like the end of the preproduction planning cycle, these presentations get much more detailed and elaborate. It is during these times that the team leads rework their schedules for the next milestone and reevaluate features that could face the chopping block. Thus it becomes imperative that the game features that each team believes in most strongly are presented in such a way that they become as indispensable as possible.

This is where Director really shines.

For our presentation at the end of preproduction, we created an interactive prototype of the Xbox Live experience. Up until now, when groups of people wanted to play Halo, they had to lug a television and a console over to a friend's house and link up on a LAN. As cumbersome as that sounds, Halo parties were a huge phenomenon that we had to try our best to recreate on Xbox Live. We wanted to convey this experience using our new idea that we called the "party system" and create a sort of virtual couch for friends to play each other on. Of course, to present this to the others we had to create the players and the scenario for the presentation.

When I say we created an interactive prototype, I use the term "interactive" as loosely as possible. Essentially it was a fairly canned prototype that accepted only certain keystrokes when the occasion called for it. The score was very linear and the scripts were kept to a minimum. About the only scripting I did was the use of keydown scripts to jump to markers. This manner of production allowed me to take the time to render out and finely polish the transitions and areas that I went to and dispose with any work on areas I didn't. After all, it was pretty much a showpiece that only I would run.

We simulated the dialog by taking voice actors (read: me and a few buddies) and recording our parts in the studio. Our sound engineers postprocessed the remote voices to simulate voice over Xbox Live and cut each piece of dialog into a separate AIFF file for me. Any transitions or effects like motion blur were prerendered in After Effects and then imported as QuickTime movies. This gave the presentation a much more finished look. Check out the final presentation by clicking the link below (broadband connection required).

• View the demo (06:30 min.)

The Idiot Factor

Sometimes, no matter how well you plan, spec, and prepare your plans, there are things that you become so familiar with, that they make sense only to those involved with the product. Unfortunately, it can be difficult to know which aspects of the game interface are going to throw end users for a loop. That's where usability studies come in very handy. Not that we are trying to cater to the lowest common denominator, but if we do come across a feature where we see a trend among test participants in which they are having difficulty discovering or using, then we need to come up with a better plan.

It becomes painfully apparent to me that many console games out there don't take the time to do this. If there is anything I could do to persuade other game UI designers out there to do, at the very least, it would be to take the feature that you feel is most likely to run into usability issues and run a user test on it. Director makes this really easy to do and very much worth the time and effort involved.

In Halo 2, we wanted to make sure that people were able to find their ever-present friends list, create a party, invite people to that party, and then take that party into a game. The prototype we made for the test was about as far from my previously mentioned flashy, canned prototype as you could get. There was neither a lot of polish, nor predefined routes that the user had to take. We made that prototype as accessible and idiot-proof as possible. There were very few transitions, and it was filled with heavy scripting and logical paths.

The feedback we received from the usability tests was indispensable. It allowed us to make the processes as user-friendly as possible. In any kind of interface you design, any time you add more functionality and features to it, you inherently make the UI more complex because the end user necessarily has more choices to make. Such was the case with the difference between Halo and Halo 2. Thanks to the freedom to explore, refine, and evaluate what we gained through our Director prototypes, however, I believe we made the experience as worthwhile as possible.

About the author