Still not get the whole picture of component, too abstract for me.
Lets make concrete examples
#case 1 OO programming style - A Race game
You declare a class Pilot() which contain generic variables and generic methods
Then you instance objects : Schumaker, Alonso, Massa etc
In the game play you call
Schumaker.Move(); Massa.Collide();
There are 20 or so pilots in the race who share the same methods and the same variables
However this is not alwayes the case
#Case 2 - Components , an RPG game
You have a lot of different type of characters in the game
In case of 00P , You should
a) To declare few complicated classes and sub classes which instance many objects
b) To declare many simple classes which instance few objects
Or something in between , in any case it is evident that OOP is not an optimal solution
Using components you create your objects and indipendent components, as well
Components are basically a set of variables and functions performing a certain task
Then you attach the components to your objects, just the ones which are stricly needed
Apparently it is an optimal solution for many games
However , I came across some issues
a) It is hard for me to think of generic components which are suitable for a variety of different entities
On the other hand if you code specific components for specific objects you lose the advantage of having generic re usable components
b)The functions of the same class share the same variables and they work well together, having been created togheter
Components, of course, do not, being created as indipendent items
A component must call , for example, an other component even though they are attached to the same object
May be it is just a matter of habit