What's wrong with the architecture of a game object drawing and updating itself?

Posted by Ricket on Stack Overflow See other posts from Stack Overflow or by Ricket
Published on 2010-06-08T19:21:53Z Indexed on 2010/06/08 19:32 UTC
Read the original article Hit count: 142

What are the reasons for and against a game object drawing and updating itself? For example, if you have a game where the player has a position on screen, why not have an all-encompassing class:

public class Player {
    private int x, y, xVelocity, yVelocity;
    private Sprite s;
    //...

    public Player() {
        // load the sprite here, somehow?
    }

    public void draw(CustomGraphicsClass g) {
        g.draw(s, x, y);
    }

    public void update(long timeElapsed) {
        x += (xVelocity * timeElapsed);
        y += (yVelocity * timeElapsed);
    }
}

What is wrong with this design? What are the downfalls or concerns? How would you better write something like this, or better architect this type of thing in a game?

Also, somewhat connected, how would you implement loading that Sprite image?

And furthermore, how would you then implement collision between two Players?

(I should probably separate these extra two questions into new questions, huh?)

© Stack Overflow or respective owner

Related posts about architecture

Related posts about object-oriented-design