Can / should you reference queries from a geotic instance?
luetkemj opened this issue · comments
tldr;
Would you recommend adding queries to the geotic instance itself so they can be referenced from a component handling an event or should queries only be accessed from systems?
I have been working on traps in my game. Traps are triggered when an entity moves into a space containing a trap. To do this when and entity moves I fire a "contact" event on every other entity in the same tile. Traps listen to this "onContact" event and explode when triggered.
Initially I had intended to have all of the explosion logic in the trap component itself. This includes determining all the entities in range - determining those effected by the trap - dealing damage - and finally applying blood.
The question is in applying the blood. I keep a dijkstra map to track blood that gets built using a geotic query. Queries are not accessible from a component. Importing the instance of a query into a component blows up because the engine creates the components before the queries and we get undefined variables. My solution was to create an AreaOfEffect system moving all the logic of triggering a trap from the trap component to the system. So now Traps listen for an "onContact" event and add an AreaOfEffect component to their parent entity and the system does the rest with full access to any queries it needs.
On a whim this morning, I tried storing my queries on the geotic instance itself (ecs) in order to have access to them in components. Now I can access them at ecs.queries.myQueryName. If I were to follow this pattern I could go back to the original plan of keeping all the logic in the component itself.
Will likely stick to the AOE system as it's pretty generic and useful for more than just traps but I can see having access to queries in the component being very useful in other cases. Any reason not to add them to the ecs instance? Trying to think of how this might blow up in my face...
When the query stuff was designed, i tried on purpose to not tie them down to a specific architecture.
In traditional ECS, you really do not want to put any logic inside components at all, they should only contain data. However, there are no rules
If you create and store the query on a component, it will have a performance impact if you spawn too many of that component type. However, if you are only referencing the query by doing ecs.queries.myQueryName, then performance shouldn't be an issue.
The issue with referencing it, is that you're introducing an outside dependency. That query has to exist for the component to function properly
i think the AreaOfEffect system you have now is nice and generic, which is what ECS is all about
In traditional ECS, you really do not want to put any logic inside components at all, they should only contain data.
I have struggled conceptually with this traditional rule and Bucklew style events that contain a fair amount of logic - but I suppose like most things, it depends :)
I really like events - I just have to remember not to use them lazily when a more generic pattern that may require a bit more effort up front would be appropriate.
Thinking this through - Maybe the right approach with events is to use them strictly for simple component management. Adding and removing components, modifying a simple property - but nothing too complex that would require knowledge of the rest of the system.
For example, use events to increase or decrease a health components HP property. However when that component reaches 0 HP use the event to add a new "Kill" component that is used in a system. The rationale being that killing an entity has far more side effects than just reducing the HP of a single component.
Still trying to wrap my head around how to implement a goal stack style AI with this but I think I'll get there...
Maybe the right approach with components is to use them strictly for simple component management. Adding and removing components, modifying a simple property - but nothing too complex that would require knowledge of the rest of the system.
That is a very comfortable medium, and the original intent of the events 👍