Both.

A significant portion of the player's interactions with the game world can be modeled exactly the same as other entities' interactions, so it makes sense to have the player be just another entity. However, the player will also usually require additionally bookkeeping data that doesn't apply to other entities, so it makes sense to have a dedicated structure for that.

I usually model this by having a "player controller" or some similar object which has a reference to the game entity representing the player. This allows the best of both worlds, and if done cleanly can also allow you to temporarily take control of other entities in the world for diagnostic purposes.

Of course, for games where the player has no avatar in the world itself (Tetris and other puzzle games, for example), this doesn't really apply.

Note specifically that the conceptual "player" can be detached from a physical avatar object, which gracefully handles not only avatar death as Sean mentioned, but also the initialization and shutdown cases where you may want something representing a player to exist before the world and any entities are fully initialized and ready.

As long as the "player controller" and input logging mechanism are synchronized with the game logic time it is just a matter of design. Do not write this:

while ( !Quit ) {
    RenderTime.UpdateBy(FRAME_TIME);
    Entity.Do( WHAT_TO_DO, RenderTime.Delta() ); //Do() is virtual.
    Render();
}

Should be pretty obvious that it is a matter of design when doing this way:

while ( !Quit ) {
    LogicTime.UpdateBy(FIXED_TIME);
    /* You should take the render time into consideration, 
     * but this is just a example. */
    Entity.Do( WHAT_TO_DO, LogicTime.Delta() ); //Do() is virtual.
    Render();
}

Id like to hear more concrete examples on how to make a pluggable controller, like input and ai being able to control a character.

How do you make it reusable, capable of controlling different characters. Im thinking on comands to actions interpreter.

Both ai and input handler need to be aware of comands or actions, so they generate then in the same way. Then a receiver need to receive those and make the stuff happen.

ai / input handler (custom mapping) -> actions (sent to registered targets) -> char controller compo (execute actions) -> movable component (compo::move(dir)), etc

Something like that?

What happens for very different characters with different actions..Im imagining a map of actions to delegates, so the controller would simple call a delegate registered for the action..(that way you dont need inheritance and your char controller components can be in a pool ).

OgreBasicObject

-movable compo (speed, dir, face dir, etc)

-sprite compo

-trafo compo

-collider compo

-ogre compo ( lvl, stats, attacks, etc )

-char controller compo ( custom action mapping, action A -> delegate(ogreCompo::Attack1())

-keyboar input compo ( custom key mapping, key K -> action A -> send to char controller )

or

-basic melee enemy ai agent compo ( some algo -> action A -> send to char conttroller )

Not really sure...

Maybe Im hijacking the thread, should I open another?

In my engine, I have given the player it's own entity in its own structure. However, with that said, I still draw its resources (textures, etc) from a resource list containing not only the resources from the player, but the other objects on the map as well.

I like the main player having it's own data structure / entity because most of the manipulation in my game is on the main player. Other entity lists such as models, when moving east, west, north, or south, in my engine, move around on the screen while the main character stands in the middle of the screen always, creating the effect that he is moving. Having myPlayer variable that points to the Main Player structure makes it easier to keep it exactly where I want it.

Also, myPlayer structure is always going to be visible. Almost all other entities on my resource lists are unloaded at some point and replaced by loading other entities. Keeping myPlayer on it's own structure, according to my resource list abilities anyway, just makes sure I don't accidentally unload the myPlayer. Considering that the main player shouldn't be unloaded (in my game anyway), it has no business hanging out with entities that are temporal.

I hope this helps at all.

Hope this helps.