by DST » Mon Jun 21, 2010 6:18 am
It's an attempt at what i called on Regame "Multidimensional Cascading", and it's why i've always disliked strings in programming, precisely because they are so specific. They are probably best for most programming, but I'm imagining cake in the sky where one day all programs will work together in some glorious carnival of a program which will probably never happen, but ....who knows?
Multidimensional Cascading is where you have to synchronize things in completely unrelated dimensions, yet with as few differences as possible. Here's an example:
Gears in a watch are synced by both the size and the number of teeth on them, to result in a sync of A. torque and B. rotation speed (time). But they also sync side by side, in 3d space, A. to fit inside a watch, and B. to use the fewest points of attachment possible (to manufacture you always try to simplify) and C. to work a long time off a small amount of energy.
And the watch casing they fit in must be made to A. be cheap to manufacture B. be strong to last C. be comfortable to wear D. look nice.
And then you have to figure in shock resistance, and corrosion resistance, and, after you've got all that together, and you've designed the perfect watch, now you have to design the factory the watch is to be made in; all the tools and molds and machinery that produces and assembles the watch. The less differences you have between all the previous variables mean less differences in the factory variables. So cascading is all about aligning trajectories to achieve efficiency, leading up to the main producer of the product and how simple that machine is to build and maintain (in this case, the factory is YOU! The machines are the functions you write, and the products are the games you publish. And the less coherence you had in the factors of the watch design, the more expensive, fragile, and complicated the production tools will have to be!)
I always draw my plans around mathematics to achieve the cascade, as much as possible.
In mageslayers, i use a base enemy with many animations and enemy types inside of one actor. Actor enemy has 3 animations for each enemy: attack+run right, attack+run left, and die. So i named my animations thusly:
000
001
002
010
011
012
where 000 was the bird right, 010 was the wolf right, 020 was the mud monster right, and 001 was bird left, 011 was wolf left, etc. etc.
Then, I call the number based on direction towards player, like so:
if(x<player.x){
dir=0;}
else
{dir=1;}
then strncat the dir onto the enemy type, which i was already using in a case switch in draw actor to determine what the enemy did in the first place.
Now i've used actor int type to determine all actions, and type+dir to determine all animations. (with a 0 at the beginning so i can have more than 10 enemies. Note that enemies would be limited to 10 animations each max using this method).
In this case, type and dir had to be cast to char[] to write them to an animation call, but in the end, they were useful for other things (such as the case switch). And they keep in with other mathematical synchronization; such as, the right animations end in 0 and the lefts end in 1, so i can always use math on the 'angle' variable, where right is 0, etc. etc.
As well, i can also use these variables in loops (the coherence i talked about earlier), so i could easily ask for the last number of every animation state of every enemy; And if you were using a WIND spell to blow them back, determine how much they were blown back because i could easily determine which direction they were facing.
That is, without having to ask an "IF" statement every time.