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.

DispatchOnSet/DispatchOnChange

We previously saw how to let engines communicate through entity components data polling. 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. That's it, some times data polling is awkward, we don't want to poll a variable every frame when we know that the data changes rarely. 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 hold by these classes must be set or changed. There aren't great examples in the Survival code, but you can see how the targetHit boolean of the IGunHitTargetComponent works. The difference between DispatchOnSet and DispatchOnChange is that the latter triggers the event only when the data actually changes, while the former always.

The idea is that you should always design your engines for data polling and use pushing just for performance as polling every frame could be costly. Any time you use dispatch in such a way you can't replace it with data polling, it's a mistake.