@ agnasg

La programación de juegos es diferente

04-03-2018 12:16 PM

 

Esta discusión en r/gamedev es interesante (como la que estuve comentando en el post anterior). La discusión gira alrededor de este source code del juego Celeste. Es un archivo de la class Player (escrito en C#, buuu). Son 5500 lineas de if’s, else’s y variables para controlar el juego. He hecho un resumen de todas las posiciones, contradictorias entre si de los comentadores. La conclusión es que yo solo se que no se nada.

Le he agregado un  a aquellos puntos que en mi especializada opinión son los correctos.

 

  • Ninguna función debe exceder de 100 líneas y debe tener una sola responsabilidad. Ningún archivo debe exceder de 250.
  • Se debe utilizar algún programming pattern. Por ejemplo, en este caso sería ideal ECS (entity component system, o entidad-componente-sistema). Entonces las variables se colocan en componentes y el sistema maneja estos componentes.
  • Unity es un mal ejemplo para cualquier cosa.
  • Unity es un buen ejemplo para cualquier cosa.
  • Otro programming pattern interesante puede ser el observador, en donde cada componente envía mensajes y el objeto que debe recibirlo lo captura y lo usa. El resto de los objetos simplemente ignora los mensajes.
  • Utilizar mensajes para comunicación entre objetos es una pesadilla, porque en sistemas complejos es imposible saber lo que está pasando.
  • No se debe ser tan dogmático en relación a cómo programar, cada quien basado en su experiencia debe decidir qué es lo que funciona para él y qué no funciona.
  • Si el equipo de trabajo > 2 la situación cambia y se deben aplicar las mejores prácticas.
  • No hay nada malo con tener muchas variables privadas
  • No se deben tener muchas variables privadas, sino que todo se debe organizar en objetos (usar ECS, de nuevo)
  • El juego que utiliza esto ha sido un éxito, eso demuestra que un código desordenado y sin las mejores prácticas es irrelevante si funciona. Reviews en Steam.
  • No hace falta tener mejores prácticas, refactoring, etc. porque eso aplica en software que debe ser mantenido durante mucho tiempo. No es el caso de este juego. Si fuera un MMO, la situación sería diferente. Relevante xkcd 
  • No estoy de acuerdo con que esto es mal código. Yo no lo usaría para enseñanza, pero la complejidad justifica el estilo.
  • Esto es mal código. Por ejemplo hay un switch donde se selecciona cuál sonido usar dependiendo del valor de una variable. Eso debe estar en un arreglo. De esa forma al agregar/cambiar/eliminar un sonido, solo hay que hacerlo en un solo sitio.
  • Tener buen código es como un seguro: Si todo sale bien, no pasa nada. Si aparece un bug o hay que hacer un cambio, es mejor tenerlo que desear tenerlo.

Esto es relevante para mí últimamente porque estoy desarrollando activamente khpx, un juego espacial, y como ya he dicho en posts anteriones, no estoy usando classes sino  programación estilo C (archivos separados con variables globales) y el stl de c++. No cumple con la práctica de no usar variables globales, pero facilita y acelera el desarrollo (discutido en los posts anteriores).