For Kobold Kit (the Sprite Kit game engine) we’re working on Super Stick Spy, a 2D platformer game. Like so many others, we started out using the (Box2D) physics engine that’s so neatly integrated in Sprite Kit to get everything up and running quickly.
But we knew full well that for the final product, we’ll have to scrap the physics engine altogether and follow best practices when it comes to platformer-programming.
Now with the demo version nearing completion (see video) I can tell you in full detail why you don’t want to use a physics engine for a 2D platformer!
Moving Platform Hell
A moving platform with physics needs to be a dynamic body. Don’t even try moving static bodies, at least in Box2D that will end up in jumpy movement of the body. Though kinematic bodies work better (if available).
The player or other game characters standing on a moving physics body will have the platform slide underneath their feet. The characters won’t magically move along with the platform! And there is no feature in the physics engine that lets you set this up. You have to program it to synchronize character movement with the platform they’re currently standing on, and end the synchronization as soon as a character lifts its feet up from the platform.
Which can be a problem for downward-moving platforms as the player loses contact with the platform every other frame, starts falling, and lands right back on the platform. To put it in Homer’s words: “Doh, doh, doh, doh, doh, doh, doh …”. So you need to make the character stick to the platform, yet allow him to fall off of the ledges and jump, and possibly also allow him to be forced off the ground by normal collision events (projectile impact, platform moving through a tiny crevice). Continue reading »
You have a tilemap and you want physics collisions on it? The solution seems obvious: create a rectangle shape for every blocking tile.
But ouch! This solution is not just hugely wasteful and unnecessarily slows down the physics collision code, it also introduces the well known problem of characters getting stuck even on flat surfaces.
This is in particular a problem for Box2D because its collision mechanic doesn’t work well with flat surfaces subdivided into smaller segments (rectangle shapes in this case).
A workable but still very awkward solution to work around this behavior is to create characters with bevelled edges at the character shape’s bottom at the risk of bopping characters as they walk about the map.
Lupines in the Moore Neighborhood
A good solution to generate physics collisions is to implement the Moore Neighborhood algorithm to generate chain shapes which are more suitable for tilemap collisions. The downside is that adding or removing individual blocking tiles at runtime requires updating the shapes - this is not implemented in this project.
Every flat surface, no matter how many tiles form the surface, will then consist of only one straight collision segment. Here’s a quick demo video of the project discussed in this post that shows the algorithm at work and the resulting “game”:
Another live report from the front…
LearnCocosTV - Episode 2: Fixing Bad
• Simple Multiplayer Data Sharing Project
• iDevBlogADay: Fast Pixel-Perfect Collision Detection
• Kobold2D 1.0.1 Released:
o KKPixelMaskSprite, KKScreenshot, Ad Banner rotation
o Solutions for “failed with exit code 1” linker errors
• Xcode Trips & Ticks
This continues and concludes the previous post of the Fast Pixel-Perfect Collision Detection for Cocos2D with Example Code (1/2) article.
In my book I explained how to create collision shapes for physic engines using the freely available version of VertexHelper Pro. Granted, it works, but as soon as you need to update your shapes frequently or you have many different shapes to edit it’s going to be a lot of manual work and error-prone copy & paste between VertexHelper’s code generator and your source code.
VertexHelper, meet your replacement: PhysicsEditor
PhysicsEditor was written by Andreas Löw, the author of the very popular TexturePacker tool. He has proved again that he can create powerful yet easy to use tools for game developers.
The greatest part about PhysicsEditor: it can automatically trace your shapes to generate collision shapes and it works flawlessly! You can even tweak the amount of vertices (and a lot of other things) as needed, for example if your physics engine has a limitation on how many vertices can be used for a collision shape (Box2D default: 8 vertices).
But it doesn’t just create the collision shapes, it also allows you to edit physics properties of a shape that often go along with it. Density, friction, “bouncyness”, and other parameters can be tweaked in the GUI.
As they say, an image speaks louder than words, so I suppose a video speaks in a thousand images:
Not just Cocos2D
PhysicsEditor currently exports to Cocos2D + Box2D (Chipmunk/SpaceManager support is forthcoming and should be available soon) and also to Sparrow Framework + Chipmunk and of course Corona SDK.
And it works on Windows, too! Which makes sense given that Corona supports Android development under Windows.
I also found this post about PhysicsEditor with a working Flash example (at the bottom). It seems that even exporting respectively using PhysicsEditor with Flash + Box2D seems to work well. Wow!
Brace for impact!
Check out the PhysicsEditor Features page to learn more about what this great tool can do for you! You can get PhysicsEditor alone for $17.94 but you can also grab a bundle deal which includes TexturePacker for $29.99, or almost 20% off.
Continuing with yesterday’s Box2D Car demo I’d like to stay on the topic of Box2D and present to you the Tilemap based Box2D world put together by theTconcept, a website hosted by a group of italian and mexican designers, writers and coders.
In their tutorial they explain how to create Box2D collisions from a Tiled Map Editor world, by using the object group layer. The one you can use to place arbitrary rectangles on in Tiled. The resulting Xcode project is available for download.
