One way to do it is to have a collision manager of sorts. That would hold lists of everything collidable. You'd ask it if you're colliding with anything (something like collisionManager.colliding( entity ) where entity is the thing you want to check) and it'd notify you (and possibly the thing you're colliding with) in some way (like calling a collidedWith( Entity* e ) function or something).

If it also returned true if a collision happened and false if none, then you could use it to determine whether you can move somewhere or not. You could loop through everything trying to move, and call that function and if it returns true, roll back to the old position.

I have a question. Everybody talks about making managers for everything these days. What benefit does a collision manager provide over just a free-standing function? I'm not trying to say there is no benefit. I've just never thought about it, so I don't presently see any advantage.

Here are some advantages, as far as I can see:

1. It keeps the code cleaner and therefore easier to understand.

2. It allows for more efficient management of collidable objects. That is, if the objects are stored in a data structure that reflects the geometry of the game world, then each object wouldn't have to be compared with every other, only the ones within a certain distance (whatever that may be).

3. Per #2, it allows the game to run faster. :)

- Rob

Quote:Original post by RobAU78
Here are some advantages, as far as I can see:

1. It keeps the code cleaner and therefore easier to understand.

2. It allows for more efficient management of collidable objects. That is, if the objects are stored in a data structure that reflects the geometry of the game world, then each object wouldn't have to be compared with every other, only the ones within a certain distance (whatever that may be).

3. Per #2, it allows the game to run faster. :)

- Rob

You can do that without a manager though, so per Troll's question
whats the advantage - what can be done that wasn't possible before?

Hmm... nothing, I suppose, but there is still the issue of code conciseness. The idea is to keep things clean and as easy to understand as possible. Doing so will make it easier to change the code later.

- Rob

The major advantages that I see on this topic are those here:

1: It makes the code EASIER to read

2: The code will be Object Oriented

3:As of 2, Object Oriented Programming allows for more reusable code later, rather then if you just throw it all into a function and make it for this specific code source....


As I see, Its a ton better to make it reusable later, :-D

Quote:Original post by RobAU78
1. It keeps the code cleaner and therefore easier to understand.

I agree that clean code is, all else being equal, easier to understand, but how is the code cleaner when you have a manager? Just having the infrastructure around for a separate management class is going to add code, which all else being equal, will result in more code for the same functionality, which would tend to obscure things.

Quote:Original post by RobAU78
2. It allows for more efficient management of collidable objects. That is, if the objects are stored in a data structure that reflects the geometry of the game world, then each object wouldn't have to be compared with every other, only the ones within a certain distance (whatever that may be).

I don't see this at all. Doesn't a scene graph serve a similar function? Wouldn't tracking collisions be somewhat related to the world representation, (e.g. a quake level vs. an rts game)? Wouldn't the collision manager then end up defining a parallel data structure when it doesn't need to?

Aside from that, why would a free-standing collide function be unable to use some sort of spatial data structure? Let's say I kept all my world objects in an octree for view frustum checks. Why not just pass that to collide?

Quote:Original post by Aeneas
2: The code will be Object Oriented

3:As of 2, Object Oriented Programming allows for more reusable code later, rather then if you just throw it all into a function and make it for this specific code source....

Being object-oriented to be object-oriented has no intrinsic value. The fact that Java considers the sin function to be a part of some math object is very silly to me. Object-orientation doesn't mean that code is more or less reusable. Some of the most-reused code out there isn't object-oriented. The entire ANSI C runtime is not object-oriented, and it gets used a lot even in C++ programs. Believe it or not, but the STL is not object-oriented, at least so says its designer.