• Looking for something?

Things to Initialize on your AS2 Game/Project

While transitioning to AS3 is a massive must as people have regarded, some developers (mostly new) just want to or is forced to get stuck with AS2. So if you’re working on a AS2 project or lower, here some common things you should consider checking at the start of your project.

Some common but usually neglected things you might not want but your game might have:

  • The everlasting suggestion of “avoid directly referencing _root“.
  • Yellow boxes appear (on buttons/movieclips) when pressing Tab.
  • Cheating by pressing Space when the yellow boxes focus on buttons/movieclips.
  • Cheating by right clicking (shows the context menu, a cheat for some game genres).
  • Cheating/altering game play/screens by pressing forward, back, etc from the context menu.

_root or no _root

_root?

_root ?

As you might have read a dozen or countless times, it is highly recommended to not directly call _root within the project, although using _root is not necessarily wrong. These developers come to use _root as a hack way of referencing an absolute path to their objects. If you are building an independent system, prototypes, does not consider expansion/addons and will never be a part of a larger system then it would be fine to use _root as a hacky way. But if your work is part of a larger system or the like consider having to add in various (most of the time, 3rd party) extensions, plugins, services, APIs (application programming interfaces), SDKs (software development kits), or anything similar in it’s purpose then you’ll be in for some serious headaches. Most notable of these are those that wrap your game within another swf file. You might be able to face serious issues and problems varying from sounds not playing/missing, disposition world objects, localtoGlobal/globaltoLocal miscalculations, undefined object property, sprites (movieclips) not following the expected position and behavior, wrongly positioned custom cursors and a lot more.

// somewhere in the timeline...
_root.mySuperFunction = function(){
  // doing some super things
  return 'my super function worked!';
}
 
// somewhere else in the game...
trace( _root.mySuperFunction() );
// before
  // outputs: my super  function worked!
// after some integration and browser testing...
  // outputs:         (its really has no output)
// nooooo!!! it isn't working now! but it used to work before,
// maybe this thing wrecks my game when I use it!? I didn't do anything else.

Although I won’t be discussing fixes for the issues mentioned above, we can start by doing what is recommended, to not directly reference from the _root. The most starter’s way from first look at the documentations and other sources, is using _lockroot. Basically it could prove to be a good way to fix and keep things the same but for some cases it might not be enough. For more assurance and better practice I would recommend referencing _root from a global variable or static variable from a class (most recommended).

Why do I have to use a variable? So what we reference can be dynamic – there are some cases where the _root is not technically the parent most, where it can be a specific game container or something similar, this way you don’t have to shift through using _root and updating all your codes when needed. And the sole reason is for code reusability.

// probably on frame1 before your preloader code
this._lockroot = true; // where this = root actually
this.mySuperFunction = function(){
  // doing some super things
  return 'my super function worked!';
}
// for those who do timeline coding or the like
_global.gameroot = this; // where this = root actually
 
// somewhere else through the game...
trace( _global.gameroot.mySuperFunction() ); // output: my super function worked!
// hoorah! its working well!
// and for those who use classes (highly recommended),
// simply pass it on your main class during instantiation
// to be referenced on a static variable
var maingame = new MainGame( this ); // where this = root actually
 
// on your MainGame class or the like
class MainGame{
  public static var GameRoot:MovieClip;
  // constructor
  public function MainGame( root:MovieClip) {
    GameRoot = root; // stores the root mc in static var
  }
}
 
// somewhere else through the game...
// now simply reference from static variable MainGame.GameRoot instead of _root
trace( MainGame.GameRoot.mySuperFunction() );  // output: my super function worked!

Magical Weirdness of Yellow Boxes

Yellow Box

Yellow Box

Some games that incorporate interactive buttons (or movieclips that acts as buttons) are not wary of this feature. Basically flash has the ability to take use of tabbing on GUI, but since we are game developers there are high chances we would not want this as it might look ugly. While most games might not be affected by this feature there are certain circumstances that the game play can be cheated one way or another. Good examples are those games that use mouse interactivity using mouse over and mouse click events, where as the player can cheat things by combining tabbing, pressing space (to select) and the use of mouse. When a yellow box appears over a button its rollOver event is triggered, and when space is pressed its onPress event is, and that is where some cheating may occur on some combinations and timing. It is fairly a simple piece of code you have to declare at the beginning to disable all of the magical yellow boxes.

// probably on frame1 before your preloader code
this.tabEnabled = false; // disable tabs for the whole movieclip
this.tabChildren = false; // disables tabs for the rest movieclip's childrens

Right clicks and Context Menus

Which frame to move?

Which frame to move?

While the context menus from right clicks (control-click for Macs) on flash can’t be removed, we can modify the menus and also strip down unnecessary movie controls like forward, back, play, etc. If your game/project is AS2 powered and is not really well structured (timeline coding and uses gotoAndStop() methods ) then you might encounter glitches and frame skips once the player right clicks and select any movie controls. They could end up skipping levels to scoring indefinitely and would make things less fun and more cheating for them.

If all you want is to simplify the menu:

// probably on frame1 before your preloader code
Stage.showMenu = false;

But if you also would like to customize and add your own menus then:

// probably on frame1 before your preloader code
// instantiate a new contextmenu
var my_cm:ContextMenu = new ContextMenu();
my_cm.hideBuiltInItems(); // hides the built in items, duh
my_cm.customItems.push( new ContextMenuItem("(c) Jayc Santos", gotoJayc) ); // creates a new menu
function gotoJayc(obj, item){ getURL("http://jaycsantos.com/"); }
this.menu = my_cm; // overwrites the default menu and where this = _root (most of the time)

There are also some cases where simply right clicking would create issues for the game play and/or cheat things. A good way to determine is to use the onSelect event. You can also use the onSelect event for more customizations of your context menus (see livedocs sample).

var my_cm:ContextMenu = new ContextMenu();
function menuHandler(obj:Object, menu:ContextMenu) {
  trace( "right click context menu was invoked" );
  // do awesome things
}
my_cm.onSelect = menuHandler;
this.menu = my_cm;

Conclusion

So overall you might probably want to have something like:

// probably on frame1 before your preloader code
Stage.showMenu = false; // hides the built in items on context menu
this._lockroot = true; // locks the root, duh
this.tabEnabled = false; // disables tabs
this.tabChildren = false; // disables tabs for it's children

for timeline coders

_global.gameroot = this; // where this = root actually
//  when "this" is traced it ouputs "_level0" most of the time unless altered

and for those who use a little more OOP approach

var maingame = new MainGame( this ); // where this = root actually
 
// on your MainGame class or the like
class MainGame{
  public static var GameRoot:MovieClip;
  // constructor
  public function MainGame( root:MovieClip) {
    GameRoot = root; // stores the root mc in static var
  }
}

Now, your actionscript 2 coding life will be a little better with these in mind.


Other Keywords

  • Starting flash with actionscript 2 (AS2).
  • Frame 1 of actionscript 2 project/game.
  • Preloader code actionscript 2 (AS2).
  • Why to avoid or why not use _root/root with actionscript.
  • Getting rid of yellow boxes when tabbed.
  • Flash actionscript tabs.
  • Flash actionscript context menus.
  • Flash actionscript important points especially for games.

Have something about this? There are 4, where's yours?
  1. kreig

    great read!
    i’m an AS2 guy and I know / aware of the exploits of the old system.
    And this took out a few thorns off my chest.
    I’m moving to AS3 after I finish my last game on AS2

    PS: why is your “Send” button is named “Search” ?

    • Jayc Santos

      Holy smokes I didn’t even notice that it was “search” to begin with. There, fixed and well.

      Glad it’ll help, I always try to not forget about having these with my as2 projects.

  2. Porter

    I try to avoid _root all together just because it was used by me in nearly every line of code back in AS2. I find that avoiding it keeps me on track with learning AS3 and staying away from bad practice. Nice article though, I’m aware it’s old but I checked it out anyways :)

    • Jayc Santos

      Great that old articles are still able help… and it will continue to until AS2 dies w/c I doubt would be somewhere near. I still tackle AS2 with a few projects and especially now that I’m playing around with flashlite and flash player for mobile (just for fun) so it’s still quite limited by AS2.

      Nice for you to drop by mate. :)

Leave a Comment


 (not published)


= Sum of 3 + 4 ? If this is your first post, your comment will be moderated.
Please use english and keep it punctual.