Classes are a major feature of AGAST 1.08 and later. You can think of a class as a broad category of objects which share common events. Classes are created by setting up one object with the desired events, and then setting the "class" property of other objects to point to that object.

The simplest use of a class is to clone an object. Say, for instance, that you have a lot of identical machines that go "ping" whenever you use your keycard on them. You could write a global object like this:

object PingMachineClass
{
     // Disable the class, so that it can't be clicked.
     enabled = false;

     //Make the class invisible
     visible = false;

     //Set the machine graphic and click area
     setStopAnim(pingMachine_sprite);
     setClickArea(-10, -10, 10, 10);
}

event Lookat -> PingMachineClass
{
     Ego:
     "It's a machine."
     delay 1;
     "It appears to have a slot for a keycard."
}

event Keycard -> PingMachineClass
{
     "<Ping!>"
}

The PingMachineClass object has been disabled and made invisible because it's not going to be used directly; we're just going to reference it from other objects. Now, whenever you want to put a ping machine in a scene, all you have to do is this:

object Machine
{
     // Make this object a child of the PingMachineClass
     class = PingMachineClass;

     setPosition(320, 240);

     // Enable the machine and make it visible
     enabled = true;
     visible = true;
}

Now, the machine object will look and act exactly like the PingMachineClass object.

However, duplication of objects isn't the only use for classes; in fact, it probably isn't even the most common one. Remember how we said classes share common events? Well, they do, but they don't have to share all of them. Suppose, for instance, that you want this particular machine to go "pong" instead of "ping." All you have to do is add a new keycard->machine event:

event Keycard -> Machine
{
     "<Pong!>"
}

This event overrides the keycard->PingMachineClass event.

The machine example illustrates the basic use of classes, but there's a lot more that you can do, by combining classes with some of AGAST's other features. For instance, suppose you want certain objects to highlight green when the mouse hovers over them. You could write MouseOver and MouseOff events for every one... but that could be a lot of events, and all that copying and pasting would be extremely tedious, and you'd be up a creek if you decided you needed to change something.

Once again, classes come to the rescue. Just create a basic object that does what you want:

object GreenHotSpotClass { }

event MouseOver GreenHotSpotClass
{
     // Make the object green
     filter = COLOR_GREEN;
}

event MouseOff GreenHotSpotClass
{
     // Set the color back to normal
     filter = COLOR_WHITE;
}

Now, all you have to do when you want to make an object that highlights is add "class = GreenHotSpotClass" to the object. In fact, why not make the machines highlight green? You might think you'd add mouse events to PingMachine, but there's an even easier way: just make PingMachineClass part of the greenHotspotClass!

object pingMachineClass
{
     // Setup the machine to highlight green
     class = GreenHotspotClass;

     // Disable the class,  so that it can't be clicked.
     enabled = false;

     // Make the class invisible
     visible = false;

     // Set the machine graphic and click area
     setStopAnim(pingMachine_sprite);
     setClickArea(-10, -10, 10, 10);
}

These examples only scratch the surface of what classes can do for your game. The possibilities are endless!

If you want to know more about the technical details of how classes work, read on to the next section.

Classes in AGAST

Dynamic Classing

In many languages, an object's class is static, defined at the time the object is declared, and fixed when the code is compiled. However, in keeping with AGAST's emphasis on flexible design tools, an object in AGAST can change its class at any time, just by setting the class property.

Whenever the class property is set, the object calls the initialization events of the class object, the class's class, and so on. These calls are made outermost first. For example:

object a
{
     Caption = "Class A";
}

object b
{
     class = a;
     Caption = "Class B";
}

object c
{
     class = b;
}

Here, when object c is set to class b, the initialization event for a is called first, followed by that for b. As a result, object c's caption is "Class B".

Events

The core utility of classes is to let objects inherit the events of other objects. When an object event occurs, the interpreter first looks for an event script attached to the object, then looks for an event script attached to its class, and so on down the line. The search order is as follows:

• object events at local scope
• object events at global scope
• class events at local scope
• class events at global scope
• class's class events at local scope
• ...etc...
• default events