¿Es correcto mi entendimiento sobre el layout de juegos en capas?

Empecé a explicar cómo se diseña un juego en capas para un amigo mío. Quiero asegurarme de haber explicado las cosas correctamente, así que quería verificar mis pensamientos.

Básicamente, según entiendo, los juegos están diseñados con las siguientes capas, en el siguiente order:

  1. Motor de renderizado
  2. Motor de Física
  3. Motor de juegos
  4. Juego con guiones

¿Es esto correcto? ¿Estoy explicando esto bien?

Cada vez que alguien usa la palabra "motor" en relación con un componente de un juego, la palabra pierde un poco de significado. El término fue inventado en los días de Doom; imagina cuánto significado le queda.

Derecha. No mucho.

"Motor de juego" solía tener un significado bien definido. Hoy en día, "motor" es simplemente un sinónimo exagerado de "biblioteca" o "module".

El "motor de representación" no es más que la parte de una base de código a la que se le dice dónde dibujar cosas, y esas cosas se dibujan allí. El "motor de representación", en un juego bien diseñado (difícil de conseguir, lo sé) no tiene conocimiento de quién le dice qué renderizar o dónde renderizarlo. Lo único que le importa es hacer el renderizado.

El "motor de física" nuevamente es simplemente la parte de la base de código que decide cómo se mueven las cosas y si colisionan. No debe saber ni importar cómo se transmite esta información al usuario. Un motor de física bien estructurado no debería tener dependencies particulares en el motor de renderizado, ni siquiera saber que está alimentando un motor de renderizado. Simplemente mueve cosas.

El "Motor de juego" es un concepto tan nebuloso que no existe.

Un "juego de secuencias de commands" (una de estas cosas no es como la otra) es un juego que tiene secuencias de commands que controlan algunos aspectos de la misma. ¿Qué aspectos depende del desarrollador del juego? Algunos juegos exponen el renderizador directamente al guión, por lo tanto, codifica la mayor parte del juego en el guión. Otros solo exponen cosas básicas como la capacidad de generar entidades en ubicaciones fijas y pnetworkingefinidas para las secuencias de commands. La mayoría están en medio. Obviamente, algunos ni siquiera tienen scripts para empezar.

En última instancia, ninguno de estos modules necesita tener alguna relación entre ellos. Se puede decir que están compuestos jerárquicamente, pero ninguno de ellos necesita saber que el otro existe para hacer su trabajo.

Esta pantalla de Game Engine Architecture (ISBN 1568814135) proporciona una visión general bastante buena de los componentes que puedes encontrar en un motor de juego típico.

No estoy seguro de que puedas explicarlo en términos de capas. Un motor de juego tiene muchos componentes, algunos de los cuales mencionas, pero están interconectados de varias maneras.

En primer lugar, creo que el # 3 en la list no tiene sentido.

En segundo lugar, Renderización y Física pueden o no estar conectadas directamente (la mayoría de las veces el renderizador depende al less un poco de física para la colocación de objects, etc.) y pueden o no ser controladas por un administrador de escena personalizado. Esto también implica controlar las entidades escritas.

Yo diría que los componentes son iguales que actúan principalmente de forma independiente, pero que pueden acceder a los datos de los demás si lo necesitan.

Bueno, no del todo. El process no es necesariamente tan lineal, y lo que ha enumerado aquí es principalmente lo que se requiere de los progtwigdores.

Dependiendo de los requisitos, algunas de estas cosas no son necesariamente necesarias. El motor de representación se necesita para juegos 2D o 3D, pero para juegos que solo dependen del sonido o de alguna salida de dispositivo periférico o tal vez no sea necesario. La física no es necesaria para una amplia gama de juegos. El motor de juego es algo que se encuentra en la parte superior de la architecture y se comstack. La creación de secuencias de commands no es absolutamente necesaria para los juegos, y la mayoría de los juegos no tienen soporte para scripts. El scripting es para evitar tener que volver a comstackr en cada pequeño cambio, lo que ayudará, pero para los juegos más pequeños los times de compilation pueden ser tan insignificantes que no importan.

El order en que estos se construyen no es necesariamente estricto. Pero dado que el "Motor de juego" está esencialmente en la parte superior de la estructura, es beneficioso tener las interfaces del motor gráfico y el motor de física consistentes durante el desarrollo. Por lo general, utilizaría las soluciones existentes para charts y física, ya que las soluciones disponibles son lo suficientemente genéricas, usables y robustas, y ahorra mucho time.

Lo que ha ignorado mencionar aquí es que también necesita muchos activos. Sonidos, música, models, texturas, maps, elementos, etc. según el juego.

No realmente capas, más como partes.

Hay una parte que trata sobre dibujar a la pantalla. Otra parte se ocupa de las colisiones. Otra parte trata de la física, es decir, cómo se mueven los objects en el juego. Otra parte trata de sonido y música. Otra parte trata con la input. Otra parte se ocupa de los events del juego. Luego está la parte que contiene todo el contenido del juego real; IE los enemigos, elementos, lo que sea que hace el juego. Podrías tener otra parte dedicada exclusivamente a la IA.

Todas estas partes tienen trabajos que hacer. Idealmente, no les importa quién les está hablando. Lo único que les importa es hacer su trabajo. Consiguen algo, lo procesan y luego escupieron algo. No les importa quién los envió o hacia dónde se dirigen. Lo único que les importa es su trabajo.

Un motor de juego podría considerarse todas las partes que no son el contenido del juego. El contenido del juego serían los activos específicamente únicos para un juego en particular; los files artísticos, los files de sonido, los files de música y los files de códigos que procesan las otras partes en la salida de la pantalla. Son dos mitades de un todo.