Implementing movement in a Pacman game

Question

I am making a Pacman Player vs Player game in Java, and I am wondering if I am implementing movement in the game in a good manner. Anything that will reduce the code size or make the program faster is wanted.

Note that the game is not complete, and I have only worked on player one (Pacman). I have not started on player two (ghost) or the maze or pellets.

Movable Interface

public interface Movable {
void move();
}

Pacman / Player One Class

This class represents player one, or the Pacman character. It implements Movable.

@Override
public void move() {
    if (this.direction == Direction.UP) {
        y -= 5;
    } else if (this.direction == Direction.DOWN) {
        y += 5;
    } else if (this.direction == Direction.RIGHT) {
        x += 5;
    } else if (this.direction == Direction.LEFT) {
        x -= 5;
    }
    create();
}

Game Class

In this class, I make a global type of my Pacman class, and I instantiate it in the Game's initialize method.

Pacman pacman;

I also make a global array of my Movable interface with a size of one (for now) which will hold my pacman instance.

private Movable mover[] = new Movable[1];

Then:

@Override
public void actionPerformed(ActionEvent e) {

    if (running) {
        moveEntities();
    }

    this.repaint();
}

private void moveEntities() {

    initializeMovement();

    for (Movable m : mover) {
        m.move();
    }
}

private void initializeMovement() {
    mover[0] = pacman;
}

Answer 1

Initial thoughts are:

• Why is move calling create? I don't know what create does, but this seems like a strange way for move to work.
• You're using 5 for all four directions, this seems like it should probably be a constant.
• It's unclear how you're going to implement collision detection at the moment, but it's something to consider when defining the interface for moving items.

From your comments, it seems that create draws Pacman. If this is the case, then I'd still say that you don't want to be calling it from within your move method. You want to try to decouple your game mechanics + movement/collision logic from your drawing/rendering logic, they are different concerns and may well move at different speeds. One of the things you've said that you are looking for is to improve the speed that your code runs at. If you think about running games on different hardware, one of the things to consider is that you need to start thinking about using that hardware effectively. To give a concrete example, if your current computer processes your move method 10 times a second, that's going to move your Pacman 50 units. Another computer may only run it 5 (moving 25 units) or may run it 50 (moving 250 units) that's a lot of variability that's usually ironed by linking the distance moved to the amount of elapsed time, which may be detached from the render time.

I haven't read the whole thing (and it seems to be aimed at the mobile market), but this seems like a fairly good introduction to game loop mechanics.