Performance, file-size and visual/audio fidelity is something every designer and developer should consider when creating content for the web. I can remember when I first started using flash it was all about doing as many cool and complicated on-screen concoctions as possible, regardless if the frame rate slowed to a crawl. However as I and the platform as a whole has matured I’ve found myself considering and weighing up the above to get the most out of every experience I fashion.
This post looks at a recent project of mine, which at face value appears quite simple, however behind the scenes there were a number of hurdles that needed to be overcome before the finish line.
you can view the final advertisement here (turn the sound on!)
So the basic idea was to have hundreds of coffee beans sitting in the leader-board banner at the top of the screen and an Espresso cup sitting in an MPU banner bottom right. When the user interacts with either banner the beans would begin to fall down, get ground up and coffee would pour into the espresso cup. Once this animation finished the user would be prompted to pick their favorite type of coffee, which would then transition the MPU banner to the users selection. Sounds easy enough right… Well yes… and no. The main problem with this campaign is that it was for McDonalds, they expects the finest visual aesthetics however we have very limited file-size and processing power to play with.
I first concentrated on creating a realistic looking bean. Seeing as the geometry involved is quite simple I decided to go ahead and make a 3d model of half a coffee bean. Then simply used Away3D to load it into flash.
Now rendering one 3D bean is all fine and dandy, however when you get up into the hundreds things start to slow down… like really slow down! can’t wait for the new upcoming low-level 3D API Mole Hill. Anyways for the time being the solution to this is pretty straight forward, all I did was load the model once and then take a Bitmapdata snapshot every 5 degrees when required, then each bean display object simply pulls and displays the relevant Bitmapdata snapshot.
The next challenge was to decide how these beans were going to animate. I wanted to make it as realistic as possible. The obvious choice would be to utilize one of the many as3 physic engines out there. I decided to go with box2d, however ran into problems almost immediately. The first issue was of course performance, as soon as I added more than say 40 to 50 objects everything really started to slow down (and I’m on a pretty fast computer). The second issue was that it was adding about 300kb to the file-size.
So how can I get rid of these performance and file-size issues while still keeping the resulting animation… Simple, get rid of the engine in the final swf. I created a new fla that setup a physic scene and recorded the position and rotation of each bean every frame (see above). This swf ran slow as hell (about 1-2 frames per second) however this didn’t matter as long as all the information was being captured. I then filtered the data, compressed it into a ByteArray and saved it as a data file ready to be embedded in the final swf.
This allowed me to simply embed this data file in the final swf, uncompress the data and animate all the beans without actually publishing with a physics engine. This approach resulted in a saving of 266kbs and a swf that played back easily at the target frame-rate.
Final Leaderboard by itself (should be 728×90 pixels, but i had to scale it down to fit in this post)
I will post a second part to this post covering the MPU.