How do others keep track of everything going on in their games? I am working on a new game and I am quickly realizing everything that I need to keep track of.


Maybe a layerManager that keeps track of all the layers and what is happening for a particular scene.

Maybe a sceneManager for sharing objects among scenes

But then getting to game play itself, what if you have 100 objects on the screen each with its own state and happenings, there needs tobe a way to keep track of all of that.

Drawing everything out is really helping me.

Can anyone share with me how they go about object tracking/management? I am seeing a few different managers and then maybe even a parent object that manages the managers..is my thinking way off?

Any design patterns that may be useful for me to read about?

Update: doing some reading and maybe a Factory pattern might apply.


1 Answer 1


I'll share my design as of current implementation I did for my game.

ObjectPool & Managers

For objects whether it's enemy objects, collectable items, powers-up, effect (more like particle), etc, I managed them through my own implementation of ObjectPool as you will know roughly number of instances you would need in the game for certain time, so it will help create those ahead of time and put into good use immediately in the game whenever you need it. The benefit is that there's no lagging due to object creation during gameplay.

As well, I have another layer to manage those ObjectPools according to their own category. Anyway for my case, I manage them all inside ObjectSpawner class in which it has responsibility to spawn enemy, effect, etc whenever you need.

In each ObjectPool, there's information I can access later which is array of objects it currently has at the moment (active objects). Thus I can access those information via ObjectSpawner class in which it will get me by accessing specific ObjectPool in another hop. Of course, you can set "tag" for each sprite thus this will add another flexibility in accessing and managing those object (or sprites) and it can suit your need.

Scene management

Cocos2d-x or Cocos2d-based framework already did a great job in scene management, but as you already knew it's not enough just yet. The same as yours, I have to implement on top to handle the current scene and layer state. For my current implementation, I have a utility class to manage switching from specific layer to another. I use logical-OR operation to maintain both scene and layer state. I safely, and carefully defined both scene and layer constants separately in the single header file, please take a look as follows.

// significant scene constants
// **don't use the following 3 values directly, they're used inside enum
#define LAYER_2_SIGNIFICANT 1024
#define LAYER_3_SIGNIFICANT 2048

// [0, 511]
struct SceneState {
    // [0,127]
    struct Misc
        enum ID
    // [128, 511]
    struct Gameplay
        enum ID

// virtual set by hands
// note: MAIN layer always be 0, others use LAYER_<number>_SIGNIFICANT
struct LayerState
    struct Gameplay {
        enum ID {
            MAIN = 0,

Then when I need to switch from one to another layer, I extract the first half of scene information, and another half of layer information to correctly check and switch to target layer properly.

This means I modified CCScene class to maintain one integer, and other utility functions to flexibly switch layer as of your need.

One last thing is that I have a policy for ease in management. In scene in which most of the time in cocos2d-x world, we will create a main layer under the name of -postfix-Scene. Says you need to create a Splash scene. I usually create with this name, "SplashScreenScene". That file is actually CCLayer (not CCScene), but inside that file we have CCScene created to hold it via scene() function. My point is to make clear that in certain scene, it may have layer members as follows.

  • Main layer (in which it is itself as I described above)
  • Touch / Control layer (this is a layer to interact with players via touch, or gesture)
  • Optional layer
  • Optional layer
  • ... (go on)

Designing like this will help managing scene more easier as we will know exactly which layer we should focus in pause/resume the game as it acts as a controller of all its layer members, which layer we should disable/enable touch, and which layer is just an eye candy (but this will serve you well when you need to hide/show/fade a specific layer of overall scene.

Anyway this is one of many possible ideas you may do with your own implementation. I hope you get some ideas and make one that right to you.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .