Animation Fallbacks

Discuss suggestions to improve the Axel library.

Animation Fallbacks

Postby tharo » Sun Jun 16, 2013 4:54 am

Hi Arkeus,
Today I was merging around with animation fallbacks.
I came to this issue working on a simple Character class. I noticed that I got to take care of a shitload of things.
Such as 'what gonna happend if my character stops walking'. Taking care of this went out into a true mess and I wondered why. Almost any animation needs to be 'done' at some point and push's the sprite to return into another state.

Thats why I had some fun with overloading and this is the result:
  • AxAnimation became a new public Member 'fallback:AxAnimation'. It acts as pointer to what gonna happend if the game logic does a fallback.
  • AxSprite became a brand new AddAnimation function. In my case I removed the entire old version of function MixiMaxi and went over to a clean oop function:
    Code: Select all
    public function addAnimation(animation:Animation):PxSprite
       animation.framerate < 1 ? 15 : animation.framerate;
       animations[] = animation;
       return this;
    I was wondering why you dont had made it like this in the first place... If you have a huge number of Sprites that also use the same tile-organisation there is no need to re-define the same animations over and over again. Its more class extending friendly, too and. Last but not least: typing a new AxAnimation( ... wont make code ugly after all. But of course right now everyone using AxGL is using the old syntax. Why not overload the function?
    Code: Select all
    function addAnimation(name:*, frames:Array, framerate:uint = 15, looped:Boolean = true, callback:Function = null):AxSprite {
       if(name is AxAnimation) ...
    else oldcodehere ...
    I would go so far. That maybe you also remove the callback argument since its optional, too...
  • Okay. But why all this? Now we come to that point that just come in handy:
    Code: Select all
    public function fallback():void {
       if (animation.fallback != null)
  • I use it like this:
    Code: Select all
    var tmp:PxAnimation;

    // stand, slowdown, walk, start
    tmp = new PxAnimation("stand-down", [..], 1, false);   
    tmp = new PxAnimation("slow-down", [..], 6, true, null, tmp);
    tmp = new PxAnimation("walk-down", [..], 6, true, null, tmp);
    tmp = new PxAnimation("speedup-down", [..], 6, true, null, tmp);
    So whenever I notice a Button Change I can trigger a fallback.

Also its possible to think about a end_animation() function that will trigger that after the current animation-loop it will do an auto-fallback.

+ allows easy animation chaining
+ and takes away complexity from the acteur controll logic
+ AxSprite get more oop and extend-friendly. The function syntax get cleaner and dont need to be changed with any new feature.
+ Allows to create a Singleton of Animations => much less memory usage on heavy usage of animated sprites. Particles f.e.

- AddAnimation syntax will change.
- Function overloading in Flash is really messi somehow.
- In the other Hand AxSprite get MORE and more complex. Many times you dont even need all this Features. Its the same with AxTilemap. => Maybe both classes should reform stict to oop and offer a simple and extended version. Or maybe just a separate AxSprite and AxSimpleSprite class.?
Posts: 15
Joined: Fri Mar 29, 2013 4:31 am

Re: Animation Fallbacks

Postby Arkeus » Sun Jun 16, 2013 11:30 am

Hmm, okay, a few things:

I'm not sure I see the gain in changing the add animation function:

addAnimation(new AxAnimation("walk", [1, 2, 3], 12));
addAnimation("walk", [1, 2, 3], 12);

For the most part, the Axel API has you making calls and it handles the object creation behind the scenes. For example, instead of creating an AxMusic object and passing it to Ax.playMusic, it takes in the parameters and handles object creation for you. In this case, you're just offloading work from the engine to the developer. Depending on the change, it's possible to add a new field to AxAnimation more gracefully, but it really depends on the change. With this API as long as it's an optional parameter its graceful. By changing the API now it's a huge backwards breaking change, whereas if I make changes to animations through the current method, I might never have to make a change that breaks all previous animating.

As for fallbacks, I'm not sure I see the value. It seems extremely game specific. For example, in my games, I can't think of why I would want a fallback. If anything, it would end up introducing bugs that would require people to dig into the library code to figure out why their animations aren't behaving as intended. Also I'm not entirely sure when a fallback takes place? Is it just after a non-looped animation ends? In all my games, there wouldn't be a fallback animation, because when you stop walking, the fallback would be different depending on different factors (are you facing up/left/down/right? etc).

As for your comment about redefining the animations again, are you referring to sharing animations between objects of different types? I don't think I've ever seen a need for that, and if I did, the common animations would probably be defined in a base class. There are also many other ways to solve the problem (you could create an animation group that you pass to various objects, such as a "FlyingEnemyAnimationGroup" that you pass to enemies that share common animations that will add them, if for example you aren't inheriting from some common class for it.
User avatar
Site Admin
Posts: 363
Joined: Mon Mar 26, 2012 12:43 am

Return to Suggestions

Who is online

Users browsing this forum: No registered users and 1 guest