adam4813
Create a JSON Protocol
The SC format is temporary. I believe the consensus is that JSON is a good direction to take it. Use this issues thread to start thinking about the actual JSON protocol for creating entities.
- Identifying existing entities and resources is a big part of this
- creating components with pointers to existing resources
- creating new components for an existing entity
- updating anything over a network connection where each client may have different ids for the entities
- Components may have dependencies. This should be expressed in the JSON object.
- for example, BulletShape components require a Mesh
- In terms of networks and client/server interaction, the protocol should support multiple operations
- create entity
- create component
- destroy entity
- destroy component
I think that we must have a unique id, i.e a GUUID, across all servers and clients in the same universe, otherwise it is technically undoable to synchronize data. If we need local id, they will be clearly identified as such to not leak.
Note that from an external point of view, ECS exposes 'features' (former name metacomponent) that are a set of components strongly dependant and sharing the same lifecycle. For example an entity that can receive external forces will request ControllableMove feature (name may change) that will add 2 components, 1 for directional force and 1 for rotational force. So, feature is what we query and components are what we get. There must be a feature taxonomy and an explicit dependence management at the feature level, not at the component level. There must be a taxonomy of components also.
So, there is no need for component creation operation, but feature creation operation, but the need is similar.
There must be a feature taxonomy and an explicit dependence management at the feature level, not at the component level. There must be a taxonomy of components also.
Once again I think we are trying to say the same thing but using a different vocabulary! In Adam's lexicon, "components" are groups of "resources." In yours, "features" are groups of "components."
Global UIDs is a good idea to have built into the engine from the start. Does that mean that the server always provides the next available ID?
Further thoughts:
- resources need factory methods and therefore names. (Is that what you meant by "a taxonomy of components" ?)
- either components are required to create/link all resources at creation time, or they need to specify a default value
To c&p from my chat epiphany: <adam4813|mobile2> catageek: I think I get your thinking <adam4813|mobile2> Your idea of a component is that of each element or component of a vector for example <adam4813|mobile2> Your components would be xyz and your metacomponent would be the vector <adam4813|mobile2> Where as I am not being a granular and a such call the trsnsform a component that contains position and orientation vectors <adam4813|mobile2> And you purpose using banks of your definition of components that are retrieved via accessor and I just store them in what I call components <adam4813|mobile2> I guess my components by your definition would be a composite On Jan 13, 2014 11:08 AM, "wrongu" [email protected] wrote:
There must be a feature taxonomy and an explicit dependence management at the feature level, not at the component level. There must be a taxonomy of components also.
Once again I think we are trying to say the same thing but using a different vocabulary! In Adam's lexicon, "components" are groups of "resources." In yours, "features" are groups of "components."
Global UIDs is a good idea to have built into the engine from the start. Does that mean that the server always provides the next available ID?
Further thoughts:
- resources need factory methods and therefore names. (Is that what you meant by "a taxonomy of components" ?)
- either components are required to create/link all resources at creation time, or they need to specify a default value
— Reply to this email directly or view it on GitHubhttps://github.com/adam4813/Sigma/issues/135#issuecomment-32189061 .
Yes I think that you point out our difference of vocabulary.
But at the end what will be accessible to an entity is a component in your definition, and it will be a pointer on a element of a vector (metacontainer) which is a component in my definition, so we agree on what is a component since it is the same thing (a pointer or the data itself).
The granularity of the component is still under discussion. I agree for xyz to be an component, but orientation should be another component, and transformation matrix a third component, because I don't think that they will be involved together in the same loop. Storing a composite is a bad practice since we must load and store the composite when only a part of it is processed. It tends to pollute the cache. It is reasonable to think that xyz will be processed while the matrix is not accessed, or the inverse. The more primitive the components are, the more simple will be the hunt for memory transfer optimization.
For GUUID, i would say that the first bit of our 32 bit ID could be reserved to mark the id as global or local.
For the taxonomy, I think about the component names (xyz, orientation, transform) that are hardcoded in their respective class, and to features names, PhysicalWorldLocation for example, that groups (xyz, orientation, transform) and that have factories declared in factory system. Components do not have factories, it is managed at metacomponent level. Names are needed to request a feature, and names and types are needed to access a specific component.
For the sake of clarity let's call "features" composite components or just composites as that is what they are. Features will just lead to confusion. On Jan 13, 2014 1:19 PM, "catageek" [email protected] wrote:
Yes I think that you point out our difference of vocabulary.
But at the end what will be accessible to an entity is a component in your definition, and it will be a pointer on a element of a vector (metacontainer) which is a component in my definition, so we agree on what is a component since it is the same thing (a pointer or the data itself).
The granularity of the component is still under discussion. I agree for xyz to be an component, but orientation should be another component, and transformation matrix a third component, because I don't think that they will be involved together in the same loop. Storing a composite is a bad practice since we must load and store the composite when only a part of it is processed. It tends to pollute the cache. It is reasonable to think that xyz will be processed while the matrix is not accessed, or the inverse. The more primitive the components are, the more simple will be the hunt for memory transfer optimization.
For GUUID, i would say that the first bit of our 32 bit ID could be reserved to mark the id as global or local.
For the taxonomy, I think about the component names (xyz, orientation, transform) that are hardcoded in their respective class, and to features names, PhysicalWorldLocation for example, that groups (xyz, orientation, transform) and that have factories declared in factory system. Components do not have factories, it is managed at metacomponent level. Names are needed to request a feature, and names and types are needed to access a specific component.
— Reply to this email directly or view it on GitHubhttps://github.com/adam4813/Sigma/issues/135#issuecomment-32201185 .
Ok we are using rapidjson for object (loose sense of the word) creation parameters either from disk, network, or maybe even scripting.