I have locomotion working acceptably on an aircraft. It simply follows a target object wherever I move it. How should I approach local avoidance and/or pathfinding for a 3d space with no floor? Ideally I'm thinking I want to use the local avoidance algorithm to give the Locomotion FSM a target and move that along a path or something as the agent gets closer.
There are literally tons of pathfinding solutions but they are all for ground-based agents. Are there any 3d systems available? It may be possible to do A* on a cubical grid, but I'm worried that would get too expensive for a bunch of individual agents.
I also considered very rudimentary local avoidance, like moving the target point and using raycasts outward to detect any objects, then using the hit normal to plot away from it. This would probably give me very stupid AI, though.
Have you searched for an existing solution? maybe some ai framework can do it, I would make a asset store shortlist and contact them authors to see what can be done on that front.
Else, the best way is to go full physics and implement raycastings. but the actual pathfinding is going to be trickay, avoidance is ok if obstacles are convex more or less.
I've been looking extensively and haven't been able to find a Unity based package, UAnswers had some threads on the idea but nothing solid. I haven't looked for an external library or anything because I doubt I'd be qualified to make use of it.
Good idea contacting the authors of the existing packages, I'll give that a whirl and see what their input is on the matter.
I have been leaning toward the full physics/raycasting and gave it a try with mediocre results, it can work but I think it would might be a real challenge to make smart ai rather than ai that just avoids rocks immediately before crashing with this method which is why I'm looking for a proper package to handle it.
Alright from what I can tell there needs to be a different implementation to get pathfinding in 3d space that is acceptably efficient and there seem to be a lot of inherit issues with 3D pathfinding in the first place..
So far it's been recommended that I continue experimenting with what I'm currently working on: raycasting for a robust local avoidance system.
The mian problem with 3d pathfinding apparently isn't that difficult to develop but is significantly worse for performance (http://arongranberg.com/vanillaforums/discussion/comment/1603/#Comment_1603) in relation to world size which means you'll likely be using a very chunky node graph with low fidelity. The alternative is using point graphs which are custom placed nodes that the agent can path between but it only works properly in a mostly static world where objects aren't moving on top of the nodes that you've placed. If they did, the agent would try to path to them and crash into something dynamic, potentially. This is a huge problem if you're in space with orbiting mechanics or any other number of dynamics.
One trick I thought of was using a smaller 3d graph that follows the agent and updates per frame. Basically bigger, 3D local avoidance since its too expensive to scan the whole game area, or even potentially just to your target.
Another thought was using a low quality point graph over the game zone for major pathing and then again, a robust local avoidance method to handle the up close encounters.
But, either way it seems that the local avoidance is the key. It's somewhat opposite of shooter AI it seems, since plotting the path is the major load, then handling local avoidance is a smaller issue depending on how many agents are involved. If this were aircraft in the atmosphere it would be super easy, locomotion with a target and an FSM for combat behaviors. But in space there are likely many dynamics in the game space like asteroids moving, large dynamic debris, gravity agents, and any solutions have to work and be optimal for 3d use.
So it seems like the solution winds up being: A vague path plot to the target (cheap, large block graphs), a robust local avoidance system(rays, normals, delta positions), and then potentially VO/RVO considerations (velocity of dynamic agents that could hit us) depending on how expensive it is at that point.
-- use offmesh links to move from one layer to the other. OffMesh links are used for ladders and jumps to move from one navmesh spot to another without continuity.
then, you will get a sense of 3d navmesh space, because offmesh links will be understodd during pathfinding algorythm, and to if you are at the highest level and want to go to he ground level, it will find the closest offmesh link to move down in layers.
It may be impractical if you expect a total freedom of movement, but I think you can get pretty near a good result if you place enough off meshlinks.
@Lane. Wow. Thats a huge amount of research. This never occurred, but 3D pathfinding should really be an interesting challenge.
The alternative is using point graphs which are custom placed nodes that the agent can path between but it only works properly in a mostly static world where objects aren't moving on top of the nodes that you've placed. If they did, the agent would try to path to them and crash into something dynamic, potentially. This is a huge problem if you're in space with orbiting mechanics or any other number of dynamics.
I think this may be worth exploring.
May be you'd need to add something like adding triggers to the path nodes and disabling them (exclude them from the search list) when they are triggered by asteroids (colliding objects). So, when an agent would try to pathfind he would find a path around it.
I didn't know about Off Mesh Links but it sounds like it could be promising.
I wonder what the practical differences are in using off mesh links instead of just generating a low quality 3d point graph on the whole game area, though. The built in Nav features would probably be convenient to use, but I'm not convinced that would be better than using a solution with points.
Yeah I thought about that, it probably wouldn't be too much more complicated to add in, I think its kind of required if most of the space is dynamic. If the Agent tries to path to the other side of the station and the station is floating around then it would fly up to it and rely on LA to path around it unless the obstructed nodes were disabled for pathing. It's probably something that would need to be added if point graphs were used.
I thought a little more about using raycasts for the long destinations. Worst case scenario in open space is navigating around a huge space station, everything else is either fairly small or an agent for combat targeting. So I thought it might work if the destination was set on the other side of a station, then a ray cast straight to it, and if it hits something then it rotates in a circular motion until it finds some clear area and then paths to a spot near there (basically kind of looking for a tangent point). The circular expansion of the ray would keep it working in 3d space and it would at least get to the edge of the problem object and eventually around it.
Your pathfinding trick sounds ingenius. I guess it can be a practical solution in open space. If the agent and the destination is rotating around a common center. But it may not provide solution to more general cases, particularly in cases when a vehicle has to navigate through an asteroid field or something.
I figured if the agent had got into a really congested area then I would need some way to weight its direction choices toward the "far" destination to prevent him from repeatedly avoiding locally in the wrong direction. It needs a feedback loop. Kinda stuck on that one for the moment... there is definitely some low level stuff in there to figure out, but I think I could make the ray idea work at least for open space. If there were to be an interior area I would definitely want to go with more traditional methods.
As it's not dimension based. I think it can work equally in 3d space.
Uhm... indeed, if you would set your "free space" with evenly spaced nodes ( like the light probes unity uses for lighting) then it could work.
Okay, some basic raycasting with local avoidance is working like... like a rock falling down a cliff.
FSMs consist of Brain, Aim and Move.
FSM Move just pushes the ship with force, later the speed var will be manipulated remotely by the brain.
FSM Brain constantly raycasts and looks for obstacles, when it finds one it looks for clear space which is done by using the raycasts didHit bool, it animates in a direction until the bool is 0 which sends and event to move the target point by bouncing off of the last hitPoint by a specified gap float, which turns the ship away from the object..... Sort of.
Thats basically all it does for the moment. It is very difficult to control but the agent will avoid colliders decently while sometimes going postal and getting confused. The logic for moving the target is not good yet and doesn't consider any kind of physical area context that needs to be considered if we want a smart placement of the targetPoint.
In addition to the (local) Target Point for the agent there is an Anchor Point which if it gets too far away from it will turn around and try to go back. There isn't any weighting to deciding the raycast direction for pathing around objects so once he turns around he'll just start avoiding however he can and eventually fly into oblivion and trigger the Anchor distance U-turn.
It's slightly boring to watch, but the Agent does avoid the asteroids consistently now. With some more work I can sort out directional weighting and acquiring targets for combat. For now, this local avoidance method needs a little more work with the local rays. It seems when they get very close to an obstacle they tend to not be able to see it clearly because of the raycast spread being too narrow at the nose of the craft.
it also flies around in circles if it has enough space, this is because of how I'm projecting its path to wander, and needs to be randomized with some variety.
He bumps into a lot with this method but it seems to perform more consistently than the first method.
Some good news is that with this update I can't seem to completely trap him.
Very nice. I saw your work and I like it. Also may you post your last post AI test package? I´m also looking to develop an object evade solution in an open space.
Same here. I did watch your demo a bit, at one point the AI decided a perfect circle was the way to go and it kept that up.
I'd like to see either what you did via screen shots of your FSMs or something like that. I've been playing with UnitySteer and Rain, but similar headaches as everyone else has had.
Take a look at this and let me know if it works. This is the AI, ship and basic chase combat ai.
Bah, I forgot to include a couple of custom actions.
Here's a package with the custom actions. You may aleady have these in your project so I'd recommend importing both of these into a new project to avoid errors in the console about duplicates.
Dude\EnemyLauncher - what goes in the Create Object?
Dude\MotorAim - FSM - what Action is in Check path below Raycast?
Dude\Raycaster Prefab - FSM - what Action is in Raycaster below Set Vector3 XYZ?
Also MonoBehavior above Combat FSM on Dude is missing.
Its a Missile, you can delete the EnemyLauncher item since I switched it to use the railgun and the error should go away.
Check Path is experimental and on hold so it's skipping through it. The missing action is Raycast 2.
The missing action is Raycast 2.
ArrayMaker Proxy, I'm not using it yet so you can freely delete it.
On MotorAim - Once I put Raycast 2 in - should it be Hit Event = NoClearPath, No Hit Event = Finished?
Also - EnemyRail FSM - Looks like the last action is unable to find it's target.
I think that you have a very solid AI. Seriously. I'm going to play around with this, but I like how it flows.
Only thing I would add is an additional FSM that checks to see if there is no Agent Anchor, then drop one at the point that the Dude ship is at. I dropped your Health FSM (I saved it as a template) on the Enemy_forTheAi and once the ship destroys this enemy, then it keeps going back trying to shoot nothing (i.e. it stored the last position, where the enemy died) and keeps going for that.
The warning was from the target the rail hit not having a health fsm. Looks like you added one.
The ai will loop around and shoot nothing because its firing is based on the angle to target, we'll have to leave the combat state and go back to wandering if we want to stop firing. That hadn't been put in yet i just got started on combat.
Yes, being able to return to Wander would be good. I was playing around with that but haven't gotten it to work yet.
Issues - Something in your FSMs keeps resetting the AgentAnchor to 0,0,0 but I can't figure out what. Once I figure that out I can test to see if the above works.
So, what are you using to get the battle target vector? If you're just setting it to the position of the BattleTarget object, then you might as well just parent it and save a process.
The Anchor being moved to the Battle Target might end up being a clunky method, the behavior of the agent is vastly changed when you adjust the minimum distance to the Anchor during combat and I'm thinking of ways to avoid doing that or using an array system to gather nearby obstacles to weigh in a safe direction vector and also weigh that against a projected path of the Battle Target.. So theres some advanced things that need to happen in the brain, I think, to make the system more stable than it is now.
The idea is to let Brain just collect data and decide what 'state' the entity should be in - ie Wander, Combat, Flee, Follow, etc... Then in those states its sending downstream events to the other FSM's to activate certain paths of actions to keep it all modular. That'll allow us to build everything separate, define conditions in the brain, then send messages to the other FSM's about doing specific things. I think ideally the Brain would just be collecting data, deciding what state to be in or deciding what things need to be done and just telling the other FSM's to do it and they'll have all of the dirty vectors and such down in those FSM's.
Here's a good theory reference for the weight ideas and array. I think without adding some context for the brain to consider then the AI is always going to be a little dumb and non-persistent in the big picture.
I'm still playing around with it. I'm thinking about adding an AgentAnchor to each Enemy and leaving the default one at origin then just switching.
I really don't think that you need to make this AI more complicated. The movement is good. The flow is good. It just needs some tweaks. For instance, it needs to target a little better and shoot more often once it's in range (it takes a long time to kill an object). Also it might need a runaway state. I'm actually fairly close to some basic changes without really changing all your stuff because you have done an excellent job setting this up (much better than I could have done).
Here's the package containing ONLY the Prefab Dude & Enemy updated with some changes.
Issues - The Ai runs into asteroids and gets stuck pushing them. Where should he wander once the Enemy is finally destroyed.
FYI - I finally got some flying AI to work using Rain Indie. I might post something up on their forum in the next day or so.
Really? Thats great! It's flight AI using all 3 directions?
Yes, but not totally autonomous. But that's okay actually. Still playing with it, but excited it's working. Also, your set up is really good. Like I said, a few tweaks and additions and perfect (remember to keep it as simple as possible as AI looks good simple with lots of random choices).
Update for this coming along soon..
I made a lot of progress last Friday on it but squeezing out time to work on it is still hard, I hope to have something available to share this week. Remaining setup for the next iteration is basically just Combat mode, tweaking the aiming, fixing any obvious bugs and setting up the Flee behavior.
This still isn't what I really want, it's basically an improved version of the last package and while it does improve quite a bit on the previous one I'd like to do an even more intuitive system that can path around things better and have more awareness of its surroundings but it would likely require some arrays and interesting weighting of priorities and I want to hold off on arrays for the time being.
Okie dokie heres a vid on the update.. Download will follow soon.
You can't patch this update in, you will need to replace the whole system. If you have questions feel free to ask.
As far as the update... The Behavior FSM manages what state the agent should be in, and the Locomotion FSM executes steering which should be done in that particular state while the Information FSM uses a spherecast to collect pertinent data in front of the agent such as giant rocks that he might crash into.
There are some hangups that I don't like, and you'll find them in testing it. I think I'm aware of most of the shortcomings but I'm not sure how to approach resolving them just yet.
You'll see Pink explosions and maybe some other materials and stuff since some of the FX are paid assets pieces.
The Asteroids I made are also included. The spaceship is a free asset (https://www.assetstore.unity3d.com/#publisher/3815) redist from the Asset Store.
In the EnemyRail fails to add 2 scripts.
Odd, I thought I had all the actions in there.
Not sure what the missing scripts would be. Let me know if adding this action resolves the errors.
Oh my, really sorry it seems the package doesn't have the custom actions! Check the attached file for all of them, I'm also updating the dropbox package so they'll be included.
I tried to open the file in hex and search the name of the script but I couldn´t find either.
Leftovers from an FX asset I stripped out, theres actually just the FSM there in the latest so I'm thinking they're safe to remove.
Now it works. I shall test it in full and keep in touch.
I didn´t have much time to test but from what I saw I like it. Also it seems that it still gets stuck sometimes ... must use more the debugger and stress that AI a little. ;D Also adding a missile detector would be great (I´ll start something in my spare time) than add a transition to evade it. Also I was thinking in adding a little more at your project - two new steering behaviors: queue and leader. I´m still learning the steering behaviors and I also have very little time but when I have something I am more than happy to share it here and make this a full system.
Yeah some intermediate level behaviors still need to be added for sure, this is a decent dummy Foundation for various types of enemies without getting into too much unique customization.
One way I thought we may have trouble scaling the steering system is that we currently need to provide a vector position to head towards instead of steering in a vector direction so that impacts how we proceed resolving targets and obstacles in all behaviors.
I've noticed when they get stuck is usually when a missile is invoked and has pushed them off course. This will go away when throttle control based on the raycast hit distance is added because the full constant throttle is what's making them stick and unable to turn.
I know that I am missing something but I can´t see where do you set the velocity?
You can't really set the velocity. The thrust is based on force input which is pretty rudimentary, I think I even crammed it in the Health FSM for the time being until I can build a proper thrust system and number that will be consistent between agents of different Mass.
Hi @Lane, Awesome work on the Aircraft/Flight AI. I'm new to Playmaker and I'd love to give this a try, but the dropbox links are dead.
Would you be able to repost or send them?
iirc the videos show the concepts and ideas I used, maybe you can derive enough from there to roll your own?
Hi, sorry for necroposting. I'm interested in looking at your logic for this if you still have it and are willing to share. I'm happy to host it on dropbox for others as well... I've just cleared out like 4 GB's of space... obviously it's outdated and no pressure to update anything. I still have Unity 4 installed. Feel free to PM me.
No plans to reup this, sorry. The YouTube video still stands though, so you could get the overview of the system from there.
That's a shame, but understandable. At least thank you for having shared your knowledge and experiments!
From your posts and yt videos- I gather that analyzing your FSMs must be like a playmaker masterclass, those who get the chance to learn from you should count themselves lucky!
Is there any way to access this project or the videos mentioned explaining the setup, as there seems to be a severe lack of steering AI setups not only for Playmaker but even for Unity itself, which is strange as you would expect it to be something quite common.
No plans to reup the project files, sorry.
There is indeed a lack of information and/or open sourced projects for steering behaviors, but the principles of steering systems can be analyzed and applied to an fsm system inside playmaker, as the video and my project demonstrates.