1

Im in the middle of creating my first iPhone game - I have a background in OOP and in particular C++ so I had some questions with regards to how best to logically setup layers while maintaining functionality.

Currently I WANT for my game to have three main layers:

  • HUDLayer (All static objects on the screen are here - game controls, User score, pause button etc.)
  • PlayLayer (The Player, the main game loop and all of the game logic here)
  • Level Layer (The level images and the level physics objects that the player interacts with, and the background music specific to this level)

Notice I used the word WANT here - because for the life of me im constantly having to move logical objects around just to work within what appears to be Cocos2d's and spacemanagers structure.

Below are just some of the issues that I'm facing

  • I would like for my PlayLayer to be the scene thats loaded by the director - but if I do that then all of the HUDLayer objects get covered behind the PlayLayer, and dont stay in place like they should, hence the HUDLayer is my scene and I have had to do that just to make it work
  • I would like to play the background music (via simpleAudioEngine playBackgroundMusic) in the LEVEL layer because I want different levels to have different music. So far the ONLY way I have gotten background music to work is to have it in the TOP most layer i.e. in this case the HUDLayer
  • Because of the fact that I have to use an instance of the SpaceManagerCocos2d object to create physics bodies - it seems like my level layer has to be killed and just incorporated within my PlayLayer otherwise im having a nightmare of a time attempting to detect collisions between the player and the level.

Am I missing something very obvious here? is there a core understanding of layers that Im just not getting? More and more I feel like im being pushed by the framework to build the whole game inside of a single class and just to use layers as scenes.

Is anyone else having these problems? Am I approaching the architecture of the game wrong? Any help would really be appreciated.

Thanks in advance guys!

Salman
  • 494
  • 4
  • 18

1 Answers1

4

Well, each game is different. There are many good discussions on the cocos2d forums about architecture, some people prefer to use an MVC approach, some like using an Actor metaphor to contain physics objects, etc.

Here's my approach:

  1. Use two CCLayer objects (GameLayer and HUDLayer) as child nodes of one CCScene (GameScene). These are the "view" objects.
  2. Create a GameController singleton that can make changes to the game state (also stored in GameController, or in a separate file.) You could also subclass CCScene and call that your controller.
  3. GameLayer is in charge of rendering the graphics of the game level and all actors in it; it also handles getting game input via touch events.
  4. HUDLayer is placed at a higher z-index than the GameLayer and obviously has all of the CCSprite objects for the HUD and buttons.
  5. Interaction between the HUDLayer and the GameLayer is managed via the GameController.
  6. GameController does all of the state changing and game actions.

That's just my approach because it worked for my current game, and it by no means is the definitive answer.

I'd suggest that you look into using an Actor paradigm for your physics objects -- SpaceManager does a decent job, but you don't necessarily always want physics objects to extend CCSprite.

asinesio
  • 345
  • 1
  • 5