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.