Gaming Your Way

May contain nuts.

Zap and some Flash CS5/iPhone tips

I hate using such a search engine friendly title to a blog post, we normally bask in the willfully obscure, but as this may actually contain something of interest as opposed to the usual random words I figured it was worth at least trying to vaguely flag it up.

Let's start with a big caveat. I developed Zap using the beta version(s) of Flash CS5, and due to it's very nature it's not the final finished product. That means a couple of things, firstly that the launch version is going to be better than the one I used, the Flash team are really breaking their necks with the iPhone exporter and just doing great work. Secondly as it was beta software things are pretty fluid. I really honestly doubt that there are going to be any major changes so soon to release, but some of these tips may not be valid on release.
One last thing, being on the beta program means being under a NDA. In terms of this post it means I won't be going into technical things, performance or new API's etc. Think of this more as a primer which can hopefully give you a little head start than a sneak peek at what's under the hood.

Ok, the main thing is eeking out as much performance as you can.

* Vectors / Drawing API / Gradients. No, no and no. We're bitmaps all the way baby.
* BlendModes. Think more about burning the effect you want onto the bitmap itself.
* MovieClips. Save them for intros and title screens, avoid them in-game, as you just can't cache them efficiently so you're hitting the slower vector plotter.
* Text. It's slow enough when running in a swf. Time to code yourself a text plotter using bitmaps ( Like Movieclips, for in-game anyway. Top and Tails performance is never really a big issue )
* CacheAsBitmap. He's going to be your new best friend, love him and cherish him, as he'll give you much better performance ( There is a new cache command too, but NDA and all that ).
Some things to keep in mind, setting sprite.visible=false wipes the cache, so when you use sprite.visible=true again you're forcing a re-cache. Altering the alpha property also forces a re-cache ( As does scale etc. All the things I'm sure you're aware of any way ). One thing I didn't know before starting on Zap was that if you holder.removeChild(sprite) the cache is lost too, and that the cache only kicks in when the displayObject is first added to the stage.
In terms of how that hit my workflow, I had to change up and create all my sprites / bitmaps in each classes constructor and add them to the stage hidden off to the side.
When you first launch an app on the iPhone the "boot" picture appears straight away. Make sure that the very first thing you do is have a copy of that same image sitting topmost on your stage. Then you can call all your constructors and create all your display assets hidden under that cover, and when everything is in place you just transition that screen out. It hides any nasty stutters whilst the game makes everything it needs ( Using Zap as an example, the boot pic is our logo with "loading" text displayed on it, with the same image minus the loading text in the game itself, so the change from bootpic to game is pretty seamless ).
* Every pixel counts. Only plot what you need to, abuse the swf background colour as much as you can to save plotting.
* Pooling. Hopefully this is something you're used to doing anyway, but it's really vital when exporting to iPhone. During the constructor stage of my game I created all the pools too. Just using a simple Vector list, or linked lists. Pooling is such a simple thing to do and avoids any more object creation / deletion and stops the garbage collector being a big fat processor hog.
* Music. That loop that doesn't sound too bad on your PC at 32kps sounds really nasty on your iPod, funny what with it being a music player first and foremost. It's not a web game, push that bitrate up.
* scrollRect. I usually use that for animating bobs ( Blitter objects, ie sprites you plot with copyPixels or by adding the Bitmap directly to your stage ), using it to view a window on a sprite sheet to make it look like a sprite is animating, all nice simple stuff. I only had the briefest of tests with it on the iPhone, and I think it could be a texture memory hog, so the best way may be to just copyPixel each frame as you need it ( I've really not tested this to death so this could be complete arse, I was using a really big sprite sheet, so for now take this point with a pinch of salt ).
* Think blitter. Our good friend Rich showed me a blitter engine running on the iPod and it was really impressive. Blitting really is the way to go, just one canvas and plot all your pixels to it. I've just finished our own blitter engine for the up coming "Destroy More Cars" game which will be handy for future iPhone games. I'll post more details about that another time ( I'm tempted to open source it, but I really can't be doing with "This feature doesn't work" feedback. It doesn't ? Write your fucking own then ).
* Petty things. Mark your classes as final where you can, don't divide by two when you can multiply by 0.5, stop events from propagating. All tiny tiny things, but every little helps.
* Remember startDrag ? Sure you do, we all used it back in Flash 5. You're designing for the sexy iPhone now, it's not a mouse interface, let the player drag things around in a sexy way, they'll love you that little bit more for it. Apple have lots and lots of style guide docs, give them a read, it still applies to us even if we're Flash kids.

In terms of workflow, if you use Flex or FlashDevelop then you're not wanting to go back to the IDE in a hurry, it's too much of a shock to the system. I stuck with Flex ( By that I mean coding as3 in it, not mxml, there's still so much confusion about it even now ) and with including the AIR swc got auto-complete goodness on all the new commands. Lovely. Because Zap doesn't use anything really iPhone specific that needs to be on the device to test, I just added a simple test. If it's running via Flex check the keyboard and use that, if it's on the device don't run the keyboard code and revert to just mouse events.
I can't emphasis how much time this saved. You surely know the difference in compile time from Flex / FD compared to the IDE anyway, who wants to go running back to that ? It's not always going to be possible, but where you can make a version that can be tested off the device.
( In saying that, still test often on your device just to ensure that you're getting the performance you expect ).

How I set it up was having an empty fla with the iPhone publish settings in it, which just pulled in my classes. With CS4/5 supporting <embed> you don't have to change a line of your code, just use a different fla for laying out your assets for import. Using an empty fla just feels cleaner to me ( In actual fact I used two, one for testing and one for distribution, as you have to use different certs / profiles for each, more on that below ).

Moving on to Apple related things, brace yourself, this isn't the same as uploading a game to newgrounds. We've all read that getting a game published on the App Store is so easy and pain free, but that's mainly coming from people who are more used to the hell of developing for consoles, not Flash.
You're going to have to pay your $99 or whatever it is to register as a developer with Apple. My advice here is just register as a person rather than a company, it's a lot less hoops to jump through, plus when it comes to the App Store you can use a company name anyway which is searchable.

Next up is getting a cert and provisioning profile so you can test the game on your device. On the Mac that's fairly straight forward, on Windows it's a couple more things to do, our mate Iain touched on it in his blog post about his iPhone game. Come launch time I'm sure the web will be sinking under the weight of tutorials on how to do it.
One thing with the provisioning profile is that you can add devices to it. We couldn't really get access to any non-3GS / 3rd gen devices which restricted our testing, but you really want to be bugging everyone you know with an Apple machine for their device IDs so you can send out builds of your game for testing.

Come the glorious day that your app is ready to submit remember you'll need a distribution profile and cert. Also remember to re-read all the Apple guidelines, you don't want your game knocked back because of a silly mistake. You'll need to supple a link to a support site for the app, so prepare to remember your html skills that you've forgotten ( We just used the zap preview page, added a link to the contact form and job done. We've got a pimping and support page all in one ).
One last submission tip, when setting the release date, set it off in the ( Near ) future. If you leave it as todays date then when the game is passed at least 2/3 days after todays date it will be hidden in the latest releases ( Say you submit your app today, the 26th, and leave that as the release date. The game is accepted on the 28th. Your game will be classed as being launched on the 26th even though no one can actually buy it 'til the 28th, and even then it's got to filter around all the worldwide App Stores. This means all the games released after the 26th will be shown above yours in any latest games list ).
Once the app is approved, dive into itune connect and alter the launch date to tomorrow.

I think that's it. Hopefully I've not said anything I shouldn't have and got myself into trouble. If I have then I'll just lie and say my Mum is ill and start crying, no one will give me a bollocking then. When you do finally get your hands on the brand new Flash CS5 have a good google around for Apple developer forums. Every possible problem you'll ever have with submitting game has already been covered off by other people, the iPhone development community is huge and excellent, imagine our community without all the "I need teh codez lol!" and that's pretty much it.


Comments (11) -

  • charlie

    2/26/2010 2:17:47 PM |

    Very, very useful!

    Now, if only you could post something that would help me clear my backlog of work so I could get on to actually using the information rather than just appreciating it.

    That being said, I'm partly attributing the delay to CS5 losing me a day's work. It may well not have been the CS5 install, but a word to anyone who's coming to this party as late as me - back up everything before you start the install, don't be tempted to see what happens to your current project in cs5 without having done that backup!

  • Squize

    2/26/2010 2:34:50 PM |

    Yeah, never use the beta on a live project mate. The FlashBuilder beta has opened up now, but I'm not risking that on a live game as I'm sure the project format will have changed and it soon becomes more trouble than it's worth.

  • MichaelJW

    2/26/2010 5:20:46 PM |

    Really great tips, Squize, thanks :)

  • Squize

    2/26/2010 6:33:03 PM |

    Thanks mate. We're not really a tip giving blog, but there are lots of things to get your head around when it comes to CS5 / iPhone development, so if I can ease the pain a little then my karma will get a well needed boost.

  • tom

    2/26/2010 6:36:40 PM |

    hey man,
    nice write up, but one thing i find problematic about any kind of CS5 writeup before its launch is people other than Adobe employes are scared of writing anything that acts against their NDA and then they also most times write that its a beta and performance will likely be improved before release and then also give performance tips as if those tips would be required with any tech and its not much different with CS5. In reality, how likely is it that the performance will be improved a lot more before release?
    Not very likely.
    What about writing about what the performance is like compared to any other tech out there, at the end of the day what worth does your article have without that?
    You also don´t write about which apis are supported or not, not even what´s already public knowledge.
    I´ve seen you got one review from the US where someone complains the game doesn´t run on his 3g, what´s up with that?
    Don´t mean to flame you but yeah, i find it annoying when thanks to such posts where people talk about CS5 without mentioning the biggest problems it has Adobe gets away with launching the thing at probably unacceptable performance and with lacking sdk features and api support.

  • Squize

    2/26/2010 7:18:55 PM |

    Hey Tom.

    The post is a primer of what to expect regards getting the performance up as high as possible. With respect to the NDA I didn't want to go down the route of performance benchmarks ( To be honest not only just 'cause of the NDA, but it opens a can of worms. As soon as anyone says "Such and such runs at x fps" then you're just inviting dozens of follow up questions about how quickly other things run, and life's far too short to go down that path ).

    Hopefully I've stayed pretty neutral with what I've written. I've not said it's the best thing ever, or a disappointment ( Neither is true ), but more what to expect when starting to develop for it. People can read into that what they want, it's not my place or wish to either promote or decry CS5's iPhone exporter.

    I'm not writing a review about it, ideally my post will give people a sneak peek of what to expect in terms of having to change the way they work to match the device, and when CS5 is launched they can refer back to the post so they can avoid some of the pitfalls both of us had to stumble through.

    "people other than Adobe employes are scared of writing anything that acts against their NDA"

    Well it's a question of respect mate. I could blow the NDA out and spill my guts about CS5 and perhaps not lose anything in the grand scheme of things, but I respect the NDA ( Like I would a client's ). It's a two way street, Adobe get my feedback and bug reports and get to have some content to promote CS5 with before launch ( Like at the FITC the other day, Zap was shown ), and in return I get to be slightly ahead of the curve.

    "What about writing about what the performance is like compared to any other tech out there"

    Again the post wasn't really about that. To me it's pointless comparing it to say Unity iPhone, when the Unity web player beats Flash hands down in terms of performance, I think most people already realise the same will hold true no matter what the target platform.
    But the same comparisons still apply ( Between web and iPhone middleware ), there's no doubt that Unity is a better game engine than Flash, but Flash has many other strengths, so you target your tech to the game you're making. I wouldn't make a 3D game in Flash for the web, and neither would I do it using Flash on the iPhone. Likewise in terms of development time / costs for a simple 2D game Flash has the advantage [ For me ].

    "You also don´t write about which apis are supported or not, not even what´s already public knowledge. "

    Again, it's not a review of what Flash can and can't do on the iPhone. I honestly don't know what's public knowledge, so rather than put my foot in it and say something I shouldn't, I thought it best to leave those posts to other people ( Who may in many cases be Adobe employees, so don't fall under the same NDA beta testers do ).

    "I´ve seen you got one review from the US where someone complains the game doesn´t run on his 3g, what´s up with that?"

    The game doesn't run at an acceptable speed on some older machines, despite testing it as much as we could on pre-3GS devices. We've flagged that up in the description as the last thing we want is people wasting their money.

    "In reality, how likely is it that the performance will be improved a lot more before release?"

    I'm not in a position to say, as to be honest I don't really know. I do understand that Adobe have a commitment to improve performance after release, which is the same as all middleware providers.

    "Don´t mean to flame you but yeah, i find it annoying when thanks to such posts where people talk about CS5 without mentioning the biggest problems it has Adobe gets away with launching the thing at probably unacceptable performance and with lacking sdk features and api support."

    I'm not taking it as flaming at all mate. Like I've said, it's not a review of CS5, it's to hopefully help fellow devs when they upgrade and start making their own iPhone apps. I got a lot of help on the pre-release forum and this is my attempt to give something back.

    I know I'm a bit out of order, but hopefully that's covered all your points :)

  • tom

    2/26/2010 8:45:19 PM |

    ay, i wrote a lengthy reply but it didn´t get posted =(
    Well, in short:
    Unlike in web projects running on a highend pc its a way bigger deal maker or deal breaker how the thing performs on an iPhone (pre 3gs), so i find it more important people are aware how it performs and also how it performs compared to other tech running on the device.
    I understand you don´t want to write a review though, i´m not sure i like it, but yeah, i understand =)
    And yeah, for those who do buy CS5 your post will likely be helpful to them =)

  • 8bitjeff

    3/1/2010 5:54:26 PM |

    Wow, this is a great post, thanks, Squize. (I've emerged from my cave)

  • Squize

    3/1/2010 9:51:43 PM |

    Glad to see you're back in the daylight mate :)

  • flo

    3/3/2010 2:36:49 AM |


    very nice article. i am really interested in the blitting frameworks you are talking about (yours and rich's). are there any more infos to be found on these?


  • Squize

    3/3/2010 2:41:22 PM |

    Hi flo,

    Thanks for the comment. The post just after this touches on the blitter engine, also 8bit rocket have done loads of great articles about both the theory and practice of blitting ( They've got a book coming out soon which will be packed full of blitting tips, also a full framework I believe, so that could well be worth looking out for ), a link to their blog should be in our blogroll over on the right.

Comments are closed