5

I am designing a tower-defense game, and for that I am using the A* pathfinding algorithm to reach my destination from my spawn-areas.

The problem here is that all the units stack, which doesn't look visually good. Is there a way I can make them somehow group instead, and spread more if there's not enough space?

The algorithm works so that all units move a single tile at a time.

Mathias Lykkegaard Lorenzen
  • 15,031
  • 23
  • 100
  • 187

5 Answers5

5

A friend of mine who used to do AI design for a famous first-person-shooter game that you've probably heard of tells a story about how their pathfinding algorithm produced a fake-looking behaviour. You'd throw a grenade at a group of enemies in a constrained space, and they'd all bump into each other trying to all get on the efficient path to the single exit. It looked dumb and broke the illusion.

Rather than burning valuable processor cycles on better pathfinding, they added a heuristic such that if a group of enemies is fleeing, and an enemy bumps into another enemy twice in short succession, the enemy stops trying to flee and instead does a duck-and-cover, and then usually gets killed by the grenade as a result. It's very satisfying to the player, and looks a lot more realistic.

Perhaps there is something similar you can do here. If too many units end up heading towards the same path and are colliding with each other, and it looks unrealistic, is there some cheap and easy thing you can do to detect the situation and change the animation?

Eric Lippert
  • 647,829
  • 179
  • 1,238
  • 2,067
4

You can use flock behavior to have them follow the same general path but not stack up on each other. There is an XNA example provided by MS here: http://xbox.create.msdn.com/en-US/education/catalog/sample/flocking

Ed T
  • 410
  • 4
  • 11
3

Are you re-calculating the shortest path at every time-step?

If yes: Just give a tile a maximum amount of units that can stand on it. If it is full, no more units can occupy this tile.

If no: calculate the path of each unit one after the other. Give every tile a vector telling the other units (coming afterwards) when this tile is occupied how much. Put this information into your A* algorithm. Note: your algorithm will be a lot slower this way.

I would suggest to re-calculate the shortest path at every step.

EDIT 1 Actually, the complexity of the algorithm is in both cases the same, however, it seems to me that case 1 is much easier to implement.

Christian
  • 4,345
  • 5
  • 42
  • 71
1

If you add a penalty for tiles occupied by many creepers, it would probably space them out as long as there is room for them to move.

It wouldn't necessary be the fastest path anymore though. It could also make them more unpredictable, which depending on your target difficulty could be good or bad :)

Skurmedel
  • 21,515
  • 5
  • 53
  • 66
1

How about iterative pathfinding?

  1. Run a path-finding algorithm, ignoring issues with overlap. This will find the shortest path.
  2. Simulate the creep movement. This simulation should run with tile-based movement so that it will be fast.
  3. Select half (fiddle with this) of the creeps that are waiting in a line and thus not moving. Rerun the algorithm for those creeps, but add extra weight penalty at this position they were waiting. This weight will ONLY be applied to the creeps which had the extra weight.
  4. Repeat steps 2-3 until some condition is met, paying some (fiddle with this) attention to the previous extra weights.

This algorithm will require fiddling to fully coalesce into something useful. However, it has the advantage of using preplanned paths, so it won't have any loops or creeps moving backwards. It also allows you to ignore things like timing, so it's conceptually simpler. But also probably less efficient.

Brian
  • 25,523
  • 18
  • 82
  • 173