I'm creating a simple 2D game and need some feedback on my collision detection approach. Here is the gist of what I'm going for:

1. Have a collide-able component to signify that an entity can be collided with.

2. Have a mover component that moves an entity (just going with simple pixel movement in my game, no force vector stuff).

3. Have a collision handler class that has access to all entities. It will look at entities that have both a collide-able component and a mover component and see if they collide with anything that has a collide-able component or screen edges (only if they have moved recently).

4. After detecting collisions, the collision handler class will call the mover component to move the entities appropriately (out of walls and that stuff).

I'm very new to this stuff. I'm guessing I would need some spatial partitioning scheme to speed things up? Should all entities be stored in the same data structure? Or should they be separated based on some kind of criteria? Example: stationary objects in one list, movable objects in another, decorations in another, etc...? Thanks in advance.

> mover component ... collision handler

The typical term is "collision response" which may help you get better search results.

> guessing I would need some spatial partitioning scheme to speed things up?

Spatial partitioning helps reduce the number of items you need to test. Instead of testing against all 5731 items in your level, you instead test against 3 items physically near you.

> Should all entities be stored in the same data structure? stationary objects in one list, movable objects in another, decorations in another, etc

Usually there are multiple representations, and often items are referenced in many data structures. You may have meshes that are part of a graphics mesh resource pool, and a mesh may be referenced by many game objects. Game objects may be referenced by their locations in spatial trees, referenced by their location in a scene graph, referenced by their locations in physics systems, and more.

Generally there are pools of similarly-typed objects such as a pool of meshes, a pool of textures, a pool of game objects, a pool of components, but that is not a rule fixed in stone. Every implementation can do different things. Do what makes the most sense for your system.

You are using the term "component" incorrectly, but you get your point across. If you are in fact creating a simple 2d game, then yes, their would be no problem with your proposed solution. A game object can hold simple collision information (along with your draw buffers and required associated data for everything else), which is passed into a check function, then the two colliding objects are moved accordingly. A simple solution for a simple game. A full-blown physics pipeline is not really necessary at that point.

As far as spatial portioning is concerned, that is a fairly straight forward solution to implement depending on the complexity required. Depending on how many collide-able objects you may have at any given time in a scene, it may not even be a concern.