Flash development - are you doing it wrong?

Inspired by years of working with Flash and with other Flash developers (ninjas and newbies), here is my checklist of how to do things "the right way" in Flash and ActionScript (don't really know about Flex - you crazy guys do whatever you like!). I really want your comments on this one. Am I way off the mark? Do I go too far, or not far enough? Leave a comment please! Here they are:
  1. Don't use code for layout. If you are setting the position of all your visual elements with code, rather than using the Flash IDE, you are doing it wrong. Designers like to "nudge", "align" and "tweak" layouts, and if you have to change a number in your code and republish the swf for every nudge, then you're probably in for a long night. If you have a data-driven site (e.g. with a variable number of menu items), you may have to do some dynamic positioning, but keep it to a minimum.
  2. Don't write code on the timeline. Why? Because you can't search it, open it in an external code editor, version control it or merge it, that's why! Version control and a decent editor (ie. Flexbuilder, FDT or FlashDevelop) will save you many hours of development. These editors have great auto-completion features, and a version control system such as subversion may just save your job one day - when Flash corrupts your FLA or you accidentally overwrite your whole day's work. The only good reason to write timeline code is calling functions or dispatching events during timeline animations (e.g. dispatchEvent(KICK_BALL) when the animation of the foot reaches the ball), but again, keep it to a minimum.
  3. Write lots of small classes. When transitioning from timeline scripting to OOP, a classic mistake is to make one or two big "god" classes that control most of the functionality. If you're doing this you haven't really transitioned to object-oriented code at all. Each class should do only ONE thing, or to put it another way, there should only ever be one reason to change any of your classes. This seemed very prescriptive to me at first, and I still find it difficult, but I've learned to love it! How long should a class be? Well anything more than about 500 lines seems like it could be broken down more. In any particular project I normally have at least a few classes that are only 5-10 lines long. Think about your project as a set of self-contained components that you could re-use if you wanted to.
  4. Use ActionScript3 whenever possible! I've met a couple of people who are still defaulting to AS2 for "simple" stuff. Er, why? Better to get your head into AS3 mode as much as possible, especially on the easy stuff. How else are you going to learn? AS2 is rubbish! You may still have to use it for some banner-ad networks, etc though :(
  5. Don't use the main timeline to organise the "flow" of your site. I used to swear by this method as a way to organise my sections - creating a separate class for each screen, and putting each screen on a different frame. Move to a different frame and Flash will automatically destroy the old section and create the new one. Easy! Only problem: doesn't work in AS3! It will remove the section from the display list, but it will stay in memory, running its ENTER_FRAME, probably throwing errors, and generally doing the naughty. The solution? Create and destroy all your screens / sections from code - e.g. mainMenu = addChild(new MainMenu()); removeChild(mainMenu); mainMenu.destroy(); etc.
  6. Tidy up after yourself. Keep your FLA tidy. Name your layers, name library items sensibly and keep them organised. Delete empty/guide layers. At the end of the project, delete all your traces, unused code, and any commented out code -they will only confuse you later.
  7. Test extensively. Test driven development for a Flash developer should mean running your swf and clicking on everything really fast until it breaks, then fixing it and doing it again. The more complex the application, the more ways there are to make it do something unexpected, throw and error, or generally crap-out.
  8. Know how good you are. This one goes a few different ways. On the one hand, don't be cocky and let your ego write checks your body can't cash. Don't commit to mad schedules or deadlines. Make sure there's contingency time built into every project, because you can pretty much guarantee something will go wrong at some point. On the other hand, don't be lazy or complacent. Don't look for excuses not to change your code or design. If a colleague suggests an improvement, don't just go "No, it doesn't work like that", but think seriously about the cost/benefit of the idea. Keep improving your knowledge and learning new technologies, because if you don't, the industry will eventually leave you behind. Know what you're worth. If your boss is driving round in a sports car while you do all the hard work, you're probably doing it wrong.
  9. Don't use anything obscure. Sometimes I'll make an update to a project that was created by another developer, and I'll experience some weird behaviour, missing files or unexpected errors, and it will because the developer has chosen to use some obscure feature of ActionScript or the Flash IDE. In Flash CS3, it might be menu settings like changing the view preview quality and everything on the stage looking weird, or turning off "export hidden layers" and half your site unexpectedly disappearing. Everyone SHOULD turn OFF "Automatically declare stage instances" though, as it's very confusing to not have all your variables explicitly declared. Try not to use weird language features and optimisations, like backwards loops unless they're completely necessary. Name your functions and variables with full English words please! That includes writing "event:Event" instead of just "e:Event". How can you search through text for a one-letter variable?!
  10. Sweat the details. Polish counts for a lot in Flash sites, so the more time you can devote to little finishing touches, the better. Consider things like: fading in-and-out on page transitions rather than just jump-cutting from one page to another, adding custom options to the right-click menu, disabling the Tab key, optimising the file size and creating a decent preloader.
Hope you found something useful here - trust me, I've learnt these lessons the hard way! Leave a comment if you agree or disagree with any of them, I want to know what you guys think.


Anonymous said…
Good tips from someone who's obviously been in the trenches a while.

I like the first one especially. Some developers think that using the Flash IDE for layout is not 'real programming' and so spend hours nudging code-defined x/y locs trying to match the designer's comps.

2 more I would add:

Reuse Code when Possible. If you use some code more than once, put it in your code library. Try to abstract out stuff like menus/menu items so you don't keep re-writing the same code.

Use Flex Builder to publish your SWF. This may be more of a personal preference, but I find that using AS3 projects in Flex Builder with 'Build Automatically' turned on is a real time saver over publishing with Flash. It also gives access to FB's debugger.

Build a code library as you go
Anonymous said…
Do you not like Flex developers or something, I swear, lol... J/k :-P Erhm, but yeah, id agree with just about all of this, and a lot of this especially keeping your classes small and doing specific things just seem like common sense... I mean that's some pretty basic good coding practice right there. OH and yeah, DEFIANTLY use a separate tool for editing your AS3 code, my god I can not stand the AS3 editor in Flash. Use Flex builder for that sort, that way you will have access to the profiling and debugging tool as well. Even though Flex is more developer centric id say a lot of this stuff applies to Flex as well.
Anonymous said…
About first point "Don't use code for layout":

I don´t compile with Flash for some reasons like you said, corrupted .fla, debugging, version control, etc. I create a Flexbuilder or FDT project and compile direcly with flex sdk. How do I get the library symbols? It´s easy. I have a fla for that. The application loads the resulting "library.swf". I do it with "bulkloader" library, so it´s easy to access any symbol.

How do I layout?
In that "library.swf" I have some movieclips that I call "LayoutTemplates", that have some rectangles inside. I copy that rentangles x and y (sometimes width and height) to my instances, so the designer can change them whenever he wants.

I agree the rest of your advices.
Good blog!
Anonymous said…
all make sense - apart from the final element of point 9. Whilst plain English might make searching for class instances easier one letter argument or object instances are much quicker at run-time.

FDT offers a great instance search tool, that checks not just for the name but also class type. It's a good as a global txt based search.
Anonymous said…
Great post.

I would add to #6 and say that it is helpful/important to make your library structure match your code structure. If you have a MenuItem in your library that exports to a class and the code for your MenuItem is in package "project.navigation.menu" then you should create a folder structure in the FLA that mimics your package structure. You could create folders for project/navigation/menu and then place a movieclip in that menu folder called MenuItem. That way, if you need to nudge layout you can quickly find the asset that corresponds to the class you are working in.
Philippe said…
Good summary - I totally agree about these tips!

@Ickydime: correct, library must be well organized, grouping symbols a bit like your classes.

And BTW for the external editor, I'd mention that FlashDevelop is actually designed to work nicely with Flash.
Anonymous said…
i also totally agree with u but i think one point is missing by writing small classes...
write comments for the ASDoc tool.

It will help u to reuse older classes u have been written and makes it easier to share them with the com ;-)
Alain Kaczmarek said…
Thx for the hints.
About #5 Don't use the main timeline to organise the "flow" of your site :
what would you advice so ?
Vash the Stampede said…

Create a document class that can control the display list for you with a function(s) for adding and removing children.

#11. Use the flash event system or some derivation to loosen the coupling and create your own custom events to push around data. Definitely reduces lots of reference errors while increasing some boilerplate.