Trouble Using Component Base Pattern

Question

I am trying to use a component based pattern on my new project. The last projects I did the old fashioned way. Base class and derive from that until your brain hurts. This time I wanted to do it on a new way with a component approach.

Component Base Summary: The idea is that you build components and compose your objects out of different components e.g. the Player class holds GraphicComponent, PhysicComponent, InputComponent, CameraComponent, ScriptComponent and so on, but an decoration object like a plant only has GraphicComponent and maybe PhysicComponent.

I like this approach. I tried to implement it but I have a little understanding issue.

As far as I understand it, each component has the logic for itself in it, and barely know of other components. But this is the part I don't understand: Let's say we have a RenderComponent which holds the logic for rendering. But each concrete object like a player, a plant an UI-element and so on has to be rendered on a completly different way. The player hast special effects and different animations, the plant is only a sprite and the ui element is a combination of both. Do I put the logic for every different rendering in the RenderComponent all at once e.g. RenderPlayer(), RenderPlant(), RenderUIElement() which does not make sense to me or do I make an Interface out of the RenderComponent and create a specific RenderComponent for each concrete objects like PlayerRenderComponent : IRenderComponenent ?

Update

After reading the Answer from Nick, I did a quick UML-likish diagram to clearify if I got the idea/structure right. The diagram is just an example with a pseudo UML-like diagram an some pseudo example constelations. The Idea is, that the concrete composition objects holds and treats their component as a data structure. They set it, alter it, and read from it to do it's logics. They also can compare Components of other concrete objects for convience and provice their components to higher systems (like managers)

Update 2 After some discussion and a bit of confusion due opposites arguments, I started to google with new keywords I got from the comments and found an article which helped me understand how the system is glued together.

Answer 1

While components may have logic in them, the sort of logic you're talking about (loosely termed batch logic) doesn't exist at the entity level -- instead it exists in the game loop.

This makes sense when you look at a theoretical (but typical) deferred 3D renderer. This renderer may have to run through all objects of similar type (a data member of your entity class/struct); say we're doing a rendering pass for all entities of type == TRANSPARENT. Here, we have certain graphics API functions that must be called just once before and/or after all TRANSPARENT elements are processed, to allow for correct blending. This is common in game engines... you may have heard the term batching. The particles are treated as a batch. They don't act, they are acted upon.

Why? Well, as you've realised, if you were to have such logic contained in each entity, you would not be able to make your API calls just once for the batch of transparent particles; instead those calls would be made per particle, which may be impossible due to performance or other limitations (typically the purpose of batching is to tackle similar processing in the same place (in the code, and linearly in memory in order to improve cache performance, and as batching is such a common pattern in games development, CBEs are typically designed to support this). This is because no entity can know what other entities are doing (to enable this would be architectural folly), so none know whether the necessary rendering calls have or haven't been called yet. So we move this logic "up-and-out".

To conclude: Cycle through all elements of similar "type" together -- this may require a pre-sort or you may already maintain these in different lists -- and process them using one master block of code that is not embedded in entities or components, but instead exists directly or indirectly (through helpers) in your game loop. This will allow you to treat all similar components in the same way, in phases relating to their different properties in terms of physics / rendering / AI etc.

P.S. It is a good idea to start thinking of your entities as data / state rather than functionality, IMO. See Mick West's Evolve Your Hierarchy for more details.