How to tie a bullet release with a firing animation

Question

Lets say you have an animation that you want to happen when firing a bullet. How would you get the bullet to show up at the end of the animation. The only thing I can figure out is to know the time length of the animation, and delay setting the bullets position and setting it active until that amount of time has passed. I was just wondering if this is the best approach, how does everyone else handle this?

EDIT: I think i'm having trouble wording the question properly.

Answer 1

Fundamentally you're on the right track - you need to know how long an animation lasts to do this sort of thing. Animations are more than just a collection of frames, there is all sorts of other information around them that you need. E.g. how many frames are there, does the animation loop, how quickly does it play back (e.g. 10 animation frames per second or 25, or 60?). Every animation can be defined in terms of a few pieces of data, which some generalised animation code can look at and play back. You should be encapsulating the animation part in its own bit of code, which is aware of nothing except these animation definitions and how to display the individual image frames. That is, have an animation object which you can load, start playing, stop playing, and tell to render at a particular location on screen.

A flexible approach is to use a sort of animation definition to encapsulate this sort of information. So rather than just saying "animation X is all of these frames, just play through them", you get something a bit more complex.

E.g. with some sort of mocked up data format

animations =
{
  { name="walk", files="walk*.png", frameCount="12", loop="true" },
  { name="fire" files="fire*.png" frameCount="6",
       events = {
           { name="bulletLeavesGun", frame="4", param1="43", param2="30" }
       }
  }
}

So your code says something like:

currentAnimation = animations.Get("fire");
currentAnimation.Play();

How you detect events can either be with the animation code calling you back (i.e. when it detects a new event because the animation has played to a certain frame, it calls your game code to tell it about the new event), or by polling the animation like so:

List<Event> events = currentAnimation.EventsSinceLastCheck();
foreach (AnimationEvent event in events)
{
    if (event.name == "bulletLeavesGun")
    {
        Vector2 bulletPosition = new Vector2(event.param1, event.param2);
        Vector2 actualBulletPosition = new Vector2(
                 character.x + bulletPosition.x, 
                 character.y + bulletPosition.y);
        CreateBulletAt(actualBulletPosition);
    }
}

Points to note:

• Animation code should exist separately from game code. You really don't want your gameplay code too tightly tied to the nuts and bolts of animation playback.
• The animation code knows whether or not to loop based on the animation definition
• The animation code knows when the animation is done, and can call back to some other code to say 'hey, the animation called "fire" just finished, what do you want to do now?'
• The animation code doesn't know anything about events other than that they have a name and some arbitrary data associated with them (param1 and param2)
• The animation code knows what frame it's currently on, and when it changes to a new frame, it can check and say 'oh, I'm on frame 4 now, that means this event called "fire" has just happened, add that to my list of recent events so I can tell anyone who asks about it'.

If you don't need the bullet firing to happen within the animation, but only once it has finished, you can get away with a much less complex system without the notion of events. But you'll still want a system where animations play back on their own, know how long they are, and can call back to the game code when an animation completes.

Answer 2

In some way, you'll have to wait until the animation is done and create the bullet at that point.

Just setting a timer will work, if you're sure that your animation rate is fixed. As a minor variation, you could have code internal to the bullet that makes it wait invisibly for a moment before appearing and moving.

Depending on your development platform, you may have some sort of animation update function or callback that will let you respond the exact moment the animation reaches the desired point. This is how I'd do it with Flixel, for example.

Answer 3

Straight forward answer: Assuming you have an animation that you want to play when the player hits the 'fire' button, and then have a bullet come out after it's done playing. Ideally, you should avoid hard-coding the animation time, and fire the bullet when the animation completes (using a callback function or something, depending on your platform). I can't think of any other method to do this that isn't overly complex.

Alternate Game Design answer: Unless there's a really, really good reason to do so, I would avoid having a delay from pressing the 'fire' button and having the bullet appear. Unless the animation is really, really short (one or two frames, max, basically a muzzle flash), it's going to make the fire button response feel slow, and it will just get annoying to a typical player. Even if you do decide to go with using an animation before the bullets come out (turn based RPGs and tactical games would be acceptable reasons to do this), I'd think about including a "turn off animations" option somewhere, to allow the game to move faster if the player wants.

Answer 4

As MrCranky says ; keep animation and logics separated.

But most importantly, logics must remain the master part.

• When the fire button is pressed you should trigger the draw "action" in your character's state (logics).
• This action should trigger the drawing animation with all the parameters (time to live etc).
• Once the draw action is finished you can trigger the fire action (could fire once or more depending on the weapon)
• This action can generate bullets and trigger the fire animation.

Keep in mind that controlling the UI from the logics is the only way to ensure you will be able to keep, reuse and share your logics later (new renderer, new game, server version without a renderer...)

Answer 5

First off, I'd use an event system (observer pattern?) to decouple pieces of the code. This isn't just for the animation, but certainly applies there. Then the animation code can simply say dispatchEvent(event) and some other part of the code listens for that event, without either part of the code needing to know about each other.

Now the animation code needs to actually have a reference to the event dispatcher (easily done with dependency injection) and you need to have some XML or JSON that actually defines your animations. Something like:

{
  animation: {
    name: shoot,
    length: 12,
    spritesheet: shoot.png
    event: {
      frame: 4,
      name: bulletLeavesGun,
    },
  },
}

Read in the data when loading the animation, and have the animation code dispatch the event when it's on that frame during playback.