That’s quite a big topic… Assuming you’ve read the docs and looked at the examples already, but need a different perspective…
First off, the architecture is very open-ended, and just as with many other systems in UE there are hundreds of different ways to skin the proverbial cat. You don’t necessarily have to use any of those components to make game AI, but they’re very useful since any non-trivial system is going to end up needing something very similar to what they offer anyway eventually, so you might as well use them right away.
- Behavior Trees make decisions based on available data, and that data is usually provided by a Blackboard.
A classic example would be an AI that follows some predetermined route until it finds an enemy to attack, at which point it leaves its route and runs off chasing the enemy actor. The ‘enemy’ would be represented by an object key in the blackboard, and the tree would use a Selector that either leads to a patrolling sequence or a chasing sequence based on whether or not the object key is set to a valid actor or not. That value itself could be set/cleared by any means available: a service running in the tree looking for enemies, a PawnSensing/AISense component on the AI Pawn triggered when an enemy is visible or makes a noise, some routine ticking away in the AI controller, or anything else you can come up with as long as the blackboard key value is ultimately set or cleared when necessary.
The purpose of the Blackboard might be a bit obscure at first, but just think of it as a shared set of variables that the pawn, the controller, and the behavior tree can all access easily without having to expose any special properties or methods. It’s just sort of there as a floating data host that all linked AI components agree upon as being the information source of choice.
- AI Controllers are used much like PlayerControllers to possess pawns, but are driven by input from game logic rather than mouse/keyboard/gamepad.
They can be really simple, limited to setting up the blackboard and starting the behavior tree, or they can be very detailed and truly simulate a human player by sending input events to the pawn. It’s up to you how you want to run it. Deciding what parts of the logic to put in your controller and what parts to put in your pawn is largely a coin-flip in a lot of cases, so just pick a convention and stick to it. Personally I like to use the controller as a buffer between the pawn and the blackboard/behavior tree, so the pawn can communicate with the controller, but it cannot talk directly to the BB/BT, yet the BT can run tasks targeting the pawn.
- NavMesh and EQS are the bits missing from your list.
If you want to be able to send your AI unit to some specific location in your level, you’ll probably want to use a NavMesh (assuming the AI is some type of ground unit walking/driving/crawling on solid objects). Once in place, it lets you call AI methods such as ‘MoveTo’ on your pawns, making them find a suitable path to the target. This is where EQS comes in. Sometimes you need data that cannot easily be obtained without some high-level environmental awareness, which EQS provides. It can be used for things like “find the closest location, in the navigable area, that is x units away from the enemy’s current location” or “find a location that is as far away as possible from this nuclear bomb, preferably inside a lead-lined fridge”. The answer can then be used for a simple ‘MoveTo’ task to make you AI run over there.
In summary, it’s a lot of stuff, and the only way to really get to grips with it is to start using it hands-on and make lots of experiments. I find that you can’t really internalize the full depth of these systems just by reading about them or looking at tutorials - you have to work with it, make a lot of mistakes, etcetera, until it really sinks in. Just start with something ridiculously simple, then build it up bit by bit.