Breathing Adobe Air
Posted on March 18, 2013 by Steven
While I usually try to adhere to the software development adage, “never build what you can buy”; I am also a believer in the extension, “except when it is core to your business.” On more than one occasion, I have seen a project’s reliance on third-party software hinder development. With this in mind, I set out to develop my own game framework. It was a series of C++ libraries and SDK wrappers that I called “Workshop.” Since Mark and I were on our own, we were happy to build our technology over the course of our first few games – especially since third-party engines didn’t offer enough benefit to offset their cost.
When we joined Execution Labs, things changed a bit. We had tighter deadlines and a few free software licenses. From a business perspective, it made sense to put Workshop on the back-burner and develop our first title in Unity. This allowed us to create a 3D game, which we felt would have more impact on the iPad. We thought 3D would make character customization easier, since we could re-use animations while swapping skins. The downside was that I had no experience with Unity and it had been a couple of years since I last touched C#. I spent a few days evaluating the engine and was pleasantly surprised. The component-based game object system was similar to what I was building and the C# integration meant that I could develop almost as if I was working with native code. Just before the move, I whipped up a quick prototype for the people we’d be meeting on our first day.
As part of Execution Labs, we are introduced to potential mentors and our first day happened to fall on “Mentor Day.” For most of the day, we sat in an office and met with dozens of people to whom we pitched our company and project. While most were positive about the team and the design, many – especially the art mentors – suggested that 3D may not be the way to go and that we should seriously consider a 2D art style for the game (their other suggestions were good too). With this in mind, we later conducted interviews for both 2D and 3D artists.
One thing that those interviews made readily apparent, is that 2D games are easier to assemble with small art teams. 3D artists often specialize in modelling, rigging, or animation and very few regularly do all three themselves. The 2D skill set translates form concept art, though game assets, and all the way to marketing materials. This is not an issue of talent, it’s an issue of expectations and workload. We thought 3D would make things easier, but it seemed the turnaround for 2D would be faster (especially during the prototype phases).
After switching the game to 2D we were also warned that developing a 2D game in Unity would be cumbersome and were encouraged to change. At the same time, Unity proponents were telling us that it was workable with third-party extensions. There was no obvious choice.
In late February, we met Mark Mikulec. He co-founded a company, Antic Entertainment, who authored many of their projects in Adobe Air. My initial reaction was, “isn’t that Flash?” I had previous experience “building games” in Flash and linking Flash user interfaces to native code applications. None of those experiences were pleasant. However, Mark assured me that ActionScript “doesn’t suck anymore” and that my code would resemble a Visual Studio project. Skeptical, but desperate for a way forward, I started prototyping in ActionScript, FlashDevelop and the Starling Framework (check out Adobe’s Gaming SDK).
Given my history with Flash, “surprise” doesn’t go quite far enough to describe how I felt. It went from being something that I would have never considered an option to the technology we would pursue to develop our game.
The truth of the matter is that this game could be built in anything and that I could agonize forever finding a perfect solution. However, having invested so much time in Unity, we needed to make a decision and to make it fast.
We chose Adobe Air for the following reasons:
- The combination of Adobe Air with Starling and FlashDevelop gives us a way to develop iPad apps for free (other than our Apple developer subscription).
- As an added benefit, our game is immediately portable to Android (with automatic screen resolution/aspect ratio compensation).
- Adobe Native Extensions (ANE) allow us to either purchase or develop native code interfaces for social plugins, store interfaces, and analytics solutions.
- Adobe Scout profiler will allow us to more easily identify performance bottlenecks
While I’m still not thrilled with ActionScript as a programming language, I’m happy with the environment and would suggest that devs working on small projects give it a try.
Like Mark said, it doesn’t suck anymore.
- On March 18, 2013