notification if animation has ended ...

[Serethos]

i often stumble over a problem concerning my animation sequences:
normally each sprite has 1..n animation objects for controling all bitmap-based animation sequences. therefore the relation
of both classes is single wayed

sprite ---has--> animation

but sometimes i need to know the exact moment when a sequence has just ended.  e.g. the sprite exploded so after that it can be removed.

i only see two solutions:
- a bidirectional relationship so that every animation can consult its sprite reference
(which can be somewhat tricky cause all other animations which do *not* require to notify the sprite do not know that they shoul not do so ... this would require more additional workarounds)

-  i could permanently ask:
are you finished ...are you finished ...are you finished ...are you finished ...are you finished ...are you finished ...
 


btw:
in general if you need back references for very special purposes, dou you rely on using normal references correct or do you write interfaces just for this purpose (or use observer or whatever)

[kevglass]

It depends entirely on a whole bunch of other things

For example, if you're Sprite->Animation interaction is thus:

1   2   3   4   5   6   7   8   9   10

Sprite {    tick(delta) {        anim.tick(delta);    }    render() {         Image image = anim.getCurrentFrame();         image.render();    } }

Then its very easy. You just ask the animation if its finished once you've ticked.

However, your scenario might be completely different. This process is normally refered to as Design

Kev

[Serethos]

its very similar to your example except that the animator ticks automatically. the sprite-class only calls getCurrentFrame().
sure, i could do something like

1   2

if( animator.hasEnded() )            rideTheChicken();

but such things are always a little dumb and not the really event driven ...

as a workaround i use the other method of adding the spriteclass like a listener to the animator object. if the animator's listener != null it notifys it.

the question whether to use the first or second method is a little like memory VS cpu.
first needs permanent method calls with value comparision, second needs extra references for little use.

perhaps i should mention that i only think that much about those little issues cause its for a handy game where common design patterns are generally thrown over board.

Games published by our own members! Check 'em out!

[kevglass]

I think you have to ask yourself why you wouldn't just use the straight forward method. Checking a boolean each frame really isn't going to be a CPU choker. You'll have much more important optimisations than that to worry about...

What flexibility/reusability is adding the AnimationListener interface really giving you in your use case? If its none or a weak answer that you find yourself wondering about then its probably not really worth it...

And of course if it is later, we work in a wonderful refactorable language called Java...

Kev

[Serethos]

perhaps it my very personal feeling, but i dislike solutions,
where events occur but are tested permanently.

sure, i know, with this logic i should feel uncomfortable with the whole collision detection ...    

only aspect i have for my defense is that handy programming forces you enough to replace good design with clumsy code where everyone references everyone and tests if it should test the test ...
then theres a time, where you try to avoid this crap ...

[Malohkan]

you should only care if it's a difficult calculation to check to see if the boolean is true.  As in, you have a game which requires a difficult check and loop through all of the objects in your scene to decide if a game is won, but if you just let the objects themselves say, "hey, I'm there, end the game now" you could finish and not have to check every object every tick.  Since you're just checking a single boolean, or probably comparing two numbers, that's a silly thing to optimize.

[kevglass]

only aspect i have for my defense is that handy programming forces you enough to replace good design with clumsy code where everyone references everyone and tests if it should test the test ...
then theres a time, where you try to avoid this crap ...

I agree entirely. But what I'm asking if this small nuance of your code is really worth worrying about just yet.

Kev

[shmoove]

Unless you can think of a few more places where you'd like to listen for events from the the animation class, I'd go with the simpler check-the-boolean solution.

shmoove

[Malohkan]

also consider in this case... either you check every time to see if the animation has finished, or the animation itself checks every time to see if it's finished.  I can't forsee a way you'll get out of that single boolean check.  Firing an event once you know it's done means you've already discovered it's done... meaning you just did the check you would have done otherwise.  The only difference is not only are you firing an unnecessary event, but you're also having to catch it and handle it.

[Serethos]

the event firering isnt extra work:
in my animation class i have to test whether the end of the sequence is reache, e.g. to loop it from beginning, play it backwards, whatever. sure, this is an aspect which grows out of my animation class design..

Games published by our own members! Check 'em out!

[Malohkan]

exactly, you have to test to see if it's reached.  When it is, you remove the animation, it's as simple as that.  You have to do that test either way.  Might as well handle it right when you find it's true rather than have the intermediate step of firing and handling the event.

1   2   3   4   5   6   7

for (int i = 0; i < size; i++) {       animation[i].run();       if (animation[i].isDone()) {             remove(i);             i--;       } }

And have your remove() method remove that slot and change the "size" variable.