Guys, I kind of like the idea of putting 100k components into GameObject and then if I want to use something, I just set the flag to true. The GameObject will be giant, but once I get used to it, I will be ok.

Use the right tool for the job... However, don't do this. It will become a maintanance nightmare. Splitting things up into modules (composition, inheritance, it doesn't matter) has many benefits.

for( auto& object : gameObjects ) { Renderer::draw( object, viewCamera, interpolationRatio ); }

With composition, you should have a separate list of just the Renderable objects, and only loop over those:

for(auto& renderable : renderables) { Renderer::draw(renderable, viewCamera, interpolationRatio); }

The point of composition here is to (somewhat ironically) decompose your GameObject into its component parts. The only thing the renderer needs is the render info; it needs nothing from the GameObject other than its Renderable component.

Another way to think about: rather than your system pulling Renderables out of the list of game objects, a game object should push its Renderable into the systems. Invert your dependencies.

You really really don't want that update pattern you posted. It doesn't scale, it's slow, it's messy, and it's _more complicated_ than needed so you aren't even really saving yourself any effort by using it. :)

Remember, you might not even want to walk components in a simple list, because that means you aren't doing any kind of efficient scene graph walking and culling. So even if you didn't use components, you'd still want entirely separate lists between "all game objects" and "game objects organized in a spatial partioning data structure." :)

The one tricky case that tends to lead people to tie components and gameobjects together is the transform matrix/data. e.g., game logic needs to know where things are, graphics needs to know where things are, and physics controls where things are. However, those can still all be separated fairly cleanly. The most naive way is to make a Transform component and just have your Renderable and Physics components hold references to the Transform component when initialized. For a simple engine like you're working on, I'd start there.

The key point here: put your components into their own lists if they need to be walked or iterated over. That's basically a part of ECS, but is waaaaaaay simpler than a "full" data-driven ECS. It can be as simple as this (using some globals because it's a short example and I'm lazy):

// nice simple GameObject with static composition, just like you wanted
GameObject::GameObject() {
  // transform is a separate object so it can be shared between modules
  // without introducing a dependency on GameObject
  _transform = make_unique<Transform>();

  // renderable is a completely stand-alone object with a dependency
  // on transform (and whatever resources it needs) and nothing else,
  // though note that this shouldn't be in GameObject probably since
  // you might have objects that have no visuals, e.g. trigger zones
  // or sound sources
  _renderable = make_unique<Renderable>(*_transform);
}
 
void Renderer::render(Camera& camera) {
  // renderable is only walking the known renderables, so if some GameObject variant
  // has no renderable, it won't be in this list, and there's no need to query every
  // possible GameObject variant for a Renderable
  for (auto& renderable : gRenderables)
    draw(renderable->getMesh(), renderable->getTransform(), camera);
}
 
// NOT how I'd recommend registering Renderables in real code, but it suffices for the example
Renderable::Renderable(Transform& transform) : _transform(transform) { gRenderables.insert(this); }
Renderable::~Renderable() { gRenderables.erase(this); }

What you should take away from this is that using composition _simplifies_ code. And you don't need to go anywhere near any ECS framework nonsense to get 90% of the benefits of composition.

there is no terrible code or pattern, there's just code that is not suited for the purpose

The point we're trying to make is that the solutions you've posted are fairly terrible for the given scenario.

As for your question regarding your character with the magic spell -- to me, that would be an example showing why CollisionBox and Health should not be a part of the GameObject base class. You'd normally derive the player from the GameObject (or a more specialized class deriving from GameObject, as suggested above), and use composition to add in the remaining parts (in this case, the special stuff for collision and health).

Another potentially solution if Collision were derived from another class would be to have collision flags in the collision info, and be able to basically turn off collision against walls, etc. dynamically. You will at some point probably want this anyway, because everything will not collide with everything else the same way. A prime example here was actually given by SeanMiddleditch, with trigger zones. Certain trigger zones might only be triggered by certain types of entities, which could be implemented with various flags.

Okay, imagine I have classes Monster, Missile and Castle. And they all have a Renderable component in them. Now I want to push them into a vector in order to draw them at once. //Create and fill vector. std::vector> renderables; renderables.push_back( make_unique( glm::vec3( 3.0f, 0.0f, 3.0f ), myResources.monsterAnims, myResources.objectShaders, myResources.getHeightMap() ) ); renderables.push_back( make_unique( glm::vec3( 3.0f, 0.0f, 3.0f ), myResources.missileAnims, myResources.objectShaders ) ); //And so on.... Is this what you mean? And one more question, if you have the time.

I'm not sure what the make_unique is trying to accomplish with these examples. Are those your GameObject sub-classes? You don't put GameObjects into the renderables list - you should only put their Renderable components into the renderables list. There is no reason to sub-class Renderable for each possible GameObject type. You'd only subclass Renderable for things that are drawn using entirely different code; e.g., two sprites are identical other than the resource they use, so they use the same Renderable.

So a Monster and a Missile both have a Renderable component. Just add that to your renderables list.

Look at the example I posted earlier. It's the creation of the components there that registers _the components_ in the renderables list. You can structure that code in many ways, but the key part is that the components live in the specific list, not the game objects. The game objects live in their own list of all game objects. Yes, there's many lists - one for all game objects and then another list per component type (for any component that you need to iterate over, at least).

Imagine I want to create a MegaFatMissile that is kind of really like a normal Missile but it's fat and does a lot of damage, but it recharges slower. And I feel kind of lazy and I want to inherit the MegaFatMissile from the normal Missile instead of copy pasting a few components. Is it ok to inherit just once?

It's OK if it solves a real problem that inheritance is meant to solve. I'm not sure that it does in this case.

If your problem is just configuring components, move that code outside of your classes. Something like this:

void addMissleComponents(GameObject& object, Texture missileTexture = data.missileTexture, int missileSpeed = data.missileSpeed, /*etc*/) {
  object.addComponent(make_unique<Physics>(...));
  object.addComponent(make_unique<Renderable>(missileTexture, ...));
  object.addComponent(make_unique<Seeking>(missileSpeed, ...));
}
 
void addFatMissileComponents(GameObject& object) {
  // just like a normal missile, but some different data instead of the defaults
  addMissileComponents(object, data.fatMissileTexture, data.slowMissileSpeed);
}

In other words, remember that your basic unit of composition is _functional composition_. Don't make a class out of something that can just be a function. Don't duplicate function code if you can just use a function parameter to alter the behavior instead.

And if I don't want to inherit at all and want to create a new class that will be really like some previous class of mine, is it ok to add the same components again and just add 1-2 more additional components that are specific to the new class. It's not a problem to me, I'm just wondering if it's bad practice to copy/paste components like that?

It's not bad practice to copy-paste component configuration. There may be better tools available in some engines, but many don't have said tools. In Unity, for example, you'd just drag-n-drop the components you need onto your object prefab; there isn't even any kind of inheritance available at that level. The engine we use at work _does_ have a (multi-)inheritance tree you can use to compose objects, which we make heavy use of, but our engine is not exactly structured the way I would ever recommend for you to structure yours. :)