CS3 observations, what’s up with Is-a clips and Sound?

 Been using CS3 for a bit now, getting to grips with AS3, and what feels like excessive handholding at first is now flowing naturally, and i feel far less prone to silent failures than before. To me this is entirely excellent, good show!

The IDE however, i am less impressed with, and i am hoping to be wrong or ignorant so some of you can correct me in my ridiculous ways.

Overall, i feel as though AS3 integration in the Flash 9 IDE appears tacked on, or retrofitted. Experimenting with AS3 early on in flex and with apollo gave a far, far stronger impression of the strengths of the language than how it appears when used in tandem with the IDE, particularly in how AS3 handles sound and the library.

AS3′s substitution of attachMovie for the movieclip constructor is, while logical on the surface, somewhat baffling to me in practise. In AS2, extending MovieClip required you to declare variables to gain references to clips already instanced in the library movieclip. For instance, extending a movieclip containing a textfield with instance name “nameField” would require var nameField:TextField to gain control of that field in the class. What this gives you on script level is an overview of relevant movieclip members, as well as code completion. In AS3, declaring variables to refer to hand placed movieclip members throws an error:

1151: A conflict exists with definition x in namespace internal.

This effectively forces us to write notes about movieclip members in comments or the like, and denies us code completion. I’m not sure how i’d deal with this more effectively, but i do sorely miss being able to do this in the old fashioned way. If there is a faster, more convenient workflow, please inform me

Secondly, where the Timer class allows us a “safe” way to programmatically trigger callbacks without the setInterval danger of orphaned intervals, the new Sound/SoundChannel symbiose allows us to freely orphan sounds, while forcing us to keep track of separate class instances to have specific control of individual sounds, easily lost should the reference to the relevant SoundChannel be overwritten.

The current sound toolkit appears eclectic, almost chaotic, and in my opinion performs even worse than its previous incarnation

Sound: Loads and plays streamed audio, provides close() method to stop streaming sound, dispatches events to keep track of load progress, takes a soundtransform instance
SoundChannel: gives playback and level information and an event when sound playback ends. Contains another method to stop sound, which DOESN’T work for streamed sound, yet a SoundChannel instance is nonetheless required to alter properties of streaming sound during playback.
SoundTransform: Encapsulates all pan and volume properties previously associated with the Sound class.
SoundMixer: static class containing global methods and properties for all sounds.

Out of these 4, the Sound/SoundChannel relationship with their dual stop methods makes me wonder what the rationale behind it all really was. The SoundChannel class in my opinion has no logical place in the hierarchy given that it doesn’t actually give us any real control of the channel in question. Were we able to declare a SoundChannel and pass it Sounds to play it’d be a different matter. In addition, the name SoundMixer is a complete misnomer, as the class offers absolutely no channel-specific controls, nor does it keep track of currently playing channels.

I applaud being able to source audio externally, but i’m bewildered by the choices of terminology and the weird sound/channel symbiose. The docs insist the API is powerful, but i don’t see how it is, aside from external sourcing of audio.

So overall, i enjoy AS3, but its integration with IDE workflow seems unfinished and awkward.

Anyone want to correct me? Please?

Update: Zeh Fernando off flashcoders informs me:

“When using classes, go to your publish settings, actionscript, and turn off “automatically declare stage instances” and it should behave as it did before — you’ll need to declare stage instances yourself. I agree that’s odd, I use it off, but I guess they decided to add it on by default is so beginners wouldn’t have trouble dealing with elements when coding ‘on the timeline’. “

Party on then

AS2 Pseudo-enumerations and constant collections

Prerequisites: Knowledge of basic Actionscript 2 OOP

Note: I am not assuming any kind of innovation here. I have been made aware that this a method adopted by Adobe for their Flex framework and AS3 best practises, and as such, i appear to have merely been independently clever for once

What are enumerations, and why bother?
Enumerations are a concept i’ve encountered a bunch in the past, but never really understood until recently. Usuallywhen spotted in the wild, they take this form:

enum AIStates{
idle,
chasing,
attacking,
searching,
patrolling
}

What does this tell you, at first glance? We are obviously creating some sort of data structure, an array of what looks like properties without values. From the name “enumeration”, we can assume (and correctly) that each of these values ARE assigned values. As an object structure, the above example would take this form:

AIStates= {
idle = 0;
chasing = 1;
attacking = 2;
searching = 3;
patrolling = 4;
}

Still, what good does this do us? At runtime these values are still just references to numbers, so there’s no REAL advantage, is there? As i was trying to wrap my head around this concept, i did pretty much exactly the opposite of what i should have done; i made an AS2 Enum class with functionality for adding and removing elements.

The fundamental flaw here is that enums are, by nature, static. They are never meant to change, as they describe constant states. You could translate the whole idea, loosely, to a collection of static constants. As such, my class was pointless. No enum should ever change at runtime.

Let’s reaffirm this important truth:
What is a constant? A value that never changes at runtime.

In a game application, a constant could be a player’s default walk speed, its run speed, how much damage a bullet of a certain type does.
It could be the sound a door makes when it opens, the speed at which it opens, how much damage it can take before breaking.

An enumeration, though a collection of constants, is also commonly a collection of string identifiers referring to numeric IDs. At runtime, a conditional checking a numeric value takes considerably less resources than a conditional comparing strings. In this way, for the sake of conditionals and identification, enumeration have an immediate advantage.

function updateAI(actor:Actor):Void{
switch(actor.state){
case 0:
//patrol corridors
break;
case 1:
//chase player
break;
case 2:
//search for player
break;
}
}

Now with an enumeration

function updateAI(actor:Actor):Void{
switch(actor.state){
case States.PATROL:
//patrol corridors
break;
case States.CHASE:
//chase player
break;
case States.SEARCH:
//search for player
break;
}
}

I assume, as a developer, you’re not missing out on the other great advantages here.

1. Readability is greatly improved
2. The actual values of the constants are externalized, meaning locating their values and altering them is much less of a hassle.
3. The constant values are grouped and externalized, meaning they can be referred by multiple classes

The advantages are just too many to ignore. There is one more serious advantage however, entirely at development time: If you use FlashDevelop, Primalscript or any other third party Actionscript IDE with intellisense-style code completion, you will never have to remember the exact value of a constant ever again, nor will you ever have to deal with plain numeric values alone for the advantage of conditional simplicity.

Now for our actual AS2 implementation
Actionscript 2 has no inherent enumeration type, nor does AS3. My implementation is more of a pseudo-enum than an actual barebones enumeration in that it only truly cares about the fact that it’s a collection of static constants. As an AS “traditional” enumeration would force you to type in constant values regardless, there is literally no real advantage to limiting the structure to integer values.
Summing up, our implementation is an abstract class populated by public static variables.

class enums.EnemyStates{
private function Playerstates(Void){
//private constructor, abstract class
}
public static var IDLE:Number = 0;
public static var CHASING:Number = 1;
public static var ATTACKING:Number = 2;
public static var SEARCHING:Number = 3;
}

There you are. A collection of constants referrable by any other class.
A more complicated example, with enum cross references:

class enums.Characters{
private function Characters(Void){
}
public static var ANDREAS:Character= new Character("Andreas",24,enums.CharacterTypes.LEAD_VOODOO_ENGINEER);
public static var GARY:Character= new Character("Gary",enums.Defaults.DEFAULT_CHAR_AGE,enums.CharacterTypes.AWKWARD_SOCIALLY);
}

So we see, our constant collections can naturally hold static instances of any datatype. Commonly, we’d avoid any datatype that actually manifests itself in the application, such a MovieClip or Sound, leading us to a second fundamental truth:

Constants are set before their context has initialized, and do not change during the context’s execution

I strongly urge you to play around with this methodology in FlashDevelop. Since i began using it, i have no idea how i’ll ever go back to initializing constants in every class instance.

Further reading:
enums @ wikipedia

Hello world

Hi, and welcome to my second attempt at blogging about Adobe Flash Actionscript development. With this blog i’ll be attempting a bit of blue ocean strategy. You want cutting edge wow, don’t come here. This is not about technical marvel. This is a blog about making your life as a developer easier, keeping your head healthy, and in general avoiding headaches and gray hair.

My name is Andreas Rønning. I was born in 1982, and this is my 6th year as a full time Flash developer. I started out with Flash 4, and we’re on the doorstep of Flash 9. It’s amazing to think how fast time goes by.

One thing that i feel separates me from a lot of other Flash developers is that i have always had an immediate and deep respect for how development has been traditionally done in the past. When we were creating applications in Flash 4 we were being denied the fruits of our founding fathers’ labor. We had to invent our own methodology, building games and applications in a framework that was frankly designed to let us make fancy animations with limited interactions. I was always interested in how “real software” was being made, how they tackled problems, and how their solutions could be applied to solve mine.

It’s an understatement to say that until Flash MX2004 and Actionscript 2, Actionscript development was a mutant beast. As the platform grew in popularity, developers from other languages got into the game, working their butts off to find ways to gain the benefits of object oriented programming with a toolkit that wasn’t essentially built for that purpose. This is almost an exact parallel to what’s happening to Javascript right now. The resulting hacks and “hack best practises” live on to this day, and have shaped Actionscript development into an unruly animal with few if any best practises that aren’t viciously argued over on messageboards and other fora.

I chose pretty early on that some things require tight optimizing, other things simply need to work right, and as such the development methodologies will always have to be flexible. Some methods are frowned upon for “being slow”, but you should always ask yourself if your codebase will benefit from this relative slowness in terms of readability and reusability (is that even a word?).

I’ll be writing about methods i come across that make my day better, make my code prettier, and helps me meet the deadlines. Stuff that lets me go home with a clear conscience.

Hope you’ll find it useful!