¿Cuál es la diferencia entre un marco de juego y un motor de juego?

¿Cuál es la diferencia entre un marco de juego (por ejemplo, XNA con C #, SDL para c ++) y un motor de juego?

¿Los frameworks de juegos usan motores? ¿Un motor de juego encapsula submotores como motores de física, motores de partículas, etc.? ¿Deberían usarse juntos o son mutuamente exclusivos?

¿Supongo que hay motores separados para 2D y 3D?

Realmente no hay definiciones estrictas para "motor" o "marco".

En términos generales, se considera que un motor "hace más" o tiene más herramientas y soporte relacionado que un marco, que en sí mismo es a menudo una colección suelta de funcionalidad relacionada expuesta a través de alguna API unificada.

Con ese fin, las cosas que dicen ser motores pueden usar cosas que dicen ser marcos para lograr la funcionalidad, pero eso no siempre tiene que ser así. Del mismo modo, una cosa que dice ser un motor de juego puede afirmar que sus partes constitutivas (la física y el renderizado, etc.) se implementan con un motor físico o un marco físico. Los tipos de tecnología referidos por ambos términos se pueden usar indistintamente o no.

Puede haber "motores" o "marcos" para casi cualquier cosa: física, sonido y sí, incluso gráficos 2D o 3D.

Realmente es solo un problema de terminología, y generalmente no importa mucho. Desde una perspectiva funcional, una perspectiva centrada en hacer su juego, lo que debería importar es si la tecnología en cuestión ofrece o no lo que necesita para hacer su juego. Si se llama a sí mismo un motor o un marco no tendrá ninguna relación con eso.

Definición simple que uso: puedes construir un motor en un marco pero nunca construirías un marco en un motor. Uno es el esqueleto que determina la arquitectura y el flujo del programa, el otro es el músculo que hace el trabajo.

Para un ejemplo concreto, Artemis es un pequeño marco ordenado para construir sistemas de componentes, pero nunca lo llamaría un motor. Puede construir Artemis Systems y componentes estándar para crear un motor a partir de él.

Un framework es una colección de (generalmente) bibliotecas de nivel inferior y material auxiliar que puedes usar para hacer lo que quieras (gráficos, sonidos, etc.). No hay nada relacionado con el juego en un marco, excepto que generalmente están optimizados o diseñados para hacer cosas que son comunes en los juegos.

Ejemplo: un motor le permite tener una lista de entidades, cada una con una posición en el mapa. Un marco le permite renderizar un objeto 3D en una determinada posición.

Entonces los conecta dando a cada una de sus entidades un objeto 3D y renderizándolas cuando sea necesario.

Y ta-da, tienes un juego.

Para una explicación realmente detallada, recomiendo leer la única Biblia Game Engine Architecture de Jason Gregory. Supongo que es el trabajo más completo sobre este tema desde que se publicó. No solo maneja la parte de C ++, sino que también es importante para cada programador de motores de juegos que respalda la teoría / arquitectura. Es un buen punto de partida independiente del idioma. Para obtener una visión general de lo que estamos hablando es de esta imagen del libro

Déjame intentar responder la pregunta.

Lo que escriba será código :-) después de años de experiencia, escriba lo que necesita y cómo lo necesita o utilice lo que le proporciona lo que necesita.

Los términos motor y marco provienen de la arquitectura de software junto con otros términos. Entonces, comencemos con los términos básicos y avancemos.

Biblioteca

Ejemplos típicos: una biblioteca matemática que proporciona todos los tipos y funciones básicas para cálculos matemáticos (Vector, matriz, ...) o una biblioteca de imágenes (jpeg o png) que proporciona la funcionalidad para escribir imágenes jpeg o png

En Unity 3D Math es una biblioteca matemática.

Teoría: un libray proporciona características dedicadas en torno a un tema (por ejemplo, matemáticas) Y el programador lo solicita a pedido .

Alguna vista previa: puede haber bibliotecas que contengan marcos, también conocidos como una biblioteca de marcos.

Marco de referencia

Teoría: un marco introduce una inversión de control . Esto significa que el desarrollador la mayoría de las veces no llama a los métodos del marco, pero el marco llama al código del desarrollador. Las excepciones son cuando tiene que integrar la biblioteca de marco en su código y debe iniciar el marco. Una biblioteca de marco proporciona todos los métodos, funciones e interfaces para un marco con un uso dedicado. Entonces los marcos pueden estar en una biblioteca.

Ejemplo típico: Unity 3D MonoBehaviour proporciona métodos como Awake, Start, OnUpdate. El desarrollador implementa estos métodos y luego estos métodos son llamados por el marco (gestión de objetos de juego) (esta es la inversión de control) . Lo mismo con los métodos OnCollisionEnter, OnCollisionExit. Están en el mismo Monobehaviour pero apuesto a que son llamados por el marco de la física.

Una vista previa: motor, tiempo de ejecución, editor, SDK

Dado que el término motor siempre fue un poco vago y todavía lo es (y no mejora con los desarrollos tecnológicos posteriores) alguna explicación preliminar.

El término motor se usa para varias cosas y no se puede decir de manera única cuál es la correcta. En 2004, cuando tuve contacto por primera vez con los motores de juegos de escritura, también fue vago. Tenías un motor de juego en el sentido de algún tipo de código que cargaba datos predefinidos y te permitía jugar el juego. Como carga datos predefinidos, se denominaron motores controlados por datos. Los compilas una vez y los datos externos podrían haber sido juegos diferentes sin recompilarlos. En algún momento esto fue lo mismo que un tiempo de ejecución.

El editor es claro. Le permite definir los datos predefinidos cargados por el motor / tiempo de ejecución.

Un motor con un editor se llamaba SDK (por ejemplo, Hammer SDK).

Luego hubo / hay motores dedicados. Un motor de phyiscs, motor de renderizado, motor de sonido, motor de gestión de objetos de juego, motor de red, ...

En mi opinión personal, esos no son motores (especialmente un motor de renderización NO ES un motor de juego ya que solo renderiza). Cuando busco en Google Engine Engine, los resultados contienen 90% de motores de render puro que no son motores de juegos. Llamaría a todas ellas bibliotecas, pero como pueden cargar datos predefinidos, coincidirían con el término motor basado en datos.

Una última nota breve antes de entrar en detalles: me gradué con éxito con una maestría en ciencias de la computación. Mi tesis de maestría trató el tema "cómo desarrollar el núcleo de un motor de juego". Es decir, la parte del código que agrupa todos los demás motores, gestiona los objetos del juego, el bucle del juego, etc.

Publiqué mi tesis de maestría como un libro (corto). El único comentario en Amazon de un comprador / lector es (después de unos años): no se trata de un motor de juego. Desde que me gradué con éxito y, por lo tanto, he defendido mi tesis contra 3 programadores experimentados (2 de ellos dedicados a juegos y aplicaciones interactivas), creo que he escrito un motor de juego.

Editor

Fácil: le permite definir los datos en el formato que las otras partes los requieren y, por lo tanto, elimina la demanda de escribir esos archivos a mano o utilizar herramientas externas para crearlos.

Esto es lo que hace el editor de Unity 3D.

Tiempo de ejecución

Este término a menudo se usa igualmente con motor (que puede ser correcto o incorrecto).

El tiempo de ejecución ejecuta los datos generados y hace lo que tiene que hacer con los datos. Por ejemplo, mostrarte el juego y dejarte jugar. No crea ningún dato (excepto tal vez guardar juegos) en el sentido de que no puede modificar el juego en sí.

El Unity Web Player es / fue un tiempo de ejecución que te permite jugar juegos de Unity dentro de un navegador web.

Puedes cargar y ejecutar múltiples juegos diferentes con el mismo tiempo de ejecución.

En el caso de la API de secuencias de comandos Unity 3D, existe un corte entre la funcionalidad que funcionará en el juego y la funcionalidad que solo funcionará dentro del editor.

SDK

Este término a menudo también se llama marco .

En aquel entonces, un SDK ha sido un conjunto de herramientas como un editor, IDE (entorno de desarrollador integrado) para programadores, exportadores de formatos de datos y el motor de ejecución.

Por lo tanto, un SDK / framework le proporciona un flujo de trabajo y utilidades predefinidos y le muestra una forma (bien diseñada) de cómo puede (fácilmente) crear un juego.

Básicamente, el motor Unity 3D estaría mal ya que encajaría más en la dirección del SDK. Pero dado que Unity es aún más, se necesita una nueva palabra / definición para que coincida con lo que es.

De todos modos, para introducir el otro término, un SDK / framework le proporciona una canalización de desarrollo de juegos predefinida (no solo una cartera de activos, sino quizás, como Unity, una tubería de activos, lógica, compilaciones, implementaciones, ...)

Motor

sarcasmo en Usado para todo, ya que todo el mundo quiere ser genial escribiendo no solo una biblioteca, un marco o un juego, sino mejor escribiendo un motor completo. sarcasmo

Vamos a dispararlo:

Un motor

1. es una pieza de código / software
2. está destinado a ser reutilizado en múltiples proyectos (también puede escribir un motor de juego para un solo juego)
3. para ser reutilizado, el motor del juego separa la parte reutilizable de la parte específica del juego
4. para ser reutilizable (dependiendo de cómo se pretende reutilizar) hay diferentes sabores, como un motor impulsado por datos que carga datos externos

Un motor puede consistir en otros motores múltiples (ya que todo se llama motor hoy en día). Un motor de juego puede incluir

• un motor de renderizado haciendo el renderizado (OTRA VEZ: maldita sea, el código que solo renderiza NO ES un motor de juego)
• un motor de física que hace la física (es un motor de física, no un motor de juego)
• un motor de IA que maneja las cosas de AI (es un motor de IA y no un motor de juego)
• un motor de red (por ejemplo, RakNet) que hace las cosas de la red (es un motor de red, no un motor de juego)
• un motor de audio que hace el audio (es un motor de audio y no un motor de juego)

Un ejemplo para una aplicación basada en un motor central que proporciona un marco basado en complementos para agrupar todo en un modelo de gestión de objetos de juego basado en componentes. Cada subengine (audio de representación) es un módulo agregado al motor del juego como complemento. Cada componente puede ser parte de un subengine / module. Y la gestión de objetos del juego (basada en componentes) es el enlace de conexión entre los módulos separados.

La definición más cercana para Game Engine

Un motor de juego es la parte del código fuente de su juego que proporciona toda la funcionalidad que está destinada a ser reutilizada en múltiples juegos y le permite codificar y ejecutar su juego. Por lo tanto, reúne todas las otras partes del código (renderizado, audio, física, administración de objetos de juego, redes) que son bibliotecas, marcos o motores dedicados (renderizado, física, ...).

El motor del juego es el desastre en el medio.

Como ya dijo @Josh, no existe una definición estricta de marco o motor, pero, en un sentido conceptual, ambas son herramientas muy diferentes.

Un marco contiene una abstracción de API básica para trabajar, lo que le brinda al usuario herramientas de nivel superior para interactuar con la plataforma o la funcionalidad sin (generalmente) preocuparse por el rendimiento, la compatibilidad, etc. En los ejemplos que proporcionó, SDL es un marco, brinda puede utilizar la plataforma y puede construir su software detrás de esa capa sin preocuparse por la administración de ventanas, cosas específicas del sistema operativo, etc. Si desea construir un software completo, necesitará diferentes marcos, por ejemplo, SDL para administrar los medios y material de plataforma, Box2D para gestionar física, etc.

Un motor es diferente, en este caso, la herramienta envía todo lo necesario para el desarrollo, un motor de física le proporcionará todo lo necesario para administrar la física y enviará una API fácil de usar, por lo tanto, si desea construir una simulación de física, No necesitará ninguna otra biblioteca de terceros. Los motores no son más que una colección de marcos, otros motores, interfaces, fragmentos y código general que proporciona todo lo necesario para completar el proyecto sin necesidad de otros terceros ni preocuparse por cosas de nivel inferior.