Scratch

The easiest way to make a sprite have a walking animation is to include a different sprite that does all the sensing.  Make a second copy of your basic sprite and have it set it's ghost effect to 100...then have it do all the sensing and then work on animating the other.

MoreGamesNow wrote:

I've been messing around (occasionally) with making a platformer with a walking animation.  Unfortunately, I have been unable to develop a satisfactory technique.  Well, actually, I had a project almost working (all it takes is a little playing with numbers), but I didn't like the method or the complexity.  Here's the question: how do you make a platformer with animations (especially walking animations)?

P.S. It may be important to note that I want this to work with changing velocities.  The faster you walk, the faster the animation.  Anyone know a formula for frequency of steps to distance?

I don't know of a formula, but I think one way to tackle the idea of the adjusting the animation due to the velocity would be to have the time delay between animations be a variable that adjusts due to changing velocity.

Alternatively, you can design the platform engine so that the costumes changes based on how many steps a sprite takes. 

MoreGamesNow wrote:

Cheddargirl:  That's basically the method I'm using right now.  What if I did it "backwards", and based your speed off your rate of costume change?

If you can find a way to determine how one can directly control the rate of costume changes, then that could also work. If you're using the arrow keyboard controls, then the rate of costume change would then be affected by how long the arrow keys are held, and then you would have another formula to determine distance traveled. But that sounds just as complicated as doing it "forwards". 

Hmm... I'm thinking that having the costume rate change based on distance traveled is the easiest way to go here since it seems the least complicated solution (at least so far. Anyone is free to pitch in an idea if they can think of something less complicated).

For example: Assume you want the sprite to change for every ten steps taken in the x direction (and that the platform engine is not for a scrolling platform). Let's have two variables: last_step, and current_step. The script to control costume change could look something like this:

When green flag pressed
set last_step = x_position of sprite

When right/left arrow key pressed
     set x_position of sprite = current_step
if |current_step - last_step| >= 10
     do costume change
     set last_step = x_position of sprite
else
     no costume change

That's just the basic script I'm thinking of (it's a little bit longer and complicated based on the costumes used for the walking sequence, but not too much). I wonder if this makes sense. ^^;

MoreGamesNow wrote:

Well, it's a little more complicated since I'm not using < when [] key pressed >.  I'm using an if-statement in a for-loop, and I'm not changing the x-position directly, just the x-velocity, and after giving the user the chance to change the x-velocity I change the x-position.  A simplified version of my script is this (without y movement, walls, etc.)

http://i1081.photobucket.com/albums/j34 … vement.gif

if I use this code for a walking animation:

Code:

When Green Flag Pressed
Forever
{
     Next costume
     wait (X) seconds
}

I need to know X, based off of the x-velocity, or an alternative way to do a walking animation, while keeping the smooth movement of the forever loop (in contrast to the <When [] pressed> block) and x-velocity.

While the user manipulates x-velocity by pressing the arrow keys, this still allows the user to manipulate the sprite's x_position (at least indirectly), yes? So I think there might be a way to add my script to your script try combining that with my script by adding my script into a forever loop.

With my last code, I had two variables called last_step and current_step. last_step is used here as a reference point, current_step continually records the sprite's x_position. Assuming you still want to have a costume change for every 10 steps the sprite takes (it doesn't necessarily have to be 10, you can adjust the number based on the frames you have): If the difference between the two of them is ten or higher, it means that the sprite has traveled over ten steps in either direction (and then you have to start the calculation over again), otherwise, the sprite has not yet traveled ten steps and you need to wait until the sprite has traveled ten steps.

I'm thinking abut something like this: You have something that initially sets sets variable (last_step) to record the last position of the sprite.

When green flag pressed
set last_step = x_position of sprite

And then you have this in the forever loop of your script

set x_position of sprite = current_step  //variable (current_step) continually keeps recording current x_position of sprite.
if |current_step - last_step| >= 10 //calculates absolute value between last_step and current step. If it's ten or higher, that means sprite has walked over ten steps
   do costume change for walking
   set last_step = x_position of sprite //setting the (last_step) resets the variable for new calculation.
else
   no costume change //Sprite should not go to the next costume if sprite has not traveled over ten steps

That code calculates whether or not the sprite has traveled a certain distance (no need to calculate for the time delay between costume changes) at the end to the velocity change.

Hopefully that sense. If you still have the engine up somewhere, I can try to remix it and show you what I mean.