I generally use an entity/component structure for games or game engines I work with. Have an entity with a map/list/vector of all of the components registered with it. Have most major functionality accessible through the components.

Each component is responsible for an interface to a major function of any object. So, to interface with rendering aspects of your entity, you would have a RenderComponent. The render component would have all the functions needed to interface with your render mesh. Similarly, for physics, you would have a PhysicsComponent with all the functions needed to interface with your physics body.

Also, to keep your different components and interfaces from being too tightly coupled, I highly recommend a messaging system. A message system allows you to send messages between entities, or between components on a single entity, without having to include all kinds of headers or have other developers know much about the underlying functionality of each component class.

I would recommend against putting any render info into the entity class itself if that is indeed the lowest level base class. For example, some entities may not render at all, like an invisible trigger volume that could react to a player or other object entering it. Same with something like physics, because some models may only need to render and never collide with anything. The entity should be fairly empty IMO, and exist mostly to give a common interface between all components on the entity, as well as do things like call some kind of Run() method on each component each frame.

Here's the full source/demo of the last engine I worked on, it uses an entity/component hierarchy and messaging system. Feel free to look at it if you'd like:
http://quickstartengine.codeplex.com/

Quote:Am I correct?

I would say no.

In a component-based system (which I would recommend over a more traditional inheritance-based system), there's no need to create different 'named' entity classes like MoveableEntity, StaticEntity, etc. An entity's characteristics and behavior is defined by the components that make it up, so there's really no need to also have multiple entity classes with different characteristics. (In fact, that would largely defeat the purpose of using a component-based system in the first place.)

Quote:
One more question. Assume my entity system is component based now, and one of the components is PhysicComponent which contains the position of the entity in the world. My scene graph no longer needs to hold the position for nodes? How do I tie the entity with scene graph?
With the old design of entities without components, I'd have a SceneNode with position and entities attached to it. What do I do in the new approach?

Thanks once again.

Position and rotation are two of few things I end up putting into my Entity class. I felt that whether or not an object has physics or a render component, it may still need a position. I have cases where objects have either physics or render, but not both, and if I had put position into the physics component I would've had no position without having physics.

In my Run() method in the PhysicsComponent I ask the physics body what its position is, and I set the Entity's position to whatever that is. I do the same for rotation/orientation. This allows the physics simulation to move the Entity. Conversely, if the Entity's position or rotation is changed from a non-physics method, I end up pushing those changes to the physics simulation.

Quote:Why not having PositionComponent for example?

You could do that if you wanted. How far you want to go with the component system (and how granular you want to make it) is really up to you.

Personally though, I wouldn't bother having separate components for position, orientation, etc. IMO, it makes more sense just to have a single 'transform' component.

As to whether the transform component should be 'optional', that's also up to you. To really go all the way with the 'component' paradigm, you would probably make it optional (after all, there could easily be a game entity - such as an entity whose sole responsibility was to play a background music track - that wouldn't need a transform component). Like lordikon however, I've found it convenient to make the transform component intrinsic to the entity. (In my system it's still a component like everything else, but it's added automatically and all entities have one.) Other component-based systems I've seen seem to handle this the same way.

I've chosen to use a PlacementComponent which provides the global (i.e. world related) position and orientation as both vector / quaternion and composed matrix. Any automatic changes to the placement is done by a plugged in Controller instance. I'm used to define the traditional parenting (i.e. a local space) also by a Controller, namely the ParentingController (you guessed it). However, that is another story. The placements itself are managed by a subsystem called the SpatialServices. This is fine because a dense storage of related data structures gives normally a good cache usage (if the entire batch can be updated at once). The SpatialServices drives the update of the (obviously non-static) placements by invoking the plugged in Controllers. It further allow queries for vicinity of objects and such things.