I see a question about bunch-of-circles-collisions come up often, and I seem to see always the same issues come up, but I haven't had the chance to test it myself... unfortunately, I don't have time to test it either nowadays.. :/

Maybe I should stop buy and playing video games...

Haha, yeah... it's frustrating. There are whole books and tutorials about implementing physics engines, but it's hard to boil that down to simple concise answers to share.

And of course, all the techniques have different trade-offs, so there's not really a simple "right" or "best" way to point to a lot of the time...

No, however, most implementations that folks ask about here have similar flaws: they test A with B and then B with A, they push objects in a really narrow 1:1 view, etc..

Fair point.

I thought I recall seeing one recently & now I can't seem to find it. As I recall, the issue was that w/ too many points, the simulation was too jiggly. I think the resolution loop was: test all point to point pairs & nudge them if they're too close. But the nudge code wasn't included.

That question is now deleted, so it explains why you don't see it :)

Yes, it was testing A with B then B with A in the same set of nested loops.

The fact that the order is always the same while checking may cause oddities too.

We use ODE for a physics engine and I was kind of shocked to see that it used random into its collision resolution code. It shuffles the order of the objects before the resolution. It all made sense when I read the comment stating something like "may help get things unstuck and converge".

My first thought was that it might be easier to find a stable result if their was precedence (i.e. higher IDs nudge lower IDs)

Then I thought, well, yes, but that's not really representative of how physics works.

Then later I followed it with, true, but the OP version isn't real world either - it seemed to assume infinite energy (hard to know for sure w/out the nudge code).

I agree that they all have this sort of "same but different" flavor to them. You observation about narrow fixed perspective is the closest I've seen to a meta pattern to them.

That & time steps - it seems pretty rare to find a question that is looking at trajectory interceptions.

What do you mean by "trajectory interceptions"?

Is that a common feature in physics engines?

Ah, do you mean something like continuous collision detection, where you're doing a sweep test to find the mid-frame time of impact when two objects first touched, rather than moving everything fully then checking for overlaps at the end of the move only?

I suppose that is useful in most platformers where there is "one" physics-based object, controlled by the player, and other static objects.

I wonder how it would play out in a "particle soup".

I have finally managed to fix my Dubins path test implemenation...

This one was okay, but this algorithm assumes that the vehicle can "steer instantly". Which is fine for a truck or a car, but now I need it for an articulated vehicle, which looks odd when you just steer it in place...

Even with their comments I'm not sure I understand what they mean. I suppose not being a Discord user contributes to this...

@Vaillancourt as a discord user, i have no clue what they are talking about

@TheMattbat999 Their (closed) post on so has a bit more details.

I don't think they could achieve what they want to achieve.

@Vaillancourt I think they're trying to mimic this PolyMars video (youtube.com/watch?v=0fWdU8JCT6Y) but not really understanding the concepts. i.e. that you need to build the game with Discord integration in mind from the start and you can't just retrofit an existing game.

Yeah, that's what I understand. I don't think Discord would let a bot just send a stream of JavaScript to be executed on the client.

It definitely would not, I've built a Discord bot before so I think I know where OP is confused. You have to build the bot commands into the structure of the game, such that inputs are taken as bot calls. You can't just "send a game through a bot", it's more that the bot itself has to be the game.

The JavaScript runs purely on the server/bot end, not on the client's end.

Yes, that's what I gather from the video. The TurkeyDev guy seems to have a bunch of games made for Discord, I'd have to look through the videos to see how far it can be taken, but it definitely appears to solely run on the server, not on the client.

If bots could run code on the client that interacts with it then Discord would be a very horrifying place

I agree.

@DMGregory Yes - there's probably a better / more official term for it.

@Vaillancourt It's as by DMG - rather than move & check for collisions between bodies, you calculate the paths the bodies would take, look for the earliest collision along those paths & deal with it. As far as I know, it's not a common feature.