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 [glyphicon icon=”thumbs-up”] 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.[glyphicon icon=”thumbs-up”]
• 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.[glyphicon icon=”thumbs-down”]
• Unity es un mal ejemplo para cualquier cosa.[glyphicon icon=”thumbs-up”]
• Unity es un buen ejemplo para cualquier cosa.[glyphicon icon=”thumbs-up”]
• 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.[glyphicon icon=”thumbs-up”]
• 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.[glyphicon icon=”thumbs-up”]
• 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)[glyphicon icon=”thumbs-down”]
• 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 [glyphicon icon=”thumbs-up”]
• 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.[glyphicon icon=”thumbs-up”]
• 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.[glyphicon icon=”thumbs-up”]

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).

• Estaba leyendo este post sobre hacer una “own engine“ (recuerdo una época en que leía los posts completos) y me puso a reflexionar, ¿estoy haciendo una engine propia para khpx? La respuesta corta es sí. Si  entramos  más en detalle, no exactamente. La respuesta completa estará en un futuro post sobre la tecnología detrás de khpx, pero baste decir por ahora que khpx está sólidamente basado en DirectX, que tiene respuesta a casi cualquier cosa que se requiera de un api gráfico. Esto deja por fuera cualquier posibilidad de migración a otras plataformas, pero qué me importa, hace tiempo dejé de preocuparme por la tecnología en sí y me dediqué a programar juegos (al menos las llamadas a DirectX están confinadas a rutinas xxx_render (), eso ayuda, ¿cierto?). En lo que al game engine en sí se refiere, es decir, la estructura que permite hacer el juego, es una amalgama de funciones estructuras alrededor del main-loop. No, no hay nada como esto (Godot engine) detrás de khpx (detrás y adelante de khpx está, khpx). No hay editores, ni Lua, plugins, ni flujo basado en nodos. Solo rutinas del juego: ¿no es eso lo que debe haber detrás de un juego?
• Por cierto que en el mencionado post, aparece como uno de los principales errores que cometen los programadores de juegos generalizar demasiado temprano: es mejor copiar y pegar al ir desarrollando que abstraer las funciones principales y derivar de ellas  (” it’s better to default to copypasting it than to abstracting/generalizing it too early”). Nada puede ser más cierto. El post también menciona algo que yo estoy aplicando en khpx, ciertamente hay unas mejores prácticas de ingeniería de software pero están orientadas a software que va a ser compartido entre grandes grupos de trabajo o el público en general. Si eres un desarrollador solitario, algunas de estas prácticas no son necesarias. Por ejemplo, no hay problema en tener variables globales siempre que sean manejadas correctamente y estén confinadas a un archivo (salvo pocas excepciones). Esto acelera el desarrollo y garantiza hacer las cosas, aunque no sea de la forma más elegante.
• Yo no sé cuántas horas paso sentado programando frente al computador. Con toda seguridad más de 10 horas diarias. Eso es destructivo para mis articulaciones. Por ello, y como un mecanismo anti-stress camino unos 40 minutos diarios, más breves interrupciones para estirar las piernas cada 45 mins. Encontré este artículo que dice que no solamente es suficiente caminar, también hay que usar a su máximo las articulaciones, de otra forma se interrumpe o se desmejora la creación del líquido sinovial, que es lo que mantiene lubricado las articulaciones. Una de las múltiples maneras de usar a su máximo las articulaciones es “agacharse”. Así que voy a incluir esto en mi rutina diaria ya que todavía no me decido a practicar yoga (donde se usan al extremo todas y cada una de las articulaciones). Debemos cuidar nuestra musculatura y huesos, al fin y al cabo, nuestros huesos no están hechos de acero, y por una razón.
• Boom de Yada, Boom de Yada . No me puedo sacar esta melodía de la cabeza. ¡Gracias reddit, gracias por nada!
• Silenciosamente hice unos minúsculos cambios en el menú del lado izquierdo (the sidemenu). Eliminé enlaces a algunos temas que están en el olvido de post de años anteriores, y dejé los que son relevantes para mí en la actualidad. Ya yo no juego ficción interactiva pero leo detenidamente revisiones y comentarios en esa escena. Por ejemplo, este artículo de Gamasutra sobre sistemas de diálogos. Lo tenía guardado desde el año pasado y Emily Short me lo recordó.
• nuklear, otra solución GUI totalmente independiente de la plataforma, 100% en un header desarrollado en C con 0% de dependencias, pequeño (~18kLOC), con características infinitas, fácil de usar con DirectX, opengl*, alegro, gdi, bindings para Lua, Java, Rust, C#, otros. Estuve una mañana examinando los fuentes y va a ser mi solución para ciertos menus de khpx, ya tengo desarrollado nativo en DX el despliegue de ventanas, botones, etc., pero otras cosas sofisticadas las haré en nuklear, entre otras razones por el look profesional y el buen acabado. Recomendado A+++++.

Estoy tratando que ciertos detalles a los que nunca le presto atención, no se escapen esta vez en un pet proyect actual (khpx), incluyendo no tener externs inútiles en los archivos y que las funciones se llamen de una forma uniforme y consistente. Por ejemplo, ¿cómo se debe llamar la función de inicialización de los mapas, init_map () o map_init ()? Estoy descartando initMap () porque estoy dejando la notación Camel solamente para los nombres de las variables locales después del módulo: map_getTheCoordinates (), por ejemplo.

Pues pensaba que yo tenía alguna preferencia linguistica sobre el tema, volviendo a la controversia init_map () vs. map_init (), pero no, resulta ser que en los fuentes de umoria podemos encontrar store_init () y magic_init(), pero también init_signals(). Por otro lado en los de rogue se ve init_player(), init_colors(), init_materials (). Por su parte en doom, predomina InitSlidingDoorFrames (), InitData (), InitThinkers (), etc. Así que no, no hay alguna regla discernible por lo que voy a inventar una, me quedo con map_init (), khpx_init () y help_init (). De esa forma la búsqueda en los drop down menu de Visual studio aparecen ordenados por módulo y por función.

Toda esta atención y dedicación a khpx me resulta inusitada, debe ser que estoy enamorado. Porque eso es amor, eso es estar enamorado: cuando le dedicas el tiempo y tu esmero al objeto de tu amor. Fácil de deducir y entender.

¿Quieren ver como pierdo 4 horas de trabajo? Este bug:

[code]
CUSTOMVERTEX* pV;
for (i = 0; i < MAX_MODIFIED_OBJS; i++) {
pV = pVertices += i * 4;
pV++;
pV->Z = 2.1f;
pV++; pV++;
pV->Z = 2.1f;
}
[/code]

En mi defensa, este bug estaba profundo en el sistema de update antes del final rendering. En khpx el código está extremadamente modulado, con funciones lo más compactas posible (que es como se debe programar) Eso trae como consecuencia el problema de que para conseguir un bug tienes que seguir la secuencia de funciones y un bug puede desaparecer aun cuando sea obvio, como el de arriba.

La idea de esa rutina es colocarle 2.1f a la coordenada “Z” de los objetos de tipo CUSTOMVERTEX con índice 1 y 3. Lamentablemente la variable pV tenía serios problemas al ser inicializada. MAX_MODIFIED_OBJS eran 6 objetos de tamaño sizeof (CUSTOMVERTEX) * 4. Esta rutina generaba la inicialización solamente de los objetos 1, 2 y 4 lo cual parecía algo tan bizarro como imposible. Adiós a 4 horas de productividad echadas a la basura. Que lástima.