My game development experience is largely limited to a few flash games and proof-of-concepts. I had certainly never built anything this large or ambitious. But I had a Game Design Degree, and an idea of how large and complicated the scope would be, so I was determined to muscle my way through.

After spending a little time playing around with Objective-C and Java, we determined that Flash AS3 was the best way to go. Air 3.1 had just come out, and it was looking like previous performance issues had been fixed. Using AS3 and AIR, we could output to most devices from a single code base, and I already had a strong background in Flash.

I spent weeks pouring over frameworks, performance tests, tutorials, and forums before even touching a single line of code for the game. The number of bookmarks I had saved was getting way over 30. Finally, after all of my research, I had settled on a flash framework called “Flixel.” (http://flixel.org/).

It was easy to use, had a huge community, and well over a dozen open sourced games to pull code from. I had found and completed three full-game tutorials online, and decided it was time to finally start diving into the beast that is Dragons and Unicorns. After about 10 hours of coding, I had a basic file-structure and framework laid out and ready, with a few sprites on the stage for something nice to look at. Everything was going splendidly.

One major drawback to Flixel, however, was the fact that it uses a technique called “Blitting” to render everything to the screen. Blitting is a process by which the framework takes every pixel on the stage, and compiles them into a single cohesive image before outputting it to the screen. It does this for every frame, and can only be routed through the CPU.

This is a problem for mobile devices however, as their CPU’s are generally smaller, and already tasked with running the rest of the processes on the phone. The accepted practice for most mobile apps is to route everything through the GPU.

Because of this, I was constantly researching techniques for optomizing Flixel for devices. Many of the techniques I discovered were untested or largely not applicable to this project, and things were starting to look pretty grim.

However, during the course of my research, I discovered a new framework that used Flash’s built in Stage3D to render 2D through the GPU. It was called “Starling.” (http://gamua.com/starling/). The early performance tests were looking phenomenal. After a lot of hemming and hawing, I decided that the time I lost re-structuring the framework would be made up in the optimization phase. So I sat down one weekend, and rewrote everything I had done up until that point.

That’s not to say Starling is without it’s flaws. It is fairly new to the market, so finding support or examples from its community can be frustrating. And it doesn’t have nearly as much to it as Flixel does. There are quite a few functions I found myself having to write from scratch (such as an update function, or a framework to easily swap out “screens” of data). But as the community around it grows, these issues become less and less problematic.

The moral of this story: No framework is perfect. Find one that fits your individual needs, and stick with it. If something shiny and new comes along, carefully weigh all of the pros and cons of restructuring. There is nothing wrong with putting the new shiny into your back pocket to play with later.

— Justin Collins Lead Developer Dragons and Unicorns