cocos2d for iPhone

A fast, easy to use, free, and community supported 2D game engine

1. 

   slycrel
   Member

   So, I've decided to try and implement a 2d side scroller, similar to many in the 8 bit days. An action-RPG probably.

   I've decided to use objective-chipmunk for the foundation, which has been really cool so far. Gravity is great, got a TMX map level working with the physics engine to walk around on. I've started looking at adding an enemy, and have run into the problem of wanting to use cocos2d animations to animate my enemies while still using the physics engine. These seem to be somewhat incompatible.

   For my first enemy I've started to implement a bat that flies at the player. I'd like this to work something like the green bats in super mario world, or maybe the bats in castlevania. However, with the physics engine they couldn't move through the walls and floors or even through the player, making handling them getting from point A to point B a fairly hefty problem. Additionally trying to animate the wings using joints and the physics engine is kind of a problem. My understanding is that I need to reflect my sprites based on the physics, not move the physics based on sprite animations in order for the engine to work properly.

   As a solution I'm thinking about doing the following:
   - Create a chipmunk space for the player and the world (and possibly boss fights). This would handle player movement, physics and possibly basic animation.
   - Create a separate space for the enemies and/or NPCs. This would allow for gravity to work on enemies as needed. Not all enemies would use this, only ones effected by gravity.

   This would solve the problem of the bats and other enemies (maybe ghosts or somesuch) being able to pass through walls, since they would be sprite-based only. Additionally enemies could pass through the player similar to the old platformer games. However! This would also require not using physics for most collision detection, instead using sprite-based collision, and I'd have to define the level physics for two separate spaces.

   Alternate options I've thought about are having only one space and having gravity-based enemies simply working differently (they collide with the player and can cause problems there, which would alter gameplay but could be ok) and still have sprite-only based enemies that I have to manage differently. And then there's the physics-only option that doesn't have things that move through walls. I could be wrong but pretty sure you can't have chipmunk objects pass through each other within the same space.

   As I'm typing this that last seems like a better way to go, if I can live with the gameplay changes it will cause. Will have to consider that.

   I'd love to have feedback on if either of these are a viable option or alternate approaches if anyone has suggestions or experience here. There's plenty of waste here in both, and I'm not sure what the best solution is, or even if I'm looking at this the right way. (I'm new at writing platformers of any kind)

   Posted 4 months ago #
2. 

   itlgames
   Moderator

   On Box2D you have something called sensors, you can still manage the collision but they don't actaully collide and stop, so you can use to move through your player or walls. With last version of Box2D you also can set a particular body to ignore gravity. I'm sure chipmunk has something similar.

   EDIT: I think it's cpShape with sensor set to true.

   Posted 4 months ago #
3. 

   itlgames
   Moderator

   By the way, on Box2D you can create kinematic bodies, so they can be moved using cocos2d actions, again I'm sure chipmunk has something similar. I have been building a few 2d platformers recently using Box2D and had to deal with all those issues. I also read a TMX map and build the collision shapes grouped on rows, so no need to create one single shape for each tile (I think it's too expensive). Talk with @slembcke cos I think there is something called auto-geometry that may help you.

   Posted 4 months ago #
4. 

   slembcke
   Administrator

   You have several options for filtering out collisions: layers, groups, collision handlers and sensors.

   For the case of the bats, I think you'll find layers to be sufficient and simple. I have an example of using layers as collision rules in the manual: http://chipmunk-physics.net/release/ChipmunkLatest-Docs/#cpShape-Filtering It could do with a little editing, but it should get the general idea across. If you want to ignore collisions between the bats, you can just use a collision group. If those don't offer you the flexibility you want, you can always reject collisions from begin or presolve collision handlers.

   You might also want to take a look at Your Story. http://www.udevgames.com/entries/your-story It's a Chipmunk based platformer that I collaborated on for the uDG 2011 competition. The GitHub project page is here: https://github.com/maximile/Your-Story It might give you ideas for implementing a lot of the platforming behavior.

   Posted 4 months ago #
5. 

   slycrel
   Member

   I'll check into the sensor thing. That sounds exactly like what I'll need to use for the "non-collision collision" shapes without having to go to two separate spaces or managing some objects outside the physics engine.

   Kinematic bodies sounds great -- I had been thinking it would be a super pain to try and emulate actions via the physics engine, much better to do this on the cocos2d level and then map the movement to a physics object. <goes and does some document digging> Looks like this is a "rogue body" in chipmunk, at least according to the brief blurb mentioned here. Not exactly sure how that works if the body isn't added to a space, I'll have to dig into that some.

   And yes, I am currently doing 1 tile per static shape for the floors/walls, and looking forward to the auto-geometry hopefully being able to do this for me. It's on my list of things to check into -- so far I don't have much going on but it's not yet been a problem. I'm only testing on the iPad2 though, so it's higher end than what I'll likely want to support in the end.

   I really appreciate you taking the time to respond. I figured there was some direction I had been missing here, I'm very grateful for the direction on how to use existing tools to solve these issues. Thanks!

   Posted 4 months ago #
6. 

   slycrel
   Member

   Thanks @slembcke. Very useful to have the example code there to look at. Also after looking again at the chipmunk docs it seems I have much to learn about the collision stuff. It's not as black and white as I expected it to be. I'll check into the layers for the bats specifically, since they will be "flying" and should be more or less ignoring gravity. Other than mass, are there ways to ignore or offset gravity in chipmunk?

   Posted 4 months ago #
7. 

   slembcke
   Administrator

   Yeah, you can feed the tile data into the auto-geometry and get back only the outlines of the solid areas. I don't have an example of how to do this yet though... (To be honest, I've never even looked at tilemaps in Cocos2D ever). Really all you need to do is make a ChipmunkBlockSampler with a block that acts as a "get pixel" function for the tilemap. I can point you in the right direction once you get that far.

   As far as accepting actions, it's really easy to make your game objects support them. Really all you need to do is give them a setPosition method.

   -(void)setPosition:(CGPoint)pos
   {
   	ChipmunkBody *body = self.mainBody;
   	cpBody *cBody = self.mainBody.body;
   
   	cpBodySetVel(cBody, cpvmult(cpvsub(pos, cpBodyGetPos(cBody)), 1.0/FIXED_DT));
   	body.pos = pos;
   }

   Then you can add actions using [[CCActionManager sharedManager] addAction:action target:self paused:FALSE] or something similar.

   Posted 4 months ago #
8. 

   slembcke
   Administrator

   2D games can have a lot of weird collision filtering rules. (one way platforms, layered scenes, etc) I tried to make the collision filtering pretty flexible, being able to reject or ignore collisions from collision handlers is a pretty important one.

   The easiest way to ignore gravity on a body is to do body.force = cpvmult(space.gravity, -body.mass). You can also define a velocity function to ignore the gravity, but I don't really have a good example of that other than the Planet demo in C: https://github.com/slembcke/Chipmunk-Physics/blob/master/Demo/Planet.c . Acceleration due to gravity is the same for all objects regardless of their mass, so don't try setting the mass to 0. You'll just cause really bad things to happen. (I think I added an assertion for that actually).

   Posted 4 months ago #
9. 

   slycrel
   Member

   Hey, thanks a ton @slembcke. I'm not expecting the tile stuff to be particularly difficult. I only spent a few minutes getting it working in the first place. The auto-geometry sounds like it will definitely optimize my static object count. Don't be afraid of TMX Maps, they are just 2d arrays of tile objects really. For now I'm doing this with the tile map:

   // add the TMX map
   		CCTMXTiledMap* map = [CCTMXTiledMap tiledMapWithTMXFile:@"physicsTest1.tmx"];
   		if (map)
   		{
   			[self addChild:map z:-10 tag:'MAP '];
   
   			// set up chipmunk
   			space = [[ChipmunkSpace alloc] init];
   			space.gravity = cpv(0, -2500);
   
   			// create the bounding box for the edge of chipmunk.
   			[space addBounds:map.boundingBox
   				   thickness:10.0f
   				  elasticity:1.0f
   					friction:1.0f
   					  layers:CP_ALL_LAYERS
   					   group:CP_NO_GROUP
   			   collisionType:nil];			
   
   			CCTMXLayer* walls = [map layerNamed:@"Walls"];
   			// create physics based on the map properties
   			for (int x = 0; x < map.mapSize.width; x++)
   			{
   				for (int y = 0; y < map.mapSize.height; y++)
   				{
   					int gid = [walls tileGIDAt:ccp(x,y)];
   					NSDictionary* dict = [map propertiesForGID:gid];
   					NSString* type = [dict objectForKey:@"type"];
   					if (type)
   					{
   						if ([type isEqualToString:@"stone"] || [type isEqualToString:@"wood"])
   						{
   							CCSprite* sprite = [walls tileAt:ccp(x,y)];
   
   							ChipmunkBody* body = [ChipmunkBody staticBody];
   							body.pos = ccp(sprite.position.x + sprite.boundingBox.size.width/2, sprite.position.y + sprite.boundingBox.size.height/2);
   
   							// create a shape based on the body
   							ChipmunkStaticPolyShape* shape = [ChipmunkStaticPolyShape boxWithBody:body
   																							width:sprite.boundingBox.size.width
   																						   height:sprite.boundingBox.size.height];
   
   							// properties of the shape
   							shape.elasticity = 0.0f;
   							shape.collisionType = borderType;
   							shape.friction = 1.0f;
   							shape.data = sprite;
   
   							[space add:shape];
   						}
   					}
   				}
   			}
   
   			[self makePlayer];
   
   		}

   Definitely not optimized, but also doesn't seem to have much of a performance hit. I probably have 800ish tiles in my test level and it seems to be fine so far so I've not worried too much about that yet. I'll definitely let you know when I get to that if (when!) I have questions.

   Beautiful on the actions. That means I'm almost there already I think, just need to add the setPosition: method. I assume I will need to call that in the scheduled update for these objects. I've been playing with some simple animations in cocos2d already so I'll hopefully try that out here in the next few days. Looks like the key there is the velocity.

   And with that I may not need to ignore gravity as much. Though what you've got there would be cool for a high jump power up or something like that. I'll make sure to avoid messing with the mass in regards to gravity.

   Thanks, that's very helpful!

   Posted 4 months ago #
10. 

    slembcke
    Administrator

    Actually the biggest advantage of the auto-geometry is to avoid the "cracks" between tiles. They can cause all sorts of annoying problems that would make your game look unpolished such as sliding a box across what appears to be a smooth floor and it getting stuck, or jump not working occasionally/randomly because the player bounced off the ground for a frame or two after skipping over one of the cracks. You'd probably run into memory issues before performance issues with static shapes as they don't require a lot of CPU time to deal with them.

    In regards to the setPosition: method. You could call that in your scheduled update method, but what I meant is that if you implement position/setPosition: then you can use CCActions such as CCMoveTo or CCMoveBy. They really don't expect a CCNode or anything, just an object that implements those methods. Then if you want to make a platform that moves back and forth forever, you can just do a repeating sequence of CCMoveTo actions, schedule it when the level is initialized and forget about it. Easy.

    Posted 4 months ago #
11. 

    slycrel
    Member

    Great, I think my ignorance is showing! :D

    Glad to hear that performance issues are not a problem for static shapes. I agree with the reasons you mentioned -- better to have complete objects than matched edge objects and less memory I'm sure will be very useful, especially on older devices.

    As far as the setPosition: goes... I misunderstood. I'm familiar with the cocos2d side, I made the bad assumption that chipmunk was doing something with that on it's own. Thought it was odd that it didn't show up in the protocol. That explains that, I'm over-complicating it.

    My paradigm is to have a CCNode that contains all children related to a "monster". I should be able to add a set position method on that and handle all of the related body interactions. Excellent! Much cleaner than stuffing things in the scheduler and it sounds like I won't have to change much at all here.

    Thanks for the clarification.

    Posted 4 months ago #

RSS feed for this topic

Reply

You must log in to post.