CODEWITHSUNDEEP
iosobjective-csprite-kitgame-physics
Kyle Decot
Kyle Decot

Reputation: 20835

Adjacent SKPhysicsBody not working properly

I am having a problem when trying to put two blocks that have physics bodies on top of one another.

http://s1173.photobucket.com/user/Kyle_Decot/media/example_zps02f027fe.mp4.html

As you can see in the video I am able to place my block on top of the stacked blocks even though they are placed right on top of one another.

Both the player block and the other blocks inherit from a base Block class which looks like this

#import "Block.h"

@implementation Block

+ (void)loadSharedAssets {

}

- (id)initWithColor:(UIColor *)color size:(CGSize)size {

    self = [super initWithColor:color size:size];

    if (self) {

        self.texture = [SKTexture textureWithImageNamed:@"tile"];

        self.physicsBody = [SKPhysicsBody bodyWithRectangleOfSize: self.size];
        self.physicsBody.usesPreciseCollisionDetection = YES;
        self.physicsBody.dynamic = NO;


    }

    return self;
}

@end

Update

I've added a picture to make the problem a little more clear. Essentially the problem is that even though the blue blocks are right above one another, I am still able to jump up (w/ the red block) and sit on the edge of the bottom blue block (which shouldn't be possible). It seems something is off w/ the physics bodies or something.

enter image description here

You can see that the red block is slightly higher than the adjacent blue block for some reason and "sits" on the edge of the bottom blue block. when I jump up against it.

Upvotes: 2

Views: 447

Answers (3)

davbryn
davbryn

Reputation: 7176

EDIT: replaced original suggestion with answer

Scrolling to section 4.5 Edge Shapes of the box2d documentation and you will find the cause of this (SpriteKit uses Box2D under the hood for it's physics implementation)

In many cases a game environment is constructed by connect several edge shapes end-to-end. This can give rise to an unexpected artifact when a polygon slides along the chain of edges. In the figure below we see a box colliding with an internal vertex. These ghost collisions are caused when the polygon collides with an internal vertex generating an internal collision normal.

The two edges here (edge1 and edge2) are the left hand side edges of the two blue boxes in your game (so picture it rotated 90 digs counter-clockwise)

Box2D introduced ChainShapes to get around this issue (which you can find referenced in section 5.6 Edge Shapes.

The idea is to replace groups of square physics bodies with a chain of these vertices whenever generating more than one box at the same time.

I believe you can access these within SpriteKit by using bodyWithEdgeChainFromPath and passing in a Core Graphics path consisting of the corner points of the boxes you want to combine to form the collision chain

Upvotes: 1

Batalia
Batalia

Reputation: 2435

EDIT: since you've clarified your question a bit and you seem to want the red one to fall back to the ground, while the blue blocks stay where they were, it seems that the bodies may be too rough, which makes them stick, and the red one doesn't slide off.

There's the friction property - modifying it can turn the body from a rough one (1.0) to one that's as smooth as an ice cube (0). Per the documentation, the default value is 0.2, which may still be too rough for your needs. Try setting it to physicsBody.friction = 0.0 in all involved bodies.

EDIT 2: it seems that it's a deeper bug. You can try the following workarounds to achieve your desired effect, if you want to sacrifice a little accuracy:

  • set your first blue block physics body to the target rectangle size, then make each subsequent lower block body 1-2 pixels narrower, so that you evade the 'lip'
  • set your physics bodies to circles rather than rectangles if all else fails - bodyWithCircleOfRadius:self.size.width*0.5. For a fast enough simulation, this might do.

Upvotes: 0

s.bandara
s.bandara

Reputation: 5664

I could imagine that tiny numerical errors in the simulation run by SpriteKit, in particular regarding collision detection and motion will make the red box indeed sit on the edge of the lower blue box. This position may be stable simply because the blue box accelerates the red box leftwards for the short amount of time it remains on screen.

A solution could be to use specific body types that merge the different configurations of boxes with smooth left vertical surfaces that occur in your game. In the specific case, it would be a box that is twice as high than wide. Before you spend a lot of time on this, you could test first of all, if removing the lower blue box stops the red box from getting stuck.

You don't need to define different Block classes for different box configurations: your initWithColor:(UIColor *)color size:(CGSize)size already appears to accept different sizes, but you might want to provide additional texture tiles and identifiers for those to select from.

Upvotes: 0

Related Questions