Sign in to follow this  

Storing movement scripts

This topic is 4864 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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...

Share this post


Link to post
Share on other sites
Why not hardcode? Its not unmodular, its just easier to change later on. Because you only have it in one place in your code.

But if you want to get into scripts, then make an editor in vb or something and design movements and save them into a file. then on startup of the game, you can load the movements into memory and presto!

Share this post


Link to post
Share on other sites
...And then I re-read the question. You might want to store the actions in a dynamically allocated list or array, because there is no way of knowing the number of operations you will need to do on startup. 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.

So you could have like:

Movements * m;
int CurrentMovement;
int NumMovements;

//....obtain values...
//...
m = new Movements[NumMovements];

//inside loop:
x += m[CurrentMovement].xchange;
y += m[CurrentMovement].ychange;

CurrentMovement++;

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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 :)

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
+1 to thedevdan.

Do the physics first, and then calculate which frame to show based on the current x/y acceleration/velocity/displacement.

Now the stream-of-thought part: In your "scripted animations", you could actually take a scripting approach, and have those physics parameters passed to the script (which returns a frame ID). You could then either hard-code that (i.e. treat the language you're working in as a scripting language), or roll your own system. With the hard-coding, you might find it a tiny bit less ugly to have a separate file for each sprite-ID-calculating function. Or something. Depends on the rest of your design I guess.

Share this post


Link to post
Share on other sites

This topic is 4864 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this