Proposal for Enhanced Integration of matter.js Physics Engine

[monteiz]

Overview:

Currently, Phaser 3 offers a built-in physics engine alongside support for matter.js. After using both extensively, I'd like to propose a discussion on the potential benefits of focusing more on enhancing the integration with matter.js rather than continuing to develop the built-in physics engine.

Reasoning:

1. Advanced Features: matter.js boasts a range of advanced features and capabilities that surpass the built-in engine. It's a mature and widely-used physics engine within the development community.
2. Efficiency: Instead of maintaining two separate physics engines within Phaser 3, consolidating efforts into improving the matter.js integration could lead to more streamlined and effective development.
3. User Experience: Dealing with multiple physics engines can be confusing for users, especially newcomers. Consolidating around matter.js could simplify the learning curve and overall user experience.

Proposed Steps:

1. Enhanced Integration: Allocate resources towards optimizing and enhancing the integration with matter.js, potentially phasing out the reliance on the built-in engine.
2. Documentation and Guidance: Provide comprehensive documentation and guidance on leveraging matter.js within Phaser 3, ensuring users have the necessary resources for a smooth transition.

Benefits:

1. Unified Experience: Users will benefit from a more coherent and unified physics system, reducing confusion and fostering a more accessible development environment.
2. Improved Functionality: Leveraging matter.js can open doors to more advanced physics simulations and interactions, enriching the possibilities within Phaser 3 games and applications.
3. Community Alignment: Aligning with a well-established and respected physics engine like matter.js can encourage community engagement and contributions.

Conclusion:

I strongly believe that consolidating efforts on matter.js integration aligns with Phaser 3's goal of providing a robust and user-friendly framework. I look forward to engaging in discussions and contributing to this potential direction for the platform.

[photonstorm]

I'm not entirely sure how we'd enhance the Matter integration any further? We are already using a version of Matter in advance of the main branch on their own repo (with a few extra features we added, plus some of their upstream optimizations they're yet to integrate into their main), and we have better TypeScript definitions!

We could author new documentation, but that's nothing to do with integration as such, more just education.

The biggest issue is that Matter is very sporadically updated. I'm pleased the main dev still has interest in it, but updates, fixes and features are very infrequent, which is fair enough, it's just a little side project for him. The simulation accuracy, thanks to relying almost entirely on verlet integration, isn't very stable either and it often falls over in a few key areas (stacking, high hz displays, complex scenes, etc) compared to the likes of Box2D. If it was frequently updated and maintained then I would have probably done what you suggested years ago, but sadly that isn't the case.

Plus, we're about to move fully into Phaser 4 development now. And the first versions of that won't have any bundled physics systems at all. It will be entirely up to you to pick what you want to use and integrate it yourself. Personally, I'd likely start with something along the lines of Rapier.

[monteiz]

Thank you for the detailed response, @photonstorm.

To clarify my point further, the idea isn't merely about fixing the built-in physics engine, but rather directing efforts toward completing the matter.js integration due to its far superior capabilities in the realm of JavaScript 2D physics.

For instance, I've noticed instances like the newVelocity property being undefined within the body instance when using matter.js, contrary to the documentation's specifications.

Switching entirely to matter.js as the sole physics engine could significantly streamline documentation efforts, a facet I understand as a considerable workload in the workflow (even with AI's contributions vastly improving productivity in this area). This consolidation could greatly simplify the learning curve and reduce potential confusion for developers.

Additionally, I'm unsure about the notion of entirely removing a physics engine from a game engine framework to enhance it. It seems counterintuitive to remove a fundamental feature like a physics engine, as it can potentially limit the out-of-the-box functionality and accessibility for users.

Physics engines are often fundamental to game development, especially for newcomers who rely on built-in systems to kickstart their projects. Removing this core feature might pose challenges in terms of accessibility and might steepen the learning curve, potentially discouraging some developers.

[photonstorm]

This still doesn't sound like integration to me. It sounds like fixing bugs within Matter, that for some reason (time? enthusiasm?) the Matter author has decided not to fix. They very rarely merge pull requests on the main Matter repo. So we'd have to make the fixes downstream and then just hope they merge upstream. Far more likely to happen, is they just replace whole sections of the library with new features and it utterly breaks our now out-of-sync downstream version.

As I said, if Matter was more actively maintained by its author, your idea is fine and makes sense. But sadly that isn't the case. And that's fine, like I said, it's only a hobby project for him. He has no obligation to merge PRs or fix things. However, it will not be part of Phaser 4 as a result of this.

[monteiz]

Thank you for your response @photonstorm.

Considering the challenges with Matter.js's maintenance, I wonder if it might be worthwhile to explore an alternative avenue. Instead of dedicating resources to the development of a built-in physics engine within Phaser 3, would it be viable to consider creating an independent fork of the Matter.js project?

By forking the project and continuing its development independently, the Phaser team could potentially address improvements, bug fixes, and enhancements specific to Phaser's needs. This approach could offer more control over the evolution of the physics engine while ensuring it remains aligned with Phaser's goals and requirements.

I understand this proposal might involve additional considerations and efforts, yet it could provide a middle ground between relying on the original Matter.js and developing an in-house solution.

[photonstorm]

I think if we're going to adopt and use a new physics system, even one we maintain ourselves, that there are honestly better alternatives these days. It's also a massive undertaking and would take away a lot of focus from Phaser itself. But, it's also important. So something for the team to consider in the coming months.

[monteiz]

Yeah, I'm not a big fan of Matter.js either; it feels a bit shaky. But I'm glad we could talk about the importance of a good physics engine. A game framework in 2024 needs solid physics to stay competitive, right?

Thanks for thinking about this suggestion for the future. It's tricky to balance new ideas, stability, and using resources wisely. I trust the Phaser team to handle it well and stay on track with their plans.

Thanks for the great chat about Phaser's future... I'll be excited to see how things go from here.

[wyattades]

Plus, we're about to move fully into Phaser 4 development now. And the first versions of that won't have any bundled physics systems at all. It will be entirely up to you to pick what you want to use and integrate it yourself. Personally, I'd likely start with something along the lines of Rapier.

Hey @photonstorm, I'm about to kick off integrating rapier.rs into my own phaser project; I mostly need it to get deterministic physics in my multiplayer game. Do you know of any examples to work off of for integrating rapier (or any custom engine)?

[photonstorm]

Beyond what we do already with Arcade or Matter, or did in the past with Box2d or p2, not really. Mostly you just sync the sprite with the body and the rest is helper functions to ease dev.