I am sorry for the terrible description of this question. I am making a game where the user has to try and through a football through a moving tire. I have the game set up with a single scene & layer and I am wondering how to implement options for having different background images, tires, and footballs to choose from. I don't expect someone to explain to me how to code my game. I want to have specific objects for the different background images. Like, for instance, a prison background image would have a metal tire, different football, and have certain objects be flying through the scene while attempting to throw the football through the tire. Should I create a separate scene & layer for each background image & its corresponding sprites or is there a better way to go about this. All I am asking is for someone to point me to some example code or a project that does something similar. SORRY for the long post
If you are willing to keep everything in just one png (background + moving sprites) and use a CCSpriteBatchNode you can easily keep the rects of the elements equal for all the different settings and just load a different file.
Otherwise just have a set of files and use same CGRect, it shouldn't be hard at all..
Related
I have seen some similar questions asked but no definitive answer.
I have a background image that I'm using for my main menu for a cocos2d game. I plan to have it animated but not sure what is the most efficient way to do this. One idea was to have multiple images to create the animation but I was thinking this may take up too much memory as each image would be quite big.
The other idea was having one background image as a sprite and then having child sprites of that image that are animated with ccaction. The only thing is I may not be able to create such an elaborate animation if I do this.
I just wanted to get some feedback on this to see what would be the best approach.
Thank you,
Making a frame-by-frame animation of the whole screen would make your app size litteraly explode.
You should definitely go with your 2nd idea, i.e have different sprites for each animated component and use actions to animate them.
Check out CocosBuilder: it provides a nice UI for designing such complex animations
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).
Is it possible to use a large image in Cocos2D, and allow, via swiping or pinching, for the user to zoom in and out?
I see from this post, that the max res for a Cocos2D image is 2048x2048. That is obviously larger than a device viewport, so I want the user to be able to move around the image.
I'm not creating a game, I'm making a sort of interactive biological cell, that will allow the user to tap arbitrary organelles, and see a popup of information about them.
Here is an idea of what the image will be, and obviously cramming the whole thing into a device viewport is not possible:
So really, before I delve too deep into this project, I'm just curious as to whether it is possible to use a large image, that allows the user the ability to arbitrarily move it around, and, if I can detect organelle touches, perhaps via CCSprites?
I recommend subclassing CCSprite and using your large image as the class's image. CCSprites certainly can detect touches by simply adding the basic CCTouchDispatcher delegate to the sprite's class:
[[CCTouchDispatcher sharedDispatcher] addTargetedDelegate:self priority:-1 swallowsTouches:YES];
Then also add this method to your CCSprite subclass:
-(BOOL) ccTouchBegan:(UITouch *)touch withEvent:(UIEvent *)event
You can do anything you want with the touches at this point, scroll or whatever suits your needs.
You could break up your image into many multiple sprites and use a CCLayer to manage touches instead, it just depends on whether you really need your image to be that large, or if the limitations for a single image are enough for you to work with, considering they are pretty large too. My method here is a lot less complicated than that.
The max texture size is limited by OpenGL ES not just coscos2d and it changes by device. However, you can load the image into more than one texture and then position and move those textures around the screen. So really you could have the appearance of an image any size you would like but programmatically you will have to manage the different sprites (tiles) of the image.
CCSptites don't detect touches. CCLayers have will get the touch events you can then do a hit test to see if it hits a givcen CCSprite.
Hi. I am new on this website and also in cocos2d. I am a student and I need your help.
I am making a game based on one of the tutorials in a cocos2d game development book. The concept is simple; different objects are falling from the top of the screen and I have to avoid or catch them by tilting the device. The main character, which is one which has to avoid objects, has different properties which can change by grabbing different objects (e.g. the player may have a shield if it grabs one). In order to display the shield I have to change the sprite of the player. I am not sure how I can achieve this. Could anyone help me in providing some guidelines on this?
Use setTexture to switch the image (texture) of your current sprite with another:
[playerSprite setTexture:[[CCTextureCache sharedTextureCache] addImage:#"playerWithShield.png"]];
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.