Bad Flash Programming – Case Study
21 Oct 2007 2 Comments
Way back in 2003, when I was just starting to seriously work with Flash, I was inspired by the vast array of games popping up on the internet to create my own, making a slight nod to the sci-fi genre, and computer games from my childhood including Monkey Island and the lesser known, but very cool, Omnicron Conspiracy.
This was my first attempt at any kind of serious ActionScript programming, so now with ActionScript 3.0 on the horizon I’m now going to deconstruct why it was all really not very good.
Organisation and Naming
The main reason to organise your file is to make it easy for yourself and others to work with, make changes, and return to at a later time to make updates.
Layers

So here’s a little snapshot of my FLA file. I’ve made some attempt at naming layers, even categorising them, but I’ve been a little lazy and missed some out. This is going to make it quite difficult if I want to change something on a specific layer. If I’d carefully named all my layers with an appropriate and consistent naming convention, then put them into relevant folders, searching for things would be a much easier process.
Library

It’s not just in the layers section that setting naming conventions and organising folders is helpful. As you can see in this screen of the library I’ve named the symbols with some relevant names, but there is no naming conventions or organisation, which again is going to make it difficult to find a specific symbol I’m looking for.
Actions & Functions

Right, now the really crazy part of the programming. See all those little a’s, I’ve put code in every frame, and on quite a lot of the layers. Many of these are also repetitions of what was on the frame before. There is also code on symbols within the stage. If I want to find out what is happening within the programming I’ll pretty much have to read through almost all of these frames and layers, even then I’m going to have to decipher how it all works. So, to make the application easier to work with, I would be better doing the following:
Actions
Placing all the actions on the one layer makes the code easy to find and debug, this is especially helpful if you are creating a complicated application. You can also create a separate ActionScript (AS) file to keep all your actions together.
Functions
According to Flash…
A function is a script that you can use repeatedly to perform a specific task. You can pass parameters to a function, and it can return a value.
This means I can create one piece of code that I can use once, or be called again using one line of code, instead of repeating the full code each time. So, if I’d created functions for certain repeated tasks, there would be less code throughout the file, and it would be a more streamlined file to work with.
See the example below:
Use this, once:
check_money = function () {
this.onEnterFrame = function() {
if (_root.moneyAmount == 0) {
_root.moneyHave = 0;
} else {
delete this.onEnterFrame;
}
};
};
And whenever you want to use the function use:
check_money();
Instead of the following on every frame within the layer:
if (_root.moneyAmount == 0) {
_root.moneyHave = 0;
}
Structure, Timeline & making it all Dynamic

Another thing that makes my FLA file very messy and difficult to amend is that everything is placed along the timeline. Each background tile and line of conversation has all been placed on each frame. All movements are animated in movie clip within movie clip. This makes the file very rigid and time consuming to develop, as each item is fixed.
Changing the Scene
Using the attachMovie() function means I could store each scene in the library then load them in as needed.
Movement
Instead of animating the character along each path I want him to take I could create one movement function, then every time I wanted him to move I could just call the function including the coordinates for where he should stop.
Dynamic Text
With dynamic text I could create functions to control the lines of conversation and their consequent actions, rather than place different static text on every scene.
Which means…
Creating an application in this way creates:
Increased flexibility – It would allow amendments and additions to be made easily, making developing the application a smoother process.
Increased transferability – The code can be reused again and again in other applications, saving time and effort in the future.
End results
Just to keep you a little longer, here is the flash game, still a bit buggy and rather cheesy. I always meant to create a next chapter for it and develop it further, but hopefully you’ll enjoy it anyway.
2 Comments (+add yours?)
Leave a Reply
RSS
Nov 07, 2007 @ 15:57:46
I had no idea they had brought out any Monkey Islands after the second one! Played both on the old Amiga, but now I’ll have to see if I can get them for the PC. There goes the last of my spare time…
Loving the blog by the way!
Nov 07, 2007 @ 16:01:21
DO NOT PLAY THE THIRD ONE!!! It’s very upsetting after the second. I’ve not actually played the fourth one, after being burned by the third, but I may eventually give it a go. Every few years I give the first two a play again though!