Flash actionscript 3 differences between throwing code to timeline and using separate .as file

Question

I am student and my teacher keeps telling me to get used to make my flash games in separate .as file, instead of going to flash and building my game using flash timeline and adding needed actionscript 3 codes there, close to places and times where action happens.

He insists this because of some problems, but I really haven´t grasped completely what he means, so can someone quickly explain problems that could occur if I build bigger structure games without separate .as file(s) instead using flash timeline and separating my code?

I feel stubborn resistance in my head because I haven´t had so far too many problems separating my code, and even if he says it is easier for myself to figure things out when code is in same place, but I have tendency to abstract/irrational thinking, so I at least so far don´t see problem with it, to me it seems harder to add all the actionscript 3 to same place... or maybe I am just stubborn fool and I should listen to him... so, can someone explain?

thank you in advance!

Answer 1

Structure:

Like walkietokyo said, having your code separated into objects can make it really easy for you down the road to use your code again. Want to add another type of weapon to level 4 in your game? Easy. new GrenadeLauncher();. Eventually, you'll have a little library of components you'll use in all your projects, saving you plenty of time.

File Size / Memory:

If your entire application is inside a FLA, a user has to download the entire FLA (assuming the content is available on a webpage) before she can use it. For small programs, this isn't a big deal. For massive programs with many different screens, or for games with levels, this can be a problem because everything stays in memory. You can save on download time and memory usage by only keeping in memory what you need.

Working on a team:

Let's say you're making a game and you're coding up level 6. Meanwhile, your artist is adding some art to the library and making some tweaks on the stage. You commit your changes to the version control system, and there's a conflict. Your artist already committed her changes and now you have to replicate everything she did in your version, wasting both her and your time. If you were coding level 6 in level6.as, this wouldn't have happened. Personally, I find this the best reason to code in text files and leave the FLAs for UI and art.

Memory, as in elephant:

Two months down the road, you're going to open up your file and want to find that nice grenade launcher you wrote, but you won't know where to begin. If you code in a structured way in files using packages, you won't need to remember. Just go through your folders, and eventually you'll find mygame.weapons.GrenadeLauncher.as.

Answer 2

Structure. As you will notice as you're getting more familiar with AS3, there is a lot to be gained by structuring your code according to best practices. Not only does it give you more control and more easily read code, it also makes it easier to build useful, reusable object-oriented code.

Even though you're probably good at irrational thinking, your memory likely isn't. And when a colleague will eventually touch your code in the future both you and your colleague will be lost.

Answer 3

I pretty much have the same answer as walkietokyo: code organization and structure. An example can be say you're making a game like asteroids. It can be useful to separate your code out to say: player movement, shooting, bullet and asteroid hit detection, and asteroid movement, and maybe score handling. Then when you (or someone else) revisits it in the future, your code is in smaller bits, easier to digest, with each part focused on a specific thing. Possibly even reusable for something else that may have similar behaviours.

By separating your code out, it can also make it a lot easier to test and debug, since if say there was a bug in player shooting, you wouldn't need to worry as much about the code in all the other sections compared to if it was all in 1 giant fla/file. It can also simply make it a lot easier to just navigate through, rather then having to find it from one long thing.

But I'd also add some minor points in that if you work with multiple people on the same project, separating it out also lets people work on/handle different sections at once and if you're using versioning system to handle your files, comparing 'plain text' AS files are a lot easier then comparing flas. You could even treat the fla as just a 'resource/assets' file and have different versions.