It’s no secret we’re working on our own game, and as you can expect that takes priority over other concerns, so I wanted to address what that means for the feature support in UnitySteer. The short answer is that I’ll continue to develop it, but its features and direction are being dictated by the needs of our game.
Take for instance path following. SteerForPathSimplified was meant mostly as a demo on how to build path following behaviors. It was a quick and dirty implementation, following on the steps of the other two examples, used to showcase usage of the pathway methods to calculate your agent’s position in a path. It has some obvious deficiencies, the main one being that it does not particularly aim to stay within the pathway’s boundaries.
How did that play on our end? It allowed me to prototype path following on our game, which I could then replace with a different drop-in path following behavior down the road, the same way I moved from the basic SteerForNeighborAvoidance to SteerForPotentialField (which I’ll discuss in a future article) and from then on to our current approach.
However, people started using it as is, which I should have expected – it’s there, so why not? – which has brought to my attention some small issues on cases that didn’t appear on my test scenes. This is a side effect of it being used mostly for prototyping on my end. I expect I’ll do a full replacement in the near future, with a proper implementation, but meanwhile I suggest you keep your eye on the development branch where I’ll be uploading the small fixes. If you encounter any oddities, do let me know with a small sample case and I’ll do my best to fix any bugs, but I’m tied up between the game and an on-going client project that should keep me occupied for the next 3-4 weeks, so don’t expect any major rewrites during that time.
On other news, the more I experiment with alternate approaches, the less happy I am with three particular bits of UnitySteer.
The first one is the default SteerForNeighborAvoidance behavior. It works fine as a sample case, but movement lacks a certain elegance of other approaches I’ve tried so far. For much more reasonable approaches, I recommend you visit Mikko Mononen’s blog Digesting Duck, particularly his articles on Detour Crowd and the navigation loop presentation.
Then there is the issue is that the final movement vector is the weighted average of the various forces acting on the vehicle. To understand what this means, suppose that a vehicle has two steering behaviors: SteerForPath and SteerForNeighborAvoidance. In that case, its final vector will be the weighted average between both, which requires a good degree of tweaking to get working right. That was fine at first, and it does work on the general cases, but now that I’ve got a ton of agents running around on constrained areas it’s not ideal. What would be best is to use a neighbor avoidance behavior as a sort of post-processor which corrects the previous behavior’s vector, instead of blending in with it.
Finally, UnitySteer vehicles look at the world in terms of an immediate force vector, not of a desired position. This is a subtle distinction. It means that since AutonomousVehicle’s view of the world is I want to move in that direction, not I want to reach that spot.
So what? Suppose you have an agent which pathfinds to a destination and then, having reached it, stops. Then another vehicle comes hurtling towards him. It would be ideal to have the first one get out of the way, which I can do with the current field behaviors I’m testing – however, the agent then won’t know where it was supposed to be so it can return to its spot, because the AutonomousVehicle was only following the forces that took it there and the path following behavior is no longer contributing any force.
It’s very possible I’ll soon do an experimental branch on github for these changes. While you’re welcome to play with it, I suggest you hold off integrating it into anything even closely related to production, as its details are likely to change often.