This site is now just an archive over the rise and fall of Flash. The domain flashmagazine.com is available for sale
Login | Register

Developing with Flash

What's different about developing for Flash than a roll-our-own engine?

By Scott Bilas, Oberon Media, Inc. For artists, it's about the same. Make art in Photoshop and check it into source control - Flash can import a variety of formats, including PSD. For audio, hand off MP3's to Flash, or give it WAV's and let Flash do the compression itself. Of course, Flash is much more flexible in that it's easy to find artists with Flash animation experience for contract or full time work. We can simply have them make SWF's and integrate that directly into the game via loadMovie() or dragging and dropping the SWF onto the stage or into a symbol. Or they can edit our FLA's directly, if they're careful. Audio engineers can do the same thing, if sequencing audio into animations.

image

The real difference with using Flash comes with assembling the game - the work our content engineers will do.

Setting Up for Debugging
Flash is an extremely tolerant platform. It will accept and silently ignore any error. This understandably sounds harsh to C++ or C# programmers accustomed to crashes or exceptions, but we've all been to web sites that have put up annoying modal JavaScript errors, or other problems resulting from bad programming. Macromedia understood that not everyone coding Flash tests their work thoroughly, and that most of the problems that result can be ignored to avoid ruining the user experience. So they only permitted two types of errors to throw up a system dialog: an infinite recursion (greater than x levels of call stack), or a code hang (greater than x seconds of code execution without returning to the system). In either case, Flash will put up a dialog. In all other cases, whether a function call is spelled wrong, or a member is accessed on an object instance that doesn't exist, Flash ignores it. This is great for the web experience, but is horrible for development. Important exception: the compiler will catch it, but only when using classes and strongly typed variables - more on this in a little bit.

To help work around this, we need to configure the system to use the debug Player. This involves the following steps:

1. Exit all browsers and the Flash IDE.

2. Download the uninstaller at: http://www.macromedia.com/cfusion/knowledgebase/index.cfm?id=tn_14157

...and run it.

3. Install the Debug Player found at C:Program FilesMacromediaFlash MX 2004PlayersDebug. This can be verified by going to any site with Flash on it (such as the banner on the top of www.macromedia.com) and right-clicking on it. If there is a "Debugger" grayed out in the menu, then the debug version is installed. This menu selection doesn't do anything except show that the Debug version is installed (i.e. it's always grayed out).

4. Create a file mm.cfg in C:Documents and Settings(username) containing:

TraceOutputFileEnable=1
ErrorReportingEnable=1
MaxWarnings=0



Now, when any errors occur that are caused by accessing runtime members that don't exist, or if a trace() is called, Flash will output to the flashlog.txt file in C:Documents and Settings(username). This can be watched during development with a tail program. If using MX components, it's best to filter tail through a grep that removes all the errors that the components cause (those components are not exactly "clean").

Next, we'll need to add the development tools that any game engine would require - a console, logging features, error reporting, and assertions. Note: Flash has no concept of a modal dialog that is callable from code, so asserts that stop the game are not possible. The trick to work around this (assuming we really want to make sure the game stops executing when something bad happens) is to just go into an infinite recursion. Flash will instantly put up a dialog that testers can catch, and the game screen will still be in the state it was at the time of the failure, for a screen shot.

Finally, when we code, we need to make sure to do everything in classes using private access protection when necessary, and use ActionScript 2.0 with strongly typed variables, parameters, and return types on methods. Without classes and strongly typed variables, we don't get any type safety at all - Flash reverts to ActionScript 1.0 mode which will tolerate pretty much anything it tries to compile. But when using them, the compiler will catch almost all of the errors for us. In practice, it's really only necessary to tail flashlog.txt when something bizarre is happening in the code that makes no sense. More often than not, it's a typo.

In order for the strong typing to really work, we need to modify the factory-installed Flash class stubs. The type safety feature of ActionScript 2.0 is disabled on a per-class basis by the "dynamic" tag attached to the class. Macromedia apparently did this in Flash MX 2004 for backwards compatibility. So in order to maximize our chances at finding errors, we need to go through every one of the .as files shipped with Flash and remove the "dynamic" keyword, then fix all the errors that come up from that (as mentioned before, Flash ships with unclean classes). These classes are found in an obscure location - deep breath -

C:Documents and Settings(username)Local SettingsApplication DataMacromediaFlash MX 2004enConfigurationClasses

It's best to take this whole folder (minus the 'aso' subfolder, which is for intermediate object files), check it into version control in a standard location, and delete it from its original goofy location. Then update Flash's global classpath settings to point to the location mapped by version control for these files. This is similar to what we would do with Visual Studio for include or lib paths. Then go through the .as files one by one, removing "dynamic" from each, except for the Function class, which really needs to keep its dynamic tag otherwise many things in Flash will break.

Note: many of the MX components will throw up a lot of compile errors if used with this classpath. At Oberon, we don't use components except for prototyping, because they are so heavyweight, slow, and difficult to skin how we like. So in our projects that use the components that throw errors, we simply set the classpath for each project to point at an unmodified classes folder. It's not the best solution, but then again, MX components are evil.

Organization
Here are some tricks to help keep Flash projects organized, under control, source control friendly, and team friendly.

- Use .as (AS2 class) and .asi (#include from FLA) files as much as possible. Keep all code out of the FLA files, other than the one- or two-liners. Because FLA files are binary, they end up getting exclusive-locked in source control, plus they cannot be diff'd for changes. Developers will end up fighting over who gets to keep the FLA checked out when only code changes are required. If the code is #include'd, or stored in classes (.as files), then this problem is avoided.

- Ok, well avoid using .asi files too. They are a necessary evil in just a few cases where classes can't be attached to objects (such as startup code for the root timeline). Flash compiles them as AS1 code, so they will not be typesafe and can have easy errors creep in. It might even be better to take all that code and store it in a class as a static function, then call that function from where the #include would normally be.

- Use externally shared FLA's for "content" art, broken down by content type (game board pieces and animations, cut scenes, etc.). This will permit art integrators, or perhaps artists, to work on FLA's without affecting code, layout, or running into exclusive-lock problems with other developers. It also helps with keeping large FLA's under control. Whether or not this is necessary really depends on the project size and team dynamics.

- Keep everything off the main timeline in the core FLA, and work exclusively in symbols. Symbols are the most powerful concept in Flash.

- Keep data in external XML files. Audio can go in external MP3 files, if it's more convenient that way (it certainly speeds publishing up).
Flash Performance >>>

 

Next tutorial:
Conclusion

Previous tutorial:
What is a Flash Game?

Get new stories first

Click to follow us on Twitter!

 

Comments

No comments for this page.

Submit a comment

Only registered members can comment. Click here to login or here to register