Most developers are well aware that user interface can break a product. Sadly, it doesn't usually "make" a product. Players don't often think, "Wow. This UI is really well-executed!" If the UI is really well-executed, it's most likely that players hardly notice it at all. The trouble happens when the interface gets in the players' way, or is found inadequate. A game can be beautiful and have great features, but if the interface annoys, irritated players tend to simply pick something else to play.

Obviously, user interface has to be taken very seriously during development, which can require quite a significant investment of time and effort. Every feature needs a good interface, but there's a seeming infinity of presentation methods. How should we as developers decide how to build each interface component? There's certainly more than one way to approach the problem, but for Jumpgate Evolution, our team has elected where possible to let the players themselves guide us.

For a game that hasn't been released, such a pronouncement might sound ridiculous, but we're working to accomplish this very goal from three different directions. First of all, we're driven by the need to make the displays and controls very accessible and easy to use. Information must be available where and when the player needs it. Key choices must be practically self-evident. Frustration must be minimized, especially in the first fifteen minutes of play, when the new player is deciding whether the game is interesting or not. To learn how to do this, we test very frequently, in focused sessions lasting about fifteen minutes, using someone who has never seen the game before. We watch everything they do, asking them to tell us what they are thinking about as they do it. This teaches us what they are trying to do, where they are looking, and what they are, astonishingly enough, not seeing. We have found repeatedly that even though the information a player needs may be there, placed in a very obvious way from the designer's point of view, the player still may completely miss it. As UI designers, watching these tests can be brutal, agonizing, even maddening. Our response to the input that comes from the tests, though, is really simple. When the tests show us that things are being missed, we change those things. In this manner, many parts of our user interface are being adjusted every week, as we strive to make sure that needed information is clear and noticeable, and that it ceases to be intrusive when it's not needed. We’ve already gone through three major design iterations as well as scores, possibly even hundreds, of minor adjustments and it's not finished yet. Nearly every day we change some part of the UI again, little by little moving closer to our stringent accessibility goals.

Rapid iteration is one of our major development strategies, and for UI we're aided in this not only by our automated build system, but by the decision a year ago to license Scaleform, which allows nearly all of our UI development to be done using Flash. Instead of spending time building internal tools, which our team then has to get accustomed to, we've been using well-established commercial Flash development software and leveraging the prior knowledge of Flash that members of our engineering and art teams already had. As if this weren't enough benefit, we also have the option of opening some of our interfaces to customization by the many Flash developers who will doubtless be part of the game's eventual community.

While a focus on the experience of the new player drives design of the basic interface, our second big input into interface considerations comes from Jumpgate Classic and its existing player community. Lessons learned from the parent product's implementation help guide many of our decisions, and we also have 6.5 years of suggestions and ideas from the running game to draw upon. Rather than impacting initial gameplay, though, most of this input is influencing our thinking about what we term "advanced play". These are things that aren't often the concern of the new player or initial impressions, but instead are relevant to players who are making use of the real depth of the game. Directives originating from our experience with Jumpgate Classic include a need to have more economic tools and displays as part of the station interface, improved squad (guild) and facilities tools, new combat coordination tools and features to support situational awareness in battles, and inclusion within the game of information that had previously been available only on the game's website. These changes or improvements relative to the older product may be individually motivated by design issues specific to each feature, but all fall squarely within the realm of making functionality more accessible to the player in Jumpgate Evolution.

Finally, there come times when it's very hard to determine the "right way" to do something. Sometimes it just won't matter, but sometimes it's clear that the users are polarized into two or more camps, where the "right way" for one group will frustrate the other. In some of these cases, we as designers are simply taking the easy way out. Instead of dictating how to play our game, we're implementing systems that suit each camp, and allowing the players to decide for themselves which to use. One good example of this was mentioned in a prior article on flight dynamics, in which I described our decision to implement a toggle between two flight modes, letting the players control the "feel" of flying their ships. Another, purely interface related example, is what we've chosen to do with the game's radar display: we had all the signs of a religious war brewing between the supporters of an Elite-style radar and a Freespace-style radar. Each side claimed their style felt most intuitive, and that the other style was difficult to read. Neither side wanted to budge. Rather than possibly alienating some fraction of the game's audience, we've chosen to implement both styles of radar, again with a toggle, so the players are able to choose. Of course, this decision was a tad easier because the Jumpgate Classic code already implements an Elite-style radar, so that instead of two types we're really only implementing one, but that's part of the advantage of leveraging an existing product.

We're also applying the philosophy of "let the players choose" in more general areas of the game's interface. In addition to the obvious customizability granted by using Flash, we're making most portions of the UI summonable and dismissible, adjustable in terms of size and color, and movable. Players will be able to decide what they need to see, when they need to see it, what color they want it, and where they're willing to sacrifice space on the screen. This is not particularly novel in modern online games, but it's a far cry from what interfaces were like when other space games like Elite, Privateer, Freespace, and even Jumpgate Classic were released. Allowing players to personalize the interface is another tactic to minimize potential frustration caused by our decisions as UI designers, and should simultaneously provide a big boost to accessibility. Despite the time and effort that goes into building a user interface, ultimately we want it out of the way, so players can enjoy the game.