Foundation Game Design with ActionScript 3.0, Second Edition (12 page)

Figure 1-43.
There are many perspectives to choose from, if you need them.

You should know that these perspectives exist, but you probably won't need to use any for the projects in this book.

Another issue to keep in mind is that if you double-click the title bar of any window, it will expand to fill the whole workspace. Just double-click it again to make it shrink back.

Occasionally you'll compile a program and even though there are no error messages, the program won't seem to behave the way you expect it to. Recent changes you'd made to the program won't seem to have taken effect, and you can't find anything wrong with your code at all.

If this happens, you'll need to reset the compiler by doing a clean compile of your program. To do this, select Project
Clean. Select the project you want to clean and click the OK button. The compiler will now recompile your program from scratch.

When your program or game is completely finished, it's a good idea to create a
release build
of it. This is an SWF file that is slightly smaller in size than the SWF file that's created when you run and debug your programs. The reason it's smaller is because it doesn't contain any debugging information or trace statements. The release build SWF should be your final product.

To create a release build SWF file, select Project
Export Release Build from Flash Builder's main menu. A new window will open with options that you will probably never have to change. Click the Finish button, and Flash Builder will make the SWF file for you.

When it's done, you'll find the release SWF in a folder called bin-release in your project folder, as shown in
Figure 1-44
.

Figure 1-44.
Create a release build SWF, which is smaller in size that the SWF files that are created during debugging.

At the end of this process, you have a SWF file that you can take to any computer and run, as long as the Flash Player is also installed on that same computer. The fact that the SWF file needs the help of the Flash Player to run is very important. As a game designer, you need to know why this is and the kinds of limitations it might impose on you. Let's take a closer look at what's going on behind the scenes when you publish a SWF file.

AS3.0 is a type of
high-level programming language
. High-level programming languages, such as Java, C++, and Visual Basic, are designed so that humans can easily read, write, and understand them. They use real English words such as “function” and “class,” and use elements of English grammar such as quotation marks and semicolons. But computers don't understand English. Try asking your computer for help with the dishes this evening, and I expect you'll get nothing but a stony silence. (If not, let someone, hopefully a professional, know about it!)

At their most basic level, computers understand only a binary language of 1s and 0s. All the AS3.0 code has to be translated into binary code so the computer can understand it. Fortunately, you don't have to do
that manually, so you can put away the pencil and paper. Flash has a built-in compiler (a software component that translates code) to do the job for you.

Keep in mind that, unlike writing a program in a language such as C++ or Visual Basic, Flash's compiler doesn't compile your code so it's directly readable by your computer's central processing unit (CPU), which is your computer's main brain. It compiles it only so that it can be read by the Flash Player software.

Before you can run any of your AS3.0 programs, the Flash Player software has to be installed on your system because it's the job of the Flash Player to interpret your code to the CPU. Because of this, AS3.0, like Java, is known as an
interpreted programming language
. Interpreted languages use a piece of software known as a
virtual machine
, which acts as an interpreter between the CPU and your program. The Flash Player is AS3.0's virtual machine.

Interpreted languages have a number of advantages over languages that compile directly to the CPU. Most importantly, it means that your programs will run flawlessly and exactly the same way on any operating system (Windows, Linux, or Mac OS X) that has the Flash Player installed. You only need to write your code once, and the Flash Player, which is written for each operating system that it's available for, will take care of the job of making sure your code runs properly. The other advantage is that the Flash Player protects the computer it's running on from any code that you might have written that could accidentally freeze or crash your system. All this tends to make interpreted languages very convenient and reliable languages in which to program.

One major disadvantage with interpreted languages, however, is in the area of performance.
Performance
is a bit of computer jargon that basically means how efficiently or quickly your program runs. Imagine visiting a foreign country where you don't speak the language, but instead are accompanied by a translator who painstakingly translates every word you say and then translates each reply back into English. It would be a very slow and tedious process. Unfortunately, this is exactly what's happening between the Flash Player and the CPU when you run your AS3.0 programs. How slow is it? Exact numbers are hard to come by, but a reasonable estimate might be 10 to 20 times slower than if the code were compiled as binary machine language and running directly on the CPU. (By “slow,” I mean exactly how quickly the CPU can process each instruction or calculation your program asks it to perform.)

Adobe has done a great deal with each successive generation of the Flash Player to improve performance, but this is a major handicap for game developers who depend on squeezing every iota of processing power out of a system to maximize performance in their games. This is why 3D Flash games, which require a vast amount of processing power to calculate geometry, struggle to compete with the rich graphic splendor of 3D on the game consoles (such as the Xbox, PlayStation, and Wii.) The consoles use custom compilers that optimize all the game code to run directly as machine language on their specific processors.

If you're thinking of eventually getting into game design for consoles, however, you're still in pretty good shape with Flash: the skills you'll learn by programming in AS3.0 can be directly applied to programming for consoles when you're ready to take that step. The AS3.0 programming environment is also probably the most user-friendly programming environment you can learn in. And, hey, make a game with Flash, post it on the Web, and you've got a potential worldwide audience for it—that's power!

Before this chapter closes, let's take a quick look at an aspect of programming practice called
naming conventions
. You might have noticed something peculiar about the kinds of names that you gave the file, class, and method names. Look at the choice of file name for the AS file:

Does it look a little strange to you? It should. You'll notice that the
H
and
W
are uppercase, and there's no space between the two words. This is a style of giving things names that programmers affectionately call
camel case
(also known as
humpBackNotation
). Can you guess why it's called that? I'm sure you can!

With camel case, you can write a compound phrase using more than one word. The words are not separated with blank spaces, and the phrase is still easily readable by you and by AS3.0. Blank spaces in the middle of compound names are the programming equivalent to foxes in a chicken coop—avoid them at all cost! The AS3.0 code compiler throws its hands in the air when it encounters a blank space where there shouldn't be one, so camel case was developed by programmers as an efficient way of writing compound words or phrases without spaces. You should also avoid blank spaces in any of your folder names, because if you're using an IDE other than Flash Builder, the underlying Flex SDK that compiles your code can't process paths to files that include spaces.

Camel case is an important feature of naming conventions, which are rules that programmers decide on before they start a project about the style they'll use for creating package, variable, class, object, method, and file names. By strictly sticking to these naming conventions, programmers are better able to dodge the easy-to-make errors that come from misspelling or incorrectly capitalizing any elements in their code. They can also easily see what kind of programming object they're dealing with simply by the way it's been capitalized.

There are two types of camel case that you'll be using throughout this book.

• Lower camel case
  : startsWithLowerCaseLetter. You'll be using this case for package names, variables, methods, and instances.
  
• Upper camel case
  : StartsWithUpperCaseLetter. You'll use this case for class names and constructor method names. You'll also use it for the names of AS class files such as HelloWorld.as and Main.as, which must be named exactly like the class they define in the file.
  

Because ActionScript is a case sensitive programming language, keep in mind that helloWorld is different from HelloWorld, which is different still from helloworld. Make sure that you follow all the capitalization as it appears in the text; otherwise, your programs won't work. If you write a program that seems perfect in every way but just doesn't run, check your spelling and capitalization! This is one of the most common mistakes that novice programmers make, and many a programmer will tell you tales of woe about debugging sessions running till 4 a.m. where the culprit, when eventually smoked out, was revealed to be a single misspelled or incorrectly capitalized word. The author of this book refuses comment!

Well done! You've written and published your first AS3.0 program! It wasn't so hard, was it? In fact, congratulate yourself for getting through one of the most difficult chapters in the book. I've laid the programming foundations for all the games and projects to come, and you'll find that you'll use this same format for setting up your programs over and over again in your career as a game designer.

This chapter has covered a lot of theory, and if you are new to programming, you might have found some of it a bit heavy. I sympathize with you! But you don't necessarily need to completely understand all the theory to create games. The most important thing is that you know what programming code you need to use to get the results you want. A deeper understanding will come with time, a lot of trial and error, and doing as much experimenting with your own projects as you can.

A deep dark secret that most programmers often don't like to share with the rest of the world is that a great deal of the world's software is built with a little bit of understanding and an awful lot of copy/paste. That's all part of the learning process. Of course, you need to know exactly what bits of code you need to copy and paste, and how to change them to get the results you want, which is something only experience (and this book!) can teach you. But as time goes on, you'll soon recognize the usual suspects and be copying and pasting along with the best of them.