Usar mvc para jogos

Tambem estou curioso em saber!!!

Ate mais

Pelo que li, o MVC apresentado pelo artigo é aquele adaptado para aplicações web, onde as modificações no modelo precisam ser propagadas via controle. Mas creio que para jogos é possível utilizar a forma clássica do MVC, na qual a visão fica observando as modificações do modelo e o controle não precisa mover uma palha pra fazer isso. Pelo menos eu já fiz alguns jogos simples - como Pong, jogo da velha e batalha naval - e sempre procurei desenvolver dessa forma.

EDIT - há controvérsias na comunidade se MVC trata de camadas ou não. Veja este artigo do Phillip Calçado.

Não é impossivel, no caso MVC é uma arquitetura de camadas, e jogos geralmente usa uma arquitetura de eventos, entao seria apenas fazer uma arquitetura hibrida, onde a camada de view seria projetada para eventos… muitos software já fazem essa mistura…

blz tnaires
Muito interessante este artigo,estou querendo aplicar o mvc para meu jogo de damas, qde acabar acho que vou postar aqui para discutirmos! :lol:

E não é assim?

Pelo menos, na maior parte dos artigos sobre jogos, vemos o seguinte loop:

while (rodando) { leInputs(); processaLogica(); desenhaJogo(); }

O método leInputs() é a parte de controle. Ele recebe os inputs do usuário (seja via controle, joystick, etc), e informa aos objetos de negócio do jogo. O processaLogica() atualiza os demais estados de maneira automática, uma vez que o jogo possui diversos objetos controlados pela máquina.

Model atualizado, vem a parte de desenhar o jogo. Nada mais é que a leitura da situação do model e renderização na tela. O loop de jogo, nada mais é do que o modelo de interação MVC.

Assim fica facílimo incluir novas formas de se controlar o jogo (bastando mapear na parte de controle os novos inputs para as classes de negócio), incluir novos scripts para o jogo (desde que a parte de negócio seja scriptável), ou mesmo, mudar completamente a aparência do jogo.

ViniGodoy:

E não é assim?

Pelo menos, na maior parte dos artigos sobre jogos, vemos o seguinte loop:

while (rodando) { leInputs(); processaLogica(); desenhaJogo(); }

O método leInputs() é a parte de controle. Ele recebe os inputs do usuário (seja via controle, joystick, etc), e informa aos objetos de negócio do jogo. O processaLogica() atualiza os demais estados de maneira automática, uma vez que o jogo possui diversos objetos controlados pela máquina.

Model atualizado, vem a parte de desenhar o jogo. Nada mais é que a leitura da situação do model e renderização na tela. O loop de jogo, nada mais é do que o modelo de interação MVC.

Assim fica facílimo incluir novas formas de se controlar o jogo (bastando mapear na parte de controle os novos inputs para as classes de negócio), incluir novos scripts para o jogo (desde que a parte de negócio seja scriptável), ou mesmo, mudar completamente a aparência do jogo.

Vinni, mas acontece que dentro do metodo desenhaJogo() cada elemento é responsável por se renderizar, neste caso MVC foi pras cucuias nao acha, onde esta o MVC se o model tem acesso ao contexto gráfico?

E onde isso elimina o MVC? O contexto gráfico é parte da camada de view.
Quem se desenha é o Widget, um objeto gráfico e, num sistema bem implementado, ele irá obter as informações de desenho da camada de modelo.

É uma arquitetura muito próxima da do Swing.

O é comum fazerem é deixar o método de desenho dentro da classe de negócio. Nesse caso sim, haveria problemas com o MVC. É uma abordagem comum pq geralmente não é necessário tanto desacoplamento em jogos, uma vez que se trata de um produto fechado. Mas jogos que suportam MODs não costumam a cometer esse “erro”.

ViniGodoy:

E onde isso elimina o MVC? O contexto gráfico é parte da camada de view.
Quem se desenha é o Widget, um objeto gráfico e, num sistema bem implementado, ele irá obter as informações de desenho da camada de modelo.

É uma arquitetura muito próxima da do Swing.

O é comum fazerem é deixar o método de desenho dentro da classe de negócio. Nesse caso sim, haveria problemas com o MVC. É uma abordagem comum pq geralmente não é necessário tanto desacoplamento em jogos, uma vez que se trata de um produto fechado. Mas jogos que suportam MODs não costumam a cometer esse “erro”.

Nesse sentido de ter que suportar MODs, faz até sentido usar MVC porque há um esforço em abstrair ao máximo os aspectos visuais da parte core do jogo. Mas esse esta londe de ser o caso da maioria dos jogos, até um cadastro de funcionário tem mais probabilidade de ter que suportar “MODs” do que um jogo casual. Portanto não diria que é um erro implementar um elemento do jogo (que pertence ao core) dependendo do contexto gráfico (que teoricamente pertenceria a visão):

class Nave {
   ...
  
   public void atira() {...}
   public void atualiza() {...}
   public void paint(Graphics g) {
      // codigo que pinta a nave no contexto gráfico
   }
}

Um sistema bem implementado nem sempre é aquele que adere ao MVC, mas aquele que representa bem uma solução para o problema em questão. Neste caso foi decidido que o Graphics pertence ao model, e não a visão. O que me parece ser bastante razoável em se tratando de um jogo!

Realmente o modelo guardar os seus dados para se desenhar torna a programação de jogos mais fáceis.

É por isso que coloquei “erro” entre aspas, pois só pode ser considerado erro se estivermos olhando do ponto de vista do que prega o MVC. Mas aí entra bem o seu questionamento: MVC é mesmo adequado nesse caso?

Particularmente, também acho que MVC, num jogo fechado e lacrado, pode ser um excesso de preciosismo. Até porque, não se planeja dar manutenção nesse jogo por um período longo de tempo (poucos anos, se comparado com o “tempo indefinido” dos sistemas comerciais).

Agora, não é o gameloop que elimina o MVC, nem o fato de cada objeto se renderizar, e nem o fato de se passar o contexto gráfico. E sim, o fato desse se utilizar as mesmas classes para o contexto gráfico e para o model. Concordo com você que, para absurda maioria dos jogos, casuais ou não, não é uma má abordagem deixar tudo junto. Até porque, ainda é a minoria dos jogos de prateleira que suportam mods de fato. Tanto que, tanto para o Batalha Estelar, quanto para o Campeonato Bola Gelada, não adotei o MVC e fiz exatamente como você comentou. Foi uma abordagem bastante simples, e muito efetiva.

No caso do jogo de damas, pode ser interessante aderir ao modelo. Até porque, pode-se querer no futuro mudar o tabuleiro, adotar novas perspectivas (3D / 2D), ou mesmo inserir uma nova representação do mesmo modelo da dados (tabela com jogadas, por exemplo).

Em muitos jogos 3D, a separação do modelo e negócio é feita pelo próprio Scene Manager. Ele gerencia Scene Objects que, no final, perguntam a um modelo de dados como devem ser renderizados. Dependendo da API escolhida, esses objetos poderão ou não se mixar com as classes de negócio.

Em resumo estavo pensando em criar uma arquitetura MVC mais ou menos desse tipo
onde a classe GameControler tem as seguintes responsabilidades.

1)trata eventos da tela
2)trata eventos de usuário
3)trata eventos de Agentes

public class  GameControler{
   //metodo que recebe e trata todas as ações das  telas
    public void doviewAction(int tipo ,hastable params,Object class){
          if(tipo == ActionView.Menu){
             setViewCurrent(Menu.class);
           }
      }
    //metodo que recebe todas as ações do usuário
    public void gameActionUser(int tipo ,hastable params){
    //metodo que  recebe todas as ações do usuário
      if(tipo  == ActionGame.FIRE){
       drawWorld.shutle.fire(modelGame.x,modelGamey);//Na classe   DrawWorld  é usado   o componente  especifico,  que nesse  caso é a classe shutle. O tiro é desenhado nas coordenadas estabelescidas pelo model
      }
    }
     //metodo que recebe todas as ações pelos respectivos agentes do jogo
    //Todos os agentes teriam duas classes uma de representação canvas e outra   na camada   model,pois de fato aqui entra a I.A do jogo e existem n algoritmos para tal propósito 
   public void gameActionAgent(int tipo,hastable params,Agents agents){
              if(tipo == ActionGame.ESCUDO && agents == ALFREDO){
                  drawWorld.ALFREDO.escudo();
              }
      }
}

A classe DrawWorld em seu loop principal desenharia todos os compontens do mundo,cada componente teria que ser ouvinte do model de tal maneira toda a lógica de collisão faria parte da classe Model.Penso em criar uma thread exclusivamente para tratar e notificar os respectivos componentes para avisar suas respectivas classe canvas na camada de representação.

A classe GameModel iria ofereçer os serviços fundamentais para o jogo tais como; serviço de controle de collisão e notificação ,serviços especificos de cada regra de negoçio em si e por fim os agentes, sempre se necessários.
Sujestões são bem vindas!!

Acho que se voce pensar direitinho não há necessidade de disparar mais do que uma thread. Se isto acontecer esteja preparado para as implicacoes de se lidar com multiplas threads acessando recursos comuns.

Pois é, mas na verdade só teriam três processos não?uma da midlet, uma da classe responsável pelo desenho e por fim a do model.Acho que o impacto não seria tão crucial assim.Em geral, uma aplicação móvel j2me, constuma suportar pelo menos 10 processos sem problemas.Realmente o problema nasce quando vc quer diminuir o acoplamento e aumentar a coesão.Mas em fim, se tiver um sujestão diferente mas que continue dentro do mvc estou disposto a levar em consideração sim!! :D.

Não estou falando de processos, estou falando de threads:

new Thread(this).start();

Não vejo necessidade para mais que uma thread. A thread principal do midlet assim como as threads responsáveis por receber eventos do teclado e de desenho não são disparadas programaticamente. (Até onde sei o método Graphics.repaint() é assíncrono portanto a thread que irá chamar paint() em cada um dos elementos do jogo será fornecida pelo ambiente de execução, e não pelo programador).

blz cara, mas o que sugeres para diminuir o acoplamento e aumentar a coesão ?
E insisto em achar que 3 Threads não afetam tanto o desempenho!!

Putz cara, nada de especial além da velha e boa OO.

Desempenho do que? do programador ? eu acho que quanto mais thread maior probabilidade de voce se ferrar.

De qualquer forma sugiro que de uma olhada no código de outros pra ver como eles fazem. Se quiser me manda um email que te passo um joguinho que fiz algum tempo.

E como você garantirá que a thread de desenho não rode no meio da execução da atualização do model? Ou você vai desenhar o mundo “parcialmente processado”? Da mesma forma, o que impediria a thread de eventos de rodar no meio dessa atualização? Ou usará sincronismo para serializar as duas threads (e nesse caso, pra que duas threads?)

Por fim, se houver thread diferentes para o usuário e para o mundo, acho difícil garantir justiça. Como garantir que agentes diferentes tenham a mesma parcela de processamento, num mundo multi-thread?

Concordo com o mochuara. Acho que uma arquitetura single-threaded com uma boa dose de OO já é mais do que suficiente.

Companheiro, um link com bom conteúdo sobre MVC está aqui.
Espero que ajude em algo quando fala da integração das partes. Abraço.