Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.

share|improve this question

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.)

share|improve this answer
Good tip. Thanks – o01 Aug 30 '13 at 8:36

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!

share|improve this answer
Farseer is for C#. The OP is using Java. The point is still valid, but perhaps you should use an example that the OP can actually use. – Richard Marskell - Drackir Jun 12 '12 at 19:36

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

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)

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...

share|improve this answer
You wanna mark one of these as the answer? – A13X Jun 8 '12 at 0:33
This answer is largely off-topic. He's asking about the best organizational practice for where to write collision-checking code, not how to implement keyboard-based movement. – Josh1billion Jun 12 '12 at 21:52
Sorry I was thinking of a KeyListener and that this would somehow deal with keyboard/movement. – A13X Jul 24 '12 at 19:34

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

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

share|improve this answer

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.

share|improve this answer
up vote 0 down vote accepted

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.

share|improve this answer

Your Answer


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.