Keeping player aligned to grid in Pacman

Question

I am making a Pacman game using XNA. The game is tile based, with each tile being 32 pixels. As the player moves, I need to know whenever it is perfectly on a tile (ie position of 32, 64, etc...) so that I can check to see if the next tile is free. I am using the following logic to test this.

if (position.X % 32 == 0 && position.Y %32 == 0)
{
    onTile = true;
}

I figure that I need to make the player's speed evenly divide 32. Everything works fine if I make the player's speed an integer such as 4 or 8. But if I make the speed something like 6.4, I end up with positions such as 64.00001, and my if statement no longer works correctly.

How can I keep the player aligned with the grid, while allowing a wider range of player speeds than 1, 2, 4, 8, 16, and 32? Or is there some better way to go about this?

Thanks

Answer 1

I've used the modulus operator method before while I was trying to emulate the movement in classic JRPG games, and also ran into the same limitation as you did. In order to be able to use any speed value, you need to approach the problem in a very different way.

The method I suggest is to treat movement as if you were following a path, moving your character between each node in the path at whatever speed you want, but making sure to keep the path nodes aligned to the grid. Because if all of the end points of your movement are aligned to the grid, then your character will also remain aligned, no matter what speed he's moving at.

For this answer I'll just give an example of how it can be implemented, although there are many other ways to do it. I've based the implementation for this answer on another answer I've given before, which I suggest you to check if you have any questions about the method below:

• Related answer: Make objects follow a strict path (Xna)

The core of that answer is the following method which moves the position towards a goal, snaps to the goal if the movement happens to overshoot, and lets the user know when the movement has finished:

private bool MoveTowardsPoint(Vector2 goal, float elapsed)
{
    // If we're already at the goal return immediatly
    if (_position == goal) return true;

    // Find direction from current position to goal
    Vector2 direction = Vector2.Normalize(goal - _position);

    // Move in that direction
    _position += direction * Speed * elapsed;

    // If we moved PAST the goal, move it back to the goal
    if (Math.Abs(Vector2.Dot(direction, Vector2.Normalize(goal - _position)) + 1) < 0.1f)
        _position = goal;

    // Return whether we've reached the goal or not
    return _position == goal;
}

Using this method, it's pretty simple to move your character around. But unlike the other answer, this time instead of using a list of positions as the path for the character to follow, I decided to only record what the next target is, and compute a new target whenever the old one is reached.

I created these variables for the pacman, that specify its position, speed, direction, and a nullable Vector2 to store the next target in its path:

private Vector2 _position = new Vector2(32, 32);
private const float Speed = 156;
private Vector2 _direction = new Vector2(0, 1);
private Vector2? _target;

And here's the bulk of the Update method:

// Detect user input and set direction
if (Keyboard.GetState().IsKeyDown(Keys.Down)) _direction = new Vector2(0, 1);
if (Keyboard.GetState().IsKeyDown(Keys.Right)) _direction = new Vector2(1, 0);
if (Keyboard.GetState().IsKeyDown(Keys.Up)) _direction = new Vector2(0, -1);
if (Keyboard.GetState().IsKeyDown(Keys.Left)) _direction = new Vector2(-1, 0);

// If there's no target and we can move in the chosen direction, set new target to be the next tile
if (_target == null)
    if (CanMoveInDirection(_position, _direction))
        _target = _position + _direction * 32;

// If there's a target, then move pacman towards that location, and clear target when destination is reached
if (_target != null)
    if (MoveTowardsPoint(_target.Value, (float) gameTime.ElapsedGameTime.TotalSeconds))
        _target = null;

The comments should be self explanatory, but I suggest you to try the sample below and see for yourself how it works. Just copy the code into a new XNA project, it does not require any assets to run.

• Full XNA 4.0 sample: http://pastie.org/4178262

PS: I know some parts of the movement are not behaving exactly like pacman, such as stopping when changing direction towards a wall. The point of this answer is really just the grid aligned movement.

Answer 2

I would keep the position in units of tiles, not pixels, in an integer. Then I'd Hold the direction the player is moving, it could take values like, NORTH, SOUTH, EAST, etc. Then I would have two offsets as floats. On each update, I would then use the direction to figure out which offset to add to. If I was moving NORTH, I would subtract speed variable from the yOffset. If I was going SOUTH, I would add speed to yOffset. If I was going WEST, I would subtract speed from xOffset. And so on. Finally I would check to see if the yOffset is greater than the tile size and if it is, I'd add 1 to it's yPosition. If it's less, I'd subtract. I would do the same for the x. When rendering I would always do xPosition + xOffset. Which I'd do for the y too.

Answer 3

What I've done is previous projects is not match the player exactly to a particular tile but more like if they are mostly overlapping a tile.

Vector2 tilePosition = new Vector2(position.X % 32, position.Y % 32);
if(tilePosition.X >= 16)
    tilePosition.X = position.X + 32 - tilePosition.X;
else
    tilePosition.X = position.X - tilePosition.X;

... repeat for Y ...

Obviously there are cleaner ways of writing that but the idea is that if half of the player is overlapping the next tile, assume they are on said tile. And since you are checking if they can intersect the next tile before hand you can always assume that they are never half on an open tile and half on a collidable tile.

EDIT: The idea behind this approach is that unless you use exact multiple of your tile size as your movement speed then you can never assume that the player exactly occupies a single tile.

Instead, when a player is colliding with at least 50% of a tile, consider them to be occupying that tile.

In the image above, we would consider the player to be occupying the green tile instead of the blue tile.