Interface-Designe of a Game-Physic-Engine

[LonelyStar]

Hello dear Community,

I am having trouble on how to designe the Interface for a Physic-Engine for games.

The Idea so far:

- I have a rigidBody class, which is a general class for objects in the physics world.
- I have a Physic class handling the rigid bodies and stuff.

The engine should not only handle physics but also general collision detection. In a game one has different types of objects. In example:

-Players
-Opponents
- Bullets
-Walls/Obstacles
-Pickups (like Ammo, Health e.t.c.)

Now the physics object needs to know which objects can collide with which and needs a way of reporting such collisions. It also needs to know, if it should calculate collision response. In example:

- If a Player collides with a Health-Pack, the physics Engine needs to report this, so that the player gains Health and the Health-Pack is deletet.
- If a player collides with the wall, the physics Engine needs to calculate the collision response and apply it.
- Bullets can not collide with Pickups.
e.t.c.

The problem is now how to make a Interface which can provide this functionality. My Idea is to put bodies into "groups" and tell the Phyics object, which groups can collide with which and when we need to know about a collision.

Example:
Group 1=Players
Group 2=Walls
Group 4=Pickups

PhysicEngine.GroupsCollideWithResponse(Players,Wal ls);
PhysicObject.GroupsCollideWithoutResponse(Players, Pickup);

The biggest Problem is, how to give the feedback, if a collision occured.
One could add a virtual function:
RigidBody.OnCollision(RigidBody* ThOther);
But I think this interface would be not so good because there are always to bodies in a collision, so that the collision would be reported twice!

How would you designe this?
I am looking for Ideas on how to replace the group-system and what the best way of reporting a collision would be.

Thanks,
Nathan

[Dark Storm]

One idea I am implementing in my own RTS game is giving each body a 'state' or mode.

My game engine has the vector that stores all the bodies in the game and it iterates through them once, calling each body's 'mode' object and call the method resolveData(rigidBody[] list) passing it an array storing all bodies in the game. Each mode overrides resolveData(), so for example if you have a moving object, he would be in 'MoveMode' and its resolveData() would iterate through the array making sure that it doesn't collide with anything and if it does, store the body(plural if you want, my engine only stores a single colliding body, the first it encounters) it is colliding with. If a body was shooting something it would be in AttackMode and a call to resolveData wouldn't do anything.
This way you eliminate unnecessary iterations through the body list.

Basically the main features are the variable Data which stores whatever you want and the resolveData method/function.

On each iteration thru the body list, each body has 3 methods called, checkDeath() to see if the body is dead and if it is, remove it from the list, resolveData() to perform collision detection, target finding, whatever data you want the owner to know about other bodies in the game, and act() which causes the owner body to move, shoot, do whatever he's doing. If hes moving, act() will check the mode first to see if the resolveData() call found a collision which would be stored in the Data variable.

There is probably a better way, but this is mine for the moment.

[SmokingRope]

I have implemented this once through and used a system very similar to what you described. In each call to onCollision you only modify the state of the (this) object. The trick is that you need to store all the changes which are being made during collision response in a queue that get's applied after all objects have been updated.

An example:
Collisions are checked.
A car and a wall collide.
The car's onCollide method is called with the wall: car->onCollide(wall).
The car calculates and stores it's new collision force in it's update queue.
The wall's onCollide method is called with the car: wall->onCollide(car).
The wall doesn't do anything because it is an immobile object.
The car applies all changes which have been added to it's update queue.
End Collision Checks

[Dark Storm]

Yea that sounds similar to what I wrote. The main difference, I think, is that my resolveData(), which I think is analagous to your onCollision(), doesn't actually do anything, it simply stores data and it is actually different in each implementation of it in the different classes because it is overridden.

All the changes in the unit's state are done when I call act() on it.

So for example to use your car collision example.

car.getMode().resolveData(body list[]) is called
Collisions are checked with the provided list[].
A car and a wall collide.
the car's Mode stores the wall that the unit collides with and returns.
car.act() is called
the Mode object is checked to see if any collisions were detected.
If not, the car moves and does whatever else.
If so, the car would then resolve the collision inside act().

This would have to be modified a little bit so that the wall was made aware of the collision if you were to use it for a proper physics engine, but for limited RTS purposes, it works.