Comentarios
Responder
Ahora, para una respuesta menos frívola, con algunas sugerencias. No los tome como recomendaciones de implementación, más bien como ejemplos de uso posible.
- Constructor: configure la entidad basada en componentes un componente a la vez, según los datos
- Método de fábrica: cree NPC o widgets GUI basados en una cadena leída de un archivo
- Prototipo: almacene un carácter «Elf» genérico con propiedades iniciales y cree instancias Elf clonándolo.
- Singleton: este espacio se dejó deliberadamente en blanco.
- Adaptador: incorpore una biblioteca opcional de terceros envolviéndola en una capa que se parece a tu código existente. Muy útil con DLL.
- Compuesto: crea un gráfico de escena de objetos renderizables o crea una GUI a partir de un árbol de widgets
- Fachada: simplifique las bibliotecas complejas de terceros al proporcionar una interfaz más simple para hacer su vida más fácil más adelante.
- Flyweight: almacene los aspectos compartidos de un NPC (por ejemplo, modelos, texturas, animaciones) por separado de los aspectos individuales (por ejemplo. posición, salud) en un principalmente de forma transparente
- Proxy: cree pequeñas clases en un cliente que representen clases más grandes y complejas en un servidor, y reenvíe solicitudes a través de la red.
- Cadena de responsabilidad: maneje la entrada como una cadena de manipuladores, 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é activo), luego el juego (por ejemplo, para mover un personaje)
- Comando: encapsular la funcionalidad del juego como comandos que se pueden escribir en una consola, almacenar y reproducir, o incluso programar para ayudar a probar el juego
- Mediador: implementar 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 de IA)
- Observador: hacer que la representación renderizable de un personaje escuche eventos de la representación lógica, para cambiar la presentación visual cuando sea necesario sin la lógica del juego necesita saber algo sobre el código de renderizado
- Estado: almacena NPC AI como uno de varios estados, por ejemplo. Atacar, vagar, huir. 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á deambulando, etc.)
- Estrategia: cambiar 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 realizar búsquedas de ruta y planificación más genérica
- Método de plantilla: configure un Rutina genérica de «combate», con varias funciones de gancho para manejar cada paso, por ejemplo, disminuir munición, calcular la probabilidad de golpe, resolver acertar o fallar, calcular el daño, y cada tipo de habilidad de ataque implementará los métodos en su propia forma específica
Algunos patrones se dejaron de lado por falta de inspiración.
Comentarios
Respuesta
Respuesta
Una cosa que Brandon Eich tuvo el buen sentido de mencionar en Codificadores at Work es que los patrones son trucos y soluciones: [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 una evolución en el lenguaje que agregue los bits correctos.
Como programadores de juegos en lugar de diseñadores de compiladores, rara vez tenemos la opción de evolucionar los lenguajes que usamos, pero podemos aprender a desarrollar nuestro propio estilo para adaptarlo mejor a nuestro lenguaje y requisitos. Los patrones son algo de esto, pero no usar patrones es otra parte, especialmente porque, como dice Brandon, los patrones rara vez 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 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 sus objetos deberían ser más simples para empezar. Los patrones populares son herramientas a las que recurrir cuando los necesitamos para gestionar algo complejo, no herramientas que deberíamos desear utilizar para construir algo complejo al principio.
El buen código (del juego) puede usar patrones, o puede que no. Si usa patrones, está bien, son una gran herramienta de comunicación para explicar la estructura del código a otros programadores en un nivel alto e independiente del lenguaje. Si cree que el código es mejor sin usar un patrón, no se castigue con probablemente lo sea.
Comentarios
Responder
Por supuesto, como han dicho otros , todos los patrones son útiles en las circunstancias adecuadas y parte de aprender a usarlos es aprender a 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 útil en la programación de juegos.
Programación:
- Singleton: No odio este como lo hace mucha gente; se puede usar para cosas como el single- jugador jugador o el lector de teclado.
- Fábrica: le permite crear y destruir objetos de manera eficiente.
- Estrategia: le permite cambiar las estrategias de IA con elegancia.
- Índice espacial : Ayuda a realizar consultas en conjuntos de datos espaciales.
- Compuesto: establece una jerarquía de objetos útil.
- Peso mosca: libera memoria al genéricaizar cosas como enemigos idénticos.
Usabilidad:
- Escudo: protege de la activación accidental de acciones dramáticas.
- Estado: señales visuales del mundo / estado de la interfaz de usuario.
- Cancelación automática del modo: hace que el juego funcione de manera más intuitiva.
- Imán ismo: Autoaiming y fácil selección de unidades.
- Enfoque: Eliminar elementos de UI que distraen.
- Progreso: Universalmente útil.
El libro, por supuesto , entra en más detalles sobre cada uno de estos.
Comentarios
Respuesta
Los sistemas de entidades son un buen tipo de patrón. No es exactamente un patrón de diseño ya que no es estrictamente OOP. Sin embargo, puede mezclarlo con OOP.
Algunos buenos enlaces (comience desde arriba para la introducción):
Comentarios
Responder
Todas. Excepto Singleton. [/ flippancy]
Comentarios
Respuesta
No se trata realmente de patrones, sino de principios básicos detrás de ellos. En «Patrones de diseño: elementos de software reutilizable orientado a objetos» (1995) , el grupo de cuatro (Gamma, Erich; Richard Helm, Ralph Johnson y John Vlissides) recomienda solo dos principios para el diseño orientado a objetos: (1) programa para una interfaz y no para una implementación y (2) favorece la composición de objetos sobre la herencia de clases.
Estos 2 principios son muy útiles en muchas tareas del juego desarrollo. Por ejemplo, muchos programadores de juegos han utilizado una jerarquía de clases profunda para representar las entidades del juego. Hay otro enfoque basado en la composición : objetos de juego basados en componentes. Artículo sobre este enfoque. Aún más enlaces . Es un ejemplo de patrón de decorador .
Comentarios
Answer
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 se conoce la variación del tipo en el momento de la compilación.
Comentarios
Respuesta
Un patrón de diseño que desarrollé a lo largo de muchos años, y que ha sido espectacularmente útil para mí, es algo a lo que me refiero como «conjuntos de definiciones negociados»; cómo resumirlo en términos 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 de la propiedad tenga un objeto de definición correspondiente (un objeto único compartido por valor) que especifique su comportamiento , y se accede a ellos a través de un intermediario central (que, en términos de GOF, puede ser un Registro, una Fábrica o ambos). En mi uso, generalmente también se accede a ellos a través de claves escalares, para facilitar el enlace débil con fines de morfismo en tiempo de ejecución.
Comentarios