Quest Pals Tutorial 2 : Basic Animations

OK, so your character can move, but right now they’re legs are stuck in place and they’re using the wonderful powerful of nothing to float effortlessly from place to place, right? Though floatation powers might sound cool, a single static animation doesn’t look very cool to the player.

So in this tutorial, we’re going to talk about animating our character and learning how to use the Animation Manager. The Animation Manager can be found inside of the platformer kit that comes with Stencyl (2.x). Or you can just download the .png below and import it using Stencyl’s import option (import is one of the main buttons up top).

Download this .png to your computer…

Then use the import button here.

The Animation Manager and Priority

See the block below?

Found under Actor >> Draw.

This is how we normally change your animations. But we are going to use the Animation Manager to keep things organized. Just like with motion, we have a way of keeping code and behaviors from fighting each other. As such, the Animation Manager behavior should be the only behavior on your actor allowed to use the above block! What happens is any other behavior that wants to change the animation of your character must “request” the Animation Manager to do so.

And that’s where our topic of priority comes in. The Animation Manager uses a pre-determined hierarchy to determine which animations get to play and which do not. This is not the same as what we did in tutorial one. Any key press could step in and take control. In this instance, we rank potential candidates in a non-changing list, and then the Animation Manager gives priority to the command with the highest rank. The order in which commands arrive is irrelevant; certain commands have more “authority” than others. So if you have the following hierarchy (stored in a list):

1. Command H
2. Command B
3. Command V
4. Command E

When Command H requests to change the animation, it always wins. Nothing outranks it. If Command B makes a request, it will win only if Command H is not using its animation. Comand V can win if Command H and Command B are not using their respective animations at the same time as itself. And so on and so forth.

Remember, the Animation Manager’s hierarchy list is not supposed to change at runtime. You input the entries into the list using the actor’s behavior pane and then should leave it alone.

Applying Animations to our Movement Behavior

We will want our actor to have eight animations. He should have two groups of animations for “idle” and “moving”, and then four in each group for the four directions (2 x 4 = 8). As such, make eight non-hidden animation attributes:

• Walk Left
• Walk Right
• Walk Up
• Walk Down
• Idle Left
• Idle Right
• Idle Up
• Idle Down

First, we need to give our movement behavior a “command” that it will send to the Animation Manager. Make a text attribute and call it “Command Name”. Here’s the important part: make sure the text you input into the attribute “Command Name” also goes into the Animation Manager’s hierarchy list. Otherwise, the Animation Manager will not recognize commands from our movement behavior.

Once you’ve designated a command, named it, and added it to the Animation Manager, tackle those animations! Let’s start with the moving animations. These are really simple. All we need to do is make a “request” using our Command Name at the same time we set our speeds. To issue a request, go to the Custom tab of your behavior palette and look for the custom block signifed by the arrow below:

 

“Anim attribute” is the animation we want to play. The “text” it is looking for is our Command Name attribute.

Simply take this custom block and place one in each of the speed-setting sections for left, right, down, and up. For each custom block, simply match the animation you want with the appropriate option (unless you like walking backwards or something and want to put your “down” animation with the “up” branch, but hey that’s your choice). Each block uses the Command Name attribute for their text; in general, a single behavior will only use one command for all of its animations because it should be designed to not make animations fight within its own control. Remember, the problems come when multiple behaviors try to change animation independent of each other.

Here I used the “Left” section as an example of what to do.

Go ahead and test it out to see if the moving animations play.

Idle Animations

Hopefully you got things working, but now when you stop your character he just walks in place, doesn’t he? This isn’t Treadmill Land, so let’s make him stop.

Now, we will use the same block as above to set his idle animation in the place that we stop speed. However, the problem you may recognize is that the stop-movement area doesn’t know which direction we were moving in. How does it know which idle animation to use?

We can fix this. Make a new animation attribute (I will call it Remember Idle). Then, in the same place we set our moving animations, we are going to make it “remember” which idle animation to use when the time comes by setting Remember Idle to the appropriate animation. Then in our stop-movement area, just issue a request using the Remember Idle animation. Voila, problem solved. You may also choose to let this be non-hidden, so that you can set Remember Idle to a default start animation in the behavior pane.

First set the Remember Idle attribute.

Remember this concept (hmm, that sounds a little punny…). Sometimes it will make more sense for a previous piece of code to set-up the next piece of code coming after it. Don’t make two sections of code go through the legwork if only one piece needs to. We COULD have stuck a section somewhat similiar to the movement code down into the stop-movement code (check last pressed key), but there was no need since the code above it could amply inform the stop-movement code of what it needed.

In Conclusion

Fantastic! Our character is starting to look a little more natural in appearance isn’t he?

Though its usefulness is a little masked at this point, the Animation Manager will become important later when we start adding new behaviors that also change the animation. Remember, a little planning ahead can go a long way in keeping you organized and making later changes less painful.

So remember:

• Priority, priority, priority! Make your code cooperate, and put measures in place to facilitate multi-behavior management. You’d be surprised how even small scale games can benefit from this.
• Remember! Um… wait, remember to remember? Well, yeah, I guess that makes sense. You can’t always do this, but when you can, its definitely a good idea.

Advertisement