There's a lot more to cover in terms of configuring or tweaking avoidance, especially DetourCrowd, bit I would prefer to introduce stuff in bite-sized chunks. I haven't tried enabling both on a single AI so I can only imagine what would happen exactly, but since RVO works on movement component level I'd guess it will override whatever DetourCrowd tries to do. The two avoidance methods described here do not work together. Stay tuned for more information on this topic ) These don't cooperate! Alternatively we'll introduce an out of the box AIController that uses crowd pathfollowing. It's the case since there's no way to override Actor's default subobjects in blueprints just yet. As a workaround and due to time constraints, a separate Utility AI graph had to be created and assigned for each AI character.This is curently the only way to enable detour crowd for your project, unfortunately. As a result, however, another class could not be initialized correctly for unknown reasons. In order to instantiate my own utility graph, an attempt was made to derive from this class in C++ and to overwrite some functions. The Behavior Tree uses the UBrainComponent class to instantiate the Behavior Tree graph. Because this graph is not instantiated, all AIs share the same input and evaluation of the graph, overriding each other’s behavior.
In the character controller of the NPCs, a utility AI graph asset can be selected to control the AI. Therefore, the Utility AI system is recommended for selecting a behavior, while the Behavior Tree can be used to implement and execute the selected behavior. This made the implementation of more complex behavior confusing and time-consuming. While the behavior (the actions) of the AI was selected by the utility AI system, the actual implementation in the game world was implemented exclusively through Blueprints (and sone C++ exposed functions). The goal of the game is to sneak or fight your way inside a castle, steal the guarded crystal and drop it off at a specified location. The player can do stealth, ranged or melee combat. To enable a fun small game to test the AI, a small RPG system was implemented. The strength of the Utility AI system is the selection of a possible behavior, while the execution of the selected behavior can be more easily defined by a Behavior Tree. Through the implementation of the Utility AI system in Unreal Engine, it turned out that a hybrid of this approach and behavior trees can achieve an optimal result. The decision represents an actual function in the game world, e.g. If an action is selected, then the decision associated with this action is executed. The optimal action that has achieved the highest action score is therefore getting selected. This enables a comparison of all possible actions. The input values of the considerations are normalized, the output of the considerations is multiplied and results in an action score. Possible considerations for ranged combat are the distance to an opponent or the number of arrows. An action consists of any number of considerations, which has an influence on the probability that the AI chooses this action. An action defines a possible behavior of the AI, for example ranged combat. These can be defined intuitively by a game designer. The Utility AI principle allows the definition of actions, considerations, and decisions. In behavior trees or state machines, only one consideration is often considered before moving on to the next one in a fixed order. 
The selection of a behavior with this method is often binary, the behavior tree can quickly become complex, and the definition of different behaviors is therefore unintuitive. The possible decisions of an AI are represented by selectors and sequences in a behavior tree.
0 kommentar(er)
