Should my game handle collisions in the Player object?

Question

I'm making a 2D platform game. Right now I'm just working on making a very generic Player class. I'm wondering if it would be more efficient/better practice to have an ActionListener within the Player class to detect collisions with Enemy objects (also have an ActionListener) or to handle all the collisions in the main world.

Furthermore, I'm thinking ahead about how I will handle collisions with the platforms themselves. I've looked into the double boolean arrays to see which tiles players can go to and which they can't. I don't understand how to use this class and the player class at the same time.

Answer 1

tl;dr I recommend handling the collisions "in the main world"

I can tell you what I'm doing in my platformer (still early in development). It seems to work pretty well.

I have an Updater class which handles basically all of the game logic for updates. That means:

• Processing keyboard input to adjust player movement
• Collision checks
• Collision reponses

I tried to write this stuff mostly in functional style (i.e., static methods) so I'm not dependent upon state and side-effects to perform basic update functions.

About 2 years ago when I first hacked together a prototype for a platformer, I had most of the collision and response in the Player class (or an abstract base class). This turned Player into a cluttered mess. When I recently did a re-write, I decided move all of that logic out of the Player (and other types of entity classes). Now, each entity class is more or less just a container for state; there's very little logic. For me, I find this much easier to maintain. (It also forces me to write simpler and more general code.)

Answer 2

Have you looked into physic engines like Farseer? Then Farseer would do the whole collision detection for. You just have to add the player as dynamic body and all the platforms as static bodies.

Hope I helped you!

Answer 3

Actually, if you're using Java, I'd recommend this tutorial:

http://www.youtube.com/watch?v=NIUKHHVF9ek&feature=relmfu

This guy helped a lot with my own sidescroller that I'm working on. I'd assume a lot of the same scrolling implementations would be the same for a platformer, except you'd be able to visit past places on the map, collide with a platform image, etc.

As for your more specific question about collisions, Mr.JavaHelp does go over it in the tutorial, but not in great detail. Basically, you can just keep the actionListener in the Board (World) Class and have the key methods in the Player Class. Here's an example of the Player Class Key Events:

    public void keyPressed(KeyEvent e)
{
    int key = e.getKeyCode();

    if(key == KeyEvent.VK_LEFT)
    {
        vx = -4;
    }
    if(key == KeyEvent.VK_RIGHT)
    {
        vx = 4;
    }
    if(key == KeyEvent.VK_UP)
    {
        vy = -4;
    }
    if(key == KeyEvent.VK_DOWN)
    {
        vy = 4; 
    }
    if(key == KeyEvent.VK_SPACE)
    {
        fire();
    }
}

And for a collision box, try some if statements in a checkCollision method such as (Rectangle1).intersects(Rectangle2){ }; Make a rectangle with the Rectangle Rec1 = Player.getBounds(); method if you can.

I just learned this and it seems to be working quite well so far. Just trying to implement a Title Screen with a Start Button actually...

Answer 4

Store your physics shapes in you Player / Enemy classes. This could be part of a physics component in a component-based architecture.

Perform you physics update in with a dedicated physics engine. Either your own, or one of the several already available.

Answer 5

The way I'm doing it is I'm grouping all the collidable objects in the world inherit from a superclass, and I'm letting each entity, meaning both the player and platforms detect the collision from the method in the superclass.

The collision detection method is called whenever an entity moves.

The method that the entities use to handle the collision however, is specific for each subclass, since the player will react differently to a collision than a platform. So in each subclass, the 'collision happened' method is implemented differently.

When a collision is detected, the superclass of the entity signals the other entity that there was a collision, and calls the opposite entity's 'collision happened' method.

Then again, you could as others say use an already made library. I implemented my own system since I need simple physics and didn't want to complicate things.

Answer 6

After a few years of research, game programming, trial and error, I've come back to answer my own question. I've found that the best way is to do this is using the Artemis Entity Component system. For those interested, research in component based architecture. It changed my life (for the better).

Create a Collision Component and attach it to the "Player" entity. Then create another class, the CollisionSystem, where you handle all Entities that have the Collision Component. In the CollisionSystem, do all of your fancy logic, intersection checking, collision handling, etc.