¿Cuáles son algunos buenos recursos en el diseño de motores de juegos 2D?

Question

Estoy jugando con el desarrollo de juegos en 2D usando C++ y DirectX en mi tiempo libre. Estoy descubriendo que el enfoque de modelado de dominios de problemas empresariales no ayuda tanto como me gustaría;)

Estoy buscando más o menos las "mejores prácticas" equivalentes al diseño básico de los motores de juegos. Cómo las entidades deberían interactuar entre sí, cómo deben representarse las animaciones y los sonidos en un mundo ideal, y así sucesivamente.

¿Alguien tiene buenos recursos que pueden recomendar?

Answer 1

Gamedev.net es generalmente donde me vuelvo para tener una idea de lo que otras personas en la comunidad de desarrollo de juegos están haciendo.

Dicho esto, me temo que descubrirá que la idea de "mejores prácticas" en el desarrollo de juegos es más volátil que la mayoría. Los juegos tienden a ser aplicaciones tan especializadas que es casi imposible dar respuestas de "talla única". Lo que funciona bien para Tetris será inútil con Asteroids, y un modelo que funcione perfectamente para Halo probablemente fracase miserablemente para Mario.

También encontrará rápidamente que no existe un "estándar de la industria" para formatos de textura, malla, nivel, sonido o animación. Todos solo lanzan los suyos o usan lo que sea conveniente para la plataforma. De vez en cuando ve cosas como COLLADA, lo cual es bueno, pero sigue siendo solo un formato intermedio diseñado para facilitar la escritura de exportadores.

Si eres nuevo en el desarrollo de juegos, mi consejo sería este: no te mates por la estructura de tu código en tu primer intento. Pruebe un juego simple, como los asteroides, y simplemente corte hasta que funcione, sin importar cuán "feo" sea el código. Use formatos simples con los que esté familiarizado sin preocuparse por lo bien que aguantarán en proyectos más grandes. No se preocupe por los complementos, máscaras, editores o cualquier otra pelusa. ¡Solo hazlo FUNCIONAR! Luego, cuando hayas terminado con ese primer juego importante, escoge otro, y esta vez limpia uno o dos aspectos de tu código (¡pero no te pases de la raya!) ¡A partir de ahí, itera!

Te prometo que esto te llevará más lejos más rápido que cualquier cantidad de hurgar en línea por el "camino correcto" (esto viene de alguien que ha hecho MUCHA metida de pata).

Y una última idea para ti: si te sientes más cómodo trabajando en un espacio más definido, echa un vistazo a XNA o una biblioteca similar. Predefinirán algunos de los "mejores" formatos para usar y te darán herramientas para trabajar con ellos, lo que elimina algunas de las conjeturas iniciales.

¡Buena suerte, y sobre todo recuerde: se supone que los juegos (y su desarrollo) son DIVERTIDOS! ¡No te dejes atrapar por las cosas pequeñas!

Answer 2

Haz un juego. Cuando hayas terminado, haz otra. Mire lo que le gustó y lo que no le gustó y luego haga otro.

Hablando en serio, puedes leer todas las guías de "mejores prácticas" para el diseño del juego que quieras, pero en última instancia todo se reduce a la experiencia. La única forma de obtener experiencia es sentarse y escribir un juego. Después de hacer esto varias veces obtendrá una mejor idea de cómo escribir un juego.

Answer 3

Casi cualquier libro que tenga Andre Lamothe como uno de los contribuyentes.

GameDev tiene toneladas de artículos también.

Answer 4

Como todavía no se ha mencionado, ¿por qué no comenzar mirando un motor existente que se ha lanzado a la comunidad? Como estás hablando en 2D, recomendaría algo como Abuse. Sí, es antiguo y la mayoría de los bits interesantes están en Lisp, pero el juego se hizo muy popular por un tiempo, lo que significa que estaban haciendo algo bien.

Da la casualidad, creo que el hecho de que gran parte del juego original estaba en Lisp es una lección muy útil. Elija el lenguaje/herramienta más robusto y no se preocupe por el rendimiento. Siempre puedes optimizar las partes lentas en C más tarde.

Answer 5

No puedo estar más de acuerdo con usted: las aplicaciones empresariales no lo preparan para la programación de juegos.

He creado algunos juegos de pequeña escala en python, java, html/php y perl. La estructura básica de un juego, como usted probablemente sabe, es:

bucle principal:
    handleInput()
    updateGameLogic()
    renderImages()

Ahora, eso es todo bien para juegos de una sola pantalla y de un solo hilo, como cualquier cosa de los años 70 u 80. Pero no creo que esta estructura sea particularmente adecuada para juegos de pantallas múltiples (como juegos de rol) ni nada más exótico. No se enhebra muy bien. El código se vuelve bastante original ya que necesitas manejar una variedad de entradas. No escala bien

Sin embargo, antes de criticar demasiado esta metáfora, tenga en cuenta que este es un EXCELENTE lugar para comenzar. Me atrevería a recomendar el aprendizaje de Python/Pygame y comenzar a construir juegos con esa herramienta en lugar de C++, lo que complica el proceso de diseño e implementación. Cuando prototipos en python, verás que el juego toma forma mucho más rápido y se encuentra con problemas independientes del lenguaje.

Para mí, los aspectos más difíciles y que consumen más tiempo de la programación de juegos son los activos gráficos y de sonido. Si bien soy un poco nerd de audio y músico aficionado, crear música creíble y apropiada y SFX es un proyecto por sí solo. No tengo talento gráfico, así que debo confiar en la modificación de imágenes existentes o el uso de las que están disponibles gratuitamente. Afortunadamente, hay fuentes gratuitas ampliamente disponibles que pueden usarse para juegos (y poco más, ya que son casi universalmente malas).

Por último, no hay nada como el código abierto para ver cómo otros proyectos manejan esto. Battle of Westnoth es un juego maduro y de tamaño mediano. Es posible que desee ver lo que está pasando allí. Una vez más, los juegos en python frecuentemente hacen que su código fuente esté disponible, para que puedas ver a través de cientos de proyectos allí. También podría descompilar los ROM de atari 2600, pero eso no le dirá mucho acerca de la programación de hoy. El viejo VCS era un dispositivo dedicado que manejaba sus aplicaciones de una manera muy dependiente del sistema. :-D

Finalmente, también me gusta Andre LaMothe. Tengo su antiguo libro de 1993 que tiene un millón de páginas de grosor. Aunque sigue siendo una buena referencia en algunas ideas de juegos genéricos, una gran parte se obvia con la disponibilidad de bibliotecas y marcos gratuitos que no existían en ese momento.

Buena suerte con su proyecto.