Off Topic

Promotion
Once-per-game feedback requests or release threads are OK, but a considerable history of participation on /r/gamedev is required. Must be a Text Post.

Devlogs that do not have a focus on being useful to other developers. Do not talk about what advancements occurred on your game this week. That is what Feedback Friday, Screenshot Saturday, the Daily Discussion thread, /r/devblogs, and /r/gamedevscreens are for.

Memes

Explicitly On Topic

AMAs
If you have a unique perspective on something, we'd love to hear it. This is not a way to promote your game/kickstarter/etc, please see above. The focus should be on providing info to the community, not promoting yourself. Be sure to include your education and years of experience to provide some context.

Restrictions

Do not use [tags], assign flair to your post after it's created.

Question posts...
should include what you've already tried and why it was inadequate. Be sure to check the FAQ.

I ALWAYS recommend using a grid of buckets (cells) over any other Spatial Database structure.

You essentially have a grid of cells with some dimension... each cell is a linked-list of all entities that have their upper-left corner in that cell.

Each frame you determine the cell of each entity based on its new position... if it's different then it's current cell, then remove itself from its old cell and add it to the new one.

To do collision detection, you can easily calculate the exact cells under a AABB, and then iterate over the cells checking for collisions between the querying AABB and the AABB of each spatial entity.

The only gotcha with this method that you have is when the right and bottom bounds of the entity extend beyond the boundaries of the current cell. To fix this, make sure you know the largest width/height of any entity and use that as a buffer around the normal query AABB

I implemented one six months ago as a simple method to get away from iterating all the entities, and I've never had to think about it since. I've added a few slightly higher level methods to do spherical and cube style queries (even those are dead simple), but it's all been rock solid, and dead simple.

Sweep and Prune is great if you have objects that are not very dynamic. They have to stay in the same 'order' for it to be efficient.

Quad/Octrees/binary trees etc are great if you have a lower number of objects and there is no boundary for them to be in, like outer-space. It would be for when all objects in the game world need to be part of collision interactions, not just those on screen.

A simple, and often the fastest method which you did not mention is a spacial hash table, otherwise known as a grid. If you only need to check on screen, or in a defined area like a room, or certain distance from the player, just make a grid, put everything in its appropriate box, and check each box from collisions.

Yeah sounds like it is your best option, and should be the easiest to code. The trick is getting the size of the grid right. I normally try to size somewhere between one box for each object and having the box be the size of the object. So if I have a 100 objects on screen that are 5x5 pixels each, a 10x10 grid would be the largest boxes I would do (which would be 80x60 pixels each at 800x600). 5x5 pixel boxes would be the smallest which would be a grid 160x120. The optimal size for your game should be somewhere between those 2 sizes, but probably it will be fast enough anywhere in there.

Consider also an AABB tree, this is much simpler than a quad/oc/kd-tree in dealing with things that AREN'T point data.

AABB tree is a (typically binary) tree of AABB's, with the single rule that each child of an AABB node must be contained within that AABB (But children may themselves intersect).

It still requires updating like quad-trees do, but you don't have any issues with things like quad-trees on allocating objecs to nodes, each object is a single node in the tree defined by its AABB and lookups and intersection queries are still trivial.

For static geometry Octree is the way to go for full 3D games ( quad for 2D naturally ). When you batch your static meshes you cut them to fit perfectly in the Octree. Also, collapse the first few levels as they're unnecessary as they will always be intersected by the camera and never contain anything.

Keep dynamic objects in a separate tree, the best one I've found so far is a structure usually called dynamic icoseptree. There's papers on it online. A proper dynamic icoseptree has a ton of nice advantages. Terrific worst case & possible to deffer tree optimization without any false positives, no degenerate cases ( n-trees for example tends to fall apart when objects overlap edges close to the root ). In practice they perform better than binary trees due to being rather shallow.

I favor sweep and prune along one axis for its simplicity of implementation(the key parts of the algorithm can amount to under 10 lines in many languages), and I've never needed to change away from it when I've used it.

You can come up with situations where it goes quadratic if a lot of stuff gets trapped in a line on the "wrong" axis, or the sort order is changing very rapidly, but if those cases actually become a problem, the code was cheap - rewrite it. As long as the broadphase was designed to be swappable rewriting will not be a problem.

I've also used fixed grid or hashed grid since they are also relatively straightforward. I've never felt a strong need to go the quadtrees route and so have never learned it, not that I have anything against it.