Would Echo (A Haxe Native Physics Engine) Be Viable As a Driver For Awe6

[bedwardly-down]

I noticed that Box2D was being tested out fairly recently and attempted to implement it in a test project. Despite there being quite a bit of documentation for it, it was pretty painful to get it to work with awe6 and the pixijs target (most likely due to my own lack of experience with it and how highly verbose Box2d is). It was suggested that I tested out Echo, a more modern, streamlined 2D physics engine that was developed in order to make physics easier to implement. Its dev is also pretty active and is available for support in several of my own game dev circles. Much of what I learned from Box2D translated directly to Echo and I've uploaded my test repo here.

Echo does have DebugDraw support for OpenFL and Heaps and making a Pixijs driver for in the framework was very straightforward. I haven't tested the OpenFL part of it, but if it's anything like my experience with using Pixijs, it would most likely require backend work to get functional. I know that it was stated that you prefer not having a physics library implemented directly into awe6 when I did my Pixijs 5 port test, but I'd still like your thoughts on this. Thanks. :smile_cat:

[hypersurge]

If it helps, we use Box2D frequently and added both a PixiJS and CreateJS debugDraw to the Haxe version https://github.com/hypersurge/box2d

Box2D is comprehensive (with joints and motors) and well documented at https://www.iforce2d.net/b2dtut/, however probably isn't the most friendly when creating custom resolvers, and the api is C++ flavoured? For non-joint projects we still regularly use the much simpler Physaxe (Echo looks to be a similar feature set?).

My thoughts are that separation is important - so implementing physics libraries directly into awe6 isn't necessary or desirable. Instead we compose them in an IEntity when needed, and endeavour to avoid exposing anything library specific in the public interface so as to "black box" physics as-a-service.

The intended advantage is that a developer can pick the physics (or rendering, or pathfinding, or whatever) library that works for their project, and potentially swap it out later if the requirements change. Thanks.

[bedwardly-down]

Thanks for such a detailed response and that makes perfect sense. Part of future-proofing means having the bare essentials built in and leaving how the end user extends it up to them, am I correct in reading that that way?

[bedwardly-down]

I also wanted to say thanks for the info on the box2d debug draw for pixijs. Since Echo is going to be fine for my needs for the time being, I’ll use that as a base for my testing. The way Echo did its other renderers seems pretty similar, so I’ll have to research a bit. ;)