Should we enable developers to extend Ash to use more sophisticated rules for adding entities to node lists? about ash

[vrobel]

As for my "excluded components" feature Family is not the only class involved. Game that is needed can be extended more easily but there should be access to Game's fields or some other option for feature extension.

Alternative Family implementation per Node type (defined in a static property) is a nice idea. But also setup of different default implementation might be useful. It may introduce quite a lot of copy code

[vrobel]

As for my "excluded components" feature Family is not the only class involved. Game that is needed can be extended more easily but there should be access to Game's fields or some other option for feature extension.

Alternative Family implementation per Node type (defined in a static property) is a nice idea. But also setup of different default implementation might be useful. It may introduce quite a lot of duplicated code for other implementations. Strategies can just be the piece of code that matters for adding new features but I think there should be more ideas for features to validate points which those strategies should cover

[richardlord]

Yes, but I figure we can probably make it so that family is the only class that needs changing. The key requirement seems to be that the family is informed when a component is removed from an entity as well as when it is added, which makes sense for a general implementation.

[vrobel]

Yes, definitely that would be better to have only Family implementation changeable.

[Stray]

Option 1 ++;

This strikes me as being kind of similar to the question of fallback providers in Swiftsuspenders - the vast majority of cases are served by the default, but those that aren't can benefit from being able to alter that default behaviour.

For the Injector, we've basically said "roll your own" (assuming the changes get pulled to the main branch!) - so I can imagine the NodeListManager (Family implementation) being settable, with your current Family as the default.

Beyond that, I'd leave it down to the developer to further configure. Rather than specify the Family class per list, I'd be more inclined to leave it up to the developer to pass a configuration to their NodeListManager, or set static properties, or use metadata - that's more flexible and also leaves your default API footprint smaller.

If the developer needs a NodeListManager that further diversifies into multiple strategies, they can implement that (and I'm guessing patterns will emerge for doing that well if it's needed sufficiently frequently).

My feeling from having considered this for the Swiftsuspenders Injector is that having the slightly higher barrier of "roll your own" is a good thing, compared with "use this more complex API". In many cases it will be more transparent to manage this complexity inside a system (as you illustrated), so that should be the path of least resistance.

[tdavies]

Good to see some serious discussion on this.

I think these requirements are similar to multiple components argument. I.e. can I add the same component to an entity twice. I'm not convinced that there is a use case where this is necessary and can't be solved another way and it introduces a lot of complexity.

The optional component requirement pretty much goes against the whole node idea and is so easy to do entity.has() that it makes it kind of irrelevant.
The excluded component perhaps has more of a case in that the node is at least still relevant although this to can be simply done with entity.has(). However they fall into the same category which is filtering node lists. There are many situations where filtering is needed such as frustum culling. My though was to enable some interface to add filters to the families. Although they would normal work on the component data there is no reason you couldn't use it in the excluded component scenario.

Last but not least extending the base component. I'm struggling to see a use case here myself. I don't think it breaks any rules as such and possibly saves on a bit of typing but components are data not objects (be nice if you could enforce that in a language somehow). I'm guessing that a scenario that calls for extension may be using them for more than that.
I second Richard in that I didn't need any of this functionality for the game I built. I need to take a good look at ash when I next get the chance it seems to be maturing nicely. Keep it up.

[vrobel]

One note about excluded components. Using has() doesn't help me when my system depends on nodeAdded and nodeRemoved signals.

[richardlord]

The idea of using filters on the NodeList, as Tom suggests, does mesh with another idea I want to implement which is sorting the NodeList. However, I find Stray's argument for simply allowing the replacement of the Family class compelling - it's simple to implement, allows great versatility to the developer, while ensuring the use of entity.has() and entity.get() is an easier option for beginners who might otherwise be confused or led astray by the in-your-face versatility of other options.

[tdavies]

I think there is a good argument for making replacement of the Family class possible as long as the API remains simple. It cant hurt and will probably lead to better design. However family doesn't seem the right place to filter/sort nodes based on there data which I also see a need for. So maybe it needs both?

[BigPhilCombo]

i do think the idea of being able to add all components of a base type is something that is a bit more than an edge case and would be very valuable.

[richardlord]

I've created a new branch - https://github.com/richardlord/Ash/tree/flexible-families - and implemented a possible solution. Please take a look and let me know what you think.

[vrobel]

I added my excluded components feature based on familyClass here. For now using custom familyClass only for few nodes can be achieved by setting custom familyClass, calling getNodeList for those nodes and setting it familyClass back to default then. Families are created then and used later. Looks fine for me. Just wondering about testing my custom family. I think tests should be refactored to those testing Family management in game and Family logic itself. So I think ComponentMatchingFamilyTests should be a separate set of cases and my ComponentExcludedMatchingFamily should also be tested in a separate set of cases

[richardlord]

Yes, the tests do need refactoring.

[richardlord]

At last I've found time to refactor the tests. I retained the old tests as integration tests since they test Game and ComponentMatchingFamily in combination. Such tests wouldn't be expected for other family implementations but since I already have them and they are valid I consider them worth keeping.

The changes have been merged into master and the development branch for this feature removed.