Some of these solutions place significant constraints on gameplay (e.g. bullet speeds vs object thickness). That's ok for a small game experiment that you have clearly defined in advance and are not going to develop much further, but most games are not developed like that. Usually you don't have a clear idea of all aspects of your game in advance, and you want more general solutions.
For example, instead of grid-based preliminary collision detection you could use distance-based one, i.e. if object coordinates are farther away than obj1.saferadius + obj2.saferadius then they don't collide.
If all you want is distance between points
(x1-x2)^2+(y1-y2)^2+(z1-z2)^2 = dist^2 works.
However, in games you frequently want to check the intersection of lines, or spheres with plains, cubes etc. And for those equations you often have to deal with the inverse square root function.
PS: Anyway, my point was more abut the process. First you try A, which culls 90% of your objects, then you try B which culls 95% of the objects then you do the full and actuate solution if you have time. http://en.wikipedia.org/wiki/Ragdoll_physics takes a lot of CPU time, and now days games need to be even more realistic.
No, you have to know your design before you can judge collision's needs properly, and you have to have some expectation that you'll get it wrong the first time and require iteration, because collision _is_ gameplay when we speak of games using a lot of spatial elements. Otherwise you are implicitly making the engine determine the design - which is acceptable in some circumstances, but increasingly likely to cause problems as you try to specialize the design. So it's OK to start with simple assumptions and wait for them to break. You aren't (yet) working with a live system where data is lost by changing collision. Let me give some examples.
Pistol Slut, for example, doesn't introduce any special handling for environmental collisions(platforms, ledges, etc.) because it doesn't focus on that kind of platforming gameplay. In a distance game like Toss the Turtle or Hedgehog Launch, resolving fast-moving collisions by constructing swept polygons becomes a very good idea. In an game like an RTS where you have lots of unit movement, collision may take place with points on the tile-map, building on the pathfinding algorithms, rather than by handling a separate set of collision structures. In a game like Prince of Persia: Sands of Time, you have to develop some kind of history of object state, including collision, so that the game works properly when time is reversed. In a game spanning very large distances you have to account for numeric precision(i.e. you can't just throw in a floating-point type and be done). In a networked game you have to include some interpolation, prediction, and compensation for latency so as to improve the feel of hit registration. And so on...
In all cases, a substantial part of gameplay rests upon technical assumptions. Trying to combine every collision feature you can conceive of into one universal system will increase your effort into the man-years range very quickly, so it's not done that way.
Comments
Some of these solutions place significant constraints on gameplay (e.g. bullet speeds vs object thickness). That's ok for a small game experiment that you have clearly defined in advance and are not going to develop much further, but most games are not developed like that. Usually you don't have a clear idea of all aspects of your game in advance, and you want more general solutions.
For example, instead of grid-based preliminary collision detection you could use distance-based one, i.e. if object coordinates are farther away than obj1.saferadius + obj2.saferadius then they don't collide.
The problem with that solution is it's slow and not that accurate.
In an actual game you probably want something like:
There's no need to take square roots. sqrt(x) is monotone increasing, so comparing squared-distances is equivalent to comparing distances.
If all you want is distance between points (x1-x2)^2+(y1-y2)^2+(z1-z2)^2 = dist^2 works.
However, in games you frequently want to check the intersection of lines, or spheres with plains, cubes etc. And for those equations you often have to deal with the inverse square root function.
PS: Anyway, my point was more abut the process. First you try A, which culls 90% of your objects, then you try B which culls 95% of the objects then you do the full and actuate solution if you have time. http://en.wikipedia.org/wiki/Ragdoll_physics takes a lot of CPU time, and now days games need to be even more realistic.
No, you have to know your design before you can judge collision's needs properly, and you have to have some expectation that you'll get it wrong the first time and require iteration, because collision _is_ gameplay when we speak of games using a lot of spatial elements. Otherwise you are implicitly making the engine determine the design - which is acceptable in some circumstances, but increasingly likely to cause problems as you try to specialize the design. So it's OK to start with simple assumptions and wait for them to break. You aren't (yet) working with a live system where data is lost by changing collision. Let me give some examples.
Pistol Slut, for example, doesn't introduce any special handling for environmental collisions(platforms, ledges, etc.) because it doesn't focus on that kind of platforming gameplay. In a distance game like Toss the Turtle or Hedgehog Launch, resolving fast-moving collisions by constructing swept polygons becomes a very good idea. In an game like an RTS where you have lots of unit movement, collision may take place with points on the tile-map, building on the pathfinding algorithms, rather than by handling a separate set of collision structures. In a game like Prince of Persia: Sands of Time, you have to develop some kind of history of object state, including collision, so that the game works properly when time is reversed. In a game spanning very large distances you have to account for numeric precision(i.e. you can't just throw in a floating-point type and be done). In a networked game you have to include some interpolation, prediction, and compensation for latency so as to improve the feel of hit registration. And so on...
In all cases, a substantial part of gameplay rests upon technical assumptions. Trying to combine every collision feature you can conceive of into one universal system will increase your effort into the man-years range very quickly, so it's not done that way.
Some sort of axis-aligned bounding box collision checking is the usual approach for a first preliminary pass.