# Entity Component System, How to decouple components need for entity as parameter?

I use Artemis entity system framework, C# port. I have problem with figuring out a good way to handle items and using them.

Game is AI driven mostly, so it's not the player that is interacting, but AI. AI is basically Entity with AIBehaviorComponent that is ran by AISystem. AI has helper functions that allows it to find all items (ie. Entities with InteractiveComponent) and then it can pathfind to it and use that item. AI is using BehaviorTree that is stored in it's component.

I have InteractiveComponentthat allows player and AI to Use entity. I have this thing working, but it looks a bit dirty solution. Use method is interface that is implemented by Item object that is tied to that component. This way i can have item made with:

new InteractiveComponent(new AwesomeItem());


Calling Use requires me to:

1. Get entity ref
2. Find component 'InteractiveComponent
3. interactiveComponent.use(me)

me is (this) Entity. The AI entity that is calling the use. I am passing entity to Use method, because using something can alter the entity. It could add component to it, check if it has certain component and then modify the data or remove components, it could even remove the entity.

So, I'm bit lost here. This works, so it's "ok" i guess, but it looks very dirty. I have not found a way to allow somekind of InteractiveSystem to take care of item using without adding huge complexity issues ( Those arise quickly when you try to force Entity system to do something it does not easily allow ).

So, question is:

How to decouple this so, that i don't have to pass Entity to component?

I just don't feel good about the current code but so far it's the best solution we have come up with.

So you're passing the Entity to Use because Use could (effectively) "do anything" with the entity, but you want to come up with a way to not pass the entity?
This is pretty straightforward: change your design. Define more concretely what you want Use to be permitted to do to a thing, and pass it a reference to some interface exposing what it is allowed to do. Otherwise accept that your current design needs the entity in Use because Use is allowed to do almost anything to an entity.
There are lots of different ways you could reorganize this to make it look or feel different, but fundamentally if your fixed principle is that "using a a thing can mutate the using entity, you're going to need to give it the entity, and what you have now seems like a reasonably straightforward approach to that (your dependencies in Use` are explicit; this is a good thing).