Collision detection in a tight maze

Started by
5 comments, last by joekarl 8 years, 6 months ago

The idea here is we have a tight maze (ie, a maze with 0 thickness walls and movement only along the x,y axis). This differs from say Pacman where the walls are a full tile thick. A specific example of this is Wizard of Wor.

Wizard_of_wor_1.gif

So I think there's a couple ways to go about this:

I could create a list of walls for the level and then do collision detection against the walls. This seems to work fairly well collision wise as movement is just a general thing with sliding against the walls. Problem is collision detection is pretty complicated due to the walls not actually having any size physics wise.

The other option is to create a tilemap with each tile knowing which side(s) it has walls on. Movement is more complicated because you're moving from point to point in the grid. This is nice because AI can make decisions about where it wants to go strictly when it hits grid points.

At a glance how do you think this sort of thing was implemented in the past? (I'm guessing it was probably the the tilemap way as it's be less CPU to do this).

Advertisement
I would definitely go for a tile map.

For non-zero wall thickness I would just add 1/2 a wall thickness at all sides of a tile. I think that should work.

I do wonder where your 0 wall thickness requirement comes from. With 0 wall thickness, you walk from center to center at the grid. with non-zero wall thickness, you add a wall thickness to that distance, I don't understand how that is relevant.

I guess the 0 wall thickness thing is more for the tilemap approach as there's no physics object per wall, the wall is more of just for display instead of actually impeding the players motion which is governed by the tilemap. I guess I was being a bit hasty in thinking the wall collision version had to have a 0 thickness wall.

Got some prototype stuff up and running with the tilemap setup. Basic idea is the enemies pick a tile adjacent to their current tile that they want to go to (so long as it won't go through a wall) and then travel to that tile. Once there they decide to go to another tile. Rinse, repeat.

Create a 2 level collision detection,

1- Rectangle collision - where you check if your player has collided with any of the walls.

2- Pixel collision - check if the player's pixels actually hit any of the walls pixels(in the texture).

This is useful if you want high precision, and because that's a really simple game, it would work fast enough.

I can think of two ways to do this.

1.) Like you do in the video, but there is no need for collision checks with the walls here. The characters are restricted to the center of the maze cells, so they can only move in directions dictated by the type of cell. If there isn't an opening, don't allow the move.

2.) Define each cell's bounding box so that it is inset from the walls and ensure that your characters bounding box/circle stays WITHIN the cell's bounding box, unless moving towards an opening.

Create a xy grid in memory. For each cell in the grid define which of the 4 directions the user is able to move in (You can store each direction as a bit (ie North = 1, East = 2, South = 4, West = 8) and just store one value in each grid. ie a value of 10 would mean that a player can only move East or West. When a player moves just check the grid value against the direction of desired travel and allow or disallow. When rendering the maze, just look back at that same value. If the value is 6 then you have an L shape where players can either move east or south, so that tells you that you must place walls on the north and west sides of the grid cell.

@MarekKnows yeah this is what I ended up doing. Works well enough for the enemy movement and makes the code super clean. Using ascii for the tilemap so a little different but same concept.

This topic is closed to new replies.

Advertisement