I am working on an iOS game using Swift and SpriteKit. It involves collisions between two or more SKShapeNodes that have physics bodies that go along with them.
My problem is that when they collide, if they are going too slow, the collisions are treated as inelastic and rather than bouncing they "stick" to each other so to speak.
From numerous searches, I believe I've found the problem to be in the underlying physics engine which is Box2d. There is a defined constant 'b2_velocityThreshold' that is set to 1.0f and if a collision happens at speeds under that threshold, I run into the issue stated.
How do I go about changing that value to a number that would help maintain the elastic collisions? I'm not sure how to access the files and be able to update that value. Would I need to download the Box2d library and then connect that into my project somehow? Or would I need to restart and import that from the start? and build the project in C++ from the beginning because Box2d is written in C++?
In Sprite Kit you can't change any of the box2d parameters because there's no source code for Sprite Kit and the version of Box2d that Apple used to build Sprite Kit with. You will have to make the game work with whatever parameters are exposed by the Sprite Kit API.
One thing you can try: set friction of the two slow moving bodies to 0. This may preserve their energy (velocities) when colliding.
Related
I'm trying to understand the proper way to move "obstacle" objects in corona/box2d. I want to know how to write my code so that the movement is deterministic and in-step with the physics engine. Is this possible?
I'm familiar with Unity which has a physics update (FixedUpdate). Where you can add a bit of code to execute on every physics step. This keeps the physics deterministic, frame and system time independent.
For example, in my game I want to do things like: Make a platform that moves back and forth, make an object that scales up and down in size. I would still like the physics to work properly and allow the ball in my game to bounce off of these for example. Depending on the case, I imagine that I should use either kinematic or dynamic bodies.
I've searched around and the way to periodically manipulate these objects is to use:
timer.performWithDelay. But this has an issue mentioned in the docs "Timers run on system time. If the app is suspended, running timers will not be automatically paused"
Listening to an enterFrame event. But this has a similar issue, if the frame rate drops then the object won't be moved enough. We can use delta time to deal with this, but this has determinism issues (moving an object too much on a lag spike).
transition.to. I'm guessing this is implemented with timer.performWithDelay and has the same issues.
I don't think that any of these will behave deterministic. Any suggestions? Thanks for the help.
You should really use:
object:setLinearVelocity(xVelocity, yVelocity)
or
object:applyForce(xForce, yForce)
instead of transition.to.
I'm trying to replicate the pendulum effect as seen in the old game "Gold miner", if you ever played it before. Do I need to use a physics engine for that, or not? I heard that Box2D is preferred over Chipmunk when it comes to ropes, but do I really have to join two objects together with a rope to accomplish this pendulum effect? I'd love to do it without a physics engine, but if I have to use one I think I would pref chipmunk as it comes with Cocos2d v3. (In short, whats the best way of making a pendulum that swings forever and can be lowered and raised)
Im' a complete n00b when it comes to physics engines, never used one before, only made non-games apps before :/ Any help is very appreciated =)
You mean the grappling hook in that game? That's absolutely not physics, or at least can be done easily without a physics engine. At best you may want to use the physicss engine's raycast collision detection methods (if any).
I just started to learn how to use spritebuilder since basically everyone told me it saves a lot of time and easy to integrate things, but I am running to an issue where the objects and players that are suppose to sit on the ground fall through.
You need to use a single CCPhysicsNode that contains all the physics objects of your game.
Your setup effectively creates two separate physics worlds that won't interact with each other, therefore rock and guy will never be able to "make contact" with ground.
Interestingly you tagged this with sprite-kit so if you are using the (not officially released, no longer in development) SpriteBuilder version that supports Sprite Kit, know that CCPhysicsNode will not function at all. The SpriteBuilder Sprite Kit version does not support physics.
I trying to rewrite simple game (developed by me with Cocos2d+Box2d sometime ago) using Sprite Kit framework. Everything looks much simpler in Sprite Kit, which is great, but I have a problem adjusting physics world parameters in the new project. I have noticed that sprites created using exactly same graphic images (all have basic rect-based bodies) have four times lower mass in Sprite Kit than it had in Cocos2d+Box2d. Setting bodies density to 4 solve the problem, unfortunately that's not the main issue. It looks like the same problem with 4-time multiplier works for all forces in the physics world. I have done some testing in Sprite Kit and create a body with mass four time higher than in Cocos2d+Box2d, I have also set the world gravity to be four time lower than in Cocos2d+Box2d. As a result physic in both projects (first using Cocos2d+Box2, second using Sprite Kit) behaves similarly. I can't find anything like PIXEL_TO_METER_RATIO (that was available in Box2) in Sprite Kit. Is there any option that allows to adjust the physics world in Sprite Kit to behave like in Cocos2d+Box2d without multiplying all forces, masses etc? Maybe there is some kind of configuration property that allows to adjust it. If I leave the same values for gravity, mass and forces in Sprite Kit that I was using in Cocos2d+Box2d everything in the game will be simulated too fast. My question is how to deal with problems like this when migrating from Cocos2d with Box2d to Sprite Kit framework?
The only solution is to re-tweak the forces and other settings until things feel right.
Internally Sprite Kit uses Box2D but we have no way of knowing if and how Apple may have modified it. What is known is that they use different default settings for the Box2D world which means physics values can not be ported as is and expect the same results.
I believe this was discussed in the developer forum (under Sprite Kit) where someone investigated the actual numbers for changed settings. Note that these are settings in Box2D's code most users won't even consider to modify, so we have to assume Apple had their reasons to change them in the first place.
I am currently part way through developing my first game with chipmunk2D on the iOS platforms.
One problem I have encountered however is the lack of repeatability within the chipmunk environment. For example, I can have a fairly simple (<20 blocks) setup and yet every time physics is applied to the body's they react in slightly different ways. The ways they react are never violently different yet they are different enough to the point where it is game breaking for me.
When creating the chipmunk bodys/shapes/spaces I am including size, mass, moment, friction, and elasticity. I believe I am including everything there.
Does chipmunk use some randomization in its physics code? If not (or even if it does) What is the best way to fix this randomization
http://chipmunk-physics.net/release/ChipmunkLatest-Docs/#cpShape-Misc
Chipmunk keeps a counter so that every new shape is given a unique
hash value to be used in the spatial index. Because this affects the
order in which the collisions are found and handled, you can reset the
shape counter every time you populate a space with new shapes. If you
don’t, there might be (very) slight differences in the simulation.
So, reset the counter before each simulation, and you should have better reproductibility.