Polarith AI (Free/Pro) | Movement, Pathfinding, Steering

As I pointed out earlier in a post, I needed to ensure that our company is financed and can live. At the moment, everything goes well, so I started to merge the 3D stuff last weekend (still in my free time).

This review is the first time for me to look over that great stuff my team achieved the last months, so there are a lot of merge requests and testing before I can upload a new package. But I will update you guys here in the forum for each merge request I get done.

I already managed to merge the code adaptions necessary for supporting 3D. The next one will be the 3D sensor and perception pipeline. After that, the first behaviours follow. Then, the example scenes can be integrated. I will keep you up to date. Things are going on!

I'm sorry for this significant delay this year, but our team is finally growing. We hire a new C#/Unity developer, and it seems that things will go quite faster in the future because I can give up some gatekeeper responsibilities. Thank you all for your loyalty and continues support! I'm so thankful to be blessed with such a great community.


Martin Kirst from Polarith

 

No stress, I'd say we're much better off with a delayed release than with a company that ran out of funds and had to deprecate the asset.

 

Thanks for the update Martin

 

Hi !

Considering purchase of this superb AI system; what is the actual status of 3D integration ? Any ETA ?
Thanks !

 

The status is the one of my last post to this topic. I will inform you guys about every single integration progress I confirm. At the moment, I am convinced that we manage it this year.


Martin Kirst from Polarith

 

Thanks for the quick reply; will consider other options until then.

 

Good luck. Maybe we meet again when we managed to get this monster of a patch done. See you until then.


Martin Kirst from Polarith

 

Hey so in going through the quickstart I noticed the simple example does not seem to do well with large scaled objects. What is the reason for this?

 

Hi DespairBear,
the reason for this is simple. Behaviours like AIMSeek solely rely on the obstacles position and ignore the extents. Behaviours like AIMPlanarSeekBounds are fit for your example. However, these are exclusive to Polarith AI Pro.

Nevertheless, we added a feature that helps users of Polarith AI Free as well in such situations. With AIMSteeringTag you can define the radius of each object, so even AIMSeek would take the extents of such obstacles into account.
Hope that helps.

Franz Pieper from Polarith

 

Hi there, I saw that formation is one of the upcoming feature. May I know when it will be implemented? If i can't wait for your release and want to implement it instead, could you please give me some hints of how to do so?

 

Hi Anthony-LAW,

even though we already completed the implementation, we are unfortunately blocked by other vital projects we need to make a living. I am on the way to polish the code, write the doc and prepare some demo scenes. In our current state, I think it is possible to release within this year or at the beginning of 2019 though I cannot promise.

If you want to implement it by yourself, there are two ways to handle a formation: centralized and decentralized. The former approach uses a separated GameObject|script to set the target position, e.g. in AIMFollow for each agent, based on its location inside the formation and the formation size.

The latter and more efficient approach computes the position for each agent itself relative to a formation center. If an agent knows its location (index) in its formation and other formation defining parameters such as the size (number of agents), then the relative position can be calculated independently. This position can be used to calculate the ResultDirection such that the agent is going to move to its location inside the formation.

Best wishes,
Martin 'Zetti' Zettwitz from Polarith

 

HI Martin,

Thx for the reply.
I have another problem about steering. Imagine that a spaceship follows a 2D path on X-Y plane and there is an obstacle in front of it. The current AIMAvoid/AimPlanetAvoid/AIMBounds will try to avoid the obstacle by finding a way on the X-Y plane. That means the spaceship will deviate from the path. If the spaceship is smart enough to move up or down to avoid the obstacle, then the space will still follow the 2D path and avoid the obstacle at the same time. How can I implement such an avoidance logic? Would you mind posting coding here to show us pls?

 

Hello!
First of all i wanted to say thanks for this great asset. I'm making my second game ever, never had experience with ai. So i was like "ehm, it will be super hard to make a working ai in my game". Then i downloaded your product, and to my surprise after a few hours of work i was being chased by a swarm of enemies shooting at me. But then i decided i should add dangers, and i ran into a problem. Before you read further you should know that i use free version so you don't really have to waste your time.

Pic1: on top is player. it's object of interest
in the middle is obstacle. object of danger.
in the bottom is ai agent

Pic2: purple line is interpolated solution. So as i understand, ai decided to go around the right side of the obstacle, and then to the interest. Which is exactly what it does with simple controller. But in the physics controller there is this IF check:
if (Context.DecidedDirection != Vector3.zero && Context.DecidedValues[0] > 0.0f)
First part works fine, but second one is zero until interest moves, so agent runs into danger. I've added some debug lines, and before i move player (object of interest) my console looks like this:
Context.DecidedValues[0]: 0 Context.DecidedValues[1]: 0
So AI agent starts to move to interest, completely ignoring the fact of danger on the way.
But if i move interest, console goes like this:
Context.DecidedValues[0]: 0.06951271 Context.DecidedValues[1]: 0

I don't understand what's going on. I tried to change interest's rigidbody to continuous dynamic, and it didn't help. Can you explain it to me, please? What are these decided values and why they are 0 until interest moves or agent runs into the wall?

 

Hi Anthony,

you are welcome
At first, let's clarify: do you have a simple 2D game using a top-down/sideview camera? If so, there should be no problem at all, since this avoidance in z-direction can be reduced to an occlusion problem. So you don't need any avoidance at all since you can just do some graphics tricks (like rendering the agent in front of the obstacle).

To handle the situation robustly in 3D, you need a 3D sensor and a 3D controller. I am afraid to tell you that this is not a trivial problem since for such sphere like sensors linear interpolation is not available (at least in real time). Unfortunately, we are in delay with the release of our 3D sensor. There are other hacky ways to do this, but let me tell you, it's easy to construct counterexamples where these solutions will stuck with multiple obstacles since they do not observe the complete 3D space.

The first option would be, not use our AI to avoid in the Z plane - you can use the AI to steer in the X-Y plane and handle the avoidance in Z direction with another force that pushes the agent away from the obstacle(s). This can be implemented in a custom controller.

Another approach would use two separate AI components, where the sensors are perpendicular to each other.
So you need 2 GameObjects with their own AIMContext, sensors and behaviours, but only a single controller handling both AIMContext instances. This controller can use the first DecidedDirection to steer as usual and the second if a specific condition is met (e.g. DecidedValues[0] > x) to move above or below an obstacle.
In this video, we show how to use a setup with two different sensors for one agent. Even though it is a different use case, it might help.

.

I am convinced you will be able to implement such a logic easily.
With best regards
Martin 'Zetti' Zettwitz from Polarith

 

Hi ATernov,

welcome to the forum, nice to have you in the Polarith family We are happy about your feedback, that's exactly why we are doing this.

First of all, our controllers are just simple examples. They will fit many simple scenarios, but they can quickly run in situations where they won't work out of the box. In your case every object in the scene is collinear. So its a mixture of several problems: the parameters won't fix the situation and the Danger is higher than your constraint in every direction where Interest shows up (because they are collinear) so the controller decides to move to its default direction.

To clarify: the Decided Values are based on the Decided Direction, that is the best solution/direction that is acceptable to the agent. The corresponding values indicate the magnitude of the sensors in this direction. If you have not already done, I highly recommend to read the introduction to get the idea behind our concept: http://docs.polarith.com/ai/quickstart-aim-concept.html

Back to your problem. There are several options to handle your situation:

A cure to the symptoms is to adjust the parameters of your AIMContext by playing around with the Danger constraint to accept more or less dangerous solutions (i.e. the agent moves closer to the object). You can also adjust the Sensitivity Offest in AIMSeek for Interest to obtain more solutions from the sensors on the side, so it could not become zero so easily anymore.

To cure the root of all evil, you can alter the PhysicsController by simply setting a minimum torque so it won't be zero at all and turns to the Decided Direction, even if its Decided Value is zero. We also stumbled across the same problem in few occasions. It is not always the best solution to scale torque and force with the DecidedValue.

Best wishes and happy coding,
Martin 'Zetti' Zettwitz from Polarith

 

I really appreciate your detailed response, Martin. It clarified a lot for me, thank you!
The reason i'm using the example controller is i wanted to play with it for a bit, and understand how it works. Also i wanted to see what API calls it makes etc. After i get a grasp on it i'm planning to reuse the player's controller, so player and ai would move the same.

Back to my problem. I was able to fix it both ways you advised me. Now i kinda see what's happening. Decided direction is at 90 degree angle from the obstacle - it's the closest direction that doesn't have red danger sensor line. But it doesn't have a green interest line either. So it has 0 decided (interest) value.

It's a really flexible system you've got there. I can see a potential to dynamically make enemies more reckless after a player hits them or something
Thx for sharing it with us!

 

Hi I have a question does Polarith support dynamic navmesh? (runtime recalculate navigation on moving/rotating platform)(keep charactor's relative position to platform in the meantime ) Thank you.

 

Hi ATernov,

I am happy to read that you could fix the problems and understood the idea behind A custom controller is always a good idea since every game or simulation is different. I like your idea of changing the behaviour of your NPCs as part of the gameplay, that's exactly what we love about this concept: you can think more about AI design than AI implementation and NPC become more realistic.

Have a great day,
Martin 'Zetti' Zettwitz from Polarith

 

Hi zIyaGtVm,

all our system needs is a path object. The origin and if it is dynamic or static does not matter. In Polarith AI Pro, we provide such a behaviour for the Unity Navmesh such that it calls the path calculation of the Unity Navmesh Agent under certain conditions, e.g. every 1 second. If you have a unique Navmesh system, then you have to implement an adapter that gets the path from your Navmesh and passes it to our AIMFollowWaypoints behaviour. So yes it is possible. If you have further concerns, please ask

Happy Friday,
Martin 'Zetti' Zettwitz from Polarith

 

Thanks!
Still wondering will agent be stable on its original path during seeking while platform is rotating.
Although built-in navmesh surface supports platform moving, however navmesh agent will be throwed away.

 

Hi zIyaGtVm,

The path extracted by our AIMUnityPathfinding component is in world coordinates and is separated from the actual navmesh. To achieve a coherently moving agent, the path must, unfortunately, be updated every frame during the transformation. This can be achieved using the validators in AIMUnityPathfinding.

I hope this was helpful to you and answered your question. If there are more riddles than before, feel free to ask

Have a great day,
Martin 'Zetti' Zettwitz from Polarith

 

Hello @Polarith , I need to create a click to move controller, what is the fast way TO DO this?

I have been used this code but doesn't work (from http://docs.polarith.com/ai/manual-aim-path.html)

Code (CSharp):

1.  
2. using Polarith.AI.Move;
3. using System.Collections.Generic;
4. using UnityEngine;
5.  
6. // Class using/containing your custom pathfinding solution
7. public class CustomPathfinding : AIMPathfinding
8. {
9. // Your custom pathfinding back-end
10. [SerializeField]
11. private Pathfinding pathfinding;
12.  
13. // Transfers the computed waypoints
14. protected override IList<Vector3> points
15. {
16. get { return pathfinding.waypoints(); }
17. }
18.  
19. // Starts the computation of the path
20. public override void CalculatePath(Vector3 destination)
21. {
22. pathfinding.CalculatePath(destination);
23. }
24.  
25. // Checks if the computation has finished
26. protected override void Update()
27. {
28. base.Update();
29.  
30. // Notify the related components that there was a data update
31. if (pathfinding.PathIsReady)
32. PathChanged();
33. }
34. }
35.  

 

Hey,

Do you have a simple video tutorial for the Unity navmesh examples?

thanks

Nalin

 

Hi @Triggeredge,

first I have to apologize for not answering for such a long time, somehow I didn't get the notification mail...

Since I`m not sure how your game works I'll try to answer the best I can.

To create a click to move controller you can use an approach both with or without pathfinding. The most simple solution would be using an AIMSeek that references a Gameobject that is placed on the target location. If there are obstacles on the path AIMAvoid or other avoidance approaches can be used.

If you have a maze-like level structure you need to use the Pathfinding solution since a global solution is necessary.

In the latter case, you could simply use AIMUnityPathfinding implementing a custom pathfinding solution is not necessary. The key to have a move to click controller is the same, a corresponding target must be set on click and with an active TargetValidator, the behaviour is going to calculate a path to the new position. The agent generates interest in the path direction with the AIMFollowWaypoints behaviour.

If I got some wrong assumptions or you have further questions please let me know.

Franz Pieper from Polarith

 

Hi @puzzlekings ,

also, sorry for reacting so slow.

Unfortunately, the answer is no. Hopefully, we'll find the time to produce such video in the future. Do you have a specific question or a specific problem I can help with?

Franz from Polarith

 

Can you tell me why the Interest is set up with AIMSeek and why the Danger is set up with AIMSeekNavMesh in the example?

I tried creating a scene from scratch and my agent wouldn't move, so I've just started tweaking the existing scene and putting a maze in there. Also trying to setup a simple non physics controller so movement can be a bit more predictable. With the physics controller the agent kept getting stuck in the walls maybe due to colliders etc.

Thanks

 

@puzzlekings

You are right, a physics-based controller can sometimes get into trouble with the colliders. It is perfectly possible to adapt this example scene with a non-physics controller. You just need to exchange the controllers on the agent and remove the physics components. The AI GameObject with the AIMContext does not care how your agent is moved at all.

Our pipeline goes like this:
- AIMContext iterates each AIMBehaviour
- Each Behaviour calculates magnitude values based on the parameters and environments and writes them to its TargetObjective
- AIMContext composites the results of all AIMBehaviours
- You got a context map, which are these lines shown by the ContextIndicator, each ring is one objective.
- AIMContext calculates the best direction based on your objective settings.
- You somehow translate this direction into movement. Again, AIMContext does not care how.

In the example scene, AIMSeek is assigned to "Interest" because this is the maximized objective. AIMSeekNavMesh is assigned to "Danger" because it is minimized. The resulting direction is calculated such that the direction with the highest interest is chosen without violating the danger constraint. For example, direction 1 would have 1.0 interest but 0.7 danger. direction 2 would have 0.7 interest and 0.4 danger. So which is best? We use the constraint value to determine that. If it is 0.5 then direction 2 would be better even though the interest is lower. If the constraint would be 0.8 then of course direction is the best to go. This translates to "Chose directions towards the objective as long as no NavMesh edges are too close".

I hope this explanation helped to better understand the idea behind Polarith AI. If not feel free to ask for more details.

Franz Pieper from Polarith

 

Finally purchased the asset (for another project); just trying to understand how the whole thing works. I can't get examples in the Lab scene to work; nothing happens when I hit play; other examples work fine. Any idea ?

 

Hi @DiscoFever ,

and thank you for buying our product.

Can you give further details on which scenes seem to be broken? It would also be interesting to know which Unity version you are using. We are going to investigate as soon as we know where to look.

Furthermore, there are a couple of scenes, like AIMAdujst and AIMAlign were the agents do not move at all. The information we want to display is in the context indicator. To see them you need to active the gizmos. Maybe that was the reason. I hope we do not caused confusion.

I also highly recommend having a look at the quickstart guide, since the way how Polarith works strongly differs from common Steering. Besides the basic tutorial videos, this one also aims at describing the main idea of our system which I also highly recommend.

Hope that helped and if not feel free to ask further questions.

Franz Pieper from Polarith

 

Hi Franz ! Thanks for the very quick reply. I watched all tutorials (cool and funny btw); just wanted to put the hands on the UnityNavMesh, but agents don't move at all.

As I wrote, all scenes in the 'Lab' folder; agent doesn't move; I see gizmos and decision.
Using Unity 2018.2.14f1 (Mac)

Using all default values; straight from the package in the AssetStore.

 

Ah ok, wasn't sure if you meant the lab scenes in general or only the 3D lab scenes. I tested it and it actually works. However, I remembered another customer who encountered the same problem. The root of all evil are the friction values for the agent's collider. I'm pretty sure that in your case the agent does not move because the applied force does not overcome the static friction.

This is something really odd since on our test systems we do not have this problem. Also, this seems to behave differently between Unity versions. You can verify my guess by turning down the friction values on the "Lab Agent.physicsmaterial" e.g. to 0.2 from 0.4.

I'm sorry that you had to encounter this problem, we definitely have to think of a better way displaying our AIMPhysiccontroller. It is problematic though, since tweaking the friction values also affects the trajectory of the agent.

Hope that helps and nice to hear that you enjoyed our videos. Hope we can produce more soon.

 

Yep that was it ! Reducing to lower values both ground and agent works. Thanks now I'll play around with car in my project.

 

Will you release the 'suburb' demo scenes that you showed in the trailer ?

 

Hmm, this is a scene we were not satisfied with, in the context of publishing it. However, it is heavily requested so I think we need to have another look at it. Unfortunately, I cannot promise anything currently.

Franz Pieper from Polarith

 

Thanks Franz

I have a variety of controllers now working in the same scene around a maze.

One thing I noticed:
AimContext and AimSterringFilter both need a SteeringPerceiver which is most likely the same one. When both were empty in a new scene I dragged SteeringPerceiver to only the AimContext and then when I hit play it got wiped out to NULL. In fact both inspector fields need to be set, otherwise it doesn't work - so maybe there's some redundancy?

Regarding physics and stopping things from getting stuck I'm experimenting with a capsule collider instead which works ok on a level plane, but it needs X/Z rotations frozen to stop it from rolling around. If you have any other suggestions that would be cool

cheers

Nalin

 

Hi, been looking at picking up the pro version for a while now. Was wondering if it can somehow also handle moving an AI in reverse? Thx!

 

@puzzlekings Hi Nalin,

nice to hear that your controllers work.

I think there might be a little confusion about wizard tab. You only need to reference a single AIMSteeringPerceiver in the AIMSteeringFilter by either dragging the corresponding GameObject into the field or by using the Tag(handy for prefabs). The wizard tab in AIMContext (the most right tab) was intended to aid with a fast setup and thus it is as you say redundant.

Regarding the capsule collider, unfortunatly I have no out of the box solution up my sleeve. In fact when I used the capsule collider I also choose your approach to make things easy. Implementing a fitting character collider for a game is a very difficult task and it is of course very specific. The only thing we can do is to give examples how to apply the AI results into a collider.

Have a great week
Franz Pieper from Polarith

 

Hello @christougher.

What do you exactly mean with 'Was wondering if it can somehow also handle moving an AI in reverse?' Like stepping back in time or just a character that moves in reverse like a car backing up or something entirely different?

Best wishes
Martin 'Zetti' Zettwitz from Polarith

 

Yes like a car backing up to avoid danger or seek a more optimal position. Sorry, should have been more descriptive. Basically be able to accelerate both forward or backward if need be. As an example lets say a 2d space dogfight reminiscent of the old Dos game Solar Winds... at 22:20 there is a brief dog fighting scene. At 22.24 the player (albeit not ai) performs a little reverse thrust to get in better position. I suppose this is along my idea of what I'm after.

Dang that game makes me nostalgic, gonna have to find it and fire up DosBox lol. Anywho... When I first saw your "Feature Update" video my jaw dropped when I saw the multiplayer space shooter scene thinking the player characters were AI controlled. My bad but man that would have been some killer AI out of the box! Regardless Polarith looks pretty dang cool so far. Looking forward to the 3d update!

 

Hi, I'v tried the AIMFollowWaypoint, does it only look for next point in sequential index? (circle / back forth).
Is there any behaviour for seeking around combined AIMPath?
I mean, multiple AIM Linear Path combine together as one, and calculate the nearest way to approach target.

e.g AI(blue cube 1F) seek Target (white cube 2F).
Thanks

 

Hi @christougher!

I've good news for you! Our AI can handle such situations, but maybe not the way you would expect.

The AI is designed to compute the best direction that the character should move, it's up to you developers to move the character into that direction. The movement is done by the controller. The individual game setup is highly specific, so the controller is. We do provide some example controllers, but they are quite generic and not suitable for many situations although they will give you a hint how to implement your own.

For your interest: I've recently added some simple lines of code to the vehicle controller for backing up to fit a simulation of a research project. It may be a starting point for you:

Code (CSharp):

1. private bool reverse = false;
2.  
3. FixedUpdate()
4. { ....
5.     // angle between current direction and decided direction
6.     float diffAngleDirection = Vector3.SignedAngle(
7.                 transform.forward.normalized, AimContext.DecidedDirection, Vector3.up);
8.  
9.     // prevent stuck in a forward-backwards loop
10.     float thresh = reverse ? 75f : 110f;
11.  
12.     if (Mathf.Abs(diffAngleDirection) > thresh)
13.     {
14.         reverse = true;
15.         inputAcceleartion = -1;
16.         inputSteeringAngle = Mathf.Sign(diffAngleDirection) > 0 ? -10 : 10;
17.     }
18.     else
19.     {
20.         reverse = false;
21.     }
22. ....}

Thanks a lot! We are working on the merge for 3D

Sparkling Friday!
Martin 'Zetti' Zettwitz from Polarith

 

Hi @zlyaGtVm

this is quite a difficult problem you have there. Unfortunately, Polarith AI does not consider this case out of the box, so AIMFollowWaypoints only considers the next point of one AIMLinearPath only.

The reason is simple, the problem itself has a high complexity. When you have just one path, it is obvious which the location is. With multiple path objects, there is no next point, all paths need to be analysed to find the closest location, which can get expensive for long paths and many agents.

So my approach would be to implement an AIMRadiusSteeringBehaviour and add an array of path objects, in the overridden startsteering method you could search for the nearest location by traversing the path objects which the can be used to calculate the ResultDirection. However, if possible, I recommend using Unitys NavMesh since the problem does not exist there. This is because the navmesh agent would evaluate the own position and recalculate the path if possible.

Hope that helps

Franz Pieper from Polarith

 

Thanks for your replying, actually I'm a bit tired of using NavMesh since the NavMeshComponents[Github one][I need its feature to avoid static baking because my ground is rotating] caused my project to crash several times.So I bought Polarith instead to see if steering system could be more stable.

Like Martin said above,do you mean by using AIMUnityPathfinding to override NavMesh built-in behavior,I could achieve a relatively fixed path on my rotating platform?

Is it possible to evaluate the path if I draw every point in single linear path component[green line]?Does it needs extra algorithm? Any advice would be appreciated.Thanks.

 

Ah ok, if Navmesh is not an option, then we need to find another solution. As far as I understand your example I have to say, you need a custom algorithm. Our system is built around the assumption that the points are ordered and that there is a next one.

Your approach is certainly possible. It means that you have a graph with n nodes and you need to find the shortest path from a starting node to an end node. This sounds a lot like Dijkstra's algorithm might become handy. In my opinion, you could use two approaches to implement such strategy. First, implement a custom AIMBehaviour that gets a graph as input which is as well something you need to implement. Second, you can implement a custom Monobehaviour which manipulates the targetIndex of AIMFollowWaypoints. Maybe option 2 is easier since you don't need to understand our classes in detail, on the other hand, it is cleaner

Franz Pieper from Polarith

 

Hi Franz,

What is the current status of the 3D pathfinding?

 

Pro Purchased! Can't wait to play with it! In my one and only published game (Polygon Gladiator on android, iOS and Windows 10 is anyone cares lol) I struggled with having an AI that would aim to ram the player while avoiding the weapons which are at fixed points on the player, avoiding the front or sides depending on the weapon. I ended up using obstacles with unity's navmesh that carved continuously, which kinda worked okay but also would sometimes scooch an enemy from the weapons and certainly isn't optimal for mobile. Polarith looks like it would have been perfect for that. I'm thinking of trying to revisit and update that game with Polarith to wrap my head around it before I'm off to other projects.

 

Hi @brettmoody,

I think there is a little confusion: we do NOT work on pathfinding, but on a 3D-sensor system that can find solutions/movement directions based on multicriteria optimization. For clearance: pathfinding is a global approach and context steering is a local approach.

Unfortunately, I can't foretell a release date yet, since we won't promise something that we can't hold. All I can say is: we are working on it.

Franz Pieper from Polarith

 

Hi @christougher,

Nice to hear that you are the newest member of the Polarith Pro family We hope to save you tons of code and hours of work. It's always a good idea to get familiar with the AI first, before using it productively. We recommend to read the manual and watch the tutorials first if you haven't done already.

Additionally, last time I forget to add a GIF of the altered car controller to show you an example of the adjustments.



Have a great kickoff for this week.
Martin 'Zetti' Zettwitz from Polarith

 

Hi, I've got a request/suggestion to improve the Perception Pipeline. I don't necessarily want the use the Layer system to define the Interest/Danger objects and I'm adding everything at runtime and spawning/reusing multiple prefabs. Would it be possible for you to add the following code to the AIMEnvironment.cs?

Code (CSharp):

1.     public void AddGOToEnviro(GameObject GO)
2.     {
3.         GameObjects.Add(GO);
4.     }
5.  
6.     public void RemoveGOToEnviro(GameObject GO)
7.     {
8.         GameObjects.Add(GO);
9.     }
10.  

This would make it easy for me to add/subtract gameobjects to the Environment.GameObjects list as I spawn/despawn them at runtime without being contrained by the layer system. This seems like it would be way more performant then calling UpdateLayerGameObjects(). Correct me if I'm wrong. I'm not a strong programmer so I could be missing something.

 

Hi again @christougher,

it's always nice to hear when customers use your product to a point where they can make suggestions.

The GameObjects List is a public member of AIMEnvironment so you can do the following examples without having the methods you suggested:

Code (CSharp):

1. environment.Gameobjects.Add(entity);
2. environment.Gameobjects[i] = entity;

And, of course, all other operations you could do with a List. I understand your point though, regarding usability and readability it might be better to encapsulate the list with methods like you suggested. At the time we implemented the core of our AI we felt that simply making the List public is the best way. Or is there any other benefit I'm simply missing?

There is also a tiny yet handy script in our package. (scripts/EnvironmentUpdater.cs) This script can be used to assign GameObjects to an AIMEnvironment based on the hierarchy. You might want to have a look at it.

Regarding the performance your guess is right, the layer system is most efficient for objects that stay in the scene like static obstacles. Using the AIMEnvironment.Gameobjects List you also have the advantage of setting a feasible capacity, so you avoid relocations of the list in the memory when frequently adding and removing objects.

Franz Pieper from Polarith