Inevitable Random Access

[waxen hill]

Assume we have 200 AI Agents, each as an individual Entity with the same archetype. There is always a case where one Agent might need to interact with another arbitrary Agent. Now assume every agent can invoke an action on any other agent through an event. As the system gets more complex, we divide AI Agents into more sub-entities (AIEmotion, AITrait, AIProperty...etc), but it seems that communication between any two arbitrary entities is inevitable.

My questions is:

for the related entity, especially in this 1 to 1 case, should we still use SystemAPI to query this entity or just keep an Entity inside related Entities? I saw in the MegaCity and NetRacing examples, for this low-frequency job, they just store the Entity inside a component. But what if the system has a lot of low-frequency work which all need random access (take 10,000 random access lookups separated in 30 frames), https://www.youtube.com/watch?v=KuGRkC6wzMY&t=1276s, like the Write relationship in this talk, is this structural change and random access approach still the best practice in large scale?

[warm temple]

for 200 it probably does not matter

[waxen hill]

Sorry for the confusion. When transitioning from OOP to ECS, we started with 200 entities. As our system grew, these expanded to 4,000 entities(maybe more in the future), each with a complex 5-step process(with in aSytemGroup) involving random access and ECB writes. As the project scales, is this approach still viable, or should we consider alternatives for larger projects?

[warm temple]

With ComponentLookup (if it is readwrite) you can`t use a parallel job. Probably not a good idea with a lot of entities

[rapid mural]

I was in a similar boat where I prioritized granular design over ECS design. The result was bloated and slow code with far too many ComponentLookups. Instead, consider having all AI logic in one job, with heavy usage of #region and partial classes to make the code easier to read. When interacting with other agents, I assume you would only have agents interact with others based on spatial proximity? In that case, you can implement a simple spatial partitioning to grab agents close enough to the actor agent. Then, for interactions like Damage, Notify, Stun, etc, write events to a parallel queue within your parallelized master AI job, and process those events on a single job right afterwards. The result is a fast parallelized AI job with no component lookups, and a small single threaded job using lookups. Only downside is that you need to make heavy use of #region, partial classes, and other means of mitigating massive classes

Using this design I am able to run 4000 agents in a Rome Total War style battle game at around 4ms of 8-core CPU (though the AI code looks unwieldy!).

Also, if you decide to implement a spatial query, your mind might jump to a NativeMultiHashMap mapping int2 coordinates to a list of AgentProximity structs. Problem is, NMHM elements have O(n) access due to its skip list implementation! So you must implement your own optimized form. Basically, build the NMHM, then use it to create a NativeHashmap mapping int2 to an int, and use that int to access a flattened NativeList which contains all the elements of an int2 bucket but they’re right next to each other for O(1) access. You’d also need an accompanying NativeList that holds the indices of these contiguous element lists. Yes, you’d have to rebuild the NMHM and also your optimized form every frame, but the payoff is that you can make huge numbers of spatial queries at next to no cost

[waxen hill]

Great, thanks!
That's precisely my concern.
I believe it's also a common question that someone transitioning from OOP to ECS would encounter after going through all the basic documentation.
Your case and solution suggest that I might be using an incorrect design pattern to handle all these AIAgents.
Perhaps I'm still approaching the solution from an OOP perspective.
I'll take some time to redesign the structure and will update this thread if I figure it out.

[rapid mural]

Yeah, I was constantly warned by other people here that I was also still in an OOP mindset. Regarding your question about AI Design in DOTS, I made a forum post that could be of interest to you https://forum.unity.com/threads/dumbgoap-ai.1470292/ since your seem to be developing a huge-scale RTS game