¿Cómo diseñar un motor de juego en un lenguaje orientado a objetos? [cerrado]

Cada vez que intento escribir un juego en un lenguaje orientado a objetos, el primer problema que siempre enfrento (después de pensar en qué tipo de juego escribir) es cómo diseñar el motor. Incluso si estoy usando bibliotecas o marcos existentes como SDL, todavía tengo que tomar ciertas decisiones para cada juego, como si usar una máquina de estado para administrar menús, qué tipo de clase usar para cargar recursos, etc.

¿Qué es un buen diseño y cómo se implementaría? ¿Cuáles son algunas compensaciones que deben hacerse y sus pros / contras?

Dudo que alguien pueda decir 'Tienes que hacer esto y aquello y esto y esto tragamonedas con eso usando el patrón X'.

Sin embargo, algunos recursos útiles:
Enginuity - una serie de artículos de construcción de motores en Gamedev.net.
Game Coding Complete - Soy el propietario de este libro, y trata todos los aspectos (bueno, casi) de la programación del juego. También tiene un motor construido en todo el libro.
Game Engine Architecture : este es otro gran libro para el diseño de motores.
Diseño del motor C4 : tomado de mi comentario, pero esto muestra una forma de alto nivel de ajustar cada parte del motor.

Estos pueden ser demasiado para lo que necesita, pero no puede saber demasiado sobre algo, y estoy seguro de que obtendrá un buen plan de ellos.

EDITAR: Olvidé que los artículos de Gamedev se han archivado desde el nuevo sitio, corregido :)

Como ejemplo, así es como está estructurado mi proyecto roguelike actual (en Java). Está utilizando un motor de gráficos 2D, por lo que gran parte del código de renderización ya estaba a cargo de mí. La crítica es bienvenida.

class Game
Esta clase configura la máquina de estado que administra el estado actual del juego. (en un menú vs. comenzar un nuevo juego vs. jugar un juego guardado)

interface State
Cada clase de estado contiene dos bucles: un bucle para actualizar la lógica y un bucle para renderizar. También contienen código para llamar a la Gameclase y solicitar un cambio a un estado diferente.

class ResourceManager
Un singleton que es inicializado por la Gameclase que carga todos los recursos necesarios y permite el acceso a ellos. No me gusta este diseño porque hace que sea difícil cargar / descargar recursos en diferentes niveles, por ejemplo. Probablemente diseñaría esto de manera diferente si estuviera comenzando de nuevo.

class Map
Un mapa contiene una serie de mosaicos y una lista de todas las criaturas y elementos del mapa. Es una clase bastante básica.

class Creature
Las criaturas contienen información sobre sí mismas, incluidos los cálculos de movimiento (lo que requiere que sepan en qué Mapa se encuentran y que puedan consultarlo para descubrir obstáculos). Decidir si hacer esto, o hacer que algún tipo de clase gerente se encargue de todas las criaturas es algo con lo que lucho.

interface AITask
Las criaturas pueden tener una lista de AITasks, que se ejecutan cada vez que se ejecuta el bucle lógico de la criatura. El AITask tiene su propio bucle lógico que emite comandos a la criatura, y una condición de terminación que determina si la tarea se completó con éxito o no.

interface UIElement
Implementé mi propia interfaz de usuario para este motor. Cada UIElement tiene un bucle de representación y un bucle lógico. También tienen un bucle para procesar la entrada del teclado / mouse. Todos los elementos pueden tener una cantidad de elementos secundarios, que se representan después de sus padres, y se hacen cargo de la entrada del teclado / mouse. Esto le permite tener menús con submenús, por ejemplo.

El primer punto importante es que no hay una respuesta "buena" a esta pregunta.

Lo más parecido a una respuesta correcta sería algo como: depende en gran medida del tipo de juego, la plataforma objetivo, las limitaciones (tiempo), etc.

Dicho esto, hay algunos artículos realmente buenos que le mostrarán cómo otras personas han intentado responder a este problema (ya que he tratado de encontrar información sobre esto en el pasado).
Como el pato comunista mencionó la enginuidad artículo sobre sobre el desarrollo del juego me ayudó a comprender algunas partes de la arquitectura del juego.

Mi diseño actual es un híbrido de Quake3 / Doom3 y un poco de la biblioteca de clases .NET :)

Tengo dos bibliotecas (estática o dinámica depende de cómo quiera construir / entregar) el Frameworky el Library.

La Biblioteca contiene todas las clases auxiliares que están ahí para ayudar con la producción del software del juego, pero no se limitan a este tipo de producto. es decir, tiene una implementación de una lista vinculada que está optimizada para el código del juego, pero podría ser utilizada por cualquier cosa que necesite el servicio de una lista vinculada.

El Framework es la agalla del 'motor' si quieres llamarlo así. Mucho de esto sigue las filosofías de diseño de Quake3 (solo de una manera más orientada a objetos). Contiene la CLI , la gestión de tiempos, el código específico del sistema operativo y, finalmente, las capas de red, etc.

Estos dos se vinculan con la aplicación real que se está produciendo. losGame si quieres, que contiene el código específico del juego. De la misma manera, Quake3 carga las DLL dependiendo de qué 'mod' se esté reproduciendo.

Para darle una idea de la estructura aquí hay un desglose rápido de carpetas y contenidos para cada lib:

• Marco de referencia
  • IO (clases especializadas de gestión de archivos, clases de impresión de texto (por ejemplo, a la CLI), y registro, etc.)
  • Red
    • Cliente (clases que representan lo que el Framework considera una 'persona jugando / conectada al juego')
    • Servidor (clases para administrar la conexión en el marco y administrar los reproductores)
  • Plataforma (clases de manejo de teclado / mouse / controladores, rutinas específicas del sistema operativo como getTime ())
  • Sistema (clases de muy bajo nivel, como una clase de error para ayudar a imprimir mensajes de error, clases de temporización y la propia CLI).
  • Renderizador (autoexplicativo)
  • etc.

• Biblioteca
  
  • Colecciones (clases que representan colecciones de datos, listas vinculadas / tablas hash, etc.)
  • Matemáticas (clases básicas de ayuda matemática como vectores y matrices)
  • etc.

HTH! Debería darte algunos consejos ...

Cosas para considerar

• Los lenguajes orientados a objetos tienen problemas porque generalmente no tienen funciones de primera clase o no todos los datos son objetos (como enteros o flotantes en Java). Los patrones de diseño abordan estos problemas con varios patrones. Generalmente es más rápido codificar y más fácil de mantener el uso del lenguaje que puede hacerlos (objetos de primera clase); por ejemplo Python (que también permite un diseño orientado a objetos), tendrá una velocidad más lenta.
• Cálculo del evento, al menos para la IA
• Lógica de Hoare, use precondiciones y postcondiciones para al menos probar su código
• Agentes, miren las entidades del terremoto
• Bases de datos relacionales, una forma poderosa de almacenar datos

Buen diseño

• hacer diagrama ER
• hazlo correcto
• cree su base de datos, objetos o estructuras de datos a partir de ella

Los datos son clave para la programación. Si diseña bien sus datos, el algoritmo generalmente emerge de ellos (si no cuenta algunos algoritmos numéricos, como el determinante informático).