Game User Interfaces

In my last blog post, I talked about the anatomy of a simple game.  The list should be fairly comprehensive for things that all games have in common.

It was pointed out to me that there, of course, are more nuances to games than just identifying what's IN them.  The user interface (UI) is sort of an important thing if people want to be able to see all that hard work you put in to making a game!

Technically, the user interface is part of the output of any software product, but the user interface is so involved, I figured it would be best to have its own post (after I left it out last time!) - phsaw, users don't need that!

Ok, let's break UI down in to a couple of components.

User Interface Design is the craft of ratios, colors, layout, math, graphs, art, shades, and all that other stuff that artsy people do.  Those people design what the user ends up seeing, where it is, how big it is, to what scale, what perspective, and what the programmer ultimately wants to reconstruct during deployment of the product.  Design is responsible for a coherent interface (similar color schemes for example), ease of navigation, and stuff like this.

Standard UI things would be usage of color themes, using familiar user navigation mechanisms (buttons), common layout themes (close button in the upper right or upper left corner), acceptable colors for things (purple for pause button?), but really this gets even more involved.  Deeper topics would be stuff like evoking mood by shapes and colors, designing intuitive user interfaces without having someone need external help and tutorials... yea all this stuff is behind UI design.

What about UX?  When I first heard about UX, I thought it was some new technology rage and I'd have to get certified and trained in it... apparently UX just means User EXperience.  I'm still going to chalk this up to buzzword-worthy, but it essentially comes down to figuring out if the user enjoys the experience that is your product.

As a programmer, I suppose this "user experience test" doesn't really fall nicely in to one of many other kinds of tests, so sure, why not, let's have it be its own thing.  I mean, how can I really test the design of the product itself from the software level.

Usually, UI and UX can be clumped together for that nasty UI/UX combo acronym.  Basically, how "nice" can a user experience your product without being turned off by it.  Did someone need developer assistance to actually play the product?  If someone is lost trying to use the product, they probably don't want to hear programmer technical jargon on top of them trying to figure out what they are already doing wrong anyways.

As part of Game Design, the UI should be heavily considered and thought out.  Again, as a programmer, when I hear UI, I think, "meh, just put some buttons around and the user will figure it out"... while that may be true, there is some actual science behind this.  Look in to the Golden Ratio and Rule of Thirds if you don't believe me.  Combining math and art/presentation; what a scary idea.

But really, it's a lot of stuff we take for granted and "know about" without really thinking about.  Like for example, we like stuff centered -- but why?  And, centered on what, in relation to what else?  What if all my buttons were different sizes and put in different places even if they did the same thing, but it can be ok because the buttons are on different screens?

Now for the catch, if the "theme" of the product is craziness, can any and all of these rules be thrown out?  Yes.

In fact, I was told in one of my art classes that "if even the smallest thing is off, people will notice and you'll get poor reviews"... as opposed to "however, if everything on the canvas looks intentional, it is lauded for its creativity".  So the short of it, if you screw up, it better be on purpose, otherwise you'll have angry people UX'ing all over your game, then probably with the mad reviews also.

Alright, next post should get back to graphics programming stuff and texture atlases.