0
votes

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?

1

1 Answers

2
votes

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.