While working through the plans for this next release of OctoberProject (dropped item entities, projectiles, and more mob types), I realized that fitting things like items and projectiles into the existing CreatureEntity system may not be appropriate.

On one level, these should be considered the same, as they are entities which can move in the world and have various kinds of collision logic.

However, this doesn't quite fit for a few reasons. First of all, they have no active movement (no AI, only motion due to gravity) and potentially only 1 kind of active decision (to damage something when colliding, for example). Second of all, they have no health, breath, or a normal sense of facing direction (not a bad things but makes the fit seem not quite right). Third of all, other things don't interact with them the same ways (you don't bump into or act upon an item sitting in the world, the way you would a mob).

So, now I am thinking that maybe these should be considered as a completely different kind of entity, probably not even in the same namespace (as they don't even map nicely into the PartialEntity client-side concept).

While this would probably be ok (it would be a non-trivial amount of work - but probably easier than a non-trivial collection of special-cases), it does have an interesting implication: Performance. This is yet another collection of small parallel tasks.

For a while now, the structure of the core parallel logic engine has started to feel... poorly oriented. That is, the threads each pick up an entity, then each pick up a cuboid, and then the merge logic combines all the results from these threads in order to build the snapshot for the end of the tick (thus creating the materials for the next tick). While this works, I wonder if this is inefficient as the threads pick up work with no real plan beyond wanting to complete all of it. This means that their own data caching is not as useful since each work unit might be completely unrelated and they might pick up the heaviest work item last (thus starving the other threads and delaying the end of tick), not to mention the thrashing around the central atomic counter in order to pick up work units which may be too small. Also, it means that all the work of combining these elements must be done in the single-threaded merge path.

It got me wondering if maybe all players and creatures should be associated with a cuboid, meaning that the work units are larger, there are fewer of them, and they would make better use of the per-thread data caches. Further, I started to wonder if the unit should actually be cuboid columns, thus further improving cache density while also allowing the per-column data merging to happen in the parallel logic, not the single-threaded merger (well, some would still be here). When looking at how to introduce things like dropped items, this seems like even a better idea since still fewer small work items would be required.

This change to larger work units would pretty much require that some sort of "processing cost hint" be introduced so that the heaviest work items are picked up first, resulting in better work distribution. Of interest is that much of this hint could be derived from the now-parallel column result merging (everything except for input from players or entities/actions delivered to a different column).

Another up-shot is that this may mean that EntityCollection could use this cuboid-based entity segmenting to scale better than walking the entire collection to find something (or needing to create some special look-up index based on locations).

This would also improve the logic of what to send to the clients as the entities and cuboids would be tied together instead of being multiple data sets with largely-redundant selection logic. As an aside, I have also wondered if the per-client network scheduling (or at least prioritizing) could be done by this parallel path, as well.

It is a pretty big change, and does move some logical responsibilities around within the design, so it will require some thought, analysis, and implementation time.

Still, the more I think about this, the more I think it is inevitable and doing it now might simplify these new entity types.

More thought required,
Jeff.