AAIController implementation is too character-specific

[V1nce]

@mikepurvis;637911

I have no problems with other BehaviorTree nodes using the DoN plugin. His FlyTo node extends from BehaviorTree task. I’d take a another look at the AIController, because it is not hard linked with Character.

On the contrary, the blueprint nodes and functions on AAIController that relate to movement have explicit arguments which relate directly to character navigation.
By “character navigation” I mean the navmesh implementation, which is only suitable for character (run about on a flat surface) navigation.

This over-specificity in both the function arguments and the components implies AAIController is not suitable for anything but characters.
Yes, that’s only an implication, but as AAIController is also the lowest level AI Controller you can implement without rolling your own solution it means any extension you make from AAIController will be cluttered (or hindered) by character-specific code.

@mikepurvis;637911

3D space requires a different pathing solution than navigable 2D space. In a perfect world, as a user of the API you wouldn’t know the implementation details of the difference, but honestly if they made the system and handled it a certain way people would be clamoring for it to be either different or more modifiable. AI is always tightly coupled with design in games and there is not a generic solution that will satisfy everyone. That is why there are AI designers and programmers.

There’s already such a thing as a pathfinding nav component, so I don’t see why 3d-space pathfinding can’t be implemented as another nav component. The real question is what interfaces are required by: 1. the abstract pathfinding, 2. the specific pathfinding

As I’m sure you know, there are plenty of ways to write decoupled code so you don’t have specific implementations all over the place, or not enough power. Factory methods to provide request objects that can be used to execute tasks is a simple enough way to side-step enormous or implementation-specific functions.

The trade-off is always a question of DX (how obvious is it that you have to do X to make this system work) and and how much time you can spend doing development ($$$).

@mikepurvis;637911

If Character doesn’t fit your needs, you need to extend Pawn and make your own. AIController works just fine Pawn and subclasses of it. That doesn’t mean you have to throw AIController out and start that from near scratch as well.

No it just means if I extend the base AI Controller, which is AAIController, and implement my own AAIFlyingController, I will have a lot character-specific stuff hanging off the side of my class (moveTo functions) which is in no way the right way to do things.

@mikepurvis;637911

If you do decide you need your own Controller I would not worry about getting off branch from UE4’s. If they ever add a more abstract version, or include 3D navigation you could use it in your next project but keep your system for your current game.

[/quote]

I get where you’re coming from; Yes, I could just roll my own. Yes, I could extend the current one and work around the specifics. but this is not about what I can do, this is about the fact that UE4s AI system starts off being implementation specific and does not allow me the flexibility I desire.

I’m willing to plough my own time into this (so the cost is free), but I need to know what Epic consider the correct direction. I don’t want to put a weeks worth of work into a PR that will never see the light of day because I went against the grain. I merely require some direction as this is such as a low-level system.

Personally, I’m leaning towards making AAIController extend from a new non-character-specific class, and re-engineering the inheritance and cast checks in the BT nodes.
I haven’t tried it out, but I feel this would avoid breaking everyone’s current Blueprints and behaviours (no changes to interfaces) while also opening up the AI system to broader implementations.