Jump to content
  • Advertisement
Sign in to follow this  
Atridas

Triggers and cell-space particioning

This topic is 3943 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm trying to write the trigger system of my game and I've got some trouble. The think is that i don't want to try EVERY Trigger agains EVERY enemy unit. So I found somethink called cell-space particioning. It's abaout dividing the map i cells and have stored the units instead of all in a single list/vector in a list/vector of each cell. So every trigger have to test only for a few units in the closest cells, my question is, how do I link the "lists" efficently? I dont think that coping 3 or 4 lists into one for every trigger can be so fast, even if they are lists of pointers (almost forgot, C++ with stl). Oh, and is there any "better" or just alternative way (oct-trees, quad-trees, BSP... I read somewere that can be used, but I thought they were for grafics...).

Share this post


Link to post
Share on other sites
Advertisement
You don't have to split up your unit list into multiple lists just because you're using a grid. Each cell can have it's own list of references/pointers to units, while the units are stored inside a single list elsewhere. You only need to update these cell lists, and that's a matter of inserting and removing references - which is much cheaper than moving whole unit objects themselves.

Binary, quad- and octrees are also optimization tricks, and yes, they can be used here. However, are you certain that this is a performance critical area? Have you tested it? It might not be a real issue, in which case you're better off spending your time elsewhere. First get something to work, then optimize it (but don't build something so, that it's extremely hard to optimize ;)).

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!