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.