Tilt To LiveWhen 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:

  1. messy and hard to maintain
  2. difficult to change
  3. 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.


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:

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);

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.

Tilt To Live

I’ve had this issue in past 2D games all the time. The ability to interpolate 2D rotations for basic animations for anyone that doesn’t understand quaternions becomes a rather laborious task. I’ve done messy if-then statements to try to catch all the cases where rotation hits the ‘360 to 0’ boundary and it’s always ugly and seemed like there had to be a more mathematically correct way to interpolate a circular value.

Well for anyone that sticks with it long enough, they undoubtedly run into quaternions. What are quaternions? I’m not about to explain it in detail, but I like to think of them as a way to express a 3D rotations and not having that annoying gimbal lock problem.

So how do quaternions help our 2D rotation needs? Well if you’re in a situation where you need to interpolate between the shortest path between 2 angles then Quaternions can help. You have a few choices to solve this problem:

  1. Use if-then clauses to try to catch all the cases when you hit a rotational boundary if you are rotating from, for example, 300 degrees to 2 degrees. You would want to rotate all the way through 360 instead of going backwards.
  2. Use quaternions, which are more applicable to 3D rotations, to interpolate between to angles using spherical interpolation (slerp for short).
  3. Use spinors, which are a very similar concept to quaternions, except they are more catered to 2D rotations.

You’ll eventually see that using quaternions is somewhat overdoing it as 2 axises are never used in any calculation in 2D. If you eliminate these 2 axises from the quaternion you end up with a spinor! Thanks to Frank, of Chaotic Box, who helped lead me down that direction for my own iPhone game.

To help test out the concept and make sure it’s working I ended up writing a Blitzmax quickie app using what little I know about quaternions. I’m certainly a bit iffy when it comes to dealing with complex numbers, as I don’t fully grok them as I do normal vector math, but I make do. So if anyone reads this post and sees some sort of logical error in my code, by all means leave a comment and I’ll improve the listing.

So to get started I needed a way to represent a 2D rotation as a spinor. So I created a spinor type with some basic math functions (all of them analogous to how quaternions work):

Type Spinor
Field real:Float
Field complex:Float

Function CreateWithAngle:Spinor(angle:Float)
Local s:Spinor = New Spinor
s.real = Cos(angle)
s.complex = Sin(angle)
Return s
End Function

Function Create:Spinor(realPart:Float, complexpart:Float)
Local s:Spinor = New Spinor
s.complex = complexPart
s.real = realPart
Return s
End Function

Method GetScale:Spinor(t:Float)
Return Spinor.Create(real * t, complex * t)
End Method

Method GetInvert:Spinor()
Local s:Spinor = Spinor.Create(real, -complex)
Return s.GetScale(s.GetLengthSquared())
End Method

Method GetAdd:Spinor(other:Spinor)
Return Spinor.Create(real + other.real, complex + other.complex)
End Method

Method GetLength:Float()
Return Sqr(real * real + complex * complex)
End Method

Method GetLengthSquared:Float()
Return (real * real + complex * complex)
End Method

Method GetMultiply:Spinor(other:Spinor)
Return Spinor.Create(real * other.real – complex * other.complex, real * other.complex + complex * other.real)
End Method

Method GetNormalized:Spinor()
Local length:Float = GetLength()
Return Spinor.Create(real / length, complex / length)
End Method

Method GetAngle:Float()
Return ATan2(complex, real) * 2
End Method

Function Lerp:Spinor(startVal:Spinor, endVal:Spinor, t:Float)
Return startVal.GetScale(1 – t).GetAdd(endVal.GetScale(t)).GetNormalized()
End Function

Function Slerp:Spinor(from:Spinor, dest:Spinor, t:Float)
Local tr:Float
Local tc:Float
Local omega:Float, cosom:Float, sinom:Float, scale0:Float, scale1:Float

‘calc cosine
cosom = from.real * dest.real + from.complex * dest.complex

‘adjust signs
If (cosom < 0) Then cosom = -cosom tc = -dest.complex tr = -dest.real Else tc = dest.complex tr = dest.real End If ' coefficients If (1 - cosom) > 0.001 Then ‘threshold, use linear interp if too close
omega = ACos(cosom)
sinom = Sin(omega)
scale0 = Sin((1 – t) * omega) / sinom
scale1 = Sin(t * omega) / sinom
scale0 = 1 – t
scale1 = t
End If

‘ calc final
Local res:Spinor = Spinor.Create(0, 0)
res.complex = scale0 * from.complex + scale1 * tc
res.real = scale0 * from.real + scale1 * tr
Return res
End Function

End Type

One caveat in the above code is that any angle from 0-360 is mapped to 0-180 in the Spinor. What does this mean? it means if I want to represent the angle 270 I need to divide it by 2, creating the spinor with the angle 135. Now when I call GetAngle() it will return 270. This allows us to smoothly rotate the whole 360 degrees correctly. This is explained here in more detail.

So now I want to spherically interpolate (slerp) between 2 2D angles. Well, if I call Slerp() on the spinor type it’ll do just that, giving me another spinor that sits in between the 2 angles. I’ve read a couple of articles in the past on slerp and how to implement it, but in order to get things done I just used a publically listed code snippet and ported it to blitzmax. That whole article is worth the read and recommended, even if you’re just using 2D.

Now that the concept of spinors is encapsulated in the Spinor type I wanted just a basic convenience function that I can feed 2 angles and get another angle out:

Function Slerp2D:Float(fromAngle:Float, toAngle:Float, t:Float)
Local from:Spinor = Spinor.Create(Cos(fromangle / 2), Sin(fromangle / 2))
Local toSpinor:Spinor = Spinor.Create(Cos(toAngle / 2), Sin(toAngle / 2))
Return Spinor.Slerp(from, toSpinor, t).GetAngle()
End Function
the ‘t’ variable is the time variable from 0 to 1 that determines how far to interpolate between the 2 angles. Giving it a value of 1 means you will get toAngle out, and a value of 0 is equal to fromAngle and anything in-between is just that…in-between.

Now I can call Slerp2D(300, 10, 0.5) And get the correct angle without worrying if I’m interpolating in the right direction :).

Also, I want to point out that the above code was just used in a quick proof of concept app. It’s somewhat sloppy and to be honest, I’m not sure I named the portions of the spinor correctly (real,complex), but it works. For clarity and to save time I didn’t inline the Slerp2D functions or the Spinor type methods, so it generates a lot of garbage. You would need to optimize this to use it in a tight loop somewhere. Any suggestions are welcomed.

As for references, I did some searching and got most of the ‘missing link’ materials I needed to bridge the gap between quaternions and spinors from:


I’ve been using Subversion even as a single developer for several years now. It’s invaluable to me and millions of other developers. If you’re a developer working on any project that lasts more than a couple hours and you aren’t using version control then you are shooting yourself in the foot. As a developer, we’re comfortable with juggling several things in our heads at the same time, it’s a fundamental skill we use everyday when developing software. But when you start to do ‘internal’ version control in your head while developing you are only slowing yourself down and it will ultimately lead to lesser quality code.

Don’t think you’ll need this chunk of code, but you’re not absolutely sure? Did you just rewrite method X but you want to keep the previous iteration around as a reference? And more relevant to me: Are you making a bug fix but are mentally keeping in mind how to revert that fix in case it doesn’t work?

All of those questions are red flags that you aren’t using your version control system (if any) to a meaningful capacity. That last question came up earlier this week when I was wrapping up the first alpha build to start testing with a small group of testers for my iPhone game, Tilt To Live. I wanted to implement a new collision algorithm in the game so the higher difficulty levels would run much more smoothly. Wanting to get this right ‘the first time’ (hahah ya right, another lesson learned) I first mocked the algorithm up in Blitzmax, optimized there and debugged it there. Of course, any debugging done in a different language for a mock up is fixing purely conceptual bugs rather than implementation bugs.

The Wednesday night deadline was quickly approaching and I just finished implementing the new algorithm. I start play testing for 5 minutes. 10 minutes. 15 minutes. 20 minutes, wow the game is performing really well! 25 minutes, CRASH! WHAT?! How can this be?

So I quickly restart the game to see if I can figure out any clues as to why it is happening. 5 minutes in I crash again, but it’s still seemingly random. And the debugger isn’t spitting out any useful information to help pinpoint the bug. Knowing the only code I had introduced was replacing a call to the new algorithm I knew just replacing a single line of code would revert me back to the ‘previous version’ (this should have been red flag #1). I start debugging for hours to try to find the cause of the ‘BAD_ACCESS’ fault that is most likely coming from a null pointer somewhere in the new collision algorithm, that seems to still happen ‘randomly’.

Anyway, hours pass and then the next day I spend a few more hours on it to try to see if I can fix it before I start trying to compile an alpha build. Failure. I simply just need more time to get this fixed without releasing the alpha build with a critical bug (red flag #2).

In the end, I had to revert to the slower n-squared collision algorithm for the alpha build. Using SVN, it was trivial to revert back to the previous version, quickly test it, build, and release. Yet, there is a much better process to avoid this very time-sensitive issue of getting bug fixes into a build without compromising the stability of the build. It’s called branches.

Now, I’m no stranger to branches, as I use them to catalog releases, but to incorporate them into my daily development routine is new and is something I’m going to try to implement to avoid this issue in the future. Jeff Atwood, co-creator of StackOverflow.com,  has a rather good summary of different branching patterns for on-going development. As a single developer I’m going to try to adopt the ‘trunk is sacred’ (Branch per Task) method and try to merge features into it from development branches.

What’s the benefit? Always being able to release something that is relatively stable regardless if you’re in the middle of something or not. And you don’t have to worry about ‘auxiliary’ changes you made leading up the current fix that may also break the build. I’m finding that as I draw closer to a more complete game, I need to be able to release builds on a weekly or bi-weekly basis for testers to play test. Knowing that there is some glaring bug that is a showstopper is a head ache for you and your testers.

I’ve been researching different version control systems outside of SVN to see if there’s something that could make branching and merging more seamless and integrated into my work-flow. I’ve found that distributed control systems such as git, and Bazaar, supposedly make this fast and easy. Although,  I’m not ready to give up subversion yet; mainly because it is working. But I may test those systems out in the future for smaller projects. TortoiseSVN’s merging dialog can be a little more clearer, as it stands now it is rather confusing the first time you use it. I’m currently testing out Versions (Mac Only) since I’m developing mostly on the Mac for the iPhone game, and it seems to be a little more intuitive in branching, but can’t comment on merging yet as I’ve yet to look into it.

And now I’m off to enjoy the rest of my weekend :).

Update: Looks like Versions won’t suit my needs. Neither will Cornerstone. SyncroSVN Client seems to support basic things like switching, merging, and branching while the other more ‘fancy’ looking apps don’t do anything beyond committing/updating/branching. Except that SyncroSVN’s GUI isn’t any easier than the command line for merging/switching. Looks like I’m going to the command line or revert to using Tortoise SVN (on windows) for the time being while these Mac apps sort themselves out and mature a bit…

I’ve settled into my new apartment and job and trying to get a decent schedule for working on my different game projects. For now my iPhone game is my ‘main’ project which I spend Monday through Friday working on in the evenings. Weekends I devote to side projects such as Gunstyle. Trying to make progress is getting increasingly harder as my time has become extremely limited to about 1 maybe 2 hours a night during the week. Trying to debug a complex issue in 1 hour is usually not possible for me. And the constant stopping/starting between 1 hour sessions a day apart really hurts productivity when trying to run down a difficult bug. In the end I’m still making progress at least, though a bit slower than a few months ago.

Cutting the Fat

Since I’ve moved I’ve kind of been borderline obsessed with planning, time management, and scheduling. Just a couple of things I’ve come across over the last few weeks that’s helped me:

  • When planning a development schedule for your ‘free time’ in the evenings, take how many hours you think you have to dedicate to a project and cut it in half, if not more. I’ve found that while there’s a 3-4 hour window of time it for me to do work, 2 of those hours are typically eaten by a) random phone calls from family/friends b) my cat c) misc chores that need to get done d) laziness.
  • Remove garbage from your life and daily routine. Over the past couple of weeks I’ve been very aggressive in stopping habits that simply waste time, or cutting back significantly on a lot of things.
    • TV? Cut. Only time it’s on is in mornings while eating breakfast.
    • RSS feeds? I’ve cut most of the spammy, useless news/time-waster ones. Every couple of days I scan my list and if I find a feed that I’m simply constantly putting aside from reading then I deem it not important enough to follow and it’s cut.
    • Games? Sadly, yes :<. My Xbox 360 currently isn’t even hooked up. On the weekends I play quick games of QuakeLive, DeFraG, Tribes 2, or any other multiplayer game. I choose multiplayer because the investment isn’t long term (like a 40-hour epic single player game) and it’s easy to ‘unplug’ from the game and any commitments to it.
    • THE REST OF THE FUCKING INTERNET. I’m still bad at this, but improving. If AIM is on or I stumble on a somewhat interesting link it becomes a HUGE time sink. When you are working on a project with extremely limited time the internet is your sworn enemy.

So in essence, as an indie developer with a day job I think an argument can be made that your most important asset is your time. Being a one man crew or a small team, you are working under very tight constraints and you constantly have to be on the look out for creating a more efficient production schedule. I have some nights where literally every minute counts because not finishing off a feature that night essentially means another day lost to that feature.

Estimating And Scheduling Times

Another issue I’ve come across lately is when it comes down to actual implementation details and estimating how long a feature will take to implement, I tend to draw a blank. Before, when I was on a less ‘strict’ schedule in college I would just work ‘until it was done’. Now with me working with a little more urgency and trying to put together weekly development plans it’s become an ever increasing problem. From the past couple of months here is what I gathered and hopefully may help someone else:

  • Take a task or feature and determine if it’s something you can do in one sitting. If not, break it even further down unil you think a single item can be done in one sitting/session.
  • I find that I over-estimate my coding abilities A LOT. My main flaw is I greatly under-estimate the time needed for debugging and optimization. I tend to finish the initial implementation of features fairly quickly, but then I spend the next 90% of the time debugging, optimizing, or tweaking it. And since this is usually not in the same session, I have to spend time reading my own code to get back up to speed on where I was prior to leaving it. I now take this into account when planning my weekly goals.

This post is pretty much an obvious ‘duh wtf’, but getting some of it into a list may help a few trying to find things to create that extra 30-minutes or hour so they can get just a tad bit closer to finishing their own game :). Adios.

Graduation is over :). Real world here I come.  Anyway, going to be moving in probably a month or so. In the meantime I’ve got a lot more time to focus on some of my game projects. My main focus is finishing up an iphone game and it’s coming along great! Whenever I play it I end up playing it for a lot longer than needed for testing, so hopefully that’s a good thing :). I’m still iterating on the gameplay and the aesthetics for it using placeholders and crappy programmer art. The current build in still shots looks like a ‘mess’ more or less. Won’t make for good app store screens looking like it is now because it’s too confusing. The very first version was very easy to distinguish the player from enemies because it simply had 3 colors (black, red, white). I may have to use that principle moving forward to help keep the confusion to a minimum.

The game is a tilt-controlled shoot-em up. Except the player cannot shoot directly :). So during the game the player only tilts the iPhone and never touches the screen. Two big wins here:

  1. Intuitive controls
  2. No fingers getting in the way of the screen.

In order to destroy enemies the player must run into power ups. When they hit one it sets off an explosion affecting an area around the power up. The basic one simply kills enemies in the blast radius, while others have more interesting effects.

So here’s a few screenshots of the game from very beginning to the current ‘messy’ build.


The above screen shows the very first prototype. Green boxes were pick ups. People that played it enjoyed it despite the really simplistic look.


The next iteration had some basic placeholder graphics and a static background placeholder image. The gameplay also introduced pre-configured wave shapes for enemies to spawn in. So in addition to random spawning enemies could try to attack in lines, surround you in a circle, etc. It upped the difficulty a bit so some tweaking was needed.


This next iteration was focused on gameplay improvements and additions. I added a new power up (a type of explosion that spread from enemy to enemy), and a combo system along with a few other things. The new power up was added to counter-act the difficult spawning patterns of the enemies and it proved useful. It was almost too useful.


And that brings us to the current build. I redid a lot of the graphics and went for a simple vector-art look. Unfortunately, the overall look tends to be very messy in screenshots and the color scheme is ‘meh’. Though I like the look of the enemies, the explosions (particularly the redone viral spreading explosion) could use some work. The blue enemies are enemies that were hit with a freeze power up. There were a few more power ups added. In general, the game feels more solid but visually feels less focused.

Those that are wondering where I got the placeholder background images from:

I do not intend to use them in the final game as they will be replace by original artwork.

I’ll have more on the game’s features in the coming weeks as things start to finalize.