Help making enemies more aware of walls.

[Pungsnigel]

Hi!

I'm currently part of project group, writing a shoot 'em up java 2D game. Using the A* algorithm, I managed to sort out the basic enemy pathfinding, and they have no problem finding the players position and start attacking. While implementing the pathfinding, I didn't take into account that the actual enemies would have collision boxes, not just a position to keep track of, resulting in a enemy behavior that doesn't handle walls very well.

Basically, the calculated path is correct, but since the enemy only makes sure their upper left corner (their position) never enter a wall-tile, problems occur when any other corner is the one close to the walls. I don't really know how to handle this, and would be grateful for any tips I could get.

[princec]

Modify your pathing algorithm such that when standing next to a wall, they cannot make diagonal movements. Currently you are probably allowing every grid tile to allow all 8 neighbours as nodes in your A*; simply don't add ones which would cause the gid to walk through a wall.

Cas

[Pungsnigel]

Thanks for your answer:)

I made sure they don't walk diagonaly close to walls, they consider themselves as standing in the tile the upper left corner of their collision box is positioned in. The problem is that the enemies think they are walking from one tile to another, while most part of their actual collision box is located in another. So while the upper left corner will never collide (thanks to them never walking diagonaly while close to a wall), the rest of the body will

Games published by our own members! Check 'em out!

[krasse]

I always combine the path planning with a simple obstacle avoidance when the path is followed.
It is often quite easy to compute an extra movement offset by setting up repulsive "fields" around objects.

I did so in this (without path planning) and this (with path planning) game.

[Pungsnigel]

Sounds quite a bit like what I'd like to achieve! Do you mean that I should try to make the walls "push" the enemies away, or find some way for the enemies to behave a bit differently when close to walls?

[Eli Delventhal]

Why not just change things to use their center rather than their top left corner?

Actually now that I think about it, that shouldn't matter. If I want to move to (3,5) on the grid then that means my top left corner wants to move to the top left of (3,5). So unless your walls are jutting halfway between grid positions I don't see the issue if you're being consistent.

[krasse]

Sounds quite a bit like what I'd like to achieve! Do you mean that I should try to make the walls "push" the enemies away, or find some way for the enemies to behave a bit differently when close to walls?

The basic idea is to use several sources to define the movement.
The path following (or where the bot wants to be/go) will provide the basic movement vector and then you simply add contributions from obstacles and other things you want to avoid (grenades, projectiles, team members and enemies). A moving vehicle could contribute in such a way that it makes the bot move out of the way,  but should not contribute at all if the bot is behind it etc.
Then you simply normalize the resulting vector and use it as the new movement direction. Often this gives a nice and rather natural behavior, I think.

[Pungsnigel]

I feel I might have been a bit unclear, I didn't know what information would be needed. The reason I can't calculate the correct vector in the manner you describe is because we designed the game so that there would only be 8 directions. I do like the idea though, thanks:)

[Pungsnigel]

Thanks for answering:)
I gave that a go, and while they are closer to managing corners and such, they still can't. As of now, the corner of their collision box will still hit the corner of the walls. They consider themselves to be standing in the tile that the center point of their collision box is positioned in. This of course means that they may believe that they should go left, from tile (3,5) to tile (3,4), even though parts of their collision box could reside in tile (4,5). If tile (4,4) is a wall, I got myself a problem:(

[Pungsnigel]

Finally got it working! Had to change quite a bit of code, but now it's behaving:)
Thanks for all the answers!

Games published by our own members! Check 'em out!

[krasse]

Great!

[Eli Delventhal]

Good stuff. Did you ever figure out the issue or did you just find it working when you redid everything?