Platform Architecture Help

Started by
3 comments, last by DishSoap 10 years, 4 months ago

Hi there. (The title meant to say Platformer* not Platform)

I am currently building a platformer. I use sweep and prune to detect collision and for the screen culling. It works great, I just wanted some ideas for a good way of detecting the 'response' when two individual objects collide. Currently(which I want to change) I have a struct that looks something like this:


struct WorldObject
{
    Vector position;
    Rect intersection_rect;
    Drawable sprite;
    CustomResponse* response;
};

Where my data structure for sweep and prune holds a group of these CollidableObjects and the response is basically implemented in the object that the player is colliding with. So a moving platforms response would accept the Player as a parameter, and respond by changing the player's position by adding or subtracting its movement. It would then end this response when the player no longer collides with it.

I don't really like this strategy. It adds a lot of functionality, which I don't feel really relates, to one struct. I was wondering how you guys have done this in the past? How did you query for the 'types' of objects intersecting, how did you find the drawable based on your culling from sweep and prune, etc. Thanks!

Oh, by the way. Happy Thanksgiving!! smile.png

Advertisement

EDIT: I Apologize, after rereading your question I see that this isn't really relevant. I don't know how to delete a post so I'm just leaving this edit. If a mod wants to delete it that's cool. But maybe it'll be helpful to you or someone anyway

I'm not good at this stuff yet, but I'm dealing with something similar in my game so I figured I'd at least give you my two cents, for whatever it's worth, since you don't have any other answers yet.

I have a similar system for collision detection and my gameObject class has a collide(GameObject otherObject) method method in it. when a collision happens, this method is called on both colliding objects, passing the other object as the parameter for both of them of course, and then each individual object handles the reaction.

The GameObject class that all my objects derive from has a flag for 'dynamic', meaning an object that moves on it's own and reacts to gravity/collisions etc. players and enemies and things that follow the laws of physics are dynamic, while stationary objects and objects like moving platforms that move but only according to a predefined path are dynamic=false. So in the GameObject class I have a default colldie() implementation where if it is dynamic then it just moves the object until it's not colliding anymore and if it's not dynamic it does nothing. If I want different behavior I can always override the collide method for that class.

This way the collision reaction is coupled only to the class of the object that is colliding and colliding objects can handle their own collisions without having to know about anything else other than the object passed into the collide(GameObject) parameter. The one downside is if 2 dynamic objects collide, this would cause the first object who's collide method is called to move until the objects aren't touching and the other object doesn't do anything because by the time it collide()s the objects aren't touching anymore, and this may not be desirable behavior.

I'm considering a couple different ways of handling this:
Either have

if (otherObject.isDynamic && otherObject.isFirstObject) {

//determine how far I need to move to not be colliding with the other object, move half that distance

//Also set isFirstObject to true so that when the second objects collide() method is executed it skips this if block and reacts normally, moving the other half of the way until the objects are no longer touching

} else {

//react normally, just move until not touching anymore

}

Or

if (otherObject.isDynamic)

if (id < otherObject.id) //Only execute the following code if this objects id is lower than the other colliding objects, so it only gets

executed once

//Insert advanced code to handle the reactions of both objects in one place here, moving them as they should be based on their

mass and speed and other factors. Maybe reset their velocities based on bounciness to make them bounce or soemthing

I hope my explanations are relevant and that they make sense

Sorry if I got your hopes up when you saw you had a response and you were expecting someone who actually knew what they were talking about haha

No, thank you for the response :).

My hopes are to find a logical system for processing collision, drawing, and reactions. Just hearing how other people have built this system helps me greatly.

To address what you said, I don't really like coupling of the collision method to a gameObject, I would have to code every possible combination of collision in each gameObject. But perhaps that is the best way of doing things?

I have a simple skeleton of a physics system in my game, and this is one of the aspects i had to consider.

I have:
-Multiple types of collision objects (eg. circle), each type stored in a container with all such collided of the same type
-Game objects (eg. player), each having an ID to a collision object of game object type specific type (eg. all players are circles)
-Abstract colliders, basically colliders of unspecified type used by the broad phase, each has bounds, as well as an enumerated to specify what collision object type it represents AND the ID of that collision object in its respective container
-Handler for each pair of potentially colliding object types. Eg circle-rectangle handler. Implemented using polymorphism so that when the broad phase finds a potential collision, it gets the correct handler pointer (from 2d table of collidertypeB,collidertypeA) and calls a virtual like detectCollisions(abstractColliderA,abstractColliderB). Each handler has references to the containers required to access the colliders.
-A contact list. Handlers only detect contacts, with point of intersection, normal of intersection as well as penetration depth and surface materials, adding the contact to the list. The list is then processed to resolve the collisions. (apply forces and move objects)

For simplicity we want no connection between a game object and the colliders type used. Thus all colliders can represent any game object. Thus all colliders need a game object ID. You may place this ID in whatever stage. To customize collision response, also add custom collision handler pointer (implement using polymorphism class?) to the colliders. Then you can pass to this handler the two game object IDs which it can then process as it likes. It can modify the colliding bodies through the game objects.

o3o

I have a simple skeleton of a physics system in my game, and this is one of the aspects i had to consider.

I have:
-Multiple types of collision objects (eg. circle), each type stored in a container with all such collided of the same type
-Game objects (eg. player), each having an ID to a collision object of game object type specific type (eg. all players are circles)
-Abstract colliders, basically colliders of unspecified type used by the broad phase, each has bounds, as well as an enumerated to specify what collision object type it represents AND the ID of that collision object in its respective container
-Handler for each pair of potentially colliding object types. Eg circle-rectangle handler. Implemented using polymorphism so that when the broad phase finds a potential collision, it gets the correct handler pointer (from 2d table of collidertypeB,collidertypeA) and calls a virtual like detectCollisions(abstractColliderA,abstractColliderB). Each handler has references to the containers required to access the colliders.
-A contact list. Handlers only detect contacts, with point of intersection, normal of intersection as well as penetration depth and surface materials, adding the contact to the list. The list is then processed to resolve the collisions. (apply forces and move objects)

For simplicity we want no connection between a game object and the colliders type used. Thus all colliders can represent any game object. Thus all colliders need a game object ID. You may place this ID in whatever stage. To customize collision response, also add custom collision handler pointer (implement using polymorphism class?) to the colliders. Then you can pass to this handler the two game object IDs which it can then process as it likes. It can modify the colliding bodies through the game objects.

Reading this gave me a ton of good information on how to implement my collision responses.

I have since restructured and re did a lot of code to accommodate my own version of what you said. I very much like the result.

Thank you.

This topic is closed to new replies.

Advertisement