In all of my tests/projects with DOTS so far, I’ve very often ended up having to fallback to IJobChunk because I required a job that operates on more than 6 component types. Are there plans to generate “IJobForEach_EBCCCCCCCCC” and so on? Not sure about the technical implications of this (if it would make the codebase size completely explode or not). Maybe an on-demand IJobForEach codegen tool could be nice if we ever need more components/buffers?
There are times where I could combine several components into one in order to reduce the required component count, but that means there’s a price to pay in performance, modularity and clarity. (a lot of other jobs may not need all of the data in that big combined component). I don’t really want to end up with a component called “HealthButAlsoPlayerInputs”
I also haven’t tried the Entities.ForEach much, so I dunno if this solves that problem
It’s been rare I’ve needed more than six component types in a single job, but when I do I just access them via ComponentDataFromEntity within the job. I always make sure that I have RequireComponentTag or WithAll<T> specified so I do not need to do an existence check when accessing them within the job. Performance has rarely ever been an issue with this approach, and if it has I do the next approach.
Alternatively split your jobs up more so you don’t need to access as much, or have jobs that calculate intermediate data for a later job to consume. For instance my utility AI system uses a job to collect and calculate various metadata about entities, stores them in intermediate NativeArrays, and then the followup job does the real work. That followup job really only needs a couple component types at that point because the collection work was done by the first job.
I also don’t make my component data extremely granular, often preferring them to use “feature flag” enums to combine optional but conceptually related data into a single struct. For instance, I don’t separate mana, health or armor into different component data, and as they are each optional any logic using them just checks a enum StatType : short bitmask field to see if the entity has one or the other.
Entities.ForEach lets you go up to 8, and also with a bit more flexibility. (like it’s fine if you want to use 8 dynamicbuffers.
if you want to go totally rambo I think you could trick the entities.foreach compiler into doing more if you make a custom delegate, and provide a .ForEach overload like the ones in Packages/com.unity.entities/Unity.Entities/CodeGeneratedJobForEach/UniversalDelegates.gen.cs
the reason we’re restricted to 8 is that we need to generate a custom delegate type for each combination, and there’s a balance between “phil wants 9” and “all tools / IDE’s start running a bit slower because there’s more types to scan/autocomplete against”.