Foundation ActionScript 3, Second Edition (2014)
Chapter 1. Getting Started with ActionScript 3.0
Here you stand (or sit or lie) at the start of a long and perilous journey to becoming an ActionScript developer. Well, OK, maybe not all that perilous—it’s not like there are any dragons, angry trolls, or even anything as dangerous as a mildly annoyed snail—but you can get some pretty nasty finger aches from all the typing.
Umm… where was I? Ah yes, ActionScript. In this chapter, we’ll look at what exactly this thing called ActionScript is, the processes you’ll go through to create an ActionScript project, and what ActionScript can bring to your Flash work.
Toward the end, we’ll dive right in at the deep end and look at an example of an ActionScript 3.0 project in all its naked glory. Don’t worry—you’re not expected to understand any of what’s going on at this stage. The aim of this example is to whet your geek taste buds (everyone has them, even if some people won’t admit it; they’re responsible for that “oooooh” sound we make when we see an iPhone or any other shiny new device). The idea is that once you’ve seen the potential of ActionScript, you’ll be hooked and inspired enough to want to read the rest of this book in one sitting.
Before we get that far, though, I thought it might be nice to take a stroll down memory lane and look at how ActionScript came to be, stopping along the way to sniff the flowers and enjoy the views.
A Brief History of ActionScript
The official definition of ActionScript, directly from our grand overlords at Adobe (http://www.adobe.com/devnet/actionscript/), goes something this:
ActionScript is the programming language for the Adobe Flash Player and Adobe AIR runtime environments. Originally developed as a way for Flash developers to program interactivity, ActionScript enables efficient programming of Flash applications for everything from simple animations to complex, data-rich, interactive application interfaces.
This is a good definition, as you would expect coming from the company responsible for the language, but it doesn’t tell you much about how ActionScript came to be.
What we now know as ActionScript 1.0 first appeared in Flash 5. Previous versions of Flash allowed developers to add commands to their movies to control the playback and store values, but they were basic and it was arguable whether those commands could be called a programming language. ActionScript 1.0 was based on ECMAScript 262, the same family of languages that includes JavaScript.
If you’re the curious type, you might be wondering about ECMAScript. ECMAScript is a programming language defined by a standards body known as Ecma International (which used to be the European Computer Manufacturers Association before it changed its name). This organization helps create, define, and promote standardization for all sorts of highly technical stuff. ECMAScript was created in 1997 with the aim of solving the incompatibilities between the different implementations of JavaScript found in Netscape and Internet Explorer. (In fact, Microsoft’s version was so different that it was called it JScript rather than JavaScript.) ECMAScript has since become the de facto standard for scripting languages on the Internet, which is why Macromedia (now Adobe) decided to adopt the standard for its new Flash scripting language.
ActionScript 2.0 arrived with Flash MX 2004 and was based on a newer version of the ECMAScript standard. Although on the surface this version appeared to have a number of new language constructs—like classes, interfaces, and private and public attributes—it was really a thin veneer over the old version, still compiling down to the prototype-based programming used with ActionScript 1.0. (Not sure what a prototype is? Thankfully, with ActionScript 3.0, we don’t have to go down that road.)
ActionScript 3.0 is based on and compiles with the very latest, bleeding-edge version of the ECMAScript standard—ECMAScript Edition 4 for all you trivia buffs out there—and adds a host of new language features. Because ActionScript 3.0 is fundamentally different from its predecessors and requires a completely new player to interpret it, you can use it only for projects that target Adobe Flash Player 9 and above. ActionScript 3.0 was first available as part of Flex 2, and was then incorporated into Flash CS3.
The Rise of ActionScript 3.0
Adobe released Flex 2 in July 2006 and with it gave the world the ActionScript 3.0 programming language. Flex 2 was designed to provide a rapid development environment for rich Internet application (RIA) development and does not contain the notion of a timeline as in Flash. Instead, the user interface is authored using MXML files (Adobe’s own markup language for defining ActionScript applications using the Flex framework) and ActionScript 3.0 code to create the final SWF files. (Although this is the normal course for using Flex, you also have the option of working strictly in ActionScript without using MXML or the Flex framework.)
You have at least two paths for creating SWF files with ActionScript: the Flash integrated development environment (IDE) or Flex. Since the Flash IDE is the more common choice, much of the text in this book is presented from a Flash-centric view. The basic tenets of ActionScript 3.0 programming are the same whether you use Flash or Flex, so the majority of this book will be useful no matter which development environment you’re using. In addition, toward the end of the book you’ll find a couple chapters on authoring ActionScript 3.0 projects with Flex, so it’s like getting two books for the price of one—a bargain!
If you’ve installed and worked with Flash, you know that creating SWFs is as simple as creating a new Flash file and using the File 
Publish menu command. For Flex, things get a little trickier—or, perhaps, more intriguing and appealing—presenting you with a number of options. If you have purchased and installed Flash Builder, either as a stand-alone application or as an Eclipse plug-in, you can use that to create a new Flex or ActionScript project. You can then run this project in order to create an SWF file. In addition to Flash Builder, you also have the option of using the free command-line compiler. This involves creating ActionScript and (perhaps) MXML files, and then using the compiler to create SWF files from this source. Often, this is accomplished with an automation tool like Ant (http://ant.apache.org/). To find out more about this approach, you can start with a tutorial such as http://www.senocular.com/flash/tutorials/as3withmxmlc.
For years, the term Flash has encompassed multiple meanings such as the Flash IDE, the Flash Player, and the ActionScript compiler. This book will include statements like, “This line tells Flash that . . .,” where Flash is used in a more general sense and is applicable even if you are using Flash Builder or the command-line compiler to create SWFs. For clarity, when referring specifically to a certain component in the larger Flash platform, the text will use the more precise term, such as the Flash IDE. For reference, the Flash platform contains the following technologies: Flash Player, Flex, Flash Builder, Flash Professional, Adobe AIR, Flash Media Server, and BlazeDS. You can find out more at the Adobe website: http://www.adobe.com/flashplatform/.
All the examples in this book (with the exception of those from the Flex chapters) will be presented as Flash files. Because the ActionScript will nearly always be in external files, there’s no reason you couldn’t adapt these examples for use in Flex. In fact, this book’s downloadable files include both Flash files and Flex ActionScript projects, where applicable, to run the ActionScript.
The Flex directories in this book’s downloadable code are not actually what would be considered “Flex,” which usually implies use of the Flex framework and MXML files to control layout. Flash Builder and the free command-line compiler not only allow for compilation of MXML and Flex projects, but also of pure ActionScript projects, which include nothing but ActionScript code. For the chapters not specifically about Flex, the samples are in ActionScript projects.
ActionScript and Object-Oriented Programming
Object-oriented programming might sound scary and official, but when you see and hear it shortened to the common and silly-sounding acronym OOP, it becomes much less daunting. What is OOP? Well, put simply, OOP is a programming technique. It’s a way to write and organize your code to make it easier for you, as a developer, to build and maintain your applications. OOP developers break down functionality into modular pieces that interact in certain, recommended ways.
Back in the dark ages of programming, applications were written using a procedural programming methodology, which basically means that the program started running at the beginning and kept on going through the code in a linear fashion. But this method of programming did not lend itself well to the expansive applications with graphic user interfaces (GUIs) that were becoming more prevalent on the personal computers in everyone’s home. A new way to program was needed to make it easier to build and maintain these types of applications, which were highly focused on user interaction.
This was when OOP appeared—something of a swashbuckling hero with a cape and sword, crashing through a lovely stained-glass window, I would imagine. OOP introduced a new way to organize a program by breaking up an application into small pieces called objects, each with distinct functionality. These objects then took care of interacting with one another to create a seamless program. The beauty of this approach is threefold:
· It’s easy to break down a problem into small pieces and tackle each separately.
· It’s easier to reuse functionality from one project to another.
· It’s considerably easier to debug a well-written OOP application if something goes wrong.
As you might have guessed, since this is a book on ActionScript and I’m spending a bit of time talking about OOP, ActionScript is an OOP language. When you code in ActionScript 3.0, you will be practicing OOP, whether you know it or not. Of course, there are degrees of adherence to true OOP methodology, and there are certainly open debates within the OOP community about how certain things should be done. But generally, there is consensus on some of the root tenets of OOP. ActionScript 3.0 helps to enforce these OOP principles, whereas ActionScript 2.0 and 1.0 were much less strict (that’s not necessarily a good thing). So as you are learning ActionScript through this book, you will also be learning OOP, which will be an added bonus.
The Development Process
If you have never worked with ActionScript, it is important to understand what exactly will change in your workflow for producing SWF files once you make the decision to add ActionScript to your projects. The changes will differ depending on the amount of code you want to add. If you are an animator and want to add a simple preloader to your movie and a replay button upon its completion, the amount of code you will need and the changes to your workflow will be significantly less than if you are creating a game or an online application. In addition, where you add your code and how you incorporate it into your projects will also vary from project to project.
For Flash users, ActionScript’s simplest integration involves adding some code to the timeline using the Actions panel in the Flash IDE. This was the way it was accomplished for many previous versions and still has its uses. For instance, the preloader and replay button mentioned in the previous paragraph might be implemented in such a way, as they are small pieces of functionality that are largely independent of the rest of the movie. In such cases, you can often continue to work as you normally would within the application and add the necessary code to your file once the main content has been completed. It’s a great way to learn the ins and outs of ActionScript without diving headfirst into hard-core OOP programming in external class files.
If you are a Flex user or have more complex interaction to code in Flash, your best bet is to use external ActionScript files that you can reference in the Flash IDE or, in the case of Flex, through MXML. In this case, you’ll need to do much more planning, and the diagramming of code beforehand is an important step. What does this diagramming mean to your workflow?
For animation development, you’ll start with a storyboarding phase. In a storyboard, you mock up the proposed animation in still frames in order to determine storytelling and flow. Figure 1-1 shows an example of a simple storyboard. Including this step in the process helps to ensure that the work on the animation does not go astray. You avoid going down a path where you waste time and need to redo work based on issues that you didn’t foresee.
Figure 1-1. An example of a storyboard for a proposed animation
If you’re developing a game or application using ActionScript to control its logic and interactions, you’ll start by mapping out how code will interact. This helps to flush out problems in the logic and ensure that development stays on track (well, as much as possible). Unified Modeling Language (UML) is a common technique used for diagramming an application’s programming logic, as shown in Figure 1-2.
Figure 1-2. A UML diagram of several classes and how they interact
The extent you need to diagram can change from project to project, and the level of detail at which you diagram is a subjective topic. Typically, though, each box will be divided into two or three sections. The top section is the class name; the second section includes the class properties, followed by the class events and methods. However, in any case, when planning a Flash or Flex project that will include ActionScript, planning the code before you start programming should be considered within your workflow. As tempting as it is to just dive right in and start coding, you can quickly become lost in your code and lose sight of your overall objective (if you even know what it is in the first place).
That’s not to say that coding from the hip doesn’t have its place. Sometimes before starting a more formal design process, you just need to know if something is even possible. The only way to discover that is to sit down and build a rough version that tests all the key elements of your project. This technique is known as rapid prototyping, and the idea is to test all the key functionality without necessarily worrying about best practices or tidy code. Once you know your ideas are possible, you either throw away the code and start again, or refactor the code into something that’s a little more refined.
Once you have done the proper planning and design, and you’ve created the necessary visual elements using the Flash IDE, you can write your code, testing as you go along to make sure that you’re still on the right track. For an animation, you might continually test the movie to see how a motion plays out. In a similar way, with code, you might test a small piece of functionality within the larger application. Instead of tweaking graphics and animation in a timeline, you will be tweaking code to fix errors and add new functionality.
Many of the animations I work on now are all done through ActionScript. I used to build animations in a timeline, small pieces at a time. Now I build animations through code, programming small pieces at a time. The workflow has stayed very similar. Only the method I use to create the animations—code instead of timeline—has changed.
Organizing Your Files
Before you start writing any ActionScript code, you should consider where you are going to store your files. Your ActionScript files should go in the same directory as the main FLA file for your project for Flash users, or in your project root directory for Flex users. This might be individual ActionScript files, or, more often than not, entire subdirectories of ActionScript files divided into packages. However, having a common project root directory is usually a good rule to follow. (Of course, there are exceptions, such as when you’re creating code that will be used by more than one project.)
Modern operating systems have user-specific directories where they can store personal files. On Windows systems, this is C:\Documents and Settings\[username]; on Mac OS, this directory is /Users/[username]. Personally, I like to create a Projects directory in my user directory, with subdirectories for each of my individual projects. That way, I can back up all my projects in one go without needing to hunt for them.
Since all the projects for this book are related, you’ll probably want to create a subdirectory for the book (named Foundation AS3 or something similar), and then have a subdirectory for each chapter. If you download the sample files from the book’s website (www.foundationAS3.com), you’ll find that they are already organized in this way.
Throughout the book, I’ll refer to the project directory as the directory in which you want to store the files for that project. If you’re following the suggested organization scheme, that will be the directory of the current chapter; if you’re using your own scheme, then the project directory can be wherever you want it to be. It’s completely up to you where you want to keep your project files and how you want to organize them.
Adding ActionScript to Your Projects
You can add ActionScript to your projects in several different ways:
· Place code on the timeline.
· Import code from an external file.
· Specify a document class.
· Link library assets to external classes.
Each approach has benefits and drawbacks. Here, we’ll look at each option individually, using the classic “Hello, world” example, which is often the first exercise when learning a programming language—getting your program to come alive, wake up to the world, and greet you.
Placing Code on the Timeline
It used to be quite acceptable for developers to write their ActionScript code directly onto the timeline in their FLA files. Even now, there are times where it’s useful to place code on the timeline, so it’s worth knowing how to do this. Follow these steps:
1. Create a new Flash File (ActionScript 3.0) and save it with the name timeline.fla in the project directory.
It’s a good idea to get into the habit of saving files just after creating them (even before you’ve actually made any changes), and then saving periodically as you’re working. As with any application, Flash could experience problems. By saving regularly, you reduce the chances of losing your work.
2. Select the first frame of Layer 1 of your movie in the timeline.
3. Open the Actions panel by selecting Window Actions from the main menu. (To save your mouse some traveling time, you can also open the Actions panel using a keyboard shortcut: F9 if you’re using Windows and Option+F9 if you’re using Mac OS X.) You should now see the Actions panel in all its naked, brazen glory. The big white expanse on the right of the window is where you write your ActionScript 3.0 code if you want to place it directly on the timeline.
4. Type the following, as shown in Figure 1-3:
trace("Hello, world");
Figure 1-3. The Actions panel in the Flash IDE
5. Test your movie by selecting Control Test Movie from the main menu. You’ll see the Output panel with your ActionScript’s output, as shown in Figure 1-4.
Figure 1-4. The classic “Hello, world” using ActionScript to trace to the Output panel
Don’t worry too much about what the text you’ve just typed in means—you’ll find out in the next chapter. However, don’t let that detract from the fact that you’ve just crafted your first piece of ActionScript 3.0 code. You’re now officially an ActionScript developer. Groovy, baby!
Unfortunately, writing your code into the frames of your Flash movies is not considered best practice. If you can imagine that the code could be on any frame of any movie clip in your Flash movie, you might guess that it’s not a great deal of fun hunting down a specific piece of code if you need to change it. This makes it difficult when a new developer joins a project and needs to discover how things are done (believe me, I speak from experience). In addition, if you are using any type of version control, code directly in an FLA file cannot be versioned and compared easily. In a large software development group, this coding approach also makes it impossible for multiple developers to be working on the same file, which can be done with text files.
Still, timeline code has its place for simple projects or one-person shops. Flash developers have worked this way for years.
Importing Code from an External File
One step up from placing code directly on the timeline is pulling the code into a frame from an external file. Importing code from an external file doesn’t affect how your ActionScript is incorporated into the final SWF file. It just separates your code from the FLA file.
This technique might be useful if the code you’re writing is designed to be part of more than one SWF file, allowing you to make changes just once (to the external file) and have them incorporated into multiple SWF files. Without the ability to import code from an external file, you would need to copy and paste the code into each FLA file that needs to be updated. You’ll still need to publish each movie that makes use of the external file when you make a change; the import happens only at compile time, not at runtime. On the plus side, this means that you don’t need to upload the external ActionScript file to your server along with the SWF file(s), as it has already been compiled.
I’m sure you’re itching to get your code imported from an external file. To do so, follow these simple steps:
1. Create a new Flash File (ActionScript 3.0) and save it with the name import.fla to the project directory.
2. Select the first frame of the movie, open the Actions panel, and enter the following code in the area on the right:
import ImportClass;
var imported:ImportClass = new ImportClass();
3. Select File New from the main menu. Then select ActionScript File from the list in the New Document dialog box, as shown in Figure 1-5, and click OK.
Figure 1-5. The New Document dialog box with a new ActionScript file selected
4. Enter the following code into the text editor:
package {
public class ImportClass {
public function ImportClass () {
trace("Hello, world");
}
}
}
5. Save the file as ImportClass.as in the project directory.
6. Switch back to the import.fla file in the Flash IDE.
7. Test your Flash movie by selecting Control Test Movie from the main menu. You should see the same result as when you placed the code on the timeline, as shown in Figure 1-4, but this time, the code is being pulled in from an external file.
While this method is better than placing all your code directly on the timeline, you still needed to add the import statement in the FLA file, which, once again, makes it difficult to find and manage. Not only that, but although the code was in an external file, it was actually compiled into the first frame of the SWF file as though you had written it on the timeline.
Thankfully, Flash provides two other, interrelated methods for adding ActionScript to your projects, both of which allow for better management of your code.
Specifying a Document Class
Flash CS3 introduced the concept of a document class. This is a movie clip that controls the main timeline in Flash, which is actually a movie clip itself—it just happens to be one that holds everything in your movie. A document class has some extra functionality that you, as a developer, can code. So perhaps the additional code might be kicking off the loading of a series of animations and managing the playback. In that case, you would associate this class with the main timeline of your movie, so that when the SWF file is loaded into the Flash Player, it will immediately run your additional functionality.
This is a pretty advanced topic to bring up in Chapter 1, but to demonstrate the different ways ActionScript can be used, specifying a document class must be noted here. And, in execution, it’s pretty easy to do, as the following set of steps demonstrates:
1. Create a new Flash File (ActionScript 3.0) and save it with the name document.fla in the project directory.
2. Open the Property inspector (if it’s not already visible) by selecting Window Properties from the main menu, or by pressing F3 (Windows) or Command+F3 (Mac OS X).
3. Toward the bottom-right side of the Property inspector, locate the text box labeled Document class and enter the text Document, as shown in Figure 1-6.
Figure 1-6. The Property inspector with the document class added
4. Save the changes to your Flash movie.
5. Create a new ActionScript file and save this file into your project directory with the name Document.as. (Note the capital D, which is a common and recommended practice for classes and class files.) This means both document.fla and Document.as will be in the same directory in your file system.
6. Enter the following text into your new ActionScript file:
package {
import flash.display.MovieClip;
public class Document extends MovieClip {
public function Document() {
trace("Hello, world");
}
}
}
7. Switch back to the document.fla file in the Flash IDE and test your movie by selecting Control Test Movie from the main menu. Once again you should see the same result in the Output panel (Figure 1-4).
Don’t worry too much about what all the stuff you typed means. I promise that by the end of Chapter 3, you’ll know it backward and forward.
Linking Library Assets to External Classes
Linking library assets to external classes in order to use ActionScript in your Flash movie is similar to using a document class. Remember when I mentioned that the main timeline was a movie clip? Well, there can obviously be a lot of examples of movie clips in your FLA—ones that you create and store in the Library and can then drag onto the stage and timeline or attach using ActionScript. In much the same way that the main timeline as a movie clip can have a class associated with it, you can have a movie clip symbol in the library associated with a class. When this is done, any instance of that symbol that is added to the stage, either in the IDE or at runtime through code, will run the additional code that you have added using the external class file.
To test this, you can reuse the ActionScript file you created in the previous example. Let’s take a look at how this works:
1. Resave the Document.as file from the previous section as Symbol.as.
2. Change the references in the file from Document to Symbol, as in the following code:
package {
import flash.display.MovieClip;
public class Symbol extends MovieClip {
public function Symbol() {
trace("Hello, world");
}
}
}
3. Create a new Flash ActionScript 3.0 file and save it with the name symbol.fla in the project directory.
4. Select Insert New Symbol from the menu to open the Create New Symbol dialog box. Click the Advanced button in the bottom right to get the expanded dialog box, as shown in Figure 1-7.
Figure 1-7. The Create New Symbol dialog box for adding new library assets
5. In the Create New Symbol dialog box, enter Symbol as the name of the symbol and set the symbol type to Movie clip. In the Linkage section, select the Export for ActionScript option. A number of fields will then be filled in automatically, as shown in Figure 1-8. You’ve specified that this symbol will actually create instances of the Symbol class you coded.
Figure 1-8. The filled-in Create New Symbol dialog box for this exercise
6. Click OK to exit the dialog box. You will be placed in editing mode for the symbol. Click the Scene 1 button on the timeline to return to the main timeline.
7. Open your Library (Window 
Library) and drag an instance of Symbol anywhere onto the stage.
8. Test your movie by selecting Control Test Movie from the main menu.
In this example, you associated an external class file with a symbol in the Library. You can do this for any number of symbols and thus have instances of many different classes represented by instances in the Library. The components that come with Flash use this technique, with each component mapped to a class and its ActionScript file.
Now that you know about the different ways to use ActionScript, you may recall that I promised you a more complex example of an ActionScript project. As I’m never one to go back on my word, next you’re going to create something that would be impossible to do in Flash without the help of ActionScript: random animation in the form of hundreds of balls bouncing around the screen.
Bouncing Balls
Building a Flash movie with balls bouncing all over the screen is something of a rite of passage in the ActionScript world—everyone seems to build one at some stage to test coded animation and basic physics. It’s a great way to see some ActionScript in action as you start out on your programming path.
As I mentioned at the beginning of the chapter, you shouldn’t try to understand the code behind this example. I promise that by the time you’ve completed Chapter 5, you’ll understand every single line of code, but for now, you’ll have to trust me that the steps you follow will produce the desired result.
Figure 1-9 shows what we’re going to produce.
Figure 1-9. The balls they are a-bouncin’
Without further ado, let’s get cracking. You’ll need Flash CC installed to play along, though Flash Builder users can find a Flex-tastic example in the downloadable files.
Creating the Flash File
As in the previous short examples, you begin by creating a Flash file:
1. Create a new Flash File (ActionScript 3.0) and save it with the name bouncing.fla in the project directory.
2. Draw a filled circle on the stage with a diameter of roughly 50 pixels.
3. Using the Selection tool, select the circle and convert it to a symbol by selecting Modify Convert to Symbol from the main menu, or by pressing F8.
4. In the Convert to Symbol dialog box, give your symbol a name of Ball. Set the registration point to the center. Check the Export for ActionScript check box. Enter Ball in the Class field. You might need to switch to advanced mode by clicking the Advanced button to see all of the options. Your dialog box should match Figure 1-10.
Figure 1-10. The Convert to Symbol dialog box with all the necessary fields filled in for the Ball class
5. Click the OK button. An ActionScript Class Warning dialog box will pop up, telling you that Flash couldn’t find the class you have specified and that a class will be generated for you when you publish your SWF, as shown in Figure 1-11.
Figure 1-11. This warning lets you know that no class was found and so one will be created behind the scenes upon compiling
6. You know that the Ball class doesn’t exist because you haven’t created it yet, so it’s safe to click OK and ignore the warning. Generally, it’s better to create the class first before trying to associate a symbol with it, but there is no harm in creating the symbol first as long as you understand the warning.
7. Save the changes to your Flash file.
That’s it for the Flash file for now. Next you need to create the Ball class that Flash was looking for and couldn’t find.
Creating the Ball Class
Ball is going to be an external class file. It will be similar in structure to the Document and Symbol classes you created earlier, but a little more complex since you want the ball to bounce around the screen and not just say “hello.”
1. Create a new ActionScript file and save it with the name Ball.as in the project directory.
2. Enter the following code, which is the code that makes the ball bounce around the stage. Again, you don’t need to understand it now, but by all means, read through it. ActionScript is quite readable for a programming language, and you don’t necessarily need to understand it all to get a rough idea of what a particular piece of code is doing.
package {
// Import necessary classes
import flash.display.MovieClip;
import flash.events.Event;
import flash.geom.ColorTransform;
import flash.geom.Rectangle;
public class Ball extends MovieClip {
// Horizontal speed and direction
public var speedX:int = 10;
// Vertical speed and direction
public var speedY:int = -10;
// Constructor
public function Ball() {
addEventListener(Event.ENTER_FRAME, onEnterFrame);
// Colors the ball a random color
var colorTransform:ColorTransform = new ColorTransform();
colorTransform.color = Math.random()*0xFFFFFF;
transform.colorTransform = colorTransform;
}
// Called every frame
private function onEnterFrame(event:Event):void {
// Move ball by appropriate amount
x += speedX;
y += speedY;
// Get boundary rectangle for ball
var bounds:Rectangle = getBounds(parent);
// Reverse horizontal direction if collided with left or right
// of stage.
if (bounds.left < 0 || bounds.right > stage.stageWidth) {
speedX *= -1;
}
// Reverse vertical direction if collided with top or bottom
// of stage.
if (bounds.top < 0 || bounds.bottom > stage.stageHeight) {
speedY *= -1;
}
}
}
}
3. Save the changes to your ActionScript file.
4. Switch back to the bouncing.fla file in Flash CC and test your movie.
If everything has gone as planned, you should see the instance of the Ball symbol that is on the stage bouncing around, as in Figure 1-12. It might be a surprise to you to see the ball colored differently than what you created on the stage, but that is due to some code that colors the ball randomly when the movie starts (look for the lines with ColorTransform). If you do not see this or get an error, check your file against the Ball.as file included with this chapter’s downloadable files.
Figure 1-12. The ball is bouncing
You have one ball bouncing around the screen, but that’s not exactly going to set the world on fire, is it? Let’s scale it up.
Adding More Balls
Your goal is to get 50 balls bouncing around the screen in random directions at random speeds. To do this, you first need to set up a document class for your bouncing.fla file. Then you’ll create the Bouncing class so that it produces the Ball instances, places them at random points around the stage, and sets them off at random speeds and in random directions.
1. Switch back to the bouncing.fla file in Flash CC and save the file as multibounce.fla.
2. Delete the single instance of the Ball symbol from the stage. You’re going to create all the balls using ActionScript, so you don’t need anything on the stage for this example to work.
3. Create a new ActionScript file and save it with the name MultiBounce.as in the project directory.
4. Enter the following code. Again, feel free to look through and see if you can guess what might be going on here.
package {
import flash.display.MovieClip;
import flash.events.MouseEvent;
public class MultiBounce extends MovieClip {
// Number of balls to create
private static const NUM_BALLS:uint = 50;
// Constructor
public function MultiBounce() {
stage.addEventListener(MouseEvent.MOUSE_DOWN, onStageClick);
}
// Handler for when stage is clicked, creates balls
private function onStageClick (pEvent:MouseEvent):void {
stage.removeEventListener(MouseEvent.MOUSE_DOWN, onStageClick);
// For each ball to be created
for (var i:uint = 0; i < NUM_BALLS; i++) {
// Create new Ball instance
var ball:Ball = new Ball();
// Places ball at mouse click
ball.x = pEvent.stageX;
ball.y = pEvent.stageY;
// Specify random speed and direction
ball.speedX = (Math.random() * 30) - 15;
ball.speedY = (Math.random() * 30) - 15;
// Add new Ball to stage
addChild(ball);
}
}
}
}
5. Save the changes to the MultiBounce.as file.
6. Switch back to the multibounce.fla file.
7. In the Property inspector, enter MultiBounce in the Document class field, as shown in Figure 1-13.
Figure 1-13. Setting the document class for the FLA
8. Save the changes to your Flash file.
9. Test your movie. The stage should initially be blank. Click the stage, and you should see 50 pretty little balls of different colors bouncing all over the stage (as in Figure 1-9).
There’s much more you could have done with this example, but I didn’t want the bells and whistles to get in the way just yet. What you did create, with only a little code, is a movie that required user interaction, then responded to that user interaction by creating and animating a large number of graphics that were positioned and colored through code.
ActionScript in Action
I hope the bouncing balls example has done enough to convince you that reading the rest of this book will be worthwhile. But if it hasn’t, here’s a short list of just some of the cool things that you will be able to accomplish with a newfound knowledge of ActionScript:
· Websites that invite interaction
· Online video games
· Interactive banners
· Dynamic animation
· Complex visual effects
· RIAs (a very big category)
If you are using Flash and would like to create any of these, ActionScript is your ticket on the bus, so to speak. It is a necessary tool for any Flash developer, and, believe me, a lot of fun to play around with. In fact, I envy you a little the thrill of discovery of what can be done with ActionScript. I remember when I first started out and experimented with creating an animated star field that you could fly through. I stayed up all night working it out for myself and, in the end, it was exhilarating as I flew through the stars on my screen. Now if that isn’t a metaphor that belongs in a book on learning code, I’m not sure what is!
Summary
This was a brief chapter, intended to give you an insight into what ActionScript is and what it can do. You learned the definition of ActionScript and had a quick look at its history. I explained how Flash and Flex are related, and how both of them make use of ActionScript 3.0 to provide interactivity and advanced features. Finally, you created some basic ActionScript code to demonstrate the various ways in which you can integrate ActionScript into your Flash projects.
You have already begun your journey toward becoming a full-fledged ActionScript developer. In the next chapter, you’ll learn about the fundamental building blocks of the ActionScript 3.0 language. It’s going to be a wild ride, so if you want to grab a coffee, be sure to put it in a mug that won’t spill, then head on back to your computer and the book for some exciting chapters ahead.