Hi guys
I am new to the cocos2D.In my game i have one scene and several layer to display Menu,pause,level finish,game over. now i want to find out the layer which is being used on top of the scene. i already tried and got the solution to solve it by using boolean variable for every layer. but this is not a good way to use i thought.
please provide some suggestions
Thanks
Riash
You can simply keep a pointer to the active layer. And it is better to have different scenes for every game state because in this case your management will become much simpler. That's because typically your game scene will have more then one layer. For example: background, level objects, controls and so on.
Related
I am trying to develop an 2D game using cocos2d library. I am still learning the framework.
Please understand that I am new to game development but not new to programming using objective c.
Here is the issue I am facing when it comes to my game development effort - I feel that I am missing the theoretical understanding of how to develop an infinite scrolling game. Is it possible for any of you to provide me some guidance on that ?
Here is my understanding of achieving infinite scrolling using cocos2d framework:
Cocos2d has a singleton director class which handles the current scene and scene transitions
In the current scene, I feel like I have to create an platform object consisting of several images and add them as a child to the current layer. And constantly run a move action to the platform sprite. So as and when I detect a particular image is off screen I have to replace it with another image. That way I will be able to create an infinite scrolling.
I am sorry if point 2 is not coherent. I just attempted to put my understanding of how to infinite scrolling.
Can you please help me with this ?
Thanks
I dissected how to implement scrolling with cocos2d-iphone in this article. What you probably want is the "fake scrolling" approach where two background images are moved and switch position after one completely left the screen.
You want to do this for the background layer only, not individual sprites. Your world isn't really moving, it's just the background panning that creates the illusion of movement. All sprites etc (player, enemies) movement is still relative to screen coordinates.
You'll find a working implementation in the code for my Learn Cocos2D 2 book in the Shoot'em Up project.
If you don't want to bother implementing this yourself, KoboldTouch supports endless/infinite scrolling for tilemaps. Here the game objects actually move along with the background infinitely (up to the maximum coordinates supported by float which is around +/- 16 million points).
I've been developing a 2d RPG based on the LWJGL alongside with Java 1.6 for 3 months now. My next goal is to write all of the non-game-ish stuff. This includes menus, text input boxes, buttons and things like the inventory and character information screens. As I am a Computer Engineering student, I'm trying to write everything on my own (except, of course, for the OpenGL part of the LWJGL) so that I "test" myself on the writing of a simple 2d game engine.
I know that making such things from scratch requires basically mapping textures to quads (like the buttons), writing stuff on them and testing mouse/keyboard events which trigger other events inside the code.
The doubt I have is: should I use VBO's (as I'm using for the actual game rendering) or Immediate Mode when rendering such elements? I don't really know if Immediate Mode would be such a drop on performance. Another point is: do the interface elements have to be updated as fast as the game itself? I don't think so, because nothing is actually moving... Are actual games made like that?
Immediate Mode is more straightforward for the task, you would not need to take care about caching and controls composition/batching. Performance dropoff is not that big, unless you render a lot of text (thousands of letters) with each glyph in a separate glBegin..glEnd. If you don't use VBO anywhere else I would recommend trying it out for text output and doing everything else in easier Immediate Mode.
GUI elements might not change as often as game state does, but there's a catch - you could need to update them each time there's a cursor interaction (e.g. button gets OnMouseOver event and needs to be rendered with a highlight). These kind of events may happen very frequently, so thats why rendering may be needed at a full speed.
can anyone please make me clear about the difference between a Scene & a Layer in COCOS2D. I am bugged up with this.
Buddy, it is very simple. Whenever you use COCOS2D, you will be having a class which extends Layer. And which you are going call from Main activity. So for one displayable screen, there can be only one layer. In the class(which extends Layer) can have any number of scenes. You can even set the dimensions for the individual scenes too. But, make sure that, you release the memory immediately after you switch from one scene to another... Enjoy... :)
I am at the start of my cocos2d adventure, and have some ideological questions to ask. I am making a small space-shooter game, am I right to use the following class structure?
Scene
Background Layer
Infinite parallax background
Game Layer
Space ships
Bullets
Control Layer
Joystick
Buttons
and a followup question — what is the best practice in accessing objects from other layers? For example, when the joystick is updated, it must rotate the space ship and move the background. Both of these are in other layers. Is there some recommended way to go about this or should I simply get the desired objects by Tag and operate on them?
Cocos is a big singleton-based system, which may not appeal to some developers but is often used in Cocos apps and is the fundamental architecture of the framework. If you have one main scene and many subsequent layers added to that scene, and you want controls from one layer to affect sprites or logic on other layers, there really is nothing wrong with making your main scene a singleton and sending the information from the joystick layer back to the scene to handle for manipulating other layers or sprites. I do this all the the time and this technique is used in countless Cocos tutorials in books and online, so you can feel that you aren't breaking too many rules if you do it this way (and it's also quite easy to do).
If you instead choose to use pointers in one layer to send data to other layers, this can get you into a lot of trouble since one node should never own another node that it doesn't have a specific parent-child relationship with. Doing so can cause crashes and problems with the native Cocos cleanup methods when you remove scenes later, and potentially leak memory. You could use a weak reference in such a case instead, but that is still dependent on one layer expecting another layer to always be around, which may not be the case.
Sending data back to the main game scene to then dispatch and use accordingly is really efficient.
This seems like a perfectly reasonable way to arrange your objects, this is a method I use.
For accessing objects, I would keep an explicit reference to the object as a member variable and use it directly. (Using tags isn't a bad option, I just find it can get a little messy).
#interface Class1 : NSObject
{
CCLayer *backgroundLayer;
CCLayer *contentLayer;
CCLayer *hudLayer;
CCSprite *objectIMayNeedToUseOnBackgroundLayer;
CCNode *objectIMayNeedToUseOnContentLayer;
}
Regarding tags, one method I use to make sure the tag numbers I'm assigning are unique is define an enum as follows:
typedef enum
{
kTag_BackgroundLayer = 100,
kTag_BackgroundImage,
kTag_GameLayer = 200,
kTag_BadGuy,
kTag_GoodGuy,
kTag_Obstacle,
kTag_ControlLayer = 300
kTag_Joystick,
kTag_Buttons
};
Most times I'll also just set zOrder and tag properties of CCNodes (i.e. CCSprites, CCLabelTTFs, etc.) the same, so you can actually use the enum to define your zOrder, too.
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!
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:
Use two CCLayer objects (GameLayer and HUDLayer) as child nodes of one CCScene (GameScene). These are the "view" objects.
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.
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.
HUDLayer is placed at a higher z-index than the GameLayer and obviously has all of the CCSprite objects for the HUD and buttons.
Interaction between the HUDLayer and the GameLayer is managed via the GameController.
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.