Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

I'm not sure how should I design the collision part in order to respond the all the game requests.

First that comes in mind is 1. Update the game objects positions 2. Check the collision 3. Update the positions based on collision data

Now the problem is what if an object needs to know when it did collide in order to perform some actions. Lets say a player picks a chests, so he must not be bounced by the chest and also all the player, chest and cut scene sequence need to be triggered.

So if I do everything in collision routine (without triggers) then all the game logic is biased toward one game and is not flexible, its need to be adapted/rewritten for each game.

If I use triggers and call every object collision function what if player needs to move backward and collisions needs to be rechecked, do I need to make a flag to recalculate and collisions for objects that has this flag set until collisions are done?

Or do I check for chest collision in player update method (before the global collision routine) and do all the calculations there... but what if I don't want the player to react to collision if chest is closed and react if its opened (not just a player-chest collision pair setting)?

What is the best way to implement this kind of system that will be flexible for future games and in the same time respond to all requests of game design (in this case the example I wrote above, player-chest)

share|improve this question

2 Answers 2

up vote 0 down vote accepted

If I use triggers and call every object collision function what if player needs to move backward and collisions needs to be rechecked, do I need to make a flag to recalculate and collisions for objects that has this flag set until collisions are done?

Don't do it that way, the reason for this is simple.

Your gamecode needs to know exactly which object can collide with which, this means that you can't use schemes that reduce the amout/count of collision tests, which means that your game will run too slow with enougth objects which can collide with each other ( time complexity).

Now the problem is what if an object needs to know when it did collide in order to perform some actions. Lets say a player picks a chests, so he must not be bounced by the chest and also all the player, chest and cut scene sequence need to be triggered.

You can write your collision callback function/delegate in that way that it returns true if the two objects did collide, if they did you calculate the collision response.

To illustrate this idea here is the calltrace for a object which didn't collide

(in collision response phase, in physics engine source)
(object A and B did collide)
CollisionSouldBeHandled = this.onCollision(A, B);

if( CollisionShouldBeHandled )
{
   this.calculateResponseForces(A, B);
}


// collision event call code can come here

So in the onCollision method you check if A is a chest and B is a player or the other way around and you return false if it is that case.

To handle the event you have two possibilities

  1. handle it immediatly
  2. put it into a queue and handle all at once after the collision detection/resolve phase
share|improve this answer

The way I do it is. First check for collision of one object at the position it would be at if you did move. If something is there then move until you hit that object and then stop. (or bounce but keep the distance in mind)

In order to get the triggers working make sure your objects like chest have a callable method which player can call when it hits something (like from a parent class) things that don't do anything should have this empty while things such as chests that do an event will perform it in this method that an object will call on it when it notices it has collided with another object.

here is psuedocode one direction just for simplicity:

// first figure out where the object would be when it moved
// 
int speed = 10
newx = x+speed;
newy = y;

// check the collision at that point
if(object = collision(newx,newy)){
    //move to the objects edge
    for(int i = 1; i < 10; i++){
        if(collision(x+speed,y)){
            x = newx + i-1;
            y = newy;
        }
    }

object.collidedwithyou(this);
}
share|improve this answer
    
Thanks for answer, so you purpose to do the collision checking inside the character object? One thing that comes in mind in this implementation is what if many enemies are surrounding the player, then each one will check the collision with other one and react accordingly wouldn't this create some additive effect, like all of the bounces at big speed, or just one if reaction is applied to the first only and he moves to non collidable area? –  Spider Jul 30 '13 at 15:51
    
if there are a bunch of enemies you should make it so that when one enemy collides with another it changes their direction/speed as well as your own (and then check for collision again in that new direction/speed. then when the other enemy starts checking it will have the bounce direction/speed already and won't be hitting you again. –  SteveKB Jul 30 '13 at 17:10
    
I see, thanks for help. But I'll think I'll pick Quonux answer, as its more optimal (less collision checks/calls) –  Spider Jul 30 '13 at 23:04

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.