I'm working on a project where I have a node affected by gravity. I would like to be able to apply a vertical acceleration to this node without touching gravity. Pretty much like a hot air balloon that I would make go up or down while other objects are still normally affected by gravity.
balloon = Vehicle()
balloon.physicsBody = SKPhysicsBody(polygonFrom: path)
balloon.physicsBody?.affectedByGravity = true
I tried playing around with applyForce(_:) and impulse but what I'd like is a proper acceleration and not a punctual impulse to defy gravity over time! Any suggestion?
What you're looking for are physics fields (SKFieldNode), in Sprite Kit.
These provide the ability to influence objects with general forces, like wind, lift, black hole style attraction etc.
You can read about them here.
The really important consideration of how they can work is in this quote:
Physics bodies with affectedByGravity set to false are still affected
by the gravity fields created by linearGravityField(withVector:) and
radialGravityField().
But what they forgot to also make clear(er) is that objects influenced by gravity are ALSO influenced by these fields.
Let's say I have a SKSpriteNode that represents a car wheel, with a circular SKPhysicsBody successfully attached to it. The genre would be sideways scrolling 2d car driving game/simulator, obviously.
What I want is to calculate all the in-motor physics myself without resorting to the SpriteKit physics engine quite yet. I'd like to keep full control on how the mechanics of the motor, clutch, transmission etc. are calculated, all the way to the RPM of the drive wheel.
From that point onwards, though, I'd happily give control to the SpriteKit physics engine, that would then calculate what happens, when the revolving drive wheel touces the surface of the road. The car advances, slows down, accelerates and/or the wheels slip, whatever the case might be.
Calculating the mechanics to get the wheel RPM is no problem. I'm just not sure on how to go on from there.
I'm able to rotate the wheel simply by applying zRotation in the update: method, like this:
self.rearWheelInstance.zRotation += (self.theCar.wheelRPS/6.283 * timeSinceLastUpdate); // revolutions / 2pi = radians
This way I'm able to apply the exact RPM I've calculated earlier. The obvious downside is, SpriteKit's physics engine is totally oblivious about this rotation. For all that it knows, the wheel teleports from one phase to the next, so it doesn't create friction with the road surface or any other interaction with other SpriteKit physicsBodies, for that matter.
On the other hand, I can apply torque to the wheel:
[self.rearWheelInstance.physicsBody applyTorque: someTorque];
or angular impulse:
[self.rearWheelInstance.physicsBody applyAngularImpulse: someAngularImpulse];
This does revolve the wheel in a fashion that SpriteKit physics engine understands, thus making it interact with its surroundings correctly.
But unless I'm missing something obvious, this considers the wheel as a 'free rolling object' independent of crankshaft, transmission or drive axel RPM. In reality, though, the wheel doesn't have the 'choice' to roll at any other RPM than what is transmitted through the drivetrain to the axel (unless the transmission is on neutral, the clutch pedal is down or the clutch is slipping, but those are whole another stories).
So:
1) Am I able to somehow manipulate zRotation in a way that the SpriteKit physics engine 'understands' as revolving movement?
or
2) Do I have a clear flaw in my logic that indicates that this isn't what I'm supposed to be trying in the first place? If so, could you be so kind as to point me to the flaw(s) so that I could adopt a better practice instead?
Simple answer, mixing 2d UI settings, like position and zRotation, with a dynamic physics system isn't going to have the results you want, as you noticed. As you state, you'll need to use the pieces of the physics simulation, like impulse and angular momentum.
The two pieces of the puzzle that may also help you are:
Physics Joints - these can do things like connect a wheel to an axel so that it can freely rotate, set limits on rotation, but still impart rotational forces on it.
Dynamically Adjusting Physics Properties - like increasing friction, angular dampening or adding negative acceleration to the axel as the user presses the brakes.
After quite a few dead ends I noticed there is in fact a way to directly manipulate the rotation of the wheel (as opposed to applying torque or impact) in a way that affects the physics engine accordingly.
The trick is to manipulate the angularVelocity property of the physicsBody of the wheel, like so:
self.rearWheelInstance.physicsBody.angularVelocity = -self.theCar.wheelRadPS;
// Wheel's angular velocity, radians per second
// *-1 just to flip ccw rotation to cw rotation
This way I'm in direct control of the drive wheels' revolving speed without losing their ability to interact with other bodies in the SpriteKit physics simulation. This helped me over this particular obstacle, I hope it helps someone else, too.
I'm working for a small bouncing ball game using the SpriteKit physics engine. My problem is:
When I apply a huge impulse on the bouncing ball to have it fall on ground fast, sometimes it may pass through the ground (very thin, height=2).
I find this in the Apple document, but it doesn't work.
Specify High Precision Collisions for Small or Fast-Moving Objects
When Sprite Kit performs collision detection, it first determines the locations of all of the physics bodies in the scene. Then it determines whether collisions or contacts occurred. This computational method is fast, but can sometimes result in missed collisions. A small body might move so fast that it completely passes through another physics body without ever having a frame of animation where the two touch each other.
If you have physics bodies that must collide, you can hint to Sprite Kit to use a more precise collision model to check for interactions. This model is more expensive, so it should be used sparingly. When either body uses precise collisions, multiple movement positions are contacted and tested to ensure that all contacts are detected.
ship.physicsBody.usesPreciseCollisionDetection = YES;
You can set your sprite's node.physicsBody.usesPreciseCollisionDetection = YES; but this will not guarantee a collision flag all the time as your sprite's velocity could simply be just too high.
You should apply a speed limit to your nodes as to prevent them from going too fast. Something like this:
if(node.physicsBody.velocity.dx > 200)
node.physicsBody.velocity = CGVectorMake(200, node.physicsBody.velocity.dy);
The above code example will limit the right movement, dx, of your node to 200 while keeping the dy (up/down) velocity as is.
I'm working on a 2D Platform game, and I was wondering what's the best (performance-wise) way to implement Surface (Collision) Detection.
So far I'm thinking of constructing a list of level objects constructed of a list of lines, and I draw tiles along the lines.
alt text http://img375.imageshack.us/img375/1704/lines.png
I'm thinking every object holds the ID of the surface that he walks on, in order to easily manipulate his y position while walking up/downhill.
Something like this:
//Player/MovableObject class
MoveLeft()
{
this.Position.Y = Helper.GetSurfaceById(this.SurfaceId).GetYWhenXIs(this.Position.X)
}
So the logic I use to detect "droping/walking on surface" is a simple point (player's lower legs)-touches-line (surface) check
(with some safety approximation
- let`s say 1-2 pixels over the line).
Is this approach OK?
I`ve been having difficulty trying to find reading material for this problem, so feel free to drop links/advice.
Having worked with polygon-based 2D platformers for a long time, let me give you some advice:
Make a tile-based platformer.
Now, to directly answer your question about collision-detection:
You need to make your world geometry "solid" (you can get away with making your player object a point, but making it solid is better). By "solid" I mean - you need to detect if the player object is intersecting your world geometry.
I've tried "does the player cross the edge of this world geometry" and in practice is doesn't work (even though it might seem to work on paper - floating point precision issues will not be your only problem).
There are lots of instructions online on how to do intersection tests between various shapes. If you're just starting out I recommend using Axis-Aligned Bounding Boxes (AABBs).
It is much, much, much, much, much easier to make a tile-based platformer than one with arbitrary geometry. So start with tiles, detect intersections with AABBs, and then once you get that working you can add other shapes (such as slopes).
Once you detect an intersection, you have to perform collision response. Again a tile-based platformer is easiest - just move the player just outside the tile that was collided with (do you move above it, or to the side? - it will depend on the collision - I will leave how to do this is an exercise).
(PS: you can get terrific results with just square tiles - look at Knytt Stories, for example.)
Check out how it is done in the XNA's Platformer Starter Kit Project. Basically, the tiles have enum for determining if the tile is passable, impassable etc, then on your level you GetBounds of the tiles and then check for intersections with the player and determine what to do.
I've had wonderful fun times dealing with 2D collision detection. What seems like a simple problem can easily become a nightmare if you do not plan it out in advance.
The best way to do this in a OO-sense would be to make a generic object, e.g. classMapObject. This has a position coordinate and slope. From this, you can extend it to include other shapes, etc.
From that, let's work with collisions with a Solid object. Assuming just a block, say 32x32, you can hit it from the left, right, top and bottom. Or, depending on how you code, hit it from the top and from the left at the same time. So how do you determine which way the character should go? For instance, if the character hits the block from the top, to stand on, coded incorrectly you might inadvertently push the character off to the side instead.
So, what should you do? What I did for my 2D game, I looked at the person's prior positioning before deciding how to react to the collision. If the character's Y position + Height is above the block and moving west, then I would check for the top collision first and then the left collision. However, if the Character's Y position + height is below the top of the block, I would check the left collision.
Now let's say you have a block that has incline. The block is 32 pixels wide, 32 pixels tall at x=32, 0 pixels tall at x=0. With this, you MUST assume that the character can only hit and collide with this block from the top to stand on. With this block, you can return a FALSE collision if it is a left/right/bottom collision, but if it is a collision from the top, you can state that if the character is at X=0, return collision point Y=0. If X=16, Y=16 etc.
Of course, this is all relative. You'll be checking against multiple blocks, so what you should do is store all of the possible changes into the character's direction into a temporary variable. So, if the character overlaps a block by 5 in the X direction, subtract 5 from that variable. Accumulate all of the possible changes in the X and Y direction, apply them to the character's current position, and reset them to 0 for the next frame.
Good luck. I could provide more samples later, but I'm on my Mac (my code is on a WinPC) This is the same type of collision detection used in classic Mega Man games IIRC. Here's a video of this in action too : http://www.youtube.com/watch?v=uKQM8vCNUTM
You can try to use one of physics engines, like Box2D or Chipmunk. They have own advanced collision detection systems and a lot of different bonuses. Of course they don't accelerate your game, but they are suitable for most of games on any modern devices
It is not that easy to create your own collision detection algorithm. One easy example of a difficulty is: what if your character is moving at a high enough velocity that between two frames it will travel from one side of a line to the other? Then your algorithm won't have had time to run in between, and a collision will never be detected.
I would agree with Tiendil: use a library!
I'd recommend Farseer Physics. It's a great and powerful physics engine that should be able to take care of anything you need!
I would do it this way:
Strictly no lines for collision. Only solid shapes (boxes and triangles, maybe spheres)
2D BSP, 2D partitioning to store all level shapes, OR "sweep and prune" algorithm. Each of those will be very powerfull. Sweep and prune, combined with insertion sort, can easily thousands of potentially colliding objects (if not hundreds of thousands), and 2D space partitioning will allow to quickly get all nearby potentially colliding shapes on demand.
The easiest way to make objects walk on surfaces is to make then fall down few pixels every frame, then get the list of surfaces object collides with, and move object into direction of surface normal. In 2d it is a perpendicular. Such approach will cause objects to slide down on non-horizontal surfaces, but you can fix this by altering the normal slightly.
Also, you'll have to run collision detection and "push objects away" routine several times per frame, not just once. This is to handle situations if objects are in a heap, or if they contact multiple surfaces.
I have used a limited collision detection approach that worked on very different basis so I'll throw it out here in case it helps:
A secondary image that's black and white. Impassible pixels are white. Construct a mask of the character that's simply any pixels currently set. To evaluate a prospective move read the pixels of that mask from the secondary image and see if a white one comes back.
To detect collisions with other objects use the same sort of approach but instead of booleans use enough depth to cover all possible objects. Draw each object to the secondary entirely in the "color" of it's object number. When you read through the mask and get a non-zero pixel the "color" is the object number you hit.
This resolves all possible collisions in O(n) time rather than the O(n^2) of calculating interactions.
I have an issue similar to http://farseerphysics.codeplex.com/Thread/View.aspx?ThreadId=72364
I have a rectangle player geom, and many rectangle tile geoms lined up next to each other.
Occasionally when the player geom is crossing between them he seems to clip onto the corners of the tile geom and as a result rotate over.
Even when switching the moment of inertia to infinity which prevents rotation, the player geom "hops" when it clips the edge.
Here is a screenshot of the geoms tripping image http://notspike.com/PrototypeG/trip.png
Is there any fix for this? I've tried the Farseer forums but it seems pretty inactive
Here is a link to a video using a circle geom for the player
http://www.notspike.com/PrototypeG/trip.avi
I would suggest that you avoid the use of small tiles placed next to each other for the level's collision geometry. For example, although visually it's clear that you're using tiles, the "floor" from the video would best be described as a long contiguous rectangle. That way, you don't have this problem at all ... floating point math is already imprecise enough and tiling collision geometry is just asking for that to go wrong :-)
I've had this happen before when my shapes are small enough or the movements are fast enough for the interval between physics calculation "ticks" to be enough to allow the objects to overlap before the collision detection kicks in.