Hey everyone, I'm working on my first 2D game using sprites more advanced than a pong paddle, and I'm trying to develop a way to group all of my sprite movements in a script-like way. For example, if the user types the jump key, my sprite will enter an scripted animation that will move him correctly until the animation script is finished. The problem is, I'm having a lot of trouble deciding how to go about this. When I call my animate function during every game loop, I want my sprite to move according to the script he's already in. So at first I was thinking of using callback functions. For instance, if there's no user input, his "idle" movement function would be active and it would do nothing to keep him in an stationary state; if the user preses right, the sprite's "move x-cood right" function will be active until the right key is let go; if the jump key is hit his "jump" function will alter is y coordinate until the jump sequence is over... etc... But then I was thinking about it, and that's a pretty dumb way to implement it. Not only are callback functions nasty to deal with (I'm using C++), but they would only allow 1 function to be active at a time. So moving left or right while in a midair jump would be impossible. Unless I want to use an array of active callback functions... but I'm absoltuely sure that that's going waaaaayyyyy overboard. So to make a long story short, I'm looking for advice... I'm curious as to what the normal method of handling this is. I don't want to program directly in my game loop something messy like "if jump key is pressed, move y coordinate" - that's far too un-modular for my tastes. But then again, if I give each movement it's own modular script, things start getting way too inflexible. I'm sure I'm just not thinking of an obvious way to implement sprite movements in a simple yet modular fashion, so I'd greatly appreciate anyone who can nudge my brain in the right direction...

Generally, movement is done independently of animation. It's the easiest way. In pseudocode:

// moving left:if( left_arrow == PRESSED ){  Position.X --;  if( !moving_left )  {    moving_left = true;    first_anim = WALKANIM_FIRSTFRAME;    last_anim = WALKANIM_LASTFRAME;    curr_anim = first_anim;  }}// later, for the animation:if( curr_anim < last_anim )  curr_anim ++;else  curr_anim = first_anim;

The "*_anim" stuff are animation frame indices of some sort.

Quote:Original post by squicklid
In each one, you could have a struct of movement that contains xchange, ychange, and rotation, or any other type of action, and the duration of each.

Oh ok, that actually makes a lot of sense. It's modular and simple. Originally I was thinking way too object oriented - making a basic movement base class and making a child class for each type of movement, each with it's own overriding movement function. ... yeah that was a bit too complicatd I think. This method gives you modularity with struct/class based movements but without all overhead in speed and code size.

Quote:Original post by CGameProgrammer
Generally, movement is done independently of animation. It's the easiest way.

Oh ok, good... I was going to ask that next. I already have a pretty robust animation system going on. I just call something like MySprite->ActivateAnimation(<animation #>); and it will automatically go through the frame animations for me at whatever speed I want (or the frames can change manually by calling MySprite->NextFrame() ). I was going back and forth on whether to incorporate the movement directly into my animation structures, but that seemed a little restrictive. So I was starting to lean towards keeping the structures modularly independent, yet linked in the game loop code anyway... but thanks for helping me making up my mind :)

So one more question for you all, what is the normal way of handling things like this. To most programmers hardcode directly into one part of the game loop like you suggested at first, squicklid? Do they usually use scripts? Or is it some other way? I've already got my basic "engine" framework in place, so I'm not planning on re-writing anything, but I'm just curious as to what the coonventional standard for it is.

Just a thought but if you create member functions to handle types of movement, then why not abstract the keypress from the action one more time by having the sprites process a message? What I mean is have a sort of command interpreter that receives a command like "walk right" or "jump up" or "walk stop" or something of that sort that calls the correct function for that message. This way you can just send the right message depending on the keypress without cluttering up your keyboard handler. This also has the advantage of laying the ground work for a scripting system. Just an idea :)

What I did in my Qbasic (yes!) platformer was just have my character have X and Y speed. When he jumped, his Y speed became negative. However, if I detected he was off the ground I would add a little to his Y speed each frame, so when he jumped it made a true correct arc (I did have a maximum falling speed though, like Mario). I did animations based on speed and whether he was on the ground.