Another way is: instead of storing entities by location have each entity store its own location and simply store them in an agnostic container. Pick a container that will allow you to quickly locate entities matching a position through iteration.
Having entities store their own location, was my very first choice, in a list. But it was inefficient since I had to run through the list each time I wanted an entity, so this seems logical.
Sorry, agnostic container? I searched some stuff on google, but there was nothing specific. Is this a some sort of a library, or just a spontaneous word you made?
There's also the possibility of hybridization. That is, have a master list of entities which are aware of their own location and also retain a 2D array of containers that point to all entities that occupy each location. This is the most expensive in terms of storage and architecture but has the best access time for any method.
This seems tough, but I'll consider it as my second option.
Thank you guys, if you can just help explain the concept of this agnostic container, I would be grateful.
Also, since almost anything with height will be an entity, and some entities won't update, should I keep them in a different layer?
So there are two types of entities, the ones that stay still (trees), and the ones that move (animals). There is no point to do Entity.Update() if it's a still entity, so it's logical to keep them in two different layers, right? But the problem is, since they're both entities, it's like separating skin from bone, I don't like the idea of two layers for entities.
Is there another method for this as well (or should I make a new thread)?
Edited by WeNeedFocus, 06 May 2013 - 05:21 AM.