¿Cuáles son algunos patrones de diseño de programación que son útiles en el desarrollo de juegos? [cerrado]

Tengo algunos libros sobre Patrones de diseño, y he leído algunos artículos, pero no puedo entender intuitivamente qué patrones de diseño de programación serían útiles en el desarrollo de juegos.

Por ejemplo, tengo un libro llamado ActionScript 3 con patrones de diseño que detalla varios patrones de diseño como Model View Controller, Singleton, Factory, Command, etc.

Como alguien nuevo en esto, no puedo entender cuál de estos sería útil, o de hecho si alguno de estos son los patrones de diseño que debería aprender y tratar de usar. ¿Quizás hay otros patrones de diseño más específicos de programación de juegos que ni siquiera conozco?

Si tienes experiencia usando un cierto patrón de diseño en el desarrollo de juegos, me encantaría escucharlo. Razonar sobre por qué se usó, ejemplos de código o recursos en línea también sería muy útil si los tiene. En este momento estoy más interesado en las implementaciones de ActionScript 3 y C ++, pero definitivamente podría beneficiarme de la experiencia y los ejemplos de cualquier lenguaje.

¡Gracias!

Ahora para una respuesta menos impertinente, con algunas sugerencias. No los tome como recomendaciones de implementación, más como ejemplos de posible uso.

• Generador: configure la entidad basada en componentes un componente a la vez, según los datos
• Método de fábrica: cree widgets NPC o GUI basados ​​en una cadena leída de un archivo
• Prototipo: almacene un personaje genérico 'Elf' con propiedades iniciales y cree instancias Elf clonándolo.
• Singleton: este espacio se dejó en blanco deliberadamente.
• Adaptador: incorpore una biblioteca de terceros opcional envolviéndola en una capa que se parece a su código existente. Muy útil con archivos DLL.
• Compuesto: haga un gráfico de escena de objetos renderizables, o haga una GUI de un árbol de Widgets
• Fachada: simplifique las bibliotecas complejas de terceros al proporcionar una interfaz más simple para facilitarle la vida más adelante.
• Flyweight: almacene los aspectos compartidos de un NPC (p. Ej., Modelos, texturas, animaciones) por separado de los aspectos individuales (p. Ej., Posición, salud) de una manera mayormente transparente
• Proxy: cree clases pequeñas en un cliente que representen clases más grandes y complejas en un servidor, y envíe las solicitudes a través de la red.
• Cadena de responsabilidad: manejar los aportes como una cadena de controladores, por ejemplo. teclas globales (por ejemplo, para capturas de pantalla), luego la GUI (por ejemplo, en caso de que un cuadro de texto esté enfocado o un menú esté arriba), luego el juego (por ejemplo, para mover un personaje)
• Comando: encapsula la funcionalidad del juego como comandos que pueden escribirse en una consola, almacenarse y reproducirse, o incluso crearse una secuencia de comandos para ayudar a probar el juego.
• Mediador: implemente las entidades del juego como una pequeña clase de mediador que opera en diferentes componentes (p. Ej., Lectura del componente de salud para pasar los datos al componente AI)
• Observador: haga que la representación representable de un personaje escuche los eventos de la representación lógica, para cambiar la presentación visual cuando sea necesario sin que la lógica del juego necesite saber nada sobre el código de representación
• Estado: almacene NPC AI como uno de varios estados, por ejemplo. Atacando, errante, huyendo. Cada uno puede tener su propio método update () y cualquier otro dato que necesite (por ejemplo, almacenar de qué personaje está atacando o huyendo, el área en la que está vagando, etc.)
• Estrategia: cambie entre diferentes heurísticas para su búsqueda A *, dependiendo del tipo de terreno en el que se encuentre, o tal vez incluso para usar el mismo marco A * para hacer una búsqueda de ruta y una planificación más genérica
• Método de plantilla: configure una rutina genérica de 'combate', con varias funciones de gancho para manejar cada paso, por ejemplo. Disminuya la munición, calcule la probabilidad de golpe, resuelva el golpe o la falla, calcule el daño y cada tipo de habilidad de ataque implementará los métodos de su propia manera específica

Algunos patrones quedaron fuera por falta de inspiración.

Escribí un libro sobre exactamente ese tema: Patrones de programación de juegos . Los capítulos que están allí pueden ser útiles para usted.

Una cosa que Brandon Eich tuvo el buen sentido de mencionar en Coders at Work es que los patrones son hacks y soluciones alternativas: [los patrones] muestran algún tipo de defecto en el lenguaje. Estos patrones no son gratuitos. No hay almuerzo gratis. Por lo tanto, deberíamos buscar la evolución en el lenguaje que agrega los bits correctos.

Como programadores de juegos en lugar de diseñadores de compiladores, rara vez tenemos la opción de desarrollar los idiomas que usamos, pero podemos aprender a desarrollar nuestro propio estilo para que se adapte mejor a nuestro idioma y requisitos. Los patrones son parte de esto, pero no usar patrones es otra parte, especialmente porque, como dice Brandon, los patrones rara vez pasan sin un rendimiento notable o un costo de memoria o agilidad de código. MVC simplemente no es un gran patrón para muchas cosas en los juegos. Singleton es una solución alternativa para las reglas de inicialización estáticas de C ++, y probablemente no debería hacerlo de todos modos. Factory simplifica la creación de objetos complicados, tal vez tus objetos deberían ser más simples para comenzar. Los patrones populares son herramientas a las que recurrir cuando los necesitamos para administrar algo complejo, no herramientas que deberíamos desear usar para construir algo complejo desde el principio.

Un buen código (de juego) puede usar patrones, o puede que no. Si usa patrones, está bien: son una excelente herramienta de comunicación para explicar la estructura del código a otros programadores en un nivel alto e independiente del lenguaje. Si crees que el código es mejor sin usar un patrón, no te rindas, probablemente lo sea.

Por supuesto, como han dicho otros, todos los patrones son útiles en las circunstancias correctas, y parte de aprender a usarlos es aprender cuándo usarlos. Sin embargo, el excelente libro Core Techniques and Algorithms in Game Programming de Daniel Sanchez-Crespo Dalmau, enumera seis patrones de programación y seis patrones de usabilidad como especialmente útiles en la programación de juegos.

Programación:

• Singleton: No odio este como lo hace mucha gente; se puede usar para cosas como el reproductor de un jugador o el lector de teclado.
• Fábrica: le permite crear y destruir objetos de manera eficiente.
• Estrategia: te permite cambiar las estrategias de inteligencia artificial con elegancia.
• Índice espacial: ayuda a realizar consultas en conjuntos de datos espaciales.
• Compuesto: configura una jerarquía de objetos útil.
• Flyweight: Libera memoria al genérico de cosas como enemigos idénticos.

Usabilidad:

• Escudo: protege de la activación accidental de acciones dramáticas.
• Estado: Indicaciones visuales del mundo / estado de la IU.
• Cancelación automática del modo: hace que el juego funcione de manera más intuitiva.
• Magnetismo: autoajuste y fácil selección de unidades.
• Enfoque: Eliminar elementos de IU que distraen.
• Progreso: universalmente útil.

El libro, por supuesto, entra en más detalles sobre cada uno de estos.

Los sistemas de entidades son un buen tipo de patrón. No es exactamente un patrón de diseño, ya que no es llamativamente OOP. Sin embargo, puedes mezclarlo con OOP.

Algunos buenos enlaces (comience desde arriba para la introducción):

• http://www.csharpfriends.com/Articles/getArticle.aspx?articleID=387
• http://t-machine.org/index.php/2007/09/03/entity-systems-are-the-future-of-mmog-development-part-1/
• http://games.fh-hagenberg.at/wiki/index.php?title=Componentbased_entity_systems

Todos ellos. Excepto Singleton. [/ligereza]

No se trata realmente de patrones, sino de principios básicos detrás de ellos. En "Design Patterns: Elementos de software reutilizables orientada a objetos" (1995) , la banda de los cuatro (Gamma, Erich; Richard Helm, Ralph Johnson y John Vlissides) recomienda sólo dos principios para orientado a objetos de diseño: (1) programa para una interfaz y no a una implementación y (2) favorecen la composición de objetos sobre la herencia de clases.

Estos 2 principios son muy útiles en muchas tareas de desarrollo de juegos. Por ejemplo, muchos programadores de juegos han usado una jerarquía de clases profunda para representar entidades de juegos. Existe otro enfoque basado en la composición : los objetos de juego basados ​​en componentes. Artículo sobre este enfoque. Aún más enlaces . Es un ejemplo de patrón Decorador .

El patrón de plantilla curiosamente recurrente puede ser realmente útil para evitar métodos virtuales y la penalización de rendimiento que puede provenir de las llamadas a funciones virtuales.

Este puede ser el patrón apropiado cuando en realidad no necesita tener un contenedor del tipo de clase base que tenga la interfaz que busca, pero le gustaría tener comportamientos e interfaces con nombres similares.

Por ejemplo, puede usar esto al compilar clases para múltiples plataformas o motores (dx vs. opengl) donde la variación de tipo se conoce en tiempo de compilación.

Un patrón de diseño que desarrollé a lo largo de muchos años, y que me ha sido espectacularmente útil, es algo a lo que me refiero como "conjuntos de definiciones de intermediación"; cómo resumirlo en términos de GOF parece ser controvertido, pero esta pregunta que escribí al respecto en StackOverflow entra en algunos detalles al respecto.

El concepto central es que alguna propiedad de un modelo, como la especie de una criatura, se configura de modo que cada valor posible para la propiedad tenga un objeto de definición correspondiente, un objeto único y compartido por valor, que especifique su comportamiento, y se accede a ellos a través de un intermediario central (que, según GOF, puede ser un Registro, una Fábrica o ambos). En mi uso, generalmente también se accede a ellos a través de teclas escalares, para facilitar el enlace débil para fines de morfismo en tiempo de ejecución.