Qual é a diferença entre uma estrutura de jogo e um motor de jogo?

Na verdade, não há definições estritas para “mecanismo” ou “estrutura”.

De modo geral, considera-se que um mecanismo “faz mais” ou ter mais ferramentas e suporte relacionado do que uma estrutura, que em si é apenas uma coleção frouxa de funcionalidades relacionadas expostas por meio de alguma API unificada.

Para esse fim, coisas que afirmam ser motores podem usar coisas que afirmam ser estruturas para alcançar funcionalidade, mas nem sempre precisa ser o caso. Da mesma forma, algo que afirma ser um motor de jogo pode alegar que suas partes constituintes (a física e renderização, etc.) são implementadas com um motor de física ou uma estrutura de física. Os tipos de tecnologia referidos por ambos os termos podem ser usados indistintamente ou não.

Pode haver “motores” ou “estruturas” para praticamente qualquer coisa – física, som e, sim, até mesmo gráficos 2D ou 3D.

É realmente apenas uma terminologia problema, e geralmente não importa muito. De uma perspectiva de funcionalidade, uma perspectiva focada em fazer seu jogo, o que importa é se a tecnologia em questão oferece ou não o que você precisa para fazer seu jogo. Se ele se autodenomina um mecanismo ou uma estrutura, não terá qualquer influência sobre isso.

Definição simples que eu uso : você pode construir um motor em uma estrutura, mas nunca construiria uma estrutura em um motor. Um é o esqueleto que determina a arquitetura e o fluxo do programa, o outro é o músculo que faz o trabalho.

Para um concreto Por exemplo, Artemis é uma pequena estrutura legal para construir sistemas de componentes, mas você nunca a chamaria de motor. Você poderia construir sistemas Artemis e componentes padrão para criar um mecanismo a partir dele.

Comentários

• Na minha empresa, alguém projetou uma estrutura sobre o mecanismo. essa estrutura serve como uma coleção de partes ausentes que o mecanismo não ‘ fornece, unifica coisas que, de outra forma, seriam um pouco desorganizadas em nosso (antigo) mecanismo. E fornece ajudantes para facilitar o desenvolvimento.

Uma estrutura é uma coleção de (geralmente) bibliotecas de nível inferior e coisas auxiliares que você pode usar para fazer o que quiser (gráficos, sons, etc.). Não há nada relacionado a jogos em um framework, exceto que eles geralmente são otimizados ou projetados para fazer coisas que são comuns em jogos.

Exemplo: um motor permite que você tenha uma lista de entidades, cada uma com uma posição no mapa. Uma estrutura permite que você renderize um objeto 3D em uma determinada posição.

Então, você os conecta dando a cada uma de suas entidades um objeto 3D e os renderiza quando necessário.

E ta-da, você tem um jogo.

Para obter uma explicação realmente detalhada, recomendo a leitura deste e only bible Game Engine Architecture de Jason Gregory. Acho que é o trabalho mais completo sobre este tópico desde que foi publicado. Não lida apenas com a parte C ++, mas também e importante para cada programador de motor de jogo a teoria / arquitetura por trás. É um bom ponto de partida independente da linguagem. Para ter uma visão geral, do que estamos falando é esta imagem do livro

Deixe-me tentar responder à pergunta.

O que quer que você escreva, será code 🙂 após anos de experiência, escreva o que você precisa e como precisa ou use o que fornece o que você precisa.

Os termos engine e framework vêm da arquitetura de software junto com outros termos. Portanto, vamos começar com os termos básicos e seguir em frente.

---

Biblioteca

Exemplos típicos: uma biblioteca matemática que fornece todos os tipos e funções básicas para cálculos matemáticos (Vector, Matrix, …) ou biblioteca de imagens (jpeg ou png) que fornece a funcionalidade para escrever imagens jpeg ou png

No Unity 3D Matemática é uma biblioteca de matemática.

Teoria: uma biblioteca oferece recursos dedicados em torno de um tópico (por exemplo, matemática ) AND é chamado pelo programador sob demanda .

Algumas visualizações: pode haver bibliotecas contendo frameworks, também conhecido como sendo uma biblioteca de frameworks.

---

Framework

Teoria: uma estrutura introduz uma inversão de controle . Isso significa que o desenvolvedor na maioria das vezes não chama os métodos do framework, mas o framework chama o código do desenvolvedor. As exceções são quando você precisa integrar a biblioteca da estrutura em seu código e iniciar a estrutura. Uma biblioteca de estrutura fornece todos os métodos, funções e interfaces para uma estrutura com um uso dedicado. Portanto, os frameworks podem estar em uma biblioteca.

Exemplo típico: O Unity 3D MonoBehaviour fornece métodos como Awake, Start, OnUpdate. O desenvolvedor implementa esses métodos e, em seguida, esses métodos são chamados pela estrutura (gerenciamento de objetos de jogo) (é a inversão do controle) . O mesmo com os métodos OnCollisionEnter, OnCollisionExit. Eles estão no mesmo Monobehaviour, mas aposto que são chamados pela estrutura de física.

---

Uma prévia: mecanismo, tempo de execução, editor, SDK

Visto que o termo motor sempre foi meio vago e ainda é (e não fica melhor com novos desenvolvimentos tecnológicos) uma explicação prévia.

O termo motor é usado para várias coisas e não pode ser dito exclusivamente qual delas está certa. Em 2004, quando tive o primeiro contato com a criação de motores de jogos, também estava vago. Você tinha um mecanismo de jogo no sentido de algum tipo de código que carrega dados predefinidos e permite que você jogue o jogo. Uma vez que carrega dados predefinidos, eles foram chamados de motores orientados por dados. Você os compila uma vez e os dados externos podem ser jogos diferentes sem recompilá-los. Em algum momento, isso era igual a um tempo de execução.

O editor é claro. Ele permite que você defina os dados predefinidos carregados pelo mecanismo / tempo de execução.

Um mecanismo com um editor foi chamado SDK (por exemplo, SDK do Hammer).

Então, havia / são mecanismos dedicados. Um mecanismo de phyiscs, mecanismo de renderização, mecanismo de som, mecanismo de gerenciamento de objetos de jogo, mecanismo de rede, ….

Na minha opinião pessoal, esses não são mecanismos (especialmente um mecanismo de renderização NÃO É um mecanismo de jogo, pois faz apenas Renderização). Quando eu procuro no google game engine, os resultados contêm 90% de engines de renderização pura que não são game engines. Eu chamaria todas elas de bibliotecas, mas como podem carregar dados predefinidos, elas corresponderiam ao termo mecanismo orientado a dados.

Uma última observação antes de entrarmos em detalhes: Eu me formei com sucesso com um mestrado em Ciência da Computação. Minha dissertação de mestrado tratou do tópico “como desenvolver o núcleo de um motor de jogo”. Significa a parte do código que junta todos os outros engines, faz o gerenciamento de objetos do jogo, o loop do jogo, etc …

Publiquei minha tese de mestrado como um (curto) livro. O único comentário de um comprador / leitor sobre a Amazon é (depois de alguns anos fora): não se trata de um motor de jogo. Desde que me formei com sucesso e, portanto, defendi minha tese contra 3 programadores experientes (2 deles dedicados a jogos e aplicativos interativos), acho que escrevi um mecanismo de jogo.

---

Editor

Fácil: permite definir os dados no formato que as outras partes exigem e, portanto, elimina a necessidade de gravar esses arquivos manualmente ou usando ferramentas externas para criá-los.

Isso é o que o editor Unity 3D faz.

---

Tempo de execução

Este termo é frequentemente usado igualmente com o motor (que pode estar correto ou incorreto).

O tempo de execução executa os dados gerados e faz o que tem a ver com os dados. Por exemplo, mostrar o jogo e permitir que você jogue. Ele não cria nenhum dado (exceto, talvez, salvar jogos) no sentido de que você não pode modificar o jogo em si.

O Unity Web Player é / era um runtime que permitia que você jogasse jogos Unity em um navegador da web.

Você pode carregar e executar vários jogos diferentes com o mesmo tempo de execução.

No caso da API de script Unity 3D, há um corte entre a funcionalidade que funcionará no jogo e a funcionalidade isso só funcionará no editor.

---

SDK

Este termo é frequentemente também chamado de framework .

Naquela época, um SDK era um pacote de ferramentas como um editor, IDE (ambiente de desenvolvedor integrado) para programadores, exportadores de formatos de dados e runtime / engine.

Portanto, um SDK / framework fornece um fluxo de trabalho predefinido e utilitários e mostra uma maneira (bem projetada) como você pode (facilmente) criar um jogo.

Basicamente, o mecanismo Unity 3D estaria errado, pois se encaixaria mais na direção do SDK. Mas, como Unity é ainda mais, uma nova palavra / definição é necessária para corresponder ao que é.

De qualquer forma, para apresentar o outro termo, um SDK / framework fornece a você um canal de desenvolvimento de jogo predefinido (não apenas um recurso pipeline, mas talvez, como Unity, um pipeline para ativos, lógica, compilações, implantações, ….)

---

Motor

sarcasmo em Usado para tudo, já que todos querem ser legais escrevendo não apenas uma biblioteca, um framework ou um jogo, mas melhor escrevendo um mecanismo completo. sarcasmo off

Vamos acioná-lo:

Um motor

1. é um pedaço de código / software
2. que se destina a ser reutilizado em múltiplos projetos (você também pode escrever um motor de jogo para apenas um jogo)
3. para ser reutilizado, o motor de jogo separa a parte reutilizável da parte específica do jogo
4. para ser reutilizável (dependendo de como isto é destinado a ser reutilizado) existem diferentes sabores, como um mecanismo orientado a dados carregamento de dados externos

Um motor pode consistir em vários outros motores (já que tudo é chamado de motor hoje em dia). Um mecanismo de jogo pode incluir

• um mecanismo de renderização fazendo a renderização (DE NOVO: deus, droga, inferno: o código que faz apenas a renderização NÃO É um mecanismo de jogo)
• um mecanismo de física fazer a física (é um motor de física, não um motor de jogo)
• um motor de IA que lida com as coisas de IA (é um motor de IA e não um motor de jogo)
• a motor de rede (por exemplo, RakNet) fazendo as coisas de rede (é um motor de rede, não um motor de jogo)
• um motor de áudio fazendo as coisas de áudio (é um motor de áudio e não um motor de jogo)

Um exemplo para um aplicativo baseado em um motor central que fornece uma estrutura baseada em plug-ins para reunir tudo em um modelo de gerenciamento de objetos de jogo baseado em componentes. Cada submotor (renderização de áudio) é um módulo adicionado ao mecanismo de jogo como plug-in. Cada componente pode ser parte de um submotor / módulo. E o gerenciamento de objetos de jogo (baseado em componentes) é o elo de conexão entre os módulos separados.

---

A definição mais próxima para o Game Engine

Um mecanismo de jogo faz parte do código-fonte do seu jogo que fornece toda a funcionalidade que é destinado a ser reutilizado em vários jogos e permite que você codifique e execute seu jogo. Portanto, fornece pistas todas as outras partes do código (renderização, áudio, física, gerenciamento de objetos de jogo, rede) que são tanto bibliotecas, frameworks ou motores dedicados (renderização, física, …).

O motor do jogo é a bagunça do meio.

---

Como @Josh já afirmou, não há uma definição estrita de framework ou mecanismo, mas, em um sentido conceitual, ambos são ferramentas muito diferentes.

Um framework contém uma abastraction API básica para trabalhar, dando ao usuário ferramentas de alto nível para interagir com a plataforma ou a funcionalidade sem (em geral) se preocupar com desempenho, compatibilidade, etc. Nos exemplos que você deu, SDL é um framework, ele dá você se abstém da plataforma e pode construir seu software atrás dessa camada sem se preocupar com o gerenciamento de janelas, coisas específicas do sistema operacional, etc. Se você quiser construir um software completo, vai precisar de outro frameworks, fe SDL para gerenciar as coisas de mídia e plataforma, Box2D para gerenciar física, etc.

Um motor é diferente, neste caso, a ferramenta traz tudo o que é necessário para o desenvolvimento, um motor de física irá fornecer-lhe com tudo o que é necessário para gerenciar a física e fornecerá uma API fácil de usar, portanto, se você quiser construir uma simulação de física, não precisará de nenhuma outra biblioteca de terceiros. Os mecanismos não são mais do que uma coleção de estruturas, outros mecanismos, interfaces, fragmentos e código geral que fornecem tudo o que é necessário para concluir o projeto sem precisar de terceiros nem se preocupar com coisas de nível inferior.