How would you dynamically change a systems function but use the same data?

Say you have a behavioural system for an NPC and depending on some external state the way they move changes...

e.g. A mob or horde will advance or retreat based on the command they are given or the total damage they are taking from an enemy.​

So their HordeMove system has an advance mode or a retreat mode... how would you implement this switching of behviour in one system?
​

I'm presuming that at some point the generation of new data structures for what is a two or more state flip will cost more than being able to change the processing of the System.

Or at what point is it worth using the same systems for multiple actions/behaviours vs lots of systems for each action/behaviour?

 

Normally you would rather change entity component tag, to execute appropriate system.

But to exact answer your question, you simply read value of data in entity, and use switch, or if loop statement.
Nothing special.

For example, one of my modding system is nothing but one big switch statement, taking over 30 enums (and growing), to check condition and executes appropriate action.

 

Won't this have a processing overhead, as you would be creating and moving a lot of data around in memory, as opposed to flipping a switch in the system and branching to a different algorithm or using a differnt function e.g. delegate.

 

If flipping a switch cause the same behaviour change to all entities then that sounds better than tagging all of them.

However the tag component "overhead" can results in cheaper action later on in the case that only subset of entities will receive a new behaviour, since if you have already paid memory movement cost then filtering which one to work on is free, and they became contiguous in memory.

Probably the only way to know is to profile based on each specific use.

 

Providing having same entities on single system, flipping switch will be performant, I presume.
But once you start using multiple systems, you don't want to iterate all entities on each of system.
Hence you do some filtering, reducing number of processing entities, per each systems.

But in theory, you could perhaps write game in a single system, using just switches? (rhetoric question)

 

Well previously I've written different Brain functions as delegates that are assigner per object, and wondered if that would still be a good way to run with ECS and Burst. How high a cost would a delegated function be on a system over thouasands of entities?

It just seems that once you get into a set of Units/NPC with different brains/behaviours then you either end up writing lots of ECS Systems when you could just have one BrainSystem that has fuctions or switch case statements for each type.

I'm assuming that a Behavioural system will trigger other sub-systems as it's state changes and it's the logic of what triggers a behavioural change that will vary between different Unit/NPCs.

 

I don't know why you even need delegates for brains.

But is rather straight forward in ECS, to make brain as one system, where assigned entities are acting as brains. Then you don't need even remove brain components, once brain component is assigned to entities. And your filter is ready.
Now just run your brain system on threads with burst, where associated entities hold relevant value in brain component. That it it.

If you want anything to do with Game Objects, that you need additional tweening mechanism, preferably on separate system, on main thread.

 

So an Entity could not contain a delegate function as data?

 

I am rather skeptical. As ECS would require to reinterpret it, what it is.
I don't think that would be any performant approach. If at all possible.
But someone more experienced would be better, to answer on that question.