To be fair, Notch did just spend a few years of his life thinking entirely in terms of axis-aligned boxes. ;-)

>> (I'm not as quick as Notch!)

You probably haven't been writing games as long, or written as many, or entered as many game contests/competitions as he has.

It'd probably take him a while to write a database or word processor since he likely doesn't have the domain knowledge and experience.

My understanding is that usually you want both because AABB is good for broad-phase because it's so quick then true polygon collision can be done in a narrow phase.

Absolutely.

Interesting. I've recently set aside a ThreeJS project. I'm not a math wiz but even with Three, you still need some idea about matricies, vectors and even quaternions. The way you're "supposed" to do collision detection with Three is with raycasting, so more fun with vectors and matricies. I thought I had scaled down enough other things for prototyping but perhaps there was more room than what I thought.

You might want to take a look at our product, PlayCanvas. We've tried to do all the maths for you, so you don't have to. :-)

Well, this can actually have a pretty significant effect on the feel of the game so depending on what kind of game you were prototyping, it might be worth it (though, your better off hardcoding a few cases of SAT than trying to get it working completely generally in a prototype).

How would one hard code SAT cases? Just curious I've got the general code working now.