If a variable is a bucket that can hold one thing, an array is a superbucket that can hold many things.

The language you use determines what an array can hold. Certain languages will only let you put the same type of thing in your array superbucket – “this superbucket holds only screws”, or “this superbucket holds only issues of Playboy from 1972-1981″. Actionscript 3 lets you mix it up, putting anything you want in your array – including other arrays!

Creating an Array of Your Own

Let’s start simply. To get an instance (copy) of AS3′s built-in Array class that you can play around with, use the new keyword:

var myArray:Array = new Array();

This line of code means that we want to reserve a place in the computer’s memory to store something. The name of that thing is myArray. The type of that thing is an Array. We’re setting the value of that thing using the = operator. We use the new keyword to get a copy of the Array class, and specifying Array() is how we do it, building our new Array instance from the Array class’s constructor function. The semi-colon is like a period ending the statement.

Be sure to check out our Understanding Classes tutorials to learn more about constructor functions.

Once we’re done, we have an instance (copy) of the Array class called myArray that we can mess with.

Filling the Superbucket

Now that we’ve declared our array, let’s define it by adding some elements to it. We’ll throw in a few strings, which are datatypes surrounded by quotation marks.

myArray = ["wookie", "ewok", "sarlac"];

We use those square brackets a lot when working with arrays.

Now the array instance has three elements in it. They’re all string literals, but they could be a mix of things – numbers, ints (whole numbers), booleans (these are like lightswitches – on or off), or other arrays.

Peering Into the Superbucket

In order to find out what’s in our array, we use the name of the array followed by two square brackets, and the number of the element we want to know more about. A semi-colon ends the line, like so:

myArray[2];

Just typing that up won’t do anything, though. The Actionscript interpreter figures out the answer, and keeps it to itself. We need to use the built-in trace function to get Flash to report the value to us in the Output window.

trace(myArray[2]);

The answer is “sarlac”. Surprised? Arrays are zero-based, which means you start counting from zero. So element 0 is “wookie”, element 1 is “ewok”, and element 2 is “sarlac”.

Changing the Contents

If we wanted to put something at the end of this array, we could just be direct about it:

myArray[3] = "taun taun";

Now the array is four elements long: “wookie”, “ewok”, “sarlac”, “taun taun”. In fact, if we just trace out the name of the array, that’s what the Output window will report to us. Give it a try:

trace(myArray);

We can knock an element out and replace it with something else just as directly:

myArray[0] = "hutt";

By directly accessing element 0, we’ve knocked out “wookie” and replaced it with “hutt”. Poor wookie.

The Array Class and its Toys

The Array class gives us a bunch of goodies to play with. Like any class, it has methods (things that it does) and properties (things that it is or has).

Many of the Array class’s methods (things that it does) help us to put new things into the array at specific points, and pull things out of the array. Here are a few examples:

Array.pop(); removes the last element from the array
Array.push(); adds an element to the end of the array
Array.shift(); removes the first element and shifts everything back by one
Array.unshift(); adds an element to the beginning of the array and shifts everything ahead
Array.splice(); lets you specify an index point and a length so you can laser-cut elements out of an array and, if you wish, replace the removed elements with new ones. It’s like open-heart surgery for arrays.

One of the most commonly-used properties (things that it is/has) of an array is length, which just reports how many elements are in your array. So far, myArray.length is 4. You can see this by tracing out your array’s length property:

trace(myArray.length);

Notice that no round brackets are required. You need to use those round brackets for methods, not properties.

Using the Toys

So if we wanted to add a Gungan to our array (for some ungodly reason), we could use the Array class’s push method, like so:

myArray.push("gungan");

Now, myArray.length is 5 – “hutt”, “ewok”, “sarlac”, “taun taun”, “gungan”. Let’s get the wookie back at the beginning of the list by using the unshift method:

myArray.unshift("wookie");

Now, myArray.length is 6. Here’s what myArray looks like: “wookie”, “hutt”, “ewok”, “sarlac”, “taun taun”, “gungan”.

Performing Open-Heart Surgery on an Array

Finally, we’ll decide to get the ewok out of there using our surgical splice method. Splice wants to know where we want to start cutting, how many elements we want to remove, and which elements (if any) we want to insert into the array. Let’s keep it simple, and kill off the ewok for now.

The ewok is sitting at index 2, if we count from the beginning starting at zero. So we tell the splice method that we want to start hacking and slashing at index 2, for a total of 1 elements:

myArray.splice(2,1);

Now when we trace the array, the ewok is gone: “wookie”, “hutt”, “sarlac”, “taun taun”, “gungan”. (Note that when you actually trace out your array, the Output window leaves out the string quotation marks … i’ve left them in here to remind us that we’re working with strings, not variable names.)

What if we wanted to remove the hutt and the sarlac? We’d tell the splice command to start at index 1, which is where the hutt is, and remove two elements, like this:

myArray.splice(1,2);

That means “start at element 1, and remove two elements.” So our array is now “wookie”, “taun taun”, “gungan”.

Finally, we’ll use splice to get rid of that taun taun, and throw some invasive Star Trek races into the mix:

myArray.splice(1,1,"vulcan", "klingon", "tribble");

Now, we trace out the array and we get “wookie”, “vulcan”, “klingon”, “tribble”, “gungan”. That’s because we told splice to start at index 1 (which is where taun taun was), remove one element (namely, taun taun), and insert those three other species/races at the incision point. The transplant was a success, doctor!

How Does This Help Me Build Games?

Admittedly, this all seems pretty pointless when you don’t have a real-world code example. But arrays don’t really come to life until you learn one of the other basic programming elements: loops. In the next tutorial, Understanding Loops, we’ll break down the basic structure. Then in Understanding Loops with Arrays, we’ll see how they play together. Finally, i’ll throw you a few real-world code examples of how i use loops and arrays to code different pieces of my games that you can learn to use in your own projects.

For more Flash AS3 Tutorials and a pile of other useful stuff, check out our Flash and Actionscript 911 feature.

For Spellirium we had to develop a system that could determine the most efficient path between a series of nodes on a point. After some diligent research and careful consideration it became clear that the A* search algorithm was the way to go.

Now, I was familiar with the basics behind A* but had never actually implemented it. Thankfully though I had a copy of Keith Peter’s Advanced ActionScript 3.0 Animation which has a very nice chapter all about path finding and A*.

Before we begin, some prerequisite knowledge is required. In order to follow along with this you should have a knowledge of AS3 Classes and Interfaces. It is certainly possible to implement A* without knowledge of these concepts but in order to build a flexible, reusable solution, we will be using both. Check out our Understanding Classes in AS3 tutorials if you need help getting up to speed.

What is A* path finding?

According to the ever-so-useful Wikipedia, A* path finding can be described as:

(A) computer algorithm that (finds an) efficiently traversable path between points, called nodes…. A* uses a best-first search and finds the least-cost path from a given initial node to one goal node (out of one or more possible goals).

Sounds nice, but what does this mean? It means that A* chooses a node (or tile in a tile based world) searches through all the directly connected nodes and calculates a cost to travel to all of them. It then selects the node that has the lowest cost and uses it as the starting node for the next phase of the search. A* continues to do this until it reaches the destination.

To implement the algorithm it is first important to understand a few concepts:

• Node: This is a point along a path. In a tile-based environment you can think of it as a tile. The reason why we don’t call it a tile is because it can be used for non-tile based worlds. You will provide A* with a starting node and ending node. A* will then calculate all the nodes to get from the start to the end.
• Parent Node: When a node is tested in the algorithm all of its directly connected nodes (nodes that are traversable in a single step) are assigned that node as their parent. By doing so, we can easily work backwards through all of the parent nodes to create our path after we reach the destination node.
• Cost: Cost is assigned to each node based on two factors. Nodes with a lower cost are used over nodes with a higher cost. The two parts that make up the cost are: the cost to get to that node from the starting node and the estimated cost to get from that node to the end node. The cost of a node is usually expressed via 3 variables f, g and h.
• g: This is the cost to get to this node via the starting node. We know this value exactly because we can follow the parent nodes all the way to the start and add up their costs.
• h: This is the cost to get from this node to the final node. This value is estimated. It is not exact because we don’t know the path that we will take to get to the final node. Therefore we must estimate the cost and we do so using a function called a heuristic.
• f: This is the total cost of the specific node – it is calculated by adding g + h.
• Heuristic: This is the function that estimates the cost of getting from a particular node to the end node. The beauty of A* is that it supports a variety of heuristics, therefore you can try out different ones until you get the result you are looking for. Heuristic functions can differ based on their speed, efficiency and a variety of other criteria.
• Open list: This is a list of all the nodes that have been visited (in an iteration of the search) and have been assigned a cost. The node that has the lowest cost will be used to perform the next iteration of the search.
• Closed list: This is the list of nodes whose neighbors have been visited.

The Algorithm

Now that is out of the way we can move on to the actual algorithm. Before we actually begin coding, let’s just take a look at how A* actually works.

1. Provide a starting node and an destination node
2. Add the starting node to our open list (which should have been empty)
3. Start our search loop:
   • a. Pick the node currently in the open list with the lowest cost – we will call this node the current node. When we first run the loop this will obviously be our starting node.
   • b. If the current node is the same as the destination then we are done and we can move on to step 5.
   • c. Check every directly connected node. In a tile based world this would be up to 8 tiles. For our implementation we will provide a function that determines all the connected nodes. For each node that is connected:
     • i. If the node is not traversable (you can’t move to it because it Is occupied or for some other reason) or the node is already in the open list or in the closed list we can skip and move on to the next node in the list of connected nodes. Otherwise continue to ii.
     • ii. Calculate the cost of that node.
     • iii. Set the current node as the parentNode.
     • iv. Add the node to the open list.
   • d. Add the current node to the closed list.
4. Now return to step 3 (loop again) with the newly updated open list. (The loop should keep running until it hits the destination node)
5. We have found the destination node (hurrah!) Now we create a list of nodes that will be our path list and we will add the destination node to that list.
6. Add the parent node of the destination node to the path list.
7. Add the parent of the previous node to the path list, we will continue to do this until we have added our starting node.

We should now have a list of all the nodes that make up the best path from our starting node to our destination node.

The Implementation

Now that our theory is out of the way, let’s start writing some code. First we will start with our Node class. For this I will actually create an interface for your node:

public interface INode
{
	function get f():Number;
	function get g():Number;
	function get h():Number;
	function get x():Number;
	function get y():Number;
	function get parentNode():INode;
	function get traversable():Boolean;
	function set f(value:Number):void;
	function set g(value:Number):void;
	function set h(value:Number):void;
	function set parentNode(value:INode):void;
	function set traversable(value:Boolean):void;
}

This is a pretty straight-forward interface. It includes the variables for all the properties we discussed above (f,g,h and parentNode ). The other variables are fairly self-explanatory. X and Y obviously indicate the position of the node. We will use these values in our heuristic to estimate the cost of traveling from the node to the destination. The traversable variable is a simple Boolean that indicates if the node can be used in our path finding. If it is not then the algorithm will simply skip it when it is encountered. This is useful in a world where a node might be occupied by a prop (say a rock, tree or wall) or if there is another player/character occupying that space and you don’t want to support multiple characters on a single node. Implementing this in a class should be very easy.

Now we will build a class called Pathfinder. We will create the class only using static methods. Hopefully this will make it very flexible. It will not take much to turn this into a standard class but for our purposes static methods will do very well.

public class Pathfinder
{
	public static var heuristic:Function = Pathfinder.diagonalHeuristic;

Here, we define the heuristic function we will use to estimate the cost of traveling from a node to the end. In this example we will use the diagonal heuristic. At the end of this article, we will discuss some other heuristics and how to implement them.

Let’s move on to our actual path finding function:

public static function findPath(firstNode:INode, destinationNode:INode, connectedNodeFunction:Function ):Array 	{

Let’s examine the parameters:

• firstNode: INode – this is the first node in our path
• destinationNode: INode – The is the node that we are going to be traveling to
• connectedNodeFunction:Function – This is a function that will return an array of nodes that are connected to a given node.

Since each implementation might be different we abstract it out this way. After we write our class I will use a tile- based example to illustrate how this works, but your method might be different.

Lastly, the function returns an Array. This will contain all the nodes along the path.

Variable Setup

So now that is out of the way let’s do some initial work:

var openNodes:Array = [];
var closedNodes:Array = [];
var currentNode:INode = firstNode;
var testNode:INode;
var connectedNodes:Array;
var travelCost:Number = 1.0;
var g:Number;
var h:Number;
var f:Number;
currentNode.g = 0;
currentNode.h = Pathfinder.heuristic(currentNode, destinationNode, travelCost);
currentNode.f = currentNode.g + currentNode.h;
var l:int = nodes.length;
var i:int;

The first two arrays will hold our open nodes and our closed nodes. Then we have a variable currentNode which will keep track of the node we are currently on. We set this to be our firstNode since that is where we will start.

Next we keep a variable testNode:INode, which will be the node that will be a connected node of our current node.

Next we have g,h and f values we will keep track of for each node.

We then set the initial g value of the currentNode (which is also our first node) to 0 since it does not cost anything to get there since it is already our current location.

Then, we calculate the estimated cost to reach the end using our heuristic, and finally the final cost which is calculated by adding g + h (the starting cost plus the final cost).

Lastly, we have some variables that we will use inside of loops in our A* algorithm.

The Loop

Let’s move on to the actual loop.

while (currentNode != destinationNode) {
	connectedNodes = connectedNodeFunction( currentNode );
	l = connectedNodes.length;
	for (i = 0; i < l; ++i) {
		testNode = connectedNodes[i];
		if (testNode == currentNode || testNode.travesable == false) continue;
		g = currentNode.g  + travelCost;
		h = heuristic( testNode, destinationNode, travelCost);
		f = g + h;
		if ( Pathfinder.isOpen(testNode, openNodes) || Pathfinder.isClosed( testNode, closedNodes) )	{
			if(testNode.f > f)
			{
 
				testNode.f = f;
				testNode.g = g;
				testNode.h = h;
				testNode.parentNode = currentNode;
			}
		}else {
			testNode.f = f;
			testNode.g = g;
			testNode.h = h;
			testNode.parentNode = currentNode;
			openNodes.push(testNode);
		}
	}
	closedNodes.push( currentNode );
	if (openNodes.length == 0) {
		return null;
	}
	openNodes.sortOn('f', Array.NUMERIC);
	currentNode = openNodes.shift() as INode;
}

Whoa! There’s a lot going on there, so let’s try to break it down piece by piece.

while (currentNode != destinationNode) {

Start our loop. If our current node is the same as our destination then we are done and we can build our path!

connectedNodes = connectedNodeFunction( currentNode );
l = connectedNodes.length;
for (i = 0; i < l; ++i) {

So fetch an array of all of the connected nodes of our current node. Store the length and then loop through all of them.

testNode = connectedNodes[i];
if (testNode == currentNode || testNode.travesable == false) continue;

Test each node out of the connected nodes. If the node is the same as our current node or it is not traversable, move on to the next connected node.

Note: Your connectedNodeFunction might omit non traversable nodes which would make the above line redundant and unnecessary.

g = currentNode.g  + travelCost;
h = heuristic( testNode, destinationNode, travelCost);
f = g + h;

Ok, so now we are calculating the actual cost of our node. First, g:

g

In a tile based world, we simply add the cost of the currentNode to the travelCost to determine the cost of the tile. In some tile based environments, a diagonal move sometimes cost more than other moves. In this case you would need to determine if the testNode is diagonal to the currentNode and adjust the travelCost value accordingly.

In our case here at Untold, we had a situation where the cost of each connected node was not the same because the nodes could be spread out across variable distances. So in our case we changed the g calculation to use our heuristic between the currentNode and the testNode.

g  = currentNode.g + Pathfinder.heuristic( currentNode, testNode, travelCost);

Now, h:

h

This is where we use our heuristic. Our heuristic takes in our testNode and our destination node. We also supply the cost to the heuristic which will return a number. Again, we will go over the heuristic later.

f

Finally, we are at f. This is a straightforward calculation to determine the total cost of the node.

if ( Pathfinder.isOpen(testNode, openNodes) || Pathfinder.isClosed( testNode, closedNodes) )	{

Here, we use some simple utility functions to determine if the node is in either our open list or our closed list. If it is, then we should only adjust its f,g and h value if its current cost (f) is greater than the cost we just calculated.

	if(testNode.f > f){
		testNode.f = f;
		testNode.g = g;
		testNode.h = h;
		testNode.parentNode = currentNode;
	}else {
		testNode.f = f;
		testNode.g = g;
		testNode.h = h;
		testNode.parentNode = currentNode;
		openNodes.push(testNode);
	}

If the node is not in either the open list or in the closed list, then we definitely want to assign it the values we just calculated. We also want to add it to the list of open nodes and make sure its parent is set to our currentNode.

We are now done our loop and can add our currentNode to our list of closed nodes.

closedNodes.push( currentNode );
if (openNodes.length == 0) {
	return null;
}
openNodes.sortOn('f', Array.NUMERIC);
currentNode = openNodes.shift() as INode;

If there are no more open nodes, then no path is available between the provided nodes, so we return NULL.

Otherwise, sort our open nodes based on their cost and use the one with the lowest cost as our new currentNode.

If a path is available, the currentNode will eventually be the same as our destination node, and the while loop will exit. At this point, we will be ready to build our path and end our function which we do with a single line:

return Pathfinder.buildPath(destinationNode, firstNode);

Of course this means we need a function called buildPath(). Luckily, it is quite simple and looks like this:

public static function buildPath(destinationNode:INode, startNode:INode):Array {
	var path:Array = [];
	var node:INode = destinationNode;
	path.push(node);
	while (node != startNode) {
		node = node.parentNode;
		path.unshift( node );
	}
	return path;
}

In this function, we simply keep moving through all the parent nodes of the provided nodes and put them at the front of a new array we return to the caller.

The Heuristic

We are almost ready to test out our class with an example but as promised we will first discuss our heuristic.

There is a wide range of heuristics used to calculate an optimum path. The methodology is based on a variety of criteria. Different heuristics return different results and you will need to find the one that is best for your case. Right now, we’ll examine three simple heuristics, but don’t be afraid to go out and find your own.

Now, I was familiar with the basics behind A* but had never actually implemented it. Thankfully though I had a copy of Keith Peter’s Advanced ActionScript 3.0 Animation which has a very nice chapter all about path finding and A*.

Manhattan: This heuristic is the most simple. It ignores any diagonal movement, so if your world does not allow for diagonal movement it might be a good fit. It simply adds the total number of rows and columns between the two provided nodes.

public static function manhattan(node:INode, destinationNode:INode, cost:Number = 1.0):Number {
	return Math.abs(node.x – destinationNode.x) * cost + Math.abs(node.y + destinationNode.y) * cost;
}

Euclidian: This heuristic simply draws a straight line between the two provided nodes and returns its length. You might recall the Pythagorean Theorem from math class? Well, here it is in action.

public static function euclidianHeuristic(node:INode, destinationNode:INode, cost:Number = 1.0):Number {
	var dx:Number = node.x - destinationNode.x;
	var dy:Number = node.y - destinationNode.y;
	return Math.sqrt( dx * dx + dy * dy ) * cost;
}

Diagonal: This heuristic is the most accurate of the three. It is more complex than the previous two, but runs fewer times because of its accuracy. It takes into account a diagonal cost, if it is more expensive than a regular movement.

public static function diagonalHeuristic(node:INode, destinationNode:INode, cost:Number = 1.0, diagonalCost:Number = 1.0):Number {
	var dx:Number = Math.abs(node.x - destinationNode.x);
	var dy:Number = Math.abs(node.y - destinationNode.y);
	var diag:Number = Math.min( dx, dy );
	var straight:Number = dx + dy;
	return diagonalCost * diag + cost * (straight - 2 * diag);
}

Make it Go

Now that we are done with our pathfinding system, we can put it to work. Take a look at the example below. You can click on any two tiles in the grid and then we will then draw a path between the two tiles. You can change the heuristic at any point to see the different results you might get. Also highlighted are any tiles that the pathfinder tests. Notice that the Manhattan heuristic tests far more nodes than the other two.

I implement the pathfinding simply by calling the Pathfinder.findPath() function and passing the start node, end node and the function that determines connected nodes. I then pass the returned array to a function called drawPath. For your usage you probably want to do a lot more than draw a path, you probably want to have a character traverse along that path, but this is just meant to show you how to acquire which path to follow.

drawPath( Pathfinder.findPath(_startNode, _endNode, findConnectedNodes) );

The findConnectedNodes method is very straightforward. It simply returns all nodes that are adjacent to a given node. You can check it out here:

public function findConnectedNodes( node:INode ):Array
{
	var n:Node = node as Node;
	var connectedNodes:Array = [];
	var testNode:Node;
	for (var i:int = 0; i < _nodes.length; i++)
	{
		testNode = _nodes[i];
		if (testNode.row < n.row - 1 || testNode.row > n.row + 1) continue;
		if (testNode.col < n.col - 1 || testNode.col > n.col + 1) continue;
		connectedNodes.push( testNode );
	}
	return connectedNodes;
}

Of course, this implementation will not be sufficient if you want different tiles to have different costs based on terrain (quicksand might be more expensive than grass), but if you can grasp the above you should be able to make the adjustments fairly easily.

Hopefully you will now have a solid understanding of A* path finding and you can now use it in your own applications.

Click here to download the source code for this tutorial.

• none.

Begin

So you want to start creating games with Adobe Flash? Here’s the very first step.

You’ll need two pieces of software: Adobe Flash, and a program to in which to write your code. (Code is a list of instructions you give to the computer to make it bend to your steely will.) You can write your code inside the Flash program, but Flash is always playing catch-up with the great features available in other programs that make coding easier. And i like easy.

1. Download the Software

You can download a number of programs to help you code. The one we recommend (and use here at Untold Entertainment to create all our games) is called FlashDevelop. It’s free, but if you like it, consider tossing a few clams to the creators.

• Download a free 30-day trial of Adobe Flash
• Download your free copy of FlashDevelop (PC-only)

note: other popular programs that professionals use to create their code include FDT, Flash Builder (formerly known as Flex Builder), and even a fancy text editor like Notepad++. (i’m told that if you use a Mac, you’re iShitOutOfLuck on this front, but perhaps the commenters can recommend something?)

Once you’re finished downloading the two pieces of software you need, install them into the default directories, and we’ll get started setting up a project.

What is Flash?

The term “Flash” is confusing. You may have heard that some online video “is Flash”, that some games you play in the browser “are Flash”, that some websites “use Flash”, and more recently that Flash runs or doesn’t run on this device or that device. The word “Flash” is used interchangeably for both the authoring tool, the content that you create with it, and the plugin that displays that content to the end user.

The Adobe Flash software is also called an authoring tool, like a paintbrush or a table saw. With it, you produce Flash content (games, video players, websites, etc), which a person usually views in a web browser using a plugin called the Flash Player. Most often, when someone says you need to “download Flash”, he means you need to download the Flash Player plugin so that you can view Flash content that was created with the Flash tool. What you’re downloading in the link above is the tool, which is sometimes called the Flash IDE (Integrated Development Environment). i prefer “tool”, because it’s only one syllable, and “eye dee yee” is not kind to the ear.

2. Create and Save a New Actionscript 3 .fla File

When you open the Flash authoring tool for the first time, you’ll likely see a splash screen. To create a new file, etiher click “Create New Flash File (Actionscript 3.0)”, or go to File > New and choose Flash File (Actionscript 3.0) from the list, and click OK.

Your Flash file opens up and is displayed in all its glory – tons of interesting buttons and panels all over the screen. Don’t be intimidated. We’ll explore them in future lessons.

Click File>Save As in the menus. Flash files have the extension .fla. Change the name of your Flash working file to myFirstGame.fla (or whatever you like), and save it to a folder somewhere on your computer. Remember where you saved it! i recommend against saving it to the desktop – if you want it there, first create a folder on the desktop called MyFirstGame, and save your .fla file in there.

3. Create a New FlashDevelop Project

1. Open FlashDevelop.
2. In the menus, go to Project > New Project.
3. Choose a name for your project in the Name field. (You can call it MyFirstGame. Seems logical.)
4. Use the Browse button to point to the MyFirstGame folder you created, where saved your .fla file in the last step.
5. Click OK.
6. If you get a message saying “The directory is not empty …”, click OK to confirm.
7. If FlashDevelop asks you the Author name, type your own name or a suitable pseudonym, like “Cap’n CrackyPants”. All of the code you write will be signed with this name.
8. Click OK.

When you’re finished, check out the Project Panel, at the right side of the screen. (If you can’t see it, click View > Project Manager in the menus.) You’ll see your Project name, MyFirstGame. Then you’ll see the .fla file you created in Flash, called myFirstGame.fla. All of the code files you write to make your game will be listed here, along with any other files you place in the MyFirstGame folder.

Behind the scenes, FlashDevelop creates an .as3proj file in the folder, which is a metadata file that keeps track of what goes into the folder. Once you create your Project file, you never have to save it like you would most other files – you can just open and close different Project files, and they’ll list the stuff that’s in the folder with them.

4. Link FlashDevelop to Flash

The last thing to do is to make FlashDevelop aware of the Flash authoring tool so that the two can play nicely together.

1. In the menus, click Tools>Program Settings or press F10.
2. Click ASCompletion in the sidebar list.
3. Click in the field labeled “Path to Flash IDE”, and navigate to wherever you installed the Flash tool on your computer. On my Windows system, it’s here:

   C:\Program Files\Adobe\Adobe Flash CS4

4. Click the Close button.

Finish

That’s it – you’re done! Now you’re ready to create Flash content using the one-two punch combo of Flash and FlashDevelop.

So while i’m getting to know and understand the best practices of Object-Oriented programming, there are still some tried-and-true methods of finishing work more quickly that don’t obey strict OOP protocol. What follows is a list of pragmatic programming tips – ways to bend the rules, or to leverage the visual tools in the Flash IDE – to speed things up, and to make life easier.

Cheat #1: The Injection Method

The fact that the programming eggheads, the nerderati, have coined a term for this strategy means it can’t be all that bad. The injection method breaks one of the pillars of OOP – encapsulation – but it’s a Hell of a time-saver.

Let’s say you’re building an adventure game. You have an Inventory class and your MainGame class. When the player combines the “dynamite” inventory with the “hammer” inventory item, that action might trigger a death animation. The way you’ve built it, your MainGame class handles all death sequences.

According to the eggheads, the “right” way to do this is for MainGame to instantiate Inventory. In order for Inventory to talk back to MainGame, it should dispatch a custom event, which MainGame listens for:

public class MainGame extends MovieClip
{
    public function MainGame()
    {
          var inventory:Inventory = new Inventory();
          inventory.addEventListener(Inventory.DEADLY_ITEM_COMBINATION, playDeathSequence);
    }
 
    private function playDeathSequence():void
    {
           trace("You have died, because i'm a lousy game developer and i couldn't
                         think of a creative way to solve this situation without screeching
                          the game to a dead stop.");
    }
}

Here’s what the Inventory class looks like:

public class Inventory
{
    public static const DEADLY_ITEM_COMBINATION:String = "deadlyItemCombination";
 
    public function Inventory()
    {
          // Setup stuff goes here - etc etc.
    }
 
    public function combineItems(item1:Item, item2:Item):void
    {
           if(item1.itemType == "hammer" && item2.itemType == "dynaimte")
           {
                 dispatchEvent(new Event(DEADLY_ITEM_COMBINATION));
           }
    }
}

i find it a very time-consuming process to set this up, especially if you need a lot of communication between the two classes. The other asspain is that you can’t specify which deadly item combination triggered the death sequence. What if there is a special death sequence for any dynamite-related inventory screw-up, and a different sequence for any misstep involving the bagOSnakes item? Sure, you can set up some kind of custom event class, but that takes even MORE time, and you’re on a deadline.

With the injection method, you pass a reference to the MainGame class into the Inventory class. Then Inventory can invoke any public methods and properties on MainGame. It breaks encapsulation, sure, but like i said, you’ve got until Friday to make this work, and you probably won’t end up reusing your Inventory class anyway. (Certainly not NOW, you won’t ;)

Here’s how it looks:

public class MainGame extends MovieClip
{
    public function MainGame()
    {
          var inventory:Inventory = new Inventory(this); // pass , or "inject", a reference to the 
                                                                // MainGame class to inventory
    }
 
    public function playDeathSequence(typeOfDeath:String):void
    {
          // inventory calls this public method on MainGame when the time is right 
           if(typeOfDeath == "dynamiteRelated")
          {
               // Play the dynamite death animation
          } else if (typeOfDeath == "bagOSnakesRelated") {
               // Play the bag o' snakes death animation
          }
    }
}

public class Inventory
{
    private var main:MovieClip; // A reference to the MainGame class
 
    public function Inventory(main:MovieClip)
    {
         this.main = main; // Set the instance variable main to whatever's passed into the constructor
    }
 
    public function combineItems(item1:Item, item2:Item):void
    {
           if(item1.itemType == "hammer" && item2.itemType == "dynaimte")
           {
                 main.playDeathSequence("dynamiteRelated");
           } else if (item1.itemType == "bagOSnakes" && item2.itemType == "tickleFeather") {
                 main.playDeathSequence("bagOSnakesRelated");
           }
    }
}

Of course, with anything in programming, there are many ways to skin a cat. If you only ever have one Inventory in your game, you might even make it a static class. The eggheads are going to crucify me for my abuse of the injection method, but that’s alright – i’ve got six dirt-cheap preschool games to build by Friday. i welcome crucifixion with open arms, as it were.

Cheat #2: Dispatching Events from the Timeline

The architects of Actionscript 3 pulled kind of a dick move by rendering the timeline incredibly difficult to deal with. One of the best things about Flash was the amount of complicated graphics and animation stuff it did for you right out of the box, but AS3 robbed us of productivity by making us write a lot of code when we shouldn’t have to.

This disadvantage rears its ugly head when you need to wait for a MovieClip to finish playing its animation. One way to deal with this is to listen to the clip’s ENTER_FRAME or EXIT_FRAME events, and wait until it hits its last frame:

var groovyMovie:GroovyMovie = new GroovyMovie();
addChild(groovyMovie);
groovyMovie.addEventListener(Event.EXIT_FRAME, checkCompletion);
 
function checkCompletion(e:Event = null):void
{
	 if(e.target.currentFrame >= e.target.totalFrames)
	 {
		 // MovieClip has reached the end of its timeline.
	 }
}

That’s fine. But what happens if the clip contains a number of separate animation sequences? You can write a conditional statement inside the checkCompletion() method that looks at the currentLabel property, but that makes your code even thicker:

var groovyMovie:GroovyMovie = new GroovyMovie();
addChild(groovyMovie);
groovyMovie.addEventListener(Event.EXIT_FRAME, checkCompletion);
 
function checkCompletion(e:Event = null):void
{
         var clip:MovieClip = MovieClip(e.target);
 
	 switch(clip.currentLabel)
         {
                case "finishedJumping":
                     doSomethingAfterFinishingJumping();
                     break;
                case "finishedGyrating":
                     doSomethingAfterFinishingGyrating();
                     break;
                default:
                     break;
         }
}

Putting code on the timeline is dirty and bad. Occasionally, i’ll throw in some timeline events (gotoAndPlay(), stop(), etc) but that’s the extent of it. Except in this situation. In this sitaution, if it helps speed things up, i’ll advocate slipping in a dispatchEvent() action on the timeline.

On the salient frame of GroovyMovie:

dispatchEvent(new Event("finishedGyrating"));

And here’s our modified code from elsewhere:

var groovyMovie:GroovyMovie = new GroovyMovie();
addChild(groovyMovie);
groovyMovie.addEventListener("finishedGyrating", doSomethingAfterFinishingGyrating);

No more messy switch statement and – maybe the eggheads can confirm or deny this – i think the code may speed up, because you’re no longer checking that conditional statement every frame. (i’ve never cottoned on to the inner workings of the virtual machine, so if i’m wrong about that, feel free to nerdspank me.)

Cheat #3: Positioning Markers on the Stage

One of the most difficult things about AS3 for me, a visual person, is that i suddenly have to lay visual elements like buttons and text fields out in code, instead of on the stage. You get a lot more control over your elements when you manipulate them with code only, and some stuff just downright doesn’t work unless you work solely with code.

What i can’t stand is not knowing where things are going to end up on the stage. i start by positioning something:

widget.x = 173;
widget.y = 221;

Then i compile. When the code places my element on the stage, i soon see it’s off by a longshot. So i go back to the drawing board:

widget.x = 192;
widget.y = 237;

Compile. Check. Damn – this time, i’ve overshot the mark. i repeat this process – set x/y, compile, check, close swf – until it’s in the right place. And then i do the same with some other element. It’s aggravating.

i’ve found one of the fastest ways to cut through this is to create an empty MovieClip in your library and call it “Empty”. Drag it out to the stage where you want the code-created element to exist. Give it the instance name “marker”, or whatever. Then in your code:

widget.x = marker.x;
widget.y = marker.y;

Later, if you find out you got it wrong, don’t painstakingly tweak the numbers in code. Just grab the marker instance and drag it somewhere else on the stage. Step 4: profit.

Cheat #4: Stealing Color Effect Data

i hope i’m not the only one, but classes like ColorTransform confuse the heck out of me. ColorTransform takes eight arguments:

ColorTransform(redMultiplier:Number = 1.0, greenMultiplier:Number = 1.0, blueMultiplier:Number = 1.0, alphaMultiplier:Number = 1.0, redOffset:Number =0, greenOffset:Number =0, blueOffset:Number = 0, alphaOffset:Number = 0)

Whenever i need a specific outcome from the ColorTransform class, i put a MovieClip on the stage and adjust the Color Effect properties in the Properties panel. If you choose “Advanced” and play with the dials, you may notice that there are eight different parameters you can tweak. These eight params map onto the eight arguments that the ColorTransform class expects.

Here’s the corresponding code, taken from the numbers on the dials. The offset parameters are percentages, so remember to divide the first four offset numbers by 100 (just throw a decimal place in front of them):

var ct:ColorTransform = new ColorTransform(.29, .38, .33, .77, 82, 3, 72, 51);

It’s not exactly a “cheat”, but it does get around this notion that we need to fight tooth and nail to imagine everything through code.

Cheat #5: Guided Layers

This last one is also less of a cheat, and more of a way to get stuff out of codespace and into the more visual Flash environment.

If you’ve ever had to open another programmer’s code and Flash file, you may have been faced with a blank screen. All of the elements are linked in the library, but you don’t know where they’re supposed to go or how they’re supposed to appear without compiling the movie. And if you’ve been hired to fix an incomplete project and the fla won’t compile, you could be in for a world of hurt.

This is usually the path you follow to figure out how the file’s been built:

1. Check for timeline code in the first frame.
2. Check for a document class.
3. Check the library for linkage names to see what gets added to the stage dynamically

In order to be kind to Future-Me, or to anyone who inherits my code if i get hit by a bus, i use guided layers. If you put something on a layer, and then right-click the layer and hit “Guide”, that thing won’t show up when you compile. It’s MUCH friendlier to open up a file and see elements on the stage, so you get some idea of what’s supposed to appear in the file, instead of seeing a blank screen.

Important note: If you put code on your timeline (and in nearly all cases, you shouldn’t), your code will still fire even if you Guide out the layer that it’s on.

Speed Kills

So those are a few ways that i “cheat” by leveraging the Flash IDE or using “good-enough” practices instead of “best” practices to speed through tight timelines. Do you have any less-than-perfect strategies to get around writing mountains of code, or to make things easier on yourself? i’d love hear them!

“Fwitter”. Deal with it.

Our Pull Twitter Updates Into Flash tutorials (Part 1 and Part 2) continue to be popular! A few folks were asking how i had taken my Twitter feed and rigged it so that people’s Twitter names and links were clickable. i promised to write tutorials on demand, so here we go.

Clickify Your Twitter Feed in Flash

Here’s the process in pseudo-code:

1. Take the chunk of text and split it up into individual words
2. With each word, figure out if it starts with “@” or “http:”
3. If it does, wrap it in html tags
4. Re-assemble the string
5. Set the re-constituted string as your dynamic text field’s htmlText property

So, let’s start with a simple chunk of Tweet text:

“Hey everyone – @untoldent’s blog is INCREDIBLE! http://bit.ly/cXX06r”

Note: this is just a tweet i pulled at random from the Twittersphere. It could have been anything. But my blog is usually a trending topic at any given time of the day.

We’ve got two things we want to make clickable: @untoldent, which should link to untoldent’s Twitter user page, and http://bit.ly/cXX06r, which should take us to that webpage.

Splitting the String

The String class has a built-in method called split. It takes an argument that lets us carve a string up, and the resulting fragments are put into an array.

So, for example, if we have a comma-delimited string:

var fraggles:String = "Gobo,Mokey,Wimbley,Boober,Red";

we can split it using the comma as a separator. The resulting fragments are returned as an array.

var fraggles:String = "Gobo,Mokey,Wimbley,Boober,Red";
var aFraggles:Array = fraggles.split(","); // use the comma to split up the string
 
trace(aFraggles.length) // 5
trace(aFraggles[2]); // Wimbley
trace(aFraggles[4]); // Red

So in the case of our Twitter string, we want to split it up into individual words. The thing that separates one word from another is the space character. So let’s use space as an argument to split up that string:

var aWords:Array = twitterString.split(" "); // use the space character to split up the string

Note: the split method is slow, so use it sparingly. There’s not a lot going on in our Twitter reader, so we can get away with it.

Now let’s loop through each element in the aWords array – each word in the Twitter post – and determine if it’s a Twitter username (which starts with “@”), or a URL (which starts with “http:”). We’ll create an empty string to hold our final output, and run each word through a separate method.

var finalString:String = ""; // Create a new string to hold our final output
var len:int = aWords.length; // store the length of the aWords array to speed up our loop
 
// Loop through all of the words in our tweet:
for(var i:int = 0; i<len; i++)
{
    var word:String = aWords[i]; // Store an individual word in a variable
    finalString += " " + checkWord(word); // Run the word through a checkWord method, and tack the 
    // return value onto the end of our finalString (along with a space character, to space the words out)
}

Note: We’re storing the length of aWords in a variable, instead of saying i

Obviously, what’s missing is the all-important checkWord() method. Let’s build that next.

The checkWord() Method

Our checkWord() method is going to do this, in pseudo-code:

1. Accept a word
2. If the word starts with “@” or “http:”, wrap it in href tags and return the string
3. Otherwise, just return exactly what was passed in

To check if a string contains a certain other string, use the String.indexOf() method. indexOf() will return the place in the string where the other string first appears.

For example, let’s find the indexOf the capital letter “W” in the string “NSFW”:

var str:String = "NSFW";
trace(str.indexOf("W")); // 3

The answer is 3, because “W” is at index 3 in the string. (Remember that strings and arrays are 0-based – the first element is at index 0, the second element is at index 1, and so on.)

If the thing you’re looking for can’t be found anywhere in the string, the indexOf() method will return an index of -1:

var str:String = "NSFW";
trace(str.indexOf("pictures of adorable kittens")); // -1

Substring

The last thing you need to know how to do is to grab just a piece of a string. This is because the twitter name comes through with an @ symbol at the front, for example @untoldent. But we need to link to http://www.twitter.com/untoldent. Notice there’s no “@” in that URL.

We need to extract just the username from the string, without the “@”. We can use the String.substr (substring) method to do that.

The way String.substr() works is that you pass it a start point and an end point, and it rips that section out of the string and returns it.

So, check it out:

var str:String = "manboobs";
trace(str.substr(3,7))); // boobs

The letter at index 3 of “manboobs” is “b”. (Remember – we start counting at zero.) We rip the section out up to index 7, which is that last letter, “s”. So what’s returned are the letters from index 3 to index 7 – “boobs”.

If you want to rip out a chunk of your string from a certain index point to the last letter in the string, you can use the String.length property.

var str:String = "manboobs";
trace(str.substr(3,str.length))); // boobs

If you’re on high alert and paying really close attention, you’ll notice that str.length takes us one index point past the end of our string. (“manboobs” is 8 characters long, and there IS no letter at index 8.) Flash just ignores us if we try to grab more of the string than actually exists. So technically, this is also valid:

var str:String = "manboobs";
trace(str.substr(3,5000))); // boobs

Armed with this knowledge, we can build our checkWord() method.

Let’s Do This Thing

private function checkWord(word:String):String
{
 
   if(word.indexOf("http:") == 0)
   {
         // This word starts with "http:" at index 0 (the beginning of the word)
 
         // Wrap it in html href (anchor) tags:
         return "<a href='" + word + "'>" + word + "</a>";
   } else if (word.indexOf("@") == 0) {
         // This word starts with "@" at index 0 (the beginning of the word)
 
         var justTheName:String = word.substr(1, word.length); // Remove the "@" from the username
         // We do this because we need to link to http://www.twitter.com/untoldent (for example),
         // not http://www.twitter.com/@untoldent
 
         // Wrap it in html href (anchor) tags:
         return "<a href='http://www.twitter.com/" + justTheName + "'>" + word + "</a>";
   } else {
        // There's nothing special about this word.  Return it as-is.
        return word;
   }
}

Note: Did you notice the use of single quotation marks and double quotation marks? You need to wrap you url in quotes, but since we’re already using double-quotation marks around our string, we need to use single-quotation marks to wrap the url, or they’ll interrupt our string definition and screw things up.

The Money Shot

So far, we’ve turned this:

"Hey everyone - @untoldent's blog is INCREDIBLE!  http://bit.ly/cXX06r"

into this:

"Hey everyone - <a href='http://www.twitter.com/untoldent'>@untoldent's</a> blog is INCREDIBLE!  <a href=''>http://bit.ly/cXX06r</a>"

The very last step is to use the htmlText property of your dynamic text box and stuff it with that fancy new string. Assuming you have a dynamic text box called twitterTxt, do this:

twitterTxt.htmlText = finalString;

You’ll now have clickable links inside your text field.

Extra Credit

If you’re super-astute, you’ve noticed that this code won’t actually work! That’s because the Twitter string says “@untoldent’s”, not “@untoldent”. The apostrophe-s is going to screw your code up, because you’ll be linking to http://www.twitter.com/untoldent’s, which is not a valid URL.

Using what you’ve learned in this tutorial, can you augment your checkWord() method to detect a “‘s” at the end of a Twitter user name and rip it out?

Further Reading

i hope this tutorial was informative and helpful! For more Actionscript and Flash tutorials, thrill to our Flash and Actionscript 911 book.

The SOUND_COMPLETE event is not triggered when your sound finishes playing.

SOLUTION:

There are a few different reasons why this problem may occur, but here’s how it played out in my project:

When you’re listening for a SOUND_COMPLETE event, you work with two Classes: Sound and SoundChannel. The event listener goes on the SoundChannel instance:

var sound:Sound = new Sound("allYouNeedIsLove.mp3");
var soundChannel:SoundChannel = sound.play();
soundChannel.addEventListener(Event.SOUND_COMPLETE, soundIsFinished);

In my project, i rigged up a “Pause” button. When the player clicks “Pause”, i stop the sound and take note of the Sound’s position. When the player clicks “Pause” again, i unpause the game and tell the Sound to start playing where we left off.

But whenever you paused and unpaused the game, the SOUND_COMPLETE Event wouldn’t fire any more.

That’s because whenever you tell a Sound object to play, it returns a new SoundChannel instance. The old SoundChannel instance – the one with the event listener on it – is no longer relevant, so the event doesn’t fire. So to get this to work, when the player unpauses the game, you have to add the SOUND_COMPLETE event listener to the new SoundChannel instance that’s returned when you call Sound.play();

THANKS FOR BAILING ME OUT!

BIG thanks to user WearDark on the Kirupa forums for clearing this up, and for saving me from hours and hours of bug testing trying to figure out what was going on!

http://www.kirupa.com/forum/archive/index.php/t-263824.html

i’d look like a fool if i tried to write a tutorial at this point. So instead, i’ll share this list of translations of common Actionscript 3 coding tasks to the Unity3D engine’s JavaScript-like UnityScript language.

1. Render an Object Visible or Invisible

Actionscript 3:

thing.visible = true; // or false

UnityScript:

thing.renderer.enabled = true; // or false

2. Tint an Object

Actionscript 3:

var colorTransform:ColorTransform = new ColorTransform();
colorTransform.color = 0xFF0000;
thing.transform.colorTransform=colorTransform;

UnityScript:

thing.renderer.material.color = Color.red;

3. Get a Random Number

Actionscript 3:

var someRandomNumberBetween0And5:int = Math.floor(Math.random()*5);

UnityScript:

var someRandomNumberBetween0And5:int = Random.Range(0, 5);

4. Respond to a Key Press

Actionscript 3:

 
stage.addEventListener(KeyboardEvent.KEY_DOWN, doKeyDown);
 
private function doKeyDown(e:KeyboardEvent):void
{
	switch(e.keyCode)
	{
		case 32:
			// Space bar! Do stuff.
			break;
		default:
			break;
	}
}

UnityScript:

if(Input.GetKeyDown("space"))
{
	// Do stuff.
}

5. Open a Web Page

Actionscript 3:

navigateToURL(new URL("http://www.untoldentertainment.com"), "_self");

UnityScript:

Application.OpenURL("http://www.untoldentertainment.com");

Technical Correctness vs. Getting Sh*t Done

i’ve been really happy with the way this series has been received. If you’re like me, you’ve had a hard time understanding the big deal about OOP and Classes – you know it’s something you’ve got to bite the bullet and eventually learn, but it seems like a whole lot of extra typing for nothing.

But for those of us designers-turned-coders who have embraced Classes (or have been forced into using them for a paid project with a deadline), we’ll tell you that when written the “right” way, Classes can free you from writing a lot of code in your next project.

The trouble comes when you know so much about Classes that you write them too correctly. You can definitely spend too much time making a Class all things to all people and for all purposes. “It’s a MegaClass that can be an animated sprite AND a media player! It’s so VERSATILE!” Meanwhile, you either haven’t launched a game in a year, or your clients are calling every other hour wondering how their project is coming along.

Let’s Recap

In Understanding Classes Part 1, you freed yourself from the timeline. In Part 2, you took a little detour and learned how to piggyback your library to write custom MovieClip symbols using inheritance. In Part 3, you started looking at how code could be organized in separate files to keep your workspace light, and to better organize your work. Now let’s take a look at the next principle of OOP, encaspulation, to see if we can’t turn our Classes into true drag-and-drop Lego bricks.

Lego, Ikea furniture, and Your Code

Once again, the three principles of Object-Oriented Programming are inheritance, encapsulation, and polymorphism.

Think of your Classes as Lego bricks. You want to build a Media Player brick that works in your current project, that you can lift out and snap into your next project that requires a Media Player, with no extra work required. That’s the dream, anyway.

Up to this point, i’ve recommended that you make all of your Classes’ fields (things that a Class is) and methods (things that a Class does) public. Public variables and methods can be accessed by anyone and anything outside the Class.

Let’s look at some code. We have an ImageGallery Class and our Main Class. Main creates an instance (stamp, version, print) of ImageGallery and draws it to the screen using addChild:

package
{
	import flash.display.MovieClip;
 
	public class ImageGallery extends MovieClip
	{
		public var numberOfImagesICanDisplay:int = 5;
		public function ImageGallery()
		{
			// Display numberOfImagesICanDisplay
		}
	}
}

package
{
	import flash.display.MovieClip;
 
	public class Main extends MovieClip
	{
		public function Main()
		{
			var imageGallery:ImageGallery = new ImageGallery();
			addChild(imageGallery);
		}
	}
}

So far so good. But take a close look at that variable on ImageGallery:

		public var numberOfImagesICanDisplay:int = 5;

That field is declared public. That means that any idiot (including YOU) can access that field and change it. Let’s be a total jackwad and, from Main, change it to eight million:

		imageGallery.numberOfImagesICanDisplay:int = 8000000;

This messes up ImageGallery’s pyjama party to the very limit. How is ImageGallery supposed to display eight million photos? It’s only really set up to handle five images. There HAS to be a way to protect important variables like numberOfImagesICanDisplay from other ass-hat Classes like Main.

Stop Looking at My Privates

Fortunately, there is a better and less future-altering way. If we change public to private, only instances (copies, stamps) of the ImageGallery Class can read and write the value of that field. Hooray!

The way i suggested you write your Classes was completely backards. Public is the most permissive access modifier. Private is the least permissive access modifier.

The rule i’ve read is that you should always start out restrictive, declaring everything private, because once you go public it’s kinda hard to go back to private. (If you were an early bloomer in high school who “went public”, you’ll know how difficult it is to regain your privacy)

So declare everything – methods and fields/variables – private. If you find that any outside Classes need to access those methods and fields later, you can open them up by making them public.

What Should I Make Public?

Object-oriented programming eggheads are pretty particular about the kinds of things that should be public, and those that should be private. The example i’ve heard is to think of a device like a vending machine. There are certain client-facing input methods that need to be accessible to the outside world:

• insert coin
• push snack button
• push coin return button

And there are certain things the vending machine is going to return to the person using it:

• snacks
• coins
• error messages (“SOLD OUT”, INCORRECT CHANGE”, “NO CANDY FOR YOU, FATTY”, etc)

So the vending machine accepts input and dispenses output. Everything else is private. The user does not need to be able to control the coils that turn to dispense the snacks. The user has no business figuring out how to make change inside the machine, or managing the vending machine’s inventory of goodies. That’s all internal stuff. That’s private.

Dispatching Events

We already know how to write a public method on a Class, and we learned how to pass a parameter through to the Class. Here’s a snippet from an imaginary vending machine Class:

public function insertCoin(coin:Coin):void
{
	// Tally up the value of the coin that has been inserted
	switch (coin.type)
	{
		case "quarter":
			coinValue += 25;
			break;
		case "dime":
			coinValue += 10;
			break;
		case "nickel":
			coinValue += 5;
			break;
		case "penny":
			// No pennies!
			return coin(coin);
			break;
		default:
			break;
	}
}

And here’s an example of how you might call that function from outside the Class:

vendingMachine.insertCoin(new Quarter());

In Actionscript 3, the proper way to signal to the outside world that something important has happened inside a Class is to fire an even dispatcher. Here’s what that looks like in our imaginary vending machine Class:

// This line goes at the top of the Class where you declare your fields:
public static const RETURN_SNACK:String = "returnSnack";
 
// And then later, when you declare your methods:
private function returnSnack():void
{
	dispatchEvent(new Event(RETURN_SNACK));
}

And here’s how you listen for that event in the Main Class (or from whichever Class instantiates [makes a copy of] the vending machine):

// Make sure you import the generic Event stuff near the top of the file:
import flash.Events.event;
 
// This is what your instantiation and listener definition look like:
var vendingMachine:VendingMachine = new VendingMachine();
vendingMachine.addEventListener(VendingMachine.RETURN_SNACK, getASnack);
 
// And elsewhere, you define the method to respond to the event:
private function getASnack(e:Event)
{
	// HOORAY FOAR SNAKZ!!!
}

Anyone see a problem yet? i do. We’re not really able to pass a parameter back to Main through our dispatchEvent command. So how does Main know what kind of snack it received?

There are a few ways around this. We can store a variable on Main called requestedSnack and take it on faith that vendingMachine returns the correct snack. Or, we can create a public variable on VendingMachine to store the returnedSnack, and in Main’s getASnack method, we refer to vendingMachine.returnedSnack. And then there are super egghead ways to do it that remain mysterious to me.

Let’s Get Ready to Fudge It

But here’s the CHEATERPANTS way of doing things. Using dispatchEvent is nice, because we can plop this vending machine down in any other game or app and it WORKS. It’s encapsulated. There are no dependancies. We just need to listen to all of its dispatched events in the new file, and we’re gold. But to be honest, that’s a whole lot more typing, and i’ve got things to do.

The cheaty way to do it is to pass a reference to Main as a parameter to the VendingMachine Class:

// From Main:
var vendingMachine:VendingMachine = new VendingMachine(this);

// From VendingMachine:
public function VendingMachine(main:MovieClip)
{
}
 
// And then later in VendingMachine:
private function dispenseSnack(snack:Snack):void
{
	main.getASnack(snack);
}

Hooray! No need to listen for an event, dispatch an event, declare a constant, or tapdance around the return value problem. The vendingMachine instance knows who its daddy is, and can invoke any of Main’s public methods.

Of course, the drawback is that this breaks encapsulation. You can no longer pick up your VendingMachine Class and move it to a new project, because VendingMachine is dependant on receiving a reference to a Class that has a public method called getASnack() on it.

Here’s how i go about it: if i’m writing something that i think is pretty handy, and it’s abstract enough that i’ll likely use it in future projects, i might do the extra work to write a nicely encaspulated Class. But if it’s sunny outside and all the other kids are playing in the park, and i can hear their joyous squeals through my opened window, i’ll break encapsulation and throw my Class a reference to the Class that instantiated it.

Don’t Cry, Nerds

Dear Eggheads: i haven’t left you out this time. The concept of passing a variable to the constructor function of a Class was explained perfectly clearly here, i hope, but i know how you like to muck things up with big words and impressive terminology. Your term for this technique is “Dependency Injection”, and if you’d like to read a more serious article on it with fewer pictures and bigger words, check out Joel Hooks’s article AS3 Dependency Injection Demystified.

Here’s a solid step towards demystifying it: STOP CALLING IT DEPENDENCY INJECTION. Sheesh almighty.

To read the rest of the Understanding Classes series, or to see more tutorials, check out our Flash and Actionscript 911 feature.

Trial by Flash

This series of Understanding Classes tutorials chart my progress through unfamiliar Actionscript 3.0 territory. i am a designer-turned-coder, so everything i understand about code was learned in the School of Hard Knocks … most often while a producer breathed down my neck and i had two weeks to program a game using concepts i didn’t grok.

i had already learned to avoid “spaghetti code”, a common newbie Flash developer habit where you stick little bits of code on various MovieClip symbol instances and frames throughout your Flash movie. The next step was to round up all of those little bits of spaghetti code and confine it all to the first frame of my Flash movie.

The next leg of the journey into Actionscript 3.0 was to escape the first frame, and to move all of that first-frame code into its own seprate .as Class file. That’s where Understanding Classes began. It seemed like a pointless step – whether the code was in its own frame or in its own Class file seemed like picky Egghead semantics.

The fuzzy picture came more clearly into focus with the next Understanding Classes tutorial, where we learned to write a custom Class to represent symbols in the Flash library. We used the less-than-helpful example of a Dog Class to explain how to pull this off.

But the time for theory is over. If we’re going to finally learn how to take full advantage of Object Oriented Programming, we need to look at some real-world examples. In this tutorial, we’ll pick through that glob of code in our Main.as file and find places where it makes sense to group chunks of functionality and split them off into their own Class files.

It’s Apparent You’re A Parent

In order to understand when and where to create new Classes, you almost have to think like a parent. All of the methods (things a Class can do) and properties (things a Class is) are your children. As your children grow older, you want them to learn how to take care of themselves. You (hopefully) don’t want to be changing your son’s diapers when he’s 17 years old.

So when you look at that mess of code in your Main.as Class, start asking yourself this question: should this kid, this group of properties and methods, be taking care of himself? Is this stuff that me, the Main.as Class, should be doing, or is this something that this kid can go off and do by himself?

Huh?

Here’s a real-world example:

package
{
	import flash.display.MovieClip;
	import flash.events.Event;
	import flash.events.MouseEvent;
 
	public class Main extends MovieClip
	{
		public function Main()
		{
			var myButton:MovieClip = new MyButton();
			myButton.label_txt.text = "Play";
			myButton.addEventListener(MouseEvent.CLICK, clickMyButton);
			myButton.addEventListener(MouseEvent.MOUSE_OVER, rollOverMyButton);
			myButton.addEventListener(MouseEvent.MOUSE_OUT, rollOutMyButton);
			myButton.mouseChildren = false;
			addChild(myButton);
			myButton.x = 150;
			myButton.y = 89;
 
		}
 
		public function clickMyButton(e:Event = null):void
		{
			playGame();
		}
 
		public function rollOverMyButton(e:Event = null):void
		{
			var myButton:MovieClip = MovieClip(e.target);
			myButton.background.gotoAndStop("highlight");
		}
 
		public function rollOutMyButton(e:Event = null):void
		{
			var myButton:MovieClip = MovieClip(e.target);
			myButton.background.gotoAndStop("unhighlight");
		}
 
		public function playGame():void
		{
			// Do some stuff here
		}
	}
}

In this piece of code, the Main.as file adds an instance of the MyButton Class to the stage. When the player clicks the button, we fire the playGame method.

There are some things here that the Main.as Class should probably do, and a bunch of things that the LabelButton Class should do for itself. Let me ask you this: why on God’s green Earth should Main.as care about how the MyButton Class implements all of its MouseEvent code? Making the button highlight on rollOver is MyButton’s responsibility, not Main.as’s responsibility.

Let’s imagine a not-too-distant future. Robots rule the Earth. Gary Coleman is in the White House. And you’re writing a new Actionscript project where you need a MyButton. The way you’ve written it here, can you easily pluck your MyButton Class out of this old project, and plunk it into your new project and expect it to work? No! That’s because you have code that is crucial to the functioning of your MyButton class outside your MyButton Class.

Do the clickMyButton, rollOverMyButton, and rollOutMyButton methods belong to Main, or do they belong to MyButton? Let’s go back to our semi-useless Dog example. Do bark, sniff and peeOnLeg belong to Main, or do they belong to Dog? They belong to Dog. So let’s put them in Dog.

Here’s the above script with the MyButton-specific methods removed:

package
{
	import flash.display.MovieClip;
	import flash.events.Event;
 
	public class Main extends MovieClip
	{
		public function Main()
		{
			var myButton:MovieClip = new MyButton();
			myButton.label_txt.text = "Play";
			addChild(myButton);
			myButton.x = 150;
			myButton.y = 89;
 
		}
 
	}
}

Wow! We really cleaned up our Main Class, didn’t we?

Here’s what our MyButton Class looks like. We’ve just plucked the methods out of our Main Class and put them where they belong, in MyButton. MyButton changes its own diapers.

package
{
	import flash.display.MovieClip;
	import flash.events.Event;
	import flash.events.MouseEvent;
 
	public class MyButton extends MovieClip
	{
		public function MyButton()
		{
			addEventListener(MouseEvent.CLICK, clickMyButton);
			addEventListener(MouseEvent.MOUSE_OVER, rollOverMyButton);
			addEventListener(MouseEvent.MOUSE_OUT, rollOutMyButton);
 
		}
 
		public function clickMyButton(e:Event = null):void
		{
			playGame();
		}
 
		public function rollOverMyButton(e:Event = null):void
		{
			background.gotoAndStop("highlight");
		}
 
		public function rollOutMyButton(e:Event = null):void
		{
			background.gotoAndStop("unhighlight");
		}
 
		public function playGame():void
		{
			// Do some stuff here
		}
 
	}
}

If you’re keen-eyed, you’ll notice that we were even able to cut down the code when we moved it to the MyButton Class. Instead of saying myButton.addEventListener(MouseEvent.CLICK, clickMyButton);, we can drop the “myButton” part and just say addEventListener(MouseEvent.CLICK, clickMyButton);. That’s essentially the same as saying this.addEventListener(MouseEvent.CLICK, clickMyButton);. The “this” keyword is like saying “me”. We’re inside the MyButton world, so we’re referring to ourselves. While we are writing code inside the MyButton class, we are MyButton.

Starting an Argumemt

Now what about that line in Main.as where we label the button?

myButton.label_txt.text = "Play";

Is labelling the button a responsibility of Main.as, or a responsibility of MyButton.as? The answer is slightly tricky.

MyButton might not always be labelled “Play”. We could (and should) think generically, so that MyButton could be labelled “Play” or “New Game” or “Change Character” or whatever. So Main.as should be responsible for labelling the button, right?

Not exactly. MyButton should still be responsible for labelling itself. But Main.as should be responsible for deciding what that label says. That way, Main could create buttons that say “Play”, “New Game” and “Change Character”,all using the same MyButton Class. The MyButton Class takes care of all the logic of actually displaying that text on itself.

To pull this off, we pass a parameter to our MyButton Class from Main.as.

package
{
	import flash.display.MovieClip;
	import flash.events.Event;
 
	public class Main extends MovieClip
	{
		public function Main()
		{
			var myButton:MovieClip = new MyButton("Play"); // Check it out!!!
			addChild(myButton);
			myButton.x = 150;
			myButton.y = 89;
 
		}
 
	}
}

Main.as creates a new MyButton instance (stamp, copy), and passes something called a parameter to the MyButton Class. MyButton grabs that parameter and uses it to label itself.

Note: if you’re fuzzy on the concept of datatypes (String, Number, Int, Boolean, etc), you may already be in over your head. Go read a basic tutorial on datatypes, and come on back.

Here’s the MyButton Class, now modified to grab that parameter from Main.as (or whatever Class instantiates [makes a stamp of, makes a copy of] the MyButton class).

package
{
	import flash.display.MovieClip;
	import flash.events.Event;
	import flash.events.MouseEvent;
 
	public class MyButton extends MovieClip
	{
		public function MyButton(labelName:String)
		{
			label_txt.text = labelName; // Grab that parameter and label myself!
 
			addEventListener(MouseEvent.CLICK, clickMyButton);
			addEventListener(MouseEvent.MOUSE_OVER, rollOverMyButton);
			addEventListener(MouseEvent.MOUSE_OUT, rollOutMyButton);
 
		}
 
		public function clickMyButton(e:Event = null):void
		{
			playGame();
		}
 
		public function rollOverMyButton(e:Event = null):void
		{
			background.gotoAndStop("highlight");
		}
 
		public function rollOutMyButton(e:Event = null):void
		{
			background.gotoAndStop("unhighlight");
		}
 
		public function playGame():void
		{
			// Do some stuff here
		}
 
	}
}

Beautiful! In this line, we accept a parameter:

public function MyButton(labelName:String)

And in this line, we grab that parameter and use it to label ourselves:

label_txt.text = labelName; // Grab that parameter and label myself!

Jockeying for Position

Finally, we’ll talk about the x/y lines in the Main Class:

myButton.x = 150;
myButton.y = 89;

Is that something that Main should be responsible for, or something that MyButton should be responsible for? x and y are properties of MyButton, so MyButton should handle them, right?

Not so fast! While we could let MyButton position itself, it wouldn’t make sense to. The Class that needs a MyButton should decide where on the screen the button should go. Otherwise, every time we create a new MyButton instance, it’ll appear in the same place on the screen. Not so hot. Main.as should take care of positioning the button instance.

Real Ultimate Power

Et voila! We’re in good shape now. We’ve:

1. Identified a chunk of code that should change its own diapers
2. Moved that code to its own .as Class file
3. Thought generically about how an instance (stamp, copy) of that Class should be treated

Now, check out the glorious wonderland we can experience and enjoy:

package
{
	import flash.display.MovieClip;
	import flash.events.Event;
 
	public class Main extends MovieClip
	{
		public function Main()
		{
			// Instantiate a new play button:
			var myPlayButton:MovieClip = new MyButton("Play");
			addChild(myPlayButton);
			myPlayButton.x = 150;
			myPlayButton.y = 89;
 
			// Instantiate a new instructions button:
			var myInstructionsButton:MovieClip = new MyButton("Instructions");
			addChild(myInstructionsButton);
			myInstructionsButton.x = 210;
			myInstructionsButton.y = 89;
 
			// Instantiate a new credits button:
			var myCreditsButton:MovieClip = new MyButton("Credits");
			addChild(myCreditsButton);
			myCreditsButton.x = 340;
			myCreditsButton.y = 89;
 
		}
 
	}
}

Wowee! THREE new button instances in half the code it took to have ONE button when we first started out.

We’re almost out of the woods. But there’s one nagging thing remaining. Notice that we have a method in the MyButton Class that looks like this:

public function clickMyButton(e:Event = null):void
{
	playGame();
}

Should MyButton decide what happens when it gets clicked? We saw that the Main.as Class can quickly create three instances of MyButton – a Play button, an Instructions button, and a Credits button. These three buttons are all going to do different things when the player clicks them. So the generic MyButton Class cannot possibly define its own click behaviour. Main.as is going to have to decide.

Let’s yank that click code right out of the MyButton Class:

package
{
	import flash.display.MovieClip;
	import flash.events.Event;
	import flash.events.MouseEvent;
 
	public class MyButton extends MovieClip
	{
		public function MyButton(labelName:String)
		{
			label_txt.text = labelName; // Grab that parameter and label myself!
 
			// this is where the MouseEvent.CLICK listener used to be
 
			addEventListener(MouseEvent.MOUSE_OVER, rollOverMyButton);
			addEventListener(MouseEvent.MOUSE_OUT, rollOutMyButton);
 
		}
 
 
		public function rollOverMyButton(e:Event = null):void
		{
			background.gotoAndStop("highlight");
		}
 
		public function rollOutMyButton(e:Event = null):void
		{
			background.gotoAndStop("unhighlight");
		}
 
	}
}

And instead, we’ll write the listener for each button’s MouseEvent.CLICK in the Main.as Class:

package
{
	import flash.display.MovieClip;
	import flash.events.Event;
	import flash.events.MouseEvent;
 
	public class Main extends MovieClip
	{
		public function Main()
		{
			// Instantiate a new play button:
			var myPlayButton:MovieClip = new MyButton("Play");
			myPlayButton.addEventListener(MouseEvent.CLICK, clickBtnPlay); // new line!
			addChild(myPlayButton);
			myPlayButton.x = 150;
			myPlayButton.y = 89;
 
			// Instantiate a new instructions button:
			var myInstructionsButton:MovieClip = new MyButton("Instructions");
			myInstructionsButton.addEventListener(MouseEvent.CLICK, clickBtnInstructions); // new line!
			addChild(myInstructionsButton);
			myInstructionsButton.x = 210;
			myInstructionsButton.y = 89;
 
			// Instantiate a new credits button:
			var myCreditsButton:MovieClip = new MyButton("Credits");
			myCreditsButton.addEventListener(MouseEvent.CLICK, clickBtnCredits); // new line!
			addChild(myCreditsButton);
			myCreditsButton.x = 340;
			myCreditsButton.y = 89;
 
		}
 
		public function clickBtnPlay(e:Event = null):void
		{
			// Play the game
		}
 
		public function clickBtnInstructions(e:Event = null):void
		{
			// Show the instructions
		}
 
		public function clickBtnCredits(e:Event = null):void
		{
			// Show the credits
		}
 
	}
}

And there you have it. The MyButton Class takes care of its own diapers. It labels itself based on a parameter that’s passed to it. It handles its own rollOver and rollOut events. Main.as takes care of creating instances (stamps, copies) of the MyButton Class. Main.as decides:

• What the button label will say
• How the button will be positioned on the screen
• What the button does when clicked

The First of Many

That’s a real-world example of where and when it makes sense to collect your code in a separate Actionscript Class file. Of course, this is just one example in an endless sea of possiblilities. The general rule is that if the code should be changing its own diapers, it should be in its own Class file. And if the code can be written generally so that it can be re-used, you’re ahead of the game.

The mystery that springs up from all of this is the OOP rule of Encapsulation, which states that you should write your Classes so that they’re self-contained and self-reliant. Not only do they change their own diapers, but they rent their own apartment and cook meals for themselves, with no reliance on outside Classes whatsoever to live.

There are advantages and disadvantages to Encapsulation, which we can look at in our next Understanding Classes tutorial. The biggest disadvantage is that to create a truly encapsulated Class, you have to write an ASSLOAD of repetetive Actionscript 3 code. i’ll show you a cheat that’ll break the encapsulation rule, but will save you HOURS of coding. The Eggheads will have my head for it, so let’s just keep it between you and me.

For more tips, tricks and tutorials on Flash and Actionscript, check out our Flash and Actionscript 911 feature.

What follows is a review by Jeff Gold (ue_jeff), our indomitable Game Developer and Keeper of All AS3 Knowledge.

From the Mouths of Jeffs

Today I set out to evaluate Kindisoft secureSWF, a product designed to help Flash / Flex developers secure and obscure their flash content from prying eyes. Thanks to several products on the market today (I am going to use SoThink SWF Decompiler as my point of reference here) it is possible, and quite easy, to open up Flash content found online to view and re-use all of the file’s source code and art assets. There are many reasons why developers would not want their files being decompiled this way. Theft of ActionScript code, theft of art assets, and hacking of controlled systems are just three.

Log in to the MochiMedia community forums and read this post about how one developer’s game was completely ripped off by someone with a swf opener:

psyon
Sep 07, 2009

On of my puzzle games was hacked. The person replaced my site logos, but apparently left my mochibot code in place, so I can see where all the hacked copies are. Anyone familiar with the site OyunKolu.com ?

SecureSwf was recommended to us by a number of our Twitter friends, including Chris Hughes from Flash Game License/GamerSafe. We had been evaluating other encryption software (most notably Amayeta SWF Encrypt 6.0) and were not entirely impressed with the Actionscript 3 code obfuscation. With Amayeta’s product, I found that using anything but the most minimal settings made my swf report many errors.

That New Software Smell

Upon opening SecureSWF I immediately noticed many options compared to the other products we had tried.

Being momentarily overwhelmed by all the panels in front of me I decided to just try out the default configuration. On the first simple swf I tried to encrypt, the default configuration worked quite well causing no errors while running the swf.

Immediately after encrypting my first swf with Swf Encrypt, I busted out my swf decompiler to see the results. Decompiling the swf was still possible ( I think this will be the case with any swf encryption ) , but inspecting the extracted code I could see a fair deal of obfuscation had occurred. (Obfuscation Translation: Code is EFFED-UP. – Ryan) With the default settings, Class names, function names, and class variables are obscured to things such as “_-V” or “_-02″, making the code very hard – but not impossible – to follow. I did notice immediately that variables scoped in functions were not obscured , but were left as var _loc_1 , var _loc_2 etc. as the compiler defines them (which I suppose is already obscure).

Giving It Some Welly

My next step was to crank up the security settings on the same simple swf. This time around I went to protection options and checked “Statement-level Randomization”, Maxed out “Control Flow Obfuscation” and “Dynamic Code Wrapping”, and checked “Break function Calls”. Honestly I am not 100% sure what all these things are doing, but I just went for overkill settings.

The swf still managed to run without any errors, and like last time I was still able to decompile the swf. Taking a look at the code again I immediately noticed quite a bit more obfuscation at the function level, and the code seemed more verbose and harder to follow.

Enter the Cow

So after my successful runs on a simple application, I tried to run a complex application through the process (Interrupting Cow Trivia, our real-time multiplayer trivia game) once again with default settings. At first the swf seemed to work with no errors, but after doing some stress testing I did notice few issues. After about 20 minutes of tinkering with the many settings available I figured out the culprit: “Control Flow Obfuscation”. Turning this one option off and then cranking all the other options managed to produce a 100% functional swf for me, and after decompiling I could not discern much difference from with the option on.

secureSWF has some other interesting features that I had not seen in other products (but, to be fair, I haven’t tried every competing product). These features include “Encrypted domain locking” and “Literal String Encryption”. I am not sure how the encrypted domain locking works , but it is a nice option and saves you from having to setup your own site locking in ActionScript each time. (Site-locking prevents your swf from being played on any domain other than the one[s] you specify.)

Literal String Encryption is another nice feature as it allows you to encrypt potentially sensitive text in your code. By default, strings will not be encrypted and will be perfectly readable when the code is decompiled. I am sure this process could be reverse engineered by digging through the code, but either way it just adds another barrier to the hacker to keep him from messing with your work.

Overall, Kindisoft secureSWF seems to be a solid product with lots of customizable features – far more than its competitors – that we plan to take advantage of for current and future projects.

End Jeff Transmission

Ryan: Of course, swf encryption is just one side of the story. If you have a game that posts information to your server to store high score data, to save games, etc, it’s important to know that all that stuff is wide open. Just grab Fiddler, a “web debugging proxy”, and run it while you play any game that makes server calls. With an unprotected game, you’ll be able to sniff out the exact asp or php page where scores are being posted, and you can use that info to trick the server into posting a high score for you. You can also use an app called Cheat Engine to wreak serious havoc with an online game, Flash or otherwise. Here’s how:

You may be wondering why, for the love of all that is Holy, we would be linking to movies and products about how to hack Flash games in a review of encryption software. It’s to illustrate the point that no protection solution is 100% effective (which is also why i have two children running around my house). Another saying i really like is “locks keep the honest people out”.

You’ll never make your game immune to hacking, but you can throw so many locks and contrivances in the way that it might take some serious skill to unlock them … and it follows that anyone with enough haxxor skillz to get through all those locks has something better to do with his considerable talents than to post a high score to your free-to-play Escape the Room game.

Win a Copy of secureSWF

Kindisoft is offering a 25% discount on secureSWF through various Flash game development sites, including FlashGameLicense.

For more articles about Flash and Actionscript, check out our Flash and Actionscript 911 feature.

Moo.

I promised that in Part 2, we’d learn how to identify chunks of code that should be moved into their own Classes. But before we do that, it’s important to talk about what a Class is. And if you haven’t learned how to extend a MovieClip symbol in your library to write a Class around it, this tutorial is for you!

Disclaimer Dear Eggheads: This tutorial is between me, a designer-turned-coder, and readers who want to learn more about Actionscript programming who likely are not Computer Science graduates. The terminology i use may not be 100% accurate, and some of the things i say may inflame your nerd rage and your unwavering demand for technical accuracy. But this article is not for you. Stop reading now. Go write some slash fiction about Captain Kirk totally doing it with the dog from Battlestar Galactica, and leave us alone to learn.

OOP: There It Is

A Class is an element of OOP – Object Oriented Programming. OOP is a flavour of coding where different objects – or things – interact with each other to solve a problem. If you’re a game programmer, the problem can be described as “How do i make a fun, functional zombie game?” The word “object” is synonymous with “Class”. You could say that Actionscript 3.0 is a Class Oriented Programming language, but the eggheads would stab you in the face.

So a Class is a thing – a chunk, a morsel, a module of code. By writing your Classes the “right” way, you’ll find you can re-use Classes from project to project. By writing them the “wrong” way, you’ll still probably wind up with a project that has nice, well-organized code that makes sense if you re-visit it a year later.

The three principles or rules to follow if you want to maximize the advantages of OOP are encapsulation, inheritance and polymorphism. We’ll be taking a brief, gentle look at inheritance in this tutorial, because i think it’s the easiest to understand when you’re starting out.

Classes contain methods and properties. (Another word for “method” is “function” or “behaviour”. Another word for “property” is “field”.) A method is something a Class can do. A property is something a Class is.
Let’s explain this somewhat better by using a crappy example that a lot of OOP tutorials use. You have a Class called “Dog”. Methods of Dog – things that Dog can do – include:

• bark
• sniff
• humpLeg

Properties of Dog – things that dog is – include:

• color
• breed
• favouriteTreat

Another way to think of it is that methods are verbs, and properties are adjectives.

Let’s Get Real

The Dog example is almost entirely useless to us as programmers. In all my years of experience, i have never written a Dog Class. But i HAVE written my fair share of music and movie players in Flash. Let’s look at the methods and properties of a media player.

Methods of our MediaPlayer Class – things that a media player can do – include:

• play
• pause
• stop
• scrub
• changeVolume
• loadMedia

Properties of our MediaPlayer Class – things that a media player is, or things that describe its state – include:

• isPaused
• songDuration (or movieDuration)
• isFullScreen
• volume

Note that the method “changeVolume” probably changes the property “volume”.

You’re Already an Expert

The good news is that as a Flash developer, you’ve been using Classes this whole time, though you may not have known it. A MovieClip is a Class. It has methods and properties. Let’s look at some of the methods of a MovieClip – things a MovieClip can do:

• gotoAndPlay
• stop
• hitTestPoint (determine whether a point is colliding with me)

And some properties of a MovieClip – things a MovieClip is (or things that describe its state):

• x and y
• alpha
• rotation

Eggheads: Are you still reading this? i told you to take a hike. Don’t jump down my throat. i know that a few of these methods and properties actually belong to Classes that MovieClip inherits from, but we’re just learning, alright? Leave us alone. Go out and LARP or something.

No Pain, No Awesome

Just as you can make the leap from stowing all your code in the first frame of your movie to putting it in an .as Class file, you can (and should) make the leap from having all of your MovieClip instances “physically” present on your stage, to keeping them in the library and drawing them to the stage using code. There are many advantages to using a code-only approach which probably won’t become clear to you until you go through the excrutiating growing pains of “WHY THE HELL AM I DOING IT THIS WAY??” like i did.

So create a MovieClip in your library. NOTE: If you don’t know how to do this, you may already be in over your head. Go check out a beginner Flash tutorial and come on back.

In order for you to make the MovieClip available to you through code, you need to give it a linkage name. Here’s how:

1. Open your Library (CTRL+L)
2. Right-click the MovieClip symbol
3. In Flash CS3, choose “Linkage”. In Flash CS4, choose “Propeties”.
4. Check the box that says “Export for ActionScript”
5. In the “Class:” field, type a logical name for your MovieClip. It’s best practice to start this name with a capital letter. Don’t use any spaces – capitalize each new word SoThatItLooksLikeThis. (This is called “Pascal case”)
6. Click “OK”
7. If you are a Mac user, and you’re saying “What’s a CTRL?? What’s a right mouse button?? i’m freaking OUT, man!”, go buy a PC ;)

Did you notice, before you hit OK, that there was a field labelled “Base Class:” that said “flash.display.MovieClip”? If this is your first time creating a library linkage, or if it’s old hat and you’ve never noticed this field, prepare to blow your own mind: you’ve just used the first principle of OOP – inheritance.

My Mind Done Blow’d Up

Here’s what’s going on behind the scenes. “MovieClip” is a built-in Class that the creators of Actionscript wrote. When you give your library item a linkage name, you are actually subclassing, or inheriting, from the MovieClip Class. That means that your new Class “Dog” or “MediaPlayer” or “EnemySpaceship” can now do all the stuff that a MovieClip can do. It can gotoAndPlay, it can stop, it can hitTestPoint, etc. It also inherits all of MovieClip’s properties – x and y, alpha, rotation, etc. – things that a MovieClip is, things that describe its state.

So now we’re getting to the point. When you create a library linkage like this, Flash is automagically creating a new Class (“Dog”, “MediaPlayer”, whatever). You don’t have to write it. But you CAN write it, if you want to. And since that’s what this tutorial is all about, then oh yes – we want to.

Oh Yes – Let’s

Start a new .as Class file. You can do it in the Flash IDE, you can write it with Notepad or Notepad ++ or any other text editor. i highly recommend Flash Develop. Remember our first Understanding Classes tutorial? Here’s the structure of a Class:

So here’s what our empty Class code should look like:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

package
{
	import flash.display.MovieClip; // Import statement(s)
 
	public class Dog extends MovieClip
	{
		// Class definition
 
		private var isBarking:Boolean; // Instance variable(s)
 
		public function Dog()
		{
			// Constructor function
			trace("i am a dog");
		}
 
		// Other functions
		private function bark():void
		{
			isBarking = true;
		}
 
		private function stopBarking():void
		{
			isBarking = false;
		}
	}
 
}

Let’s take note of a few important things.

1. i’m calling my Class “Dog”. That’s because the linkage name in used in the Flash library was “Dog”. Note: not “dog” or “DogClip” or anything. D-o-g. Same capitalization, exact same name.
2. And note that the linkage name can be completely different from the library symbol name. My library symbol could be called “This is a thing what i created in teh Flashs”. Doesn’t matter. Actionscript can’t “see” the library item name. It can only “see” the linkage name.
3. Finally, remember that the Class file name has to be the same as the Class name. If our Class is called Dog, we save the file as Dog.as. Pull any other shenanigans, and you’ll get errors.

i mentioned mysteriously in the last tutorial that the word “extends” is an inheritance word. When you create a linkage name in the library, Flash automagically writes a Class for you, and automagically extends (inherits from) MovieClip. Now that we’re writing the Class ourselves, nothing is automagic. We have to explicitly say that Dog (or whatever) extends (inherits from) the MovieClip Class. When this is all done correctly, Flash understands that there is a connection between the linked library Class “Dog”, and the “Dog.as” Class we just wrote.

You may or may not know the code for dynamically placing a linked library item on the stage. Here it is, using Dog as the example:

1
2

var dog:MovieClip = new Dog();  // or var dog:Dog = new Dog();
addChild(dog);

“BUT WAIT!”, you say. “I THOUGHT DOG HAD TO START WITH A CAPITAL LETTER??” Okay, first of all, stop yelling. Lower-case “dog” is the name of the variable that contains an instance (a stamp, a copy) of our master Dog Class. We could use “dog1″, “dog2″, or even “thisIsACopyOfDog”.

When you addChild(dog), you add your instance (stamp, copy) of the Dog Class to the list of things for Flash to draw to the stage (the viewable area that the player sees).

To confirm that your custom library Class is working, test your movie. You should see the trace action “i am a dog” in the Output window. (Press F2 to see the Output window – the trace action won’t appear on the stage)

What’s the Point?

You may be wondering why we went through all of this agony. The easy way is just to draw a dog and make it a MovieClip, and then leave it on the stage. There are many, many advantages to what we’ve just done. Let me list a few:

• You can now add as many Dogs to the stage as you like dynamically. Until now, you had to add them by hand. If you needed another dog, you (the creator) had to drag one out of the library. Now you can create an “Add Dog” button. When the player presses it at run-time, your code dynamically places dogs on the stage. Now the code is doing the work, not you.
• We’re edging closer to the next OOP principle, encapsulation. Within our Dog class, we can store methods (things that a Dog does) and properties (things that a Dog is). Every time we initialize (make a stamp or copy of) Dog, Dog can run a bunch of Dog-specific setup routines: initializeSenseOfSmell, testBarkTone, prepareToChewShoes. If you do it “right”, you’ve created a self-reliant, self-contained Class. Now every time you have a project that needs a Dog (or a MediaPlayer, an ImageGallery, a CountdownClock), you can just copy that .as Class file to a new project. If you’ve done everything “right”, it’ll just work.
• The more you start abstracting your thinking, the more you’ll be able to write generic Classes that do a number of different jobs. You might not have another project that needs a Dog, but your generic Animal Class would still do the trick.
• There’s a problem that Actionscript 3 introduced where you can’t always access certain pieces of MovieClips until they’re drawn to the screen. Writing a custom Class for your library elements can overcome this problem.

What’s Next?

Moving your frame code to an .as Class file was the first step. Learning how to write custom Classes for your linked library items is the next step, since it builds on (hopefully) familiar MovieClip territory and your existing knowledge. In the next tutorial, we’ll take a look at that big wad of code in your Main.as file and try to figure out which methods and properties can be logically grouped and moved into their own Classes.

For more tips, tricks and tutorials, check out our Flash and Actionscript 911 feature.

i love big lists of articles like this that are grouped by topic! We’ve made a few of our own here on the site:

• Flash and Actionscript 911 – An ongoing series of articles and tutorials, including common error messages and what to do about them
• News For You ue_newspoodle compiles a daily list of interesting stories on game development and related topics. Feel free to add your own links!
• Pimp My Game Our feature about monetizing Flash games has been updated with a GREAT list of articles on the subject – scroll to the bottom of the page to find them
• Conjure, a group of ETS students in Montréal, maintain a whopping pantsload of great game industry links (thanks @jeanpierflash!)
• Smashing Magazine offers 35 Excellent Wireframing Resources (thanks @danmartell!)
• Flash Game Blogs – A Who’s Who of the Flash game dev world and links to their blogs, maintained by the folks at GamerSafe/Flash Game License
• Top Indie Developer Blogs – We were delighted and honoured to find ourselves among such great sources on this list, which was posted by the buys at Gambrinous
• How to Raise Start-Up Financing – We prefer to bootstrap wherever possible, but Ben Yoskovitz has a series of articles on building a bidness with Other People’s Money
• Blender Resources – lanzoma composed a list of links to help developers who are new to Blender, a free 3D software package
• Business Resources for Startups – a FANTASTIC list of links across the full spectrum of concerns for start-up companies, game studios included
• Awesome Sources for Game Music – a list of links and mini-reviews for various music stock & service providers
• 50 Awesome Open Courses for Web Writers – Make your corporate game blog sing!
• All the Developer’s Books You Ever Wanted – A great list from Jeez.com of free pdf instructional books on a variety of languages and technologies.
• Indie Game Developer Links – Gaming Horror maintains his own superb list similar to this one.

If you have lists of links that you want to share, leave a comment and i’ll add them to this list!

A thread erupted on the FlashGameLicense community boards surrounding this post by free-to-play Flash game portal owner Yinan Chen, AKA “Archbob”, who runs FlashGameNinjaClan (which we “featured” in our recent post Why Don’t You Host Your Own Flash Game Portal?):

Mochi Leaderboards and Mochi Coins

Understandably, members of the developer community took exception to a few things Archbob had to say:

I don’t care how much the developers earn. The ones that make good games can easily make several thousand or tens of thousands per game.

and this gem from another unnamed portal owner:

I am sure Flash Game Developers make a lot of money already. [Microtransactions are] kind of greedy.

Hulk … rage … building. Sigh. Don’t get me started.

In the article, Archbob does voice some valid concerns about the implementation of MochiCoins and competing services from his industry perspective. He also goes on to shock some Flash game devs by detailing his practice of paying developers $100-200 for full source code to a game. This has led to a number of threads and posts on the subject of selling source, not least of all this post from the Vortix Games Blog:

Thinking about selling your source code?

Your Question, Answered

At the end of the day, Archbob is just a bidnessman looking to make a buck and doing it the most efficient way possible. If some devs are willing to part with their code for a pat on the back and some lunch money, it’s on them, not on Archbob.

But now that we’re all here, Flash game devs, let’s talk about this whole source code issue. What’s the deal, anyway? Should i sell my source code?

The short answer to that question is “no.”

The long answer is “no.”

The answer, translated into French, is non which, loosely translated back to English, means “no.”

The answer in the African click language Mbukushu is “nglOCK”, which – you guessed it – means “no”.

So a new question arises: have we, Untold Entertainment, ever sold our source? The answer there is actually “yes”, but to understand why, i have to take you back to a simpler time.

Let’s Do the Time Warp Again

Picture it: the year is 2007. George W. Bush is in the White House. “Fergalicious” by pop chanteuse Fergie (featuring will.i.am) tops the Billboard Hot 100, a popular music chart of the day. And the star of the Flash game development scene is a high-level programming language called ActionScript 2.

“AS2″, as it was known in jive-talking developer circles, was not a full Object-Oriented programming language. You could, with a little facial straining and a lot of undocumented wizardry, shoehorn it more towards an OOP mould, but most of us with a day job and one-week-long game production deadlines couldn’t be arsed. Those days, creating a new game meant coding it largely from scratch, or keeping a folder full of code snippets to copy-paste into a new file. Reusable code was a tale told by futurists and mad-men. Chaos and disorder ruled the day.

When our clients would request our AS2 source code for a week-long game like Eye in the Sky: Spot the Differences, it was hard to kick up a fuss. Many of our clients are kids’ television production companies who convince themselves that they’ll have the time and money to repurpose these games later, but nothing ever comes of it. If a different client were to come to us and ask for a nearly identical spot-the-differences game, i’d probably code it from scratch. The new client’s concept would probably be just subtly different enough to warrant a re-write.

But then along came a stranger to the scene, a wild-eyed and vivacious newcomer with a mane of saffron-coloured hair and a tight pair of rhinestone-studded spandex pants. “Actionscript 3″ was his name, and the industry would be changed forever.

The difference between AS2 and AS3 is that Actionscript 3 has really lived up to its promise of code reuse. Problems that used to take us days or weeks are reduced to literally a single hour, leaving us to catch up on our knitting in those long, tranquil stretches of Wednesday afternoons. AS3 has also changed the way we negotiate our contracts with clients.

AS3′s Impact on Contract Negotiations

The clients will always ask for source code, and we will always say no, for these very valid reasons:

1. By selling your source code, you are selling the right to use that code. You can’t (contractually) sell your code to someone and then turn around and re-use it in a new game.
2. With each new project, we re-use and improve upon libraries that we used in past projects. If we sold the code in those libraries, we couldn’t (contractually) use them in our next project, so our profit margins would shrink because we’d have to [technically] re-write the code.
3. The time and effort we put into some of our libraries is very valuable to us, and can represent literally years of development. We’re not going to let that fly out the door for the cost of a few weeks’ development.

To use an industrial analogy, selling your source code isn’t like selling a car. It’s not even like selling the plans or the autoCAD blueprints for the car. It’s like selling a machine which, when you push a button, makes a car.

So no, clients cannot have our source code. But this presents us with a problem: what happens when the client’s database guy needs to integrate the game into the high scores system, but he’s only available in November, and we’re finished with the game in October? Or what happens when the game is a component of a much larger website, and the client requires source code to integrate the game? Or what happens when the style bible changes and the client wants to make a character’s hat blue?

These are all real-world examples from our actual experiences. You hard-lined developers might say “if they want the hat blue, they can pay us to make that change.” But our policy has always been to enable the client to make reasonable changes after the fact, without having to pay an expensive Flash developer for simple modifications. That’s why we try to link copy decks in xml files outside the project. The client shouldn’t have to pay us more money because they want the Registered Trademark symbol added to a product name. (And, honestly, we don’t really want to halt production on a new project to make such a small change to an older project anyway).

We’re currently building a music game. What if the client finds out down the road that the rights to the songs have changed? Should they have to pay us to put different songs in the games? In my opinion, no. So we’re building the game so that it’s easy to change the playlist externally.

And the hard-line approach does nothing to solve the problem of site integration. Clients simply need source code in that case.

So what is the solution?

Enter the Shared Source Agreement

Since we started developing games in Actionscript 3, we’ve signed a Shared Source Agreement on nearly all of our projects. That’s where we can:

• Re-use
• Re-configure
• Re-sell
• Re-skin

the source code, and our clients cannot. But we do give our clients the source code, with a license to modify that code within the current skin. That means that if we’re making a game about bears who love the delicious crunchy taste of Goorman’s Cookies, the client can’t turn around use the source code to create a game about a bee who can’t get enough of the satisfying crackle of BingBong’s Peanut Brittle. They can do whatever they want with it, as long as they stick to that bear with those cookies.

The Honour System

“But if you give the client your code, aren’t they just on the honour system?” you ask. Sure they are. The client could turn around and do a variety of things with the code that weren’t contractually permitted. But as human beings, we rely on the honour system a great deal. The honour system is what keeps you from walking down the sidewalk and stabbing someone in the face. It’s what dissuades you from veering your car over the yellow line on the road and into oncoming traffic. i like the honour system. Let’s stick with it.

If it helps you with your own contracts, or if you’re one of our competitors looking to get an edge on us, here’s the kind of wording we use when we work with a client on a fee-for-service basis:

The source code for this project is licensed to [Client] under a Shared Source agreement. Untold Entertainment Inc. retains the exclusive right to modify, reuse, re-skin and sublicense the source code, and any non-brand-identifying multimedia assets. [Client] may modify the source code solely for the purposes of [project]. Untold Entertainment retains the know-how and materials to this project.

Know-How! (Contrariwise!)

When i first saw a client try to retain “know-how”, i actually had it stricken from the contract. How could someone else own my knowledge of how i did something? Did i have to erase my memory or try to blot knowledge from my mind? (Of course not. Apparently, i’m pretty good at naturally forgetting how to do things.)

i came to understand that retaining “know-how and materials” is strictly legal language pertaining to a research grant (SR&ED) here in Canada. He who writes that language into the contract gets to apply for the grant.

Let Us Retire to the Sitting Room

So this post is meant to help you out if you’re looking to do some fee-for-service work (we geev you the Flash, you geev us the monay) and you need this kind of help with your contract. i hope this post doesn’t serve as bait for an army of hobbyists telling me how great it is to sell your source code. As always, i welcome lively discussion either here or on the boards. And if this post has taught you nothing and you’re still interested in selling your source code to me for a few hundred bucks, please drop me a line. :)

It’th a Total Mathacre

Are you like me? Are you terrified of numbers? Does the thought of performing a simple math equation give you dry mouth and sweaty palms? Do fractions give you restless leg syndrome? And have you been afraid to really dive into programming because you’re worried about the amount of math it requires?

If you’ve even dipped so much as a toe in programmatic waters, i hope you’ve discovered that programming is more about logic than it is about math. You can create quite sophisticated games with branching storylines and interactivity without ever touching a floating point number (whatever that is).

i’ll level with you here: math scares the Hell out of me. But somehow, i’ve been building Flash games professionally for nearly ten years, and my arithmophobia hasn’t stopped me. What i’ve noticed in all my years of game development is that there’s one simple piece of math from back in grade school that i’ve used over and over again. I’ve probably used it in every single game i’ve ever written. But i remember a time when i couldn’t wrap my mind around what i was trying to do, because i hadn’t committed those certain math operations to memory.

So i’ll share them with you today, and i’ll share the cases where the math comes in handy.

The bit of math i’m talking about is just simple ratio stuff. A ratio is a relationship between numbers. Let’s jump into a real-world example right away.

Health Bar – Timeline

You have a game character, and he has a health bar. In code, the character’s health is expressed as a percentage: your character is at 70% health, let’s say.

You’ve built a graphic to depict this on the screen to your player. Here’s the absolute easiest way to go about displaying the health properly:

1. Make sure your health bar MovieClip has exactly 101 frames

   

   (image truncated to fit on-screen)

2. Inside the health bar, create a rectangle. This will be your character’s health indicator.

   

3. Press F8 and turn the rectangle into a MovieClip symbol.

   

   Use that little grid to put the registration point at the left edge of the bar

4. Select frame 101 and press F6 to add a keyframe there on the bar’s layer.

   

5. On frame 1, set the width of the bar to 0.1. On frame 101, stretch the bar out to its full width. (note: you may need to turn on the snap tool and move the white registration dot in the middle of the bar to its left edge on both keyframes)
6. Right-click frame 1 and select “Create Motion Tween’ in CS3 or “Create Classic Tween” in CS4

   

7. When you need to display the character’s health, tell the bar to gotoAndStop(health + 1). So if health is 0, the bar goes to the first frame. If health is 100%, the bar goes to the 101st frame. If health is 50%, the bar goes to the middle. (note: MovieClips don’t have a frame zero, which is why we’ve offset everything by 1 frame)

So that’s the old-school way of doing it. And if you’re starting out, it’s still a very viable way of doing things. Don’t let the eggheads laugh at you because you are using timeline animation.

But what about cases where you want to do everything with code?

Health Bar – Cheaterpants Mathless Method

What we’re trying to do is to change the width of the health bar using Actionscript 3 code, so that it matches the player’s health value. Here’s the easiest way to do that:

1. Make sure your graphical health bar, at full health, is 100 pixels wide
2. When you want to update the player’s health, set the width property of the bar to the health value. At 50%, it’s 50 pixels wide. At 100%, it’s 100 pixels wide.

Sounds great, yeah? We dodged the math bullet for another day.

Health Bar – Still No Math Required

But wait … what if a 100 pixel-wide health bar won’t fit in your interface? What if it’s too big or two small?

Resist the math at all costs! Just do this:

1. Scale your health bar. Even if you squish the MovieClip, the width of the bar inside is relative. It’ll still be 100px wide at full health, but it’s inside a clip that’s getting squished or stretched to make it look like it’s shorter or longer than it actually is. This will work out very well if your bar is a vector graphic, because you won’t get any jaggies when you scale it.

Um … Ryan? My health bar isn’t vector.

OR

Let’s just cut to the chase and use some of that ratio math, huh?

Biting the Math Bullet

Alright – we’ve done everything we can to avoid using math to solve this problem. Let’s take a look at the math that we need.

First, let’s gather some information. Let’s identify what we know, and what we don’t know.

What do we know?

1. We know that our character’s health is 70%
2. We know that 70% is a number out of 100. If we write it as a fraction, seventy percent is 70/100 (or “70 over 100″, or even “seventy one-hundredths”)
3. We know how wide our health meter can be (let’s say 360 pixels)

What don’t we know?

1. We don’t know how wide the bar inside the health meter is supposed to be

So that leaves three knowns, and one unknown. In algebra, our unknown value is often written as x.

Finding x

Ah, x. My old nemesis. How you’ve plagued me with nightmares over the years. But this time, i have nothing to fear, because i’m armed with knowledge, and i’ve been drinking Scotch all afternoon.

A ratio is a relationship between numbers. Do you see the relationship between the number 70 seated inside the number 100, and the width of your health bar seated inside the maximum possible width of the health bar? 70/100 is the same thing as something/360. (remember: 360 is the maximum width our health meter can be.)

So to put that a more mathy way, 70/100 = x/360.

Or, to express it as something you’d see in a grade 5 math textbook:

Oh teh noes! We’re in Math Land now! Everyone hold on to the rope, and don’t stray off the path. We’re gonna get through this thing.

Ninja Moves, Bitches

There’s a bunch of stuff that we can and need to do to this math thing … this statement … in order to figure out what x is. Anything we do to this statement is called an operation. You can think of operations as ninja moves. Let’s learn the punches, kicks, and spine cracks we need to extract the info we need – x.

Let’s see if we can beat the crap out of the other numbers to isolate x. We want x on one side of the statement, and every other number on the other side. Then we’ll wind up with a statement that says “x = some number“. That’s the number we want!

Ninja Move #1: In an equality statement like this, we’re saying that the thing on the left is the same as the thing on the right. So we can swap sides any time we like. Let’s swap sides now.

Ninja Move #2: Just the same, we can flip the fractions upside down, as long as we do it to both sides at the same time. Let’s do it!!

Ninja Move #2.5 Ok, that kinda sucks. It’s easier if x stays on top of the fraction. Let’s reverse that last ninja move!

Ninja Move #3 It looks like we can do anything we want to one side, as long as we do it to the other. x/360 is another way of saying “x divided by 360″. If you take a number and divide it by something, and then you multiply it by the same something, you wind up with your original number. Let’s see that in action with some easy math:

6 / 3 * 3 = 6;

(Six divided by three equals two. Two times three equals six – the same number we started with.)

And again:

2 / 4 * 4 = 2;

(Two times four equals zero-point-five. Zero-point-five times four equals two – the same number we started with.)

So at the moment, our math equation says x/360. If we multiply x by 360, we’ll get x all on its own. It’s like we’ve made that /360 part disappear.

BUT REMEMBER: This is an equality statement. If we kick one side in the face, we have to kick the other side equally in the face. We multiplied the left side by 360 to get rid of the divided-by-360 part, so we need to multiply the other side by 360 as well. Here we go:

How awesome is that? x is all alone on one side of the equals sign. Now we just do the math on the other side, and we have our answer.

x = 70 /100 * 360
x = 0.7 * 360
x = 252

So there’s our answer! If the character’s health is at 70%, and the maximum width of our health bar is 360 pixels, we need to change the width of the health bar to 252 pixels to make it look right.

This is just one real-world example where ratio math comes in handy. Here are a few more examples where knowing the same ninja moves helps again and again and again:

Mini-Map!

You have a character on a big scrolling background, and you want to show a dot on a mini-map in the corner of the screen.

The character’s x position within the width of the background is the same as the x position of the dot within the width of the mini-map.

character.x/background.width == dot.x/miniMap.width; // dot.x is our unknown!

Ninja move! Flip sides!

dot.x/miniMap.width == character.x/background.width;

Ninja move! Isolate the unknown!

dot.x/miniMap.width*miniMap.width == character.x/background.width*miniMap.width; // multiply both sides by miniMap.width to get rid of it on the left side!

Ninja move! Dividing a number by something, and then multiplying by the same something is the same as doing nothing!

dot.x == (character.x / background.width) * miniMap.width;

Solve for x!

dot.x = 57; // (this is after substituting nubmers for character.x, background.width and miniMap.width)

Colour Slider Control Handle!

You have a colour slider bar. The player can crank it up and down to adjust a colour swatch from 0-255. You want to know the colour value out of 255 based on where the slider was cranked.

sliderTab.y/maximumSliderRange == x/255;
x/255 == sliderTab.y/maximumSliderRange; // swap sides
x = (sliderTab.y/maximumSliderRange)*255; // get rid of the fraction on the left side
x = 42; // (again, we dropped in the number values for sliderTab.y and maximumSliderRange to arrive at this number)

Flash Video Progress Bar!

You have a progress bar on your flv video player. You want to know how far along to position the progress marker based on how much of the video has played.

marker.x = movie.position / movie.duration * totalWidthOfTheProgressTrack;

Shooter Game Accuracy Rating!

You have a shooter game. The player scored 37 hits out of a possible 553 targets. You want to express that as a hit accuracy percentage when the level ends.

accuracy = 37 / 553 * 100;

See, Mr. Sprague? That’s How It’s Done

i was never really terrible at math – i just didn’t enjoy it. i didn’t like the fact that there was only one right answer, and that in early grades, we were timed. In the first grade, we had to compete “Minute Math” sheets – one minute to burn through a page full of sums. i appreciate the thinking behind this, but wtf? There was no such thing as “Minute English” (write the alphabet as fast as possible) or “Minute Art” (string together a painted macaroni necklace in under a minute or face failure).

In high school, i finally failed my first math course – grade 12 finite. One of the reasons i never really took to math – and it’s a big one – is that i never had a math teacher who taught it to me like it needed to be taught. If my high school math teacher had told me that by learning physics, i could make a video game character jump and react to gravity and push boxes around, or that by learning trigonometry i could code my own billiards game, i would have lapped it up. As it stands, i still struggle with my fear of numbers in my professional career – the fear of failure, the constant imagined tick of the clock while i try to figure something out.

Just talk about ninja moves and video games, and everything will be fine. Ratio equations may not, honestly, be the only math you’ll ever need, but if you have a bad history with numbers like i do, it’s a decent start.

For more Flash AS3 Tutorials and a pile of other useful stuff, check out our Flash and Actionscript 911 feature.

The path i travelled from complete code newbie to the shock-inducing AS3 god that i am today ( er … hardly) went like this:

Beginner – i put my Actionscript code everywhere – on different frames of the timeline, embedded in nested MovieClips – if i can write code on it, i do.

Intermediate – Scattering code through my Flash movie makes my project an