One idea I have been messing with lately is using includes (include “actionScriptFile.as”;) on the different frames/states of my project. This way I can keep all my code organized and have my objects on different frames just like I did in AS2.

The code runs when the frame loads and I do not have to look all over the place for code. This is also an alternative to making everything into a class and exporting all your MovieClips to Action Script which screws up your loading screen. I am not advocating this as a total and only solution, just another tool or method of working on the timeline, which I am still very partial to.

My preferred workflwohas me setting up game states - title, game, win, lose, high scores - on labelled frames. i’d put all my code in the first frame and say stuff like

initGame = function():Void
{
gotoAndStop(”game”);
someJunkOnTheStage.doStuff();
}

This does not work in Actionscript 3. Instead, i have to set up my game states in separate movieclips and instantiate them, and then add them to the display list. This is already a lot more work. And what it prevents me from doing is DESIGNING my game. Codeheads are happy just throwing elements at the stage from the library and positioning them in code, but for those of us born with EYEBALLS, we like to actually see how things are going to look before our work is compiled.

If a button is sitting too far to the left, i’d much rather grab it with the mouse and move it over, seeing the result instantly, than to adjust a line of code from myBtn.x = 300 to myBtn.x = 310 (or 320 or 330 or 331.5 or who the Hell knows?)

My current workaround, and i’m not happy about it, is to lay out the game states with comments instead of frame labels. Then i put my game screens into movieclips, and put those movieclips on the stage in a guided layer. This way, everything’s laid out the same way, and i can futz with stuff the way i used to, but am forced to program and use a GameScreenManager class to add and remove the screens and prompts to and from the stage.

So, in a word, “GRR”.

E.g - http://www.richardleggett.co.uk/blog/index.php/2008/02/18/enabling_access_to_timeline_items_in_as3

It’s interesting that I’ve been using AS3 daily for the last year, have coded many apps and games and I haven’t come across this issue. I’m guessing that’s because I rarely use the timeline.

Sounds like the issue is a bit of a nasty one though if it affects you. Why haven’t Adobe issued a patch for player 9? Seems a bit odd, unless the fix isn’t possible without a major overhaul of the code.

Maybe I’m insane but having to wait N frames, hook into the ADDED event, hack a frame-script in with addFrameScript or listen for a RENDER event is definitely not enforcing best practices! Try explaining to a junior developer or one of your designers that they need 18 lines of code to target that clip after a gotoAndStop/Play.

This is a glaring oversight by Adobe, even their own developers say as much - hence the Event.EXIT_FRAME added to player 10.

The example you give in your above reply wouldn’t work in AS2 or AS3. All code is executed *before* the frame moves forward, so even though you code gotoAndStop(2) before setting the button visibility, you don’t hit frame two until all of the code on frame one is executed. So, when setting someBtn.visible to false the button wouldn’t exist and would remain visible when advancing to frame 2. With AS2 this would fail silently, AS3 will throw a run time error - I just tried it to make sure.

function imLoaded(ev:Event):void{
gotoAndStop(2);
someBtn.visible =false;
}

The code advances the playhead to frame 2, now does the button exist? I have not called the btn until the playhead advanced

In AS2 this works fine. It is does not error out, because the button does go invisible. In AS3, this code works fine once the Display Object List updates. My solution above is basically says after a frame event, execute this code, the code on frame one. Maybe I am wrong, but It seems that the display list is updated before code execution in AS2 and reverse in AS3.

I agree with your comments above, that is this probably not the correct way to do this, but it is practical and has worked in the past. The object would not require using code on every frame, maybe in a document class or neatly condensed on frame one.

Thanks all for the interest in the blog and your comments. They are helpful to me as a designer and hopefully others in the same boat.