Svelto.ECS and OOP abstraction

To be able to use ECS purely, the underlying engine must be written using the ECS paradigm too. Unity is moving toward this direction, but alternatively one could theoretically write with Svelto.ECS and C# a complete game engine. Until this is just theory, we will need to interact with OOP based libraries. This interaction can happen at least in two ways, the first one being the use of EntityViewStructs and Implementors. The secondo being more advanced and discussed in future.

When Svelto.ECS is used with Unity, Implementors are always Monobehaviours (there are rare exceptions). Implementors allow to see monobehaviours data as if it was data oriented, however Unity also communicate through monobehaviour callbacks and in this case DispatchOnSet/Change is used:

DispatchOnSet/DispatchOnChange

DispatchOnSet and DispatchOnChange are the only references (not value type data) that can be returned by entity components properties, but the type of the generic parameter T must be of value type. The function names sound like event dispatcher, but instead they must be seen as data pushing methods, as opposite of data polling, a bit like data binding works. DispatchOnSet and DispatchOnChange cannot be triggered without a data change, this will force to see them as a data binding mechanism instead of a simple event. Also there is no trigger function to call, instead the value of the data held by these classes must be set or changed.

Examples (check the hitChange entity component field):

• https://github.com/sebas77/Svelto.MiniExamples/blob/bac35a799304444a35422be569e1285fca0eb8c2/Example2-Survival/Assets/Code/ECS/EntityViews/Components/EnemyComponentInterfaces.cs
• https://github.com/sebas77/Svelto.MiniExamples/blob/master/Example2-Survival/Assets/Code/ECS/Engines/EnemyEngines/EnemyAttackEngine.cs
• https://github.com/sebas77/Svelto.MiniExamples/blob/2cfe6fa1b65acd9fb61712c04d70b58580203451/Example2-Survival/Assets/Code/ECS/EntityViews/Implementors/EnemyTriggerImplementor.cs

It's clear how the Monobehaviour is never known directly by the engine and how the OnTriggerEnter/OnTriggerExit Unity methods are still used to communicate with the Engine that has the responsibility to handle these events. Note that only this engine can handle these events and you would notice it as the way these classes are designed, won't allowed to be used in more than one engine.

In order to understand how to take your OOP mindset to ECS it would be really beneficial to read all my theory based articles:

• http://www.sebaslab.com/ioc-container-for-unity3d-part-1/
• http://www.sebaslab.com/ioc-container-for-unity3d-part-2/
• http://www.sebaslab.com/the-truth-behind-inversion-of-control-part-i-dependency-injection/
• http://www.sebaslab.com/the-truth-behind-inversion-of-control-part-ii-inversion-of-control/
• http://www.sebaslab.com/the-truth-behind-inversion-of-control-part-iii-entity-component-systems/
• http://www.sebaslab.com/the-truth-behind-inversion-of-control-part-iv-dependency-inversion-principle/
• http://www.sebaslab.com/the-truth-behind-inversion-of-control-part-v-drifting-away-from-ioc-containers/
• http://www.sebaslab.com/the-quest-for-maintainable-code-and-the-path-to-ecs/