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
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.