Feb 11 2014
Developing User Interfaces
Building user interfaces for games is an art form. Unlike building user interfaces in a business environment where you're looking at getting the job done as cleanly and efficiently as possible, with games, you want to get the job done in as fun a way as possible while retaining player interest and without being too frustrating. So for games, we're frequently making UI decisions that are specifically against efficiency. As an example, if we have a game UI that simulates a roulette wheel, then an efficient UI would just start to spin the wheel once you've placed your bet and, without further interaction, tell you what you've won or lost. A more entertaining simulation however, would not only have you place your bet, it would also have you start the wheel spinning and then start the ball moving. Once it has played an animation of the ball bouncing around the wheel, you could then click to claim your prize or accept your loss. All of these steps are there because it keeps the player active and engaged in the roulette process.
On the other hand, you can go too far with this sort of thing, too. Imagine a scenario where you wanted to craft a Greater Sword of Monster Bashing, which took five highly refined materials of metal, leather, and gemstones. If making each of the highly refined materials involved collecting 4 refined materials, each of which required collecting 4 ordinary materials, each of which required collecting 4 crude materials... that's 320 materials you need to collect and combine in order to get the sword that you wanted. Along the way, making the materials just becomes tedious without any direct benefit to you, instead of being an engaging process. One of the hardest things to do in game design is to walk that fine line between engaging and tedious. And to anyone trained in the business setting where efficiency is paramount, it all sounds insane.
In NEXUS, we're trying to keep the player engaged through the process of picking all of their cards and arranging them into all of the sets they want to use for scoring. Part of what we do to keep it from simply being tedious is the dynamic changing of scores — the score is updated with every change the player makes. This both gives immediate feedback to the player about what works and what doesn't work, and also keeps the process of picking 36 cards out of the deck from simply being a grind. Clearly, we have a ways to go to increase player engagement; there have been a number of good suggestions such as playing sounds or doing animations when sets are made that would capture player interest. Our trick is going to be choosing among these for which ones we are going to implement. We also want to avoid the problem of too many distractions, or too many repetitive sequences, because we understand that after you've seen a cut-scene the first five times, the sixth time it becomes annoying, the tenth time it becomes really annoying, and the fifteenth time you start making jokes and memes about it.
The UI also isn't just about the clicks, sounds and scenes, it's also about layout and visual balance. You want the buttons to be large enough to be easily used without overwhelming the rest of the play area. The colors need to be easy on the eyes, but not so faded that the players can't find the active areas. Icons should be clear and recognizable, and those without text need to be properly introduced so that players can understand what they mean. Each of these elements needs to be carefully balanced to please and entertain the player, just as much as the interactions mentioned above.
All of these things are still in development for NEXUS; our earliest versions have very little UI work done for them, and in many ways, we expect that the UI will be the last thing we call complete, even though it's one of the things we started on first. The current UI has only a moderate resemblance to the initial storyboards and diagrams we made, and we will be adding and adjusting a great deal more about it throughout the rest of the production process.
