"Force required" is ill-defined about yuka HOT 7 CLOSED

Hi Elias, nice to see you around here 👋

our code is based on a reference from game development. The original C++ code from Mat Buckland (Programming Game AI by Example) looks like so:

//------------------------------- Seek -----------------------------------
//
//  Given a target, this behavior returns a steering force which will
//  direct the agent towards the target
//------------------------------------------------------------------------
Vector2D SteeringBehavior::Seek(Vector2D TargetPos)
{
  Vector2D DesiredVelocity = Vec2DNormalize(TargetPos - m_pVehicle->Pos())
                            * m_pVehicle->MaxSpeed();

  return (DesiredVelocity - m_pVehicle->Velocity());
}

In general, we prefer to work with references whenever possible. Is your code section based on some sort of publication (book, paper, article) or is it a personal invention?

In any event, the engine's current seek behavior worked fine in many commercial applications. I'm afraid I do not yet understand the benefits of your approach. Especially since your code is computational way more expensive. Keep in mind that we are not interested in a physically perfect solution. It's more important to have a compromise of a reasonable behavior and good performance.

from yuka.

Nice to be here too. :-)

You are right that my method is sort of a "personal invention". Not exactly rocket science, but at least discovered independently by me. It is more expensive, but tends to converge fast. I have not proven the convergence yet. I think I would google "Banach fixed point theorem" if I were to investigate it.

The benefit is that the seek hits the target faster. The naïve seek will often spiral around the target because it does not correct for the position consequences of the velocity at the time of each control output. You will notice this if you refresh the page a few times (yeah, I haven't bothered creating an in-app reset) until the random scenario is one where the initial tangential velocity is large compared to the radial velocity and the initial distance is relatively small.

Anyway, a first improvement step, a more conservative one, will be to let seek know what the vehicle max acceleration is, so that it can output a vector of that magnitude, minimizing the position offset given the present method (by shortening the time to impact during which the offset accumulates).

from yuka.

Anyway, a first improvement step, a more conservative one, will be to let seek know what the vehicle max acceleration is, so that it can output a vector of that magnitude, minimizing the position offset given the present method.

Okay, I see now where you are heading. Unfortunately, SteeringManager is responsible to ensure the maximum amount of force a vehicle is able to produce (or to power itself) is not exceeded. By design, single steering behaviors should not evaluate Vehicle.maxForce. So in some sense you hit a limitation of the engine's chosen approaches^^.

from yuka.

SteeringManager would still be able to filter out too large values, but the steering behavior would get some idea of a "budget" for its decision. In principle the simple seek could just output a direction too, leaving to the caller to give as much force to it as it desires, but that would not be ideal, as some other steering behaviors make sense only if they can specify both the desired direction and magnitude (such as the alternative seek I wrote).

BTW, I think the usual source for these steering behaviors is Steering behaviors for autonomous characters, by Craig Reynolds (1690 citations).

from yuka.

We also worked with that reference^^. It's also used by the mentioned book. Compare my C++ code and the pseudo code of "seek" in this paper.

from yuka.

Closing. We stick to the current implementation for now but keep your suggestion in mind. In any event, thanks for your feedback!

from yuka.

No problem!

from yuka.