The title has been deliberately written to match that of Final Fantasy: The Spirits Within. With that taken care of, let me focus on the Unreal Engine part. Within is a class specifier for Unreal Engine C++ UCLASS() macro. The official documentation is like so
Within=OuterClassName
Objects of this class cannot exist outside of an instance of an OuterClassName Object. This means that creating an Object of this class requires that an instance of OuterClassName is provided as its Outer Object.
A use case is
UCLASS(Within=STWeapon)
class SUNOVATECHZOMBIEKILL_API USTWeaponState : public UObject
{
GENERATED_UCLASS_BODY()
...
}
where class ASTWeapon is defined like so
UCLASS()
class SUNOVATECHZOMBIEKILL_API ASTWeapon : public UObject
{
GENERATED_UCLASS_BODY()
public:
/**
* @brief Getter for the Owner of this inventory
*/
ASunovatechZombieKillPawn* GetSTOwner() const
{
return STOwner;
}
...
}
Now the GetSTOwner() can be accessed via following code in USTWeaponState
A shalok or verse, from Geeta, that is known to many Hindus, or the gist of which gets reflected in our actions (I am a Hindu) anyway, is the representation of iterative theme, of course, coupled with a right action mentioned above. The meaning implies that Shri Krishna takes birth in an epoch, time again, whenever there is rise of evil, to establish law and order.
Unreal Engine has a way of iterating over the C++ objects which has been used in hundreds of AAA games covering a stretch of couple of decades.
The iteration is done like so
for (TActorIterator<AActor> ActorItr(testWorld); ActorItr; ++ActorItr)
{
// print name
KR_INFO("Iterating over actor: {0}", (*ActorItr)->GetName());
}
The TActorIterator template is defined here. The pseudo code for iteration roughly is
Initialize ActorList with the appropriate UObjects (of a world or editor relevant objects for instance) of cached objects.
Appropriately define (overload) the increment (++) operator with desired class filters and appropriate checks
A fruitful thing is to think what remains constant and what doesn’t in this way of iteration, which in turn defines the concept of iteration.
Delegates are user defined datatypes that can be bound to C++ function(s) (or blueprint event(s)) of an object in a generic way. This means that the object need not be even declared for a particular delegate. Let me demostrate.
This just tells the Engine that we are declaring a user defined datatype (a delegate) which can be bound to a C++ routine with two parameters of type float. Now this delegate can be bound to any member function (with signature void (float, float)) of any object.
Finally, we observe the application of the delegate here, like so
void UTP_PickUpComponent::OnSphereBeginOverlap(UPrimitiveComponent* OverlappedComponent, AActor* OtherActor, UPrimitiveComponent* OtherComp, int32 OtherBodyIndex, bool bFromSweep, const FHitResult& SweepResult)
{
// Checking if it is a First Person Character overlapping
ABPToCodeDemoCharacter* Character = Cast<ABPToCodeDemoCharacter>(OtherActor);
if(Character != nullptr)
{
// Notify that the actor is being picked up
OnPickUp.Broadcast(Character);
// Unregister from the Overlap Event so it is no longer triggered
OnComponentBeginOverlap.RemoveAll(this);
}
}
This basically translates to the meaning that when the overlap detector of the pickup detects, well, an overlap with player’s character (no pun intended), then notify all the registered events (bound to OnPickUp variable of type delegate defined above) and run the appropriate logic in their respective classes.
The blueprint equivalent of registering event by binding to OnPickUp delegate (.AddDynamic()) is like so (Bind Event On Pick Up node)
The blueprint equivalent of
OnPickUp.Broadcast(Character);
is Call On Pick Up node
A nice property of the delegates is that they can be used in appropriate arbitrary classes (mentioned above). Look at the call to Binding Delegates node, which is a function of class ABPToCodeDemoCharacter (which is not declared or defined where the delegate is declared). The function is defined like so
We can see that an event AnEvent is bound to OnPickUp in the class even though OnPickUp is not declared/defined in the class. The event is like so
Either Unreal Engine 5 AI has become more intuitive or I am spending right time with the AI. Recently I made a zombie game first person shooter prototype with UE 5.4.4. The natively playable prototype binaries can be found at this GitHub page (available for Linux, Mac, and Windows). But, as with several different software, the versioning usually, in some sense, can make it non-intuitive.
Disclaimer: This is not to imply that what follows, the concept of Observer Aborts, is an example of different implementation with different versions of UE. From forums it seems like, but I am not sure.
The story starts with the following image
If you are new to Unreal’s behavior trees, might I refer to here, here, and here. We are interested in the BT_ZombieBehavior window containing the behavior tree for zombie AI. Clearly, as per the decorator in Sequence node (third level from ROOT), the Move To task shouldn’t be executed if Target Enemy (query key) is not set, meaning set to NULL.
This wasn’t happening practically in the game. The zombies were still moving towards the player (chase mode) when Target Enemy was not set. Native logging verified that this is case. Now, following my friend’s noble advice, on doing some forum reading, I stumbled upon https://forums.unrealengine.com/t/ai-blackboard-based-condition-does-not-abort/511343.
Based upon the observation in the forum thread, consider the following image
All we have now is to understand the purpose of setting the field Observer Aborts to self in UE 5.4.4. For that we refer to official UE documentation page. The page mentions that setting the field to Self, aborts self (node) and any subtrees, which is Move To task in this context, running under the node. This means that even if Target Enemy is NULL, Move To task is being executed with whatever Target Enemy was set earlier and, if the task is not completed, AI won’t halt the zombie, leading to an infinite pursuit, even when the pawn vehicle is out of sight.
Upon further forums’ reading, for instance this, seems like an optimization (caching?) for changing decorator conditions, which probably is our case, for re-evaluation of “if Target Enemy is set”, which updates appropriately if Observer Aborts is set to self.
Extra Credit
If you have been observing pedantically enough, in the second level from ROOT, Selector node has been replaced by Sequence which, in practical sense, is a mental exercise only. In this context, there is no practical difference between them. Because, when using Selector (at second level), until the Move To task is completed, the behaviour tree control won’t go to the Sequence with BTTask_Halt child, unless the Target Enemy is set to NULL, in which case, Move To task will be aborted, moving the control to the parent of halt task.
Even simpler version of behaviour tree, in this context, which gives the same result is like so
Since self abort stops the execution of Move To task, BTTask_Halt, which essentially sets the MoveTo actor to NULL, has no need. Probably self abort does that already.
This is the final blog-post of the series (for previous parts see here and here). As promised, here we will see the implementation of Reinforcement Learning through Behavior Tree (in natural Unreal Engine environment). The method written is fairly general and can be used to generate BT corresponding to any RL based algorithm.
The k-armed bandit (which for our case turns into shooting colored boxes) algorithm can be categorized into 5 tasks.
Select a box (based on probabilities and estimates)
Rotate towards box (for more complex, locomotion may be involved)
Shoot the box
Wait (for reward assesement)
Update the estimates
The tree built with this categorization of the tasks is shown in figure
The Engine also provides an powerful interface for Blueprints to interact with C++. This is a good way to unify the artistic and programming development of a game. We will show that in real time here.
Consider the task BTTask_FindAppBox node. The Blueprint implementation is shown in the figure
In the Engine, every BT task starts with the node Event Receive Execute AI. So we start with that and make the connection to Cast node yielding the object corresponding to class MAIPlayerController. Once that is done, we invoke the C++ method through the node Look for App Box and by setting the target pin as the casted object. The C++ method is posted here.
Similarly rest of the three tasks (except the Engine default task Wait) are implemented through this C++-Blueprint interface. Another example is BTTask_UpdateEstimates
Ravi Mohan 