Hello everyone, I have an idea for a game I’d like to implement. It requires some basic AI though and I havn’t had any luck searching some down.
Does anyone know of some scripts or tutorial for some basic AI?
The functions that I’d need are as follows.
Target acquisition, pathfind towards target, attack target, if target moves, re-acquire and pathfind toward them.
I would also like it to work in swarms (with other AI enemies attacking simultaneously).
I’ll give ya some feedback. How about smoothing the path? Instead of him making every turn on each point and moving in a zig zag pattern, how about checking if the path between two points is clear (the first point and the third point) and moving between the average of those two instead of wiggling all around the board?
I think my take on it is that I’d use a VERY different approach rather than employing a grid.
Here are two possible approaches:
Produce a script which let you designate a volume via properties which would then automagically fill the volume with nodes (density based on more parameters) and work from there. This is computationally expensive (albeit “bakeable”) but eliminates the need to build a special mesh to define the path.
Produce a script which looks at an imported model and finds path nodes (based on configurable name parameter) within it and works from there (including firing rays around to determine which routes are blocked). This would allow level designers to add all their path nodes in the same tool they build the level mesh in.
Both of these options produce a clean workflow and would allow you to produce compelling demos quickly.
Sorry this feedback is in the wrong thread – Unfortunately it’s feedback of the form “your basic algorithm is fine, but I’d use a completely different approach”.
It’s a tech demo. Making the dude’s behavior nicer is really an exercise for the end user. My problems (see earlier post) are with the overhead/workflow involved in implementing the system.
That part concerns path following which is not the goal of the library. However you do have complete freedom to define your own path following behaviour. I just provide an example script showing a very simple path follower.
Not as far as I can tell … I have to mark up the mesh manually in Unity…
Correction: Ah – btw the current version works MUCH better for me than earlier versions. Yes, you’ve basically implemented option 2 (not quite but close enough).
As long as there has been navmesh in the library, it should equal to your description in point 2. I don’t think I ever released the versions without navmesh.
What you refer to are the dynamic functionality of the navmesh cells. To mark an area as always blocked, you simply remove one or more polygons from the navmesh.
To have a togglable area (like a door, a raising bridge, a location where rocks have fallen and are thus blocking the way) you can enable and disable any polygon (or cell) in the navmesh at runtime.
So far I have not included any design-time features (editor extensions) to modify the navmesh beyond what is mentioned above.
– Unfortunately it’s feedback of the form “your basic algorithm is fine, but I’d use a completely different approach”.