My AI bots are setup to only have 1 task loaded at a time. When the AI wants to do a different task, it loads in the new task and unloads the old. This works fine.
I’m wondering when there are many Bots running at the same time, will this constantly loading and unloading task cause problems?
You can check yourself if it affects performance using Unreal Insights.
But I tell you that it is better to load only once for frequently used things.
How the hell are you doing that task loading thing?
I not using a behavior tree nor a blackboard. Just using an AI Controller. All the tasks are components.
The characters all have a soft reference array of tasks. The AI Controller decides what task to do. Then the task component is load on the character and then executed. The AI Controller then waits for the task to end and then it picks another task. The new task component is loaded and the old task is destroyed.
By doing this, I can make a breathe fire task. I can give it to a dragon a fish and it works great.
The idea is to have very elaborate AI bots that can do many task without carrying all the code
it all depends on if you are creating new segments in memory or not. If you have a pool of tasks that are activated / deactivated or the internals filled depending on the needs then you can do this efficiently as it would all just be in memory manipulation.
If you constantly create and delete tasks => that is where you can run into performance problems.
Thanks for explaining that to me.
Im not wise on how memory works.
I’m loading asynchronous a task component then destroying the component when I’m done with it.
Maybe, when the level loads I can have the game instance gather all the task that are present in the level and load them. Then the characters can get what they need from the game instance. Or just run the code directly from the game instance
Imagine memory as a hotel.
Putting the client’s luggage in the room is the most expensive thing.
If the client is going to stay for a week, it is not necessary to take out the suitcases every day.
In tecnic words:
Allocating memory is expensive.
If you can reuse, or copy, or move the data allocated is better, it is cheaper.
Also:
Memory becomes fragmented just like hard drives.
It is better to have the data together.
If you create and destroy data it will be filled with unused slots until they can be reallocated
That makes more sense.
So if the task component already exist in memory, like on a level manger actor, then adding said task to a character is no big deal as the task was already load on the level manger. Is this correct?
Yes… but do not destroy it until you do not need it anymore
You have to assign the same instance (the same pointer) Otherwise you will be creating the same thing several times.
I would also just add to this that actor components are pretty finicky when it comes to keeping them any where out of the actors themselves. Moving them from actor to actor also costs performance.
This thread also tackles the problem of if you are driving logic in actor components with tick enabled inside of them you will pay the penalty of a single actor constantly evaluating multiple ticks.
I would make a uobject (object) derived class that would get it’s tick update from a central ai manager. Guess it all depends on how complex you want the logic inside of the ai building blocks.
Personally I’d probably start off with state trees as their logic seems a bit more straightforward than behavior trees and already look like an ok system. They are internally optimized.
@br_chickn Do what @3dRaven says, you are in good hands!!
@3dRaven Thank you very much for this information!! 
It sounds like my dream of a character having code for 1 task at a time is not ideal.
Sounds like giving the AI bots all there component tasks at begin play is best.
I am ticking on the the task components. It’s just to adjust a progress bar. I will update the progress bar from the character.
Thank you. Now I have to think until I’m thunk
You have some functions and events to handle damage;
ApplyDamage
TakeAnyDamage
OnActorHit
OnActorBeginOverlap
Use them to give and get damage
Then throw a event (event dispacher or delegate) to Update the Widget (Health bar)
You can do the same for the score.
When my character became full of components (ActorComponents) I started to ask myself the same question as in that post you provided…
I was wondering if disabling the tick would be enough… it seems so… that’s good news.
I was actually considering using raw classes just in case.
With the SceneComponents it is another story
I had to disable a lot of things from the base classes and derive from them.
Sometimes I think Epic should make two versions of Unreal Engine.
One for game programmers and another for architecture and cinema.
In fact, these things make programming games more complicated.
For example lumen… everyone who makes games disables it…
i have no idea without looking at your code, and using insight as proposed.
as a personal general rule, if anything has high churn then it’s probably something that can be optimized. as some suggested with a pool.
you can incur in unnecessary disk load, you risk hitching, you risk fragmenting the memory, mac/ios does no like memory request/free too often or too big (can kill your app), you also risk having issues if at the same time some blocking load happens as it might flush the load (meaning the whole app will stop until everything is loaded), also you make the gc work harder.
i’d go with a pool. or load everytihng if it’s really not necessary to dynamically load/unload.
K.I.S.S.
Scene components have the added cost of transform calculations. If you can pick your poison then actor components are better in that regard as the don’t physically exist on the actor but just just data containers with functions.
Though if it is separate logic then at that point why not go the route of the state tree. The behaviors are basically like actor components, just not stuck on the actor but condensed in the state tree.
They have pretty good visibility
You can have external state trees though
Yes I know… that’s one of the things I set up in my “base optimizers”
bUseAttachParentBound = true; //to reduce cost of transform updates
I made the optimizers so I don’t have to repeat the configuration every time I create a new scene component…
And if Epic changes the properties (as is very common from version to version).
I only have to fix the problem in one place.
Epic software development cycle It’s a pain 
that’s a great option. i’ve been doing that for a while. didn’t knew someone else did it 
I learned my lesson after using a few versions of the engine
