BEPUphysics VS Nez

The best pure-C# physics library (hands-down) is bepuphysics2, which unfortunately is mainly a 3D physics library, but could be used for 2D if you wanted to get your hands dirty.

Bepu Physics is pretty good and is written in really optimized C#, the author's blog post are really interesting to read.

The usual approach is some form of sweep to get a time of impact. Once you've got a time of impact, you can either generate contacts, or avoid integrating the involved bodies beyond the time of impact, or do something fancier like adaptively stepping the simulation to ensure no lost time.

If the details don't matter much, it's common to use a simple ray cast from the center at t0 to the center at t1. Works reasonably well for fast moving objects that are at least kinda-sorta rotationally invariant. For two dynamic bodies flying at each other, you can test this "movement ray" of body A against the geometry of body B, and the movement ray of body B against the geometry of body A.

One step up would be to use sphere sweeps. Sphere sweeps tend to be pretty fast; they're often only slightly more complicated than a ray test. Pick a sphere radius such that it mostly fills up the shape and then do the same thing as in the previous ray case.

If you need more detail, you can use a linear sweep. A linear sweep ignores angular velocity but uses the full shape for testing. Notably, you can use a variant of GJK (or MPR, for that matter) for this: http://dtecta.com/papers/jgt04raycast.pdf

If you want to include angular motion, things get trickier. One pretty brute forceish approach is to use conservative advancement based on distance queries. Based on the velocity and shape properties, you can estimate the maximum approaching velocity between two bodies, query the distance between the bodies (using algorithms like GJK or whatever else), and then step forward in time by distance / maximumApproachingVelocity. With appropriately conservative velocity estimates, this guarantees the body will never miss a collision, but it can also cause very high iteration counts in corner cases.

You can move a lot faster if you allow the search to look forward a bit beyond potential impact times, turning it into more of a root finding operation. Something like this: https://box2d.org/files/ErinCatto_ContinuousCollision_GDC201...

I use a combination of speculative contacts and then linear+angular sweeps where needed to avoid ghost collisions. Speculative contacts can handle many forms of high velocity use cases without sweeps- contact generation just has to be able to output reasonable negative depth (separated) contacts. The solver handles the rest. The sweeps use a sorta-kinda rootfinder like the Erin Catto presentation above, backed up by vectorized sampling of distance. A bit more here, though it's mainly written for users of the library: https://github.com/bepu/bepuphysics2/blob/master/Documentati...

I use https://github.com/bepu/bepuphysics2. I haven't worked with 3d physics engines before so I can't really comment on it's quality but it is definitely an impressive project! The developer is very active and helpful and some of the demo scenes are pretty large and complex.

I'm developing an RPG in C# using MonoGame and the Nez game engine. Looking for hobbyists who would like something to do in their free-time and/or one programmer and one pixel-artist. Below is a link to a Google Drive folder w/ information regarding the game's design. Any comments, suggestions or otherwise are also welcome!

Monogame has a good number of libraries, ranging from utility and QOL stuff all the way up to something like Nez, a huge library completely reworks how Monogame works.

I have an entity-based component system based on Nez that implements most of the lower level functionality of my game, such as animation, rendering, physics, and collision initiated interactions. It was originally supposed to be an ECS but now I consider it more of an entity-based component system since the components are more about adding functionality to entities, rather than data and there (currently) are no separate systems. I've implemented a custom messaging system, of which I am quite proud, so that when one component needs to send a message to another component it doesn't have to perform a lookup using reflection nor does it need to always store a reference to that component.

They still have an Entity-Component system, but no longer an Entity-Component-System system. The part of the FAQ I’m referring to is here: Entity Systems

If your background is in C#, and you think Unity is overkill or you don't want to be taken out of a pure code ecosystem (unity is like a glorified level editor), then I would highly recommend MonoGame using the Nez framework https://github.com/prime31/Nez . Its all C#, and it gives you everything you need to start making a game and nothing else - just the kitchen sink. It gives you a game loop, media capabilities, an actor system, a UI system, collisions, animation tweening, and a lot more. The code to get started is literally simpler than a new WPF app. Check out the sample library. https://github.com/prime31/Nez-Samples The code to create a 2d tileset game with collisions, a follow camera, and a movable character who can shoot fireballs is only 300 lines long.

Here's an example of a more fleshed out game engine built for monogame: https://github.com/prime31/Nez

If you're cool with just writing code with no GUI environment, I'm a big fan of Monogame, especially when paired with the Nez library extension. Using Monogame by itself is fine and let's you do basically everything from scratch how you want it, but Nez gives you a strong foundation of basics handled for you without completely getting in your way, including an entity-component style workflow that you may be used to from Unity.