Pawn, Controller -- what's the third class?

I have a HoverTank Pawn Blueprint. It knows how to hover, and how to animate its turret/cannon. I want to support multiple different tank chassis with different weapons, so I put as little as possible into this blueprint other than chassis-specific things.
I also have a HoverController, which derives from PlayerController. It knows how to receive input from players that drives the tank, as well as doing things like spawning fired projectiles etc. I put anything that’s largely the same across hovertank types into this class.
But, I’d like to also have an AIHoverController, which uses all the same mechanisms for firing missiles, hovering, applying torque for turning, etc. The only bit I want to swap out is who sends the input – players, or AI.

What’s the right way to structure this? Ideally, I’d want the HoverController to only do player input decoding, and then send off everything else to the controlled pawn, so I can re-use the pawn for AI controlled entities.
But, because I also want a number of different chassis types (that animate differently, have different weapons combinations, etc) I don’t want to put everything into the pawn.

Where do I put all the shared stuff? Controllers expect to be attached to Pawns; Pawns expect to have Controllers; and there’s no obvious intermediary between the two, because my “shared code” needs to look like a controller to the pawn, but look like a pawn to the controller.

I can’t even use that OO cop-out of deep inheritance (which I generally dislike) because I can’t insert my shared code “above” PlayerController and AIController in the hierarchy, where it would “fit” if I wanted to shoehorn this delegation stuff into inheritance.

I’m a super noob so this may not be even remotely right, but would a blueprint interface help in this situation? I only vaguely know how they work so it might not be useful for you, but thought I’d mention it. Good luck.

I was asking the same questions over in this thread of mine, and the answer was Blueprint interfaces.

sorry, I can be wrong, why? I dont see the problem of put HoverController in the top and share commun code soo IA and player Inheritance from HoverController.

btw
my controlles are empty, put the control code in the controllers blueprints sound vintage.
How about put the share control code in a BasePawnHover and create hierarchy from them. P

A base pawn with overrides for variations may work. I have to check how updating components works when deriving from blueprints.

An interface doesn’t really let me share code - I’d have to manually forward to a delegate, which is a lot of plumbing.

Thanks both of you!

Looking into this some more, it ends up being trouble anyway, because the controller should enforce rules (“no missile firing when out of missiles”) which means it has to grab a bunch of state from the pawn anyway, so there’s still some code duplication.
Some simple way of implementing delegation in blueprinting would go a long way towards solving this problem. (Note: interfaces express the possibility to delegate, but does not allow for elegant implementation of such delegation)

Hi, IMO,
You are doing a Feudal oriented object system with controller as King (you cannot missile firing when out of missiles).
But you can try a Anarquist oriented object system, where each blueprint is sovereign of himself, sorry, too much sum in my head), to summarize, IMO this is a weapon business (I cannot missile firing when out of missiles).

I’m not sure I see how my suggestion wouldn’t get around this issue. The event fires off when the controller (either player or AI) sends the ‘Fire Missile’ message. That can be received by the pawn, where your ammo logic can occur, or could call a FireMissile function on an owned ‘Launcher’ (if you broke it down to this point, I mean, for further decoupling, with a separate BP/class for the weapons/launchers), which itself would decide if it could actually fire.