Quais recursos pertencem ao mecanismo e quais ao jogo?


19

No momento, eu me pego implementando e testando novos recursos para meu mecanismo de jogo em 2D, codificando-os diretamente no mecanismo. Simultaneamente, eu tenho um jogo de demonstração com suporte a scripts, que deve chamar as funções de mecanismo. Anexo, por exemplo, um movimento fixo de bloco à classe Entity no mecanismo, em vez de criar um script específico para o jogo. Isso definitivamente está quebrando a idéia de um mecanismo geral usado para mais de um jogo.

Existem práticas recomendadas para manter o foco na implementação correta nas partes certas (ou seja, mecanismo x jogo)?

Respostas:


25

Bem, existem algumas maneiras de pensar sobre isso. Uma é listar os recursos específicos que o mecanismo deve ter (o que você pediu aqui.) No entanto, a outra maneira é começar a fazer jogos sem se preocupar muito com o "mecanismo" e, em seguida, os recursos que você achar que estão sendo reutilizados entre vários jogos (em particular, recursos usados ​​em todos os jogos), você deve migrar da fonte de um jogo específico para uma base de código compartilhada chamada "engine".

Porque, no final, o motivo pelo qual você deseja um determinado recurso no mecanismo e não no jogo é que ele é compartilhado entre vários jogos. Normalmente, são coisas como desenhar comandos, controladores de entrada e código de rede. Um mecanismo de jogo 2D terá muitos recursos gráficos 2D, como carregar imagens, uma hierarquia de exibição com ordem z, lidar com planilhas, interpolação, etc. Muitos jogos precisam de simulação de física, embora, por outro lado, muitos não. Enquanto isso, mais coisas "ocultas" usadas em quase todos os jogos incluem temporizadores, mensagens de eventos e até funções matemáticas específicas para o desenvolvimento de jogos (por exemplo, distanceToTarget ()


Longa história curta:

A) O mecanismo deve ter recursos compartilhados pela maioria dos jogos.

B) Você aprende quais recursos são compartilhados criando vários jogos.


7
1 -just start making games without worrying too much about the "engine"
JCM 04/04

1
Bem, just start making games without worrying too much about the "engine"é definitivamente uma boa sugestão.
Christian Ivicevic 04/04

3
Eu concordo com os dois comentários acima de mim, mas a observação "apenas faça jogos sem se preocupar com o mecanismo" foi tirada de contexto e é inútil sem o resto: "e os recursos que você encontra estão sendo reutilizados entre vários jogos (em particular , recursos usados ​​em todos os jogos), você deve migrar da fonte de um jogo específico para uma base de código compartilhada chamada "engine". Em resumo, faça o maior número possível de jogos para que você saiba o que deve estar sob um mecanismo e o que não deve ' t.

2
Essa é uma ótima idéia, pois também impede a implementação de recursos do mecanismo que você realmente não precisa nos seus jogos.
Zachary Yates

2
+1 por manter o espírito da Regra de três .
Joshua Drake
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.