ATC Blitz Post Mortem


After a long day of coding UI stuff for SteamBirds, I settled into bed and had a quick game of Flight Control HD with my girlfriend. With Air Traffic Control on my mind as I tried to fall asleep, my thoughts wandered back to some old ATC games I used to play.

One of my favorites was ATC Simulator by Russel B. Davis/AeroStudios. This is a very high quality product and one of the first indie games I bought – it is as close as you can get to the real thing, even including full-on voice support and using actual airplane data.

Couldn’t the realism of ATC Simulator be combined with Flight Control?

I couldn’t sleep for an hour or two. I lay there wondering if I should just bolt out of bed and get my ideas down – but decided I’d just keep laying there, thinking about the ton of gameplay possbilities here. I was really excited.


The idea I settled on was something like a semi-realistic ATC game. Unlike Flight Control, where airplanes turn on a dime, planes would slowly turn to take on the headings you grant them. You’d also tell the aircraft at what speed to fly, and at what altitude (at least, initially). This would be done from a  familiar interface though; here’s what it ended up looking like:

I actually ended up going for a visual style I first used with Dan Cook in the original SteamBirds prototypes: cut-out airplanes, shadows, and cartoon-like forests. I really like it!


I really wanted to get this prototype done and out the door as fast as possible, so I set a goal: complete the game with only 24 hours of total work. For the entire game, not just my portion of the work! It’s like a game jam, but with each person you team up with, your time halves!

So right after waking up I started coding and went straight for around 9 hours. Since this game is mostly about time management with time-sensitive movement, this is the first game I’ve ever made that uses the clock as a gameloop instead of just using “ticks” or logic-loops tied to FPS.

The game actually runs at 60FPS, but the planes only update their positions at 10FPS.  That’s allright, since the planes don’t do a lot of zipping around and it makes the UI feel super responsive. It also helps cut down on the expensive collision/landing checking.

It’s always fun to try something new, and I think this approach was interesting – where items in the game are all synchronizing and updating at different speeds. I spent more time than I’d have liked to on it, but worth it in the end.

After I finished up the bulk of the code and the game was playable, I started asking around on chat rooms to see if there’s any artists that want to clean things up for me. It’s hard to find someone willing to get the job done in around 8 hours or less, but Andrew Sandifer was willing to accept the challenge!

We also got together with DVG Music, who was able to put together an audio track for us within our rediculous time constraints. One of my favorite things about the game is the music!

The Twist Ending

After everything was said and done, I sat back and gazed fondly upon my creation. A good little flash game! It was fun, if rough in places. But I hadn’t quite used up my entire 24 hour allotment. What should I do next?

Port it to Blackberry Playbook, obviously! Other than some initial hurdles and signing problems, it ended up being relatively painless with only minor code updates.

Blackberry ended up sending me a free playbook for the deal, and the game remains otherwise unreleased to this day.


Two lessons learned with this game.

The first lesson was about user experience and the concept of fun.

Being a pilot, and having played a lot of ATC games, I know about procedures – I know how things should look – I know how fast things play out. Here’s a quick fact: All airplanes try to turn 360 degrees in 2 minutes. Sure, each airplane can turn faster than that, but for the sake of ATC sanity there is a “standard” turn that is both safe, relatively fast, and an important bonus: is comfortable for passengers.

The 2 minute turn is a concept that has been in this game for ages – since the very first lines of code.

And it was terrible. It was not fun at all. I hate it when this happens – I mean, there’s realism, and there’s sticking to your artistic guns… But when it doesn’t pan out? That’s really rough.

The second lesson is about the wonderful world of Twips.

This one was a mind-boggling bug, but eventually tracked it down thanks to the FGL Forums and Twitter. As the aircraft slowly creeped across the screen in full-realism mode, I was incrementing the pixel location values by small amounts (this.x += 0.04;, for example). These changes appeared to be rounded-down to zero and the planes weren’t moving at all.