I have a idea for AI Pathfinding system

Users who are viewing this thread

Why do they need to be processed by frame and per AI? Hell, that is what you call lazy programming.

What do you mean? name a game with 100's of AI units in a 3d open world (non-scripted ) that pulls this off without a hitch? Im not saying there isnt room for improvement but dont act like its the status quo. Arma and Mount Blade were really pioneers on this front. And yes, you gotta check the AI often frame-wise if you wanna catch it from making mistakes, being caught in a bad loop - all the while being combat ready to ie. swing sword, block a direction, turn to imminent threat etc...
 
And yes, you gotta check the AI often frame-wise if you wanna catch it from making mistakes, being caught in a bad loop

No game does this. Even in games with dynamic or destructible objects like Arma, pathfinding is only re-assessed if something in the route is altered. In most games where the environment is mostly static, pathfinding is assessed once when the agent starts moving and is then just cached as an array of positions, and is only reassessed if the target moves. Warband does this, which is why you can't have things like breakable doors and expect the AI to pathfind through them depending on if it's closed or not, because the AI mesh can't be altered at runtime.
 
What do you mean? name a game with 100's of AI units in a 3d open world (non-scripted ) that pulls this off without a hitch? Im not saying there isnt room for improvement but dont act like its the status quo. Arma and Mount Blade were really pioneers on this front. And yes, you gotta check the AI often frame-wise if you wanna catch it from making mistakes, being caught in a bad loop - all the while being combat ready to ie. swing sword, block a direction, turn to imminent threat etc...
No? You completely miss my point, recalculating a route every frame is just stupid. Also I doubt the engine works on a frame basis, but that is another discussion.
Why would a route change every frame? If an AI reacts 0.5 seconds later then that is not a problem, changes closer to the current location are of more impact than changes further away.
The amount of recalculating that needs to be done should be based on the current action, has nothing to do with frames.

Also you can group AI's in their general movements and reduce computation load that way, one of the many ways you can reduce the load.

You see why I called your method completely stupid?
 
No game does this. Even in games with dynamic or destructible objects like Arma, pathfinding is only re-assessed if something in the route is altered. In most games where the environment is mostly static, pathfinding is assessed once when the agent starts moving and is then just cached as an array of positions, and is only reassessed if the target moves. Warband does this, which is why you can't have things like breakable doors and expect the AI to pathfind through them depending on if it's closed or not, because the AI mesh can't be altered at runtime.

FSM Class​

The FSM class contains three properties and a collection of States.

  • fsmName: This property takes a string argument and defines the name of the FSM.
  • initState: This property takes a string argument and refers the engine to begin at a predefined state in the state collection.
  • finalStates: This property takes an array of string arguments. Once the FSM reaches and of final states, it is flagged and finished.
The scripted FSM structure normally consists of one init state, one or more conditional links, one or more normal states and one or more final states. Each state has init and precondition section, while each conditional link has precondition, condition and action sections. The order of execution is:

  • State: init → precondition
  • Conditional link (condition is true): precondition → condition → action
  • Conditional link (condition is false): precondition → condition
Scripted FSMs are added into the scheduler just like exec scripts, execVM scripts and spawn scripts.
To see what FSMs are currently in the scheduler, use diag_activeMissionFSMs command.


While the code placed into any of the sections of FSM cannot be suspended (canSuspend is false), the FSM itself is suspended every simulation between the state's init and precondition (exception is the init state).
The usual difference between the state's init and precondition is 1 frame but if the scheduler is busy it can take longer.
This is the only place where scripted FSM is suspended/resumed.

~ Arma3 'wiki

I myself have created a dynamic AI camoflage mod which also checks every unit's exact position ie Shadow, Indoors, balcony, Heavy Foliage and that is also a per/Frame check. Like you said with the doorway - the more dynamic or reactive you want the AI, the more often you'll need to check. Now its true Armas' vanilla pathfinding are preset nodes and its the FSM running every frame, not necessarily the Pathfinding itself. Thats one of its flaws ill admit and why we're working on a freely open Navmesh mod - but again, the more dynamic and reactive you want your AI in an open navmesh -the more expensive the checks.
 
The usual difference between the state's init and precondition is 1 frame but if the scheduler is busy it can take longer.

Correct me if I'm wrong, but having looked at the wiki what this means is that when a request for a change in state is made, the request is added to a queue and then processed one or more frames later if the condition is met. This doesn't mean it processes these every single frame, that would be utterly ridiculous for a game of that scale.

What that page is describing is a Job/Async system, which is a very common way of making sure the CPU doesn't do too much at the same time by executing function requests one frame later if there is time left in the frame, which is why it says it could take longer than one frame between the initialiser and the actual function call.
This is why in Arma 2 (haven't played 3) if you try to spawn in a load of objects, they appear at different times because not all the requests are executed at once.
 
Last edited:
Correct me if I'm wrong, but having looked at the wiki what this means is that when a request for a change in state is made, the request is added to a queue and then processed one or more frames later if the condition is met. This doesn't mean it processes these every single frame, that would be utterly ridiculous for a game of that scale.
What that page is describing is a Job/Async system, which is a very common way of making sure the CPU doesn't do too much at the same time by executing function requests one frame later if there is time left in the frame, which is why it says it could take longer than one frame between the initialiser and the actual function call.
This is why in Arma 2 (haven't played 3) if you try to spawn in a load of objects, they appear at different times because not all the requests are executed at once.

The game executes code in both scheduled and unscheduled environments resulting in some per/frame others waiting for FSM reaction. To know what exactly is run per/frame we' d need access to source code which obviously they wont provide.

The point is I think its safe to say it is quite expensive to check for many AI units pathfinding and ill add behaviour (as i said combat readiness). You generally have to choose between very scripted or delayed/limited reactions and performance. Now Ill admit I have seen more games attempt this lately but generally its one of the reasons games have dropped Bots -especially in wide open landscapes.
 
Like you said with the doorway - the more dynamic or reactive you want the AI, the more often you'll need to check.
Yes, but think about it again. Do you really need to recalculate pathing every frame? Obviously you can, but it's extremely resource-heavy to do so and completely unnecessary. That engine you referenced might indeed check AI states per frame, but it doesn't necessarily mean it runs the corresponding action (like recalculating pathing) in the same process, not does it mean the action is done over and over for every frame the state is persisting. This means the action of recalculating pathing can happen only once every few seconds because the condition that triggers it only happens on that frequency.
 
Back
Top Bottom