Polish is about transformation. Fades and slides and scales and subtle little motions that nobody appreciates, but everything feels off when they’re not there. If we look closely at a hobby project, a solid indie title, and a AAA professional game, we can quickly see (if we’re looking for it) just how much deviation there is in the overall aesthetic created by transformations alone.

Of course, this stuff can be a pain to develop. Anecdote: Fully 60%-65% of the code for See the Light & Word Duelist is UI code. I spent a great deal of time manipulating “widgets.” Mistakes were made. This article is mostly about the mistakes.

Don’t Just Use Linear Interpolation
From an aesthetic standpoint, linear interpolation is limiting, but it’s all a lot of programmers know. Good UIs will at minimum support easing.

What is easing? It provides a sense of ‘acceleration.’ An animation which eases in will start out slow and build up speed quickly. Conversely, an animation which eases out will start out at normal speed and then slow down before reaching its destination. These can be visualized by considering how a car moves - it gradually speeds up before reaching its target speed and gradually slows down before stopping.

You can go crazy with the ways speed changes over the course of an animation - for instance, starting out at normal speed, then speed up in the middle, then returning to normal speed before stopping. For this you may want to look into curve fitting algorithms (bezier, hermite). Multimedia artists have a better understanding of when to use these techniques, but I’m afraid I’m not much help there.

If You’re Creating Your UI in Code, You’re Doing it Wrong.
Do not be fooled by the amount of work a good UI requires even for a small game. It can easily consume you. Just laying out the screen can require an enormous amount of code, and it quickly becomes a cluttered mess. I thought See the Light - a single screen puzzle game - would not require much in the way of UI, and each time I port the game I cringe at just how wrong I was.

Just don’t do it. It’s much better to be able to lay out and specify your UI in a file. This gets rid of a lot of clutter, increases your turn-around time for small changes, and in general requires less work in the long-run. This also paves the way for potentially creating a UI layout tool (or using an already existing one) in the future if you ever want to go down that road.

Consider Specifying Transformations with Data
The current UI system I’m working on allows me to completely define animations via external data. I have a section in my UI file that looks like the following:

Animation anim_name
Slide Widget=button1 StartPos=0,0 EndPos=100,100 Time=1000
Slide Widget=button2 StartPos=100,100 EndPos=0,0 Time=1000

At any point in my code, I can trigger the animation and receive a notification when it finishes. I have some general code that is able to interpret various animations and play them back. I also have a system that allows me to chain together animations one after the other for more complicated effects.

This does wonders for my code. I can play effects without worrying about the details of the effect, and I can quickly tweak animations. Further, if ever I have an artist working with me, they can modify this file themselves instead of relying on me to make code changes for certain effects.

Good Transformations are Hard
There are a lot of moving parts involved in getting a transition to look good. A button might fly in, ease out at the end, shake a little, then snap back into its “real” target position. When it hits its final position, it could shine a little. While this is happening, other buttons might be doing their own things.

There’s a balancing act involved in getting the right amount of detail in an animation; you want things to be visually interesting without being so busy that the player can’t focus.

And I can’t help a whole lot here. Artists are much better at this kind of stuff than I am. Of course, artists have tools like Flash and After Effects which are designed specifically to facilitate rapidly creating animations. If you’re able to use those, that’s awesome (and it’s why Scaleform does so well these days).

Conclusions
I spend an awful lot of my time thinking about how to streamline game development, and solid UI development tactics account for a lot of that time. Every time I start a new project, I realize that the UI is going to be more work than I anticipated originally. It’s a tough game to play, but it can go a long, long way to making the user experience more pleasant.

When doves cry.