Jump to content
  • Advertisement
Sign in to follow this  
flodywan

Pacman Collision Detection With Sides Of Maze

This topic is 2812 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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.

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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

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?

Share this post


Link to post
Share on other sites
The "virtual" pacman doing the collision stuff is the same size yes. But you can draw it any size you like by subtracing a bit from the collision coordinate and drawing a bigger object (ie centering it over the smaller one)

If the difference is too large and collision with ghosts becomes a problem, do that bit of collision in a more usual way with overlapping rectangle tests.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!