Component value based entity querying

I'm having difficulty adjusting to ECS way of thinking about the data. This post is a bit like thinking out loud.

Let's say an RTS level is separated into tiles, and I need a system to work on all units in the XY tile (TilePosition = x ,y). I would like to be able to make a query like EntityManager.GetEntity<TilePosition>(x, y).

ECS systems like Entitas keep dictionaries with user-defined keys. For example, I mark a field inside an entity with [EntityIndex], and EntityManager starts to keep track of it and is able to fetch entities with that key.

Is that something that is going to be supported? Is that even a good way of doing it?

Should I keep dictionaries, and if so, where should I put them? I could have a system that would track objects moving from tile to tile I guess and emit events when that happens if necessary. Then should I have an entity with dictionary for all current units as value and positions as keys? Or should it be an array of lists (if possible) or some such? Then any system that needs to query the units would use that entity?

What if the array or dictionary is HUGE? If it is kept on an entity it's gonna be copied for system's use. At what point it is too big to copy effectively and should be split?

I assume the boids example can shed some light on that but the talk I watched about that example was too difficult for me to understand. I'll check the source code though.

 

I think the approach needs to be tailored to your specific use case.

Because of the Unity's ECS design, the iteration are extremely fast. Often, if you entity set is small enough to fit reasonably into a cache and, you intend to work on the actual TilePosition component, it is generally more performant to just iterate over whole set and filter entities by TilePosition components for you.

If your entity set is huge, and the filtering is really sparse, having a index-lookup dictionary might be advisable.

This all again needs to be tested and tailored for your specific use case and only if you need cutting edge performance.

Initially, I would advise to not care about such nuances and really on iteration-filtering until you start seeing this as a problem.

 

Thanks for the answer. I should have noted that it's an abstract example, not exactly my case. I'm only starting to get a vague idea of possible approaches but still have no idea what each of them means in terms of numbers. So in a given example, it's how big should the map be and how many units to justify a dictionary instead of iteration.

But I guess I'd have to test.