Path Planning + Seeking Cover
Thanks for the comments William. Regarding the issues you raised...
1) In an ideal world, the planning of the path is fully dynamic, and takes into account live obstacles. This implies a direct integration of path planning and execution, as I like to call it. This is why I blame the planner, as it should monitor and take into account the execution.
However, this is naturally not yet possible for efficiency reasons... Since they had a static planner in AAS, they should indeed have some consistency checks; did we actually move forward? Should we recompute another different static path? This was not done for NPC, so I can see your point too.
The reason it bothered me is that AAS cannot return different paths for different units (I think that's right, due to the global "cache" and static path parameters). Basically, one unit in the doorway would go through it, while the one just behind would go around (in theory). But AAS would return shortest paths in both cases, forcing both units through the door. Countering this would involve stopping one unit for a while (wait behind doorway), or getting it to do something different (if the obstructing problem is even identified).
2) About the speed issue, fair point -- though the BSP would be in the cache already, for physics computatations. It wouldn't be quite as bad as you make out when done at the right time. My experimentation with this is still in its early days (trying to get Piglet and Pooh to play hide and seek reactively :) but I've noticed spreading the traces over a few seconds makes the result more human like; first find cover approximately (body hidden), then fine tune when the bot gets closer.
Thanks again for the comments, I really appreciate people actually reading and reacting to this ;)
|