This bot is going to be pretty bad ass from what it sounds like. I think your idea sounds pretty good, I would of never thought of it. If you need anything let me know. Best of luck!!!

A few comments:
- looping through hundreds of entities often is negligible compared to the actual casting of rays / tracelines
- visibility often is symmetric: if NPC A can see NPC B's head, you could save a ray by assuming that NPC B can see NPC A when NPC B is looking in NPC A's general direction.
- it might be more efficient to batch (and sort) all rays to be cast from one NPC because of application level and CPU level caching
- correct visibility probably is less relevant for health packs and for friendly NPCs than for opposing NPCs. I wouldn't bother checking visibility for healthpacks.
- some entities do not require additional visibility checks once they have been perceived because their position can easily be predicted (rockets, trip-mines).
- consider modeling 'information overload' and 'focus': an NPC performing a close-combat knife fight shouldn't be interested in spotting other threats 50m away. Similarly, an NPC tracking four threats that are nearby and in of front of him probably won't be capable of spotting a more distant threat at the edge of his field of view.

William

[Edited by - WilliamvanderSterren on October 26, 2004 1:37:59 PM]

Lots of good ideas there William. DrEvil, one very minor warning:

Iterating through object lists and intersect tests can vary wildly in cost between engines/games. Be sure you need some of these optimizations before you implement them. Depending on the engine and the data, some may have little gain.

For instance, if your visibility tests use a quadtree or an kdtree under the hood, there may be enough data moving into the cpu cache that batching your intersect tests may not gain much at all. The gain may also depend on the scale of the level or the complexity of the geometry.

It may be best to build a few test cases based on your expected entity load/density/geometry to compare different directions. I am definitely not suggesting any of these ideas are bad; their value just depends heavily on the code complexity they introduce as well as the gain you see for using them.