EWClay

Yes. You might for example use a physics engine such as Box 2D. That doesn't stop you having a physics component to handle the connection between physics and game logic, it would just not be responsible for actually updating the physics and would not need to store the physics data.

1. Split the components even more. For AI I have a pathfinding component, a chase component, an attack component and so on. I don't have a problem with very specific components for certain tasks either, such as a sliding door component. You may be surprised at how easily a complex system can be broken up and how much simpler the design becomes when you do that.

2. Very low level systems such as physics and rendering that need to know about changes immediately should be managing their own data directly (and the components only carry an ID). For the rest I just iterate through the entity list.

3. Yes, share the data outside the component system and make the components distinct.

4. I would not use inheritance within components at all, except perhaps to derive from an abstract base component. The example of a vertex buffer is a poor one also as rendering APIs do not use inheritance in that way.

5. It doesn't matter much whether you use IDs or pointers. For me, pointers are slightly more accessible because you dont need to go back to the system to get at the data. I would use smart pointers at least to avoid the risk of memory leaks or dangling pointers.

Then in terms of OOP theory, the design pattern you want is this:

http://en.wikipedia.org/wiki/Template_method_pattern

SDL_Flip is needed for every game, so factor it out and don't have the (derived) game state class even be aware of it.

Normally you would classify a point such as the camera position as in front of or behind a plane using the plane equation, which will give a distance which is either positive or negative. This is independent of the coordinate system so you need build the BSP tree only once.

Don't worry about the efficiency of the test; it is just a dot product and very quick compared to the cost of actually traversing the data.

I've considered using inheritance within components, but always backed off from it, choosing to either use multiple components or to make the distinction in a data-driven way.

This is partly because it would require a more complex system to find components. As it is, I can look up components on an entity by type. But with inheritance I would have to check every component to see whether it might derive from the one I was looking for. Then there's the possibility of multiple components of the same base type - which one did I want? This type of confusion is exactly why I went for components over inheritance in the first place.