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.

i spent the past month tweeting rotten poetry to the FGS Twitter account. The entry fee for the conference wasn’t very expensive, and the OMDC (Ontario Mosquito Death Camp) is footing the bill for half of our activities in San Francisco this week through the Export Fund. But if i see a chance to get something for free, whether it’s a conference pass or a Scientological stress test, i jump at the chance. And lo and behold, at the eleventh hour, @FGS comped me a pass … but not before GamerSafe/Flash Game License comped me another one. i felt like the one girl in grade eight who had breasts … so much unwarranted attention! Thanks, everyone. i was very happy to be there and to meet everyone in person.

If you couldn’t make it, you missed a pretty solid show. i almost wish that GDC was one day only, and FGS dragged on for a month or more. Here’s a run-down of who i saw and what i learned.

Bidness

The show was split into two tracks: business on the upper floor, and creative on the lower floor. It was the conference equivalent of a mullet.

i stayed upstairs the entire time. Adam did a great job with Canabalt, but i’d much rather learn how to make myself money than to hear about how he built a walk-in freezer made of money to store all his money, or whatever.

Opening Keynote – Jameson Hsu

Jameson’s a good guy, but a somewhat nervous presenter. He announced a few new initiatives from his company, MochiMedia: the Mochi Social Platform, and the Mochi GAME Developer Fund. i have NO IDEA why they capitalized “game” … maybe to differentiate it from their Mochi ACCOUNTING SOFTWARE Developer Fund? Not sure. The idea is that Mochi’s new supreme Chinese overlords, Shanda Games, who recently bought Mochi for $80 million, would put up $10 million to help developers make games. i didn’t quite find out what the catch was … obviously, Mochi wants any games it funds to tie into as many of its own initiatives as possible – microtransactions, ads, and the new Mochi Social Platform.

The Platform didn’t really seem like a new or Earth-shattering announcement – you could see them building up to this at least two years out. Mochi is creating an easy-to-implement solution where you can leverage social media – Facebook, MySpace, YourPants, etc – with a single, simple API. It’s nice, but like many of the other services Mochi offers, you can roll your own and have a lot more control, but at a longer development time and greater financial risk. With Mochi’s solution, you gain ease of use but forfeit control.

i was pretty happy to see the developer fund, because it was a little tiring to keep hearing Mochi and pals chanting the mantra “Make multiplayer games! They rake in a lot more dough!” They also cost a big wad more to develop. Our first foray into a multiplayer game, Interrupting Cow Trivia, means that my daughters won’t be able to get braces and will look like snaggle-toothed freaks the rest of their lives. The game was expensive to build, in other words. Mochi’s fund, they say, aims to mitigate the risk of that more expensive development, and i think it’s a step in the right direction.

They’re still, however, giving away MochiCoins to players, which the players then use to buy virtual items in your microtransaction-enabled games, which is kind of like the government approving citizens to walk out of your shop with a free television or whatever, so Mochi remains on my handle-with-care list.

Mochi’s Ada Chen said she was afraid to open her mouth around me because she never knew whether i’d write something negative about the company. Roll with the punches, Ada! If you didn’t have critics, you’d go mad with power. i’m just here to keep you honest.

4 Keys to a Successful Social Game that All Game Developers Should Know

On the panel:

• Dan Fiden – Playfish
• David Stewart – Playdom
• Gavin Barrett – Crowdstar
• Mark Skaggs – Zynga

This panel was stacked with Zynga, Playdom, Playfish and Crowdstar, the companies who – God love em – have actually turned a buck on Flash … and a BIG buck at that. When the same companies spoke at Casual Connect in Seattle last year and dropped the bomb about how much they were raking in on Facebook, i could tell the whole conference was freaking out and trying to figure out how to get some of that action. i also knew that by then, it was too late – these guys had sewn it up, a fact that they repeated often throughout this panel.

This panel, and nearly every other at the conference, was plagued with some uniformly terrible moderation. Moderator Sana Choudary, and every panel moderator at the show, pulled the same rookie error of asking very broad questions, tiptoeing around controversy, and ending on the same ridiculously vague question “Where do you think the future of _____ is going?” Oh maaaaaaan … if i have to hear that question one more time, i’m positively going to bite my pillow.

The moderator asked the audience to tweet questions. The first one i came up with was “Are you making games or slot machines??” Not very original, i know, but i have a hunch i wasn’t the only one thinking it. i could only hear these companies talk about the fun, original and interesting games they were making for so long before i really had to give my head a shake. At least one other person in the peanut gallery had tweeted the same question. Unfortunately, the moderator censored the questions, and it was as if she’d been coached to do so – like when you interview a celebrity and you’re not allowed to ask about her recent divorce or that thing on her neck. Zynga was here, and they were rich, and they were only going to deign to visit us from Mount Olympus if we were all on our best behaviour.

The end result was that the questions were vague, the answers were more vague, and at least two of the panelists were ignorant enough to clam up about numbers and say “it’s all on the Internet – go do some research and look it up.” No, fellas – i didn’t fly from Toronto to California and haiku my way to a free pass to be told to go Google my questions about your companies. You’re on the panel for a reason, and i’m in the audience for the same reason. Me: questions. You: answers. Telling people to “just Google it” is ignorant.

The conclusion the panel came to was that yes, you can make lots of money on Facebook … if you’re Zynga or Playdom or Playfish or Crowdstar.. A few other points of interest:

• Games need to be designed with social hooks from the ground-up. Retrofitting doesn’t work.
• Mark – if your numbers are going down, it’s time for a sale!
• Mark – “Zynga collects 5 terabytes of data a day. (Ryan – holy SH*T!) Don’t underestimate the data side of this business.’
• Gavin – “The support of your community and your interaction with them is the most important thing you can do.”
• Mark – (answering “what’s a minimum bar for success?”) “5 million daily active users.” (Ryan – DOUBLE holy sh*t!)

In conclusion: if you can collect and parse 5 terabytes of data a day, pull in and retain 5 million daily active users, and hook grandmas to your virtual slot machine like they’ve got a crack habit, you too could be the next Zynga. It’s that easy.

Money in Flash: Next Gen Monetization of Flash Games

On the panel:

• Chris Hughes – flashgamelicense.com
• Jim Greer – Kongregate
• Justin Wong – Mochi Media
• Vikas Gupta – Social Gold

Initially, i was a bit annoyed during this panel. The fellas weren’t talking about some space-aged monetization techniques from the future that i’d never heard of. They were talking about microtransactions, mostly – current gen stuff, not next-gen stuff like the topic promised. Still, it’s not fair for me to demand new monetization ideas when i (and many, many others i know) haven’t even made good on the current techniques.

Here were a few nuggets from this panel:

• Jim says Kongregate’s best multiplayer game is raking in 5x more cash than their best single-player game
• Justin reiterated the thing that most successfully drives microtransactions: “Getting the player to the point of need.” That’s where, for example, the next level is going to SLAUGHTER the player, and he knows it, but hey! He can buy a bigger gun for two bucks. It’s a lot like putting a condom machine in the bathroom of a cougar bar. The point of need drives more sales. (That’s my analogy, not Justin’s.)
• Jim says Kongregate is making about 1/3 of its revenue from virtual goods, and 2/3 from advertising. He expects that to level out to about 50/50 in the next year.
• Jim added that Kongregate makes about half of its ad revenue in the 4th quarter, when its advertisers need to sell video games to people for Christmas
• Justin says Mochi makes about 15%-ish of its revenue from virtual goods sales
• Echoing the sentiments of the previous panel, the lads emphasized that games need to be built with microtransactions in mind from square one. Retro-fitting an older game with new microtransactions is not as effective.
• Jim says analytics are important, and adds that you should “watch what [players] do, not what they say.” i’ve heard this before – believe it or not, the two can be completely different.
• Jim says “The vast vast majority of revenue comes from credit cards and Pay Pal.” “$100 at a time is the most common.” (Surprising! Higher than i expected.)
• Chris and Vikas agreed that once you get a player over the initial hurdle of paying the first time, it’s much easier to get that player to continue paying. Chris added “If you can sell a dollar to a user, you can sell fifty dollars to a user.”
• Vikas offers that the best way to use subscriptions is in conjunction with virtual goods payments. You offer virtual goods deals or bundles with subscriptions that end up saving the player money. He says the two are a fantastic combination.
• Justin says games that used Facebook Connect saw a 30% jump in gameplays.

One of the most interesting insights i got out of this panel came about when one of the guys from Yummy Interactive took the Q&A mic for the first of two somewhat obnoxious self-promoting speeches. He pointed out that you could also sell games for a flat fee (which conveniently ties into Yummy’s model of selling a Flash wrapper for downloadables). What ensued was a tense, almost exasperated exchange that gave me an Aha! moment.

Casual downloadable titles from sites like Big Fish Games started out at $20. The price has dropped over the year, thanks to market interference by folks like Amazon, to the point where it’s now at about $7. Flash games started at zero dollars, and have been struggling to increase. So you have this race to the bottom in the casual downloadable space, and a race to the top in the Flash games space. Is the point at which the two segments meet the perfect price to charge for an online video game? Or will Flash games prove that microtransactions in multiplayer games suck way more money out of people’s pockets than a $20 price point ever did?

Adobe Tools and Services for Flash Games

It was more than a little embarrassing that Adobe, the people who make the software that all the conference attendees were meeting and speaking about, had such an inept presentation. Technically, it was like giving a camcorder to a spider monkey and expecting it to take coherent pictures. The presenters tried to show off Flash Player 10.1 running on a number of smartphones with a very dim presentation camera, and one monitor cable that they constantly had to pull out of the camera and plug into the laptop when switching between demos and slides. The demos of games like Bloons on the various handheld devices ran disappointingly slowly. One of the presenters swallowed her mic or something by the end of the talk, and had to lean into her fellow presenter’s chest and talk into his lavalier. Just awful.

The whole time, i felt very bad for them, struggling like they did with bad tech, bad demos and no new information to share, like the release date for Flash CS5. It was the Flash Gaming Summit, Adobe. Throw us a frickin’ bone.

One demo that did pique my curiosity showed a Flash game online where the player could log in using Facebook, MySpace or YourPants, and then another player could log into the same game on the iPhone, and the two could play the game on the same network. This was a demonstration of a new initiative called Adobe Services. i need to ask them about it at GDC, but i can’t imagine what they’d charge for that setup. My guess is $lots.

The Mochis Award Show, Sponsored by Kongregate

This was a chance to see the usually serious-faced Jim Greer from Kongregate have fun and lampoon himself a bit, which was nice. The award winners all look like they deserved their hardware, but i was dismayed to discover i hadn’t heard of most of the games in the running. i knew Canabalt Machinarium, and had only heard of Time Fcuk because of a podcast i did with the developer, Edward McMullen. It underscored the fact that this past year has been non-stop work for me, and that i need to lighten up and start playing more games. i shouldn’t be such a Jim Greer all the time.

(i keed, Jim! i keed! Don’t hate.)

Monetizing Your Game Outside of Sponsorship

This panel consisted of:

• Colin Northway, Fantastic Contraption
• Daniel James, Three Rings
• Sian Yue Tan, Rocketbirds
• William Stallwood, Cipher Prime

This was a GREAT panel. i absolutely loved that it inadvertently pitted three young bucks, whose recent successes had not yet been proven as deliberate business savvy or lucky strikes, against Daniel James, who’s had a chance to very publicly succeed and fail over the years he’s helmed Three Rings.

When asked how they chose a price point for their games, the answers were naive:

Colin – “Well, World of Goo cost $20, and i figured my game was half as good as World of Goo, so i charged $10.”

Sian Yue – “We looked at $10 and $20, and went with $15 cuz it was about halfway.”

Adorable.

i could see Daniel biting his tongue, but knowing him, it wasn’t going to last long. Finally, he said in his refined British accent “So … you guys basically pulled your numbers out of your butts?”

Soon after, Sian Yue sagely added “We chose a price and we stuck with it. Moving your price point around is never a good idea.”

i could see Daniel facepalm using only his face. Having been to his monetization roundtables at GDC for the past few years, and knowing how much they monkey with their payment systems and pricing strategies, i knew he was about to assplode. Finally, he couldn’t resist speaking up: “Actually, there’s a lot of scientific research that proves you should move your price point around.”

Oh snappeth! Thou didst not!

The old dog had schooled the young pup. Here’s where Daniel’s wisdom and experience shone through. He said it was alright to make that initial guess, but that you should “be diligent about testing your hypotheses.” He went on to explain that his company had spent 5 million dollars on Whirled, only to see a $300k return. He said they could have done the same learning in far less time with far less money by testing their hypothesis early and often.

i had read Daniel’s blog where he explained the lesson learned from Whirled. He said that Three Rings was now testing Facebook games in small doses to see what would take off. i had no idea what this meant. Were they building portions of the games? How could you know if a game would do well if you only built a fraction of it?

He clarified the strategy: they were putting together highly-target Facebook banner ads for games that didn’t exist yet. Each ad would lead to a landing page with a button where the potential player could sign up to be notified about the beta, which may not ever happen. Daniel said that one of the theoretical games out-performed the others 5 to 1 in terms of interest, so that’s the one they’re going to build.

They even did granular testing on THAT game. They did at least two ads with the same artwork and a different game name. One name tested better than the other, so that’s the name they’re gonna use.

Brillant, as any true Brit would say.

Everything About Sponsorship & Licensing

What a panel!

• Greg McClanahan, Kongregate
• Joel Breton, AddictingGames.com
• Lars Jornow, King.com
• Robin Yang, Candystand

Of all the panels, this was probably both the worst and the most delightful. Let me explain.

i’m told that AddictingGames.com were harangued by a developer last year for encouraging the Flash devs in the room to submit their games for free to that portal. It was really nice to see how, after one year, the tide had turned, thanks in no small part to the effort of Chris Hughes and the Flash Game License team. FGL clearly became the Great Equalizer in the war between the portals, who want as much content as possible for as little money as possible, and the developers, who deserve to be paid for their work.

You could tell that everyone on the panel, now matter how much they downplayed it, used FGL to find the developers they sponsored. Robin, the most intolerable panelist, along with Joel, continually made the appeal for developers to forge a relationship with the portals, ostensibly so that devs would skip FGL and continue to deal directly with Candystand. The advantage, of course, is that Candystand avoids a bidding war on FlashGameLicense.

Greg from Kongregate cottoned on to this real quick and said “what’s the advantage to the developer of going to you first?” Robin and Joel each tried to spin a yarn about how they know their audience best and can give developers suggestions about how to build their games (uh … great?), and how they’ll put all kinds of money and promotion into a sequel if the first game does really well. With a huge grin, Greg said “ANYONE will give the dev all kinds of money and promotion for a sequel to a successful game!” He put a fine point on it by saying that devs should go with the highest bidder, period. Robin’s angle was so transparent that i could hardly believe her audacity. The closest parallel that came to mind was when George Bush went on teevee right after the Shock and Awe bombing campaign in Iraq and said “Now, Iraqis, please stop setting your oil fields on fire. Those are precious, and they’re the inheritance of the Iraqi people.”

Really, Bush? You don’t want the Iraqis to set their fields on fire because it’s for THEIR own good? Aren’t you the least bit interested in maybe having a little bit of that oil for yourself? Not even the teensiest amount?

It was justice, to see the reps from those two big portals twist and squirm before an audience that, in the course of a year, had begun to turn the tables on them. The white masters were suddenly so concerned for the welfare of their newly-emancipated slaves.

Ok – i’m probably going overboard with these analogies. The Iraq War? Slavery? i’m a step away from Hitler.

….

Oh, what the Hell? Candystand and AddictingGames are Hitler. There. i’m officially a hack.

Turbulence Ahead: The Ups and Downs of Getting a Premium Flash Game to Success

The last session of the day was a solo flight by Tim Flowers of Gabob LLC, who made six figures on Now Boarding. i was initially worried that, like many developer talks, Tim’s would have a very narrow focus with very few take-homes and loads of inapplicable advice, like “then my auntie died and i got some money, so i was able to fund the next portion of my game.”

i found myself actually hanging on every word of what Tim said. His whole plan for his game had been the exact plan i’d had for Kahoots – push the game out to casual downloadable portals, who take an 80% cut. His art style, liberally borrowed from Catch Me If You Can, reminded me of the pop-art style we adopted for Interrupting Cow Trivia. i wrote down everything Tim said voraciously, and after asking him a few questions at the mic, returned to my seat and somehow lost my notebook in the process. He said some absolutely smart things that are now lost to time … or to the two video cameras that taped the session. Know this: daddy wants the video tape of Tim’s session. i suggest that if it’s available, you watch it too!

NICE TO MEEEET YOOOUUUU!!!!! (WHAAAAT???)

All in all, it was a fantastic day, and i didn’t want it to end … until the after-party started, and the organizers thought it would be a simply smashing idea to blast incredibly loud club music into everyone’s ears at a networking event. i DO NOT understand why companies do that. After i grew tired of yelling into people’s faces for hours, i left the party and started writing this postmortem back at my hotel.

GDC starts tomorrow, and i’ll do my level best to pussy out of Tuesday’s parties to write more for your enjoyment.

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.