When it comes to gui coding I don’t typically find it the most glamorous things to do. Particularly when dealing with games. You are left with writing a lot of boiler plate GUI code that is tightly integrated with your rendering pipeline. And even when I do find gui libraries for games they tend to try to emulate the OS in look and feel. When you want something lightweight and very interactive/animated you typically have to write it and integrate it yourself. If someone knows of a library for games that allows for versatile GUI development please leave a link in the comments :). When left unchecked, GUI code can end up being:
- messy and hard to maintain
- difficult to change
- rigid (basically just “functional” with very minimal style)
The GUI is one of the few remaining “big” items left on Tilt To Live’s to-do list. When imagining the GUI I had all sorts of crazy ideas for animations, transitions, interactions. Despite it being a relatively minor part of the game’s experience I still felt it important to really make it as polished as possible. Why? The GUI is the first thing a new user sees when launching a game (unless you’re Jonathon Blow’s Braid). It’s important to grab the user’s attention as soon as you can to make sure they give your game a fair shake.
Attention! Over Here! Look at Me!
In the mobile market you are fighting for pretty small attention spans. One of the design goals for Tilt To Live is to make it quick to play. Currently it takes one tap to start playing the game. I’m still working on reducing the initial load time. I even contemplated removing the requirement of ‘one tap’ to play, and to just drop the player into the game. When someone selects ‘Tilt To Live’ on the iPhone there’s a large chance they are simply wanting to play a quick game of Tilt To Live. In fact, other games like Spider: The Secret of Bryce Manor do just that and it’s actually quiet welcome. My only reservation is Tilt To Live may expand in the future to multiple game types so the ‘play from launch’ approach isn’t ideal if the desired game mode isn’t known with great certainty.
Either way, trying to get that good first impression on the user is very important. In addition to that, reducing the friction required to play your mobile game could possibly raise the game up beyond “I have nothing better to do” status and overtake other forms of gaming.
Ease-e-does-it
So back to GUI animations. Throughout the game I’ve used a hacked-together curve editing tool I wrote in Blitzmax to produce animations for items spawning, enemies popping up, etc. It works “well enough”, but the barrier to creating a new ‘curve’ was still high and it added to the total filesize of the game and was another asset to add to the app. So I revisited easing functions. I use some throughout the GUI system, but they aren’t very interesting. I started looking into alternatives and ended up with a rather nice solution.
Below is a work in progess video of the new easing functions in action on Tilt To Live’s menu UI:
A couple of years ago, Shawn Hargreaves had a really nice article explaining curve functions and how to use them in the context of GUI transitions using the XNA framework. It was a really nice primer to getting your hands wet with polynomial functions. Fast forward to today, I still have the basic “exponential” and “sigmoid” functions, but they were pretty boring in the scheme of things. Tilt To Live’s aesthetic is kind of cartoony so those functions weren’t very lively.
Having worked with Flash many years ago I knew it’s easing animation capabilities were very sophisticated, but I wanted to have some subset of that flexibility in my code as well, so off to Google I went. The best resource I found was Timothée Groleau’s Easing Function Generator. Not only did it have a nice set of preset easing functions, it generated the code to produce those exact curves! Wow, this was a huge time saver! For anyone that wishes to use these functions as well, the variables used in the function probably require a quick explanation:
- t – the floating point time value from 0 to 1 (inclusive). If you want the position on the curve half way through the transition then you pass ‘0.5’ through t.
- b – the starting position. In a one dimensional setting this is the value you would get if t = 0.
- c – the ‘change’ in position. So if you want to transition from 34 to 56 then c = (56-34) = 13. (more on this later)
- d – duration of the transition. If you want the transition to last, for example, 2 seconds then d= 2.
With that actionscript function generator it’s pretty trivial to implement it in any other language (as in my case, C). Although my GUI transitions aren’t based off of changes in position, but off of start and end positions. So my typical transition function signature looks like Transition(startPosition, endPosition, delta). Below is an example implementation in C:
[c] float EaseOutElastic(float startVal, float endVal, float blend) { float diff = endVal – startVal; float tsquared = blend _ blend; float tcubed = tsquared _ blend; return startVal + diff*(33*tcubed*tsquared – 106*tsquared*tsquared + 126*tcubed – 67*tsquared + 15*blend); } [/c]
The result:
- Much more interesting GUI transitions
- No extra assets as curves are procedural
- Can re-use curves in different types of animations (position, scaling, rotation, etc)
When I’m doing a polish phase on the GUI of a game or animations, sounds, etc I’m often reminded of the tidbit from Kyle Gabler’s Gamasutra article about prototyping: Make it Juicy. Using easing functions to add a bit of bounciness, juiciness, and overall personality to a game can really help make the game feel more alive…feel more…juicy.