So you want to program a Flash game...

Tutorial 7: new ships and Artifical Intelligence

2009-01-12T06:37:00.000-08:00

Right, now that preloader nonsense is out of the way, let's get another ship up on the screen.

This is what we'll have by the end of this tutorial:

press A and D to rotate, and W to apply thrust.

Get the whole zip file here.

New ship types. To inherit or not to inherit?

Here's an interesting issue I've had. I want to make different kinds of ships. In the example above I have blueLightFighter and redLightFighter. Now, how do I define these?

Before the Tragedy, I had them as classes that extended the Ship class, so I'd just write var myShip:Ship = new blueLightFighter();

But since then, reading about OOP has got me worried about using inheritance when I don't need to. The thing is, blueLightFigher and redLightFighter have totally identical methods. In fact, the only difference they have is in the initial values for their attributes (such as maxSpeed or acceleration). Even with more complex ships, that may have multiple cannons and missile launchers, the only thing that's different is their constructor.

This led me to think that maybe I should simply pass in a variable which tells the Ship constructor what values it should use for the ship attributes. Something like var myShip:Ship = new Ship(Ship.BLUE_LIGHT_FIGHTER). The Ship.BLUE_LIGHT_FIGHTER is a public static constant (which means it can be accessed through the class definition) which will then call a function within the Ship class that sets the attributes.

But now we have another issue. I know for a fact that later on I'm going to start writing ship classes that do extend the methods of Ship - for example a great big carrier will actually have a rotationAcceleration value as well (as in it eases into rotation). Also, I'll be overriding collision detection methods. So then things would get complicated if I have to start writing:

var myFighter:Ship = new Ship(Ship.BLUE_LIGHT_FIGHTER); //just change the ship attributes
var myCarrier:Ship = new carrierShip(Ship.BLUE_CARRIER); //carrierShip extends the Ship class

urgh. I prefer simply calling a new class each time. As in:

myShip:Ship = new blueLightFighter();
myOtherShip:Ship = new blueCarrier();

Keeps things consistent. So even though my smaller ships don't need to extend the Ship class, they will do, to keep things simple when I start scripting my levels later on. All clear? Good, let's make some new ships.

Making a few changes to the Ship class.

So now in my game I'll never actually call new Ship(), but the name of a ship type that extends the Ship class. In the Ship constructor, I'll contain a call to a setShipAttributes() function (I hope it's purpose is self-explanatory). Within the Ship class, setShipAttributes is empty - it will be defined in the classes that inherit from it.

I'm also going to add a few things - each ship will have a _shipType variable. This will be useful in the future for things like AI. I plan to use the classic rock-paper-sizzors form of game design regarding units - as in shipA is deadly against shipB, but vulnerable to shipC (which in turn might be vulnerable to shipB etc. etc.). So I don't want the AI just attacking the nearest ship - that ship might be the worst kind of ship to fight. Instead, it will look for the ship types it is most effective against...

Also, let's add some arguments for the ship constructor - it's initial position and rotation.

//--------------------------------------------------------------------------
//
//  CONSTRUCTOR
//
//--------------------------------------------------------------------------
  
public function Ship(x:Number = 0, y:Number = 0, rotation:Number = 0)
{
   this.x = x;
   this.y = y;
   this.rotation = rotation;
     
   setShipAttributes();
     
   _aiPilot = new AIPilot(this);
   _controllingPilot = _aiPilot;
     
   //see bottom of file for updateShip
   addEventListener(Event.ENTER_FRAME, updateShip)
}

A nice thing about flash is that if you set a value for the arguments of a function, those arguments are now optional. So I could say var myShip:Ship = new blueLightFighter(20,50,45) to have a ship at position [20,50] and facing and angle of 45 degrees, but if I just write new blueLightFighter(20,50) there won't be an error - the constructor will merely use the default value of 0 degrees for rotation. Cool, eh?

I've also added the public static consts for shipTypes. I've made them integers, so that I can classify them (as in all ship types below 10 are fighters, between 10 and 20 are corvettes, between 20 and 30 are frigates etc.). Also, integer comparisons are faster than string comparisons...

So now let's create two new .as documents: blueLightFighter.as and redLightFighter.as. These will both be very simple classes, that inherit from Ship and simply override the setShipAttributes function. Here's blueLightFighter for example:

////////////////////////////////////////////////////////////////////////////////
//
//  AWOOGAMUFFIN
//  Copyright er... I don't understand copyright. I think uploading this code
//  possibly robs me of all rights. Just be nice - if you use my code, mention
//  where you got it from, yeah?
//
//  NOTICE: Awoogamuffin permits you to use, modify, and distribute this file
//  in accordance with the terms of the license agreement accompanying it.
//
//  Hahahaha, I just copied that from the conventions page (like everything I
//  do). There's no license agreement. Stop looking for it.
//
//  BLUE LIGHT FIGHTER
//
////////////////////////////////////////////////////////////////////////////////

package ships
{
   import pilots.*;

   public class BlueLightFighter extends Ship
   {
      //--------------------------------------------------------------------------
      //
      //  CONSTRUCTOR
      //
      //--------------------------------------------------------------------------
  
      public function BlueLightFighter(x:Number = 0, y:Number = 0, rotation:Number = 0.0)
      {
         super(x, y, rotation);
      }
  
      //--------------------------------------------------------------------------
      //
      //  OVERRIDDEN METHODS
      //
      //--------------------------------------------------------------------------
  
      override protected function setShipAttributes()
      {
         _shipType = Ship.BLUE_LIGHT_FIGHTER;
     
         //attributes specific to the blue light fighter class
         shipImage = new blueLightFighterImage();
         _turnRate = 300.0/25.0;
         _maxSpeed = 450.0/25.0;
         _acceleration = 100.0/(25.0 * 25.0);
     
         //give the ship a mind of its own:
         _aiPilot = new AIPilot(this);
     
         addChild(shipImage);
      }
   } 
}

You might be full of wonder and excitement at the line _aiPilot = new AIPilot(), as indeed you should be.

Writing the AIPilot class:

Now it's ridiculous how much time I sank into the AI before the tragedy. You get hooked up on all these tricky little details that any average user would probably never notice, but that grate against your soul. Keeping things simple and realistic is key, but ever so difficult to enforce.

So we're going to write the AIPilot class. This will extend the Pilot class, so all it will do is interpret the situation, then set commandRotation and commandThrust to the valid setting - it will never actually modify the ship itself (hence the use of private variables). For now, all I'm going to have the AIPilot do is turn to face the targeted ship, and once it is facing the ship, apply thrust.

So first of all, back in the Pilot class, we add the variable:

private var _target:Ship;

And we give this a getter and setter. The setter is important - because later whenever you set a new target for a Pilot, this will modify settings in the Pilot's previous target, as well at the new target. All this will happen in the setter, and I won't have to worry about it. For now, it doesn't do anything other than set the Pilot's _target variable...

Right, so we add an updatePilot() function in our AIPilot class, and within it we do a little trigonometry to figure out the angle between the ship and its target - we can use this with the angle getter function for our Vector2D class. We then write a function faceAngle which will turn the ship towards the desired angle, and it returns a Boolean: true if the ship is now facing its target, false otherwise. So we'll simply have the AIPilot apply thrust when faceAngle returns true. Brilliant.

Here's the AIPilot class:

////////////////////////////////////////////////////////////////////////////////
//
//  AWOOGAMUFFIN
//  Copyright er... I don't understand copyright. I think uploading this code
//  possibly robs me of all rights. Just be nice - if you use my code, mention
//  where you got it from, yeah?
//
//  NOTICE: Awoogamuffin permits you to use, modify, and distribute this file
//  in accordance with the terms of the license agreement accompanying it.
//
//  Hahahaha, I just copied that from the conventions page (like everything I
//  do). There's no license agreement. Stop looking for it.
//
//  AIPilot - the A stands for "Aaaaaaargh!"
//
////////////////////////////////////////////////////////////////////////////////

package pilots
{
   import ships.*;
   import Maths.Vector2D;
   
   public class AIPilot extends Pilot
   {      
      public function AIPilot(ship:Ship)
      {
         super();
         _ship = ship;
      }
      
      //--------------------------------------------------------------------------
      //
      //  METHODS
      //
      //--------------------------------------------------------------------------
      
      //called from the ship class
      public function updatePilot()
      {
         //start by reseting all commands
         resetCommands();
         
         //for now, we'll just have the AIPilot chase after its target
         if(_target != null)
         {
            /* calculate angle between ship and target. I should probably put this sort of thing
            in a trigonometry class */
            var targetAngle:Number = 0.0;
            var relativePosition:Vector2D = new Vector2D(_target.x - _ship.x, _target.y - _ship.y);
            targetAngle = relativePosition.angle;
            
            //so turn ship towards this angle, and if it reaches it, apply thrust
            if(faceAngle(targetAngle)) _commandThrust = true;
         }
      }
         
      //faceAngle - will turn ship towards targetAngle, and if it reaches said angle it returns true
      public function faceAngle(angle:Number):Boolean
      {
         //calculate the difference between target angle and the ship's angle
         var difference:Number = angle - _ship.rotation;
         var absDifference:Number = Math.abs(difference);
         
         //next part is a bit tricky due to the fact that we have a switch between 180 and -180
         //first, if target is within turn rate of AI ship it'll go for it!
         if(absDifference <= _ship.turnRate || absDifference >= (360 - _ship.turnRate))
         {
            //now the ship only turns the required number of degrees - which is less than the ship's
            //turn rate
            _commandRotation = difference;
            return true; //ship facing angle
         }
            
         //otherwise it will rotate to face target ship
         else
         {
            //so first check if it needs to turn right
            if(difference > 0 && absDifference < 180 || absDifference > 180 && difference < 0)
            {
               _commandRotation = _ship.turnRate;
            }
            //ok, so turn left then
            else
            {
               _commandRotation = -_ship.turnRate;
            }
         }
         return false; //ship not facing angle yet
      }
      
      public function resetCommands()
      {
         _commandRotation = 0.0;
         _commandThrust = false;
      }
   }
}

Now I think this AIPilot class is so wonderful that every ship should have one. Remember in Ship.as we had _controllingPilot? Well let's add an _aiPilot variable as well. This will be added to every ship in the constructor (as we saw earlier). This will be the default controllingPilot for all ships, so back in the Ship class, we add the line _controllingPilot = _aiPilot.

Why don't we just put _aiPilot = new AIPilot() in the Ship class? It would be more efficient than having to write it in each ship class I make from now on, right? Well, the thing is I know that the AIPilot for a little fighter will function very differently from that AIPilot for an artillery ship. Yes, in the future, we will be extending AIPilot as well, and in each ship class, we'll be telling it what kind of AIPilot to create in the setShipAttributes function. See? Thinking ahead...

In the updateShip function we also need to add: aiPilot.updatePilot().

Fine, here's the whole Ship class... I'll just make it so you have to scroll through it - that way it doesn't take up most of this blog entry:

////////////////////////////////////////////////////////////////////////////////
//
//  AWOOGAMUFFIN
//  Copyright er... I don't understand copyright. I think uploading this code
//  possibly robs me of all rights. Just be nice - if you use my code, mention
//  where you got it from, yeah?
//
//  NOTICE: Awoogamuffin permits you to use, modify, and distribute this file
//  in accordance with the terms of the license agreement accompanying it.
//
//  Hahahaha, I just copied that from the conventions page (like everything I
//  do). There's no license agreement. Stop looking for it.
//
//  SHIP CLASS - chaos and craziness and head-aches
//
////////////////////////////////////////////////////////////////////////////////

package ships
{
   import flash.display.*;
   import flash.events.*;
   import pilots.*;
   import Maths.Vector2D;
   
   public class Ship extends Sprite
   {
      //--------------------------------------------------------------------------
      //
      //  CLASS VARIABLES
      //
      //--------------------------------------------------------------------------
      
      public static const BLUE_LIGHT_FIGHTER = 1;
      public static const RED_LIGHT_FIGHTER = 2;
      
      //--------------------------------------------------------------------------
      //
      //  VARIABLES
      //
      //--------------------------------------------------------------------------
      
      //----------------------------------
      //  ship movement
      //----------------------------------
      protected var _turnRate:Number = 300.0/25.0;
      protected var _maxSpeed:Number = 400.0/25.0;
      protected var _acceleration:Number = 250.0/(25.0 * 25.0);
      protected var _velocity:Vector2D = new Vector2D();
      
      //----------------------------------
      //  identifiers
      //----------------------------------
      protected var _shipType:int;
      
      //----------------------------------
      //  visual
      //----------------------------------
      protected var shipImage:Sprite;
      
      //----------------------------------
      //  pilots
      //----------------------------------
      private var _controllingPilot:Pilot;
      protected var _aiPilot:AIPilot;
      
      //--------------------------------------------------------------------------
      //
      //  CONSTRUCTOR
      //
      //--------------------------------------------------------------------------
      
      public function Ship(x:Number = 0, y:Number = 0, rotation:Number = 0)
      {
         this.x = x;
         this.y = y;
         this.rotation = rotation;
         
         setShipAttributes();
         
         _controllingPilot = _aiPilot;
         
         //see bottom of file for updateShip
         addEventListener(Event.ENTER_FRAME, updateShip)
      }
      
      //--------------------------------------------------------------------------
      //
      //  GETTERS AND SETTERS
      //
      //--------------------------------------------------------------------------
      
      public function get turnRate():Number
      {
         return _turnRate;
      }
      
      public function get velocity():Vector2D
      {
         return _velocity;
      }
      
      public function get aiPilot():AIPilot
      {
         return _aiPilot;
      }
      
      public function get shiptype():int
      {
         return _shipType;
      }
      
      public function set controllingPilot(pilot:Pilot)
      {
         _controllingPilot = pilot;
         pilot.ship = this;
      }
      
      //--------------------------------------------------------------------------
      //
      //  METHODS
      //
      //--------------------------------------------------------------------------
      
      public function applyThrust()
      {
         var thrust:Vector2D = Vector2D.newVectorFromAngle(rotation);
         thrust.length = _acceleration;
         _velocity.addVector(thrust);
      }
      
      public function moveShip()
      {
         //first check that velocity is not above maxSpeed
         if(_velocity.lengthSquared > _maxSpeed * _maxSpeed)
         {
            _velocity.length = _maxSpeed;
         }
         
         x += _velocity.x;
         y += _velocity.y;
         
         //this next bit is just to make the ship bounce off the edges off the
         //stage
         if(x < 10 || x > 540)
         {
            x < 10 ? x = 10 : x = 540;
            _velocity.x *= -0.3;
         }
         if(y < 10 || y > 390)
         {
            y < 10 ? y = 10 : y = 390;
            _velocity.y *= -0.3;
         }
      }
      
      protected function setShipAttributes()
      {
         //this is performed by child classes.
      }
      
      //--------------------------------------------------------------------------
      //
      //  EVENT HANDLERS
      //
      //--------------------------------------------------------------------------
      
      public function updateShip(event:Event)
      {
         _aiPilot.updatePilot();
         
         rotation += _controllingPilot.commandRotation;
         if(_controllingPilot.commandThrust) applyThrust();
         
         moveShip();
      }
   }
}

Now back in the document class, in our startGame function we add these lines:

public function startGame()
{
   //create the player ship
   var myShip:Ship = new BlueLightFighter(100,300);
   addChild(myShip);

   //assign the human player as the ship's pilot
   var humanPilot:HumanPilot = new HumanPilot();
   myShip.controllingPilot = humanPilot;

   //now let's make a red fighter
   var enemyShip:Ship = new RedLightFighter(300,100);
   addChild(enemyShip);

   //this is silly - in the future part of that aiPilot's functionality will be to select it's own targets
   enemyShip.aiPilot.target = myShip;
}

One more thing, we need the HumanPilot class to know that it is controlling myShip, so in the Ship class, for the set controllingPilot() function we now have:

public function set controllingPilot(pilot:Pilot)
{
   _controllingPilot = pilot;
   pilot.ship = this;
}

And the result is an angry little red ship chasing after the blue ship and bumping against the edges of the screen. Not much of a game I admit, but things are coming along...

Tutorial 6: writing a preloader for AS3. Argh! Urgh!

2009-01-10T06:21:00.000-08:00

Click here to download the full project.

Needlessly long introduction:

This tutorial was supposed to be about creating new ships, and I was happily trundling down that road when a person called bluemagica in the flash kit forums asked me why I was exporting my blueLightFighterImage symbol on the first frame (when you tick the export for Actionscript box in the properties menu, the export on first frame box is also ticked automatically) thereby instantly revealing my pitiful ignorance because I had to ask what the whole "export on first frame" option actually meant.

Then Pazil came along and informed me that the export on first frame option means that the .swf will load up this symbol right at the start, before anything happens. This is bad. Why is it bad? Trust me, it's bad. Really, just believe me. Can't you just listen to me and cease this endless questioning? Fine, I'll explain.

You've probably played a few flash games already. If you haven't, I order you immediately to go play Pillage the Village which is probably the best thing to ever happen to me in my life.

Anyway, so you've played these games, and you've noticed that at the beginning you have a little screen with a nice graphic and a progress bar showing you how much of the game has been loaded. In the funky parlance of our trade, this is called the preloader.

I hadn't thought about this problem. Before the Tragedy I hadn't had any problems because all my symbols were vector graphics. I chose vector graphics because they are so small - at the cost of a bit more processor crunching. My game never went above 70k, so there was next to no load time. But I appreciate that some of you might prefer to use great big bitmaps for your ships and whatnot, and don't forget that later we'll be wanting sound and maybe music, and all this needs to be loaded. So here was a problem that needed to be nipped in the bud.

The unfortunate thing about the export on first frame option is that everything will be loaded before the preloader starts. This results in a blank white screen for as long as the game is loading, during which you'll lose some of your potential players, some of whom might become fans, some of whom might become groupies, which let's face it, is why we're programming, right? Chicks. Yup.

So we don't want these library symbols to be exported on the first frame. We want them exported after the preloader starts.

This is where I became upset.

Why I became upset:

At the beginning of this series of tutorials I proudly declared that I would not be using the main timeline. It would all be gloriously Object Orientated fun. Now OOP is in contrast to sequential programming, and a timeline by it's very nature is sequential. So booooo timeline, I say.

It turns out that if you untick the export on first frame option, the symbol simply will not be embedded into your .swf unless it is included in the timeline. I searched for countless minutes for a way to export library symbols with AS3, but to no avail. I wanted something where in the document class I'd have:

create preloader
start importing library symbols (while updating preloader)
when everything has been loaded, start the game.

But there's no action script function for "load library symbols". The only way to tell the compiler that I want those symbols involved in the game is to manually place them onto the stage at a frame which isn't frame one. Uurruurrrgh! Yucky.

I really don't like this. It feels wrong, somehow. Dirty. Unethical even. But hey, I'm sick of fruitless google searches, so this is how we're going to do things. After hours of experimentation (far more than were necessary, more on that later) this is what I came up with:

Making the preloader:

So first of all, let's go to our blueLightFighterImage symbol, and un-tick that export on first frame box. Then in the main time-line we have to - urgh - insert a keyframe on frame 2. Within that frame, we'll place our blueLightFighter Image. Doesn't matter where, or what rotation, just so long as it's there. This frame will never actually be seen by anyone - but it will be checked by the compiler, which will then load it into memory. It's so hacky it makes me want to cry.

Even worse, just to rub salt into the wound, we could right click on frame one, go to add actions, and noooo! code in the main timeline! We write:

stop();

Admittedly, I could actually just write this in the Document class, but I really feel like wallowing in self-pity, succumbing to the daemons of user-friendly interfaces.

nooooooooooooo!

We then need to add an empty keyframe to frame 3. I'll explain why later.

While we're modifying our blueLightFighterImage, I'm also going to set the base class to Sprite, not MovieClip - I originally had it as MovieClip so that I could animate the ship explosion, but I've decided against that, and I have some funky plans. Making the ship a Sprite is easier on the memory. Bare in mind that this means back in the Ship.as file we need to modify var shipImage:MovieClip to var shipImage:Sprite otherwise we get errors... I've also made a couple of other small changes in the Ship class, such as private variables which won't have a getter or setter applied no longer have the underscore before their names. Check out the zip file of the entire project to have a look around if you want.

don't export in first frame, and set the base class to sprite

Now that icky wysiwyg nonsense is done, we can go back into the beautiful, pure simplicity of code. We're going to write a preloader class!

The pre-loader class:

After scouring the internet, I've borrowed heavily from a post by a person called plutocrat on a thread in the actionscript.org forums. I suggest you have a read to learn about potential issues and whatnot.

The preloader knows how much has been loaded by accessing the root.loaderInfo class. I want the preloader to be a separate entity, so I'm going to have to use spaceGame.instance (remember tutorial 3?) to access the root (or stage - I'm not entirely sure what the difference between root and stage is).

Also, this is obviously a class that I'm going to be using often - for future games. Though the preloader for each game will presumably be different, the basics are the same. So I write a preloader class with a default display (all it does is create a black bar that extends across the bottom of the screen) which functions that can be overridden (more on that later) by a class which extends the preloader. This new class can be specific to the game, and have all the funky graphics it wants. Such is the beauty of OOP.

I'll make a new package called preloaders which will contain both the generic preloader and later the one specific to this game.

So this is my Preloader class (I don't capitalise the L because p is a prefix so I consider preloader to be one word. You might prefer to call it preLoader, but then you need to be consistent. So a function called unlock should be called unLock... similarly I need to be consistent in my naming).

Here's the class:

////////////////////////////////////////////////////////////////////////////////
//
//  AWOOGAMUFFIN
//  Copyright er... I don't understand copyright. I think uploading this code
//  possibly robs me of all rights. Just be nice - if you use my code, mention
//  where you got it from, yeah?
//
//  NOTICE: Awoogamuffin permits you to use, modify, and distribute this file
//  in accordance with the terms of the license agreement accompanying it.
//
//  Hahahaha, I just copied that from the conventions page (like everything I
//  do). There's no license agreement. Stop looking for it.
//
//  PRELOADER - something I plan to recycle for each game I create
//  I have borrowed heavily from code written by user plutocrat provided
//  on actionscript.org forums on this thread:
//  http://www.actionscript.org/forums/showthread.php3?t=137349
//
////////////////////////////////////////////////////////////////////////////////

package preloaders
{
  import flash.display.*;
  import flash.events.*;
 
  public class Preloader extends MovieClip
  {
     //--------------------------------------------------------------------------
     //
     //  VARIABLES
     //
     //--------------------------------------------------------------------------     

     protected var display:Sprite = new Sprite();
    
     //--------------------------------------------------------------------------
     //
     //  CONSTRUCTOR
     //
     //--------------------------------------------------------------------------
    
     public function Preloader()
     {
        createDisplay();
        addChild(display);
       
        //accessing the root through my document class instance
        SpaceGame.instance.root.loaderInfo.addEventListener(ProgressEvent.PROGRESS, progressHandler);
        SpaceGame.instance.root.loaderInfo.addEventListener(Event.COMPLETE, completeHandler);
     }
    
     //--------------------------------------------------------------------------
     //
     //  METHODS
     //
     //--------------------------------------------------------------------------
    
    
     /* the following functions just provide a basic default. With later games,
     I'll be writing preladers that inherit from this one, and override the
     following functions to create displays specific to that game */
    
     public function createDisplay()
     {
        //to be created in child classes. Here it will just be a rectangle defined
        //in the next function
     }
    
     public function updateDisplay(percent:Number)
     {
        //thanks to plutocrat for revealing to me this "with" thing
        with (display.graphics)
        {
           clear();
           beginFill(0x000000);
           drawRect(10,stage.stageHeight - 20,percent/100 * (stage.stageWidth - 10),10);
        }
     }
    
     public function removeDisplay()
     {
        removeChild(display);
     }
    
     //--------------------------------------------------------------------------
     //
     //  EVENT HANDLERS
     //
     //--------------------------------------------------------------------------
    
     public function progressHandler(e:ProgressEvent)
     {
        updateDisplay(e.bytesLoaded/e.bytesTotal * 100);
     }
    
     public function completeHandler(e:Event)
     {
        removeDisplay();
        dispatchEvent(new Event(Event.COMPLETE));
     }
  }
}

Talking a bit about Events:

Something of interest in this class is my use of events. The loaderInfo class automatically sends out an event whenever it makes progress, and also when it completes loading (it dispatches several other events, such as initialisation and errors, which you can read about in the Flash documentation). Event.COMPLETE refers to a static string variable. If you write trace(Event.COMPLETE) anywhere in your code (you need to have imported flash.events.*) you'll get "complete". That's all it is - a string. Why use Event.COMPLETE then? Why not just type

addEventListener("complete", completeHandler).

Well, that would actually work. The problem is the very real possibility that you make a typo and write:

addEventListener("compltee", completeHandler).

This means your event listener will be waiting for the string "compltee" to be dispatched before it calls completeHandler, and obviously this will never happen, and your code will not work. You won't get any warning either - the compiler doesn't know that "compltee" is wrong, so you're none the wiser. On the other hand, if you write:

addEventListener(Event.COMPLTEE, completeHandler)

The compiler will see that in the Event class there is no static const COMPLTEE and will throw an error, informing you immediately of your mistake. It's just a time-saver to be honest, but in this trade, time saving can drastically improve your mood.

I've also used dispatchEvent - when the preloader has finished, it shouts out "I've finished" with the line dispatchEvent(Event.COMPLETE). There's no reason for me not to use the static const Event.COMPLETE - in fact, it increases readability, and keeps the code consistent.

I'll be discussing events in greater detail in a future tutorial.

Back in the SpaceGame.as we'll create a preloader instance, and listen for that Event.COMPLETE before we start the game. I've written a new function startGame() which contains the code that used to be in the SpaceGame constructor.

Also, when the preloader has finished, we need to jump to frame 3, because the symbols we put in frame 2 can only be used in later frames (oh how desperately sequential!). So we bight the bullet and write gotoAndStop(3). Read about goto statements to see how bad they are. Wikipedia has a whole section on "criticism of goto usage".

Here's the spaceGame class:

////////////////////////////////////////////////////////////////////////////////
//
//  AWOOGAMUFFIN
//  Copyright er... I don't understand copyright. I think uploading this code
//  possibly robs me of all rights. Just be nice - if you use my code, mention
//  where you got it from, yeah?
//
//  NOTICE: Awoogamuffin permits you to use, modify, and distribute this file
//  in accordance with the terms of the license agreement accompanying it.
//
//  Hahahaha, I just copied that from the conventions page (like everything I
//  do). There's no license agreement. Stop looking for it.
//
//  DOCUMENT CLASS - hopefully mostly empty at all times
//
////////////////////////////////////////////////////////////////////////////////

package
{

  import flash.display.*;
  import flash.events.*;
 
  import ships.Ship;
  import Maths.Vector2D;
  import preloaders.*;
 
  public class SpaceGame extends MovieClip
  {
     //--------------------------------------------------------------------------
     //
     //  STATIC VARIABLES (CLASS PROPERTIES)
     //
     //--------------------------------------------------------------------------
    
     /*this will allow other classes to access the instance
     of the document class created at the beginning of the game */
     private static var _instance:SpaceGame;
    
     //--------------------------------------------------------------------------
     //
     //  STATIC METHODS (CLASS METHODS)
     //
     //--------------------------------------------------------------------------
    
     public static function get instance():SpaceGame
     {
        return _instance;
     }
    
     //--------------------------------------------------------------------------
     //
     //  VARIABLES
     //
     //--------------------------------------------------------------------------
    
     private var preloader:Preloader;
    
     //--------------------------------------------------------------------------
     //
     //  CONSTRUCTOR
     //
     //--------------------------------------------------------------------------
    
     public function SpaceGame()
     {
        _instance = this;
       
        preloader = new Preloader();
        addChild(preloader);
       
        preloader.addEventListener(Event.COMPLETE, preloaderCompleteHandler);
     }
    
     //--------------------------------------------------------------------------
     //
     //  METHODS
     //
     //--------------------------------------------------------------------------
    
     public function startGame()
     {
        var myShip:Ship = new Ship();
        addChild(myShip);
     }
    
     //--------------------------------------------------------------------------
     //
     //  EVENT HANDLERS
     //
     //--------------------------------------------------------------------------
    
     public function preloaderCompleteHandler(e:Event)
     {
        //always remove event listeners so that Garbage Collection can work
        preloader.removeEventListener(Event.COMPLETE, preloaderCompleteHandler);
        //don't need the preloader anymore
        removeChild(preloader);
        preloader = null;
       
        //have to do this for the symbols to be accessible. Ugly ugly ugly
        gotoAndStop(3);
       
        //let's get on with it!
        startGame();
     }
  }
}

Great. But when we test the game, we see no preloader. How do check it's working?

Testing the preloader. Awoogamuffin wastes his precious time:

Sometimes my noob status really costs me a lot of time and energy. There are certain aspects of Flash that you just need to know about, and I don't. An example is the "disable keyboard shortcuts" option in the control menu when testing a movie. In fact, I'm going to go back to tutorial 2 to tell people they need to do that for the A key to register in the test movie.

In this case, it was the fact that I was unaware that in the View menu while testing a movie, you can simulate download. It's brilliant. You can select download speed to see how long it would take, and obviously it allows you to test your preloader! Whee. Unfortunately for me I had a perfectly functional preloader for a long time, but thought it wasn't working because I couldn't get it to show up. Then I stumbled across this post in the NewGrounds forum, and all became clear.

Now there's an option I wish I'd known about earlier

Also, my little blueLightFighterImage is tiny. So I go ahead and stick a great big image in the library (remembering to drag it onto the stage at frame 2), and test it with the "simulate Download" option. It seems to work! Wahoo! We have a preloader.

Later on, I'll go ahead an extend the preloader to make something funky for this game. But that'll be later. First, we actually need a game.

Tutorial 5: making the ship move (using our Vector2D class)

2009-01-06T10:58:00.000-08:00

By the end of this tutorial, we will have this:

press A and D to rotate, and W to apply thrust

Wahey! 5 tutorials and finally something!

How'd I do it? Well, with our funky new Vector2D class it was very simple.

First, let's add a new key to listen to in the HumanPilot class. Remember our HumanPilot class, and how it inherits from Pilot? We wrote two variables for Pilot: _commandRotate and _commandThrust. Well in the HumanPilot class, for the event handlers we will write the following:

In the keyDownHandler we add the line:

if (event.keyCode == 87) _commandThrust = true; //W

and in the keyUpHandler we add:

if (event.keyCode == 87) _commandThrust = false; //W

So now pressing W will set the _commandThrust Boolean to true. So what will the thrust command do to our ship?

We need to add a few things to our Ship class: a few variables that define the Ship movement - its maximum speed, its acceleration, and finally its velocity. You know the difference between velocity and speed? Velocity's a vector, and speed is a number. Wow. Aren't you glad you learned that?

Then in the updateShip function, we're going to add a couple of things - we need it to react to commandThrust being true in the ship's Pilot, and we need to actually move the ship.

So we have two new methods: applyThrust() which creates a Vector2D based on the direction the ship is facing, and whose length is the ship acceleration. We then add this new vector to the velocity vector.

Notice that maxSpeed is divided by 25.0 (one second) because speed is distance/time. But acceleration is divided by 25.0 * 25.0, because acceleration is defined by distance over time squared. See? Physics. Oooooh.

Then we have moveShip(), which limits the ship's speed to it's maxSpeed (max is one of the few acceptable abbreviations. Again thanks intimidating conventions page).

This will be the last time I post the entirety of a class - they'll be getting bigger and bigger, especially the Ship class (it actually gets pretty chaotic, hence all the clear commenting I'm going to do). I'll just start uploading the entire project for you to peruse at your leisure. Here's the class, have a good, concentrated look at it:

////////////////////////////////////////////////////////////////////////////////
//
//  AWOOGAMUFFIN
//  Copyright er... I don't understand copyright. I think uploading this code
//  possibly robs me of all rights. Just be nice - if you use my code, mention
//  where you got it from, yeah?
//
//  NOTICE: Awoogamuffin permits you to use, modify, and distribute this file
//  in accordance with the terms of the license agreement accompanying it.
//
//  Hahahaha, I just copied that from the conventions page (like everything I
//  do). There's no license agreement. Stop looking for it.
//
//  SHIP CLASS - chaos and craziness and head-aches
//
////////////////////////////////////////////////////////////////////////////////

package ships
{
   import flash.display.*;
   import flash.events.*;
   import pilots.*;
   import Maths.Vector2D;
   
   public class Ship extends Sprite
   {
      //--------------------------------------------------------------------------
      //
      //  VARIABLES
      //
      //--------------------------------------------------------------------------
      
      //----------------------------------
      //  ship movement
      //----------------------------------
      private var _turnRate:Number = 300.0/25.0;
      private var _maxSpeed:Number = 400.0/25.0;
      private var _acceleration:Number = 250.0/(25.0 * 25.0);
      private var _velocity:Vector2D = new Vector2D();
      
      //----------------------------------
      //  visual
      //----------------------------------
      private var _shipImage:MovieClip;
      
      //----------------------------------
      //  pilots
      //----------------------------------
      private var _controllingPilot:Pilot;
      
      //--------------------------------------------------------------------------
      //
      //  CONSTRUCTOR
      //
      //--------------------------------------------------------------------------
      
      public function Ship()
      {
         _controllingPilot = new HumanPilot();
         _controllingPilot.ship = this;
         
         _shipImage = new blueLightFighterImage();
         addChild(_shipImage);
         
         x = 275;
         y = 200;
         
         //see bottom of file for updateShip
         addEventListener(Event.ENTER_FRAME, updateShip)
      }
      
      //--------------------------------------------------------------------------
      //
      //  GETTERS AND SETTERS
      //
      //--------------------------------------------------------------------------
      
      public function get turnRate():Number
      {
         return _turnRate;
      }
      
      public function get velocity():Vector2D
      {
         return _velocity;
      }
      
      //--------------------------------------------------------------------------
      //
      //  METHODS
      //
      //--------------------------------------------------------------------------
      
      public function applyThrust()
      {
         var thrust:Vector2D = Vector2D.newVectorFromAngle(rotation);
         thrust.length = _acceleration;
         _velocity.addVector(thrust);
      }
      
      public function moveShip()
      {
         //first check that velocity is not above maxSpeed
         if(_velocity.lengthSquared > _maxSpeed * _maxSpeed)
         {
            velocity.length = _maxSpeed;
         }
         
         x += _velocity.x;
         y += _velocity.y;
         
         //this next bit is just to make the ship bounce off the edges off the
         //stage
         if(x < 10 || x > 540)
         {
            x < 10 ? x = 10 : x = 540;
            _velocity.x *= -0.3;
         }
         if(y < 10 || y > 390)
         {
            y < 10 ? y = 10 : y = 390;
            _velocity.y *= -0.3;
         }
      }
      
      //--------------------------------------------------------------------------
      //
      //  EVENT HANDLERS
      //
      //--------------------------------------------------------------------------
      
      public function updateShip(event:Event)
      {
         rotation += _controllingPilot.commandRotation;
         if(_controllingPilot.commandThrust) applyThrust();
         
         moveShip();
      }
   }
}

So there's a section that simply makes the ship bounce off the edges off the screen, which will be removed later. Oh and I also changed the background colour a little so that you can see the size of the stage (which I think i'll be changing eventually). Tadaaaa! Next step - let's have some enemy ships, and let's have them fly after us enthusiastically.

Oh, and here is the zip file of the entire project.

Tutorial 4: writing a vector class (excitement)

2009-01-05T16:36:00.000-08:00

We want to make the ship fly around, but how does this work? Well it's the same control scheme that's been confusing people since Asteroids - the ship maintains a certain velocity, that can only be changed by applying a force (thrust) in the direction the ship is facing. Sounds like physics. Sounds like vectors.

Vectors? If you don't know what I'm talking about, you have some serious reading to do, because I'm not doing a maths tutorial here. This is programming. Yes it is.

I want to program a useful little Vector2D class. Where to put it? Yes, another package! Now we use the Math class within flash for all our basic Mathematic needs (like squareRoot and power etc.) but not Vector2D. So I'm going to create a package that is quintessentially British: Maths. If you're worried that you might get confused between Maths and Math, call it myMath or squirrelEggs, though I do want to point out that logical names are by far the best. You might think sometimes that my function names are stupidly long, but I prefer a long name than a name I can't remember. Generally abbreviations should be avoided for this reason.

Brazil's a brilliant film

I'm going to be using this Vector2D class a lot, so I want to make it as simple to use as possible. That's why I'm going to use setters and getters for things like angle and length. So what are these damn things?

Well getters and setters are just function calls that do not need arguments. Also, you don't actually need a variable within the class for the getters and setters to get and set. For example, my Vector2D class will not have an angle variable, but you'll be able to get it and set it all the same (that's all done by playing with the x and y values).

I'm going to be extending the Point class, because it shares a lot of functionality with vectors (as in, it has an x and y value, as well as length). We just want to add some stuff.

Point happily provides us with a get length function, but not a set length function. What it does is provide us with a normalize function which allows you to set the length to anything you want. This is not what normalise means (besides, they spell it normalize the Yankee bastards). Infuriatingly my text editor refuses to accept that normalise with an s is the correct spelling.

So what I've done is given length a setter, and I've created my own noramalise function which, as it should, reduces the vector to the length of 1 unit. Note that normalised and normal vectors are not the same (we'll be using normal vectors, of sorts, further down the line). Confused yet? Hope not.

I've made a couple of static functions. Remember that? In fact, go read that link about methods you ignored earlier when I was talking about getters and setters, it tells you all about them (calls them class methods). I'm using them mostly to provide me with alternative constructors (to create a vector based on an angle, or copying another vector).

Quick note to somebody better than me - I would love to be able to override the Point.clone() function, but of course I would need it to return a Vector2D as opposed to a Point, and overriding functions have to return the same type. Is there some clever solution to this? I've vaguely read about overloading, but only to the point that it's not supported in ActionScript 3.

For those of you who don't know what override means, don't worry, we'll get to it soon.

Right, most of the rest of this tutorial will take place in comment form - here is the entire Vector2D class in all its wonderfulness, and notice my funky commenting scheme for clarity. As the classes get bigger and more complex, this kind of clarity is really useful. I've tried to get things right based on the intimidating programming conventions page...

Hopefully the comments in this code should explain everything (if you're confused about anything, feel free to ask me questions in the blog comments).

////////////////////////////////////////////////////////////////////////////////
//
//  AWOOGAMUFFIN
//  Copyright er... I don't understand copyright. I think uploading this code
//  possibly robs me of all rights. Just be nice - if you use my code, mention
//  where you got it from, yeah?
//
//  NOTICE: Awoogamuffin permits you to use, modify, and distribute this file
//  in accordance with the terms of the license agreement accompanying it.
//
//  Hahahaha, I just copied that from the conventions page (like everything I
//  do). There's no license agreement. Stop looking for it.
//
//  VECTOR2D - wonderful stuff with maths
//
////////////////////////////////////////////////////////////////////////////////

package Maths //call it myMath if you don't like the subtle British s
{
   import flash.display.*;
   import flash.geom.Point;

   /* I've decided to make Vector2D extend Point so that I can use the x and y
   values it inherits */
   
   public class Vector2D extends Point
   {
      //--------------------------------------------------------------------------
      //
      //  STATIC METHODS (CLASS METHODS)
      //
      //--------------------------------------------------------------------------
      
      /* that funky title you saw up there? Got that idea from the AS3 coding
      conventions page... I think it looks cool. I've also tried to respect
      the order they suggest but I get confused... the url for the convention
      page is http://opensource.adobe.com/wiki/display/flexsdk/Coding+Conventions */
      
      /* these methods are basically alternative constructors, hence the term "new"
      before each function name */
      
      //so we'd have: var myVector:Vector2D = Vector2D.newVectorFromAngle(90)
      
      //returns a normal vector pointing in the directions specified by angle
      public static function newVectorFromAngle(angle:Number):Vector2D
      {
         var radians:Number = (angle - 90) * Math.PI / 180;
         return new Vector2D(Math.cos(radians), Math.sin(radians));
      }
      
      public static function newVectorClone(vector:Vector2D):Vector2D
      {
         return new Vector2D(vector.x, vector.y);
      }
      
      //--------------------------------------------------------------------------
      //
      //  CONSTRUCTOR
      //
      //--------------------------------------------------------------------------
      
      public function Vector2D(x = 0.0, y = 0.0)
      {
         this.x = x;
         this.y = y;
      }
      
      //--------------------------------------------------------------------------
      //
      //  GETTERS AND SETTERS
      //
      //--------------------------------------------------------------------------
      
      /* I'm using getters and setters for dealing with vector length to make it
      easier to code with vectors in the future */
      
      //returns the angle in which a vector is facing...
      public function get angle():Number
      {
         /* first you have to normalise. If you know the vector is normal it's more
         efficient to directly call getAngleFromNormal */
         var normalisedVector:Vector2D = newVectorClone(this);
         if(normalisedVector.normalise()) return normalisedVector.getAngleFromNormalised();
         else return 0;
      }
      
      public function set angle(angle:Number):void
      {
         var temp:Vector2D = newVectorFromAngle(angle);
         temp.multiply(length);
         this.copyVector(temp);
      }
      
      /* The Point class already has a length property, but it's read only, and I
      want to be able to set it. The Point class has function called normalize()
      which will set it to any length, but that's just wrong! A normalised vector
      specifically has lengh 1, so I've written my own normalise function, and it's
      spelt correctly too! see http://mathworld.wolfram.com/NormalizedVector.html */
      public function set length(value:Number)
      {
         //see below for the normalise and multiply functions
         if (normalise()) multiply(value);
      }
      
      //getting the length squared is less espensive because it avoids Math.sqrt
      public function get lengthSquared():Number
      {
         if (x == 0 && y == 0) return 0;
         else return x * x + y * y;
      }
      
      //--------------------------------------------------------------------------
      //
      //  METHODS
      //
      //--------------------------------------------------------------------------
      
      // does anyone know if it's possible to override + * and = operands?
      
      /* add is already a function for Point - it produces a new Point, but here I
      just want to modify the current vector */
      public function addVector(vector:Vector2D)
      {
         x += vector.x;
         y += vector.y;
      }
      //Point has a function offset(x:Number, y:Number). Plus is just for two vectors
      
      public function multiply(factor:Number)
      {
         x *= factor;
         y *= factor;
      }
      
      /* Again, Point already has an equals function, but it's used for comparison as
      opposed to assigning values... */
      public function assignValues(x:Number, y:Number)
      {
         this.x = x;
         this.y = y;
      }
      
      public function copyVector(vector:Vector2D)
      {
         x = vector.x;
         y = vector.y;
      }

      //dot multiplication used for getting projection and whatnot
      public function dot(vector:Vector2D):Number
      {
         return x * vector.x + y * vector.y;
      }
      
      //I'm only writing this because I can't override clone()
      public function cloneVector2D():Vector2D
      {
         return new Vector2D(x, y);
      }
      
      //sets vector length to one, or returns false if the vector is 0 length
      public function normalise():Boolean
      {
         if (!(x == 0 && y == 0))
         {
            var vectorLength:Number = Math.sqrt(x * x + y * y);
            x /= vectorLength;
            y /= vectorLength;
            return true;
         }
         else
         {
            return false;
         }
      }
      
      //returns the angle in which a normalised vector is facing...
      //stupidly long name, but it's logical and I can remember it
      public function getAngleFromNormalised():Number
      {
         /* look up acos and asin to learn how this works... it's all fun with
         trigonometry! */
         var temp:int;
         Math.asin(-x) > 0 ? temp = -1 : temp = 1;
         var radians:Number = Math.acos(-y);
         return (radians * 180 / Math.PI) * temp;
      }
   }
}

Right, so now we want to check that all these functions work. So in the SpaceGame.as file I make some Vector2Ds and call their methods, then trace the results to see if they are as they should be. They are! Wahooo! I've commented the trace results but feel free to check it out yourself...

//THE DOCUMENT CLASS
package
{

   import flash.display.*;
   import flash.events.*;
   
   import ships.Ship;
   import Maths.Vector2D;
   
   public class SpaceGame extends MovieClip
   {
      /*this will allow other classes to access the instance
      of the document class created at the beginning of the game */
      private static var _instance:SpaceGame;
         
      public static function get instance():SpaceGame
      {
         return _instance;
      }
      
      public function SpaceGame()
      {
         _instance = this;
         
         var myShip:Ship = new Ship();
         addChild(myShip);
         
         //testing Vector class:
         
         //testing constructors
         var vector1:Vector2D = new Vector2D();
         trace("Basic constructor: "+vector1); //calls the Point toString() function which returns (x=0, y=0)
         
         var vector2 = new Vector2D(3,-4);
         trace("Vector 2: "+vector2); //(x=3, y=-4)
         trace("Vector2 length: "+vector2.length); //5. basic Pythagorus at work here
         trace("Vector2 length squared: "+vector2.lengthSquared); //25. Yup. that's 5 * 5
         
         vector1.assignValues(0,3);
         trace("Vector1 assigned values: "+vector1); //(x=0, y=3)
         
         vector1.addVector(vector2);
         trace("vector1 += vector2: "+vector1);
         
         vector1 = Vector2D.newVectorFromAngle(45);
         trace("normalised vector at 45 degrees: "+vector1); //(x=0.7071067811865476, y=-0.7071067811865475) - remember this
         
         vector1 = Vector2D.newVectorClone(vector2);
         trace("vector1 constructor copying vector2: "+vector1); //(x=3, y=-5)
         
         vector1.assignValues(0,2.3456);
         vector1.length = 6.0;
         trace("vector1 assigning length to 6: "+vector1); //(x=0, y=6)
         
         vector1.multiply(2);
         trace("vector1 * 2: "+vector1);
         
         vector1.angle = 45;
         trace("vector1 angle assigned to 45: "+vector1); //(x=8.485281374238571, y=-8.48528137423857)
         trace("vector1 length: "+vector1.length); //12
         trace("vector1 angle: "+vector1.angle); //45.00000000000001
         
         vector1.normalise();
         trace("vector1 normalised: "+vector1);//(x=0.7071067811865476, y=-0.7071067811865475) - remember from earlier?
         trace("vector1 lenght: "+vector1.length); //1. The distance a normalised vector should be :-D
         
         trace("vector1 dot vector2: "+vector1.dot(vector2)); //4.949747468305833
      }
   }
}

Great, we have a lovely new Vector2D class, so its time to use it, right? We want to make this damn ship move, no? That'll be for the next tutorial!

Tutorial 3 part 2 - writing the HumanPilot class and making the ship rotate (finally!)

2009-01-04T09:56:00.000-08:00

Ok, we now want to make a HumanPilot class, which will set the commands depending on the keyboard input from the user. Here's what we write:

//HUMAN pilot CLASS - takes keyboard input and sets commands for ship controlled by pilot
package pilots
{
   import flash.events.*;
   import ships.*;

   public class HumanPilot extends Pilot
   {
      private var _commandLeft:Boolean = false;
      private var _commandRight:Boolean = false;

      public function HumanPilot()
      {
         super()

         SpaceGame.instance.stage.addEventListener(KeyboardEvent.KEY_DOWN, keyDownHandler);
         SpaceGame.instance.stage.addEventListener(KeyboardEvent.KEY_UP, keyUpHandler);
      }

      public function keyDownHandler(event:KeyboardEvent)
      {
         if(_ship != null) //ship could be null, in which case we want to avoid errors...
         {
            //Handle rotation:
            if (event.keyCode == 65) _commandLeft = true; //A
            if (event.keyCode == 68) _commandRight = true; //D

            processCommands()
         }
      }

      public function keyUpHandler(event:KeyboardEvent)
      {
         if(_ship)
         {
            if (event.keyCode == 65) _commandLeft = false; //A
            if (event.keyCode == 68) _commandRight = false; //D

            processCommands()
         }
      }

      public function processCommands()
      {
         _commandRotation = 0;
         if(_commandLeft) _commandRotation = -_ship.turnRate;
         if(_commandRight) _commandRotation = _ship.turnRate;
      }
   }
}

The important thing here are the words “extends Pilot”. This means that the HumanPilot class is actually a Pilot class, but with a few things attached. So HumanPilot class already has the _commandRotation and _commandThrust variables, and we don't need to write them again.

In the HumanPilot constructor, we have the function super() - this just calls the parent class's constructor (which in the case of Pilot doesn't do anything).

But Why use inheritance?

Well other Pilot types (namely the AI ones) will also be using Pilot functionality (so the command variables are shared, but so are certain functions, such as selectNearestEnemy() or reassignTarget() etc.). If I write a selectNearestEnemy() function in the Pilot class, I don't have to paste the same function into all the other classes that will be needing it.

The problem with inheritance is that it breaks encapsulation – now HumanPilot is dependent on Pilot, so I have to take both classes into account when I'm working on them. So if one day I realise that Pilot should take an argument in its constructor, I will have to modify the super() function calls in all the classes that inherit from Pilot. This is the kind of extra work which well-designed OOP should help us avoid. But sometimes inheritance is the obvious solution – if you have many different classes that all share the same core of functionality, inheritance is probably the way to go. (The link I provided about inheritance and encapsulation is a really nice explanation of OOP for stupid people like me).

In "the biz" (I just made that up, real programmers don't say that) referring to relationships between classes we talk about "is a" or "has a". A dog "is a" mammal, so the class Dog would extend the class Mammal. That's easy. But a car "has" wheels - there wouldn't be inheritance there. This is clear but there are murkier examples.

For instance, what about a wheel? A wheel "is a" circle, right? I'd disagree. It has a circle shape. But it has a lot more functionality and uses than a circle. So the relationship between wheel and circle would be a "has a", I think (the circle would be the visual variable, or the collision detection variable within the wheel class). It hurts my head to think about it sometimes.

So back to the HumanPilot class. I've added two more variables, Booleans this time: commandLeft and commandRight. This is because of the fact that we can't trust a human player (bloody stupid dolt that he/she probably is) only to press one of the buttons at time. This input is then processed in the "processInput()" function into something the ship class can read easily (in this case, an angle).

So we have a function which is called whenever a key is pressed, then another function which is called whenever a key is released. It takes as its argument a KeyboardEvent - this is what is passed from the event listener on the stage to the function that deals with it. Inside the KeyboardEvent I can access the variable keycode, which is ASCII code for the key pressed by the user. I've decided to use the codes for A and D to deal with rotating the ship.

This will set the _commandRotation to the angle at which the ship is to be rotated.

I've set the angle to the ship's turn rate, but where is that? In the ship class of course. Maybe I've broken encapsulation a little bit because the Pilot is accessing the Ship's turn rate (I just don't know anymore!). But seeing as I know all ships will have a turn rate, I don't think should lead to any problems (famous last words). The reason I've made the _commandRotation an angle, and not just a command (turn left, turn right) is that, especially for the AI player, there will be times that I'll need the ship to turn at less than its turn rate - it'll be clearer when we get there.

Anyway, look what I did for the keyboard input:

SpaceGame.instance.stage.addEventListener(KeyboardEvent.KEY_DOWN, keyDownHandler);

What is SpaceGame.instance? I hear you cry. Well, my SpaceGame.as file now looks like this:

//THE DOCUMENT CLASS
package
{

   import flash.display.*;
   import ships.Ship;
   import flash.events.*;

   public class SpaceGame extends MovieClip
   {
      /*this will allow other classes to access the instance
 of the document class created at the beginning of the game */
      private static var _instance:SpaceGame;

      public static function get instance():SpaceGame
      {
         return _instance;
      }

      public function SpaceGame()
      {
         _instance = this;

         var myShip:Ship = new Ship();
         addChild(myShip);
      }
   }
}

I've created a new variable called _instance which is simply a pointer to the single instance (remember the difference between classes and instances) of document class SpaceGame created when the game starts. The variable is static, as is its “getter” function. A static variable is a variable which is accessed through the class definition, as opposed to an instance of the class. Wuh?

Let's go back to Plato and his horse. In any specific instance of a horse, for instance my imaginary horse Buttercup, we have several variables specific to that instance. So Buttercup's variables of position, hair-colour, speed, strength, cuteness, affinity to kicking people in sensitive areas are all specific to her. But if I think of the ideal horse, the blue-print for all other horses (the class definition) then there are certain variables that are true to that class, and can be accessed through the ideal as opposed to a single instance. Variables such as class = mammal, diet = herbivore, inspirationForBadTeenageGirlArt = true. So instead of accessing Buttercup.diet I'd go straight to Horse.diet. I'm sure you didn't bother reading that paragraph. I wouldn't have.

Anyway, this means I can access the “get” function for _instance directly through the class definition of SpaceGame. Access simply points to the instance of the game created in the SpaceGame constructor (that's what “this” refers to). I can do this because there will only ever be one instance of the class SpaceGame, but its a bit weird - I'm accessing the instance through the class definition. urgh...

So from any other class, I can now type SpaceGame.instance and be accessing the document class SpaceGame. And remember what we did before? We accessed the stage through the document class. All this leads to the rather convoluted way of accessing the stage: Spacegame.access.stage. If there's a better way of doing this, please inform me!

The nice thing about this is that the HumanPilot class has its event listeners assigned from within its constructor, and I don't need to apply them from anywhere else.

Anyway, we saw in the HumanPilot class that I was setting _commandRotation to the ship's turn rate. So let's have a look inside our Ship class:

//SHIP CLASS - controls ship attributes and movement
package ships
{
   import flash.display.*;
   import flash.events.*;
   import pilots.*;

   public class Ship extends Sprite
   {
       //SHIP ATTRIBUTES
      private var _turnRate:Number = 300.0/25.0;

      private var _shipImage:MovieClip;

      private var _controllingPilot:Pilot;

      public function get turnRate():Number
      {
         return _turnRate;
      }

      public function Ship()
      {
         _controllingPilot = new HumanPilot();
         _controllingPilot.ship = this;

         _shipImage = new blueLightFighterImage();
         addChild(_shipImage);

         x = 275;
         y = 200;

         addEventListener(Event.ENTER_FRAME, updateShip)
      }

      public function updateShip(event:Event)
      {
         rotation += controllingPlayer.commandRotation;
      }
   }
}

In the ship class, I have a variable called currentPilot. Current because every ship will automatically have an AIPilot assigned to it (we'll be programming that in a later tutorial), but depending on what happens within the level, that AIPilot might be overridden by the player, or by a puppet master. For now, we're just going to create a HumanPilot and have it be the ship's pilot. Notice that we have to set the HumanPilot's _ship variable because it doesn't have one by default (the setter allows us to do this, even though the _ship variable is protected).

We also have a private variable called _turnRate. This will be set when the ship is created, but not modified later (though who knows? We might find a need for that later). So it was a "getter" but no "setter". This is the value by which the ship turns in a single frame. I've written it as 300.0/25.0 because it's easier for me to understand – that means 300 degrees per second (25 frames per second – remember we set that frame rate earlier in this tutorial?). The .0 is because of the convention for denoting Numbers literals.

There are certain things the ship will do every frame, such as move or rotate, so we're going to have an updateShip function which is called every frame (done with an event listenener again - Event.ENTER_FRAME can be accessed anywhere, not just from the stage). We need to keep this function as simple as possible, because it will be called for every ship 25 times a second. No expensive equations here, please.

So far, all we're doing in the update ship is rotating it depending on the command being sent by the currentPilot (in this case, the user). We simply add the value of shipPilot.commandRotation to the ship's rotation.

When you test your movie, however, you might notice that the A button doesn't register. This is because it is a flash keyboard shortcut that selects some tool or another. You have to go to the control menu and select "Disable keyboard shortcuts". Then it should work, and you'll have something that hopefully looks like this:

press A and D to rotate the ship

Isn't that ridiculously exciting?

What we really want is to have the ship flying around, but before we can do that we need to program a very useful, if slightly technical (read boring) tutorial. For most movement in this game we're going to use 2D vectors (remember those? Wish you had listened in Maths or Physics now?). Those will be the subject of our next tutorial…

Tutorial 3: getting user input and making the ship rotate. Creating a pilot class, and having fun with inheritance!

2009-01-04T03:57:00.000-08:00

So we have a ship on the screen, big whoop-di-doo. We want this thing to actually react to our input, right? By the end of this tutorial we should have this:

press A and D to rotate the ship. Oh and click on the flash file for it to become active

So, here's how we're going to do it...

First of all, if we're going to get things moving in this game, we need to decide how. I like things nice and smooth, so in the spaceGame.fla file I set the frames per second to 25. Also, I'm not going to bother having the game work in real time – so if the computer is slow, the game is slower too. This isn't very professional of me, but I'm doing it to allow me to have complete control over how things move, allowing for simpler collision detection and other such things later on.

In AS3, we get user input by adding special Event Listeners to the stage. In a later tutorial I'm going to go into great detail on event listeners and dispatchers (when we start to create our own ones, that is), but for now we'll just look at how they are used to get keyboard input.

So the stage, as far as I can tell, is the main MovieClip which all the visual elements of the game reside in. It's here that we'll be “listening” for key-strokes. To do this we use the addEventListener function. We need to add the event listener to the stage, and it will happily sit there waiting for keyboard input. Once that input arrives, it will then call the keyDownHandler() function within ship, so within the Ship class we might have the line:

stage.addEventListener(KeyboardEvent.KEY_DOWN, keyDownHandler);

But unfortunately in AS3 you can only access the stage from an object which has been added to the display list. So, if we write this in the ship class:

//THE SHIP CLASS
package ships
{
  import flash.display.*;
  import flash.events.*;

  public class Ship extends Sprite
  {
     private var _shipImage:MovieClip;

     public function Ship()
     {
        //add event listener to stage
        stage.addEventListener(KeyboardEvent.KEY_DOWN, keyDownHandler);

        _shipImage = new blueLightFighterImage();
        addChild(_shipImage);

        x = 275;
        y = 200;
     }

     //function to be called whenever event listener detects user input
     public function keyDownHandler(event:Event)
     {
        trace("I have pressed a key!");
     }
  }
}

We get this error:

TypeError: Error #1009: Cannot access a property or method of a null object reference.
  at ships::Ship$iinit()
  at spaceGame$iinit()

This is because the Ship hasn't been added to the display list (as in, we haven't called addChild(myShip) yet), and it has no access to the stage. Also, notice that to be able to use addEventListener() I've imported flash.events.*. Again laziness with the wildcard...

Also, I've started commenting my code. You really want to do this, even when you work on your own - I've often hated/loved my former self based on how much information I had decided to leave me about the weird stuff I'd programmed.

So what do we do?

Well, the document class (defined in SpaceGame.as) has access to the stage, so we could add keyboard event listeners from the document class to the Ship class...

//THE DOCUMENT CLASS
package
{
  import flash.display.*;
  import ships.Ship;
  import flash.events.*;

  public class spaceGame extends MovieClip
  {
     public function spaceGame()
     {
        //create new ship
        var myShip:Ship = new Ship();
        //add event listener to stage which calls function within myShip
        stage.addEventListener(KeyboardEvent.KEY_DOWN, myShip.keyDownHandler);
        //add ship to display list
        addChild(myShip);
     }
  }
}

And now it works! Whenever the eventListener detects a key-press on the stage, it calls the keydownHandler function in myShip. So far, all this does is trace an asinine message.

yes, dear, very good

But this is really awkward, as it would oblige me to write three lines every time I create a ship:

 
  allShips[i]  = new Ship();
  addChild(allShips[i]);
  allShips[i].addEventListeners();

Yuk. This is pretty much the way I did things Before the Tragedy (BT) but it's crap. The whole point of OOP is that I don't have to think about this nonsense...

Anyway, this is not how I want to do things – the ship isn't going to be the entity which detects key-strokes from the user. This is why:

We need to think about things in an object orientated way. The ship is just an automaton, a machine with certain attributes and behaviours, but it doesn't think for itself. Just like their real-life counterparts, these ships need a pilot to handle them. So that's what we're going to do: create a pilot class.

Why is the Pilot class separate from the Ship Class? In this game there will obviously be the human player controlling a ship, but several other ships controlled by the computer. The point is that the ship doesn't care who is controlling it. Whether it's an AI pilot or a human telling it to turn left, the effect is the same. So by separating the entity giving the commands and the entity responding to the commands, we're keeping things simple.

Similarly, the Pilot class will never directly modify the ship class. It will only give commands, which the ship can ignore or process.

There are going to be several different pilot types. Obviously there is a person playing the game, but also the AI Pilots, of which there will be several types depending on what ship they're controlling (FighterAIPilot, CarrierAIPilot, ArtilleryAIPilot etc.). There might also be a PuppetMasterPilot used for cut scenes, or background ships…

Each of these can pass commands to the ship they control – turn, thrust, fire, select next enemy and so on – but the way these commands are decided differs for each one. Here's a good situation in which to use inheritance. We'll have one base class Pilot which is the one core of functionality all Pilots share, then several classes that extend this class with their own specific attributes and methods. The end result will always be a simple list of commands to be sent to the ship.

First we need to create the Pilot class. Once again I'm going to start by making it a package, so I've got a new directory called pilots, and inside a new .as document called Pilot.as, and write the following code:

//PILOT CLASS - sets commands for ship under pilot control
package pilots
{
  import ships.*;

  public class Pilot
  {
     //pilot can never modify attribute of Ship, only pass commands
     //The available commands:
     protected var _commandRotation:Number = 0.0;
     protected var _commandThrust:Boolean = false;

     //The ship being controlled
     protected var _ship:Ship;

     public function get commandRotation():Number
     {
        return _commandRotation;
     }

     public function get commandThrust():Boolean
     {
        return _commandThrust;
     }

     public function set ship(ship:Ship):void
     {
        _ship = ship;
     }

     public function Pilot()
     {
     }
  }
}

So we have a class that doesn't do much at the moment. All we have are two private variables that define commands given by the player: _commandRotate and _commandThrust. They are protected, which means only this class and its children can access them, but I do want the ship to be able to read these commands, so I make "getter" functions. This means that within the ship class I could write:

Rotation += myPilot.commandRotate;

And this will work, even though _commandRotate is protected. But because I haven't written a "setter" function, the following line from within the ship class would cause an error:

myPilot.commandRotate = 5.0;

I only want Pilot classes to be able to change the command variables. But notice I have written a "setter" for the _ship variable. This will be particularly useful for the HumanPilot and PupperMasterPilot classes because they will jump in and out of ships at will, but certain things need to be done to keep the game from breaking. At the moment the setter doesn't do much, but some extra functionality will be added later.

If you're confused about the whole getter setter thing there're lots of tutorials online. Unfortunately though, my inadequacies as a programmer come out once again as it turns out that getters and setters break the all important encapsulation which I think one day I might begin to understand. Whatever. Let's make a game. But this is getting on a bit so I'll divide this tutorial into two parts...

On to part 2!

Tutorial 2: making a ship appear on screen. Packages and classes revisited (yay!)

2008-12-30T06:04:00.000-08:00

Ok, that first tutorial wasn’t so much a tutorial as lots of me talking. Let’s get something up on the screen.

First of all, organisation. I want to make a ship, and I know that I’ll be making several different ships, so let’s create a new package. Again, my creativity abounds as I decide to call this package “ships”. So, how does this work?

Well, in my spaceGame directory I create a new directory called “ships”. Therein I’ll create a new actionScript file called “Ship.as”.

Inside the actionScript file I’ll write the following:

package ships
{
  import flash.display.Sprite

  public class Ship extends Sprite
  {
     public function Ship()
     {
        trace("hello world!");
     }
  }
}

Notice the capitalisation – it’s important. To keep things consistent, I’ll be starting class names with a capital letter, and instance names with a lower case one (I believe this is the convention). What’s an instance? Read on…

So now I’ve written “package ships”. When it comes to compiling, Flash will look for a directory called “ships” whenever this class is imported from another file. How do we import from another file? Well, back in our SpaceGame.as file we’ll replace the code with this:

package
{
  import flash.display.MovieClip
  import ships.Ship

  public class SpaceGame extends MovieClip
  {
     public function SpaceGame()
     {
        var myShip:Ship = new Ship();
     }
  }
}

So what has changed? Well, as well as importing the MovieClip class, we’re now importing our own new class called Ship, from the package “ships”. Then, within the SpaceGame constructor we’re going to make a new variable.

var myShip:Ship = new Ship(): variables can be all sorts of things – hopefully you should know what they are already… things like integers, Numbers, Arrays etc. Well, instances of a class are variables also, and here we’re declaring a new variable, called “myShip” (but it could be called anything: “myShip27”, “i”, “Jennifer”) and it is of type “Ship” (the class we’ve just written).

The command new Ship() means that we create an instance (a specific individual as opposed to a general definition) of the class Ship, and this will run the constructor of class Ship – which in this case just means tracing “hello world” again. If we run it, hopefully nothing will have changed since the last version.

Great Awoogamuffin, I hear you say, what was the point of that? Well, I just wanted to show how to organise the code using packages and whatnot. Let’s actually make a ship, yeah?

The fun bit is next – design a ship. Here’s where flash comes into its own – you create a new symbol (movieClip) in the flash document and do whatever you want with it – you could make it animated or just a simple image. I’m going to keep things simple because in the end I want to have loads of these things flying around.

notice that I've created a folder within the library for all my ship images. I'm well organised.

This is my little blue fighter ship, so I’m going to call it blueLightFighterImage. The “Image” part of the name is because this MovieClip is not the actual ship, just the visual representation of it.

I won’t go into detail on the drawing and animation aspects of this game – there are plenty of resources online to help you with that – this blog is predominately about programming. But I am going to tell you that in the properties panel for your newly created ship MovieClip, you need to tick the box that says, “Export for ActionScript”. This means that now the ship Image symbol is a class you can use within your code.

notice that you can select what the Base Class is... this is useful if you want to create something which doesn't need a timeline (such as a Sprite or Shape - these are easier on the memory). I'm keeping this image as a movieClip because I'll need the timeline for things like animating the ship exploding, or for more complex ships that change their state - like aggressive to defensive or something awesome like that

[note - as of tutorial 6 some aspects have changed - the blueLightFighterImage is now a sprite, and we have to uncheck the "export on first frame" option. All is explained in tutorial 6. Things change, I guess]

Now let’s go back to the Ship class. We’re going to make it more ship-like (as in, it’s functionality will not be limited to the admittedly unimpressive “hello world”). The ship class extends Sprite, which means it has a position, rotation, and can have other objects added to it. Ultimately, our ship will have all sorts of attributes, such as maximum speed, acceleration, turn rate, ammunition etc.

But first of all we want to attach the image of a ship we made earlier. So now the ship class is going to look like this:

package ships
{
  import flash.display.*;

  public class Ship extends Sprite
  {
     private var _shipImage:MovieClip;

     public function Ship()
     {
        _shipImage = new blueLightFighterImage();
        addChild(_shipImage);

        x = 275;
        y = 200;
     }
  }
}

A few small differences here – let’s have a look at what’s going one.

First of all, I’ve been lazy, and written import flash.display.*. I believe they call the asterisk the wildcard or something (by “they” I mean real programmers), which is to say that it represents everything and anything. In this case it means importing every class in the flash.display package. Strictly speaking you should only import the specific classes you need to avoid confusion involving scary things like namespaces and other things I daren’t read about for fear of getting even more confused on the subject than I already am.

Luckily, we’re just writing a game, and not an incredibly flexible, re-usable framework (they talk about this in the intimidating wikipedia entry on design patterns). I feel guilty and pathetic, but I’m lazy so nyah!

Anyway, we now declare a variable before the constructor.

private var _shipImage:MovieClip: “private” is an access modifier (this link has a nice metaphor involving beer), and it means that access to this variable is restricted to this particular class. The underscore before the name is a naming convention (as far as I can tell) for all variables that are not public. I’ve read a few confused accounts on the internet explaining why this convention exists, but nothing of the blinding clarity needed for me to understand. If anyone reading this wishes to educate me, please do!

Anyway, this _shipImage variable is of the type MovieClip. We then call new blueLightFighterImage() which means we're making an instance of the symbol we created earlier within the spaceGame.fla file. Now, for this to actually appear within our Ship class we need to call addChild() which is a function within the flash.display.displayObject class (hence my importing everything out of sheer lethargy). All visible objects in Flash inherit from displayObject (I think). Now our blueLightFighterImage is visible in the Ship class.

I also set the Ship x and y values (these are inherited from the Sprite class) to 275 and 200 so that the ship appears at the centre of the screen ([0,0] is the top left corner in Flash – I know, that's weird. In flash, y increases as you go down, unlike all those Cartesian maths you did at school. I think Adobe just wants to screw with our heads).

But if we run the game now, we still don't see the ship! That's because we also need to add the myShip instance we created in SpaceGame.as to the display list. So now in the SpaceGame.as class we should add the following:

package
{
  import flash.display.*;
  import ships.Ship;

  public class SpaceGame extends MovieClip
  {
     public function SpaceGame()
     {
        var myShip:Ship = new Ship();
        addChild(myShip);
     }
  }
}

Notice I've also been lazy and wild-carded the import statement; that's because the displayObject class is needed for the addChild function, so let's just import everything and hope something fits...

Now run the game, and we should have a spaceGame.swf file that does this:

Yes, that's right. Absolutely nothing. On to tutorial 3!

Tutorial 1: Where do I start?

2008-12-29T03:45:00.000-08:00

First of all, I highly recommend you discretely kill off a rich relative and leave yourself on the will so as to be able to afford Flash CS3 (or whatever the latest version is once you read this). It’s relatively expensive, but it’s cool, yeah?

Now a lot of the tutorials online show you how to program a game by inputting AS3 code into the timeline of the main MovieClip. This is an excellent way of programming if you like getting horrifically confused and frantically clicking on different frames to figure out where the hell your code has gone. The big problem with this way of programming is that the bigger the game, the harder it is to expand it, so it’s only really useful for small games.

No, in my game, no code will appear on the main timeline. There might be the odd bit of code within specific MovieClips, but the idea is that each entity within the game should be more or less self-contained. This way, we can add functionality to the game all we want without making it more difficult to manage. This is the whole point of Object-Oriented programming, as far as I can tell. They like to use words like “encapsulation” but I’m going to avoid that type of jargon, mainly because I’m not entirely sure how to use it.

Where do we put the code?

The first thing we’re going to do is create a new Flash document. Now I’m making a game set in space, so I’m going to create a new folder called “spaceGame” (I’m creative like that). Then I create a flash document called, you’re never going to believe this, “spaceGame.fla”. Right, just to emphasize my point about not putting code within the timeline, I’m going to delete the one frame they put there for you.

So now what? How does the flash document know what code to run? Well, start off by creating a new actionScript file. Once again my creative genius will shine through in my naming abilities. I dub it “SpaceGame.as” and it shall be saved in the same folder as “spaceGame.fla”.

Now back in the fla document, in the properties panel for the document see that down there at the bottom right? Document class. This is the class the document opens right at the beginning – so write “SpaceGame” in that space.

As we go on in this exciting adventure, I’m going to talk an awful lot about classes, but for now let’s just write some code, and I’ll get into greater detail later…

So within the “SpaceGame.as” document, we’re going to write the SpaceGame class. I want you to write the following:

package
{
   import flash.display.MovieClip

   public class SpaceGame extends MovieClip
   {
      public function SpaceGame()
      {
      trace("hello World!");
      }
   }
}

What does all that mean?

Sorry if you already know this stuff, but like I said my target audience is people who might know some programming stuff (if statements and whatnot) but not the way that flash AS3 is organised. These few lines are all important, so let’s look at them one by one…

Package: Packages are sets of classes that work together. So in this game I will have a “ships” package, which contains all the different types of ship classes. I’ll have a “userInterface” package that contains all the… you get the picture. Packages are just the folders you save the classes in, and seeing as this class is in the main folder, it doesn’t actually belong to a specific package (otherwise it would read “package ships” for example). More on both packages and classes later.

Import flash.display.MovieClip: aha! Remember packages? We require a specific class (MovieClip - our game is a special kind of flash movie clip), which is found inside the package "display" which is in the package "flash". Obviously these packages come with flash, but we can make our own packages in the future, and we will import classes from these packages in the same way as we did the MovieClip. All clear?

public: Now, if you were good and clicked on the wikipedia link for OOP (Object Orientated Programming) you probably got somewhat confused (unless you’re good at all this nonsense). Now the idea with this kind of programming is that we’re dealing with independent, self-contained objects, which then can communicate with each other. Public means that this class can be “contacted” by any other class from any other part of the program. More on this when I feel like it.

Class: aha! Hopefully, while you were reading the above you developed a strong urge to learn what on Earth a class is – it’s impossible for me to talk about packages etc. without talking about classes. So here goes. Take a deep breath.

Think about how we talk about the animal world – it’s divided into different classes (or kingdoms, branches, I don’t know). If we talk about a class of animals, we’re talking about a group of animals that share common attributes, as well as behaviour patterns.

The attributes, such as how many legs this class of animal has, or whether or not is has feathers, would be variables in AS3, and its behaviour would be defined by functions (behaviour such as fly(), attackOldPersonInPark(), throwUpOnCarpet() ). They have a nice example involving dogs in the wikipedia article on OOP.

So we define all these things in a class document, then from the class document we can create instances of the class, which is to say a specific individual, as opposed to a general definition. To clarify this idea further I’m going to use another animal metaphor. A very old animal metaphor. And I’ll stick in some Greek philosophy. It all applies to programming.

Remember when you studied Plato at school? If not, go to wikipedia NOW, because I’d like to think of my readers (if I ever have any) as a cultivated lot. Anyway, he wrote down lots of what Socrates said, including his idea that physical objects and events are mere reflections of a pure ideal. This is often illustrated with horses.

If you think of horses, there is in your mind the fleeting perception of the perfect horse. The horses we see around us are all linked, but also unique – different colour, size, behaviour and whatnot, but they’re definitely all horses, which is to say reflections of the ideal horse, that exists beyond the physical (metaphysics).

Now I think this is a misinterpretation of Socrates’ thinking – he wasn’t actually trying to describe reality – he had merely developed Object Orientated Programming 2500 years in advance. In his example, the ideal horse is actually the class Horse, whereas all the physical horses are instances of the class, as in “myHorse:Horse = new Horse(brown, short, fast, bad-tempered)”.

I hope that cleared all that up.

SpaceGame extends MovieClip: so the class is called “SpaceGame”, fine, that’s all good. Then “extends” means that the SpaceGame class has all the functionality of MovieClip, and we’re just going to add some more. So with a MovieClip we can jump between frames, we can add other MovieClips, we can apply transformations to it, and the same is true of SpaceGame. We say that SpaceGame inherits from MovieClip.

Public function SpaceGame(): so this function is public (as in, it can be accessed from anywhere) and the function has the same name as the class. This means that SpaceGame() is the constructor of the class; it is called automatically whenever a new SpaceGame class is created.

trace("hello World!"): the trace function is something we’ll be using from time to time – it will not be part of the final product, but will help us with debugging, or as a quick fix just to see if something has worked. As for “Hello World”, this seems to be a traditional programming opening line, and I like it because it makes me think that the application has just been born and wants to greet the world. Obviously you could replace “hello World” with “go eat your grandmother” but I’m not sure that would be the most auspicious start…

So now run your flash application (cmd + enter for macs) and hopefully you should have something that looks like this:

Now in your SpaceGame folder there should be a new document: “spaceGame.swf”. This is the final product- the thing you can send to your friends be email, or upload to your site. If you open it in flash player now you won’t get anything but a white square, but within the flash application you’ll get an output window saying “hello World”.

It’s alive!

Introduction - back up!

2008-12-29T03:37:00.000-08:00

Computer games are obviously lots of fun – but how often have you wanted to improve on one, or create an entirely new one? Have you tried? It’s bloody difficult…

This series of tutorials is intended for people with at least an inkling of how to program, but initially I’ll try to explain in great detail what’s going on – this is not so much a programming tutorial as an explanation of how to think about structuring a complex game in flash (or any object orientated language). There’ll be lots of code on display, though, which hopefully should help you discover the syntax of ActionScript 3 as well...

The internet is rife with information on AS3, so if ever you find yourself confused by something I’m doing, don’t panic – there’s the documentation within Flash, and a huge resource of information at your finger tips. Also, feel free to leave comments if you want something explained in greater detail.

“So why are you making these tutorials?” I hear you ask. Well, I’ve been thinking of sharing the fruits of my slow and painful journey of discovery for a while now, and recent events have forced my hand…

For a while I’ve been trying to make a sort of 2D space shooter game, but with a relatively flexible engine and therefore several different game-play variations. So with this as my template, I set out a year ago to figure out the complexities of flash. Bit by bit, my knowledge grew, and so did the game, until recently I found it excitingly close to completion. Then the tragedy occurred.

Firstly, here’s some context, so as to allow you to fully appreciate the extent of my idiocy. I have in my possession three 1 GB USB sticks. I have an external hard drive. Also, the entire game project was only a couple of megabytes big – enough to send myself as an email attachment without breaking a sweat. Have you guessed the tragedy yet?

Fuelled by sheer spite, my hard disk died on me. I think it just wanted to teach me a lesson for my procrastination. You understand, I always planned to back up my game, but my laziness always got the better of me. Some things are best learned the hard way. And this was hard!

So please, please, please back up. Programming is a lot of work, and the work you produce is so small it really isn’t difficult to back up your work. Then again, if you’re the sort of person who only really learns things the hard way, I definitely recommend you work on something for a year then pour water onto your hard drive or something. That’ll learn ya.

Also, I’m not a professional programmer – I’m a keen amateur, who received some training at university (I studied 3D animation) but I’m far from an expert. I will surely make mistakes, and I can only hope some people reading this can point them out, or inform me of a better way of doing things. These tutorials won’t teach you the perfect way of programming a game, but they should certainly help you get started on making a decent game – my target audience is me a year ago, basically.

Anyway, time to move on to actually writing a game. Time for tutorial number 1.