What is the simplest collision filtering solution?

I will soon be returning from a long trip, and I'm excited to resume game development. I'd like to polish an old pinball game project.

The next major feature I wish to add is the presence of ramps like you would seen on a traditional pinball machine.

While balls can pass under the ramp just fine, if they enter the ramp they only collide with the ramp until they exit, not colliding with the obstacles below the ramp.

From my understanding this would require collision filtering, and I'm told box 2D supports this feature.

Basically you can create and modify groups of sprites and objects that collide with each other or not.

Unfortunately, from what I can see C3 does not yet pass this support to the user, likely due to it being a bit more complex than the average user can take, and the physics behavior is already pushing the boundaries of novice user friendly editing.

Is there a way I can get collision filtering into my game, perhaps through hand coded JS blocks that expose the groups? I'm all for add-ons, but all the topics I've found are years old and from my experience some add ons make the export to mobile prosses a bit more janky. I don't know JS, but I can modify example code. I want to learn.

What solutions might I look into?

I went through this same headache for a pinball game. Eventually I settled on toggling the ball’s physics on/off for rails. Movement on the rails was handled with timelines - I found that having precise control over beziers was actually pretty nice. Timeline speed is based on the ball’s entry velocity.

GeoffB Thanks! Good idea. I considered that too. It's nice to know that it works.

If your project is one that you are comfortable sharing or sharing parts of, I'd love to see how you did it.

Either way, I think I'd like to add more 'second floor' features over time, so it would still be nice to have collision filtering. Does anyone else have any other ideas?

I know R0J0hound worked a lot with alternate physics engines. Do you know a way to expose collision filtering into the physics behavior, or what would you recommend?

I don’t have any real recommendations. Modifying the physics behavior via scripting to be able to access box2d’s filtering will require a fair amount of digging and probably be complex to do if at all possible.

Skipping the behavior and just using a js physics library directly is another option but it’s a lot of busywork to set things up. Basically it requires making a physics version of objects and synchronizing them every tick. Just a lot of busywork mostly.

Another option is making event based physics which would give you the most control but would take more knowledge, although you can find lots of not specific to construct tutorials of how to make a physics engine online.

Simplest solution would be to just utilize the physics behaviors disable collision with other objects feature. Even if that’s a bit tedious. A more complex option would be to have the ramp be just a visual, but you’d have it duplicated off screen somewhere with collisions enabled. Then you’d have a physics version of the ball and a visual version. When hitting the ramp the physics version would be teleported to the off screen ramp while the visual version stays on screen. Or something like that.

Personally I think that if you were invested in making a pinball game(s), importing and using a physics library would be the cleanest way. It would be more work up front but it should mostly be a one time thing.

Teleporting the physics simulation ball to a separate location is a nifty idea! That seems like it would work well, as long as the physics simulation doesn't get thrown off with a sudden change in position from manually moving the object.

Also add suggestion to implement/update the physics object and just wait. Box2d collision filtering is a thing that exists after all, we just don't have access to it through the official plugin.

I'm not very familiar with the addon scene but I'm a little surprised there isn't a third party addon that uses an alternate physics library already. I guess physics is probably one of the more complicated things to implement after all.

Great ideas, oosyrag and R0J0hound. I think I have some ideas to try now. There is a feature request for collision filtering already out there, I can't find the link right now but I saw it during my search.

It had about 10 backers if I remember.

Thanks for everything! If anyone else has any other ideas throw them in here. But those are satisfying enough answers for me. It's nice to know for sure that exposing the filter through JS isn't super feasible. That was my big question.

I've been thinking, and I'm wondering if I can make this process easier with families.

In theory (I don't have an account to try this out right now. I'll renew one when I get back from this trip in August and have time to work on my project.) I should be able to make a family of sprites used for the top level of the game (ramps and stuff) and a family for the main bottom level, and then use the physics disable collision function to separate the two groups into different collision sets.

On start of layout }

Family-top disabled physics with family-bottom.

Then I would simply need to switch which set the individual balls can interact with using the same function.

I think that event applys the physics enabled disabled feature across all objects of that type, so I would need to make 3 different ball sprite types so they could be swapped independently when all 3 are on screen.

If I wanted any objects used on the main floor to also be used on the top floor, I would need to make a duplicate item for them as well, if thats the case. But I can manage that.

From my understanding, there is not a way to add or remove objects from families during game via events sheets, right?

oosyrag! I just was reading this again today, and your comment,

Teleporting the physics simulation ball to a separate location is a nifty idea! That seems like it would work well, as long as the physics simulation doesn't get thrown off with a sudden change in position from manually moving the object.

Struck me, because that is a problem I have already solved, in another situation. I figured others may want the information too.

Basically, like the manual warns you about, if you set the position manually, you could find the physics behavior doing some strange magic.

In my case, I found that moving the ball made the physics engines want to give it extra momentum, almost as if the movement was an impulse.

In my pinball game, I actually manually set the position of the ball a lot. And it took a zillion different tests to find a solution to that problem. But it's painfuly simple.

If you just disable the physics behavior, move the object, and re-enable the behavior in sequence, the physics continue just fine as if nothing happened. Just strait up turn it off and back on lol. In the same event block, or at least by the end of the tick.

I'm sure it probably adds a bit to the cpu, but I never saw measurable performance problems. And I do it several times every tick at some points.

If anyone else needs to know, there you go. And if there are better solutions, feel free to share.

But boy, that one stumped me for a long time. But it allowed me to add a few tweaks to how physics works in my game, as you can add events to customize physics behavior while it's disabled, and as long as you enable it before the behavior needs to run again, you're good.