HTML and CSS Reference
In-Depth Information
As you can see, there's not a whole lot to the base sprite code. This is intentional. The basic sprite is designed
to be as lightweight and minimal as possible, relying on descendant classes and components for any specific
functionality.
The longest method is the constructor init method, which ensures that the object has a valid properties
object— p —and grabs the width and height of the object from the asset or SpriteSheet assigned to the
object. It also grabs a globally unique ID from underscore.js to give each sprite its own unique identifier.
The Sprite class next defines two getter methods— asset and sheet —to pull out an assigned asset or
SpriteSheet if applicable. Again, using a getter method means that descendant classes (or even compon-
ents) could override the method.
The draw method is responsible for actually drawing the sprite's asset onto the Canvas. It has some condi-
tional code to check for either a single asset or a SpriteSheet and can handle both. The draw method is a
candidate for being overridden by descendant classes that have more complicated or nested drawing functional-
ity. The method also triggers a draw event in case components need to do any additional drawing. As with the
SpriteSheet , because of different support for subpixel rendering, the draw method also turns whatever x
and y values that are passed in into integers using Math.floor .
The step method is just a stub that triggers a step event for any listening components.
Referencing Sprites, Properties, and Assets
As you saw in Chapter 10, “Bootstrapping the Quintus Engine: Part II,” the engine keeps a hash of all loaded
assets to make them easily and quickly referenced by name. SpriteSheets are similarly referenced, as you
just saw, in the Q.sheets object.
This is done intentionally because the goal is to have sprites refer to the assets and sheets by name instead
of passing around instances of the sheet itself. The reason for this is that it's a major goal of Quintus to make
sprites serializable, meaning that their current state can be written out to disk and local storage, or sent over the
network to be reconstituted intact on the other end of the network pipe.
For this to work, the engine must make sure that only simple types, such as strings and numbers, are used as
properties and that serializable properties are kept separate from other properties and methods. You can see that
the sprite class keeps a separate properties hash under the property p . This makes accessing object properties a
little more verbose, but it has the added advantage that any pieces of state are segregated from all the object's
other properties.
Because giving each sprite its own name would get tedious, every sprite is identified by a unique identifier
stored in p.id . This allows other objects to store and pass around objects by their identifiers instead of by ac-
tual references to the objects, making garbage collection and network syncing simpler.
Exercising the Sprite Object
With a Canvas Sprite object in place, it's time to start a quick sample game to show how the Sprite class
could be used. This chapter builds a simple breakout-style game. You start by adding a paddle at the bottom of
the game that the user can control. Figure 11-1 shows how the game will look at the end of the chapter.
 
Search WWH ::




Custom Search