Originally Posted By: Frederick_Lim
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




Last edited by AlbertoT; 03/24/10 18:04.