Game Development Reference
If you're not sure where the problem with your program lies, ask yourself whether one or more of
these might be the issue:
Did you save the I]ej*]o file before you published the SWF file?
Did you spell everything correctly and use the correct case?
Did you save the files in the correct location, and do the spelling and case of your folders and
files match the package and class names?
Are all the AS3.0 keywords (such as eilknp, l]_g]ca, and bqj_pekj) a dark blue color? If one
of them isn't, that's a clear indication that you might have spelled or capitalized it incorrectly.
Have you closed all your curly braces and parentheses?
Did you enter the correct class name, Main , in the Class field in the dahhkSknh`*bh] Properties
Did your cat jump on the keyboard while you were in the kitchen getting another cup of
And here are some more general pointers that you should always keep in mind while debugging:
If you receive more than one error message, always try and fix the first one first. Subsequent
errors are usually the result of bits of code that depend on the earlier bits of code working
correctly. Fix the first one, and the correction will cascade through the code and often magi-
cally correct the rest.
Check the line of code that's just above the line that Flash thinks is the problem . Often, small
mistakes in the line above, which might not be big enough in themselves to generate a compile
error, could be enough to trip up the code in the next line down.
Always save the AS file you're working on before you republish it! I can't stress enough how com-
mon an oversight this is. A programmer will find an error and fix it, but then gets exactly the
same error message when the SWF is republished. This is because the file wasn't saved after the
fix was made, so the earlier saved version of the file is the one that Flash is actually
Make only one single change at a time between republishing. If your program worked and then
suddenly stopped working after you made that change, you know exactly what is causing the
problem. If you republish it only after making five changes and it doesn't work, you won't know
which of those five things is tripping you up.
Finally, the programmer's universal mantra: Test Early; Test Often. Do lots of testing and solve
lots of tiny manageable problems early on to avoid having to deal with hulking intractable
problems that can grind your project to a halt later.
Except for a few exceptional cases, this is the last discussion of debugging issues in any detail in this
topic. You'll be on your own from here on out, but the sooner you gain practice debugging your own
code, the better. Experience counts for everything in this realm, and there is no better whetstone
upon which to sharpen your skills as a programmer than a tricky debugging problem.
Also, get used to the Compiler Errors window—you'll be seeing a lot of it! It will become your closest
ally in finding and tracking down problems.