Question About extending AI Behaviour tree and blackboard

[IkoLogs]

Hi

Am a bit new to unreal framework .Following your docs to setup new project.

For all classes your doc says to derive from RTS class , and was happy with that.

But then i got to this steps

8)Set the Pawn Behavior Tree Asset of the new pawn AI controller to BT_RTSPawnBehaviorTree. 9)Set the Pawn Blackboard Asset of the new pawn AI controller to BB_RTSPawnBlackboard.

So my question here is what is your recommendation for specialising the behaviour tree and blackboard, regards what fits best to your framework.

Should we edit BT_RTSPawnBehaviorTree, BB_RTSPawnBlackboard to extend /specialise .

Or do you have some other idea as to how you expect users of RTS library to extend the design.

Thanks

[coolyoshi]

@IkoLogs

Interestingly, the ue4-orders-abilities repository has a lot of useful code and seems more up to date than this repo. I actually ended up merging that code with this one.

One way of extending it seems to be separating each order into it's own tree. Can check out an example on line 80 of this file: https://github.com/DaedalicEntertainment/ue4-orders-abilities/blob/develop/Source/OrdersAbilities/Private/Orders/RTSCharacterAIController.cpp.

Namely, the line "UBehaviorTree* BehaviorTree = URTSOrderHelper::GetBehaviorTree(Order.OrderType.Get());".

Then for each type of order, we have to fetch the behavior tree we want in the constructor I guess. For RTSMoveOrder.cpp, I just did it like this:

URTSMoveOrder::URTSMoveOrder()
{
    TargetType = ERTSTargetType::LOCATION;
    bIsCreatingIndividualTargetLocations = true;

    TagRequirements.SourceBlockedTags.AddTag(URTSGlobalTags::Status_Changing_Immobilized());
    TagRequirements.SourceBlockedTags.AddTag(URTSGlobalTags::Status_Changing_Constructing());

    static ConstructorHelpers::FObjectFinder<UBehaviorTree> obj(TEXT("BehaviorTree'/RealTimeStrategy/AI/BT_RTSMove.BT_RTSMove'"));
    if (obj.Succeeded()) {
        UBehaviorTree* btree = obj.Object;
        URTSOrderWithBehavior::BehaviorTree = btree;
    }
}

[npruehs]

Actually, for A Year Of Rain, we ended up blueprint'ing all orders, and assigning Behavior Tree references in these (data-only) blueprints. Then, our player controllers referenced these order blueprints instead of the pure code versions. Hope that helps!

[coolyoshi]

@npruehs I'm not sure if I might've misunderstood, but what was the reasoning behind shifting to blueprints? I got to a point where I was wondering how I would manage all these individual behavior trees and that got me contemplating whether I should utilize the "RTSOrderHelper.cpp" found here: https://github.com/DaedalicEntertainment/ue4-orders-abilities/blob/develop/Source/OrdersAbilities/Private/Orders/RTSOrderComponent.cpp. Hmm it does seem pretty useful. Do you think this is a good idea or would you recommend shifting to blueprints as well?

[npruehs]

Not sure whether I understand your approach :) We needed some way of linking the orders to their respective behavior trees. We didn't like FObjectFinder, because it introduces a runtime dependency on the behavior tree that the engine doesn't know anything about - it doesn't show up in Reference Viewer, isn't automatically included in builds etc. So we opted for blueprint'ing the orders, allowing us to use the Unreal Editor to assign the behavior tree references.

[coolyoshi]

Ah I see, makes sense! I didn't really consider those downsides of FObjectFinder.

When you mention opting for blueprinting the orders, does that mean you ended up not using files such as "RTSOrderHelper.cpp" and transferred that logic to blueprints? Or you just blueprinted the part of code that provides references to the behavior trees?

[npruehs]

Just the latter :) The blueprints were mere data blueprints, with references to the behavior tree assets. All logic was still part of UI widget blueprints, behavior trees and C++ code.

[coolyoshi]

Okay awesome thanks!

[npruehs]

I'm closing this now, for tracking purposes. Feel free to re-open in case you've got any follow-up questions!