Game Development Reference
In-Depth Information
Containers within containers
Before we move to the parallax effect logic, there is something I wanted to talk about re-
lated to the layering of our
_gameBatchNode
object, which you'll recall is a
SpriteBatchNode
object.
If you go to the static
create
method inside
Terrain.cpp
, you will notice that the ob-
ject is still created with a reference to a
blank.png
texture:
terrain->initWithSpriteFrameName("blank.png")
In fact, the same 1 x 1 pixel image used in the test version is now in our sprite sheet, only
this time the image is transparent.
This is a bit of a hack, but necessary, because a sprite can only be placed inside a batch
node if its texture source is the same used to create the batch node. But
Terrain
is just a
container, it has no texture. However, by setting its
blank
texture to something contained
in our sprite sheet, we can place
_terrain
inside
_gameBatchNode
.
The same thing is done with the
Block
class, which now, in the final version of the game,
behaves like another textureless container. It will contain the various sprites for the wall
and roof tiles as well as chimneys and puff animations as its children.
The organization of the layers inside our
_gameBatchNode
object can seem complex
and at times even absurd. After all, in the same node, we have a foreground "layer" of
lampposts, a middle-ground "layer" of buildings, and a background "layer" containing a
cityscape. The player is also placed in the background but on top of the cityscape. Not only
that, but all three layers are moved at different speeds to create our parallax effect, and all
this inside the same
SpriteBatchNode
!
But the amount of code this arrangement saves us justifies any confusion we might have at
times when attempting to keep the batch node organized. Now we can animate the puffs of
smoke, for instance, and never worry about keeping them "attached" to their respective
chimney
sprite as the terrain scrolls to the left. The container will take care of keeping
things together.
