Various Notes
MovieClips don’t get any ENTER_FRAME events until they are added to the stage (via an addChild() or something to that effect). Makes sense.
Layer Carnage
Something that really drives me nuts about Flash is the inability to interact with layers in ActionScript. And before anybody gets pedantic and says that’s mistaken thinking, unask the question, l2flash, git gud or anything like that, yes, I understand (I think) the design choices that make this the ‘wrong’ way of thinking, but I still think it’s stupid.
My understanding is that layers are purely design-side elements, and that once your flash gets exported they’re gone and it doesn’t make sense to try to interact with them at runtime. Okay, I can see that design decision, and fine, you want to be consistent, okay great you win the consistency prize. But as a programmer/builder of interactive things, I want the ability to put objects on different layers at design time and runtime, and that’s just not possible. It doesn’t make intuitive sense that layers go away at runtime. You can place, say, a square on the stage, give it a name and then move it around at design or runtime. Yet layers go away? Why can’t you just name them and they become Sprites or something?
One solution is to create a Sprite for each layer you want when your Engine initializes, then add all your objects to the appropriate Sprite. Which is a fine solution except that it completely sucks, since you have to duplicate your layer structure in code, so hooray we get to build everything twice, what could possibly go wrong, oh and also that will all be on top of the stuff you built in Flash Pro itself, so have fun manually reordering things, or you build it once in code and can no longer design anything in Flash any more. Either way it sucks.
The better way is to add an invisible/size 0,0 display object of some kind at the origin of the appropriate layer, then add stuff in code to those display objects. Of course event the most cursory examination of this method reveals it’s a total hack, but all the same it’s a much better solution: it gives the illusion that layers still exist – each created display object exists at the proper z position already and so it’s like the Sprite solution except sensible.
This is how I solved the problem in the first flash test game that I made; unfortunately that code is miles away and I don’t have access to it, so I’m fumbling trying to recreate it. Do you just place like a square at 0,0? But if you make the size 0,0 or make it transparent Flash just destroys it (…why? Can we not have invisible or infinitely small things?). Kind of dreading the internet search that is to follow.
Okay, 30 or so minutes later the solution: create a new MovieClip in the library and put an instance at the origin of each layer. So I did:
- Insert –> Symbol…
- Call it Layer
- Drag it onto the stage on the proper layer; manually set x and y to 0
- Name the instance – in this case I went with layer_projectiles
There’s a lot of debate on variable name prefixes. Many hatefully oppose it, but I’m going to justify it like this: AS isn’t exactly strongly typed, so it’s not like I’m saying
int __int_myInt; // an integer
or some shit like that. Prefixing with layer_ will let me organize mentally better than just projectiles, enemies, etc.
WordPress Categories vs. Tags
As I’m going to categorize/tag this post I’m looking at my options and thinking two things:
- I don’t really know what the difference between tags and categories is
- So far my choices for categories are ActionScript, Angst, BS, Development, and FMB. Well, all of those categories apply to this post, and every post I’ve yet made. In fact it’s pretty safe to say every post about FMB Development will indeed involve much Angst about ActionScript BS.
So: TODO figure out difference between cats and tags and use them appropriately. Also write about happier things.
Keyboards
For typists, and programmers especially, the right hand pinky finger is ridiculously overused. Unless you rolled a natural 18 DEX it’s absurd to have to type things like:
p0["'>:-0'"] += ‘{p}’;
Especially considering the number of backspaces one will probably need to employ along the way. So I always move my hand when sequences like this are required – which is just about every line of code. But that’s horrible, because then your hand shifts out of home position and chances are you’re going to come back wrong, slowing you even more and making more mistakes.
Furthermore, look at your keyboard: chances are the keys are staggered so that each row is shifted to the left of the row directly below it. This makes sense for the right hand, because it naturally comes in at an angle from the side of your body to the keyboard; to hit the proper key with the proper key you extend the finger forward relative to your hand. But for the left hand it’s disastrous. Your choice is either a really unnatural finger movement, or a horrible wrist position to accommodate a natural finger motion.
I’ve seen keyboards that don’t stagger their rows, but this alone is not sufficient to solve the problem – you need to then tilt the keys to face the hands properly. On a laptop this becomes absurd. Why not stagger the two sides of the keyboard oppositely, then move some of the pinky punctuation keys to the space in the center that opens up? Why has nobody done this yet?
Trigonometry
I’ve done this so many times and each time I have to mega-think my way through it all over again. And I always do it wrong the first time, then the lights dim in the room as I power ponder the solution out. Given that I’m going to forget it the next time I need it, I’ll leave some notes here.
So a ninja throws a star at a dude. That star follows a trajectory that describes the hypotenuse of a triangle with a and b sides equal to the difference in x and y positions start to finish. The star has a velocity which we’ll express as the number of pixels it can move in one second, which will be some percentage of the length of the aforementioned hypotenuse. We’re interested in knowing how far the star will travel in the x direction and the y direction each second.
We need what I’m calling a unit vector, and it can be expressed in a couple ways. We could do it with just an angle and a velocity, which is really easy and vector intuitive. But we need to apply the change in x and y 60 times a second, so we don’t want to make the calculations to translate that vector into its components over and over again. So the better way is reduce it to it’s components once then work with that. (Note that if the momentum changes over time, due to say friction or whatever it would be useful to keep the angle and magnitude around because we will need to make those calculations every time.)
The easiest way to express the unit vector then is as a single point [x,y] which represents the distance from the origin the star can travel in a second. So if our momentum is [3,4] the star will travel (using graphics orientation) 3 pixels to the right and 4 down each second. (Incidentally the total velocity in this case, as we all know, is 5 pixels/second and the angle is… something, whatever, who cares.) Here’s the bit of code that works this out:
var adjacent = target.x – tosser.x;
var opposite = target.y – tosser.y;
// TOA: tan(theta) = opp / adj ==> angle = tan-1(opp/adj), so:
var angle = Math.atan2(opposite, adjacent); //angle will be in radians, as required
momentum = new Point();
// CAH: cos(theta) = adj / hyp ==> adj = hyp * cos(theta)
momentum.x = Math.cos(angle) * velocity;
// SOH: sin(theta) = opp / hyp ==> opp = hyp * sin(theta)
momentum.y = Math.sin(angle) * velocity;
Goddamn it’s late.
Fucking WP
Jesus god is WP ever monumentally failing me right now as I’m trying to put code tags around my code.