This is a “Stencyl For Noobs” guide! This is meant to be a good, concise guide for the beginner or a refresher for the more experienced.
Animation Handling Basics
What we’re learning: The workings of animations and the basic concepts of managing them.
Contents
Why’s my Actor Flailing About?
The Fight for Animation Supremacy
Keeping Animated Order
* * * * *
Why’s my Actor Flailing About?!
A great feature of Stencyl is the ability to associate multiple graphics together under a common actor. Its sort of a no-brainer, but Stencyl does a lot of the dirty work for you, as it does with many things. So naturally, you may want to switch between different animations, using the appropriate block below:
Can be found under Actor >> Draw.
Simple command, but using it is not as straightforward as you think. And some of you know exactly what I’m talking about from your own experience. You throw down a half-dozen animation change blocks into your code (running, jumping, idle, etc.), and then are taken aback when you see your character having what looks like a frenzied panic attack as he rapidly flashes a spray of animations. What just happened?
The Fight for Animation Supremacy
If you’ve read some of my other Stency for Noobs guides, you may already recognize the concept of what’s going on: these animation change blocks are fighting with each other. One asks for an animation change, but then another tries to do the same thing, then animation carnage ensues while your poor old actor may start rapidly switching between his crawl and idle animation while flying through the sky. Awkward…
Essentially, you need to figure out a way to issue your animation change blocks their appropriate orders and make them behave together as well.
Keeping Animated Order
So let’s discuss some basic concepts and tactics on animations and how to “keep the peace” with them.
First and most importantly, animation changes are a “last wins” deal. That means when Stencyl updates your actors with recent changes, whichever animation change was seen last is the one that gets played. So essentially, when a walking, jumping, and crawling animation change are put here and there, whichever one executed last is the one that “wins”.
Again, simple concept, but making it all work can be more difficult than you think. If two animation change blocks are located in two separate behaviors, how do you know which one will be seen first and which one will be seen last? Things can get messy quick, and discovering the order that scattered blocks will execute in can be very difficult, if not almost impossible at times. So what do you do?
If your actor only has a small number of animations (like four-way walking animations and nothing else), that isn’t so bad. Put all the animations in the same behavior and make sure you have set up proper conditional checking (see Stencyl for Noobs boolean guide[s]) to make sure the right one plays.
If your actor has a medium to large number of animations, things get trickier. Its not practical for you to stash all your animation changes in the walking behavior if you also have jumping and sliding. One trick is to have some sort of animation management behavior, where all behaviors communicate with one oversight behavior. This oversight behavior is meant to be the only behavior that can change animations directly. Essentially, all the other behaviors put in requests to this behavior, and it decides which animation gets priority and plays. I discuss this in some form in this tutorial, if you want to take a closer look (this only deals with one behavior making requests, but you can hopefully get the general idea of what’s going on).
But beyond that, its really up to just designing your code right. If you are feeling ambitious and comfortable enough with the topic, you can try to devise your own method of handling animations. Just keep these things in mind:
-
Animations are “last wins”. When Stencyl finally updates an actor’s animation, the last executed change block wins.
- Generally speaking, don’t try to determine the order of execution. Often, unless you are dealing with a single behavior, you cannot do this without a ridiculous amount of work. Even then, you still may not figure it out exactly.
- Try to focus on animation priority. How does a behavior know when it can play an animation or not? Does it use booleans to make decisions? Does it check a hierarchy stored in a list? Does it “network” multiple behaviors in a web of communication? It may even be a combination of these. But think carefully about it and try to bullet-proof your method well.
Photon Game Development 
Leave a Reply