To shift toward a more declarable action/job/system execution, we are moving toward isolation and descriptor based. It will allow us to move toward more parallelism as the constraint will follow the action/job/system model. Although the ModelActionX instances are more verbose, they fit nicely with our future work. It also allows us to abstract away how the jobs declare their constraints.
A quick note on the action/job/system model. Given the internal is closely related to an ECS design, we need to express the System better. At the moment, this aspect is non-existent. The system allows a certain ordering in the rule executions. The Job is what can be scheduled in parallel. It contains the constrain on required components and is executed for each matching entity. Finally, the action is what the developer writes. We are considering making things easier by declaring mutability and some unpacking strategy so we don't always have to deal directly with components/component references.
To shift toward a more declarable action/job/system execution, we are moving toward isolation and descriptor based. It will allow us to move toward more parallelism as the constraint will follow the action/job/system model. Although the
ModelActionX
instances are more verbose, they fit nicely with our future work. It also allows us to abstract away how the jobs declare their constraints.A quick note on the action/job/system model. Given the internal is closely related to an ECS design, we need to express the System better. At the moment, this aspect is non-existent. The system allows a certain ordering in the rule executions. The Job is what can be scheduled in parallel. It contains the constrain on required components and is executed for each matching entity. Finally, the action is what the developer writes. We are considering making things easier by declaring mutability and some unpacking strategy so we don't always have to deal directly with components/component references.