EntitySet with FieldFilter

I have this component:

public class MyComponent implements EntityComponent {}

I want to create an EntitySet where the entities do NOT have a MyComponent.

entities = ed.getEntities(FieldFilter.create(MyComponent.class,null,null),OtherComponent.class);

This gives me a NullPointerException. What should I put instead?

I think there is a NotFilter, could that be?
Because you can’t say “When MyComponent’s field called null is null”

Indeed. But since there isn’t a NotFilter, what should I use instead?

not possible in my experience and it sounds like an antipattern

You could also create your own filter, could be that I implemented a not filter on my own then.
But if it’s an Antipattern…

Yep, this.

You do not really want to do what you are trying to do… but we don’t know what you are actually trying to do and so we cannot comment on the bad design.

It’s definitely an ES antipattern, though. “I want to operate on every possible entity in all of existence, millions and millions and millions of potential entities from users to accounts to flowers… that don’t have this component.” Unlikely.

The MyComponent is something like “sleeping”. So I want to work on all the entities that are not “sleeping”. But I guess I can replace it with an enum “awakeStatus{AWAKE, SLEEPY}”.

I just wanted to encapsulate the information in a less verbose component.

The flaw in this approach is that all entities that are not sleeping are not necessarily “awake”. Weapons aren’t awake just because they aren’t sleeping. Chairs aren’t awake, etc…

If you need to model awake entities and sleeping entities then you need a component that indicates both of those states (as you’ve suggested).

1 Like

Wow! Could we take that as a general approach when designing the components for a game?

My experience tells me that in ES it mostly relay on the situation, it is hard to have general rules. I just know a few antipatterns and some best practice (for example linking is done from child to parent and not the other way around) and some design patterns for specific purpose which works for me (like the famous decay system among others).

I mean, the general rule is, if you can call it that: do not rely on the lack of a component as some useful state… because that’s not really the state you mean. (Example: awake/asleep)

Alright, got it! Thank you very much Mr. Speed :slight_smile: