Estou lendo um ótimo livro, Game Coding Complete , e esse livro recomenda enfaticamente o uso da abordagem MVC (Model-View-Controller) , com três camadas principais:
- Camada de aplicação do jogo
- Game Logic
- Visualização do jogo
Para mim, essa abordagem parece um exagero para um jogo de computador móvel.
Qual a sua opinião, por favor? Vale a pena implementar essa arquitetura, mesmo que adicione comunicação extra necessária entre os módulos? Esse design pode consumir tanta energia da CPU que, no final, o resultado seria significativamente mais lento do que se não fosse implementado?
architecture
Bunkai.Satori
fonte
fonte
Respostas:
De alguma forma, apoio o uso de uma estrutura MVC, mesmo para um simples jogo para celular. Se nada mais, isso ajuda com um problema que atormenta os desenvolvedores que não foram mordidos por isso o suficiente: separar o código de exibição da lógica do jogo.
Também vou dizer, porém, que o MVC, como todos os padrões de design, existe para facilitar sua vida . Isso significa que, se, a qualquer momento, permanecer dentro de algum conjunto de regras sobre o que você deve ou não fazer ao usar o MVC está dificultando sua vida, ignore-o . Uma das duas coisas acontecerá: 1) você será mordido mais tarde e depois entenderá por que fazê-lo de maneira diferente em primeiro lugar tornaria sua vida mais fácil a longo prazo, ou 2) nenhuma conseqüência.
A programação de computadores, por sua natureza, obtém muitos seguidores de regras que valorizam a adesão ao princípio elegante em vez de realmente realizar qualquer coisa, e eles adoram propor seu sistema de valores; não deixe que eles façam de você um deles. A coisa mais importante que pode acontecer ao seu jogo é enviá-lo .
fonte
Os designs em tempo de compilação não consomem energia da CPU, a menos que você tenha um compilador incrivelmente abismal. Uma linguagem ou abordagem orientada a objetos não é diferente em características de desempenho do que uma processual. Você não invocará nenhuma sobrecarga adicional para usar o MVC. A modularidade existe no tempo de compilação, e não no tempo de execução. Uma vez que o código é incorporado e otimizado, ele não fará nenhuma diferença.
Muitos jogos modernos realmente executam os modelos e as visualizações em threads separados e obtêm ótimos benefícios de desempenho na maioria das plataformas.
Por fim, o MVC é um bom design que oferece a você maior manutenção e menos bugs etc. de graça . Não há razão para não usá-lo. É como perguntar por que você deve usar um
for
loop em vez degoto
s escritos à mão . A menos que você tenha um design superior em mente, com certeza é melhor do que nada.Edit: Projetos em tempo de compilação não consomem energia da CPU. Projetos em tempo de execução, como herança, obviamente fazem.
fonte
Quase sempre há uma troca entre a clareza do código e os requisitos técnicos (velocidade, memória etc.) do programa. As linguagens orientadas a objetos têm uma sobrecarga em comparação às linguagens procedurais, mas elas demonstraram ter muitas vantagens sobre as linguagens procedurais, especialmente na manutenção de código a longo prazo (bugs, etc.) e também na velocidade de desenvolvimento.
Então, com isso em mente, proponho que vale a pena implementar o MVC como programador de jogos . Seu código seguirá melhor os princípios orientados a objetos, especialmente o encapsulamento , e você provavelmente terá muito mais facilidade em mantê-lo (corrigindo bugs ou adicionando novos recursos).
Por outro lado, certifique-se de terminar um jogo e não gaste tanto tempo trabalhando no "mecanismo" que ele nunca é feito.
Para mais informações, leia a pergunta "Por que o MVC e o TDD não são mais empregados na arquitetura de jogos?" e minha resposta realmente longa.
fonte
a++
será exatamente a mesma quea++
em C (ondea
é um tipo primitivo, etc. etc.). Mas considere uma classe C ++ simples com uma função virtual que faça alguma coisa; essa função virtual incorre em uma sobrecarga pesada vs. uma função C simples, mesmo que o código interno seja idêntico. Linguagens orientadas a objetos têm uma sobrecarga . Desculpe por dizer explicitamente "velocidade". Se alocações extras de memória e outras não resultarem em um programa mais lento, você estará absolutamente correto.