Over the past few days, I've been dusting off and polishing my animated skinmesh baseclass (CModel.inc), and thinking a lot about how best to implement support functionality for performing blending of animations / transitioning between animations.

What I really *don't* want to do is to implement this stuff in each 'Character class' derived from CModel, really I think that this stuff ought to be implemented in the generic CModel class, thus decoupling it from the specifics of a given model or class of models (for example 'biped').

I'm tempted to implement this via a homemade scripting language (with full support for timed sound effects etc), and I am curious to know if anyone has already been down this road (I'm curious to see what kind of semantics other people used).

Posted on 2006-11-10 22:09:29 by Homer
An excerpt from an AI "behaviour", which takes care of animation, sound, particles and other actions  (it's C code) :

if(me->life<100 && age&1 && x>-50)NewDebris(6,x,y);
ON(150)me->dx--;
ON(160)me->dy--;
ON(170)me->dy--;
ON(300)me->dy+=2;
ON(310)me->dx+=2;
ON(450)me->dx--;
ON(600)me->dy-=2;
EVERY(19){
SHOOT3(7,-3,3+age&7);
SHOOT3(7, 0,3+age&7);
SHOOT3(7, 3,3+age&7);
SHOOT(5);
}


EVERY(60){
for(i=4;i;i--){
SHOOT3(7,-5,4+i);
SHOOT3(7,-3,4+i);
SHOOT3(7, 0,4+i);
SHOOT3(7, 3,4+i);
SHOOT3(7, 5,4+i);
}
SHOOT(14);
}
EVERY(100){SHOOT2(6,-20,0);SHOOT2(6,0,0);SHOOT2(6,20,0);}
EVERY(128){
SHOOT3(6,-4,5);
SHOOT3(6,-2,4);
SHOOT3(6, 0,4);
SHOOT3(6, 2,4);
SHOOT3(6, 4,5);
}


An excerpt of another type of "scripting" I've used is (this needs a custom compiler)

// Time : type x y dx dy rz flags behaviour

10 : 1 120 -90 -3 2 0 0 14
15 : 1 80 -70 -3 2 0 0 14
20 : 1 40 -90 -3 2 0 0 14
25 : 1 10 -40 -3 2 0 0 14


60 : 6 200 -10 -4 3 3 0 25
75 : 27 0 -20 0 1 32 0 25
90 : 6 -200 -10 4 2 3 0 25

110 : 1 -40 -90 3 2 0 0 14
120 : 1 -40 -90 3 2 0 0 14

This one will be easier to sequence, and makes it easy to save a game to a file.



You might really not need a script-compiler, but use masm macros to generate+compile the script into an array of bytes. Some of the "opcodes" can be directly calls to predefined functions, and the following bytes/dwords would be the parameters to the func.

P.S. I know it's not exactly what you asked for, but this point of view could help you in the design of a scripting lang.
Posted on 2006-11-11 01:47:25 by Ultrano
This is exactly what I was trying to avoid - hardcoding stuff.
Whether I write a bunch of data to a binfile from a custom tool, or embed it in an exe using exotic macros, I'm forced into a position where the user (currently myself) can't fine-tune anything without a rebuild.

I'm not scared of writing a script engine, I could just override one or two of the components from my assembler project.. what I was really interested in was the semantics of script animation.. the syntax of the language used.. stuff like that.

What we're working with is a little like a mixing bench you'd find in a sound studio, we have N tracks, and each track has N properties such as Speed, Position and Weight.
That is to say, the AnimationController is a Finite State Machine (FSM).
We want to define keyframed transitions (as linear interpolations) from one State to another, but generally we're not adjusting all the fields, often just one.
Unfortunately, m$ decided for whatever reason NOT to define Animation Track as an object.
The way it is now, we have access to an AnimationController object which has N methods for manipulating Tracks and for keying future Events on those tracks.. its really inefficient to define full state transitions for the AnimController, the solution needs to be flexible and able to be implemented at runtime (as opposed to buildtime).
Either I write dedicated transition and blend editing tools (since they do not exist as such), or it gets scripted (plaintext or not).
It's a shame masm can't produce compiled binary data files eh?
Posted on 2006-11-11 10:00:33 by Homer