Recently I've participated in pyweek (http://www.pyweek.org). I wanted to experiment with box2d + svg as a physics level editor.
Game:
http://media.pyweek.org/dl/9/GasMan/gasman-1.0.tar.gz
Using SVG as a physics editor was based on this post by @rolando:
http://www.cocos2d-iphone.org/forum/topic/124
Also @pabloruiz55 posted some code here:
http://www.cocos2d-iphone.org/forum/topic/1941#post-12181
and I've also been playing with it in:
http://blog.sapusmedia.com/2009/08/cocos2d-box2d-part-ii.html
So, here are some thoughts:
Editor integration
I think there are 3 stages:
a) No integration at all
- You need to code your physics objects
- Test them
- Worst possible scenario
b) "Off-line" editor
- Edit the shapes, positions, etc in an editor
- You need to run the code to test it
- Example: SVG editor
c) "On-line" editor
- Edit the shapes, positions, everything at runtime
- Every add/remove/change can be made at runtime
- Example: Unity3d, Mekanimo
It takes time to have a physics editor like Unity3d's. But I think that that is the ideal scenario.
But with Mekanimo ( http://www.mekanimo.net ) you can create complex physics object in a matter of minutes. And you can also export your physics objects to CPP.
So instead of trying to have c) (I don't have the resources), I was trying to have something like b).
implementation of b):
- Using SVG to edit the physics shapes: boxes, circles. In particular Inkscape.
- Editing the shapes properties from SVG: create custom tag like: physics_shape
- Implementing a simple SVG parser that knows how to create circle, boxes
- Attach sprites to shapes
New added SVG tags:
- game_data
- physics_shape
These 2 new tags can added/deleted/modified within inkscape.
game_data:
- to be used to associate 'cocos2d' with 'box2d', eg: sprites with shapes.
physics_shape:
- contains all the shape properties, like restitution, density, etc.
eg:
<path
sodipodi:type="arc"
style="stroke-width:3;stroke-miterlimit:4;stroke-dasharray:none"
id="path4992"
sodipodi:cx="314"
sodipodi:cy="330.5"
sodipodi:rx="36"
sodipodi:ry="36.5"
d="m 350,330.5 a 36,36.5 0 1 1 -72,0 36,36.5 0 1 1 72,0 z"
transform="translate(100,-94)"
game_data="sprite=bad_guy"
physics_shape="restitution=1,density=5" />Look at:
game_data="sprite=bad_guy"
It means that this object will be associated with a "bad guy". All the code related to "bad guy" will be executed:
- adding this shape to the list of "bad guys" collision list
- attaching a cocos2d sprite to this shape
Look at:
physics_shape="restitution=1,density=5"
It means that this shape will have restitution of 1 and an density of 5.
Some conclusions
Being in scenario b) is much better than being in a) but there is a long way to have something like c)
Still, scenario b) can be improved with Mekanimo.
Scenario "b improved"
- create complex objects on Mekanimo
- test them on Mekanimo
- Export them to .cpp
- Include a game_data that refers to the new objecs
eg:
<path
sodipodi:type="arc"
style="stroke-width:3;stroke-miterlimit:4;stroke-dasharray:none"
id="path4992"
sodipodi:cx="314"
sodipodi:cy="330.5"
sodipodi:rx="36"
sodipodi:ry="36.5"
d="m 350,330.5 a 36,36.5 0 1 1 -72,0 36,36.5 0 1 1 72,0 z"
transform="translate(100,-94)"
game_data="sprite=theo_jansen_1"
/>So, when you parse an sprite=theo_jansen_1 you just apply the code that was exported from Mekanimo.
So:
1) Inkscape + Box2d: Useful for platform games without complex physics objects
2) Inkscape + Mekanimo + box2d: Useful for platform games with complex physics objects
I didn't try 2) yet but I think it's possible, and that's what I will try next.
