Systems

Systems represent the part of ECS where the actual "work" happens, by overloading the Overseer.update function for a specific System, with the signature Overseer.update(::System, m::AbstractLedger). When updating a Ledger the update function of each system will be called. By overloading Overseer.requested_components, for a System, it is ensured that those components are present in the Ledger that holds the System. Following the ECS design, a System should not hold data except for maybe some settings parameters.

Represents a set of Systems that get executed as steps by calling update on those systems. The steps are a Vector of other Stages, Systems, or a Vector of those. During the update call on a Stage, if one of the steps is found to be a Vector it will be assumed that those can be executed at the same time (see the example). The representation of the steps can be thought of as a very crude DAG.

Example

Stage(:example_stage, [Sys1, [Sys2, Sys3, Sys4], Sys5])

When update is called on this stage, first the update of Sys1 will be called, then 3 tasks will be spawned each calling update for Sys2, Sys3 and Sys4 at the same time. Finally after those complete the update function of Sys5 will be called.

update(system, ledger, args...)

Function to be overloaded for any System which will be called during the update call stack.

update(stage, ledger, args...)

recursively calls update with the ledger on the steps defined in the stage. See the Stage documentation for an explanation of the execution graph.

requested_components(::System)

Function to be overloaded so that when a Ledger is created containing a system, the right AbstractComponents will be added to it.

Examples

@component struct ExampleComp end

struct ExampleSystem <: System end

Overseer.requested_components(::ExampleSystem) = (ExampleComp,)

l = Ledger(Stage(:example, [ExampleSystem()]))