🔒 Locked

patterns and design

Started by StinkyMarker Jun 22, 2007 at 10:31 AM 4 replies 1.1k views

Original Post

Jun 22, 2007 at 10:31 AM

I've been trying (sort of unsuccessfully) to flatten out my object tree and convert to using something similar to a componenet based design. I've read all I could find here, along with the postmortem on dungeon siege, and the slide show presentation about component models used in dungeon siege. Without seeing any actual implementation, I'm having a difficult time understanding several parts of this design. the first problem i have is more or less the proper way to break down object specific code into componenets and still have them work together without tightly coupling my component objects - take for example, collision reaction type code. Generally, i have seen: 1) each object handling its own collision such as object1.collided(object2), which is then followed by a switch statement for the type of object, or 2) using a double dispatch type thing to call the correct function Object::collideWith(object &obj){ obj.collideWith(this); } i have no clue how i would break this behavior down with components..im assuming i would have a collision routing function, that subscribes to a global ON_COLLISION event, which then sends the event and associated info on down to the objects. The object then passes that message and associated data on to the component registered to that event...but at that point i'm lost. I can see how this would work with something simple such as a "ExplodeOnCollision" component, but a little trouble conceptualizing how i would handle something such as a player collision component, that has to switch depending on the type of collision (since double dispatching no longer would work here), and would require specific information from the object, from a component that may or may not exist. it seems that this style of making objects just moves from having individual classes per object (which contains specific collision handling, actions, behaviors), to a single base object with separate components for every object (a playerCollision component, playerBehavior compoenent, enemySoldierBehavior componenet).. i think i may be misunderstanding exactly how this is used...any help would be appreciated, even if its to say i write way to much and say very little...

coderx75

116

coderx75

Jun 24, 2007 at 4:24 PM

Collision response needs to be handled right away. Using a messaging system seems very problematic and slow. Why not simply have an Environment object that manages your game objects? I usually handle the movement and collision of an object in these steps:

- Apply force(s) to the object, adjusting its velocity. This includes forces that may have been applied to the object previously (possibly due to collision response).
- Calculate the movement and store the new position temporarily.
- Test the old and new positions against surrounding objects for collision and return the point of collision. If no collision was detected, the position previously calculated is returned unchanged.
- Commit the new position as returned by collision detection.
- If collision was detected, apply opposing forces to both the moving object and the object it collided with. The effects of these forces will be seen in the next frame.

So, the steps put simply:

- Apply force(s)
- Calculate move
- Collision detection
- Commit move
- Collision response

Applying this in an OOP language should be pretty straightforward.

First, you have your objects that act as the physical representation of the objects in your environment. You could simply give them an ApplyForce(vector) method that modifies its trajectory. These objects could be contained within another object which represents the physical environment. This object manages the physical objects and updates them using the above steps.

You could break it down further by creating a seperate collision system which simply tests an object's new/old positions against another object. This would be directly used by the environment object.

Aressera

1,317

Aressera

Jun 24, 2007 at 11:49 PM

Quote:
Original post by coderx75
Collision response needs to be handled right away. Using a messaging system seems very problematic and slow. Why not simply have an Environment object that manages your game objects? I usually handle the movement and collision of an object in these steps:

- Apply force(s) to the object, adjusting its velocity. This includes forces that may have been applied to the object previously (possibly due to collision response).
- Calculate the movement and store the new position temporarily.
- Test the old and new positions against surrounding objects for collision and return the point of collision. If no collision was detected, the position previously calculated is returned unchanged.
- Commit the new position as returned by collision detection.
- If collision was detected, apply opposing forces to both the moving object and the object it collided with. The effects of these forces will be seen in the next frame.

So, the steps put simply:

- Apply force(s)
- Calculate move
- Collision detection
- Commit move
- Collision response

Applying this in an OOP language should be pretty straightforward.

First, you have your objects that act as the physical representation of the objects in your environment. You could simply give them an ApplyForce(vector) method that modifies its trajectory. These objects could be contained within another object which represents the physical environment. This object manages the physical objects and updates them using the above steps.

You could break it down further by creating a seperate collision system which simply tests an object's new/old positions against another object. This would be directly used by the environment object.

This is ok, but it has its drawbacks, as well as its inaccuracies (collision response should use impulses, not forces).
Here is how I do it:

I have a PhysicsWord object, that holds several different modules for each of the different functions of the engine (gravity application, force integration, collision testing, collision resolution, update positions (integrate velocities)).
One updates the world by calling the updateSimulation(double dt) function, which activates each of those modules in that order.

Each of these modules is of an interface type (pure virtual C++ class), and then you can create your own implementation of that module that can be interchanged easily (for instance, using different broadphase collision detection routines to see which is more suited to the situation). The most complicated module, CollisionWorld, has a CollisionTester. It uses whatever broadphase collision detection routine it implements, and then passes possible colliding pairs of objects to the CollisionTester. The CollisionTester returns any colliding points of these objects and then the CollisionWorld notifies its collision callback listeners that there was a collision, an passes the collision data to each of them. A callback listener is basically an interface which has a virtual function notify( CollisionCallback* ). Therefore any object can implement this virtual function and add itself as a CallbackListener to the CollisionWorld. This helps keep collision detection separate from the rest of the engine.

For instance, the collision resolver could be a CallbackListener and then whenever a collision occurs, it resolves the collision (I don't recommend this). Ideally, you would store all of the collisions that have happened and then resolve all collisions in a single step. This is better for when you have resting contact of multiple objects.

That's all for now. That's a basic rundown of my 3D physics engine's structure. It is very object oriented, well designed, and modular.

coderx75

116

coderx75

Jun 25, 2007 at 11:57 PM

Would you happen to have (or be willing to share) a UML diagram? It sounds interesting but I'm not sure I follow completely.

I'm trying to implement a physics engine that can handle collision tests on a large number of moving objects (tens of thousands). The only drawback I see here is if there happen to be many collisions in a single frame. In something this hectic, I figure if you can respond to the collision at the time of detection, then do it. I'm not looking for extreme precision, just believable physics.

Aressera

1,317

Aressera

Jun 26, 2007 at 12:12 AM

I don't have one right out of hand, but I might cook one up later.

I find it hard to believe that you'll achieve that many objects running at a real-time framerate with collision detection. at best you'll get about O(nlogn) for collision detection with good broadphase algorithms. Hell, even havok has trouble with a few thousand.

coderx75

116

coderx75

Jun 26, 2007 at 9:18 PM

On a version I wrote a few years ago, I had about 12,000 objects in motion w/ 40 fps on a P4 1.4GHz. It had a very large environment divided up into a large grid of "spaces" so that there were usually only a few objects to a space. So, each object performed only 0 to 30 or so tests. It initially used a box-to-box collsion test (taking into account frame jumping) based on the size of the objects. If the boxes overlapped, it would do more rigorous testing against the geometry of the objects.

It wasn't physically realistic and the implementation was awful but it gave me a good idea of what would be possible. I'm trying to rewrite it at the moment with better OOD and correct physical calculations. With more realism and better collision accuracy I don't expect to achieve the same performance but it shouldn't be too far off.

EDIT: Btw, I should mention this is only 2D since it would probably make a big difference. ;-)

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.