Mark Cooke’s G-Mixer

Recently I’ve been working on the iPhone / iPod touch and my first title is nearly complete. I’ll announce it here soon and give some implementation details as well once it is finished.

Speaking generally about the platform, Apple has done an excellent job on the hardware as well as the API. It is easy to work with and the exceedingly low barrier to entry is why we’ve already seen countless applications released for the platform. Below is my list of the pros and cons of working with the device.

Pros:

1. API is powerful, full featured, and well documented.
2. The Instruments tool is very well done. Looking for performance bottlenecks, memory leaks, and analyzing general application behavior is a snap.
3. Easy to test software in the iPhone simulator or directly on the device itself.
4. Popularity has spawned some great open source work. I’m using cocos2d-iphone heavily in particular and have made a code contribution or two to that framework already.
5. It is easy to get a product to market via direct distribution in the App Store.

Cons:

1. Because of the pros listed above, especially #5, competition on the platform is insanely high. Getting an application noticed, regardless of quality, is a challenge. A lot of focus needs to be placed on getting your application noticed once it is released and everyone is fighting for that attention.
2. Price competition has driven the average application price to $0.99. For most applications there is a very low glass ceiling on how much money it makes sense to invest in development. Selling 10,000 copies of an application you build yourself from scratch sounds great – and it is some nice exposure – but lets look at the numbers in a very rough way. At $1 a pop, Apple takes 30% (currently) leaving you with $7,000. Taxes, depending on your income and location, take perhaps another 20% of that. Now we’re at $5,600. For a professional developer working full time in the US with the skills to build an app themself, that’s around a months salary. Spending more than a month on the application then doesn’t make financial sense. But here’s the rub – most apps don’t sell anywhere near 10,000 copies. This severely limits the type of applications most developers can spend their time on.
3. The X-Code IDE is decent but is nowhere near as nice as Microsoft’s Developer Studio. Especially when it comes to debugging.

Based on all of this my opinion on approaching the platform as an independent is the following: start small. Really small. Tiny ideas with focused, well implemented applications that target a specific niche without being too exclusive. Build up expertise and your own code library to start building applications faster and more efficiently.

Release these applications with boot-strapped marketing and PR. Put in the work to get the application’s name out there as much as you can. Track downloads and usage using tools like Pinch Media’s analytics platform. See what sticks. Once one of these small apps gains some traction, build on it. Understand why it is working well and give users more of what they want. Once you have a little cash flow and an understanding of what is working for you in the marketplace take the time to invest in and build something larger.

Finally, don’t rely on the iPhone completely for revenue. If your application is a game, ideally design it to take advantage of the platforms strengths but also work in other contexts. For example, a title that can both work in a browser under Flash as well as the iPhone gives you multiple revenue streams and more exposure. Unfortunately Flash and the iPhone do not share a common API or programming language, so it is a larger development investment, but the additional revenue and exposure opportunities for a small title are worth it in my opinion.

Even though programming in ActionScript 3 in the Flash engine gives you access to a garbage collected language it is still easy to leak resources and kill the performance of your application. I’ve been looking into some issues with an application I’m working on as well as general debugging techniques and wanted to summarize them in a post.

First, the two main resource leaks that have come up for me in game development:

1. Leaking objects in the display list.
2. Leaking event listeners, especially ENTER_FRAME.

Leaking display list objects

This is a straightforward leak that can happen to any DisplayObject you add to a DisplayObjectContainer. Even if the object is off screen, alpha is zero, or if its visible property is set to false the object is still being updated by the Flash runtime. It is using memory and CPU cycles. Make sure you clean up your objects by removing them from the display list when they are not in use.

Here’s a small, simple code snippet for recursively walking a display list. If you suspect a DisplayObjectContainer is leaking objects, you can use this small utility function to count how many display objects exist in all children. If it doesn’t go down at all, you may be leaking objects (of course it depends on the use case of your software).

public function walkList(obj:DisplayObjectContainer):Number
{
var result:Number = 0;
if (obj == null || obj.numChildren == 0)
{
return 0;
}

result += obj.numChildren;

for (var i:int = 0; i < obj.numChildren; i++)
{
result += walkList(obj.getChildAt(i) as DisplayObjectContainer);
}

return result;
}

Leaking event listeners

This can be harder to track down than leaking display objects. Here’s the big thing that may not seem obvious to people at first – removing an object from the display list, even such that there are no more references to it, does not automatically destroy it or any of its event listeners. If you add a listener through addEventListener() you must remove it through removeEventListener().

By far the worst case of this are rogue ENTER_FRAME events that are still executing on objects you think are removed and gone.

I spent some time trying to figure out how best to track these issues down. The AS3 event model allows you to, for most events, insert an event listener in a parent object in the display hierarchy and basically monitor events as they go by. For example, if one of your child objects has a MOUSE_DOUBLECLICK event you can put the same event on your stage with the third parameter to addEventListener() set to true (capture). You can then print out what object the event is actually going to by using Event.currentTarget inside of the stage event listener.

Guess what though? You can’t capture ENTER_FRAME events in that way. You’ll have to recursively walk the display list again looking for objects that have the ENTER_FRAME event registered. If they have no parent reference then they are likely orphaned (again, depends on your software use case).

Or perhaps better yet – don’t use ENTER_FRAME at all for complex Flash software and write a traditional game update loop. That’s what I’ve done in my engine. I now only use ENTER_FRAME for hacking together prototypes.

As an addendum, here are some gotchas regarding AS3 that I learned about in my recent research:

Apparently creating static utility functions, especially math helpers used in tight loops, is significantly worse performance wise than pasting the code into the loop (aka ghetto inlining) even if complex constants would have been precomputed in the helper. Lesson: static lookup is slow.

If you can avoid it, do not call functions on class references that are typed by one of their parent classes. E.g. if you have a variable of type MyObject, try not to reference it through the global root class Object or any other parent class that may exist. This defeats the purpose of object oriented programming in many ways but for your most performance sensitive code the virtual method table lookup destroys performance.