Synchronising and updating actor transforms in Mass Entity performance

Hi Ben,

My apologies for the delay in getting back to you about this. I will try to address all the questions and points you made. If I miss one, please let me know as it was unintentional.

We’re assessing if the overhead of setting up Mass is worth the performance gains, if we only end up with 200 entities max

I feel that the perf increases from Mass may be negligible for running for only 200 entities. You could look at A/B testing to see what the Mass processor setup overhead would be versus just Actors.

Needing Actors for all entities on screen

Would it be possible to add more LOD levels for representation with Actors where you could use more simplified characters for those far away or near edges of the screen? Mass has Low and High by default but more can be added. This should allow for simplifying the meshes and potentially remove some components.

Gameplay capabilities for each character

There has been some work for making navigation more accessible in Mass with a first, and very experimental/rough, draft that will be available in 5.6. It may be useful to either serve as the basis or aid in setting up your own. There are also community versions who have worked on navmesh navigation for Mass entities. We also have been working on Mass StateTree improvements, as well as StateTree in general, which are in 5.6 and can certainly help with StateTree perf. There are also new features such as being able to specify if a task will be used for considering success of a state.

As for using GAS with Mass, it is something we have held very high-level discussions around integrating. The main issue is the current GAS implementation is built around the `AbilitySystemComponent`. There are issues with needing to track the state of the ASC, effects, abilities, and stats persist between LOD changes since Actor representation changes. It is something we have on our radar since GAS is widely used by licensees and Epic internally. I do not have any timeline on when this may get investigated further, or if we will add integration support for the systems.

With all of that being said, it does look like Actors may be a better fit for your project, but 200 full Characters could be quite the challenge with keeping perf at your desired levels. CMC is a heavy component by itself, and I believe Mover 2.0 is working to make it more lightweight. I do not know the full support of Mover 2.0 currently, but there has been work to support AI pathfollowing which I think will be included for 5.6. To use it, you may need to make a translator and update some of the fragments to support having that component rather than a CMC.

-James