Help me understanding Svelto ECS

Started by
3 comments, last by DemonDar 7 years, 9 months ago

So far I have downladed this new ECS framework and runned the example successfully, I've been following the blog of its author and readed all blog posts related to ECS and IOC from 2 to 10 times. But I'm still missing something about Svelto ECS,

I really like the idea of the author of storing the events inside entities, however I don't get what Nodes are and how should I introduce the concept of nodes when designin Entities and components,

In old-fashion ECS systems I do just design entities made of components, and I refine what components are needed until I get to a very essential set, then I design systems, I polish, I eventually change entities and so on..

But here we have nodes, how do Svelto know wich Implementors to instantiate inside each Node? and how do I design that?, seems that partially the design of the framework was done to workaround Unity3D design issues, however I feel I'm missing something essential that goes beyon the mere Unity3D design and the fact of storing events inside entities. I've been on the issue weeks, so I don't expect a quick answer (unelss of course you already use that framework or you are the author )

the gituhub link:
https://github.com/sebas77/Svelto-ECS

Advertisement

<disclaimer>I have not used this framework and I have not used Unity either, so I could be way off base here.</disclaimer>

Through the github link you provided I found this article: http://www.sebaslab.com/ecs-1-0/

And the key phrase in there seems to be this:

Nodes are a way to map Components inside Engines

It then goes on to elaborate on that in more detail.

Having read it myself I think I have an understanding on the concepts being discussed. So here's my explanation to you:

It is common for "systems" (or "engines" as they are known here) to need to access multiple components per entity. For example an EnemyEngine might need to access a Health component, an Ammo component and a Positioning component. This creates at least a 1-to-many relationship between Engines and Components. (In fact once you share components among several engines that turns into a many-to-many relationship - but only the 1-to-many side of it need be modeled).
Their solution to this problem is the Nodes concept. They represent that 1-to-many relationship as a Node object and that object might hold several components within it. Then they simply have a 1-to-1 relationship between Engines and Nodes. It also means an Engine need only manage a single object which fully embodies the relevant aspects of an entity.
Going further, I would imagine that a Node could slightly abstract over the components if it so wished. For example an EnemyNode might have a shoot() method which deducts from the Ammo component and uses the Positioning component to decide where to spawn a bullet entity. This provides a higher-level and more engine-specific API for the EnemyEngine to use, rather than it having to dig in and drive the components directly. Now the EnemyEngine can concentrate on just the AI logic itself and the menial details of keeping components in-sync is offloaded to the Node concept.
That's my take on it anyway. Hope it helps.

thanks that makes much sense. but then how are implementors mapped to nodes?, it should handle the case where implementor have X,Y,Z components while the node says X,Y,A.

From the article I linked to before where they talk about EntityDescriptors we can see that it is these descriptors which are responsible for defining the various Node types that comprise an Entity; it also takes an array of Component implementors through its constructor.

As far as as a user of this library is concerned that's all there is to it: The EntityDescriptors are where we map implementors to nodes and the underlying magic of the framework takes care of the rest.

If you want to know how that magic works under the hood then we go back to Github and take a look at the EntityDescriptor source code. We can see that from line 37 it processes the assignment of Components to Nodes and on line line 64 it will throw an exception if a component required by a Node is not satisfied by any of the implementors. So if a Node says X,Y,A and the implementors only have X,Y,Z then 'A' is not satisfied and the framework will politely blow up in your face with an exception :wink:

Thanks you so much!

This topic is closed to new replies.

Advertisement