I'm working on Pacman. So far I have a 40x40 pixel pacman, and tiles are 32x32. For simple collision I check where pacman is, then if he's in a maze tile I find out if he's past the "wiggle room" (since not the whole tile is filled with the maze side).

My collision is working fine for simple left, right, up, down. But, if pacman is moving up, his sides can pass through perpendicular maze tiles.

I know why it's doing this. It's because I'm calculating the position with respect to which direction he's headed. Ex: if he's moving left, his position is the left side & center of his height, and if he's moving right, his position is his right side, center.

My question is, should I check for collision by calculating each side of pacman (so if he's moving up, I calculate his left and right sides), then checking whether those sides are inside a maze tile? This is the only way that makes sense to me, I just want to know if this sounds like I'm on the right track or if there's a better way.

Why not check all 4 sides every frame, or at least 3 if you're going to make it based on direction? The performance hit in pac-man shouldn't be that significant.

I've never written a Pac-Man-like game, but if I were to, I'd probably treat the player as a point rather than as a circle or square.

Even though visually the game entities (player, ghosts, etc.) and the areas between the walls have width and height, practically speaking the virtual space in which the game takes place is in fact a network of rectilinear line segments (IINM). As such, I'd think that no collision detection would be necessary (not in the traditional sense, at least). Instead, the movement of the game entities can simply be constrained to the line segments that make up the network.

[font="Comic Sans MS"][size="5"]You want to read <a href='&quot;http://gameinternals.com/post/2072558330/understanding-pac-man-ghost-behavior&quot;'>http://gameinternals…-ghost-behavior</a>

the movement of the game entities can simply be constrained to the line segments that make up the network.


Doesn't this mean that pacman would have to be the same size as all the other tiles? I very much like the sound of this, but I'm not completely sure I understand.

In the GameInternals article pacman is shown centered on each tile, so should I limit the movement of my character to only if he's headed toward the center of the target tile? I think this would solve the problem of his sides running into maze tiles. I could check if the target tile is a maze, and if it's not then if he's headed toward the center of the tile. I'm gonna test this when I get home, but does it sound good?

Doesn't this mean that pacman would have to be the same size as all the other tiles?

As the article states, the sprites can be bigger than the "tiles"; however, the only thing that counts for collision is the centre point of the sprites. Animation is smooth.

One approach would be to limit movement so that the centre point of an actor cannot move beyond the centre of a tile if the tile beyond it (along the path of the actor) is a wall.

sorry if I'm confused about what you are doing, but each map tile has what as it's center? It seems like you should have the center be open, then the walls are the edges. If that's the case, you shouldn't even need "collision detection". Just set it up as a graph where each tile is a node. Every node will have neighbors where there are open sides, and none for the closed sides. Then pacman just moves to the nodes and is unable to move where there are no neighbors. This will also make your implementation of the ghosts nearly trivial as you won't have to deal with AI handling collision, and it's pretty much a straight drop in of A* or whatever you choose to use.

edit: looking at that article now, you can still create a graph where only spaces available to move to are added to the graph. Then you are only allowed to move from where you are to the center of a neighbor or the center of the node you left. You shouldn't have to do any collision detection code in pac man.

Like previously stated, creating a graph makes everything in the game pretty trivial.

As the article states, the sprites can be bigger than the "tiles"; however, the only thing that counts for collision is the centre point of the sprites. Animation is smooth.

One approach would be to limit movement so that the centre point of an actor cannot move beyond the centre of a tile if the tile beyond it (along the path of the actor) is a wall.

Thanks, that's what I did last night. They just move in the center of tiles, and if the next tile is a wall, then they can't move past that center point. It made it so much smoother than when I was doing weird calculations for wiggle room.