Apos escolher a estrutura do jogo faltava definir como seria a implementacao dos componentes e da classe GameObject. O decidido foi fazer uma classe Component e todas os componentes herdam essa classe. Alem disso a Component tem um ponteiro de map de GameObjects.Eu prefiri definir a classe GameObject apenas com os componentes e com um identificador.class GameObject {public: typedef int ObjID; GameObject(); virtual ~GameObject(); Collection components;};class Component { //ID do objeto que contem o componente GameObject::ObjID owner;public: //Contem todos os objetos do jogo map *objs; // Todo componente tem um tipo virtual int getType(){ return -1; } GameObject::ObjID getOwner() const { return owner; }}Qualquer atributo como nome do objeto ou outra funcionalidade sera adicionada a classe na forma de um componente. Os componentes podem ser criados pelo objeto ou fora do objeto.Dentro do objeto tem o problema de deixar o objeto mais dificil de reconfigurar e uma vez que uma das vantagens de usar componentes e deixar o objeto mais flexivel, isso e um problema a ser considerado.Fora do objeto o codigo externo passara o componente criado para o objeto e isso mantera a flexibilidade, ja que o objeto podera ser alterado completamente apenas alterando seus componentes. Outra vantagem e a de que, como o GameObject recebe os componentes criados como classes derivadas de Component e por isso ele so conhece essa classe, o codigo esta mantendo um fraco encapsulamento. O problema agora e como seria a comunicacao entre os componentes, uma vez que o componente Movement precisa do componente Position, por exemplo. Ha tres formas:Acesso direto aos outros componentesNa minha opiniao e mais facil de se pensar uma vez que nao e preciso realizar a comunicacao implicitamente utilizando metodos da classe componente. Porem tem a desvantagem de aumentar o acoplamento. A grande vantagem e que e simples e rapida.Modificando atributos do GameObjectDiminui o acoplamento porque os componentes nao sabem da existencia um do outro. E requer informacoes compatilhadas e isso pode causar uma sobrecarga da classe GameObject com informacoes que nem todo objeto do jogo vai precisar. Alem disso a comunicacao seria implicita, o que aumenta a dificuldade de projetar o jogo.Por mensagensE o mais complexo mas tem fraco acoplamento e a classe GameObject e mais simples. O acoplamento seria deixado para o valor das mensagens e da interpretacao da mesma e nao requer informacao compartilhada porque a troca de informacao e feita apenas entre componentes.Nao ha resposta certa e e aconselhado usar um pouco de cada. Em alguns componentes muito relacionados como Movement e Position nao seria tanto problema o acoplamento devido ao acesso direto porque eles ja sao acoplados por um depender tanto do outro. Caso todos os objetos tem alguma informacao comum ela pode ser compartilhada entre os componentes.As mensagens normalmente sao usadas para comunicacao menos importante, como uma comunicacao entre o componente de audio e o componente fisico.Na Action RPG Lib eu optei por comecar usando o acesso direto dos componentes porque eu ainda nao vou descrever todo o sistema antes de comecar programar e e mais facil de pensar. Se no meio do projeto eu perceber