A Star pathing with big and small units
Author
How do you calculate the path for a unit larger than 1 tile? Does anyone have any links to any articles on this or any experience?
First, this should belong to the AI forum.
Second, it depends on your data, what's the granularity of your grids? what's the size difference between your units (like 1, 2 or 3 tiles wide?) Something you could do, is test the surrounding tiles to make sure the entire width of the unit will pass, otherwise consider your tile as a "non passable" or "wall"... of course, if you know this at design time, you could bake these values into your grid of even have a 2nd grid for a 2nd unit size, and a 3rd for a 3rd unit size... etc...
Hope this helps
Eric
Second, it depends on your data, what's the granularity of your grids? what's the size difference between your units (like 1, 2 or 3 tiles wide?) Something you could do, is test the surrounding tiles to make sure the entire width of the unit will pass, otherwise consider your tile as a "non passable" or "wall"... of course, if you know this at design time, you could bake these values into your grid of even have a 2nd grid for a 2nd unit size, and a 3rd for a 3rd unit size... etc...
Hope this helps
Eric
Have you also seen this referred to as A*? I honestly didn't know what you were referring to in the subject. I have been known to be ignorant before though. :)
You can store a node list per-resolution. The positions are then parametrically calculated as a point field in R2. Position is the derivative of spacing, which I believe was your end goal?
Each node list is then culled using the boundary conditions, in order to remove potential nodes and associated node connection paths which are in fact out-of-bounds.
It is like Eric states above. More environments, more data. That simple.
It's like a ham, you start off whole and then slice off the ucky stuff. Mmm. Yum. Math-ham.
You can store a node list per-resolution. The positions are then parametrically calculated as a point field in R2. Position is the derivative of spacing, which I believe was your end goal?
Each node list is then culled using the boundary conditions, in order to remove potential nodes and associated node connection paths which are in fact out-of-bounds.
It is like Eric states above. More environments, more data. That simple.
It's like a ham, you start off whole and then slice off the ucky stuff. Mmm. Yum. Math-ham.
Author
I am trying to decide if having larger tiles would be better to accomodate my larger units, with the tradeoff being that smaller units will have a lot of empty space around them. Or if I should change my A* algorithm to use a unit 'hit map' and intersect this with my tileset so I can have units of arbitrary tile size and configuration. Currently I would like to support units of 1-9 tiles in size (1x1 to 3x3). I also plan on having huge units which are 25-50 tiles big, but these can be a special case I guess since they will only appear in certain situations.
Something you could do, is transparently split each 3x3 tiles into 1x1 slots.
I'm not sure if you've played Star Craft, but from what I could see in this game, they seemed to have split their tiles into smaller areas so that small units (marines, zerglings, zealots, etc...) could fit in the same tile.
Its not that hard to have larger tiles report to be "free" or "used" depending on what's on it and the type of unit requesting to use it.
Hope this helps
I'm not sure if you've played Star Craft, but from what I could see in this game, they seemed to have split their tiles into smaller areas so that small units (marines, zerglings, zealots, etc...) could fit in the same tile.
Its not that hard to have larger tiles report to be "free" or "used" depending on what's on it and the type of unit requesting to use it.
Hope this helps
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
