Building Animation Maps

A robust animation system for Quintus should have two main goals. The first goal is to make it easy to trigger animations by name and not have to worry about the speed or the frame that the animation is playing at. The second goal is to have the animation system hook into the entity’s events so that animations can trigger events to make it easier to time actions and behaviors.

Deciding on an Animation API

To begin, think about what a good API for an animation system might look like. There are two main pieces to consider. The first is the method to define animation. The second is the way animations are played. The first is straightforward: You need a way to set the frames that make up the animation as well as any additional details about the animation. Listing 16-1 shows how this can work.

Listing 16-1: The animation api

    Q.animations('player', {
      run_right: { frames: _.range(0,10) },
      run_left:  { frames: _.range(10,20) },
      stand:     { frames: _.range(30,25), rate: 1/5 },
      fire:      { frames: _.range(25,30), loop: false, rate: 1/30 },
      die:       { frames: _.range(30,45), rate: 1/5, next: 'dead' },
      dead:      { frames: [ 45 ] }

In the preceding code, Q.animations creates a sprite animation map called player and passes in a hash defining the frames and any additional details about the animation, including whether it shouldn’t loop, whether it has a rate override, and whether another animation should play after it is done.

As a shortcut to pass in a long array of frames, such ...

Get Professional HTML5 Mobile Game Development now with O’Reilly online learning.

O’Reilly members experience live online training, plus books, videos, and digital content from 200+ publishers.