Hi.
Suppose one has a 2D grid map for a game, and one wants to define special "areas" on the map, which could be bounded by a rectangle, ball, or polygon, and to which could be associated an effect or a name or something. I suppose one could store a list of these along with the level map, but what's the most efficient way then to find, given the player's position, which area(s) the player is in? How is this usually handled in games? Is the check performed every time the player moves?
Usually I put a sparse container for such things.
Whatever it is, it's sorted into sectors which are quite a bit bigger than tiles (say 256x256 or 1000x1000 pixel for example). So everytime the player moves, I check the sectors the players bounding box is touching.
Simplest way for such a container is a std::map with sector pos as key and a list of trigger regions as values.
Usually I put a sparse container for such things.
Whatever it is, it's sorted into sectors which are quite a bit bigger than tiles (say 256x256 or 1000x1000 pixel for example). So everytime the player moves, I check the sectors the players bounding box is touching.
Simplest way for such a container is a std::map with sector pos as key and a list of trigger regions as values.
But doesn't this constrain the regions significantly? E.g. they must be a union of macro-tiles/sectors, no? And what do you mean "sector pos as key"? The number of each sector?
They don't have to be a union of tiles. It does make things easier though. It can be anything as long as its sector pos is calculated from the region somehow.
As for sector pos, I meant a simplified position as the sector key (for example the tile position divided by 32). Anything is possible.
For example a tile map of 40x20 tiles can make two sectors, both sized 20x20 tiles.
Or 3x2 sectors, when a sector is sized 15x15 tiles.
In that case I'd put the trigger in all areas. There may be some duplicated checks then but in the total that shouldn't make much of a difference.
In my system (which is 3D BTW), I just abuse the collision and scripting system.
All collision objects are allowed to have a scripted callback. Most objects have no callbacks at all but those having one are internally promoted to a different mangling. This extra mangling essentially collects their collision events and dispatches the scripted calls.
It is more complicated than doing what Endurion suggests but it bought me some piece of mind. The most prominent advantage is that the system is fully generic and flexible. The drawback is obviously the extra effort involved - even with no scripting in the picture.
