Arquitetura do mecanismo de jogo MVC (Model-View-Controller) - Sim ou Não? [fechadas]

18

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:

  1. Camada de aplicação do jogo
  2. Game Logic
  3. 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
5
-1 e vote para fechar. Tudo o que vale a pena dizer sobre o MVC nos jogos foi dito em gamedev.stackexchange.com/questions/3426/… , e até agora tudo o que temos aqui é lixo.
@ Joe Wreschnig isso é muito duro, mas eu acho que é verdade ...
— Spooks
@chaos: Na verdade, votei na sua resposta, mas na verdade não precisávamos de outra resposta dizendo "use padrões se eles ajudarem, não se não ajudarem". Ou talvez sim, mas ainda é muito triste. Ainda não sei como me referir a expressões como "Projetos em tempo de execução como herança" que não sejam lixo.
2
@ Joe: Oh, bem, obrigado. :) O argumento de que o POO é livre de custos confunde um pouco a mente. Suponho que, por algum padrão, não devamos precisar de pontos como os meus reiterados, mas noobs acontecem e perguntas duplamente debatidas. Ele também tem a função de deixar os retardatários chegarem ao local como eu, reunindo um pouquinho de rep, apesar da atividade ter morrido massivamente. :) Quero dizer, droga, eu tenho 40K repetições no SO, mas aqui não consigo nem editar uma tag wiki.
— caos

Respostas:

30

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 .

— caos
fonte
Caro Caos, Gosto mais da sua resposta, portanto, estou marcando-a como resposta à minha pergunta. A abordagem MVC adiciona abstração ao design do código. A abstração geralmente adiciona etapas extras de código, que poderiam ser evitadas com um design mais direto. Como entendi corretamente, não preciso me preocupar com o custo introduzido pela abstração adicionada como resultado do design do MVC.
— Backai.Satori
1
Boa resposta, +1 sobre isso. A teoria está ótima e bem, mas pode fazer com que os jogos não sejam enviados se você simplesmente não conseguir.
— James
@ Bunkai.Satori: Adiciona abstração e, na IMO, é uma abstração útil que compensa. Concordo com a sua última declaração, com o esclarecimento de que não é um custo, e que eu acho que você não precisa se preocupar com isso.
— caos
4

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 forloop em vez de gotos 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.

— DeadMG
fonte
-1. MVC é uma decisão em tempo de design. A herança é uma decisão em tempo de design. Ambos ocorrem antes do tempo de compilação e do tempo de execução. Ambos têm grandes impactos no desempenho. Inlining nem sempre torna o código mais rápido. Sua proposta de encadeamento é incrivelmente ingênua. Nada é gratuito.
Obrigado DeadMG pela sua resposta. Basicamente, quero dizer que, com todos os níveis de abstração, o código fica mais lento, à medida que mais e mais etapas intermediárias são adicionadas. O MVC é um design mais abstrato, que provavelmente resultará em mais etapas para realizar a mesma tarefa. Isso teria influência na velocidade, imo.
— Backai.Satori
4

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.

— Ricket
fonte
1
Os idiomas OO não são mais lentos que os idiomas procedurais. Se você escrever algum código em C ++ com deslocamento de bits, não será mais lento que em C. Uma linguagem ou programa não é mais lento em comparação com o procedimento, apenas porque é orientado a objetos. Os programas exibem apenas prejuízos de desempenho porque são mal escritos . Como resultado, sinto a necessidade de rebaixar sua resposta.
— DeadMG
Oi Ricket, obrigado pela sua explicação. Parece muito lógico. DeadMG, bem, por um lado, você está correto. Por outro lado, acho que a abordagem OO adiciona mais bits de informações no código compilado do que a linguagem processual. Esses bits extras de código relacionado ao OO tornam o código resultante mais lento. Você concorda?
— Backai.Satori
3
Whoa agora ... Claro que uma linha simples em C ++ a++será exatamente a mesma que a++em C (onde aé 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.
— Ricket
2
Se a função for virtual, isso implica que o programa precisa escolher entre 2 versões diferentes da mesma função em tempo de execução. (Caso contrário, você não o tornaria virtual.) Nesse caso, você tem um nível extra ou indireto de condicional de qualquer maneira, que seria necessário implementar em uma linguagem processual (por exemplo, através de um ponteiro de função ou instrução switch) . Isso não é sobrecarga - isso é intrínseco ao problema.
— Kylotan
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.