Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added support for collision events regardless if started was called: CollisionEvent::Active #550

Closed
wants to merge 1 commit into from

Conversation

TCROC
Copy link

@TCROC TCROC commented Nov 13, 2023

This adds support for receiving collision events even after Started was called.

Why not just cache that CollisionEvent::Started was called and invoke logic every loop update until CollisionEvent::Stopped is 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/

@sebcrozet
Copy link
Member

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.

@sebcrozet sebcrozet closed this Dec 9, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants