I have several sprite physics bodies lined up next to one another, each physics body should be just slightly touching the next physics body. When I leave the app in idle for a few minutes, some of the physics bodies start to over lap each other, and when I leave the app in idle for hours, the physics body are significantly overlapping each other (about 5-10 pixels). It could be that the sprites are moving, not the physics bodies, I can really tell which one.
I don't think that collisions between the physics bodies is pushing the position around, as I setup each physics body's collisionBitMask so that they do not collide with one another. Also, there is currently no SKActions in place to move anything in the app.
Below is the code I use to setup each physics body:
spriteSegment = SKSpriteNode(texture: arrayTextureSegments[segmentType])
spriteSegment.position.x = CGFloat(countSegment) * 30 // the spriteSegment size is 30 by the way
spriteSegment.physicsBody = SKPhysicsBody(rectangleOfSize: spriteSegment.size)
spriteSegment.physicsBody?.restitution = 0
spriteSegment.physicsBody?.dynamic = false
spriteSegment.physicsBody?.affectedByGravity = false
spriteSegment.physicsBody?.categoryBitMask = bitType1
spriteSegment.physicsBody?.collisionBitMask = bitType2
spriteSegment.physicsBody?.contactTestBitMask = bitType2
addChild(spriteSegment)
Does anybody know what would be creating this behaviour?
EDIT:
Done up a sample and I still get the same strange behaviour where the images change position. I notice a small change at 20 mins, but if the app is left in idle for a hour, you should be able to clearly see what I'm talking about.
GameScene.swift code:
http://hostcode.sourceforge.net/view/3496
GameViewController.swift code:
http://hostcode.sourceforge.net/view/3497
Segment Image (0#2x~iphone.png):
Edit:
Here is an image of the difference before and after an hour. The blueish color is the physics body outline.
EDIT:
Don't know if I've done this right, but link for entire project: click here
Last Edit:
I recorded where each sprite was every 20 mins, here are the results.
Related
I am learning Swift, and as a project I am working on a tile based 2D game similar to super mario where my character will walk and jump on tiles.
The latest version of Xcode and Sprite Kit give the ability to create a Tile Map directly in Xcode.
In the presentation of the new Xcode and Sprite kit, the guy demonstrates a game similar to what i am working on.
https://developer.apple.com/videos/play/wwdc2016/610/ (around the 20th minute).
He mentions giving Tiles user data properties which i did, and in code we search through all the tiles which have that user data and give them some physics properties so that the character can collide or interact with them (in my case, my character not falling or walking through the tiles).
so basically, the idea is giving those tiles a physics Body, but this can't be done using SKphysicsBody. So there must be another way, and since i am new to Swift i am missing it.
if anyone knows this, i would very much appreciate the help.
If the question is unclear let me know because i am also new to stack overflow.
Apple staff member Bobjt says here that "the right approach" is to add user data to your SKTileDefinition objects and use that to identify and add physics bodies to your tiles.
So you would add a user data value to a tile definition either programmatically or in the editor, like so:
Then in code you would check each tile definition to see if it has the user data value. If so, then you need to calculate the tile's position and add a physics body on a new node, parenting it to your tile map. Here is the code for this which Bobjt referred to as "the correct approach":
self.tileMap = self.childNode(withName: "Tile Map") as? SKTileMapNode
guard let tileMap = self.tileMap else { fatalError("Missing tile map for the level") }
let tileSize = tileMap.tileSize
let halfWidth = CGFloat(tileMap.numberOfColumns) / 2.0 * tileSize.width
let halfHeight = CGFloat(tileMap.numberOfRows) / 2.0 * tileSize.height
for col in 0..<tileMap.numberOfColumns {
for row in 0..<tileMap.numberOfRows {
let tileDefinition = tileMap.tileDefinition(atColumn: col, row: row)
let isEdgeTile = tileDefinition?.userData?["edgeTile"] as? Bool
if (isEdgeTile ?? false) {
let x = CGFloat(col) * tileSize.width - halfWidth
let y = CGFloat(row) * tileSize.height - halfHeight
let rect = CGRect(x: 0, y: 0, width: tileSize.width, height: tileSize.height)
let tileNode = SKShapeNode(rect: rect)
tileNode.position = CGPoint(x: x, y: y)
tileNode.physicsBody = SKPhysicsBody.init(rectangleOf: tileSize, center: CGPoint(x: tileSize.width / 2.0, y: tileSize.height / 2.0))
tileNode.physicsBody?.isDynamic = false
tileNode.physicsBody?.collisionBitMask = playerCollisionMask | wallCollisionMask
tileNode.physicsBody?.categoryBitMask = wallCollisionMask
tileMap.addChild(tileNode)
}
}
}
Personally, I think this approach is too fussy. I'm going to try a different approach in my game and if it works I'll post it here. What I'd really like is for Apple to enhance the tile map API so that we can add physics bodies directly to individual tiles. Maybe in the process they could optimize the engine so that physics bodies on individual tiles would be automatically merged to form larger, more optimal shapes in order to improve system performance.
Update: I filed a request with Apple about this issue, for whatever good might come of it.
I'm not sure there's a surefire way to do this yet... but here's two ways to think about how to try apply physics to a tilemap.
Option 1: Apply SKNodes to each positions of each tile on your map, and apply an appropriate physicsbody to that SKNode based on the content and state of that tile.
Option 2: Use the position information of each tile to add an array of physicsbodies to the SKTileMapNode, and position each of them accordingly.
I'm imagining a gravity down, Mario style platformer, with this kind of terrain in need of physics bodies for the ground:
Lifted transcript from Apple's WWDC about tiles and physics:
And you'll note that I'm colliding with the tiles here.
And I achieve this by leveraging custom user data that we can put on
each of our tiles.
Here, I'll show you in our tile set.
Select one of the variants here.
And you can see that we have some user data over here.
And I just have a value called edgeTile which is a Boolean, and I set
to 1.
So, in code, I'm going through the tile map in our platform demo here,
and I'm looking for all of these edge tiles.
And whenever I find one, I create some physics data to allow the
player to collide with it.
And since it is just in our tile map here, say I wanted to get over
this large wall here.
When I run the game, you'll see that my guy can't actually jump high
enough to get over it.
And he really wants to because that red button over there looks really
tempting.
I really want to push that thing.
So, since we're just generating our physics data from our tiles and
our user data, all we can do is just going here and erase these tiles
and build and run our game again.
The tiles are now gone and we can now move through there.
And we didn't have to change code or anything.
We just used the data that we pulled from the tile map to set up our
tile.
It's that simple.
Makes it sound very simple, but takes a far greater mind than mine to figure out what is being done, and how it's being done.
Alternatively, you can apply a line sweep algorithm to the tiles you want to give a SKPhysicsBody.
You can do this in four steps;
Iterate through the position of the tiles in your SKTileMap.
Find the tiles that are adjacent to one another.
For each group of adjacent tiles, collect:
a down-left corner coordinate and
an up-right corner coordinate.
Draw a square, and move on to the next group of tiles until you run out of tile coordinates.
Screenshot without visuals for comparison
Screenshot without visuals showing the physicsbodies
See my answer in a similar post on how to implement this.
I spent two days trying different ideas but could find nothing better than what I posted in my other answer. As mentioned there, it is the way recommended by an Apple staff member and as far as I know it's the most efficient way to have SpriteKit automatically add physics bodies to all your tiles. I've tested it and it works. (Although I'm still holding my breath for Apple to add a straightfoward way of putting physics bodies on tiles).
But there are other considerations. If you are having performance issues because there are too many physics bodies in your scene, you might want to try one of these other approaches. However, they are both more time-consuming than the approach described above. The only reason that may justify using one of these more labor-intensive approaches is if you need to reduce the number of physics bodies in your scene due to performance issues. Otherwise, I think the "automatic" approach mentioned above is the best option we have.
So I won't go into detail here because I think the automatic option is the best. These are just ideas for alternate approaches if your game needs to be extra stingy with system resources.
Alternate Approach #1 - Use Fewer Physics Bodies
Create your tile map in the editor. Then keep working in the editor to drag Color Sprites (SKSpriteNodes) over parts of your map that need a physics body. Shape the nodes to make the largest rectangle possible for areas that need physics bodies. This works best for for large, flat surfaces like walls, floors, ceilings, platforms, crates, etc. It's tedious but you end up with far fewer physics bodies in your simulation than if you had used the automatic approach mentioned above.
Alternate Approach #2 - Use No Physics Bodies
This idea would probably require even more work, but you could potentially avoid using physics bodies altogether. First, create your tile map in the editor. Analyze your map to identify which tiles mark a barrier, beyond which the player should not cross. Assign a user data identifier to that type of tile. You would need different categories of identifiers for different types of barriers, and you may also need to design your artwork to fit this approach.
Once your barrier tiles are sufficiently identified, write code which checks the user data value for the tile currently occupied by the player sprite and restrict the sprite's movement accordingly. For example, if the player enters a title that marks an upper boundary, your movement code would not allow the player sprite to move up. Likewise, if the player enters a tile that marks the leftmost boundary, your movement code will not let the player travel left.
Okay, so I'm writing code for a space blaster game, and all seems to be going well, minus these crucial issues.
First, I added a spaceship (with PhysicsBody) as a child of self (GameScene).
Then I added a background layer as a node also as a child of self, behind the spaceship, and simulated movement by moving the background around behind the spaceship via joystick control.
I added a node with a boundary physics Edge Loop body so the background wouldn't move beyond the ship, and added that node as a child of the bgLayer.
I have objects for the spaceship to shoot at, but I want them to move around as the background does, so I added them as children of the bgLayer.
Of course, I needed a laser when the spaceship fires, so I added this as well as a child of the bgLayer.
_spaceship.physicsBody = (custom physicsBody code);
[self addChild:_spaceship];
_bgLayer = [SKNode node];
[self addChild:_bgLayer];
_bounds = [SKNode node];
_bounds.physicsBody = (physicsBody edgeLoop code);
[_bgLayer addChild:_bounds];
_otherObjects.physicsBody = (custom physicsBody code);
[_bgLayer addChild:_otherObjects];
_laser.physicsBody = (custom physicsBody code);
[_bgLayer addChild:_laser];
All is well, the background doesn't move beyond the spaceship,the other objects move as the background moves, and the laser fires when called upon.
My first big dilemma is when my laser fires, it does not move as the background moves, but the background moves behind it. I could probably make do but it looks funny if the laser always moves in parallel with the ship. This seems odd to me since I added the laser as a child of _bgLayer.
Second, my laser's physicsBody doesn't seem to recognize the EdgeLoop body, and sails right on through it. Also, my spaceship's physicsBody seems to recognize the EdgeLoop body, but it does not recognize the other objects that are children of _bgLayer.
Do Physics Bodies that are not children of the same layer recognize each other?
And why doesn't my laser behave similarly to other children of the same layer?
Moving the world by changing its position will affect
Children with physics bodies
Children without physics bodies
Moving the world by applying a force/impulse or by settings its velocity will affect
Children without physics bodies
Instead of moving the world by setting its velocity, you can add a camera (an SKNode with a physics body) to the world, move the camera by setting its velocity, and then update the position of the world to center the camera. You can center the camera in the didFinishUpdate method.
-(void)fireLaser
{
_laser = [SKSpriteNode spriteNodeWithImageNamed: [NSString stringWithFormat:#"blueLaser"]];;
_laser.zRotation = _spaceShip.zRotation;
CGVector rotationVector = RadiansToVector(_spaceShip.zRotation);
_laser.position = (Custom code for positioning the laser just in front of the spaceship);
_laser.physicsBody = [SKPhysicsBody bodyWithRectangleOfSize:_laser.size];
[_bgLayer addChild:_laser];
_laser.physicsBody.velocity = CGVectorMake(rotationVector.dx * LASER_SPEED, rotationVector.dy * LASER_SPEED);
}
[self fireLaser] is called in touchesBegan when a particular SpriteNode is touched.
The laser fires beautifully, but does not scroll with the background, but rather moves in relation to the spaceship. Background scrolls with a PhysicsBody and a setVelocity method is called when the joystick moves, thus simulating spaceship motion, when in reality the spaceship never leaves the center of the screen. Physics categories prevent the background physics body from colliding with anything. LASER_SPEED is simply a static const float.
Usually in 2D physics engines like JBox2D, if the user wanted to make a simulation run in "slow motion", you would just decrease the value by which the simulated world iterates by, for example normal movement at 60fps, the step would be 1/60 if the physics world is stepped forward every frame.
But for the SKPhysics class in the sprite kit in xcode 6 using swift, I only see the property called ".speed" which when I decreased, only led to a jittery mess, that updated the physics bodies once every 10 frames.
Is there a specific property, or trick maybe to get the SKPhysics world to iterate forward in time by smaller increments without gross glitchy movements?
The only way to slow down the simulation in sprite kit is to use the physicsWorld.speed element.
But if you are trying to change only one or two sprite speeds, try the velocity element of the sprite:
node.physicsBody.velocity = x
you can directly change the velocity(speed) of your node or sprite through its physicsBody.
Hope it helps :)
so I have a ball (sprite subclass) that can be dragged around the screen and updates it body to tell the world its position.
The problem is, when I apply a force to the ball while the ball is being touched (thus being controlled by a finger), I have two pieces of code fighting against each other to update the sprite's visual position.
The world stepper is trying to follow through the physics and update the ball's position. The touch methods however are also trying to update the ball's body and graphic position. Ideally, when touched I would like to kill off any physics affecting the ball.
So what exactly should I be trying to do to consolidate this? This is also creating issues for collisions and filtering. Any help appreciated. Thanks
Do you want the ball to have an accurate physics simulation? If not, you could always use the SetTransform method of the b2body class like this.
CGPoint ballLocation = ;//use the touched location for this
b2Vec2 vecBallLocation = b2Vec2(ballLocation.x / 32, ballLocation.y / 32);//calculate this on your own
b2Body * ballBody = ;//replace this variable with your ball's b2Body;
ballBody->SetTransform(vecBallLocation, ballBody->GetAngle());
Do not set the ball sprite's position manually. Leave this up to the physics simulation. Your code will get really messy over time if you have to keep track of what sprites you set the position of manually and which ones use the physics simulation to update their positions. This way is also much easier.
When the physics object is being dragged, set its velocity and angular velocity to 0,0 before running the physics step simulation. You may also want to temporarily get the physics object's position, then step, then set the body's position back, then apply whatever touch dragging offset you got from moving the finger to the body.
I currently have a SneakyJoystick up and running. It works fine, it moves the sprite around the screen. I already have it so it will flip the sprite's image when the joysticks degrees is to the left. But how do i make it so if it was moving left and then becomes inactive, the sprite won't automatically flip back? This is really confusing to me. Any help is appreciated. Thanks.
You must have a scheduled selector function in your program that checks the movement of your joystick after every second (or whatever the interval). I mean the code where you are checking if the joystick is towards left (joystick.velociy). So this selector will be called continuously, no matter your joystick is active or not. So when your joystick moves to left, you can flip the sprite and you can set define a boolean flag "isFlipped=true". And in the same selector method that you can check if joystick is not moving and "isFlipped=true" then you can flip back your sprite and set the flag false.
Generally speaking, it is advised to multiple the velocity by an arbitary amount and the delta value passed in to the update routine so that things move more smoothly. That will ensure that the final movement of the player is OK. I have seen people use a value between 50 and 200 for average movement.
eg,
CGPoint velocity = ccpMult(moveStick.velocity, 200 * delta);