A physics engine seems like such a basic feature.
We considered incorporating one, but at the end of the day it just added complexity to the apis. We’ve never had great experiences with built-in physics engines. And for 2D games, we found that the geometry apis we provide to determine collision were good enough.
I understand that you think it should be a standard/default feature. I really do get that. But we didn’t want to incorporate something half-assed just to check a checkbox on a feature list.
To prove my point.
Take any of the engines you’ve evaluated and try to get a sprite to run up a diagonal ramp. It should be a piece of cake with a built in physics engine. Right?
Another thing to try. Have a platform that moves up and down. And try to get your player sprite to stay in sync with the platform’s movement, until they jump. Again, this should be trivial to do.
3 years ago(+1)(-1)
Godot's default 2d rigidbody physics are excellent, at the very least, and Unity's 2d physics are passable. Certainly better than nothing.
3 years ago(+1)
Personally, I'm glad DRGT doesn't have a full blown built-in physics engine, this is a detail that I'm interested in implementing a solution for instead of attempting to tailor a "one size fits all" unity-ish solution to work for my desired implementation. Once you start digging under the hood of DRGT you'll find it has many of the utilities (geometry/LERP functions, etc) you need to get there and you're usually just an abstraction or two away from a working implementation.
I don't think there is a "right answer" here, it all comes down to personal preference.