So I'm supremely irritated. I've probably been trying to figure this out for about two hours (off and on) and it's just not clicking. I wrote my collision detection, and it works. However, I wanted to make a collision detection class and put it in its own CS file. So I did. Now, if I go willy-nilly and start making all of my variables static, it works. But this is not good. I can't have static variables for my tank class's position et al because I need different positions for different tanks! So to correct the problem, I first tried having my collision class inherit from the main game class, which contains an instance of tank, and using that instance. Nope. Didn't work. So I tried creating an instance of Game1 and going that route. Didn't work. I even tried inheriting from the Tank class and got the error "No overload method for Tank. Takes 0 arguments." The only way I can seem to make collision detection work is if it's either in the Tank class or the Game1 class. :( Any ideas? :(

I'm not sure I understand your problem. Are you not sure how the collision class can access an instance of Tank that's in some other class? If that's the case, you can just pass the tank to the collision class as a function parameter.

If that's not it, you'll need to give a better explanation of the problem and maybe post some source code.

Thanks, Gage64! It works now. :)

/bow

Don't pass your tank as an argument - pass it's collision box instead. Otherwise your collision code is interwoven with your tank code, which means that when you want to use collision boxes for bullets, you'd have to add another function that checks against a bullet. And for any other object type, you'd have to modify the collision box code once again...

In other words: a tank has a collision box. A bullet has a collision box. These can be simple member variabeles. When you check if two tanks collide, you check if their collision boxes collide. Doing it that way means you can leave your collision code untouched, even when you introduce new object types. And that means there's less chance to mess up already working code, and less hassle when creating new types.

Captain P-

Thanks for the pointer. That's how my Pong game is set up. I haven't started my AABBs yet. The collision I'm doing is simply to check if a tank touches the end of the window...which doesn't need a bounding box. Or do you think I should use a bounding box to check collisions with the edge of the screen?

Quote:
Original post by Captain P
Don't pass your tank as an argument - pass it's collision box instead. Otherwise your collision code is interwoven with your tank code, which means that when you want to use collision boxes for bullets, you'd have to add another function that checks against a bullet. And for any other object type, you'd have to modify the collision box code once again...

In other words: a tank has a collision box. A bullet has a collision box. These can be simple member variabeles. When you check if two tanks collide, you check if their collision boxes collide. Doing it that way means you can leave your collision code untouched, even when you introduce new object types. And that means there's less chance to mess up already working code, and less hassle when creating new types.

Captain P - I don't want to hijack this thread, but in such a system, how would you know what to do when a collision occurs? For example, if a bullet hits a tank, the tank should take damage, the bullet should disappear, and maybe a distinct sound should be played. How would you know that these specific actions need to happen? (I'm already familiar with some approaches, but I'm interested to hear what you would recommend).

@violentcrayon: Sorry for the late reply. :) Yes, I'd use the bounding box of your tank to check if it's still inside the screen region. I don't think I'd use boxes for the screens edges, if it's absolutely certain that you'll never want a different playfield, but if you're planning on adding more obstacles, then using boxes for the edges would be a good idea, since you're then going to use more boxes throughout the level already.


@Gage64: That's the collision response part, and ideally takes place on a higher level than the collision check.

Depending on the situation, I'd write a collision system that allows other code to register collision shapes with it, along with a way to receive messages when their registered shape is collided with - likely integrated with an already existing messaging system. Depending on the needs, I could send more or less information about the collision. I could also add a flagging system, to tell which objects can collide with which other objects (bullet-bullet collisions aren't interesting, for example).

But it depends on the complexity and flexibility that you need - this approach is overkill for simple games, if checking if your bullet collides with an enemy and then destroying the bullet and damaging the enemy is about all that's ever going to happen.


EDIT: To clarify, in my first example, I wouldn't make boxes members of the entities that hold them. I would let the collision system manage all these collision shapes, and have the entities store a reference or handle to them. In my second example, I'd settle for having boxes as member variabeles, because I don't need much flexibility in that case.