Wednesday, April 29, 2009

MXMLC Ruins FileSizes

While working on Build 45 today I noticed something - that my file size for the project had almost hit 200KB.

That's a lot of KB. And considering a pretty big chunk of the population in the US is still on Dialup, it's an unacceptably large number of KBs. It was taking 2-5 seconds to load on my broadband connection; I shudder to think how many people would scare away from a slower network!

I took a look back through the history of the game, and took a look at how the filesize grew with time.
  • Build 1 was 2KB. This was built in Flash directly, not in the current framework I am using now.
  • Build 2 was 54KB. This was my first setup in my actual dev environment, with all the physics libraries and various plugins I needed. I call this my baseline - this is as small as my code will get. A lot of this - probably 45KB of it - is the Flex Framework.
  • Build 11 was still 54KB.
  • Build 12 was 90KB. You may notice very little difference between build 11 and 12; indeed, the difference is absolutely miniscule in terms of code or assets. The extra 40KB in weight is entirely from debugging statements.
  • Build 26 broke 100KB for the first time (109KB to be precise). It's not surprising either - it's the first build that includes graphics (albeit basic graphics).
  • As I added more and more art assets, the game ballooned to 158KB by Build 38. By this time the game is really starting to look like the final product, and some of the art assets are still in place in the game today.
  • Build 39 took the cake for the largest single asset size jump - hopping from 158KB to 176KB just for the new menu components.
  • Finally, build 44 weighed in at 182KB.
Build 45 was nearing 190KB when I first compiled it early this morning. That's when I noticed it, and started trying to slim it down:
  • I had been lazy and was importing files I didn't need in my source code. By removing these, I slimmed my code down to 169KB - that's 21KB saved just by commenting out a few lines!
  • I turned off debugging - Which got me 30KB back. 139KB!
  • Finally, I turned on compiler optimization, which apparantly swung me right down to 129KB - which is my latest upload to the server, and the version you are playing right now.
I'm OK with having 70KB worth of art. Mentally subtracting that from my total I'm left with that oh-so-familiar 59Kb - right where I started.

After much Googling this evening it turns out that this is the price I pay for using the Flex SDK instead of the proper Flash IDE. The Flex development framework has a bunch of "features" it includes to help develop things in this pure-code environment wheras the proper, paid-version IDE is a bit more on-the-ball with what you actually need. Up until this point I had not seen any good reason for using the Flash IDE - but now I'm wondering if it's worth the 50KB penalty to stick with the Flex SDK and MXMLC. 

I didn't wonder too long, though. The answer is Yes. :) Big bloatware notepads-on-steroids is not what this industry needs! rawr!

There are a few other ways I can reduce filesizes - but to be honest, it's beyond me. I'm not even sure if I can make the suggested changes to this particular project. But let it be known, that there are mythic stories floating about the ether; proclaiming in a dream-like voice that a programmer somewhere... Somewhere far, far away... Has compiled a Flex SDK application in under 10KB.

I guess I have something to dream about at night while comfortably nuzzling my pillow with a smile on my face.

(For comparison; Colin Northway used the Flex SDK to build Fantastic Contraption, and it is 274KB - so I guess I should stop bitching. :) )

Edit: None of the sizes quoted above include audio assets, which are dynamically streamed from the server. For the curious, I have 63KB in sound effects and 2.25MB in music.

1 comment:

  1. Size is the main reason I'm not using Flex. I do use it for debugging/prototype apps (especially where I want to try tuning parameters with sliders) but it's too big when I want to ship something.

    ReplyDelete