UnitySteer - steering library for Unity

Still haven't been able to figure this out. I have tried removing both "shpericalObstacleData" and "DetectableObject" scripts from the shpere, and nothing changes. I tried raising the max force on the vehicle and the Avoidance force and still no change. is it possible that my vehicle is moving to fast? that the min time to collision is too short?

 

n8: What I was finding was (and you can see this a little in the video I posted) that at the speeds my vehicles were travelling and the forces they were using, by the time the radar detected the object, there was not enough force over time to avoid the obstacle. Then, if I grew the radar to a size large enough to detect the object ahead of time, the vehicle tries to avoid the object by the size of the radar sphere... so there is not a good way to look forward and detect an object and then "just miss it".

Also, it seems that the vehicles are using the forces in the steering scripts to move, so check to make sure you've assigned enough force in the steering script to avoid your object.

 

Little Angel, thanks for the reply! That does make sense about the system not having enough time or force left to react to the obstacle. I will try dropping the max speed way down and pushing the max force way up. If that turns out to be the issue, then that would also explain why the steer for separation seems to not be working. do you think setting the "min time to collision" to a much larger value would help at all?

 

Let me know how you get on. I've been at Ninja Camp all week at UT HQ, but I hope to get a spare mo' or two next week to look at Unity Steer.

 

Hey guys, I am still trying to work out this obstacle avoidance. I have tried the tips that Little Angel suggested, but I am still having issues. I created a test scene to try out the millions of changes that I have tried. I can get my ship to successfully navigate a scene with a bunch of obstacles in it, and it will eventually get to its target. The problem seems to be that the ship is not respecting the colliders, and treats the obstacles almost like waypoints. What I mean is that it almost goes out of its way to fly towards an obstacle instead of just trying to move around it. I recorded a quick video to show you what I mean.

I have tried setting various radius on the obstacles but it doesn't seem to change anything. Any ideas?

 

I've had the same problems as you, and could never figure out a work-around, even with the latest version of the libraries.

My suggestion to you is to use UnitySteer in conjunction with the A* Pathfinding Project free version to get the behaviour that you need.

 

I was beginning to feel the same way, intellectually. I have not yet had a chance to play with this since my last post, but when I'm thinking about it, I feel that - for my purposes - I need to put the avoidance behavior in a state machine or tree and have my seekers pursue my target as directly as possible and only when the target is hidden by an obstacle, use obstacle avoidance.

I think it's also worth noting that a lot of this steering behavior works well with larger more chaotic groups: Boids, Flocking, Herds, Groups of race cars. For that specific chase and catch behavior, A* patching may appear more intelligent. Where is gets complicated in my case is adding the 3rd dimension to the A* calculations. I had looked briefly at rolling my own A*, and the math is relatively simple. I'm frightened of the "fine print" to get is all polished.

 

Hiiii Arges

First of all, thanks for making this powerful toolkit. It's exactly what I am going to integrate in my project now.
But I encountered a problem.
The game is a 2d action-puzzle game. For the 2d part, I use 2d toolkit already, whose default plane is xy plane. Now I would like to integrate UnitySteer's 2d function with 2d toolkit. However UnitySteer's 2d default plane is xz plane.

So my question is, is it possible to force UnitySteer 2D to work in xy plane?
Thanks for your help.

 

http://www.arges-systems.com is down for a long time, who know what happen ?

 

I'm finding that link working for me. I know they've been busy finishing their game, and supporting this package is a side-project, so I'd say no guarantees on when you'll hear from anyone...

[EDIT]

As a matter of fact, here's a recent post:
unitysteer-optimization-mobile-profiling

 

Not out of the box - UnitySteer takes planar vehicles to move on the X/Z plane, but it should be easy enough to modify for that.

 

Indeed I've done it, and works great.

@Arges, Im getting some odd situations with SteerforTether, where the allowed distance affects the resultant behaviour inconsistently. For instance, If set the distance to 12, the vehicles will move as expected, but when I go down to, lets say, 10, they start acting as trapped into a little space around the tether point.

I think, however, that before going foward into trying to fix this, I would rather first update to 2.5b. My question is then, how can I relatively safely update my scene where I got Prefabs with behaviours attached, up to the latest version without breaking too much of it? is it possible?


Also, side note: I've come to notice that the vehicles sometimes get stucked into nothing, simply stopping from moving at certain point, what may indicate the forces on that given vehicle are cancelling each other to a zero point. Have you developed any way to debug the forces on the vehicles to analize and tweak the behaviours parameters to avoid those cases? Do you have any practical hack or recommendation to avoid those situations?


As always, thanks so much for such a great work!

 

Oh, also: I have noticed the new "SteerToFollow" on the blog. I was accomplishing the same simply by using steerForTarget. The library is getting a bit clogged with -what looks like- reduntant behaviours, at least on what the naming indicates.

 

I believe you are somewhat correct in that the naming may be a bit confusing, and some general behaviors can be replicated using different scripts. However, there are some key differences between the scripts. I believe the "Steer-for-target" script will cause the vehicle to slow to a stop when it is within the target radius set. If your target is constantly moving, then the vehicle will be forced to continue to try and get to the target, thus following is achieved. The "Steer-for-point" script will does not have the "slow down" effect, instead the vehicle just tries to get to that point. Finally, the "Steer-for-pursuit" behavior will cause the vehicle to actually anticipate where the target will be (if it is a moving target of course) and then steer for that position instead (this makes for more aggressive vehicles).

I agree that some of these behaviors could easily be consolidated with a few options tossed into achieve the individual behaviors. Overall, however, the behaviors work well in what they attempt to achieve imho.

@Arges correct me if I am incorrect on the behavior of the different scripts. thanks

 

That is indeed weird - it's a simple distance calculation, so that should not be happening, and I haven't observed it myself. Let me know if you narrow it down.

Here's what's likely going to be your main issue: if you have a bunch of objects with AutonomousVehicles in them, they may end up being Bipeds instead because of a metadata issue (my fault, I should have renamed it before I started the refactoring). You may need to write a quick editor script that changes them.

Other than that, I recommend you serialize everything as text before doing the change, and review the diff carefully after you upgrade - a lot of properties have changed, as you can see on the changelog, so it's a pretty major upgrade.

It does sound somewhat odd that your behaviors would exactly cancel each other out, but I guess it's not impossible.

If I get some unexpected steering behavior, I usually start by:

1) Switching the editor into Debug mode, so I can see how much is every steering behavior contributing.
2) If I see something that seems out of whack, I start adding Debug.DrawLines to the behaviors.

You may just have some issue like the behaviors are applying force, but not enough to move a rigidbody up a slope because of its mass.

My pleasure!

 

Indeed. On this specific case, they are redundant, and I intend to prune them before marking 2.5 as "final". However, my main intent with small behaviors like those or SteerForSpeed is to provide example of the rationale behind how UnitySteer behaviors are organized - what's the minimum that constitutes a "steering" - so that people can use them as a basis for writing their own (something that can be less than obvious if they just look at behaviors like SteerForSphericalObstacleRepulsion).

 

Thanks a ton! As always, a pleisure to talk with you. I will work and get back to the thread on the results of the update and some other things.

 

Ok, I have updated to 2.5.3b. As expected, the autonomous vehicles where biped after the port, but not much more hassle beyond some minor adjusments to subclasses. Lucky

Here are some comments:

First, I keep seeing some odd behaviours on my vehicles. On one side, a member of a group will sometimes stop somewhere and have a really hard time recovering from that, and rejoin the group. On the other, if I have a group that looses all its members but one, the one will also behave funny. Once I realized that was a natural problem related to the lack of neighbours, it was easy; still not implemented, but I think I would check how many members of the group are left, and if its just one, enable a Wander behaviour. But I will check more and get back.

Second, I found a minor issue. Im using isPlanar property, and found that when changing the value of the turnTime property, the plane supossed to be fixed, will fluctuate a bit.

Tracked the reason to TickedVehicle class, in the method AdjustOrientation, there is a check for TurnTime != 0, and then a check for IsPlanar. Well, fixed the issue by swaping the order of checks, first the if statement of TurnTime, and later the IsPlanar, so the "newForward" vector doesn't get affected by the Slerp operarion inside the "if (turnTime != 0)".

And third, as I use the isPlanar in the Z plane as opposed to the default Y, and I had to change that for second time after the port... and some others seem to be also changing it, I made some minor modifications to make the IsPlanar plane selectable from an editor dropdown field, just in case someone find it useful.

Im attaching the diff files with the changes, to use against the stock 2.5.3b. Just two files.


Thats is for now, thanks Arges!

 

Can this be used with UnityScript? If can , is there some explanations or examples?

 

Ok, after some work and optimization of my code, subclassing for some behaviours customization and the aforementioned solution to the alone-boid issue, I can happily said I have eliminated all odd issues.

Also, another experience to share that may become handy to others:

The vehicles use the Unity Layers to check for neighbours. This is kind of not really flexible, for a number of reasons, but mainly, Layers cannot be created from code, comparisons need bit mask operations, and there is a fairly limited number of masks available.

On my case, I dinamically instantiate several independent flocks of vehicles, so the Layer system was kind of a pain. So investigating a bit, I easily tracked the use of Layers down to only two places (cool!). The Radar class, which uses it for spherical área collision checks, and the behaviours itselves, in the class SteerForNeighbors.

Brilliantly, the Arges implementation is very easy to customize, and I ended up replacing the check for Layers in the SteerForNeighbors class, for a simply integer comparison, thus, rendering the dynamic instantiation of independ flocks of vehicles a no brainer.

 

It can - it's no different than referencing any other C# code from UnityScript. No examples that I'm aware of, since I don't use UnityScript myself.

 

Hello Novack,

You're right, and a better implementation would be a category ID or Group ID on the vehicle itself. I may put that in before I mark 2.5 as final. Glad it was easy for you to implement a workaround.

 

Excellent!

Aha, I see. Slerp is supposed to retain the magnitude and the Y value, since both vectors are unit length and have the same Y, but maybe you were running into some rounding issue. Good catch.

Thanks for the diff, I'll go over it as soon as I get a breather.

Cheers!

 

Yeah, thats exactly what I did, an integer groupId. I thought about sending a diff too, to save you from trivial work, but silly me, put the id in a class outside UnitySteer, so part of the changes are in my code instead of the vechicle class.

If you want a hand with it, please do not hesitate on leting me know, I can change what I did to a proper implementation, and send you the changes.

 

Found another issue. I will not be able to investigate further until later tonight, but posting it here in case anyone has some info.

When the IsPlanar is set to true, the vehicles will end up getting abrupt orientation changes. While the object itself does not get the fixed plane affected, some behaviour is still trying to get it to face in the right direction, with ugly results.

I think this should work either by avoiding any rotation except on the other two planes, or by allowing the object to rotate smoothly on the three planes, while preserving the fixed plane transform.position fixed for the object. Tricky.

Will research and come back.

 

Hi Arges,

First off - Awesome stuff. Thanks much for releasing this for other people to use. I've been working with it for a couple days now, and I really like it.

I have come across some unexpected behaviour... it's entirely possible that it all makes perfect sense, and I just don't see the connection, but... if maybe you could illuminate me on what I'm missing, I'd appreciate it. Or if anyone else could, too.

I have attached a Bipedal and a Steer For Pursuit to an 'enemy' object, chasing a player-controlled object with a Detectable Object on it. I've left almost everything at default, except I've changed the speed and set the enemy IsPlanar to true.

The two objects start about 16 units apart. The enemy quickly moves towards the player and turns to face as you would expect... but once the bipedal gets close to it's target, it starts to get really jerky. At this point, I never move the player. The enemy actually starts to go backwards slightly, then forwards again, etc. etc. I set up some Log statements, and what I discovered is that once it gets close to the target it starts to apply negative (away from the target) forces. Presumably this is to slow it down? The effect, though, is that the model starts to rotate to match the new heading, and then the next frame it applies a positive force again causing the enemy to rotate back. It gets even worse if the player is actually moving, sometimes the enemy can get into a state where it starts to oscillate, and it causes it to kind of zig-zag toward the player instead of a nice smooth path.

After much fiddling with various things, I've discovered that I can easily solve the problem by changing the Bipedal Tick Length from the default of 0.1 to something like 0.01. With many, many assumptions on what, exactly, tick length does... this actually makes a lot of sense. Presumably it's going to apply force 10 times as often, now, but with a much smaller magnitude (or for a shorter duration). This smooths out the issues, most definitely.

I'm wondering, however, if the smaller tick rate will affect performance. Again, assuming it ultimately means that I update more frequently, it's going to be more expensive the smaller I make it.

I wonder if the way Bipedal could detect when it's applying a 'slowing' force, and prevent rotation in these cases? Or is the rotation being caused at the Rigid Body level as a reaction to the forces?

 

Arges will need to report about the details but I can add a few things...

Tick, as far as I can tell, is how often your calculations fire and there is a tick engine controlling this, so yes, I would assume that making the tick length smaller would decrease performance.

The other issue I have discovered withe Unity Steer is that there needs to be a controller, state machine or decision tree of some sort controlling the steering behaviour. Steering doesn't work magically in all situations. You may find that you need a controller to set "tick" based on distance. You may find that you need a state machine or decision tree that changes the behaviour in certain circumstances, e.g.: from "Steer for Pursuit" to your own "Attack" behaviour when the player comes in range.

Does this make sense?

 

I also improved the jerkiness on some situations by raising the MaxForce value. But for the most part, it is usually the weight of different forces. I fixed most of this cases only by experimenting with the values. I was using something more in the lines of boids, with several UnitySteer behaviours each. In your case, should not be complicated.

And I would definitively try (at least to see how its affecting) without the rigidbody.

 

So I've built out a new scene... I started fresh to avoid any kind of interference from anything else. The problem persists almost regardless of the settings I use. I find if the target starts far away from the pursuer (30+ units), or if the pursuers max speed is very low (<6), it seems to behave... but neither of those are things I want to be forced into, and they don't make sense. Something is strange. I'll keep digging... but any help would be appreciated.

SteerForTarget behaves in the same way if the target is the target's transform.

 

Hi,

Glad you're finding it useful Mirzero.

Little Angel's description is accurate. The forces are applied every frame, but are calculated only ever Tick time seconds. It will then of course have an extra cost to run it more often, but if you have simple steering behaviors, this extra cost is likely to be negligible. The profiler is your friend.

This is more of an issue of the specific steering behavior, not the vehicle itself. What I would recommend is writing a post-processing behavior (see for instance SteerForSphericalObstacleRepulsion on the development branch) which takes that into account and corrects from the desired direction vector.

This is absolutely correct for anything but the most trivial agents. In the same way that your behavior when driving changes based on the conditions, you would want your agent's parameters to be adjusted depending on the agent state.

Cheers,

 

This makes perfect sense to me. I totally appreciate that UnitySteer is for the raw steering behaviour, and it's not for deciding which steering to do at what time, and all of that. I also agree that it should be that way. There's always AngryAnt for the behaviour stuff... and once I feel comfortable with UnitySteer I fully intend to grab AA and play around with that, too, but I digress...

My confusion comes from the fact that I think of "move to the target at this speed" as a single and simple steering behaviour. I don't really see it as something that should require any kind of behaviour controller to accomplish. I could be very wrong. I'm an amateur in all of this... but that seems pretty uncomplicated to me. I had a script I wrote myself doing it before I started playing with UnitySteer... and it worked fine. It probably wasn't very optimized, and it wasn't particularly flexible... but it got the job done. I wanted UnitySteer, though, because if offers a wide array of behaviours... which it would take me a long time to implement, and chances are good that I couldn't do it as well as Arges anyway. Perhaps I have confused and over complicated my previous posts by even mentioning the 'slowing' down thing. I don't WANT slowing down... at least not yet, and that may very well be something reserved for a behaviour switching control... it just seems to be what actually happening with SteerForPursuit.

So, to start over and make a long question really short:
With UnitySteer... should I be able to set up a situation where one gameobject moves directly (and relatively smoothly) toward another gameobject at a set speed, without any scripting of my own? Is this a use case that UnitySteer supports out-of-the-box? I don't want anything more complicated than that (yet)... I'll worry about complicated later.

If so, could you provide any insight into how to accomplish this? My attempts so far have failed, and given the apparent popularity of UnitySteer I can only assume it's a misunderstanding on my part, and I'm having trouble finding any actual examples. I don't need tutorials, but I can't even find example scenes for US2.5

 

@Mirzero Im using what you are looking for (although not with biped). So I know that you want something feasible (and very easy once you get use to UnitySteer).


Another thing I see on your setup, is that you have the "arrival radius" on the biped set to 1 (I think thats default). Try making that value smaller and see what you get.

 

I made a small change to SteerForPursuit, and now it behaves in EXACTLY the way I had originally expected regardless of the settings like arrival radius, or speed, or tick length, or anything like that. So I'm not sure, yet, what the consequences of my changes are - I'm sure it was done that way for a reason... but at least I'm getting the behaviour I wanted now. I'll work on understanding it later.

line 148 : force = Vehicle.GetSeekVector(target);
changed: force = Vehicle.GetSeekVector(target, false);

I made a similar change in SteerForEvasion (removing the subtraction of internal acceleration).

 

I've also been using UnitySteer, and to be honest, I'm not sure I will keep using it. Part of this is that the support community around the product is pretty thin - lots of people appear to have evaluated it, and/or built a boids example, but I've seen fewer significant examples (i.e. in-game characters - boids demos don't count) out there.

Unity is great - you have the asset store where code can be grabbed for way less than it costs you to write it. So there are examples like Sage and NGUI, where the time saved massively pays for the cost of the purchase, and there are others, which I'm not going to name, where you waste a bunch of time trying to figure something out, then realize you could just have coded the subset of behaviour you needed way more easily, and throw them away.

I still haven't decided which category UnitySteer fits into for my game, but I'm still using it, meaning it gets the benefit of the doubt.

Anyway, yo your actual question: I saw similar behaviour to your pursit/flee (i.e., the pursuit just looked wrong), and this was caused by setting MaxPreditctionTime on the pursuit to something far too large, like 5 seconds. If you do this with a target that isn't moving in a straight line, your pursuer extrapolates the target way out, and it looks dumb. Is this what you were doing, and if you make your MaxPredictionTime smaller, does that make your character behave right without your change?

 

Hi ferretnt1, thanks for the response.

I did try setting the prediction time... but it didn't help. In fact, I'm pretty sure when I was cruising through the code I discovered that for bipedals the prediction time isn't even used. Don't quote me on that, though... SOME input value was completely ignored (but used properly in vehicles that aren't bipedals) but I can't remember which one it was.

Anyway, changing the prediction time didn't seem to have any effect. Changing the tick time did improve things, but even with 0.0000001, which is obscene, it still behaved oddly once it got close to my target.

Again, removing the odd internal velocity adjustment solved my problems completely... but I haven't bothered (yet) to go back and try and puzzle out why it was being done in the first place. I also don't know what the ultimate consequences of my change will have, other than making it behave the way I expected it to in my current experiments.

 

The beauty of it, is that no one asked for your "benefit" of the doubt. Much work has been put into this library, I am a user of it and can testify about that.
But if you don't find it useful, then please, be my guest and drop it. If you think you can do better, go for it.

No one here is asking you anything, so please do not come and write as if you are making some sort of favour by using a free library.

And for the record, if you don't have the necessary skills to figure out how to use this, I greatly doubt you have the necessary skills to make something even near what Arges has done with UnitySteer.

Peace.

 

I'm sorry you feel you needed to respond like that. I don't want to derail this thread with mud-slinging, as it's about the most active thread on UnitySteer, which is a technology that shows great foundation and potential.

And actually, re-reading my own post, it does do UnitySteer an injustice, (especially in my mind, because I know which other asset store technologies I didn't name in the "useless" bucket.) I should have said something in-between. It's not clear to me that UnitySteer is the de-facto choice for base steering behaviours for complex, particularly land-based, characters.

However, everyone who releases a library, even for free, is asking for something. They're asking for the client's time investment to confirm that their solution can meet the client's use case more quickly than the client can build it themselves. That doesn't just go for UnitySteer, that goes for every piece of technology.

For example, Unity's NavMeshAgent is free, but if you're using it in preference to A* Pathfinding Project, you either have a project with very simple requirements, (you can tolerate your levels being entirely fixed in world space, and you don't mind your CharacterController and Navigation being nailed together in a single opaque class) or your evaluation is dubious.

Technical evaluation is always a part of game tech choices, and what you see as production implementation and support community is as important as reading the library code. As of now, I think it is a reasonable statement to say that I see fewer shipping, production-quality projects and a smaller active customer base/forum with UnitySteer than with, say, NGUI.

If my requirements were to build a set of Boids, or possibly a virtual aquarium, I'd be using UnitySteer. But it remains unclear to me that it's the one true foundations for steering complex articulated characters.

I look forward to your work showing off UnitySteer's potential. An active community of people sharing practical experience is a huge boost for any technology.

 

Ferret, as far as I know Arges built UnitySteer for use in their own projects, they were just very kind enough to share the source code, probably in the hope that others would add to it or benefit from it in some way.

In my monster truck game I've used UnitySteer for all my car AI behaviour and it's worked absolutely fantastic, and I thank them for it. What's more is I only made some very small changes to the codebase, the rest was taken care of for me, and I'm really happy with the results.

You can't expect 'support' on a free product that is more of an open source code library. The idea is to go through the code yourself and improve upon it where you can. Sometimes you're lucky to get a response from Ricardo, sometimes you are not. But the real fact is they are very busy with their own projects and don't have time to support something they've donated to the community out of goodwill.

 

Hi I have an odd behavior. If I set steer for point for a Char, the char move there and then I hit the char with something, the car star moving again toward the original point! Is there a way to reset the steer for point behavior when reaches the target? and another question. If I have a default wander behavior but I want that the player chase something if an event happens how can I put wander behavior in hold and let chase behavior handle the player?

 

Corax, most of the behaviour you describe is stuff that's above and beyond what UnitySteer does. You'll have to write custom logic that sits on top of UnitySteer to achieve it, but it should be pretty easy to write for the simple cases.

For example: add a SteerForPoint component to your object, and then add a custom script that checks to see if you're at the destination. If you are, it can disable the SteerForPoint component. That way, if something moves the object off of the point, it won't go back. Your script could also check for other conditions that turn the behaviour back on, and make it try to return to the point again, if you wanted. Eventually you might want to look into behaviour tree stuff; I haven't started working with it yet, personally, but I've heard http://angryant.com/ is really good.

Your second question is about the same. Add both a SteerForPursuit, and a SteerForWander. Add a custom script that disables the SteerForPursuit on start, and then checks for the pursuit condition. When it finds a target, it can disable SteerForWander, set the target in SteerForPursuit, and then enable SteerForPursuit. This should get you roughly the behaviour you're after.

 

Guess what actually my game is using that kind of logic, but I thought that was wrong (don't ask me the reason why). So I had a solution in my hand and didn't know. Thanks a lot!

P.s. with a little effort you can easily use Behave and UnitySteer to create complex behavior

 

I don't think the UnitySteer in asset store works in the 4.X version of Unity. Does it?

It looks very outdated in terms of the development. Will it still work in 2013? :3

I'm trying to create a 3D space sim, and UnitySteer appears to be the only non A* non grid based object avoidance system. Considering my stuff is fully 3D, I can't use grids at all.

(My thread is here)

 

Unity Steer was recently updated. It's up to 2.5bx... Check the Git Hub link.

 

Just started looking at UnitySteer, and the only examples I've found are the 2.2 ones. I'm doing a 3D space combat game, so the "Avoid obstacles and neighbors" example scene was the most applicable. I unchecked "Is Planar" on the kittens and made a bunch of copies. The behavior was pretty reasonable (well, except for the whole Kittens in Spaaaace! thing...).

For my game I pulled in the UnitySteer 2.5 code, but I can't get to the point where either obstacle avoidance or neighbor avoidance is working at all. The ships just fly through each other and the static obstacles. I've tried tweaking the various values quite a bit. For each space ship, I added: Radar, Steer For Wander, Steer For Tether, Steer For Spherical Object Repulsion, and Autonomous Vehicle. I put a Detectable Object on the static objects.

One thing that doesn't seem to exist in 2.5 is SteerForNeighborAvoidance.cs. Is there an equivalent in 2.5, or is that implied? I was hoping that static obstacle avoidance would at least work.

Anybody know of available examples using 2.5? I'm considering going with UnitySteer 2.2, as I can at least get that to work.

Thanks!

 

I have slowly been fussing with UnitySteer for a similar project, and have run into similar issues.

I'll try to share anything I discover here, but I'm not getting much free time to work on the project.

One of the main issues I'm discovering with this steering library as it stands, is it's great for very organic systems, but seems to fail in the "look and feel" of a mechanical object. This seems particularly true for flying machine behaviour. You don't really want to be rejected or repulsed by the spherical object - you want to steer for a point that will just avoid it. This is a different behaviour. As the repulsion pushes the ship away, the ship will steer in an oddly organic manner. The agents reach the point where rejection occurs and then they are pushed backwards and then slowly move around it:

This would make more sense for, say, creature, avoiding a location.

Now, this may be due to the size and distance of the detection. Perhaps making the detection radius much much larger, or seriously offset ahead of the agent. At this point in my experimenting, by the time the agent detects and is being repelled by the spherical obstacle, the agent is very close and the vector of the repulsion simply pushes it back. If the agent and the obstacle are aligned perfectly, the repulsion simply is in the opposite direction to the movement of the agent. - So - Repulsion doesn't really work for the "look and feel" you want for a spaceship or airplane. A different ticked behaviour probably needs to be written.

I was thinking something along the lines of, when an obstacle is detected, try to find the extents of the object (or some other boundary) and find the closest point to avoid the object:


The green line is the direction of travel to the red spherical obstacle, and the yellow and orange are the volumes needed to be avoided.

One factor that I have not put in is forward velocity. Most of the behaviours seem that they can be influenced in all directions of steering - but a flying object often feels best if it doesn't slow down (or doesn't slow down very much) on the local z axis, but steers to avoid obstacles on the local x y. Perhaps by limiting the amount of steering on the z axis, the feel would be better.

The basic idea of this steering concept - that every "tic" being managed by the ticked queue - you poll for a set of situations and then give each a value and then weight that as an influence of the final steering value, is a really good system. Whether the provided steering behaviours will work for this situation, I'm unclear.

Lastly - I too have had an issue with multiple agents all bumping into each other when pursuing the target:


There should be more spacing. They literally bump into each other in a train and slowly destroy each other thru lightweight collisions.

The stage of experimentation I am at leads me to wonder if this is due to weight. Each behaviour has a weight, and perhaps pursuit is too high, and therefore the avoidance steering is too small in influence?

I need to experiment more.

 

Little Angel, excellent writeup. I have the very same issues, although I havent considered creating new behaviours just yet, as for now is just a prototype.

In my case I solved the slow down/stop issue (at least a part) by adding other behaviours; so basically I get the look and feel I want, but not naturally. In my prototype the space for movement is rather small, so was easy to introduce arbitrary steering/force points, but I dont think this would work on a more open space.

If / when I work again on this I'll post my advances. In the meantime, Im paying close attention to any posts on this thread

 

My only real exposure to steering behaviors is from chapter 3 of the book Programming Game AI by Example; I haven't implemented them in an actual game yet. The book covers in detail a C++ implementation of the classic Craig Reynolds steering behavior technique (he's the one that came up with that technique and was behind OpenSteer to begin with).

So this is probably common knowledge among experienced game developers, but my understanding is that you can tweak the values of separation, alignment, and/or cohesion behaviors to control how groups of entities behave. That book also has an implementation of something called a "non-penetration" constraint to mostly keep entities from overlapping.

In terms of having a mechanical vehicle act more like it should, I'm assuming that ultimately you'd want to have the steering force vector drive inputs into a simulated vehicle, rather than use the Vector3 directly. Or even have a middle layer that uses the steering behavior vector as essentially "this is where I want to go" and go through the appropriate maneuvers to make that happen. Like, for a space ship (depending on how your specific game works), you may want AI to be able to rotate toward a target before accelerating, deal with inertia, etc.

 

Here's what the UnitySteer 2.2 example I mentioned looks like, but with a lot fewer obstacles and a lot more kitties:
http://www.stevetack.com/unity/ai/KittiesSteering2D.html

They are set to wander (SteerForWander) and to stay within the center of the scene (SteerForTether). Their obstacle avoidance and neighbor avoidance weights are set high (value of eight), which makes sense.

To make the example work in 3D (and look a bit more like space ships pulling up and diving), all you have to do is uncheck "Is Planar" in the AutonomousVehicle script/component.

Again, this is what it looks like when applying the Vector3 values directly; I'll have to play with using those as inputs to a spaceship controller for a more consistent look, but it's not that bad as is.

 

I've been using UnitySteer for a while now. I've also gone through the examples especially for the SteerForTarget. So far I've not being able to predefine more than one transform target. The idea is that the agent will move one target to another in a sequence manner. How can I achieve this? Should I modify the Vehicle.GetSeekVector(Target.position)?

 

Add a list of transforms to a List<>, then as each transform is reached, simply increment the list to the next transform and set the target to that transform.