Steering handling in Vehicle.update() ignores GameEntity.maxTurnRate

[discordier]

I am currently experimenting in combining goals and steering.
I just stumbled over the fact that steering behavior application in Vehicle completely ignores the maxTurnRate defined in GameEntity.

I wonder if we should make steering in Vehicle aware of the maxTurnRate, as technically a vehicle is a derived class from GameEntity and therefore should adhere to the same constraints?

I feel however that implementing it will break existing functionality, as one can disable MovingEntity.updateOrientation.

So we have currently the following feature matrix (ordered by class inheritance):

Method	maxTurnRate supported	updateOrientation supported	steering supported
GameEntity.update()	true	false	false
MovingEntity.update()	false (problem)	true	false
Vehicle.update()	false (problem)	true	true

• What do you think? How shall we improve the situation?
• What are the long term goals in yuka regarding the classes?
• Shall the various pieces be combinable (change to composition pattern for the entity classes) or, as it currently is, remain inheritance pattern?

[Mugen87]

maxTurnRate is actually only intended for rotateTo(). When implementing the method, I have considered to make maxTurnRate a parameter in order to avoid the impression you could use the property for other things, too. However it seemed more convenient to me if the app could configure the turn rate on entity level.

Maybe clarifying the documentation of maxTurnRate is sufficient for now.

[discordier]

Another way would be to reorganize the behaviors to not "slide" the entity but rotate and move it where possible.
So the steering force would become a "desired direction" and then we would rotate to said direction and move forward.

I am currently trying to throw together an example for moving a car across hills and stumble into issues of behaviors and the Vehicle class.
Currently it appears as if the Vehicle class is only suitable in very narrow use cases and not when:

• any vector has a non 0 Y-coordinate (as it moves in a straight line to the target, defying gravity etc., therefore must be UFO-like)
• the vehicle does not support "in place" rotation and therefore has a limit on rotation radius.

Maybe I am missing something obvious here?

Non the less, the documentation currently is pretty vague about what properties are used for calculation and therefore it would be cool to enhance it. 👍

[Mugen87]

Non the less, the documentation currently is pretty vague about what properties are used for calculation

That's true. Most parts of the documentation mainly describe the class structure but with too less explanations.

the vehicle does not support "in place" rotation and therefore has a limit on rotation radius.

The problem is that the steering model tries to be physically correct whereas non-force based methods like rotateTo() are not. However, there is no problem to combine both approaches in a game. Meaning when the vehicle (or moving entity) stays sill (when it has a zero speed), you can use rotateTo() without issues.

any vector has a non 0 Y-coordinate

That depends on the use case. If you consider FollowPathBehavior, it works fine in 3D space. SeekBehavior works fine if you model something like a rocket.

Keep in mind that games which utilizes navigation meshes, FollowPathBehavior and OnPathBehavior are the most common behaviors. The others are already more specific.

[Mugen87]

Clarified maxTurnRate via bd9d885.