[schemescape]

In my experience, collision detection is the easy piece (partly due to the prevalence of resources like this one); collision resolution is where you start having to make compromises (and there aren’t always clean solutions).

[cd_trwa]

CD is an unsolved problem. CD is actually where you make the bigger compromises. Even we had analytical solutions to every collision scenario (we are nowhere near that) still we have "floating point issue". Everything that touches FP is corrupted and it gets much worse for CD. Issues with the collision response partly the after effects.

[megameter]

I think the main difference is that it's not hard to get approximate detection methods working with some high school geometry(and for games with simple physical behavior, you can usually stop at those) but finding any kind of approximate solution to collision response is not something students are ordinarily given any theoretical background in until undergraduate education, and then mostly indirectly through calculus, not crossing into the general CS classes where it would directly connect.

If you study physics specifically and are plugged into the theory driving iterative solvers, or perhaps you study math and spot the connection between constraint problems generally and the specific case of collision, you can find your way to answers about engineering satisfying non-realistic behaviors, but that's describing a subset of game programmers. Many still stumble through a sea of hacks and reliance on libraries because the conceptual knowledge hasn't been directed at them.

[schemescape]

Good points. I suspect when you need a high degree of accuracy with nontrivial shapes you’re probably right (my 2D games required neither of these :)