EntityView Terminology about svelto.ecs HOT 9 CLOSED

this means that if you write a SocketEngine you would likely need a SocketNode. This SocketNode is a set of references to the Entity components needed by the SocketEngine.

If a Node / EntityView is closely associated with engines, then it might be useful here to also include the word "Engine" in the name (e. g. EngineEntityView). However if I understand what you are saying here correctly, it would seem that a Node has nothing to do with actual entities themselves, just their components. So in that case maybe we don't even need the word entity at all? (e. g. EngineProviso)

from svelto.ecs.

In my opinion, if you want to handle player graphic, you should not and will not use view terminology because it is too general to be handled in our code. The implementation may look like this:

• Player entity has TransformComponent, HealthComponent, and SpriteComponent
• SpriteRenderEntityView has TransformComponent and SpriteComponent
• In PlayerEntityDescriptor, you will register SpriteRenderEntityView builder
• SpriteRenderingEngine will handle rendering sprite of SpriteRenderEntityView

Take a look at this image created by @sebas77

from svelto.ecs.

I'm not sure I follow you exactly, but in any case this is not directly related to my main issue. I actually want to get rid of the term "view"! So in that regard we are in agreement. I only used it's use as an example of a possible naming conflict, since it is already being used like that.

However, you might not fully understand how people are actually using the term. I believe it's intended to be used as a board and very general term. You can have a look at this Entitas example use for more information.

from svelto.ecs.

Hello,

I called it view because it is how the engine "views" an entity. It's a view of the entity for the engine.
If you have a better name that gives this idea please let me know. Although I think it's too late to change it, it will help me to see concepts from different angles.

Btw I know that what I wrote so far is still not enough to get Svelto.ECS right. I know it because our CEO wanted to write a prototype with svelto and came with several common questions that I still didn't covered well enough in my articles, but I took a lot of notes and I will talk about them on an article related too good and bad practices. I recently improved a lot the survival demo. Currently is the best resource to learn svelto and I am writing the next article around it.

@IsaiahKelly sorry I wrote this answer this morning while I was still half asleep, I had to edit it multiple times :D

from svelto.ecs.

Yeah I was afraid it might be too late to change, but thought there was no harm in sharing my thoughts anyway, and maybe it will still help you in other ways.

Terminology has become something of an unhealthy obsession of mine recently. I think it's because I've realized it's vital in helping make systems and their APIs intuitive and easy to grasp. This seems especially important for huge paradigm shifts like from the OOP to ECS mindset.

Your reasoning behind the term makes perfect sense; an EntityView is how an engine views entities, or at least their components. However I think the problem I have is it doesn't explain the actual relationship. When I hear EntityView I just think of a visual representation or some kind of view of an entity, but I don't know for what exactly. It doesn't actually tell me anything about the relationship to engines or their use.

If I understand this correctly, an EntityView is basically a filtered list of components an engine needs to work. In that case I believe it would be much better to call this an EngineProvision or EngineCriterion since I think this better explains it's relationship to engines and purpose. You could even add the word Entity or Component in there too, but I think this alone is better than EntityView.

As for editing posts multiple times, I know that feel bro! 😄 Hope you are getting proper rest. I know you are very passionate about this and I thank you for all your hard work and sharing it with the community, but sleep is vital to helping you think through and solve these issues. I know this all too well from personal experience.

from svelto.ecs.

ok I didn't get at first what you meant with Provision or Criterion...they both sound so latin-rooted (well, greek as well), which is ok for me being Italian, but could scary other people :)

EntityComponentsMap is something that could work as well. I came with EntityView because I try to use words from that I would use to explain the concept itself. EntityComponentsMap could be actually more logic for a coder, but it would be awkward to say everytime during a discussion :D

from svelto.ecs.

Ah yes, "map" is probably the one word I was trying to think of, but could not. It is similar to "diagram", but probably much better. I also think just calling it an EntityMap would be a big improvement if you don't want to make it too long.

Then, instead of having a SocketNode or SocketView, we would have a SocketMap for the SocketEngine. This seems to make a lot more sense to me. The inclusion of the word "components" is probably not really necessary because "map" means a kind of guide to the entity, which could include components. A map is also a kind of abstract representation of something. So we can keep the association with a particular entity, but still understand this map is not the actual entity itself. Just a map to it. I like this idea a lot!

P. S. I'm not Italian and don't think "Provision" and "Criterion" sounds scary at all. In fact, I actually think they sound kind of awesome. 😛

from svelto.ecs.

For me, asian people, "Provision" and "Criterion" sounds scary. I'd never heard them used in coding before. :)

But, what do you think about Proxy?

Proxy or Proxy Pattern provide a surrogate or placeholder for another object to control access to it.
from : http://www.dofactory.com/net/proxy-design-pattern

from svelto.ecs.

I decided to keep EntityView, but in my last article I mentioned the idea of EntityMap.

from svelto.ecs.