Hi,
I'm hoping Apple developers are reading these forums to get their attention.
I was very excited to learn in WWDC 2015 videos about Apple’s new SDK for steering behaviour. The game I recently released uses a library I developed that does exactly that and I was intrigued to see how Apple are going to define the SDK and how good it will be (I’m hoping it will be good in the future). (reference to my library with full sources if interested: Steering Behaviour.
From my experience developing the library this is a tricky subject, especially the tuning aspects of it. To get an Agent to follow a path requires careful setting of the agent mass, speed and acceleration parameters (and in Apple's case, the prediction time). More over, if you want to get a formation of Agents following a path, or following a leader in a specific formation this tuning becomes even more challenging.
Unfortunately, as it stands right now, Apple’s implementation is very, very hard to tune/debug and it becomes unpredictable. For example, I was trying to get an agent to follow an 8 figure and sometimes the agent would complete the bottom circle and continue to follow that circle instead of continuing the path to the upper circle.
Wander is yet another place where I fail to get the desired behaviour. I’m getting movement in the x axis but not in the y axis (getting e-19 values on y axis). If I change the agent rotation value initially, I would get different results for Wander which are hard to explain. I'm guessing there might be a bug there with rotation.
Separation is another challenge, getting NaN values on the position and speed of the agent. This happens when I have 7 agents and I set 1 of they (the leader) to follow a path and the rest to follow the lead while also applying separation. Another question mark is looking at Apple's catalog demo of separation where they used a weight of 500 to 1 for this goal. Really?
Another area of hard to tune/understand the behaviour is with the maxPredictionTime. This is actually a very nice concept that I don’t have flexibility for in my library. This is applicable when you are following a path or trying to intercept or avoid other agents. The idea is to look ahead in time and potentially a) slow down so you don’t miss point in the path (imagine the next point requires a big turn) b) predict where the other agent is going to be and seek to that point. In practice this create another tuning problem.
Here is the scenario: I have a path which has points every ~30 units (this is an 8 figure path). If I use a prediction time of 1.5 second with speed of about 100 units/second I will get the agent to follow an 8 figure that is about 20-25 units inside the 8 figure.
Now what do I do to make the agent follow the path more tightly: Reduce the predication time to 0.5 seconds. Now the agent is right on the path, but the speed drops to about 30 units/seconds. No matter what I do now (raise the acceleration or reduce the mass) the agent speed will not rise to 100 units/seconds. What is even stranger is that raising the max speed, at this point, will also raise the actual speed in some ratio. This behaviour is, probably, tight to the prediction time which makes it very hard to find the right values.
What is my request:
I have an example of a different usage model than what Apple used (the Bot Demo) for this library. It is posted in my blog (reference above) but it is also available in the app store as an example. I really wish Apple's developers can look at this use case and try their SDK instead of mine and tune it to these requirements. I believe this can create a very powerful library. I would move to that library once it's ready and meet those requirements.
BTW, I didn't mention performance, which is very bad at this point, assuming this will be improved without me raising the flag.
