I'm making a 2D plane fighting game for the iPhone in cocos2d. I'm trying to make it so when you shoot an enemy plane, it breaks into a couple of separated pieces that will fall out of sight. What is generally the best practice for breaking one sprite up into many? should I create new images for each separate piece, or treat the initial image like a sprite sheet, and make a new sprite from segments?
Please look at this tutorial
It makes a grid of points then moves the internal (not-edge) ones around randomly a bit so it's not all perfect triangles. Then each update it moves/rotates the triangles separately--then draws them all at once.
You treat the whole thing as a sprite, so can run any of the usual actions on it. This example uses CCMoveBy to move the whole group down off the bottom.
Related
I am currently working on a 3d game in Unity, and I am working on the level design using ProBuilder. I basically created a huge cube which I "flipped normal", and a second one way smaller
which, as the other one, I flipped normal, but as soon as I crossed it while turning backward I could weirdly see through the small cube, which makes it feel unfinished. How could I fix this issue?
Normally in 3d games triangles can only be seen from one side. Usually this is not a problem because walls have some thickness. Since you clearly have paper thin walls made of only one layer of triangles this is exactly the result you should expect.
In short add the other side to your walls. The simples way is to duplicate the existing triangles and flipping them. Walls will still be paper thin of course. Later you should probably make them thicker.
I want to create a cclayer with 4-5 flying objects, flying in random directions on screen. I also want those flying objects transparent to each other, which means they can fly through each other.
What I can think of Ways to do:
With Box2D
Create a box2d world with 0 gravity. and add Polygon static ground around the edges of the screen.
Give an initial force to each of the flying objects, let them flying around and reflect on the grounds.
Problems: Objects still rest down after sometime.. Don't know why. Objects collide with each other, don't know how to make them fly through each other.
Without Box2D
use CCMove for each objects, detect if they reach edge of the screen, calculate new path for their move..
Can someone point me a direction, which way is easier? Thanks a lot.
If you have to handle complex collisions - go with Box2d. If your collisions are simple - handle them yourself.
I have a game world that's much bigger than the view port, the main character stays in the center of the view port at all times and the background layer is moved around to give the impression of the character moving. I want to make it so that the game world wraps, meaning if the the character keeps traveling either left or right they will eventually end up back at the starting position. There will be moving entities in the game world so the biggest problem I foresee is that if you go to the far right of the map you should be able to see any of the moving entities that are within the first small section of the far left of the map.
I've thought a bit about this and any solution I've come up with seems far too complicated. Like creating two identical game worlds side by side and moving them around accordingly. I live in hope that there is an elegant solution to this. Any expertise you can share would be greatly appreciated.
I'm using cocos2d on the iPhone just in case that makes any difference.
An example might be to have an x,y offset for your camera, and a multidimensional array of sprite objects.
As the player moves, the offset value changes, e.g., xMove = -1.4 and yMove = +2.6.
Then you would iterate and change the positions of all the tiles by that amount.
Next, you would identify the sprites that are too far away from the center of the screen (0,0) and re-position them to the opposite side, so they will always be visible.
This would all be done on the same scheduled 'tick' so no graphical artifacts occur.
I'm pretty surprised no one has made a wrappable tile map yet for cocos2d.
I can't give cocos2d specific advice, but I would say the most common way to do this is to create one game world, draw (parts of it) multiple times and make sure that your logic for things like collisions and AI checks for wrap-around where appropriate.
So if your player character is close to the corner of the world, you'd draw the world four times with different offsets. This needn't actually draw every single thing in the world four times any more than you would normally need to draw the entire world when only a small part of it is on-screen.
Hello everyone I an very new to cocos2d, so I apologize if this is a simple question. I would like to create to sprites that collide when they hit each other.
For instance, one sprite, spriteA, is in a fixed position on the screen. And another sprite, spriteB, is moving around the screen. SpriteB will collide with spriteA. If that doesn't make sense or you don't understand it, tell me and I will elaborate further. Any help is appreciated. Thank YOU!
Try using Chipmunk or Box2d physics systems. These are included with Cocos2d and work by having a physics simulation that updates with every time the graphics change on screen.
The physics simulation will tell you if two objects are overlapping, and will provide physical attributes like weight, slipperiness (friction), speed and direction, which creates reactions like bouncing, sliding, realistic loss of speed and changes of direction on impact.
If you are new to physics simulation, here's a 30 second run down:
Create "bodies" in the physics simulation that represent each graphical sprite
Bodies are usually defined more simply than their graphical counterparts, like a circle, square or simple polygon shape
In order to update the graphics on the screen accurately, first you establish a pixels to meters ratio. Meters are notional (i.e. made up) measurement that is used in the physics sim
Each time the physics simulation "ticks", you update the graphics on screen accordingly
So if a body in the physics sim moves 1 meter, you might transform the pixel sprite 32 pixels
Here's a good tute on collision detection using Box2d.
http://www.raywenderlich.com/606/how-to-use-box2d-for-just-collision-detection-with-cocos2d-iphone
enjoy
Its actually very simple:
Just schedule a timer: [self schedule:#selector(checkForCollision:)];
Specify the method: - (void)checkForCollision:(ccTime)dt {}
In the curly braces, make CGRects for each sprite using CGRectMake.
Then in the same method, just call: if (CGRectIntersectsRect) {}
That easy!
Well technically speaking when the 2 sprites interact, or share at least one common point, then they are colliding. I'm a little confused by your question. Are you asking for direction on how to make the sprite move on screen, or are you asking how to handle the actual collision(such as calling a method if they collide)?
I'm attempting to build a Lunar Lander style game on the iPhone. I've got Cocos2D and I'm going to use Box2D. I'm wondering what the best way is to build the floor for the game. I need to be able to create both the visual aspect of the floor and the data for the physics engine.
Oh, did I mention I'm terrible at graphics editing?
I haven't used Box2D before (but I have used other 2D physics engines), so I can give you a general answer but not a Box2D-specific answer. You can easily just use a single static (stationary) Box if you want a flat plane as the floor. If you want a more complicated lunar surface (lots of craters, the sea of tranquility, whatever), you can construct it by creating a variety of different physics objects - boxes will almost always do the trick. You just want to make sure that all your boxes are static. If you do that, they won't move at all (which you don't want, of course) and they can overlap without and problems (to simulate a single surface).
Making an image to match your collision data is also easy. Effectively what you need to do is just draw a single image that more or less matches where you placed boxes. Leave any spots that don't have boxes transparent in your image. Then draw it at the bottom of the screen. No problem.
The method I ended up going with (you can see from my other questions) is to dynamically create the floor at runtime and then draw it to the screen.