Onde o código do jogo se encaixa no mecanismo?

Eu queria saber se alguém poderia me dizer como o jogo e o mecanismo de jogo se encaixam no desenvolvimento do jogo. O que quero dizer especificamente é que o mecanismo do jogo não contém realmente um jogo. Os desenvolvedores de jogos constroem um mecanismo e criam uma nova classe que herda do mecanismo, que se torna o jogo?

Por exemplo,

class ShooterGame : public Engine
{
};

Não tenho certeza de onde o código do jogo se encaixa no mecanismo.

Não seja pego no conceito de "motor de jogo". Embora seja verdade que os estúdios de jogos geralmente tenham algum tipo de mecanismo de jogo que eles criam para acelerar o processo de produção de jogos, muitos desenvolvedores independentes ficam ansiosos em tentar criar um mecanismo de jogo que nunca produza algo que funcione.

Um mecanismo de jogo pode ser o que você quiser. Se você encontrar em comum o suficiente entre os jogos e pode subclassificar uma Engineclasse como o seu exemplo, tudo bem. Se um "mecanismo" é realmente apenas uma pequena biblioteca de funções que você achou úteis em jogos anteriores que você desenvolveu, isso também é ótimo. O que quer que isso signifique para você, o conceito de "mecanismo" é apenas um código reutilizável para ajudá-lo a criar mais jogos.

Se você está tentando criar um jogo, não se concentre em criar um motor. Faça um jogo. Quando o jogo terminar e você estiver pronto para fazer o seu segundo, comece a fazer o segundo e você encontrará pedaços que você já criou no seu primeiro jogo; então você pode extrair esses bits em uma biblioteca ou mecanismo, para serem compartilhados entre os dois jogos. É assim que um motor deve ser fabricado. Normalmente, não é algo que você decide escrever antes de fazer um jogo, porque você acaba com toneladas de código que não foram testados e está essencialmente escrevendo coisas antes de saber que precisa delas (portanto, talvez nem precise delas). Isso é como otimização prematura, mas pior.

Então, para responder diretamente à sua pergunta, basicamente um mecanismo de jogo é uma "coisa" reutilizável (biblioteca, ferramenta, estrutura) que um estúdio de jogo usa para ajudar na produção rápida de jogos, e eles geralmente o criam com jogos específicos em mente ou depois de criar vários jogos, extraindo os bits semelhantes e moldando-os em um mecanismo que eles sabem que pode ser usado em jogos futuros. Quase nunca deve ser criado sem retrospecto (dois ou mais jogos já criados) ou planejamento EXTENSIVO.

Basicamente, não estou claro onde o código do jogo se encaixa no mecanismo.

Não se preocupe: trabalhei profissionalmente em jogos onde estávamos um pouco confusos sobre onde o código do jogo se encaixa no mecanismo. ;)

Eu me vejo dizendo isso muito no desenvolvimento de jogos, mas não existe um sistema ou definição padrão para isso. Alguns mecanismos (geralmente para jogos bastante simples) permitem criar novos jogos sem escrever mais nenhum código. Outros mecanismos são basicamente o esqueleto de um jogo existente e você deve alterar o código para adicionar seus recursos. Alguns são como o seu exemplo e são coleções de classes que você pode subclassificar ou agregar em seu próprio sistema. Outros são mais como bibliotecas de código que você adiciona ao seu próprio aplicativo e as utiliza conforme necessário. A única coisa que eles têm em comum é que o mecanismo é a parte do sistema que é adequada (ou afirma ser adequada!) Para vários jogos.

Tenho certeza de que há circunstâncias em que as pessoas fizeram o que você fez acima, mas pessoalmente sempre favoreci os mecanismos como uma coleção de bibliotecas, com bits que você pode usar conforme necessário. Isso daria a você mais flexibilidade de escolha para trocar diferentes componentes, com base na adequação deles a um tipo específico de jogo (por exemplo, você pode escolher uma biblioteca ou renderizador de física 2D ou 3D, dependendo do tipo de jogo) sem ter que ter todas as outras alternativas residentes na memória ou você pode escolher entre renderizadas com base no DX9 / DX11 / etc).