Sorry for the rather speedy post a bit ago, I was getting knocked off the network by the folks coming into the room right before the session. :) I was getting ready to start and I realized I had forgotten one thing. Having the files up before the session does seem an important point though. ;)

Thanks to everyone that attended. I was really pleasantly surprised by the turnout. There were also some really good questions after the session. If you would like to see the PPT file and the related Flash files, please download the source here.

The major points of the session focused on one of two topics. The first part of the presentation was focused on what designers can do to optimize Flash Lite 1.1 performance. I used a couple of my old files like Pellet Pop and Aces High plus a maze game I made for the iRiver U10 to demonstrate some of the design techniques:

  • Smoothly animate small elements the eye is focused on and roughly animate (or not at all) large elements. This gives user the perception of smooth moving content without the hit to performance.
  • Use simple animations (scripted or tweened) to cover over processor intensive task. If you need to run a harsh loop over several items, animate a transition and run the the loop as a frame loop rather than a while loop. The example of this was using an explosion animation in Pellet Pop. The trig for digging out each column of a dynamically created terrain that has been exploded is run at one column per frame during each from of the explosion animation. The cumulative effect of the script is applied visually when the animation is finished.
  • Consider whether to use vectors or bitmaps in your application. Scaling and rotation really require vectors, but otherwise you should use bitmaps for the performance benefits.
  • Interaction differences in the devices make all the difference. Target specific devices, or classes of devices with your SWF. Flash does a great job of staying functional anywhere, but with varying screen sizes and pixel density, not to mention interaction patterns, each device is pretty unique. By tying your layout to variables that can easily be changed, it is pretty easy to create a base file then make some documented design changes to target a new device. I showed how by changing two variables, the stage size and one button event handler I was able to make a specific port of my U10 game for my Nokia that is consistent with the Nokia interactions.

From there I moved on to Flash Lite 2.0 to show how much better life is about to get. My original maze game was coded for Flash 6, and with only changing the stage size I was able to run the original game on my phone with only a very slight loss in performance. I also showed how using Flash Lite keeps you from having to implement server solutions for XML and loading JPGs. This ability really makes Flash Lite accessible to people that are purely focused on the client side.

I wrapped up my presentation by talking about how Flash Lite 2.0 is actually moving ahead of the desktop player in certain cases. In Flash Lite 2.0 you can use right to left languages and can support any media type that your phone supports. I showed an example from Adobe on how Flash can composite 3GP video straight into the Flash movie. I desperately wish Flash for the desktop had this capability.