Nesting IComponentData structs

The better question is:
What is the usecase?

 

I think it is acceptable as after current Unity Components converted to IComponentData too, it will definitely have this usecase.

 

I guess that having Inheritance kind of break the ecs pattern, it was pretty much invented to not have that. You should have the two components on the same entity.
But I might be wrong, it's what I have in mind when I think ecs.

 

Only usecase that comes to mind would be to make larger high-level components out of smaller specific components, but for that you would probably need systems to still work on subcomponents. for example let's imagine an RPG with an ActorStats component, but then the player has a bunch of extra stats, so you have a PlayerStats component that contains an ActorStats field called actorStats. I would still expect a system that operates on ActorStats components to effect PlayerStats.actorStats. Could be a really slick way to make higher level component groups but i have no idea how that would be implemented =/.

However! I think having a reliable RequireComponent tag would probably be a better solution to this problem, since then multiple high level components could share components they need (eg: ActorStats, Rigidbody, etc...).

Those are just my thoughts.

 

I'd rather have [RequireComponent(...)] too. including automatically transfer [RequireComponent] between IComponentData to their corresponding ComponentDataWrapper

a better idea would be having a IGroupedComponentData interface that can contain N IComponentData fields (and corresponding wrapper), when added to an entity it actually adds the components (i.e. doesn't exist at runtime). IGroupedComponentData can be nested.

nesting directly IComponentData would be fine as long there is a clear and intuitive semantics about the nested components (do they get attached to the entity (i.e. other systems see it)? if so, the data is duplicated or you would weave the assembly with some pointer trick? what if you have multiple components with the same nested component?)

 

I like that grouped thing and RequireComponent as a design aspect for the Designteam...
But I don't see a super really important usecase for nesting.

In my mind, nesting will break the ecs paradigm.
You create additional dependencies between different data structures and between data and systems.
And there is no information growth or other benefits. You can do the same without nesting, at the moment.

But maybe there is a usecase, I don't know

 

@jasonm_unity3d
but how do you interpret 2nd struct from component system view point: it's only Foo2 or it's Foo2 and Foo1 entity. I think you will pass reference so what about job security? Can you track nesting (first and/or more)? Not to mention memory layout as you mentioned before.

There should be one purpose component so systems can be clear about with what they work and with not. Even if system can do nested components for me it's just bad practice for simplicity and code readability sake.

 

Now I change my mind that Nesting IComponentData structs is bad idea. I think if u make it nested it's kind of like go back to OOP approach and make it complex again. Not only that, when u access the data from IComponentData, it's also very ugly like Group.Component.AnotherComponent.JustAnotherComponent.someData.

I guess you can make it throw compile error when people doing Nesting IComponentData structs.

 

I think the problem lies in expectations.
you can just do group.transformMatrix.value.m1.x where only TransformMatrix is a IComponentData, it just contains other structs (value is a float4x4, that contains 4 float4 (m0, m1, m2, m3) that each contain 4 floats (x, y, z, w))

but what if one of that nested structs happens to implement IComponentData? naturally it gets ignored, it's just nested data, it's not added directly to an entity, so it doesn't gets picked up by systems. but it does say IComponentData and that can generate confusion.
specially picking those nested fields would open a can of worms, like defining exactly how they get picked and (de)duplicated, which can cause more confusion.

but there is nothing preventing c# from having a struct with a field that's a struct implementing an interface, so it can't be a compiler error. maybe have a warning when adding it to an entity, with an "I know what i'm doing" attribute to suppress it (like [NativeDisableParallelForRestriction])

 

What about "has a" relationship? I have these little non-MonoBehaviour classes that I use a lot in my games. I was wondering how I could port them to the ECS way. Adding them as separate components is clunky. They are owned by other components in the same entity. How do you build this relationship?

I've thought about using nesting then calling a static method from the system operating them:

Code (CSharp):

1. struct Utility {
2.     ... // Whatever
3. }
4.  
5. struct SomeComponent : IComponentData {
6.     public Utility utility;
7.     ... // Other attributes
8. }
9.  
10.  
11. class SomeSystem {
12.     void Update {
13.         foreach(Component component in components) {
14.             component.utility = UtilitySystem.Update(component.utility);
15.         }
16.     }
17. }
18.  

 

"Has-a" in the ECS framework may not be a direct ownership relationship that we're used to with OOP and regular imperative programming (and I think I may do a deeper write-up on this concept), rather, we use various methods to associate entities together (this can include entity keys themselves).

For example (paraphrased from something I'm working on, definitely still figuring out the best structure)

Actor
* ActorId - Shared Value, Entity Id of Main Actor object
* TransformMatrix
* Speed
* Direction
* JumpState -- swap around with the other *States
* GroundState -- swap around with the other *States
* AirState -- swap around with the other *States

Actor Animator Entity
* ActorId - Shared Value
* Visual "Tag"
* FacingInfo
* Animator (regular Component)

Actor Current Status - add / remove status effect data as needed
* ActorId
* Health
* Stamina
* ActorId - Shared Value
* Slowed
* OnFire

* IsDeleted - use for cleanup at end of frame, only applied when Health drops to 0 and we hit the end of the frame.

From this line of thinking, let's look at it this way:

Actor has-a Animator and has-a Current Status via the ActorId (which could be just anything that works for ISharedComponentData, but likely the Entity ID of the Actor those things belongs to in the direction my game's framework is moving), which defines the "has-a" relationship.

The systems that operate on Actors and their related entities acts as rules that define and enforce the relationship between these otherwise loose sets of data.

We're so used to the OOP forcing us into thinking about is-a and has-a in terms of direct ownership or direct inheritance it's difficult to dissociate those from their higher actual concepts. In the above example, an actor is-an Actor because it has-an ActorId that matches it's Entity Id. That's it. This actor also Has-a Animator and Has-A Current Status, without needing direct ownership. It THAT realization that makes this concept so powerful and is something I suspect causes a lot of programmers raised by OOP have issues with ECS framework concepts in general, since it's such a 180 from how we're taught to make stuff.

The beauty of the above system is we can create rules that delete our associated sub-entities when the master entity dies, but the master entity doesn't necessarily need the sub-entities to do it's basic functions (for example, we could ditch the Curent Status for NPCs that don't need it, or simulate background actors without an Animator entity when they're offscreen), and they don't have to directly reference the master entity unless it's necessary. In fact, the only NECESSARY component is the ActorId, since it not only ties everything together, but denotes the life cycle (if the ID ceases to be valid, the actor is dead, and anything sharing that Id can be cleaned up implicity via our lifecycle rules).

You can extend this line of thought to inheritance as well, having a string if Entities that represent class-like objects or stable data definitions with a "Derives From" that defines the relation ship to the "base class", then use these structures as prototype definitions to assemble complete objects via a factory. And change those prototypes at runtime. INHERITANCE DEFINED BY "Plain old data" AT RUNTIME, without an extra interpreter or hot-compiler. It could be super useful for stuff like game mods and UGC that work even on limited platforms like mobile devices or consoles. You may not be able to compile up entirely new code at runtime, but with a robust enough set of components and systems, you could build an entire limited scripting extension platform for your game entirely in ECS.

Apologies for going on a rant there, I had some realizations on all of this over the last few days, it's been kinda slow at my day job.

 

I think your code is irrelevant to this topic because you have a basic struct inside IComponentData struct which isn't a bad thing.

 

I just came accross a use case.

I am currently working on a collision system :
Entities that can collide have a Position component, a Collider component and a RigidBody component (these structs inherit IComponentData).
When a collision between two objects occurs, I have to somehow signal this collision event so that it can be processed by other systems.
To achieve that, I chose to create a new Entity with a CollisionEvent attached to it.
This event should contain information about the objects at the time of the collision event.

So I have to store the Position, Collider and RigidBody components values inside of the CollisionEvent for each of the two colliding objects. Do you see any other way to achieve that without nesting IComponentData structs ?

 

system that inject all 4 IComponentData? CollisionEvent should have only nessesary information about other entity

 

I need at least to store the Position data (see it as the Unity's transform) as it could be modified by another system before the collision event is processed. And what if I need access to the colliders that actually collided ? Should I then look if a Collider component exists on the Entity at the moment the event is processed ? I thought this was not very efficient.

Or did you mean that I should not create a separate entity for the event, but instead add the component to the moving object with only the info about the second object ? What if more collisions occur at the same frame since it seems we cannot add more than one component of the same type ?

 

Nope, I mean this: entities that collides gets IComponentData CollisionEvent with all necessary data in it to process this collision.
While you should set system execution order for setting up a priority for position update (so it will be updated as you wish), CollisionEvent should have corresponding data of collided objects so each object can change only itself instead of other.
It seems right to not be able to add more components of one type. How can you process two CollisionEvent components? That entity should be process twice by system that expects one component or once by system that expects two components? So sure, you shouldn't be able to do such ambiguous thing.
To resolve that problem I think there need to be a list of collisions data in CollisionEvent component so one system can process all collisions at once for a entity.

But still I think we need to wait until Unity Team introduce us to ECS integrated collisions. They really have the answers.

 

THank you both for your answers. I chose to go with the approach suggested by Miruku since it allows for instance to filter entities based on the fact that they are colliding or not, while the "independant entity" solution would need to iterate other all entities to see if they match the collision event entities.

Seems like I will have to have a look at arrays inside components to handle multiple events.