Category Archives: Blog

Movember 2010

i’ve never (voluntarily) grown a beard or a moustache before. Puberty kind of imposed a weak ‘stache on me in my junior high days, and since i didn’t have a dad around to teach me how to shave my face, it kind of overstayed its welcome. Then later, in high school, i decided to try growing a beard, but one of the student council kids, Joey Testosterone, ribbed me about it mercilessly. i went home and shaved it off that very day.

A few years later, i landed a bit part in a community theatre production of Joseph and the Amazing Technicolor Who’s That Guy in the Background Trying to Grow a Beard?. It looked as though i had once had a full beard, but was then tragically mauled by a mountain lion and patches of it had been eaten.

Flash forward to today. It’s the end of Movember, the month when dudes grow beards to raise awareness for Cancer of the Balls and Cancer of That Other Thing, and mens’ health in general. The folks at my church are holding a creative moustache growing competition tomorrow, and the prize is a pair of Leafs tickets. i couldn’t care a fig about hockey, but the moment someone says “creative competition”, i’m in, and i’m in deep.

The Foundation

A creative moustache growing competition is more of a creative moustache grooming competition if you think about it. To that end, i figured it would be wise to grow as much hair on my face as possible, without risking the townspeople loading up their shotguns with silver bullets. So i decided to lay some follicular groundwork – the raw slab of marble from which my masterpiece would be hewed.

Ryan Henson Creighton Movember 2010 Before


An hour later, with the help of my wife and resident manscaper, armed with scissors and a safety razor (NOT electric clippers, which would be like winning the Olympic 100-meter dash with a bionic leg), we gingerly chipped away at it until we got exactly the effect we were hoping for.

Ryan Henson Creighton Movember 2010 After


i call it “The Blustery Day”.

December 1st is my birthday, at which point the moustache goes out and the presents come in (i am registered at Toys ‘R’ Us, in case you’re racking your brain trying to think of what to get me). It was an amusing adventure, and while the beard gave me a distinct confidence boost after the first two awkward weeks, it still felt like i was being stabbed in the face by thousands of microscopic men with tiny little spears. A face phalanx. A facelanx. i dunno. i’ll be glad to get rid of it, anyway.

The Results

For the entire month, Untold Entertainment’s team of one has raised exactly zero dollars in the name of mens’ health. We didn’t take donations. (It’s not too late to kick a couple of bucks over to people who did!) But consider this a promise that in future years, the Untold Entertainment team is one you want to get behind with your pledges, because we’re bringing our (hairy) game faces. An Untold Entertainment moustache is money well spent.

Join us next year. And in the mean time, make sure to give the boys a jiggle at least once a day to avoid Cancer of the Cajones (AKA Huevos Canceros). Or better yet, get your loving manscaper to do it for you.

Can’t get enough of moustaches? Check out our game-in-progress Putty Crime: On the Tail of the Foxy Badger, in which every single character (including the pigeons) have lip sweaters. Good show!

Further Reading:

Where Credit is Due

[this article was originally posted on]

Credits are those long, scrolling pages of text at the end of the movie that you watch just to see if the filmmakers added a special jokey tack-on scene at the end of the flick. If you read closely, you’ll see that they are the names of people who worked on the movie, listed alongside their job titles. In film, there are credits for the big people – the executive producer, the director and the principal actors – all the way down to the little people – the sandwich grip, the second-line gaffer, and the assistant schloob.


The elusive and rarely-seen credit roll, photographed here in its natural environment.

If you look closely, you’ll begin to see credits everywhere. They’re tacked on to the beginning and end of teevee shows, they’re inside album liner notes, and they pop up at the end of your favourite home console or computer video games. But the one place you won’t find them is in online free-to-play Flash games – partly because Flash game developers decide not to put them there, and partly because developers are actively blocked from adding credits to their games by corporations with selfish interests.


More than just being a token kind gesture recognizing the hard work and effort people put into an entertainment product, for mature industries like film, television and music, credits are actually a key cog in the machine. The CVs and resumes of performers and technicians rely on the credits system; often, your ability to land future jobs is based on the credits you’ve amassed on earlier projects. Because of this, there are unions and guilds strictly guiding the practice of giving credit, in order to protect entertainment professionals from exploitation.


It’s equally important to protect entertainment professionals from nunsploitation.

The Flash game ecosystem is notorious for being packed with non-professionals, but we boast our fair share of pros. Many game developers do what’s called “service work” to pay their bills. A company will approach a known game developer, and will contract him to build a Flash game to certain specifications. My own company, Untold Entertainment Inc., is just such a developer. We survive on service work, largely building Flash games and Flash websites for clients like kids’ television production companies. If a prodco has a teevee show, especially if it’s targeted towards kids, they’ll also want someone to build them a web game to help promote and extend their brand. Companies like Cartoon Network, Nickelodeon, and Disney regularly contract Flash game developers to build their arsenal of online games.


Disney. i’m posting their logo because i have a death wish.

If you wanted to find out which developers built these games though, you’re largely out of luck. Try fishing through the games on the sites i mentioned and look for production credits – even a single logo of the developer who built the game. With a few rare exceptions, you’ll come up empty-handed, game after game. Before founding Untold Entertainment, i worked at a media conglomerate serving a number of kids’ teevee stations. Throughout my time there, i made over fifty games. i was not credited for a single one.

Keep it Secret, Keep It Safe

Once out in the “real world”, i began to actively ask my clients for credits in the games i produced for them – a logo, at the very least. Credit is one way to boost morale and mutual respect among your developers, and beyond that – it just seems RIGHT, you know? When teevee and film are crediting their most important people down to the very guy who tapes the pylons to the road, it just didn’t seem right that the team or individual who created the entire game wouldn’t be recognized. And having my logo feature in the game somewhere could be a compelling driver for future business. All a prospective client need do is cruise through Cartoon Network’s site, for example, see my logo, and call me up with a contract offer.


With any luck, they’ll call me on the bananaphone.

Aye – there’s the rub. That’s exactly the situation that a client like Disney or Cartoon Network or Nickelodeon wants to avoid. They don’t want anyone else contracting out “their” developers. More competition for developers means that the devs will be more highly paid, and it may be more difficult for them to get their games made if the best devs are in higher demand.

No Promo

The second excuse i hear for not allowing credit is that these companies don’t want to let on that they didn’t do all the work themselves. There’s this strange macho corporate pride in pretending that all of their interactive work was done in-house – or at least, that’s the excuse they all give me. But a quick look through the credits of any special effects-laden film, for example, shows that individual effects shots are farmed out to numerous different special effects houses. This serves the special effects team in two ways: they can say they worked on Blockbuster 2: the Awesoming, and prospective clients can see their name in the credits, which both increases their brand recognition, and enables clients to contract them for new work.


The Awesoming is two and a half hours of explosions, nudity, and Hasselhoff.

But surely, a Flash game developer can at least SAY he worked on a given project, right? Actually, no. Many of these clients specify in the contract language that the game developer cannot even say he worked on the game. That means no screenshots on his site, and no link to the game. The developer must disavow any knowledge that the project ever happened, Mission: Impossible style. On one of my contracts, the client forbade me from ever mentioning i worked on the project. This became a sticking point, and when i fought for the right to promote, the client struck a bizarre bargain: i could promote my involvement in the project anywhere but online. Of course, the web is the only place i ever promote my work with Untold Entertainment.

It Doesn’t Ad Up

You could argue that the work we Flash game developers do for these companies amounts to advertising. Creating a game to promote The Family Guy or the Mickey Mouse Clubhouse shows is tantamount to creating an interactive advertisement online. And since teevee commercial spots don’t credit their creators, games promoting shows don’t need to either.

This argument falls down for two reasons: for one, there’s really no room in a teevee spot to credit the creators, but there’s plenty of room in Flash games, as they’re not temporally limited to 30 seconds. On the second count, advertising agencies promote their work all the time. Visit any agency website, and you’ll see the logos for the brands they’ve repped displayed proudly and prominently on the main page. Many sites actually do list credits for the commercials they created. Industry awards like the Clios list teevee commercial and print ad credits in full on their websites.

2010 Clio Award Winner

The 2010 Grand Clio Award winner

Credits are important. They serve as proof that a developer completed the work he said he did. They help to increase a developer’s brand awareness, and they help new clients reach Flash game developers that they otherwise may not have known about. Clients who refuse to credit developers, and who actively block developers from promoting the work are preventing the industry from maturing in the name of their own selfish interests.

Resistance by Insistence

So what’s to be done? When I started hearing from new clients that they wanted to use me instead of my more well-known competitor, i asked what he’d done to lose their business. Their answer? “He started getting pushy about credit.” Asking for credit, or even demanding credit that is rightly due to us as developers, is apparently hazardous to your health. It can harm your business. It may even be possible to land new contracts simply by forfeiting your game credit. Clients really seem to go for that type of thing.

But you know what i say? Screw that. The solution is for ALL Flash game developers to demand the credit they are due on ALL projects. Even if you’re not in this fee-for-service racket, you should add a Credits link to the main page of your Flash game as a matter of course. You need to create a logo and preface your own game with it – or simply use your own name (e.x. “A game by Ryan Henson Creighton”) Build your personal brand so that if clients come calling, you’ll have established a credit expectation in all of your games.

If ALL Flash games have a credits page (just as ALL teevee shows, movies, album liner notes, gallery installations, operas, stage plays, and nearly every other mature form of artistic expression or entertainment already has), then it will be simply unspeakable for a client to ask that you remove your name from the game. You can also support the IGDA in their efforts to create a Credit Standards guide, and point your clients to that guide during contract negotiations. For our part, Untold Entertainment now requires credit and promotion rights on all of our contracts – otherwise, we simply don’t take the job. If we as developers band together and demand recognition for our creative efforts as they do in so many other entertainment industries, together we can drag online games kicking and screaming from adolescence to adulthood.

Credits: this article was written by Ryan Henson Creighton, assistant schloob.

Understanding Loops

There is a very short list of programming structures you have to learn to be reasonably comfortable in most modern object-oriented languages. Loops are one of them.

It’s a great idea to back up and read Understanding Arrays if you haven’t already. The reason is that Loops and Arrays go hand-in-hand. Loops are the interface we use to do interesting things with Arrays. You might think of Arrays as an mp3 player, and Loops as headphones … if you try to use either of these things separately, they may not seem too terribly useful. But put them together, and boy … beautiful music happens. Unless you’re listening to Nickelback.

That’s why the next article in this series is called Understanding Loops with Arrays. For now, just muscle through this article to understand what loops are all about – i’ll try to make it somewhat interesting. The beautiful music starts playing in the next article.

Pac Man

Your code is usually chewed through, line by line, by an interpreter. The interpreter is like Pac Man. It eats the first line, and carries out its instructions. Then it eats the second line and carries out those instructions and so on, until the end of your program. Earlier programming languages had each statement numbered, and the Pac Man code interpreter would chew through each one.

Commodore Basic

Goodness knows what “poke” meant in the cocaine-fueled days of the 1980′s.

Object-oriented programming (OOP) does away with those line numbers and sends Pac Man flying all over the maze a little bit, jumping into and out of chunks of code.

Pac Man Map

If procedural code with line numbers is like traveling by train on a straight track, OOP is like taking multiple plane flights through TIME PORTALS.

But imagine for a second that your Pac Man code interpreter has to eat straight down the page to the bottom, to the last line of code. If you want to do things more than once, you have to write the command more than once:

// This is pseudo-code, which means you can't really copy/paste it and expect it to work,
// but it's very readable.
eat a power pellet;
eat a power pellet;
eat a power pellet;

Fine. Pac Man eats a power pellet three times.

Hungry Hungry Pac Man

But what happens if your code interpreter needs to do something more than three times? Say, fifty times. Or a thousand? Now you’re going to have that same line repeated a thousand times down the screen. Yuck.

Or even worse, let’s say there are a number of instructions we want to carry out, and we want that set of instructions repeated:

// This is pseudo-code, which means you can't really copy/paste it and expect it to work,
// but it's very readable.
eat a power pellet;
give Ms. Pac Man a smooch;
punch a ghost in the face;

eat a power pellet;
give Ms. Pac Man a smooch;
punch a ghost in the face;

eat a power pellet;
give Ms. Pac Man a smooch;
punch a ghost in the face;

Now you’ve got a real problem. Your little set of instructions, repeated a thousand times, adds three thousand lines to the code – four thousand with line breaks. This code becomes ridiculous to manage and maintain, it looks ugly, and it takes up way too much room.

Enter that frustrated mom from every infomercial ever: “There’s got to be a better way!”

Plastic wrap is hard

Plastic wrap is HARD!

Loops are the better way. You build them to make the interpreter repeat an instruction, or set of instructions, a bunch of times. When the loop is done, the interpreter continues on its merry way down the page, chewing through each subsequent instruction you’ve written for it.

The Anatomy of a Loop

Here’s what a loop (often called a “for” loop) looks like in Actionscript 3 and other ECMA-based languages:

for(var i:int = 0; i<1000; i++)

Let's break it down piece by piece.

You'll notice there are two sections: the declaration line, and those curly braces.

Two main loop sections

The instructions you want to repeat go in between those curly braces, like so:

for(var i:int = 0; i<1000; i++)
    eat a power pellet;
    give Ms. Pac Man a smooch;
    punch a ghost in the face;

That declaration line looks pretty hairy, though. Let's break it down.

Notice that the whole thing is just the word "for" followed by open and closed round brackets. If we completely gut the loop, it looks like this:


Doesn't look so scary any more, yeah?

The stuff between the round brackets is split up into three sections:

Loop header breakdown

  1. Start here.
  2. Keep looping as long as this is true.
  3. Do this after every run through the loop.

The first and second sections are separated by a semi-colon, which is the dot-above-the-comma symbol that we usually use to end our statements.

Names of common punctuation marks

1. Start Here

Loops start here

A "run" through a loop is called an iteration. In order to keep count of how many times we've looped, we use a variable called an iterator. Because the word "iterator" starts with the letter "i", it's common practice to use "i" as the iterator variable name.

So you need to declare and define that variable first, to give your loop a starting point. Depending on how picky your language is, you may have to type the variable (give it a datatype). Here are two examples of loops written in a permissive vs. strict language:

// Permissive, like Unity javascript:
for(i=0; i<1000; i++)

// Strict, like Actionscript 3:
for(var i:int=0; i<1000; i++)

So the only real difference is that in the stricter language, we had to declare the iterator variable using the "var' keyword, and we had to expressly say that it was an integer datatype (whole number) by adding ":int" to the end of the variable name.

Note that you can also declare the iterator outside the loop, and define it inside the loop header:

var i:int;
for(i=0; i<1000; i++)

i like doing this, because it makes my loop header look cleaner. If i have more than one loop in my program, the compiler throws an error if i use the var keyword to declare the iterator more than once. That means that if i quickly copy/paste a loop where the iterator is delcared inside the header, the compiler yells at me:

for(var i:int=0; i<1000; i++)

for(var i:int=0; i<20; i++) // ERROR!  You've already declared a variable called i, dummy.

Meanwhile, this does not throw an error:

var i:int;
for(i=0; i<1000; i++)

for(i=0; i<20; i++) // No error. We're just resetting i to zero.

What this section does is set the value of a variable called i to zero. i is our counter that will keep track of how many times we've run through the loop.

Now, onto the second section of that confusing header.

2. Keep looping as long as this is true.

Loops keep looping

Every time the Pac Man interpreter starts to chew through this loop, he's going to check the second section. This section tells him "you're okay to chew through this loop, as long as this statement resolves to true."

What do i mean by "resolves"? Imagine you take a bunch of ingredients and put them in a pan, and then bake what's in the pan. You've resolved the ingredients into a cake. In the same way, we're going to resolve the ingredients in this statement until they result in either true or false.

Here's an easy one:

3<5 That statement resolves to true, because 3 is less than 5. But this statement:


resolves to false, because 3 is not greater than 5. These are the same rules we follow when we're setting up conditional if statements. If you need a review, check out Understanding Operators, and Understanding Conditionals. (note: i haven't written these articles yet, but they're on the way!)

Things get a touch more complicated when variables are involved. Take this statement:

i<5 That's not as straightforward. i is the name of a variable (a bucket) that holds a value. Whether this statement resolves to true or false really depends on the value of i. If the value of i is 3, the statement resolves to true. But if the value of i is 867, the statement resolves to false. You can put all kinds of complicated nonsense into the second section of your loop header. Regard:

var i:int;
for(i=0; (i<1000 && theSunIsShining) || dogsLoveBacon(); i++)

In English, that second section now reads "run through the loop as long as the value of i is less than one thousand and the value of theSunIsShining is true, OR if the function dogsLoveBacon returns true.

Gross! Let's keep it simple. When i was first learning programming, i'd sometimes write very complicated loop limiters, and i'd always regret it. It's rare that you see anything beyond a simple i in this second section.

3. Do this after every run through the loop.

Loops do this after every iteration

The third and final section of the loop header tells the interpreter what to do after it chews through the last statement inside the curly braces of the loop. The interpreter gets to the bottom, does whatever is in the third section, and then checks the second section to see if it should run through the loop again. (If that's confuding, don't worry - we'll take a closer look at that process in a moment.)

In most cases, this third section will say i++. That's the increment operator, which is code shorthand for saying "add 1 to the value of i". So every time through the loop, the counter goes up by one.

Again, you can make this bit crazy complicated if you like. You could say something like i+=Math.sqrt(beesHaveKnees()), which means "add the square root of the value returned by the beesHaveKnees function to the value of i". You can even comma-separate multiple statements by saying i++, j++, which means "increment the value of i, and also increment the value of j". You can do this, but in day-to-day vanilla programming, and especially just starting out, you'll want to keep this stuff very, very simple.

Follow the Interpreter Through the Loop

So let's trace the path of the Pac Man code interpreter through our loop.

Do the thing in the first section

1. Do what's in the first section first. In this case, we set the value of the iterator variable i to zero.

Check the second section

2. Check to see if the second section resolves to true.

Chew through the statement block

3. If it does resolve to true, chew through all the statements in the statement block (the stuff between those curly braces). A power pellet gets eaten, Ms. Pac Man gets some lovin', and a ghost gets his just desserts.

Execute the third section

4. When you finish chewing through the last statement in order, do what's in the third section. In this example, we increase the value of i by one. The value of i (0) plus 1 equals 1, so the second time through the loop, i equals 1.

Check the second section again

5. Check the second section to see if it resolves to true. In our example, the value of i (1) is indeed less than 1000, so our interpreter should chew through all the statements in the loop body again. He eats another power pellet, plants another kiss, and dispatches another ghost.

Loop 1000 times

6. Let's pretend we've gone through the loop 1000 times. Pac Man's gluttony continues unabated, Ms. Pac Man struggles to cope with her husband's relentless sexual advances, and his plan for spectral genocide is finally complete. At the bottom of the loop, the value of i is 999. (Note: it's not 1000, because we started counting at zero)

Execute the third section

7. The interpreter jumps to the top of the loop header, and does what's in the third section. Adding 1 to the value of i puts it at 1000.

Check the second section

8. The interpreter looks at the second section of the loop header to determine whether it should go through the loop again. This time, i is not less than 1000. (1000 is not less than 1000.) So because this statement resolves to false, the interpreter exits the loop, and continues after the closed curly brace at the bottom of the whole structure.

Exit the loop

9. Our Pac Man-like code interpreter exits the loop and smugly strikes a pose.

A Real-World Example

None of the code in this article will actually run properly, so here's a chunk that will:

var i:int;
for(i=0; i<5; i++)
    trace("The value of i is " + i);

(If you want it to work in Unity javascript, change "trace" to "print" or "Debug.Log", and you should see the results of the loop pop up in the Console window.)

As i mentioned off the top, loops on their own are very useful for keeping our programs down to a manageable size, but they really come alive when we combine them with Arrays. In the next article, Understanding Loops with Arrays, we'll see how these two code constructs, when married, are a match made in programming heaven. And if we're lucky, we'll even see Pac Man tried as a war criminal. Join me, won't you?

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

Understanding Arrays

There is a very short list of programming structures you have to learn to be reasonably comfortable in most modern object-oriented languages. Arrays are one of them.

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!

Many arrays

An AS3 array can hold many arrays, which can each hold many things …

Many many arrays

… and you can nest things even deeper, creating an array that holds many arrays, which in turn hold many 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:


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.


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:


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:


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:


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:


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.


Yub nub! (Translation: “tell my wife i love her.”)

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:


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:


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.

Bad Apple: How the iPod Touch is Built to Break

Two Christmases ago, i bought an iPod Touch 2nd generation and a MacBook to pursue iOS game development.

Recently, the battery power on the iPod has been dropping dramatically. This week, it stopped charging altogether.

iPod Touch battery doesn't last past two years

i took the device to the Apple Store, where the Genius™ in the back told me that the iPod’s battery “is consumable”, and that two years is pretty much the upper limit of use that i could expect from the device.

He offered me exactly one option:

  1. Pay $69 (about a quarter of the price of the device) to swap it for a new one with a fresh battery.


These two devices are the first Apple products i’ve ever purchased. i’ve been hearing for years about how user-friendly the company’s products are, and how they have a mind toward building green products (i believe their latest laptop is made from wood chips and rabbit pellets).

i can’t think of anything less user-friendly than a 21st century device which does not allow its owner to replace its battery. The battery is “consumable”, yes … but consumption implies that i can replenish the consumable, and consume it again.

i consume food on a daily basis, but once the food in my fridge runs out, i replenish it with new food – i don’t pay a quarter of the price to buy a new fridge.

Imagine a world where we were unable to replenish the power supplies in our devices. Car’s battery died? Pay a quarter of the price to trade it in for a new car. Video game controllers? After a few weeks, you need new ones. Watches? Remote controlled cars? Hearing aids? Despite it being a simple process to swap in a fresh power source, all of these devices would become defunct.

Antique chest

This is a millennia-old piece of technology which, once purchased, can last for hundreds of years. It’s built with a consumer-friendly design that enables the user to open it and get at its insides without voiding his warranty.

Green and Greed

There are two angles to this issue: green and greed.

Apple’s design decision to prevent users from being able to replace the battery is an environmental no-no. i’m sure they’ll do all sorts of wonderful things with my traded-in device (like throwing a new battery in it and selling it as refurbished, or planting it to grow an Apple tree or whatever), but because i feel like Apple is ransoming my use of the device, i have half a mind to throw my defunct iPod into the ocean, specifically aiming it at a dolphin’s face. Perhaps i’ll dip it in crude oil a few times first? Apple’s locked design of the device is environmentally unfriendly.


Apple makes me want to kick a manatee in its junk (if i could FIND its junk)

Perhaps more transparently, this is planned obsolescence at its ugliest. To specifically design a device that lasts only two years is irresponsible at best – insidious at worst. Apple knows darn well that after two years, an iPod customer will likely have made a significant temporal, financial and emotional investment in the device – purchasing iTunes apps and songs, sinking time and money into certain iOS games, and integrating the device into his lifestyle (public transit and toilet time, most notably). Squeezing another 25% of the device cost from the customer every two years is a solid way to pad company coffers.

Not a Fan

When i slide the back of my Nexus One Android phone open, there’s a replaceable battery staring back at me. When it gives up the ghost – hopefully beyond the 2-year mark – i can choose to purchase a new battery from either Google or a third party, at significantly less than 25% of the phone’s price ($10 or less on eBay – that’s 2% of the device price).

Apple has its fans, to be sure, but i’m not willing to sacrifice basic consumer control over the utility of my devices for a few shiny logos and a high-profile (yet environmentally irresponsible and ultimately consumer-hostile) brand.


i didn’t mention it in the original article, but things started to go South once i installed the iOS4 update for my device. Suddenly, the battery lasted one hour instead of the days of juice that it used to provide. i mentioned this to the Apple Store guy, who swore up and down that iOS4 has no effect on battery life. He actually made me feel like a bit of a fool for even bringing it up.

Enter the Internet:

So it appears that, non-replaceable battery notwithstanding, the iOS4 upgrade may have devoured whatever juice the “ancient” 2-year-old battery had left in it. i’ll pay another visit to the Apple Store tomorrow to see if i can’t get this sorted out.


Today i returned to the Apple Store, ranting and raving and foaming at the mouth. Craftily, i told the salespeople that i wanted to buy an expensive iPod Touch, but was concerned because the battery wasn’t replaceable. How long would the device last? One guy said “WELL over 2 years … possibly 4 or 5 years.” Hmm. But then a girl i spoke to said that it depends on my usage.

Me:Very well – i pay $400 for the device. How much usage does that get me, at maximum abuse? 3 months?
Her: Probably more than that, but i can’t say for sure.
Me: You can’t say for sure that i’m going to drop $400 on an iPod Touch, and it’s going to last longer than 3 months?
Her: Okay – probably longer than 3 months.
Me: How long? 6 months?
Her: i can’t say for sure.
Me: So $400 won’t even buy me 6 months with the device?
Her: It all depends.
Me: Depends on what? Don’t you have any benchmarks?

By that point, the “Genius” at the back was calling my name. As a (fake) new customer, though, i don’t think i would have made a purchase with such a non-committal answer. At least lie to me, lady. You’re in sales, after all.

i went in hollering and carrying on and telling them that the iOS4 upgrade had destroyed my battery. One Genius had to step in and, in his smoothest “i’m a very very cool dude who works at the Apple Store and check out my awesome tattoos but they’re too obscure for you to understand” voice, he asked me to calm down. Said that iOS4, while very hard on the battery and probably a bad idea for iPod Touch owners to install, had nothing to do with my device’s battery dying. Completely unrelated.

i asked him how an ill-advised upgrade that destroyed battery life could possibly be unrelated to a battery-destroying issue. He said it was pure coincidence that my battery happened to die after i upgraded. i reiterated that after i installed the iOS4 upgrade, my battery life began to rapidly decline over a period of two weeks, going from holding a charge for days, to holding a charge for an hour. He said that when the batteries degrade, they do so very quickly. i called bullshit.

They gave me options. A battery replacement was $99. The other guy jumped in and said they don’t actually replace the battery – they give me a new device, and that would cost me $89. Both numbers were a chunk higher than the $69 mystery figure the “Genius” had offered me one day earlier. i felt like i was playing The Price is Right.

The other “Genius” offered to wipe my device and install iOS 4.1 on it. “Genius” #2 told me that any time i used wifi on the device, i’d have to shut it down by putting the iPod into airplane mode before i pushed the Sleep button. There was still no option to disable the “always-on” wifi problem that iOS4 introduced.

“Genius” #2 also mumbled something to his colleague about there being a software bug on the recharge screen when it showed one red stick, which mine did. Funny – it was the first i was hearing of it.

So i told the guy to go ahead with the reset. He wiped the device, and upgraded to iOS 4.1. Suddenly, the device started to hold a charge. i went home and plugged it in, charging it fully. It took much longer to charge this time, instead of the half hour it took when it was suffering from iOS 4.0. Wifi is off. The battery is draining at a normal, pre- iOS4 rate.

Apparently, iOS4 is not an issue for older iPod Touch devices until Pope Steve says it is. Until then, ranting and raving and demanding satisfactory service in the face of a conflicting and ever-changing customer service response is the only way. You need to be a modern-day Galileo to convince Apple that the universe does not revolve around their company.

But now that my months-old Pocket Frogs saved game file is lost forever, there’s very little compelling me to use my iPod in the near future, charged battery or otherwise.


The HTC-made Google Nexus One phone that i lauded in the original post – the one with the replaceable battery – stopped charging a few months after the warranty expired.