With a new project comes learning a new programming language, Flash.  Or more specifically, the scripting language that drives the Flash runtime, ActionScript.  Before starting up with Thinglefin, I didn’t know the first thing about it, so the last few weeks have been quite the learning adventure.

After the break, this post will get down in the programming weeds, but of general interest may be my first ActionScript app.  While starting to learn a new language, I usually start with a simple Hello World program, then add little things to it to try out bits and pieces of the language.  Since this is Flash, though, my “Hello World” program is a bit, um, flashier.  You have to click a moving target to get it to say “Hello World.”  Try it out: Hello Flash!  (Credit: about 75% of the code in this program came from this online tutorial.) 

(You may need the latest version of Flash Player installed too: get it here.)

To get up to speed, in addition to the online articles and tutorials at the Actionscript.org site,  I primarily relied on the built-in documentation that comes with the FlexBuilder 2 IDE.  (The book I’d ordered online didn’t arrive until I was several days into my studies, so I had to read a lot from the computer screen… oh, my eyes…)  For real-world sample code, I had the perfect source: Jeremy’s excellently named OMG (Online Multiplayer Game) engine, which we are using as the basis for our project.

Now that I’ve been at it for several weeks, I have a pretty good handle on ActionScript, though there are plenty of things I still don’t know.  Both known unknowns and unknown unknowns, I’m sure… 

Things I like:

It’s very easy to work with resources.  ActionScript has built in types for handling things like bitmaps,  sounds and XML.  It’s also amazingly easy to pull in data (documents, raw binaries, whatever) from remote URL’s.  Just hand it the URL and an event will come in telling you when the data has been fetched (or couldn’t be found, or whatever).  These are all things that can be fairly painful to handle in a lower-level language like C++.  In C++, you either have to build up your own libraries or find ones others have written, which can lead to bugs and compatibility problems.

There’s also a pretty nifty event system.  From the documentation, it seems that this is not a unique ActionScript system, but an implementation of this standard.  In any case, it’s new to me.  Lots of built in ActionScript classes use this to communicate, like a button class that sends out a “Click” event when the user clicks it.  It’s also easy to extend for custom use.  We’re already doing that for things like AI and custom input handling.  (There’s one thing about it that’s a bit of a pain, though - setting an object to listen for an event can create a reference that it’s easy to lose track of - see below…)

I find the concept of the Flash “stage” and display list fairly intuitive and easy to work with.  It’s basically a simple scene graph.  It is meshed very nicely with the event system, so that an event targeting an object on the screen passes down the graph and (optionally) back up again, allowing parents to have a shot at handling it.

Things I find weird:

Coming from years of C++ coding, the most glaring syntactic strangeness in ActionScript is how the types of variables (and functions) are declared.  In C++, you put the type before the name of the variable.  For example, to declare an integer variable called “foo” the C++ code is

    int foo;

In ActionScript it’s

   var foo:int;

At this point I only type it out C++ style about 1 in 25 times maybe, but it took a lot of getting used to.  The bass-ackwardsness of ActionScript here is (appropriately) an artifact of backwards compatibility with earlier versions of the language where variables were untyped.  (Typing in general is a bit weird in ActionScript; I’d say it’s generally strongly typed, but some features are exclusively dynamically typed, again apparently holdovers from earlier versions.  The compiler even has two modes, “strict” mode which resolves types at compile-time, and “standard” or “slutty” mode which waits until runtime… very weird!)

Another thing is that there is not really a concept of a “stack” or ”automatic” variable, at least not for complex types.  If you want to use an instance of a class just inside a small function, you have to create the instance with the “new” operator.  Now, in C++, using the “new” operator allocates memory and gives you back a pointer, which you have to keep track of or else suffer the consequences of either a memory leak or the dreaded bad pointer dereference.  The memory allocation can also cause a performance hit in sensitive applications like games.  So it’s been drilled into me to use “new” with extreme caution.

ActionScript, on the other hand, has no pointers.  Object destruction and memory management is handled by reference counting and garbage collecting, completely behind the scenes.  Jeremy informs me that this is how all the hip young languages are doing things these days, and in a lot of ways, it sure is nice to not have to be worrying about that sort of stuff.  On the other hand…

Things I don’t like:

ActionScript is doing a lot of stuff behind the scenes.  A lot of stuff.  It’s great as long as it’s all working, but I have a hard time trusting that it’s all working correctly, the way I want it to.  Even if my code is not managing it directly, it’s helpful to know at least what is happening.  It can help to write more efficient code and for debugging.

The main example of where this has bitten me several times already is the way the event system can interact with the built-in reference counting.  Having an object subscribe to an event can add a reference.  If you don’t unsubscribe, that object is potentially going to hang around due to that reference.  I think the way that the language architects expected this to be used was that the event dispatcher and event listener would be fairly tightly coupled, so that when you wanted to get rid of one, you’d naturally be getting rid of the other, too.  But we have things that break that paradigm.

For example, suppose we have an animated object.  We also have an object that is running an AI behavior for the object.  The behavior subscribes to an “animation done” event from the object in order to know when it has finished its task.  But then, some other event happens in the game that causes the behavior to be aborted.  I  pop it off a behavior stack and think that it’s gone… but then a little while later, an animation finishes, the “animation done” event is fired, and suddenly that aborted behavior is back from the dead, responding to the event and doing god knows what.  It never really left, since the event subscription reference kept it around.

The solution?  Making sure to unsubscribe to the event in cleanup code.  It’s easy to forget to do this, however, and since ActionScript lacks a “finalizer” method, it’s hard just to track when (or whether) an object finally gets deallocated.  Also, it’s possible to subscribe to an event with a “weak” reference that ought not prevent it from being garbage collected.  Annoyingly, though, that’s the third of three default parameters, meaning I have to type out the other two even though I never care about them.  Furthermore it doesn’t seem to always work correctly.

That’s it for my magical mystery tour of ActionScript… if you’ve read this far, I hope you’re a programmer, because otherwise it must have been really boring.  If you are a programmer and have any hot ActionScript tips to share, please, comment away!