The days of the PC-only game developer are about as alive as the days of the dinosaurs -- if you're a PC-only game developer these days, the chances are good that you're making casual games, not full-on triple-A shooter or RPG titles. Even RTS games, the genre with devotees that cling doggedly to the "PC is the only viable platform for RTS!" mantra, have transformed with the recent release of Halo Wars by Ensemble.
And that brings us to today's Good UI Principle:
Principle 1: It is far easier and cheaper to develop a multi-platform UI for the console version first and use it as the basis for the PC version than it is to develop the UI for the PC version and back-develop it for the console version.
Principle 2: In the era of multi-platform (and thus multi-input-device) games, UI coding language and algorithms need to be changed from language that uses words like "mouseover" and "rollouts" to "on-actions", "on-exits", and "on-selects."
Let's talk about the first principle, well, first. Over the course of my career I've worked on three titles that were multi-platform with different platform foci: Quake 4, whose pedigree was an incredibly hardcore PC shooter fan base but which would be an Xbox 360 launch title; Marvel: Ultimate Alliance, a superhero comic title with a decided focus on the console version with a PC port; and Raven's currently-in-development project Wolfenstein, in which the console version would be the emphasis but the PC platform would be viewed as no slouchy port.
Quake 4 was a wild UI ride in which we learned, like green soldiers on a battlefield, just how different developing UI for a console would be. We naively assumed that we could easily make one UI and simply have switches for the different versions, making any necessary art swaps for things like the buttons of the 360 controller and pushing things out or in on the screen to handle the safe area if we were running on the console instead of the PC. Wow, were we wrong.
It turned out that developing the UI for Quake 4's 360 version would be such a monumentally different task than the PC version that we ended up having to devote one person to the PC UI full-time and one person to the 360 UI full-time, with the latter person being your humble author. There were whole swathes of the 360 UI that needed to be created whole cloth that would never appear in the PC version, such as the Xbox Live matchmaking functionality. We knew we didn't want the PC version to "look too consoley" since the primary audience would be the hardcore fans of the Quake series, so we had to create entirely different art and navigational flow for the 360 version. The result was that we branched the versions at a mid-point in development, and it turned out to be a pretty good solution.
The drawback was that any core game functionality that was added that affected UI had to be duplicated by hand in both UI versions. Additionally, branching the UI had the psychological effect of making us think of them as two separate projects, so we began developing art assets independently until each version's UI was developed in such a way that any section that the two UI might have been able to share if we'd kept them together wouldn't actually look the same anymore.
I look back on our work on Quake 4 with a lot of pride because, with Raven having been a PC-only developer to this point, I felt like we handled our first console title -- a significant launch title, to boot -- really well and amassed an incredible amount of knowledge about cross-platform UI in the process that we could use for future titles.
I tried to apply those lessons to the work I did on Wolfenstein (and just for reference, that title has been in development enough since I've left that my work is probably no longer visible in it, so applying anything from here to the title when it's released is probably not going to translate). This time, I was the only UI designer on the project and wanted to keep the amount of work I'd have to do to maintain cross-platform UIs to a minimum.
One of the first lessons I tried to apply was to get rid of the notion of a "consoley UI" versus a "PC-looking UI." My feeling is that good UI is good design, and good design is universal. Good design transcends these outdated notions we have of UI needing to look a certain way simply because you have a controller in your hand and not a mouse. (How the UI actually functions, on the other hand, will become part of Principle 2 momentarily.) If the UI has good aesthetic design and functions smoothly, the player isn't going to think about whether it looks like a console UI or a PC UI.
The second lesson I learned was that the game's design is directly proportional to how miserable or pleasant the UI designer's job is going to be. (I'm pretty sure there's an equation that can be derived here, but I'll leave that as an exercise for the reader.) What's the limiting reagent in a game design as it relates to the UI? The answer is the input mechanism -- if your primary input mechanism has eight buttons and two thumbsticks, that's all you have to work with, and your game will be designed to fit that. If your primary input mechanism is a mouse and keyboard, you have whole vistas open to you.
So a corollary to our Principle needs to be stated:
In any title being developed simultaneously for multiple platforms, your limiting input reagent must be the input device with the least amount of buttons.
You may want to think of your game being played via a mouse and a keyboard first, maybe because that's your preferred method, or maybe because as a developer you've always worked in the PC medium, but you can't, even if your main SKU is the PC version. Once you do this, the game will be designed to use more buttons and input mechanisms than you'll have on your limiting-reagent input device. And once you've done that, you'll be forced down one of two roads:
1. Spend time and money you don't have to modify your game design so it plays differently on two different platforms.
2. Force the UI to do weird and strange things it's not designed to do to handle the fact that you have more input requirements than you have buttons to support.
The first one is just going to lead to complaints by players that one platform is clearly superior to the other and that you rushed out a cheap, shoddy port to make a quick buck, even if that's not what you did. The second one is going to break a cardinal rule I have in the Good UI Principles list, which is that you can never, ever get good UI design or good game design by forcing the UI design to make up for bad decisions in the game design. Both the UI and the game design will suffer for it. The shorter and sweeter version is this: UI is not a gameplay Band-Aid. (This is where the aforementioned equation comes in.)
The end result of this was that by the time I'd left Raven for something new I'd managed to create a single UI for both PC and console platforms that could switch easily depending on which platform you were running, with few areas that needed special treatment just for a specific platform. But we began running into another issue, one that highlighted the second part of today's Good UI Principle.
We realized that the development language our UI was being coded in was filled with references to mouseovers, mouseouts, escape key presses, and the like. Every time a button in the UI was created we had to do a mental switch to flip between the association of, say, the press of the D-pad down to a mouse rollover on a button. Handling the concept of "going back" was an issue -- does that always equate to hitting Escape, which we had a function for, or can you ever use Escape in a different context? Is the function mapping of the "go back a screen/widget" always one to one between the action and the Escape handler, or can Escape ever be mapped to multiple functions? This was just one example of many we came across.
The language wasn't initially mis-designed, it was simply a product of the lengthy transition that game technology took between PC-only titles and PC-plus-console titles. UI had always been the forgotten child of game development already, often getting pushed to the last moment and handed off to whichever artist and junior programmer was free at the time. It was the only development tech we had.
But even today I see the same mouse-centric language being used in the latest version of Actionscript for use in Flash, and in the GUI tech of non-early-FPS games. It surprises me, since even Flash-based games these days are appearing on console and cellphone platforms. It seems to me that one of the best ways to develop good cross-platform UI with good design that successfully trancends the notion of a platform's aesthetic is to create a UI development tool that removes any association with an actual input device and works in the more higher-level abstract terms of actions, selections, and navigation trees. Once you've put those types of functions into the hands of a UI developer they stop thinking of rollovers and mouseouts and start thinking, "what has to happen visually when we want to select this element?" Not how they're actually selecting this element. And those design decisions can begin to trancend the notion of platform and input device, leading to good, tight, solid UI design that's not only accessible for the player, but infinitely cheaper, easier, and faster for the UI designer to work on.
Okay, I admit that I've only just started these essays and I've already blatantly lied to you. Not only did I not post my first one over the weekend like I promised, I'm also doing a bait and switch on the topic. Instead of talking about the development path between console and PC UI first, there's something that came up in conversation today that I'd rather devote the first entry to, and its position on my list is 2b (because it kind of dovetails into a couple of other points I had made earlier on my list). Here's the tenet:
Giving the player all information at all times is not only not advantageous, but actively damaging to the game experience.
It's a subpoint on my list because it dovetails into a larger point, which is that a UI's job is to present only the information you need when you actually need it, and that information shouldn't crowd your screen at any other time.
Gears of War, both one and two, by Epic Games serve as a fantastic example of this point. In terms of UI the screen has practically nothing on it -- and very frequently has actually nothing on it -- and elements only fade in when you need the information. Even your weapon and ammo information will fade out if you're walking through an area of the world where you won't be experiencing any combat. There's no minimap at all. (And thank God for that -- I'll save my minimap rant for another essay.) The UI for Gears is so minimal that you'd probably forget it even had one, giving you an unfettered view to the actual game and helping to break down that barrier to full immersion that a UI can so often be.
At the other end of the spectrum is the example of a game I once worked on (a past project that will remain anonymous so as to cover my ass) in which the designers and programmers insisted on putting everything you could possibly want to know at all times in the game's HUD, all visible at once. The weapon information was required to be up at all times, along with your secondary weapon information, and a request was even made of me to put five concentric directional indicators around the crosshair icon right in the center of the screen with large timers for the bombs you had to disarm, and these went with the three grenade indicators that were already added despite my protests that rotated around the central crosshair, rendering the entire central area of the screen -- a rather important area in a shooter -- completely unusable when it came to seeing the actual game. There was a minimap chock full of ten or more different icons, one of which even told you which direction a person you could sneak up on was facing so that in case you were around the corner and couldn't actually see them you wouldn't accidentally sneak up on them if they were facing you. (Now tell me, what's the point of a stealth mechanic if you're just going to give the player all of the information they need to bypass the actual stealthing?)
Too. Much. Information.
As a UI designer I frequently encounter heavy resistance when I try to strip a UI down and make it lean and mean and contextually visible, and this is because there's a switch that tends to happen in these game designers when they go from players to designers -- they forget how to look at a game through a player's eyes and instead view it through the eyes of a designer. As designers, they want to give the player all the tools they think the player will need to enjoy playing the game, and they erroneously think that giving them lots of information at all times is helpful when in fact it can create confusion and clutter, rendering the experience far less enjoyable. Who wants to view the game world through a visible area the size of a postage stamp?
The wonderful side effect of going minimal and contextually visible is that when you hide the vast majority of your UI and you show only what the player needs when they need it, you change the level of importance of that information drastically -- what would have been lost in a sea of other UI elements on the screen (or what would have had to be made artificially larger, brighter, and thus more annoying) now becomes the singular focus, the most important thing the player needs to know right now. You automatically draw attention to something without having to do any work to set it apart from ten other pieces of information vying for the player's attention. And after all, which would you rather do: make one item visible on the screen, or have to add multiple layers of attention-grabbing art that takes up space and requires you to have to shuffle the rest of your UI jigsaw pieces just to fit it into your "640 by 480 minus the safe area and oh yeah how's it gonna look on the PC" UI?
You're likely saying to yourself, "it's all well and good to say that Gears did this, but they're a simple shooter." It's a fair point, but while I don't work for Epic and don't have any insight into their UI and game design process, I'm pretty sure that the simplicity of Gears' gameplay is not the reason for the simplicity of its UI -- it's because they made smart decisions about the flow of their gameplay and how many things would be thrown at the player at one time.
Take the lack of a minimap, for example. Minimaps, while very useful and often necessary for some games and genres (I recently had to admit that a minimap has to be in Demigod, the game I'm currently working on, and since we've put it in I've found it invaluable), are sometimes thrown into games, in my opinion, as a lazy design solution. Instead of structuring the gamplay so that the player wouldn't have to be forced to sort out which allies are where and also how much ammo he's got and also who's stealing what on the playfield, a minimap is thrown in as a way to just sort of vomit all of the information onto the screen at once (sorry about that metaphor) and let the player sort it all out.
Instead of a minimap to tell you where your allies are and where your threats are, Gears does two things: it lets you bring up a very, very simple directional indicator with the press of a button that shows you where your fellow Gears are, and it pops up a simple, small Y button with an eye icon that you can press -- only if you choose to -- to drag your camera to the single most important piece of information you need to know right now, which is sometimes a very large and recent threat or a door you need to blow up. Again, they give you an indicator of only the most important thing you need to know right now, and they don't have to do anything special to make it stand out against the noise of a UI because it's the only thing on the screen. The player doesn't need to know more than that because they're going to actually look at the game world for their information, not a UI that's blocking most of it.
And that's really the key: the game world needs to provide the majority of game information, not the UI. The UI is merely a helper for the few things we can't convey via gameplay. When I've tried on past projects to do something so simple as to hide the weapon information when you don't need it I've been told, "but I might need to know how many clips I have left before I get into my next firefight." Apparently you don't need to in Gears, and that wasn't a simple UI decision: observance of the gameplay flow shows that they carefully structure the gameplay so that you're never caught in a situation in which you don't have that information when you need it.
It can be done, and it should be done. We don't play UI, we play games. The more sophisticated our games and our technology to make them gets, the more we can let the game do the talking rather than the UI wall we're forced to construct in the meantime. And until the day a game can be made with no UI, the good UI designer -- and the game designers he or she works with -- should always be thinking, "how can this UI be reduced even further?"
I've spent the last five years of my game industry career making user interfaces for games of many types -- PC games, console games, games that ship on PC and multiple console platforms, first-person shooters, third-person action games, and strategy action games. And I spent the five years prior to that working in areas of game development that touched heavily on the user interface experience -- web design for some of the largest game web sites on the net, marketing materials for games, and more.
I've learned a lot over those many years, and about a year ago I decided it would be kind of cool to keep track of the things I've learned about UI design and the user experience in games in some kind of list. The list has since grown to include about twenty items so far and as long as I work in UI I can only assume that the list will continue to grow. I've taken to calling the list "Good UI Principles" and I've decided it would be a great idea to start expanding on each one of the items in my list in a collection of blog essays because discussion about good UI design is surprisingly hard to find. As to whether or not I'll actually contribute anything to a discussion about good UI design remains to be seen, but hey, what's the harm in trying?
I was about to start off with a disclaimer saying that I don't profess to be a UI expert, but I'm pretty sure that the people I work with would probably call out my repeated arrogance. I do tend to profess that, but it doesn't mean I fully believe it. I don't have a degree in UI or graphic design (my degree, for those that don't know, is in astrophysics); all of my knowledge comes from sheer hands-on experience. And it's precisely because of that that I want to begin these essays -- not because I want to claim to be an expert, but because I'm hoping it'll generate some discussion about good UI design in what appears to be a vacuum from people who are a lot smarter about the topic than I am. (In other words, I'm just doing this so I can steal your smarts with the thin ruse of "sharing knowledge." You see what I did there?)
So over the course of the next few months I plan to choose a topic from my list and devote a blog entry to it. As you can tell from the last dated entry I'm a fairly irregular blog writer these days, so I'm not promising any regularity in updates. But I'd love to hear back from people, and I'd especially love to get additions to the list. So if you keep your own, throw your suggestions into the comments.
There's no importance to the numbering in my list, so I won't necessarily be going in any kind of order. They're simply added as I think of them. And the first one I'd like to expand on is the following (and it happens to be number 11 in my list):
You cannot simply port a PC game's UI over to a console -- it must be redesigned from the ground up. Conversely, if you design UI for a console game from the start, porting a PC version or maintaining a PC version alongside it is much easier.
Since I wan't to devote an entire entry to this and not just cram it in with the intro to my stunning and sure to be award-winning new series, I'll leave this for the next blog entry, which I hope to bring you over the weekend.
I've been designing user interfaces for games for about five years now, and one of the things I decided to do about a year ago was to keep a list of "good UI principles," those things that people in other positions in the game industry often don't understand or realize about game UI development. This week I discovered one, what felt like a very important and revelatory one, and realized that it deserved more than just a two-line blurb in my text document.
For the past few months I've been working on the UI for Demigod (and by the way, we released the first official trailer today) and we reached a point a couple of weeks ago in which the UI needed a complete overhaul. The other leads on the project were worried about how I'd take this because they knew they were essentially telling me, "we're sorry, but you have to completely redo this, it doesn't fit with the game now." After discussing what changes we wanted to make one of the leads asked me worriedly, "are you okay with this? I mean, we're basically redoing everything." And when I said yes, explaining that this always happens in UI because there's a point you reach at which it just sort of...well, happens, he said, "it does? So what are we doing wrong, then?" Speaking in the broad, industry-wide sense of the word we.
Which was such a great question. No one had ever asked me that in game development before, and instead of having the snappy, sarcastic, and cynical comeback that I normally would reserve for questions like this about the often rancorous and mismanaged method by which many games are developed across this entire industry, I realized that the answer is this: nothing. This is actually supposed to happen. I saw at that moment that my answer of, "this always happens" deserved more than a shrug -- it was an identifiable pattern that I felt really nailed how game UI actually develops given a well-run project (which I believe our title to be). The heavens parted, angels descended with trumpets blaring, and a blinding light enveloped me. (I don't know, I guess God's a UI designer. Think about it.)
For most games, the UI should be developed in a set of stages that resembles this: a 0.1 prototyping pure whitebox phase in which you're merely prototyping functionality with raw, early gameplay; a 0.2 prototype phase in which you refine the whitebox and functionality; a 1.0 alpha prototype phase in which you now give the whitebox its art style. At this point you should be about halfway through your game's development phase, and you along with your designers and art lead will be pretty sure that your 1.0 is going to be the UI you ship with after you tweak and polish the art style a bit.
But you would be wrong. At this point your design team is still refining and tweaking gameplay and things are probably not fully settled. In fact, its at this stage where it seems most of the core gameplay is really iterated on and refined (or should be, for a decently-run project). Your whole team will be happily using the 1.0 UI that you created while you happily work on some art tweaks here and there, refine your UI's visual style, add some dialogs that the designers need, maybe add in things like your front-end movie and the like.
This is when UI entropy begins. I brought all of this up to Matt, who was also a game UI designer for a few years, and he was the one who used the term "entropy." UI entropy begins to affect your UI because as design elements change through the normal course of game development and gameplay design iteration they'll change in small enough ways individually that they likely won't cause anyone to say that the UI needs a revision, but they'll gather like a snowball, accruing more and more momentum as they go down the design hill.
And that's when they hit the tipping point, the point that hits two-thirds of the way through the game's development cycle where it's clear to everyone that the 1.0 alpha UI you built just doesn't work for your game anymore. The first few times this happened to me I felt disheartened. The process is always the same -- you're moving along in your own UI world, at this point likely mostly separated from the design team simply because there's no need to involve you much at this stage (I mean, you're just polishing art style at this point, right?), and then you get called into a meeting with the leads on the project, who hand you a sketch out of the blue outlining their new vision for the UI.
It can be debilitating. It feels like they're telling you that the work you did up to this point was for nothing, or that they're dissatisfied with the work you've done and are here to tell you how to do it the right way. But if you can get past all of that (it's hard, I know, I had to do it) you can see how this meeting is about the UI Tipping Point and what it actually means. Everyone to this point has been playtesting what has likely been a mostly solid and unchanging UI; it's given them time to really cement just what doesn't actually work in your HUD, and on the design side they've probably finally figured out what the actual focus is of the game and how the UI doesn't currently reflect it (which is a whole separate game development discussion -- sure, we're all supposed to know what our games set out to do right from the start, but even the best-run project goes through enough changes over its development life to change its focus a bit). So now they're telling you that they really feel that the weapon switching element is too small and made too unimportant over there in the corner of the screen, or that the game is about leveling up and your skill point indicators in the upper right just don't show up well enough, and this big element over here in the corner really needs to be a much smaller element, and these buttons here in the lower right are really important and should be front and center...
And it's okay. That's supposed to happen. The work you did to this point wasn't for naught, it was just another phase of prototyping. And I've found that once you've reached this tipping point, you have some early-phase stylization going on in the art passes you've done that still nag you as being just not quite right, and when you combine these with a completely new pass on the UI taking into account the things that the design team has been able to nail down as most important, wham -- you comp it all up in Photoshop (or Flash, as was the case for me on Space Siege since we used Scaleform) and you can see before you even start scripting it all into the game that it just works. The whole thing gels, the art style and the functionality. You've gone from a UI that might have felt on the surface like it worked by had slowly started nagging you as needing some kind of refinement or change that you couldn't quite pinpoint to a lean, mean, user interfacing machine.
And now you'll spend a few more months working that into the game, hopefully having had your time actually budgeted to handle this tipping point and subsequent redevelopment. Smart leads will learn to budget for this process, and smart UI designers will learn that it's just how UI development seems to work.