I know this has probably been asked before and answered just as many times, but after about 20 minutes of searching the forums, I can not find a specific resolution to my question.  I am working on a 2D action platformer and want to implement an elegant and efficient way to manage my game objects.  After reading several forum posts and documents, it seems as though a quadtree or a GGR would suit my needs (basically collision detection and culling).  I have found several examples of the former and one example of the latter (though I believe Farseer may utilize a GGR, but I'm not sure)...

So I suppose my question is - Is one method better/faster than the other?  I have read that it depends on your needs and the type of game that you are making.  And while I know the type of game I want to make, I am not sure how to decide which method would be better.  I will probably have no more than 50 active objects on the screen at any given time, but I want the entity management implementation to adjust dynamically to an objects position on the screen.  Both the quadtree and GGR implementations that I have seen seem like they could accommodate this, but I just want to see if there were any opinions before I decided on one or the other.  Also, which ever I choose, is it possible to use it for both broad-phase collision detection and terrain culling?  Thanks for your time!

If your game is primarily a side-scroller, you may want to go even simpler: Divide your levels up into numbered regions along the X axis. An object can be tagged with a start X and end X for what region it is in and you can have a sorted list of objects for broad-phase sweep-and-prune collision.

Or even have the objects check their X+cameraX,Y+cameraY values to see if they're on screen (plus a little to the area it's checking so the player can't take advantage of this).

If they're not on screen, disable them until the view moves to them.

If you're only going to have a small number of active objects on screen at a time (Less then 200, let's say), you can just go with a brute force solution.

I.E:

foreach(thing c in thingylist)
{
    if(thingylist[ c ].active==true)
    {
        foreach(thing e in thingylist)
        {
            if(thingylist[ e ].active==true)
            {
                collision detection script.
            }
        }
    }
}

You can decide how your enemies will detect objects. They might just care about the floors and walls, so in that case they'd just check through the X,Y list of floors and walls. They wouldn't care about the other enemies, and the player object will handle any collision detection with them.

So in that case:
//collision and AI for enemies.
foreach(enemy c in enemylist)
{
    if(enemylist[ c ].active==true)
    {
        AI scripts.
        foreach(wall e in walllist)
        {
            if(walllist[ e ].active==true)
            {
                Collision detection.
            }
        }
    }
}

Player input scripts.
//Player collision.
foreach(wall c in walllist)
{
    if(walllist[ c ].active==true)
    {
        Player collision detection with walls.
    }
}
foreach(enemy c in enemylist)
{
    if(enemylist[ c ].active==true)
    {
        Player collision detection with enemies.
    }
}

Thanks for the replies!!  I have considered going with brute force and it may be a short-term solution, but I also want to be able to accommodate many more objects in the game should the need arise.  Considering collision and terrain culling are but a few of the systems at work (AI, particles, combat, etc), I don't want to be hampered by an expensive O(n^2) collision algorithm if I can help it. 

To that accord, I am curious to know if there are specific situations where a quadtree or GGR would be more beneficial...  If you have many small objects, or fewer large objects on screen - is one better than the other?  Can either be coded to support those scenarios?  That sort of thing.  I have found a few research papers on the topic, but the information there seems to be rather general in that they say these things can be done, but not so much as how they can be done, which is also something I am interested in.  Thanks again for your time!