#How do you compose entity hierarchies and relationships?

1 messages · Page 1 of 1 (latest)

upper mulch
#

There are 2 related questions here. I'm coming from Flecs and am looking for similar patterns to achieve clean architecture. Let me give you an example of what I mean.

1) Entity attribute composition
Character2D has things like Position, Scale, etc. Enemy is a specialisation of Character2D (basically like a subclass in inheritance) and adds attributes specific to the enemy such as MeleeDamage.
Using this pattern I can reuse and define the common component fields only once higher in the hierarchy. How do I do this in Unity ?

2) Entity relationships
There is an IsA relationship between Enemy and Character2D. This is very useful because I can query for 'anything that's a Character2D' in my systems and get all entities, Enemy or not. Is using tags like IsCharacter2DTag the only way to do this in Unity or is there a similar way?

silk kelp
#

I will highly recommend reading official ecs documentation: https://docs.unity3d.com/Packages/com.unity.entities@1.4/manual/index.html

It will answer all of your questions and give you the fundamental knowledge to reason about unity ecs.

Your first question sounds like you have not had much experience with ecs, as in ecs you should stop thinking in oop terms and embrace composition and Entity Component System itself. Once you do, you will stat thinking about problems differently and your architecture will get tailored to how ecs should be.

#

The documentation is very well made, but you might feel that you need to read everything to understand it. In reality, it is written in a sort of chronological order of what you need to understand when

upper mulch
#

Hey, thanks your taking the time to reply. I am sure you mean well, but this 'answer' was pretty generic, and I feel like you don't understand what I am going for here as you are conflating this sort of data reuse with OOP.

Reusable semantics is a much more general concept that is far from being exclusive to OOP paradigm.

Maybe you should also check out the 'other side of the fence' ; then you might be able to understand the actual features I am talking about. For example, relations isn't an exotic feature exclusive to Flecs.

Anyway, it seems like Unity Entities has gone for a more pure Archetype implementation, with a significant hit at developer ergonomics. I have been reading the docs and coding in DOTS, and these questions have naturally come up. It just doesn't feel great in comparison to what I'm used to and this attitude of yours hasn't helped either. Happy to leave it at that.

real gull
#

since authoring prefabs in unity ecs are defined using GameObject prefabs, which get converted into ecs data at build time, you can use prefab variants as a form of inheritance that allows you to define for example the Character2D and Enemy that you have as a base prefab and a prefab variant that adds some components

#

you don't get any kind of automatic reflection added based on that however

#

in general terms i do agree with Fire that your ecs systems should be basing their queries on the actual components that you have rather than this type of "metadata"

#

after all, why would you want "anything that is a character2d"? your system can instead just query for the set of components whose data the system is processing

#

this approach allows the system to be as general as possible, which means maximum flexibility

#

and then if you need to be very specific for some reason, you can add a zero-size tag component to the entity and query

upper mulch
#

Thanks, I appreciate the specifics.

upper mulch
#

I am simply looking for equivalent patterns to what I have grown to like in this other ECS lib. It's totally fine if there are no equivalents in Entities - that was the point of my question.

#

AFAICT there were Aspects which kiiiind of had a similar effect, but they got deprecated

real gull
#

aspects were there mostly to offer a convenient grouping of components rather than type hierarchy, but yes they were deprecated and are going to be removed soon (though if you're on unity 6.3 LTS you can still use them for several years going forward)

upper mulch
#

and yep, an EnemyTag would do the trick indeed. But seems just more bookkeeping that I need to do (and structural changes associated with them, though in this case they'd stay on the entities)

real gull
upper mulch
real gull
#

for example you'd probably split projectile hit detection from damage accumulation, and then also separately from damage reactions

upper mulch
#

Generally I agree, I'm all for small & specific components and systems. Would probably go smaller next time, yep. On a non-game-jam project probably 😆

real gull
#

i think that's a fair point that points toward a difference in philosophy; unity's ecs was architected from the ground up as a reaction to old game engine architectures that failed to scale to a lot of cpu cores and large and complex game worlds

as the goal is to maximize data processing bandwidth on multiple cpu cores, the framework is best used with a mindset that tries run small "kernels" of code on strictly delineated arrays of data

#

it's very focused on data-oriented design, which is even in the name "DOTS"

upper mulch
#

I think that can be said more broadly for all ECS implementations, right? I don't think having more granular systems & data is bad any in ECS framework or more preferable in another, as it's all about cache locality in the end.

#

I am sure my code can be improved. So can DOTS 🙂

upper mulch
#

Also, the game I'm building barely has any pre-authored content. Admittedly unusual in that regard. So again, the whole editor/baker workflow is not something I'll find very useful.

ScriptableObjects could be interesting as the carriers of that data too maybe.

real gull
#

it can still be quite useful because unity ecs does have a fair bit of support for live baking in the editor which is especially convenient when tuning gameplay

#

you can generally just edit a value in the prefab and see the results live in an ecs-based project as you would in a gameobject-based project

#

though there are a number of caveats of course, any kind of hot reloading whether data or code is always a bit finicky