Animated sprites

#1

Quote:Any thoughts or obvious solutions?

Until Melv gets around to making the sprite animation system something real, you're going to have to hack the code to get what you want. The easiest way to do that would be to create a new kind of scene object using the animated sprite as a base, adding to it when needed.

Oh, and you can't really change the internal offset, as this is defined to be the center of the scene object. Until and unless they change this, you're going to need to use mounting to put the object's center in the right place.

#2 I see. Thats very nice to know. Well I was already wondering whether to create my own animation system so this is just another reason to do so.

Thanks for the info, it was very helpful.

#3 The more I think about it, the more it baffles me. Here we have this complex 2D engine and... it doesn't have more than a simplistic animation support. I am just speechless. :)

It's certainly going to shut my mouth when it comes to praising this engine, because promoting a 2D engine that barely has animation support seems a bit silly. But I guess it's my own fault for not starting with animations until now, I could have realized this limation much sooner and saved myself some work for naught.

EDIT:

After I do $testGuy.playAnimation(test1) to play an animation, how on earth do I make it play a different animation? Additional calls to playAnimation for $testGuy just does nothing. And while I am at it, can I stop an animation? Am I supposed to destroy an animated sprite whenever I want to change animation? Am I missing something?

#4 Your duration issue is solved with the "animationTime" property of the datablock:

datablock fxAnimationDatablock2D(team1GuyWalkRight)
        {
           imageMap = team1guy;
                animationFrames = "18 19 20";
                animationTime = 0.75;
                animationCycle = 1;
                randomStart = 1;
        };

#5 The animations are defined like this (most ppl put them in the datablocks.cs file):

datablock fxImageMapDatablock2D(team1Guy)
        {
           mode = cell;
           cellWidth = 48;
           cellHeight = 48;   
           textureName = "~/client/images/team1a";
        };        

        datablock fxAnimationDatablock2D(team1GuyTauntRight)
        {
           imageMap = team1guy;
                animationFrames = "15 16 17";
                animationTime = 0.75;
                animationCycle = 1;
                randomStart = 1;
        };    
        
        datablock fxAnimationDatablock2D(team1GuyWalkRight)
        {
           imageMap = team1guy;
                animationFrames = "18 19 20";
                animationTime = 0.75;
                animationCycle = 1;
                randomStart = 1;
        }; 

        datablock fxAnimationDatablock2D(team1GuyShieldRight)
        {
           imageMap = team1guy;
                animationFrames = "3";
                animationTime = 0;
                animationCycle = 0;
                randomStart = 0;
        }; 

        datablock fxAnimationDatablock2D(team1GuyStunned)
        {
           imageMap = team1guy;
                animationFrames = "12 13 14";
                animationTime = 0.75;
                animationCycle = 1;
                randomStart = 1;
        };

Then all you have to do to change animations is call on different datablocks:

$testGuy.playAnimation(team1GuyTauntRight);
$testGuy.playAnimation(team1GuyWalkRight);
$testGuy.playAnimation(team1GuyStunned);

for this to look right, you need a delay between each one to give them time to animate.

#6 @Tomas

Quote:After I do $testGuy.playAnimation(test1) to play an animation, how on earth do I make it play a different animation? Additional calls to playAnimation for $testGuy just does nothing.

That works me for me. Maybe posting some script showing your datablocks and when the calls are made would help us to help you.

To stop an animation, I have a "stillAnimation" datablock defined for my character, which is just a single frame of my character standing. When I want my character to stop animating, I call

$character.playAnimation(stillAnimation, true);

and everything works fine.

#7 Kevin: I am talking about setting the duration of a single frame compared to other frames. I am not a confused noob although there are aspects of T2D I have not touched on yet.

animationFrames = "12 13 14";
animationTime = 0.75;

Just creates an animation where each frame has identical duration, which is not what I (or anyone else creating high quality animation) wants.

I certainly does not think Smaug confused me or even bashed T2D. Nothing of what he said was false, and in contrary to you, he didn't misunderstand my post.

Still, I really appreciate any help, be it help that comes from Smaugs or Kevins or whatever, and all of your posts have been useful. At least I now know that animations are supposed to be able to change animation, and I can try to figure out why on earth it doesn't work for me :) Code snippet coming if I can't figure it out myself.

#8 @Tomas: sorry to call you a noob. Your question was so advanced that it went completely over my head and I only understood the simplistic solution. If you want multiple durations within a single animation, then well... i'm the only noob around here.

#9

Quote:
The more I think about it, the more it baffles me. Here we have this complex 2D engine and... it doesn't have more than a simplistic animation support. I am just speechless. :)

It's certainly going to shut my mouth when it comes to praising this engine, because promoting a 2D engine that barely has animation support seems a bit silly. But I guess it's my own fault for not starting with animations until now, I could have realized this limation much sooner and saved myself some work for naught.

What baffles me is why someone would feel the need to praise or criticize the engine in this forum, in such a way.
What the early adopter's release of T2D is, is a pretty elegant piece of software which enables you to easier make a game. Some people would think that means the tool is supposed to assemble in front of your eyes. The reason it doesn't have the specific feature you require is that you havn't implemented it yet. I wouldn't imagine that the requisite changes needed would take such an awful long time to implement yourself, if you compare it with the time and effort needed to create any type of finished game.
It's a platform upon which you build your product. It doesn't need to be drooled over, nor does it need that kind of criticism. It just needs to be used. If you can't use it properly, then that's not as much the fault of the implementers as your post would implicate.

#10 @Kevin - I have no idea about using the animation to move the character, but it doesn't really seem like a good idea. If you move the character by a lot within the animation, you would also have to move the collision polygon. That seems like it would get kind of intensive, if not just confusing. Or am I misunderstanding you (and Tomas)?

I think there is talk of introducing something *like* a keyframe system for animating the position of the character, not to mention scale and other elements, but I think it may be a ways off yet.

You could use the "onAnimationEnd" callback to do motion triggered by the last frame of the animation, which could work for things like jumping. For example, before a character jumps, he crouches down in preparation. After the last frame of this crouch is played, use the callback to play the actual jumping animation and apply the force to physically move the sprite.

I haven't really tried that, though, so forgive me if it doesn't actually work, or apply to what you want to do :)

@Tomas - Can you give an example of when you would want a specific duration for a single frame? It's possible that something like a schedule would work, or even just listing the frame several times in the datablock like so:

animationFrames = "0 1 2 3 3 3 3";

Or is there something more specific you're trying to accomplish?

#11 Chris: At the time of that (now deleted) post, I was living on another planet, in another solar system. I'm back on earth now, and I have no idea what wants to accomplish by a per frame "offset". However, your pseudo per frame duration solution looks like something I will use in the future.

#12 Heh... I kind of forget what you had said originally, but it didn't seem that weird. Another planet maybe, but not a completely different solar system :)

#13 My whole approach to T2D has been to start simple and add complexity with each new game idea. I'm at level 9 out of a possible 500. In my mind, having multiple durations in a single animation is around level 235. There's so much more important things to learn, such as, moving my guy around, changing animations, mounting, effects, storing, saving, loading, and soooo much more.

#14 What I am asking for is simple. Variable durations for frames means that you have for example Cast Spell #1 lasting 10 ms, Cast Spell #2 lasting 27 ms and Cast Spell #3 lasting 5 ms. I dont think I'm the only one that finds that very useful. And, as I said, that can easily be emulated by multiple-frame hack.

As for offset, that is also rather simple. Sometimes, for example in a walk animation, one frame should be offset tiny bit compared to the center of the animation. See www.gamedev.net/reference/articles/article2223.asp where the correct animation look is only achieved with such an offset.

Both of these can probably be hacked into T2D, but as I said before, a basic animation system with these vital features is something I absolutely expected from even an early adopter version of the engine. I mean, when the feature list includes things like Realistic Physics and Advanced Particle System, I should have been able to expect Half Decent Animated Sprites. What T2D has is the absolute bare minimum that can possibly be called Animation. I guess I feel a bit ripped off and tricked. You can argue forever that EA is EA and I should expect nothing, and I certainly can't argue with that. Still, I had some minimal expectations from reading the various .plans and feature list and those were not fulfilled when it came to animations.

#15 @Kevin:
As an artist, multiple durations in a single animation is quite basic and low level. Mounting, effects, saving and loading... they're all much higher to me. It depends on where you're coming from. For someone whose focus is on coding, and not art, yes, dealing with momentum and speed within the animation is higher level, and probably would be of less importance than special effects and physics.

@Chris:
Thank you very much for that solution to frame duration. Very simple, and exactly what I need. By the way, after seeing your cowboy sketch, and the One Knight Army sketches, I'm very interested in seeing your animation.

The frame duration would work for the speed/fluidity of the animation, however, like you stated, I'd have to move the collision polygon in the animation... This is difficult. The zombie animation requires a moment to lift the leg, THEN move forward. He moves in spurts per step. I was going to have a wider sprite area, and actually move the frames where he's standing on one foot, back, at the same speed as the in-game movement. But that wouldn't track as smoothly as the object scrolls, would be a lot of work to move the collision, and would just look sloppy.

I wonder if there's a way to set the velocity based on the frame number...

@Smaug:
Thanks a lot for the info.

#16

Quote:I mean, when the feature list includes things like Realistic Physics and Advanced Particle System, I should have been able to expect Half Decent Animated Sprites.

Melv once explained that he started what became T2D on his own without GG's involvement. When he did, the particle system and physics response stuff was what he enjoyed working on, so they went in earlier than would be reasonable for a game library expecting an EA release. Granted, this isn't much of an excuse for not providing a real sprite animation system, and it is my opinion that a real animation system should have been a prerequisite for releasing the EA (aka: delay it one month), but it does explain how the priorities were confused.

There are some game types that will simply require greater effort (especially some significant C++ work) under T2D's EA than should. Oh well.

#17

Quote:I wonder if there's a way to set the velocity based on the frame number...

%velocity = $zombie.getFrame() * %multiplier;
$zombie.setLinearVelocityX(%velocity);

Of course, you'd have to set up the animation frames properly. :)

#18

Quote:
What I am asking for is simple. Variable durations for frames means that you have for example Cast Spell #1 lasting 10 ms, Cast Spell #2 lasting 27 ms and Cast Spell #3 lasting 5 ms. I dont think I'm the only one that finds that very useful. And, as I said, that can easily be emulated by multiple-frame hack.

This, to me, doesn't sound like a variable duration per frame, more like variable duration per animation, which is easilly done.

datablock fxImageMapDatablock2D(heroImageMap)
        {
           mode = cell;
           cellWidth = 32;
           cellHeight = 32;   
           textureName = "~/client/images/hero";
        };        

        datablock fxAnimationDatablock2D(castSpell1Animation)
        {
           imageMap = hero;
           animationFrames = "1 2 3 4 5";
           animationTime = 0.01;
        };

        datablock fxAnimationDatablock2D(castSpell2Animation)
        {
           imageMap = hero;
           animationFrames = "6 7 8";
           animationTime = 0.027;
        };

        datablock fxAnimationDatablock2D(castSpell3Animation)
        {
           imageMap = hero;
           animationFrames = "9 10 11";
           animationTime = 0.005;
        };

Quote:
As for offset, that is also rather simple. Sometimes, for example in a walk animation, one frame should be offset tiny bit compared to the center of the animation. See www.gamedev.net/reference/articles/article2223.asp where the correct animation look is only achieved with such an offset.

This could be solved by modifying the art assets. But that's not the main problem. The problem is that a system like this probably hinges on the game. Just like AI, people except it to be in T2D, but it's usually so specific to the game, that can't invent one AI system that works for everything. So the developer can't expect a complete system.
I feel that your statement that the animation system is below the minimal expectations is highly exaggerated.

#19 @Tomas

Quote:Variable durations for frames means that you have for example Cast Spell #1 lasting 10 ms, Cast Spell #2 lasting 27 ms and Cast Spell #3 lasting 5 ms.

If these are three consecutive frames of animation, it seems like it would look a little strange. Choppy, even. I can't think of animation where I would want one frame to last five times longer than another.

One thing I don't understand is why you seem to think adding the functionality yourself is "hacking". If Melv were to add it, would he be "hacking"? Why not try your solution, and if it works, let Melv know about it and see about having it added permanently into the feature list.

It is possible that this particular feature isn't quite as obvious and that it was simply overlooked.

I'm sorry you feel ripped off (well, not really), but personally, this engine has paid for itself 10 times over in man hours, and that's at this early stage.

@David - Thanks :) I'm really looking forward to seeing some more screens of your secret project.

#20 Guys, we have a great plan for the animation system. Here, I'll be blunt about the areas that are making T2D "Early Adopter":

-Animation system
-ImageMap system
-Networking
-Editors
-Documentation

We need to refine the animation system, but we have an *awesome* system in mind. Please trust me just a little bit there. :) The ImageMap / image loading / image referencing system also needs some refinement, and that's on its way too. Networking is obviously under development. Likewise, we are working our butts off on editors. We have a lot of documentation, but it needs to be polished a lot, and we need more of it too.

... We are well aware of T2D's strengths and weaknesses, and believe me, we are already motivated 10x more than anyone here to tackle the weaknesses and improve them. So, comments like "well, this will certainly shut my mouth about praising.." blah blah don't serve much purpose. It's not going to help us get any more motivated than we are or anything... but if you're just venting, okay. I realize you are not content with the current animation system... neither are we! :)

We call it "Early Adopter" and are very upfront about that. We have a detailed plan for getting out of Early Adopter to full release, and you can see the major points we'll be hitting above. :)

Now, for the animation issues Tomas is specifically addressing: per-frame animation timings and per-frame offsets... yes, those are good features for animation system to have.

Right now, you'll have to code functionality like this yourself. What T2D provides is a base animation system (hey, you can get animated sprites going...) and a framework that is specifically designed to make it easier for us to upgrade this system in the future. Believe me, we thought about this stuff in great detail before releasing.

We'll be releasing details on our new animation system in the near future. For now though, it's not like the two featurse mentioned above are incredibly difficult to code. Your game shouldn't be blocked here by any means. If you can't do this code, that's cool, just let people know here and I bet someone will provide an example of how to do it. If you can do it, great, please go for it and submit a resource on how you did so. :)

For $100, you already get an awful lot with Torque 2D. If you are interested in making games, T2D as it stand snow will definitely save you time vs doing everything on your own. So claims that its not worth it are pretty silly. Combine that with the fact that it has a detailed, aggressive dev plan to continue adding *free* features that'll provide more and more functionailty like this, and man... is it really all so bad?

Anyway, we never claim in marketing text or anywhere else to have the animation features mentioned here, so it's not like we were misleading about it or anything. And, again, we will be updating and enhancing the animation system in a future release.