Como ya mencione en un post anterior, estoy trabajando en un viejo zombie que extraje del baúl: khpx, una aventura espacial con satélites asesinos. Gira alrededor del concepto de “eat or be eaten“, o, si no matas te matan. Por aquélla época yo jugaba Tribal Wars , que parece ser un juego de estrategia, pero en realidad es muy simple, si dejas que alguien se establezca cerca de tu pueblo, estás muerto. Anyway, khpx fue programado cuando yo estaba migrando de C a C++, es decir, no usa clases, entre otras cosas. ¡Que refrescante!. El código es claro, todo parece estar a la mano, y modificar lo que sea, o agregar nuevas cosas es simple. ¿Usar clases es complicado? No exactamente, pero hay una metodología que se debe seguir para usarlo, y hace que el código comience a oscurecerse, y funciona más como una camisa de fuerza (de las que usan en los psiquiátricos).

Hay interminables discusiones sobre cómo hacer para programar un juego de forma que sea fácil de mantener, pero no es de eso de lo que quiero hablar, sino del mantenimiento del juego, básicamente de lo que estoy haciendo en este momento con khpx. Las clases permiten agrupar funciones y sus datos, y supuestamente esto es bueno porque puedes generalizar este agrupamiento y crear grupos de grupos con funciones y datos comunes. ¡Te atrapé! Ahí está problema, como se supone que debemos hacer eso, el código resultante es oscuro, y difícil de modificar porque cualquier cambio se replica en el resto del sistema con consecuencias que no puedes descubrir sino horas después lo cual genera una pérdida de tiempo innecesaria. Sí, ya sé, una buena documentación resuelve eso, claro. Que bueno. Maravilloso.

Las clases permiten agrupar funciones y sus datos, pero eso también lo puedes hacer colocando las funciones y datos en archivos separados, con una nomenclatura uniforme. Por ejemplo, los juegos tienen objetos que deben ser manipulados en el ciclo inicialización, actualización, despliegue (init, update, render), entonces colocamos en el archivo las funciones initObjet (), updateObjet (), renderObjet (), y listo. Claro estas funciones pueden llamar a otras funciones similares dependiendo del tipo de objeto, y eso es todo, sin más complicación.

Por eso luego de pensarlo 3 nanosegundos abandoné la idea de migrar khpx a un sistema con clases, apuntadores a objetos, singletons, etc, etc. Me acabo de ahorrar días de no programar el juego programando el juego. Por lo demás, si googleas classes vs. funtions encontrarás comentarios tales como estos, donde palabras más palabras menos la conclusión pragmática es no uses clases. Normalmente.

khpx devlog