La película de M. Night Shyamalan me permite reforzar las ideas que he estado meditando durante algún tiempo, que me permitieron formular las siguientes  3 teorías sobre su curiosa carrera como escritor y director :

1. Luego de filmar Señales, M. Night Shyamalan fue secuestrado por unos aliens que llegaron a la tierra en una nave espacial proveniente de otra galaxia. Ellos se encuentran ahora disfrutando de sus películas, pues los alienígenas pensaron que era demasiado buen director y escritor para nosotros y se lo reservaron para ellos. Para que esto no fuera descubierto, los aliens colocaron a un facsímil, un impostor en su lugar, que resultó, por supuesto, un pésimo director.
2. Todos, los 7 mil millones de habitantes de la tierra fuimos secuestrados por unos aliens que llegaron a la tierra en una nave espacial proveniente de otra galaxia. Solamente una persona no fue llevada por los aliens: M. Night Shyamalan. Para que él no se diera cuenta, los 7 mil millones de habitantes de la tierra fuimos sustituidos por unos facsímiles, por unos impostores. Pero el plan de los aliens fracasó. M. Night Shyamalan descubrió el secuestro. Como protesta, ahora el hace películas malas, con la esperanza de que los aliens cambien de parecer, y regresen a los habitantes de la tierra a su hogar.
3. M. Night Shyamalan es un director y escritor malo, que hizo, en sus comienzos 2-3 buenas películas, debido a un fenómeno desconocido que es poco probable que sea descubierto, porque las mentes más brillantes de la tierra se encuentran ocupadas tratando de descubrir la cura del cáncer.

Teoría de conspiración extra: el tiempo se está moviendo al revés, en realidad estamos viendo estas películas en orden inverso, por ello primero vemos películas malas y al final su mejor película, Sexto Sentido.

Leo alarmado en mi whatsapp:

“Podemos discutir hasta el infinitum sobre la naturaleza del problema y cada quien contribuirá certeza e incertidumbre, equilibrio y entropia. Como dice el libro “los hombres son de marte, las mujeres son de venus”, los hombres necesitamos el equilibrio correcto entre intimidad y autonomía, y en mi caso particular necesito al menos un  80% de autonomía y un 80% de intimidad. No quiero extenderme más en los detalles, pues en mi opinión, dicho en 2 platos, el meollo de la cuestión es que abultamos la importancia de nuestros problemas de la misma forma en que abusamos de los porcentajes”.

Por algo las mujeres dicen que todos los hombres son iguales.

Ya he dicho anteriormente lo repetitivo que son algunas actividades/módulos en el desarrollo de juegos. El mejor ejemplo es el scripting, que permite configurar y en parte diseñar ciertos elementos del juego. Desde mi primer intento hace 20 años mi primera versión hice un programa que permitía configurar el comportamiento de los npcs, y modelar algunos aspectos del flujo de juegos (hablo sobre este sofisticado y complicado programa en este post, donde también hablo sobre la toma de decisiones involucrada). He hecho varias veces programas de scripting estilo Lua (cómo funciona en World of Warcraft), pero nunca he usado Lua en sí mismo, me he dedicado a reinventar la rueda una ya otra vez.

Otra actividad repetitiva es el sistema de manejo de npcs y sus diálogos: he hecho 3 versiones (entre ellas una que permite extraer los diálogos del documento de diseño del juego. Crazy). Y así sucesivamente repeticiones hasta el infinito: pero hay otra actividad/módulo que es también común a todos los juegos pero que ahora con khpx por primera vez realizo: el manejo de resoluciones. Todos los juegos deben adaptarse a la resolución que el sistema del jugador tenga, y debe hacerlo de una forma que permita que todo se vea más o menos igual. Hasta ahora es la primera que llego a esta etapa porque es la primera vez que hago un juego hasta tan avanzado nivel de completitud (mis zombies deambulan incompletos por ciudades en ruinas). Además siempre he usado irrlicht (el motor gráfico) quien se encarga de todo.

Hasta ahora como cualquier otro módulo es tan complicado como se puede imaginar, está unido con todo el juego (o al menos la la parte gráfica) y tiene esa característica que a veces resulta bien molesta que cuando acomodas una parte echas a perder la otra. Inicialmente traté de hacerlo lo más multifuncional posible y que luego lo pueda reutilizar para otros juegos. 2 meses después va a ser un milagro si funciona bien al menos para khpx.

En el post anterior el tema de los bugs quedó sin mucha explicación, y dado que he hablado poco de ellos, más allá de una que otra queja, este post es entonces un post sobre bugs.

Para los pocos que no lo saben, los programadores llamamos bugs a las fallas en los programas. El nombre (bug es insecto en inglés) viene dado por razones históricas. En los albores de la computación los equipos fallaban por insectos que se introducían en los antiguos circuitos y tubos que lo formaban, en una época en que nadie soñaba con los circuitos integrados, chips y otras tecnologías modernas.

Todo el tema de programación orientada a objetos (oop), clases, encapsulamiento, cero variables globales, las metodologías de software engineering  y otras ideas son mecanismos para evitar los bugs y otras alimañas que hacen que los programas no funcionen. Los resultados son mixtos.

Mi último juego, khpx, está implementado utilizando una idea descabellada: nada de clases, nada de encapsulamiento, y cientos de variables globales para mantener el estado del juego. Luego de programar decenas de aplicaciones y juegos en C++ y su parafernalia, llegué a la conclusión de que hay que usar C++ por las razones correctas, no necesariamente para evitar los bugs, pues C++ tiene un costo. Un programa en C++ es 50% más voluminoso y complejo que su equivalente en C.

No tengo una estadística que sustente ese 50%, puede ser 20% o 100%. El punto es el siguiente: ¿cuál programa tiene más probabilidad de tener bugs, uno de 1000 líneas o uno de 100? Algunos programadores sesudos argumentarán que los bugs blah, blah, blah y blah. En realidad la probabilidad de un bug no es directamente proporcional a nada, porque los bugs se rigen por la ley de Murphy, por lo que ambos programas, el de 1000 líneas y el de 100 líneas pueden tener bugs, o puede que no lo tengan. Y si ese es el caso, entonces ¿por qué voy a pasar el trabajo de escribir un programa de 1000 líneas, y la desventaja de tener que entenderlo y darle mantenimiento, en lugar de un programa de 100 líneas que con una mirada rápida puede revelar sus misterios rápidamente?

Mi respuesta es no, no tienes que pasar trabajo. Claro que hay unos beneficios adicionales de la programación orientada a objetos (oop): el código queda más organizado, se supone que es más fácil de entender para el grupo de trabajo, es más fácil de mantener. Puesto que soy un lobo estepario (un programador solo)  esos beneficios no existen o al menos estoy hastiado del costo involucrado. Y para ello, baste mencionar como ejemplo el bug que tuve esta semana que involucró 12 horas de pesquisa y trabajo detectivesco para su solución (sí, en el post anterior decía que yo estaba muy sagaz resolviendo bugs, famosas últimas palabras, horas después apareció uno que me callaría la boca).

khpx está implementado con unos arreglos que guardan la información de los sprites. Hay un arreglo g_spr_obj_tbl que guarda los objetos que no requieren modificar el vertex buffer, g_modified_spr_obj_tbl guarda los objetos que lo requieren. Modificar el vertex buffer significa hacer la llamada Lock (), modificar los vértices de los meshes (estoy hablando en términos de DirectX) y Unlock () para terminar las modificaciones.

El punto es que esta semana estuve implementando el fadein/fadeout de la cónsola que muestra los datos de los sensores y controles de la nave, y cuando agregué los objetos para manejar los sensores y controles correspondientes a una batalla, comenzaron a suceder cosas inesperadas: él nuevo sprite perdía su posición en la pantalla y su su tamaño (scale). Era claro que cuando estaba de último en el arreglo fallaba, cuando lo movía a la posición penúltima funcionaba. 12 horas después y luego de revisar el codigo decenas de veces descubrí que el objeto que muestra la posición del scroll en los listados (SCROLL_BAR) estaba mal inicializado, debía estar en el arreglo de los objetos que no modifican el vertex buffer (g_spr_obj_tbl) y en cambio estaba en g_modified_spr_obj_tbl. El índice de este objeto está indicado con un define SCROLL_BAR cuyo valor es 10, que casualmente corresponde al último índice en g_modified_spr_obj_tbl. Esto producía un cambio en cualquiera que fuera el objeto que estuviera en esa posición, que resultó ser el nuevo sprite que yo estaba insertando esta semana.

Este bug me recordó mis proyectos usando oop, porque parece el tipo de bugs que sucede con frecuencia en ese tipo de proyectos. De hecho, en todo el tiempo que tengo programando khpx (un año) primera vez que sucede algo así. El encapsulamiento de la data persigue que este tipo de fallas no ocurran, pero todo depende de que coloques la data en la variable correcta. Si te equivocas de variable, el bug sucede, con o sin oop.

Claro que una alternativa a arreglos e índices son los containers, std::vector por ejemplo, y su iterator’s. El uso de índices y arreglos son peligrosos, o al menos deben ser utilizados con suma precaución. Hay ocasiones que requieres usar ciertos objetos por nombre y apellido, por ejemplo un sprite, y su uso incorrecto afecta todo el sistema. Si revisas el código de Doom (el juego de Id Software los creadores de Quake) está llenos de arreglos, y de accesos por índice. No hay ningún mecanismo especial para evitar este tipo de bugs, más allá de un programador alerta.

Hay múltiples moralejas, y hay múltiples formas de decirlo, pero una de las que más me gusta, está en este libro “Essential C” de Nick Parlante: ” The C programming model is that the programmer knows exactly what they want to do and how to use the language constructs to achieve that goal. The language lets the expert programmer express what they want in the minimum time by staying out of their way” (“El modelo de programación en C es que el programador sabe exactamente lo que quiere hacer y cómo usar las construcciones del lenguaje para lograr esa meta. El lenguaje permite que el programador experto exprese lo que quiere en el mínimo tiempo, manteniéndose fuera de su camino”). El lenguaje C es una herramienta que ayuda a resolver problemas, en múltiples formas, pero principalmente no estorbando. Y eso es realmente una gran ayuda.

Aclaratoria: como está dicho en los posts anteriores khpx, está programado en C++ pero utilizando al mínimo los paradigmas oop. Es prácticamente C pero con el STL. Utilizo intensamente los containers std::vector y std::map lo cual garantiza un código robusto y simple (y por añadidura el mínimo uso de arreglos, pero al parecer, no lo suficiente)