If I create a path network, it's fairly straightforward how to use it for AI characters that are going to transport themselves from one node to another. However, what would be a good way of using a path network for adding AI behavior such as strafing? A strafing character would leave the path nodes and/or edges temporarily. Should I design my path network class so there's a method called "getNearestPathNode(float xPos, yPos, zPos)" and use a query to that, and a constraint that distance may never exceed a certain length (so as not to have the AI characters reach impassable points when strafing, by going too far from good paths), and then make the AI movement not so strictly tied to the path network nodes and edges? Is that how it's typically done, or are there other, better solutions? Also, how should I design the AIPlayer class? Should the AIPlayer have a primitive moveForward method similar to a HumanPlayer, or should I use manual adjustments of positions for greater control? Ideally, for simplicity, I'd of course like to use moveForward-like abstractions, but will that be sufficient?

I'm not sure what your issue is here. Movement direction does not have to equal facing direction (which is related to what he is shooting at). Are you asking your agent to move N while firing E, for example? Or are you asking him to move N and fire at a target that is kinda N by moving E and W of the path somewhat?

Personally, I like to have the current "state" or "goal" of the player queue different locomotion behavior, and let a "locomotion" system" sort it out.

The process would look like this:

Decision-making system choose a Goal/State
The Goal choose a destination
The Pathfinding system finds a gross path to the destination
Goal choose one or several locomotion behaviors (agressive, sneaky, defensive, facing back, facing forward, etc)
Considering the path and the desired locomotion behaviors, locomotion system choose the agent facing, velocity and animation at each frame.


To avoid strafing getting you stuck in silly places, it depends what you use for pathfinding. Say you use polygonal navmeshes: When you move between to nodes, the locomotion system can add intermediate 'strafing' nodes distributed along and alternatively appart from the current navigation edge. As long as it places them inside the current convex polygon, you'll never get stuck.

Quote: Original post by InnocuousFox
I'm not sure what your issue is here. Movement direction does not have to equal facing direction (which is related to what he is shooting at). Are you asking your agent to move N while firing E, for example? Or are you asking him to move N and fire at a target that is kinda N by moving E and W of the path somewhat?

Basically what Steadtler said: not getting the characters stuck in silly places etc. if they carry out moves which may have a velocity perpendicular to the movement edge they're supposed to follow to get to their movement goal.

@Steadtler: ok, thanks! I will be using a heightmap-derived system of nodes, with each node representing a position in the corner of a heightmap quad. I will have directed edges from each such corner node to all of the other 3 corners in that quad. Path edges that are too steep, and nodes (with all their edges) that are located below water level, are removed in the preprocessing stage.

A few quick tips for you:

1. Knowing the nearest path node is very useful generally, but knowing the exact point on the path edge is even more useful. It's more likely there's no blockage between the bot and the edge (it's the shortest distance) than the bot and a node (longer distance).

2. Make sure your locomotion system can track if it's stuck, either by collisions or measuring change in movement (odometry) so it can fall back to 1. just in case.

3. Give your path edges a width so the bot knows roughly where it's safe to go. (Unreal does this.) Having a navmesh is even better because you know exactly where the floor is. But this isn't 100% to prevent you getting stuck, because of dynamic obstacles, so you need 2. and 1. as a fallback.

I hope this helps,

alexjc
AiGameDev.com

Thanks for the tips! I'll try it out!

One good idea is to add shooting, strafing and cover to the pathfinding itself, converting a pathfinder algorithm to a planning algorithm.

Difficulties include how to evaluate weights for shooting opportunities and cover against enemy fire, for example by combining pre-evaluated LOS analysis to possible future enemy position approximation.

If parameters like cover, facing, light, available ammunition and weapon characteristics are accounted for, then this way a bot can really shine: General co-ordination of fire and movement, taking reasonable risks to improve overall chances, etc. and changing weight evaluation and sharing data may by used to implement co-operation and personality.

As this may be too heavy for whole paths, it can also be implemented just for subpaths, having simpler and faster pathfinder or planner for longer timescales.


-Osmo Suvisaari
waspgames.com

Matt Buckland's book; Programming Game AI by Example, has strafing bots in the example game Raven.
It is implemented as a subgoal of the AttackTarget goal.
At worst, you can still learn something from it. :)