During my winter break, I decided to embark on a glorious path into Adobe Flash-land. I have been coding my flash game for about a month and have been having a blast with the Actionscript 3.0 programming language.

As a programmer who has been developing in C++, I must say that I really enjoy using such a modern, dynamic language (although any languages besides C++ probably seems more “modern” than C++). It is great being able to develop a game that can be played on any browser that has Flash. And since Flash has been ported to such operating systems as Windows, Mac OSX and several Linux flavors, it is definitely a great way to tap into the PC gamer demographic. And if that isn’t enough, Adobe has also released a package that allows developers to bundle their games as native apps on the iPhone! What a great way to reach the masses.

From the C++ perspective, not having to worry about pointers and garbage collection is a godsend. Actionscript already provides a robust engine in which you can build upon. And they even natively support a basic Sprite class which you can derive your sprites from.

Moreover, Adobe Flash does all its rotations, scaling and skewing with matrices. Adobe provides you with the ability to upload you own matrices to high-jack the current matrix stack if you really desired.

But what you gain in using such a high-level dynamic programming language, you lose in low-level flexibility and functionality. For example, all objects in Actionscript (beyond the primitives int, bool, etc) exists as references (or pointers). The object doesn’t delete until all references to the object are removed. Under the hood, what is going on is that they are using reference counting (shared pointers) and mark sweeping to collect garbage. What that means is that the CPU has to run extra cycles to search for these unreferenced objects in order to free them from memory.

But most programmers do not want to keep track of pointers, hash tables and all that other tedious tasks that come with lower-level game-engine programming; they want to code games!  And since most 2D Flash games out there aren’t usually computationally heavy, most developers would gladly give a few cycles to gain great functionality.

flixel

After reading so much about the flixel framework, I decided to use it in helping me embark on my new Actionscript adventure. The flixel framework is essentially a wrapper around certain Actionscript features and also provides a lot of great functionality like collision detection & resolution, game states, tile maps and other cool effects.  All seemed well and dandy, like strawberry candy.

But after using flixel for a while, I started to notice a few things that I did not particularly liked about the engine. For one thing, the engine does not have a garbage collection system for the sprites. What flixel does is when you call the kill() function to kill the sprite, it only sets certain flags on which will prevent the sprite from being updated/rendered. That means that the reference is still stored in their array which means memory is being used on an object that should be freed! And given that all of your characters and bullets are sprites, you can see it how the memory can be eaten up quite quickly.

All in all, I think flixel is a pretty good engine if you are just learning to walk in Actionscript. But once you get on your feet, I would suggest that you code your own.