Game Development Reference
In-Depth Information
Using scenes in Cocos2d-x
Scenes are mini applications themselves. If you have experience as an Android developer,
you may think of scenes as activities. Of all the classes based on node, the
Scene
applica-
tion is the most architecturally relevant, because the
Director
class runs a scene, in ef-
fect running your application.
Part of the benefit of working with scenes is also part of the drawback: they are wholly in-
dependent and ignorant of each other. The need to share information between scenes will
be a major factor when planning your game class structure.
Also, memory management may become an issue. A currently running scene will not give
up its ghost until a new scene is up and running. So, when you use transition animations,
keep in mind that for a few seconds, both scenes will exist in memory.
In Eskimo, I initialize scenes in two different ways. With
MenuLayer
and
LevelSelectLayer
, each time the user navigates to either one of these scenes, a new
layer object is created (either a new
MenuLayer
or a new
LevelSelectLayer
).
GameLayer
, however, is different. It is a singleton
Layer
class that never stays out of
memory after its first instantiation, therefore speeding up the time from level selection to
the actual playing. This may not work for every game, however. As I mentioned earlier,
when transitioning between scenes, both scenes stay in memory for a few seconds. But here
we are adding to that problem by keeping one layer in memory the whole time. Eskimo,
however, is not very big memory-wise. Note that we could still have the option of creating
special conditions for when
GameLayer
should be destroyed, and conditions when it
should not.
So let me show you how to create scene transitions. First, with a
Scene
class that creates a
fresh copy of its
Layer
each time it's created.
