Finding and reacting to colliding objects

[testtext123]

I would like to find out a good way to manage game objects. I'm thinking that the simplest way would be to keep each one as a table that contains an update function, draw function, and internal state. I'm not sure how to solve these issues, though:

Objects should be able to have a shape associated with them. If two objects with shapes intersect, I need a way to decide how they react. My idea was to let objects ask the world in their update function for any intersecting objects that they're interested in, but that has two problems. First, it requires some kind of class system to be able to ask for a specific "type" of object. Second, a specific update order is needed for it to work correctly (testing for collisions only after both objects move), and even that won't help if two objects of the same type need to react to collisions. The two objects might even handle the collision twice in the same frame, which isn't what I want.

Objects should also be able to have solid shapes, which are separate from normal collision shapes. If a ray intersection test is done against the world, it should get the distance to the nearest solid object in that direction. This also requires a way to update solid objects before objects that stand on them.

Do you know of any good suggestions, code samples, or links on how to solve this?

(Suggestions on how to handle update/drawing order and off-screen objects are also welcome, but I already have a general idea of how to do those.)

[artofwork]

Collision is actually something easy to code so is moving objects across the screen its a just a simple matter of true and false.

You will see a lot of this in many examples of people's code on the forums, most people use a grid to setup their tiles and then assign specific tiles to be the collision object, where each tile has a specific number associated with it.

When the object moves across the screen each tile ( or number ) is tested against the object, if the object comes into contact with a collision object then a false value is return and the object cannot pass, but if the value comes back true then the object can go about its business.

In any project no matter what your goal, its best to start out small and build from there

[micha]

Hi and welcome to the forum,

Do you know of any good suggestions, code samples, or links on how to solve this?

All the ideas you have sound pretty good. The kind of implementation that is best for you depends on what kind of game you want to make. If the game is tile based and all objects are rectangular, then you could have a look at bump. If you want to handle arbitrary polygons then you should have a look at the love.physics module.

If you still want to implement the collision detection and resolution yourself, then please describe a bit more in detail, what you want to achieve.

And also I suggest that you just start coding. Do not try to overthink the problem, before you even write one line of code.

[testtext123]

If you still want to implement the collision detection and resolution yourself, then please describe a bit more in detail, what you want to achieve.

Objects move freely, and can have any shape attached to them. My idea was that each type of object would be in its own file which would define its init, update, and draw functions. Level layouts could then contain entries with the script filename, initial position, and other parameters.

The biggest thing that I'm having trouble understanding is that when a collision between two objects is found, how should it know how to react? For example, should it call the function that makes two walking enemies turn away from each other, the function that applies a powerup to a player, some other function, or nothing at all?

And since the interaction functions are associated with two kinds of objects, which object's script should they be in?

Do not try to overthink the problem, before you even write one line of code.

I guess that's my main problem here. I got myself so confused with this particular problem that I'm not sure how to start writing it...

[micha]

Objects move freely, and can have any shape attached to them.

For me, that sounds like you should definitely have a look at the love.physics module. I personally would not want to code collision detection for arbitrary shapes.

My idea was that each type of object would be in its own file which would define its init, update, and draw functions. Level layouts could then contain entries with the script filename, initial position, and other parameters.

Yes, you should absolutely separate the levels from the objects description.
I would approach it object oriented: First create a object-base-class, which contains the init, update and draw function. The draw would contain functionality to draw the shape that is attached to the object (or draw an image attached to the object). The update takes care of movement. Then derive all of the specific objects from this base class. The general collision detection should be object independent, so you can put it into the base class. The collision resolution, however is object specific and belongs to the objects.

But, once again, I personally would not want to code collision detection for objects with arbitrary shape. I would use the physics module for that. On the other hand, if all of your objects are rectangular, you can do it. That is not as difficult.

For the game I am currently making (see my signature), I found that there are relatively few relevant object-object collisions. The important collisions are object-level collisions. And since this is the same for all objects, I put the object-level collision detection into the base class.

[testtext123]

First create a object-base-class, which contains the init, update and draw function. The draw would contain functionality to draw the shape that is attached to the object (or draw an image attached to the object). The update takes care of movement. Then derive all of the specific objects from this base class. The general collision detection should be object independent, so you can put it into the base class. The collision resolution, however is object specific and belongs to the objects.

I'll probably just go with that if I don't get any better answer. I just can't help but think that there should be a better way that doesn't involve multiple inheritance (for objects that have more than one basic "property") and lots of "is a" tests, since those two things are almost always considered bad practice.