Building a platformer with Pixi and PhysicsJs, good idea?

[dajomu]

Hi,

 

I'm pretty new to game development. Having looked at a load of javascript libraries/frameworks (Pixi, Melon, Phaser, Lychee, WADE, etc...), I thought I would try to produce a platformer using Pixi.js.

I would like to build something that I can customize pretty heavily, so building with pixi makes sense, because I can either build my own collision systems and inbuilt physics, or use separate libraries for them.

I'm also considering combining the pixi rendering engine with something like physicsjs.

 

Having read quite a bit through these forums, I couldn't see that anyone had spoken about doing this before.

My main question is, do you think this a good idea?

Is it overkill?

I looked at box2d too, but it seems that developing with either one would be similar(ish).

 

I'm going to make a start on doing this tomorrow morning anyway, as I don't want to hesitate too long before I take the plunge, but I would love to hear of anyone else's experience or objections to doing it this way.

 

Thanks!

 

Dan

[glass22]

Pixi seems great, my problem with it was a lack of documentation, really no way to know how to do half the stuff it's capable of.

[d13]

Yes, it's a great idea and should be pretty easy to do.

PhysicsJS has a much cleaner API than Box2D, and I doubt that for most games, even complex physics games, that you'll need most of Bx2D's lower level access.

 

The PhysicsJS team are also looking for someone to make a Pixi renderer:

 

http://physicsjs.challengepost.com

 

I don't have the time, but it would be fun to do.

 

Or, maybe go the other way and build a PhysicsJS plug-in for Pixi?

[wm1sr]

I'm trying to do something with PhysicsJS and pixi.js as well.

 

The challenging part I'm having is to merge the pixi.js and PhysicsJS output into one scene. I could use the pixi.js renderer to render the PhysicsJS world, but for now I'm doing the following:

• pixi.js renders
• PhysicsJS renders

 

PhysicsJS's Canvas Renderer clear the Canvas before drawing on it, so everything pixi.js rendered before is erased. I prevent it by doing this:

physicsRenderer.beforeRender = null;

Now in the loop:

// pixi.js renderspixiRenderer.render(pixiStage);// pixi.js transforms the canvas and don't restore it back.// So in order to PhysicsJS renders everything correctly after pixi.js I restore itpixiRenderer.context.setTransform(1, 0, 0, 1, 0, 0);// PhysicsJS rendersphysicsWorld.step(time);physicsWorld.render();

 

 

[xerver]

You should just render with pixi, and then use the data from physics to update your sprites. No need to use renderers in a physics engine.

[dajomu]

Regarding mixing physicsJs and Pixi renderers:

 

Having messed about with this for a few days now, I feel like I'm starting to get a good feel for it.

At the moment I'm storing my platformer character as a pixi renderer object and extending it with a few other properties (such as health, etc...)

I started off using a sprite, but I found that it seemed impossible to render that. I'm now using a MovieClip object with multiple frames that skip about to switch between whether the character is jumping/falling/running, etc....

 

wm1sr: I've been experimenting with generating a version of PhysicsJS with the renderer and other unnecessary bits cut out using grunt and the source code from github. To be honest I'm wondering whether to bother with PhysicsJS as I built a very basic physics engine myself (while I tested out pixi). It only has basic stuff like collisions, friction and gravity, but how much more am I seriously going to need? Anyway, I'll let you know how well my experiments with cutting down PhysicsJS to exclude the renderer altogether go in the next few days.

 

glass22: Pixi is definitely lacking in some tutorials and proper examples, though the 15 packaged examples that come with the source can at least show you the way.... It would be good to make a proper tutorial for it at some point though (I may add one to my blog).

 

d13: Thanks for the link to the challenge! I will definitely go in for it if I get far enough by the deadline!

 

I'll let you know how well I manage to integrate everything and hopefully put the code on github soon.

 

Thanks for the replies. x

[markbilly]

I don't like to be one of *those* people but have you considered just vanilla JavaScript?

One can spend ages trying to find the right libraries to do physics, etc but if all you are after is a simple 2d sprite based platformer you really don't need any. It's also obvious from the above posts that using libraries can over complicate things and mean you spend your time solving the wrong problems.

Follow this great little tutorial and see how you get on. Then all you have to do is replace drawRect with drawImage and you have all you need. Plus, you're going to learn a lot more along the way.

http://codeincomplete.com/posts/2013/5/27/tiny_platformer/

[vancura]

I'd just add a few interesting articles on the topic:

 

http://www.learn-cocos2d.com/2013/08/physics-engine-platformer-terrible-idea/

http://higherorderfun.com/blog/2012/05/20/the-guide-to-implementing-2d-platformers/

http://devmag.org.za/2011/01/18/11-tips-for-making-a-fun-platformer/

[JosFaber]

I mostly use the box2d or similar framework for calculation only. Then hide it and render sprites in a graphics framework like pixi. Or sometimes even just divs. The position and rotation is read from the physics elements and copied over to the representation objects. During development you can have both right next to each other, see this simple example: