You know how designers are so particular about placing assets just right? Have you seen them zoom in on the stage, select a MovieClip, and start changing it’s position by a few tenths of a pixel this way or that?

How would you like to play a little practical joke and learn some recursive code in the process?

Here’s the idea: write a function that receives a reference to a MovieClip. It takes that MovieClip and runs a for-in-loop on it looking for other MovieClips. If it finds one it passes that MovieClip back to itself – recursion. During the process it bumps all the MovieClips it finds by a few pixels this way or that, randomly.

Place this code anywhere in your friend’s/co-worker’s/victim’s FLA and give it a start by passing a reference to the _root to the recursive function.

All this happens at runtime so all those assets on the stage at authoring time will be pushed around in random directions. Madness will ensue. :-)

Here’s the code:

Here’s what the view of the stage in the Flash authoring tool. Notice that everything is lined up on the grid lines. The gray grid lines are shapes and so are not affected by the bump function.

Here’s the SWF after the MovieClips have been bumped around. You can download the FLA here.

The bump() function receives three arguments: a reference to the MovieClip to move, the max amount to change the _x coordinate – dx – and the max amount to change the _y coordinate – dy.

So if you want to change the amount of movement then change the parameters that are passed. I find that something like 0.5 or so for each works pretty well. Annoyance will vary depending on obviousness and the time it takes to figure out what’s going on. :-)

I take no responsibility if you get fired for playing this practical joke. As a suggestion: don’t place this code in some designer’s FLA and then go on vacation.

Perils of recursion

Recursion can be an extraordinarily powerful tool but you must handle it with care. If you are writing functions that call themselves you need to have one mantra firmly committed to memory:

Save, then publish. Save, then publish. Save, then publish.

Why, you may ask? Because there is no better way to crash a program, or computer, than writing recursive functions or methods that don’t end. That’s the real key. Making sure that you break out of the recursion.

The example here is very straight forward. But others may not be. Take for instance the Lightning class that I wrote. You don’t want to know how many times I entered into an endless loop while testing that code.

You should take at least the same precautions when writing recursive code as you do when installing a new application on your system:

• Save everything that’s open
• Close every application that isn’t needed
• Always save before publishing (your mantra)
• Wear a hazMat suit
• Make sure your life insurance policy is up to date

Okay, those last two may be overkill but you get the idea.

Tomorrow I’ll have a variation on this idea that is just as insidious.