I've successfully produced a re-usable tool that can load maps from files and display them. (I'm very happy with it because it's reusable, I can use it for future products also! It's only changing the "tile-Type" enumeration in the file and it works!).

Now I'm working on player collision. Do you believe I should simply allow my Collision class to have a pointer to my player (My player holds it's own position) so it can check collision (It will also have a pointer to the map) and let Collision handle everything (Passing any collisions that happen to Physics of course).

Or do you believe I should have my Player class simply being in charge of moving the player (Which entails handling it's SpriteSheet, etc.) and have it update a playerPosition member variable in Collision?

For clarification, Collision, Player, and Physics are all classes.

That's smart. What I'll do is have a set of Collision and Physics functions that I'll use!

Thanks, I didn't even think of that.

I was thinking about this and wanted to throw out another option. You can also provide a function from a super class that all Physical Objects have and it could be used to check if it collides with some other Physical Object. Kind of like this:

class TPhysicalObject { public: TPhysicalObject(Size, Shape, etc.); virtual bool IsColliding(TPhysicalObject& otherObject); // Some other functions... }; class TPlayer : public TPhysicalObject { // Define your Player object here ... }; // In code, you can check if the Player Has collided with other objects for (int i = 0; i < EnemyBulletList.size(); i++) { if (MainPlayer.IsColliding(EnemyBulletList) { // Do whatever if player collides with enemy bullet } } // Do the same thing with enemy objects and our bullets, etc

I'm not saying one way is better than the other, but it's another option, but it's certainly better than having a Collision Object itself.

Good luck.

Thanks, I believe I'll stick with having global functions however. Maybe I'll try using inheritance in my next game.