Técnicas para reducir la complejidad en la programación de juegos

Question

En mi tiempo libre programo juegos como un hobby, diferentes tipos de cosas y actualmente nada muy complejo. Cosas como disparos 2d, juegos basados ​​en azulejos, juegos de rompecabezas, etc.

Sin embargo, a medida que el desarrollo de estos juegos continúa, me resulta difícil manejar la complejidad de los diferentes subsistemas dentro de los juegos, cosas como Interface, World View/Model, Manejo de eventos, Estados (Menú, Pausa, etc.), Efectos especiales, etc.

Intento mantener las conexiones al mínimo y reducir el acoplamiento, sin embargo, muchos de estos sistemas necesitan hablar de una manera u otra que no requiera mantener todo su código base en su cabeza al mismo tiempo.

Actualmente trato de delegar diferentes subsistemas y funciones del subsistema a diferentes objetos que se agregan juntos, sin embargo, no he encontrado una estrategia de comunicación que esté desacoplada lo suficiente.

¿Qué tipo de técnicas puedo usar para ayudarme a hacer malabares con todos estos subsistemas diferentes y manejar la complejidad de un sistema en constante crecimiento que debe ser lo suficientemente modular para facilitar el cambio rápido de requisitos?

a menudo me encuentro haciendo las mismas preguntas:

• ¿Cómo objetos se comunican entre sí?
• ¿Dónde debe ir el código que maneja los subsistemas específicos?
• ¿Cuánto de mi código base debo tener en cuenta al mismo tiempo?
• ¿Cómo puedo reducir el acoplamiento entre entidades de juego?

Answer 1

Ah, si hubiera una buena respuesta a su pregunta. Entonces, el desarrollo del juego no sería tan difícil, arriesgado y lento.

intento de mantener las conexiones con un mínimo y reducir el acoplamiento embargo muchos de estos sistemas necesitan hablar en una u otra forma que no requieren la celebración de su entera código base en su cabeza de una sola vez.

Lo hacen, pero a menudo no necesitan hablar de una manera tan directa como la gente cree. Por ejemplo, es común tener los valores de inserción del estado del juego en su GUI cada vez que algo cambia. Si, en cambio, puede simplemente almacenar valores y dejar que la GUI los consulte (quizás mediante un patrón de observador), habrá eliminado todas las referencias de la GUI del estado del juego. A menudo es suficiente para preguntar simplemente si un subsistema puede tirar de la información que necesita de una sencilla interfaz en lugar de tener que empujar los datos en.

• ¿Cómo se comunican los objetos entre sí?
• ¿Dónde debe ir el código que maneja los subsistemas específicos?
• ¿Cuánto de mi código base debo tener en cuenta al mismo tiempo?
• ¿Cómo puedo reducir el acoplamiento entre entidades de juego?

Nada de esto es muy específica para juegos, pero es un problema que se plantea a menudo con juegos porque hay tantos subsistemas dispares que todavía no hemos desarrollado enfoques estándar. Si llevas a cabo el desarrollo web, en realidad hay solo un pequeño número de paradigmas establecidos: el "único archivo de plantilla/código por URI" de algo así como PHP, o quizás el enfoque "modelo/vista-plantilla/controlador" de RoR, Django, más un par de otros. Pero para los juegos, todos están haciendo suyos.

Pero una cosa está clara: no se puede resolver el problema preguntando '¿Cómo se comunican los objetos'? Hay muchos tipos diferentes de objetos y requieren diferentes enfoques. No intente encontrar una solución global que se adapte a cada parte de su juego: entrada, redes, audio, física, inteligencia artificial, renderizado, serialización: no va a suceder. Si intentas escribir cualquier aplicación tratando de encontrar una interfaz IObject perfecta que se adapte a todos los propósitos, fallarás. Primero resuelva problemas individuales y luego busque lo común, refactorizando sobre la marcha. Su código primero debe poder usarse antes de que pueda considerarse reutilizable.

Los subsistemas de juego viven en cualquier nivel que necesiten, no más. Normalmente tengo una aplicación de nivel superior, que posee los objetos de Gráficos, Sonido, Entrada y Juego (entre otros). El objeto del juego posee el mapa o el mundo, los jugadores, los no jugadores, las cosas que definen esos objetos, etc.

Los estados de juego diferentes pueden ser un poco difíciles pero en realidad no son tan importantes como la gente asume son. Pause se puede codificar como un booleano que, cuando se establece, simplemente desactiva las actualizaciones de IA/física. Los menús pueden codificarse como simples superposiciones GUI. Por lo tanto, su "estado del menú" simplemente se convierte en una pausa y mostrando el menú, y al deshacer el juego cuando se cierra el menú, sin requerir una gestión estatal explícita.

Reducir el acoplamiento entre entidades del juego es bastante fácil, siempre y cuando no tenga una idea amorfa de lo que es una entidad de juego que conduce a todo lo que necesita para potencialmente hablar con todo. Los personajes del juego suelen vivir dentro de un mapa o un mundo, que es esencialmente una base de datos espacial (entre otras cosas) y pueden pedirle al mundo que le cuente sobre los personajes y objetos cercanos, sin necesidad de tener referencias directas sobre ellos.

En general, solo tiene que usar buenas reglas de desarrollo de software para su código. Lo principal es mantener las interfaces pequeñas, simples y enfocadas en un solo aspecto. El acoplamiento flojo y la capacidad de enfocarse en áreas más pequeñas del código fluyen naturalmente de eso.

Answer 2

Estoy trabajando en un libro sobre exactamente esta pregunta: Game Programming Patterns.