Herança vs Composição

Eu ganho meu dinheiro em C # Geralmente, nesse idioma, eu gosto de desacoplar tudo aos céus usando interfaces. Isso me serviu bem no código corporativo, mas, ao escrever jogos em C #, me vejo tendendo à herança devido à capacidade de definir alguns comportamentos padrão para as classes base. Eu me sinto sujo fazendo isso, como se estivesse desobedecendo a algum deus da arquitetura que disse uma vez "favorecer a composição sobre a herança". Sei que não é preto e branco, mas também sinto que poderia usar interfaces com um pouco mais de trabalho e conseguir praticamente a mesma coisa.

O que outras pessoas fazem? A herança é a abordagem correta para jogos ou devo refatorar em algumas interfaces?

c# architecture

— Peter Short
fonte

As interfaces também não são composição, portanto não está claro o que você está perguntando.

Eu só quero mencionar que, como você está trabalhando com C #, você teria dificuldade em escolher a herança, já que o C # não suporta a herança múltipla verdadeira. O uso do método de interface múltipla é bom até chegar ao intervalo de interface 4-5 e ter que cortar / colar mais de 25 linhas de código entre todas as classes que compartilham a mesma implementação. Existem algumas alternativas, mas são igualmente feias, pois o idioma não fornece suporte direto.

— NtscCobalt 29/10

Respostas:

A herança em jogos é, na verdade, uma das piores coisas que você pode fazer - em particular no que diz respeito às entidades. Leia isso por que. Composição sobre herança leva um longo caminho com os jogos. Quanto a outras áreas do seu motor, isso realmente não importa. Digamos, por exemplo, que você esteja fazendo uma chamada para algum tipo de serviço de rede externo, e você poderá herdar um tipo de serviço genérico para, por exemplo. HTTPService e SocketService - da mesma forma que nos aplicativos corporativos aos quais você está acostumado.

A menos que seu jogo é muito simples, você vai querer usar uma entidade arquitetura baseada em componentes (CBE). A idéia geral é que, com as entidades, a razão pela qual elas são tão comumente compostas e não herdadas é porque você não pode saber até o tempo de execução quais recursos uma determinada entidade terá. Por exemplo, pegue a nave do jogador em um atirador espacial. Você não sabe até certo ponto durante o jogo, quais armas, armaduras, sistemas (ou seja, componentes) que o jogador vai pegar, comprar, vender, perder, destruiu, etc. Portanto, a única maneira realista de modelar isso é através da composição de objetos. O lado positivo desse cenário é que você também pode ter inimigos totalmente personalizáveis, criados da mesma maneira, em vez de inimigos que são sempre exatamente iguais sempre que você vê esse tipo de inimigo. Assim, com os CBEs, você pode ver um cargueiro marciano e pensar: "Ah, ele só tem pequenos lasers, eu vou derrubá-lo", e geralmente isso seria verdade, mas quando você entra no alcance de repente, percebe que ele tem uma bunda grande. arma de buraco de minhoca. Surpresa surpresa!

A componente está removendo o acoplamento implícito da lógica, e isso é BOM.

— Engenheiro
fonte

Obrigado pelo conselho companheiro :) É bom saber que eu não estava ouvindo vozes!

— Peter Short

1 Obrigado para o artigo, eu tenho sentido de fazer isso no meu jogo por algum tempo

— John McDonald

Deve-se notar que, devido à alta inter-dependência das entidades do jogo, essa herança geralmente complica as coisas e torna a manutenção e a extensão uma tarefa complicada. Sistemas de componentes resolver este problema muito bem e outro benifit adicional é o que está listado na resposta acima;)

— James

Também deve-se notar que o "mas quando você chega ao alcance repentinamente, percebe que ele tem uma arma de burro de minhoca. Surpresa surpresa!" é um design de jogo ruim: D

— Jonathan Connell

Surpresas são divertidas, mas surpresas que significam que você morre sem aviso prévio, como um navio de baixo nível que pode OHKO, são apenas frustrantes;) É claro que isso pode não ser o que você quis dizer com sua resposta. Além disso, há muito mais em um jogo do que apenas design de jogo.

— Jonathan Connell

Para quem fala alemão um livro interessante: http://www.amazon.com/Architektur-Kerns-einer-Game-Engine-Implementierung/dp/3639324471/ref=sr_1_1?ie=UTF8&qid=1314875533&sr=8-1

Um olhar mais atento sobre quando e por que usar qual arquitetura pode ser encontrada aqui: /programming/1901251/component-based-game-engine-design

Para mim, eu decido minha arquitetura, dependendo do tamanho do projeto e da possibilidade de estender ou reutilizar o código. Por que investir horas e horas na arquitetura de um micro projeto onde não há chance de você usar o código novamente? Ao mesmo tempo, você pode finalizar o projeto.

Composição versus componentes Os componentes são interessantes, mas na maioria dos projetos / arquiteturas, a composição também funciona (sem sobrecarga baseada em componentes). Depende do que seu sistema de componentes pode fornecer que a composição não pode.

Por exemplo, pegue a nave do jogador em um atirador espacial. Você não sabe até certo ponto durante o jogo, quais armas, armaduras, sistemas (ou seja, componentes) que o jogador vai pegar, comprar, vender, perder, destruiu, etc. Portanto, a única maneira realista de modelar isso é através da composição de objetos.

tudo o que era possível sem componentes há muito tempo também

— idefix
fonte

-1, os componentes são uma forma de composição.

bem, uma forma de, mas não é a mesma, pois eles oferecem recursos diferentes. (Então, eu não entendo o seu comentário e -1)

— idefix

Quando você diz "composição versus componentes", não está claro o que você está comparando, pois os componentes são composição. Você quer dizer componentes dinâmicos vs. componentes estáticos? Qualquer um desses versus a composição de tipos não relacionados nem familiar nem estruturalmente? O que é "sobrecarga baseada em componente"? Nos sistemas de componentes estáticos (e muitos dinâmicos), a sobrecarga é quase nula.

Hum, pontos interessantes. Você se importa de uma discussão um pouco mais detalhada? Caso contrário, gostaria de enviar meu endereço de e-mail em outra plataforma.

— idefix