next »

[Craig Stern]

First of all, merry Christmas to all you Christian types. I've been taking advantage of the holiday to try to learn AS 2, and being the masochist I am, I'm trying to use it to recreate a complicated strategy board game I designed in my college days. I'm having a strange issue that I though some of you might be able to help me with. I have a class (Map.as) that generates a tile-based map, and as part of the function it uses to that, it attaches a movieclip with the instance name "HeroRed" to the stage.

HeroRed is an instance of the Hero movieclip, extended by the class Hero.as. Per the Hero.as class, when I press him, he runs a function that displays a field of clickable blue tiles around him to show his movement range. Here is my problem: no matter what I do, I cannot seem to get HeroRed to actually move when I click those tiles. _root.HeroRed seems to refer to something else, since trace is quite adamant that _root.HeroRed has in fact moved when I click one of the tiles even though the HeroRed movieclip is visibly (and clickably) right where it was.

Does anyone who knows a lot about AS 2 here have any clue what the problem might be? I'd be really grateful for any insight into the matter!

[Glaiel-Gamer]

posting your code would help, post how you attach it and how you try to move it.

Also, if you're learning new why not do AS3? The only reason people complain about it is because they get used to the bad habits that AS2 allows for.

Anyway check for these things (i'm a little shaky on my as2 skills after getting so used to AS3 and c++):

_root.AttachMovie

where are you tracing? What could be happening is:

//move clip
//trace position
//more code
//accidentally move it back
//end of frame

[Craig Stern]

Ah, never mind, I figured it out. I forgot to add the Hero movieclips to the clear map function, and the game was attaching multiple instances of the HeroRed movieclip without clearing off the old ones. Sorry!

Anyway, I'm so used to AS1 that I'm having a hard time adjusting even to AS2. I don't want to even think about AS3 until OOP has become comfortable for me!

[Glaiel-Gamer]

in that case it might be worth it to take the jump to AS3 instead of going incrementally through 2 first since 3 is going to force you to forget a couple things you learn about in 2

[Problem Machine]

One of the things I've learned about AS2 over the past few weeks: All those tutorials where they say it's bad practice to reference _root? Those are TOTALLY RIGHT. Avoid it if at all possible. Same goes double for _level0.

[bateleur]

in that case it might be worth it to take the jump to AS3 instead of going incrementally through 2 first since 3 is going to force you to forget a couple things you learn about in 2

Seconded.

Also, AS3 is actually much easier than AS2 overall. Even though it might not initially seem so to an AS1 programmer, it simply has fewer nasty gotchas and pitfalls.

[Craig Stern]

Okay, I have a couple of questions for you AS experts out there:

1) What the hell is level0? It keeps saying that one of my movieclips is _root.level0.MCname, and I certainly don't recall creating anything called level0.

2) Can a class both extend movieclips and also inherit from another class? (I'm starting to think that I need separate classes for the different units in this game, but it would be highly efficient if they could all inherit some common functions from a parent "Unit" class.)

As for AS3, what exactly is it that makes it easier to use? By all appearances, it looks much more complicated to perform even basic tasks in AS3 than it does in AS2.

[muku]

2) Can a class both extend movieclips and also inherit from another class? (I'm starting to think that I need separate classes for the different units in this game, but it would be highly efficient if they could all inherit some common functions from a parent "Unit" class.)

Why not derive a Unit class from MovieClip and let all concrete units derive from this class?

[BorisTheBrave]

1)
_levelx was the mechanism for loading in external movieclips. _level0 is the original flash file as opposed to the ones loaded, while _root was the shortcut for the one you are usually in. Not sure about your exact target.

2)
As muku suggests. Flash does not support multiple inheritance, though interfaces may be appropriate depending on what you intend to do.
You might also want to consider having your movieclips and your Unit objects (whatever they are) seperate, each having a reference to the other. This is often convenient for proper separation of different segments of code.

Why is AS3 better? Well, lots of reasons.

• The built in libraries have been tightened up to be more consistent, and powerful, in particular the display API.
• The language itself has improved considerably, though this is difficult to explain unless you try it for yourself, or are already an experienced programmer. Static typing and class based inheritance are very powerful, though you are not obliged to use either.
• Everyone else uses AS3, so there's better third party library capabilities.
• It's blazingly fast compared with AS2, and compares pretty well with other scripting languages.

It is a bit more verbose for simple tasks, particularly as tutorials aim to show you the "right" way of doing things. But it pays dividends in larger projects.

[bateleur]

(Some of this has already been mentioned whilst I was typing, but...)

1) What the hell is level0?

Informally speaking, it's the (base) layer of hardcoded stuff created using the Flash UI drawing tools. If you create everything via ActionScript it never gets used. So presumably you must have placed something on the stage manually?

2) Can a class both extend movieclips and also inherit from another class?

No.

Once you start designing more complex classes like that (which is a good thing, generally) there are two things which help:

1) Using interfaces. Interfaces are good. Learn to love them.

2) Thinking about the difference between "class Foo is a MovieClip" and "class Foo has a MovieClip". This distinction is important in any OO language, not just ActionScript. You only want to inherit in the former case. Doing so in the latter case is lazy and a habit that can cause trouble for you as your program complexity increases.

I'm starting to think that I need separate classes for the different units in this game, but it would be highly efficient if they could all inherit some common functions from a parent "Unit" class.

In this scenario a third option would be to have Unit inherit from MovieClip, then individual unit types inherit from Unit.

As for AS3, what exactly is it that makes it easier to use?

AS2 allows you to cheat in various ways when writing things, primarily by being sloppy with types and properties. It in turn is sloppy internally in the way it does things. All this is superficially convenient, but means that as you write more complex software you will start getting nasty problems associated with this sloppiness (such as runtime type errors, runaway memory consumption, poor performance and so on).

AS3 may cause brief growing pains as you learn to do things properly, but then the compile-time type checking will find a lot of your bugs for you and everything will run faster and be more stable. There are also numerous ease-of-coding benefits due to improved libraries. For example: Not all DisplayObjects are drawable Sprites and not all Sprites are MovieClips. You can load in or draw graphical data to offscreen objects unconnected to your visual hierarchy and then add them anywhere. Clearly tremendously useful for games.

[Craig Stern]

2) Can a class both extend movieclips and also inherit from another class? (I'm starting to think that I need separate classes for the different units in this game, but it would be highly efficient if they could all inherit some common functions from a parent "Unit" class.)

Why not derive a Unit class from MovieClip and let all concrete units derive from this class?

So you can link any number of movieclips to a single class?

[BorisTheBrave]

Um, you seem to have missed something. If you made Unit a class inheriting from MovieClip, you could have any number of instances of it. And you can also tell all your seperate classes corresponding to your graphics to inherit from Unit instead of MovieClip, making them "concrete" classes of Unit.

[Craig Stern]

So, just to see if I understand this correctly: I can create a Class (Unit) that extends the Movieclip Class generally, then create a bunch of specific unit that extend Unit, and in the Linkage settings for each unit's movieclip, set its Class to the appropriate customized child class. And this will work?

[BorisTheBrave]

Yes, it will. But I will repeat what everyone has been saying, which is that you should not be doing this. It is unlikely that your Unit class is actually intended to extend Sprite. Do you think you could explain what you mean by Unit?

If it is a game object, is is better that you create a separate object to represent it, and then provide a reference to the Sprite from that. "has-a" vs. "is-a" again.
This separates your game logic from your display code, which will prove vital if you ever intend to change anything, and actually makes your code easier.

So, to give an example.

Code:

public class Unit{

public var health:int;
public var sprite:Sprite;
public virtual function Die() {}
public function Damage(i:int){
  health -= i;
  if(health<0)
    Die();
}
}

public class InfantryMan extends Unit{

public function InfantryMan(){
  super();
  health = 20;
}

public override function Die() {
  sprite.gotoAndPlay("die");
}
}

Here, for simplicity, I am assuming that when you create a new Unit, you also create a sprite for it, and fill in the member variable. But you could also create the appropriate sprite in the constructor for each class too.

[Craig Stern]

Hey Boris, your example code looks very similar to what I was thinking of: I want Unit to provide some basic variables and functions common to all unit types, and use the child classes to fill in the default variables for each unit and perhaps modify some of the Unit functions where a unit requires different treatment.

I see that you don't have Unit extending Movieclip, however. I was thinking of putting movement functions in Unit, which necessarily would have to manipulate the movieclips of the units on the stage. Is there a way to do this without having the Unit class extend Movieclip? Also: shall I assume that a virtual function is a template and an override function is the child class's superseding version of the virtual function? What exactly is the super() function I see in your example code?

[BorisTheBrave]

I'm not going to go into a full tutorial on object orientation now, though you do assume correctly. You can look these things up in the AS3 reference if you want to know more.

There is not much difference between Unit inheriting from MovieClip and Unit inheriting from Object (and referencing the MovieClip). Both are acceptable. My example was with the latter. If we were doing the former, then InfantryMan's Die method would look like this:

Code:

public override function Die() {
  gotoAndPlay("die");
}

as gotoAndPlay be a method of Infantryman inherited from MovieClip. So my way basically involves typing an extra "sprite." in certain places. This may be more verbose, but I would recommend it anyway as it ultimately makes your code more flexible.

For example, you may decide you want units to be festively decorated around christmas time. If the game logic is distinct from display, you can merely change the code creating the sprites to create a different one at Christmas, but the rest is unchanged. But you find yourself with a harder time if you had mixed the two different things.

Or a less frivolous example, say both grunts and generals have similar behaviour, aside from different sprites and different health. You might not want to bother creating a class for each of them, you can just create a GenericInfantry class that takes the health value and the sprite in the constructor. If game objects were movieclips, you'd have to create stub classes for the general sprite and the grunt sprite to tell them to inherit from GenericInfantry.

Ok, I'm rambling now...

[Craig Stern]

Interesting--thanks for the tips. One more question, if I may: I noticed you typed the sprite variable as Sprite. I did not realize this was a data type for a variable. Is this just a way of accessing jpgs and pngs directly without putting them into movieclips?

[bateleur]

I noticed you typed the sprite variable as Sprite. I did not realize this was a data type for a variable. Is this just a way of accessing jpgs and pngs directly without putting them into movieclips?

It's a new class introduced in the AS3 libraries to make everything a bit less stupid. The inheritance hierarchy for MovieClips now looks like this:

DisplayObject -> InteractiveObject -> DisplayObjectContainer -> Sprite -> MovieClip

A Sprite that is not a MovieClip differs in that it has no timeline of its own. This is sensible, because for the vast majority of visual objects you don't want a distinct timeline (all game objects follow the same timeline).

Sprites are useful. The source for my current project, for example, contains the word "Sprite" 284 times and the word "MovieClip" 0 times.

(If you are still working with AS2, you should read "Sprite" as "MovieClip".)

Incidentally, regarding "super": In most object oriented languages the need occasionally arises to explicitly call a method on the parent of the current class. The parent, in formal terms, is called the "superclass". So in BorisTheBrave's example, what he's done is to define the construction of an InfantryMan very efficiently by first calling the Unit constructor (which is the superclass) and then (re)setting the health of the newly initialised Unit. (Technically it's not necessary to call "super()" in that case because it's done automatically by the system, but it can sometimes improve code clarity.)

Note that one can also make calls like "super.foo()" to call the foo() method of the parent. By far the most common case is for this to be used in the foo() method of the child class ("subclass") as a way to inherit some behaviour from the parent but do a few other things as well.

[raigan]

You should REALLY try AS3, I found it to be a huge productivity boost from AS1, simply because rather than hunting for bugs/typos, the compiler will TELL you about them.

Plus the new organization of the stage/sprites/etc is a lot clearer.. no more messing with _root, etc.

[Craig Stern]

Cool. Thanks for the explanations!