Quote:
|
Originally Posted by Maleficus
The problem is: in wolf, the total number of paths a bot may want to use is not static, like in CS. In Wolf, where you spawn, and where your goal is may change several times over the course of one match (your spawn moves back/forward, the goal moves to a diff location, etc). So, you have the problem of some nodes (that may no longer be "valid") being taken into account if you just blindly start playing with weights.
|
I don't see how it can be a problem ; look, in Day of Defeat for example, or in Team Fortress Classic on maps like Warpath, the spawn points advance on the map along with the front line. A* can handle that just fine. And in CS, same thing, when a terrorist has lost the bomb it can be at any location through the map, and the other bots can still go and pick it up without problems. Same in Opposing Force CTF when a player has lost the flag.
All you need to do is not to flag *waypoints* as goals (like in POD-bot for example), but the goal entities themselves. Then, a little helper function will tell you in realtime what is the closest waypoint to the entity you're interested in. After that, just use this particular waypoint and your bot's origin as the start and goal coordinates.
The remaining problem is the reachability of two nodes ; like, for example, a door that opens only under certain circumstances. You need to flag this in the connectivity info between your waypoints. A good idea would be also to store a pointer to the activating entity, or similar info for a bot to work out easily what it has to do to reach the next waypoint (push a button, wait for an event, etc...). Of course, these actions must be included in the final cost computation. This way, you get smart bots that open doors and work out obstacles only when 1°) it's possible and 2°) there's an advantage for them.