Aspects (IAspect)

https://portal.productboard.com/wkj...ure?utm_medium=social&utm_source=portal_share

Interesting feature. Similar to IJobEntity in ease of use but I'm hoping to read more about IAspect and in particular how both play nice with entity command buffers, as IJobEntity turned out to be slightly worse with command buffer usage than just iterating over like you usually do in context.

So these ease-of-use features are super welcome, but they don't feel practically tested. Is there any more information out there? These are pretty exciting features for gameplay, and spawning/despawning is an extremely common use-case but seems slightly neglected in the ease-of-use API.

 

I would focus on what we have now in 0.50 and not think about what is coming. From the GDC slides, there are too many redesigns of critical features such as transforms, conversion, and hybrid workflows that haven't been tested by real productions. I would be fine with a 1.0 beta in 22 LTS, but 1.0 proper sounds like the DOTS team finally caught the disease that has plagued Unity for years.

0.50 was a step in the right direction, so there's still hope, but I'm skeptical.

Anyways, my understanding of IAspect (using C++ terminology) is that it is a custom iterator that traverses over and abstracts multiple components at once. You can already do this sort of thing with IJobEntityBatch, but not with codegen, which is probably what they are looking to support.

 

have you actually seen these changes? I’m all for change but if there are major redesigns in order, wouldn’t it be somewhat inappropriate to introduce them in 1.0 drops rather than having them in prior(given how long it’s taken to get to where we are currently)?

 

I haven't seen much, but I've seen enough to believe that Unity disagrees with you. I'm with you though.

 

Do you have an example of something like this using IJobEntityBatch? I have a few places where I need the same set of components and I'm curious if this could help clean things up.

 

Sorry. No example since I haven't found a good use case for this yet myself. And I won't try to type one up quickly because it requires a number of steps. So I will list those out instead:

1. You need an "AspectTypeHandle" struct for your aspect. It stores internal fields to ComponentTypeHandle and BufferTypeHandle internally.
2. You need an extension method to construct (1) from a system.
3. You need an "AspectArray" struct which will hold the NativeArrays and BufferAccessors fetched from the chunk in internal fields.
4. You need an extension method to construct (3) from a chunk using (1).
5. You need an "Aspect" struct which can either be a ref struct or an unsafe struct and stores references or pointers to an element in each NativeArray from (3) as well as DynamicBuffers in internal fields.
6. You need public functions on your "Aspect" which manipulate the underlying data.
7. You need an indexer on (3) which generates (5).
8. Add [NativeContainer] to (5) to keep users from storing instances in other containers.

 

So this is just a collection of pointers. Which means memory access will be random?
Really, the only thing I'm interested in is how Unity will handle race conditions, like changing stats or health in their RPG example code.

 

What? No. Each adjacent index in the AspectArray would produce adjacent pointer addresses. It is still chunk iteration. It is just now you have a proxy struct containing references to the data, similar to the arguments in a ForEach sitting on the stack.

 

Oh, I was totally misunderstanding this then.
So what are some benefits for this? Better access, cleaner code, ability to merge 2 archetypes into 1 logical unit?

 

It is an abstraction (and potentially an encapsulation over a set of components). Might be useful for hiding components stored in SOA, or forcing writes to update dirty flags or change versions on entity granularity. Or just simplifying a set of complicated components into an OOP-like interface for people who don't like static functions.