sebcrozet
commented
7 months ago Thank you for this PR! The main issue with this event is that it won’t be emitted for objects that are colliding but not awake (i.e. they are colliding and at rest).
In order to know the current state of a collision, independently from the Started/Stopped events, checking the contact graph sounds more robust and would work in all cases. See NarrowPhase::contact_pair and NarrowPhase::intersection_pair.
Thank you for sharing your game. That looks like a cool casual game!
I’m closing this PR for now, but please let us know if that proposed alternative doesn’t work for you.
This adds support for receiving collision events even after Started was called.
Why not just cache that
CollisionEvent::Startedwas called and invoke logic every loop update untilCollisionEvent::Stoppedis called?This works great for linear games. However, it makes games that make use of mechanics such as a network rollback algorithm difficult. It requires us to look up the previous state in the rollback and see if a collision started or not, adding additional complexity. It is much easier to keep each update loop as stateless as possible (ideally completely stateless). Which means we can update the gameplay loop without having to concern ourselves with the previous or next state.
Feel free to accept or reject our PRs. This is simply Lange Studio's way of giving back to beautiful open source devs such as yourselves as we migrate Blocky Ball from Unity to Godot! We keep our own forks in sync and contribute back PRs so the original authors have the option to take our changes if they want them. This is proving to be a great physics engine for us and I look forward to testing it at scale on our servers!
And if you are interested in the game that is soon to be leveraging this engine, here is a shameless link drop of our Unity + Unity Physics soon to be Godot + Rapier game Blocky Ball! :)
https://store.steampowered.com/app/1343040/Blocky_Ball/