TIGSource Forums

How have people done this?  It seems like the most elegant way would be to store entities in a spatial index like an octree or k-d tree, and iterate only over only those near the player.  But I'm not sure how to go about this.

I suspect that I could get away with just iterating over everything and skipping objects over a certain distance away.

I think it's better to use X and Y boundaries really. Like in chunks. If you are calculating distances you need calculate a Math.sqrt. Wich is more heavy on your machine when you have hundreds of enemies.

What I've done in the past is to query my scene graph for all entities that are "visible" from the scene node that my interested entity is in. How the scene graph determines what is visible from that node is up to it and how it chooses to partition the scene, etc, etc, but I also had the ability to pass in a visibility mask that could further refine the search.

Once the scene graph returns a list of entities that are potentially visible to the entity I could either choose to stop there and accept the list. Or I could further refine it by walking the list and doing a camera query on each entity. This basically involved grabbing the camera information from my interested entity and passing it along to each entity in the list asking that entity essentially "are you interesting?". That entity would use that camera information passed in to determine how interesting it is to it.

I made this return an integer instead of a boolean so that I can then later weight the results based on other factors. So for example, if the entity was a projectile and it is heading towards the camera that was passed in, it is going to be more interesting to that camera than a projectile behind that camera heading away from it.

One note is that you probably want things to be alive for a bit off screen as you don't want a clump of deactivated entities (enemies, bullets, whatevs) sitting right off screen.

Basically, I have a whole bunch of particles and NPCs that need to move around and look busy when the player is within sight of them.  The more the better.  But they don't do anything relevant to the gameplay when they are farther away, so they can just stop updating and rendering. 

The quick & dirty solution is to iterate over everything, all the time, and do more logic for nearby entities.  The more elegant solution is to only iterate over nearby entities.


Only if the visible area is a sphere, not a cube - or is that what you meant?


Could you give an example?

You don't need a square root to check distance, just square the threshold distance and compare against that.

What are you developing with? There's a chance anything offscreen isnt being rendered anyways. Update is a different story though.

Put collision geometry on your camera but set it as a trigger (i.e. no collision response). When the camera gets an OnCollision callback add the entity to a list, when the camera gets an OnSeperation remove it from the list. Then just iterate over the cameras list for updates.