• “Bizarro” no significa en español lo que significa en inglés. “Bizarro” en español significa “Que es valiente y, por lo general, apuesto.” Terrible. No sé qué palabra usar entonces porque me encuentro situaciones descabelladas, ridículas, absurdas y sin sentido todo el tiempo. No consigo otra palabra que suene igual y genere la misma emoción. Y no voy a estar diciendo “descabellado, ridículo, absurdo y sin sentido” cada vez que me encuentre con estas situaciones. ¡Esto es descabellado, ridículo, absurdo y sin sentido!
• Ya mencioné en alguna parte (queda como ejercicio encontrar el post), que si hay vida extraterrestre, ya para este momento la deberíamos haber encontrado. O sus restos. O sus señales. O algo. Pero no hemos conseguido nada más allá de ciertas evidencias aquí en la tierra. Estaba viendo esta película El descubrimiento (The Discovery), y se me ocurrió que puede haber una conexión. No hemos encontrado señales de civilizaciones extraterrestres porque antes de que esas civilizaciones comiencen a hacerse notar, algo sucede, sistemáticamente. La nuestra no es una civilización muy avanzada, apenas estamos empezando a enviar señales al espacio desde hace unos 100 años. Eso significa que nos haremos notar o alguien nos va a detectar dentro de algunos cientos de años cuando nuestras señales lleguen a alguna civilización. Además está el detalle de que alguien pueda entender nuestras señales. Quizás hemos estado recibiendo señales de otras civilizaciones pero no las entendemos. Solamente una civilización lo suficientemente avanzada se va a hacer notar claramente. Pero esas civilizaciones al parecer no llegan a edad adulta. Algo les sucede, y puede ser lo mismo que nos va a suceder a nosotros. Por ejemplo: descubrimos que hay vida después de la vida: y si es así, entonces ¿para qué continuar con esta vida llena de sufrimiento, trabajo y desesperanza? De acuerdo a la mencionada película (El descubrimiento ) si la gente descubre que hay un más allá garantizado, optará por el suicidio sin pensarlo dos veces. Es descabellado, ridículo, absurdo y sin sentido pero podría ser un explicación. En cierto momento de la edad adulta de una civilización, descubren esto, y la civilización desaparece. Bizarr… coño, joder!
• “El diseño es un proceso iterativo. El número necesario de iteraciones es uno más que el número que usted ha hecho actualmente. Esto es cierto en cualquier momento.” (Akin’s Laws of Spacecraft Design)
• ¿Quién controla glibc? Un artículo sobre un elegante “lo hacemos así porque lo digo yo“.
• De una forma silenciosa, casi sin que nadie se dé cuenta, Plutón vuelve a la categoría de planeta, por lo que nuestro sistema solar nuevamente tiene 9 planetas. Enlace. O quizás no. Wikipedia sólo menciona las decisiones de 2006-2008. No pregunten. O pregúntenle a Neil. Drayss.
• La gente se está aburriendo de la IA (inteligencia artificial). De nuevo. “AI Winter Is Well On Its Way” (“El invierno de IA está en camino”). La gente quiere que IA haga algo que realmente no puede. Y hay gente de mercadeo que piensan que se van a ganar unos reales. Internet hace el resto.

• Mi comunicación conmigo mismo siempre es efectiva cuando me presto atención.
• Me entero que el grupo detrás de NetHack sigue trabajando, por lo que con gran júbilo y fanfarria anuncian el lanzamiento de la versión 3.6.1 (luego de 2 años) Yo solía jugar con devoción esta familia de juegos siendo rogue y Hack mis favoritos. Nethack nunca realmente me gustó por ciertas adiciones que lo hacen aburrido, o molesto por decir lo menos. Ahora leyendo la guía descubro que hay una opción para eliminar la mascota (una de las cosas que me molestaba, me parece que siempre está en el medio y me distrae del objetivo real del juego, además no creo que aporte algo). La mencionada opción (para eliminar a la mascota) es pettype=none se puede seleccionar a un gato o un perro, y si eres un caballero puedes seleccionar un caballo. Estas opciones se pueden colocar en un archivo de configuración (defaults.nh) y definir una variable OPTIONS, por ejemplo:
  OPTIONS = autopickup,pettype=none
• ¿Cómo se hace para ganar un premio nobel? Difícil pregunta pero un buen comienzo es ser el mejor investigador en tu campo de experticia. ¿Cómo se hace para perder un premio nobel? Esto es mucho más fácil basta con ser deshonesto, lo cual, cada vez es más frecuente. Inclusive en la investigación científica. Yo no soy fanático de la cosmología pero como todo el mundo me pregunto qué estamos haciendo aquí. Al parecer la cosmología no trata de responder esa pregunta, sino de teorías sobre el universo, una de las cuales incluye una interpretación sobre la gravedad y lo que podemos deducir por simple observación. Si el que está viendo por un telescopio no es honesto sobre lo que realmente está viendo, cualquier cosa puede pasar, incluyendo confirmar una teoría en falso. Interesante lectura. Por ejemplo esta parte “we desperately tried to rip them off, but they weren’t that dumb.” (“tratamos de engañarlos, pero no fueron tan tontos”). Sorprendente. Creía que eso solamente lo hacían los políticos y los vendedores. Ya no. Qué ingenuo soy.
• El número cromático del plano al parecer es 5. ¿Cuántos colores se necesitan para dibujar un mapa sin que dos regiones o estados o provincias adjacentes tengan el mismo color? Al parecer es 4, pero si extendemos eso a un grafo (esos dibujos con puntos y rayas que los unen), el número correcto es más 5 que 4. ¿Para qué sirve esto? Es importante para los matemáticos y computistas. Comentarios sobre el paper.
• Si piensas que google traslate es bueno, prueba con https://www.deepl.com/translator. Hasta ahora lo he encontrado más preciso.
• Yo tengo 3-4 gigas de código fuente en mi máquina de trabajo. Conseguir un código que desarrollé para resolver un problema es fundamental en mi trabajo de programación diario. El search files de windows a veces funciona, a veces no. He llegado a usar el grep de cygwin para tratar de atrapar el archivo que estoy buscando, igualmente con resultados mixtos (una efectividad de 50%). Esto es fatal para mi. Hay una nueva herramienta Search My files, que quizás ayude. La he estado probando igualmente con resultados mixtos. He pensado en desarrollar mi propia herramienta. Mientras tanto estoy comenzando a escribir un documento con una lista de código fuente relevante, y tengo una carpeta llamada stuff con ejemplos de código para resolver problemas típicos (como hacer una llamada AJAX en jquery con despliegue del ícono “waiting”, o cómo abrir un archivo en c++ usando STL, y leer las líneas fácilmente, etc) Y sin embargo la última vez que escribí un programa server/client usando UDP tuve más o menos que hacerlo desde scratch porque no ocnseguí mi programa anterior. Ups.

Estaba leyendo este artículo de la gente de SQLite, sobre por qué ellos no usan git, y por un momento pensé que era una buena idea estudiar fossil, que es lo que ellos usan. Y cuando digo un momento me refiero a 5-10 segundos, porque fossil, como es de imaginar, tiene su propia curva de aprendizaje, que es como todas las curvas de aprendizaje, una curva, con una excentricidad pronunciada. Así que como estoy en una onda de dedicarme a la programación de juegos y no a las herramientas para “ayudar” a programar, abandoné la idea. Por cierto que khpx usa por lo pronto SQLite para guardar los datos. Yo he desarrollado varias bases de datos portátiles, pero SQLite es insuperable en términos de eficiencia y confiabilidad. Como quiera que sea, khpx continúa sin un sistema de versiones (version control).

Y eso es grave.

Yo usé git con uno de mis zombies (un juego al que le dediqué una considerable cantidad de tiempo y no he publicado) y nunca descubrí el genuino beneficio de usarlo, más allá de la obstinación con sus rarezas y excentricidades (sabía que esa palabra tenía otra acepción). Actualmente hago respaldos para cubrirme las espaldas (¿por qué decimos eso si solamente tenemos una espalda) en caso de una pérdida, pero también para hacer el backtracking que me permita descubrir la naturaleza y orígen de un bug. Y eso es horrible. Identificar cuándo comenzó a aparecer un bug puede ser complicado e inútil con un sistema de respaldo, e inclusive con un sistema de versiones. git (y me imagino que fossil) tiene mecanismo de ayuda, pero solamente si lo usas en forma adecuada. Y eso consume tiempo. Hay un compromiso entre el tiempo que le dedicas a la preparación para una recuperación de desastre (corregir un bug) y el tiempo que le dedicarías si no te preparas en lo absoluto y lo haces con fuerza bruta. O con tus neuronas.

Y hay bugs que van a requerir todas y cada una de tus neuronas.

El último de estos bugs me sucedió esta semana. El ciclo del rendering es la parte crucial de todo el game loop (“el lazo del juego” no traduce todos los intrilinguis de “game loop”) . Inadvertidamente coloqué una llamada en el lugar incorrecto, y ¡bang!, perdí 30fps en el proceso (khpx está en 62fps, el bug lo redujo a 30fps). Luego de pasar un par de horas con los respaldos era evidente que no lo iba a descubrir de esa forma. En posible que con el sistema de versiones tampoco. Así que tuve que pensar. Durante 5 minutos, completos, largos y difíciles de incertidumbre y temor. Lo resolví, pero ¿cómo pudo suceder? ¿cómo fue que no me di cuenta del problema? Porque no solamente no tengo control de versiones sino porque el sistema de pruebas es muy rudimentario.

¿Qué aprendí? Nada que no supiera de antemano, necesito un sistema de versiones, un sistema robusto de pruebas, no dejar pasar cosas obvias (estar pendiente de) como un impacto en los valores de desempeño del juego, por ejemplo los fps. Lo único que voy a hacer por ahora es mejorar todo el sistema alrededor del cálculo del fps (ahora se despliega el promedio) y colocar una alarma cuando este promedio está por debajo (en forma consistente) con el normal. git, fossil, unit testing, siguen en pendiente.

Estaba viendo un mod de Super Mario que se llama P is for pain (reddit) así que lo usé como el nombre de este post dedicado a la programación de  juegos. La P también es por los Post morten de juegos, exitosos o no.  Post morten hay de sobra y ya he comentado varios anteriormente. 1000 copias vendidas son un fracaso para algunos, un éxito para otros. Para mi, terminar mi juego es el verdadero triunfo. Así que me estoy preparando para que el post morten de khpx (un juego ambientado en el espacio) exista al menos. ¿Y el dolor? Viene de múltiples fuentes. La más frecuente en este momento es el cambio de las estructuras de datos: ¿cómo definir la correcta estructura de datos para manejar todos los casos que a los escritores (yo mismo, yo solo) se les ocurra? ¿Debe haber una lista de servidores en cada planeta o una lista de servidores asociada al planeta? Ambos enfoques tienen un impacto directo en todas las rutinas que manejan los servidores. Creo que estoy dedicando el 50% o más del tiempo a modificar las estructuras cuando descubro que no son capaces de manejar correctamente lo que quiero implementar. O, a veces, la estructura es correcta pero está generando exceso de código y hay que hacerle modificaciones para mejorar el código asociado. Esto genera retrasos, nuevos bugs, frustración. Afortunadamente decidí no usar classes en este juego y los cambios son más fáciles de hacer.  O quizás no. No lo se.

¿Falta de planificación? Con toda seguridad. Estos problemas suelen resolverse con un buen diagrama que muestre las relaciones entre las estructuras. Pero mi experiencia es que ahora tengo dos problemas: ahora debo actualizar y modificar los diagramas y modificar los algoritmos que implementan las funciones/datos de los diagramas. Siempre me ha resultado doble trabajo. Es como aquél dicho “Tengo un problema, voy a usar Java para resolverlo.” Ahora tengo dos problemas. La adaptación a este caso sería “Las estructuras de datos no se adaptan a los requerimientos cambiantes del juego, voy a usar diagramas”. Ahora tengo dos problemas.

Volviendo a los post morten estaba leyendo este artículo sobre el creador de Stardew Valley, esta vez un caso exitoso (realmente exitoso, 3.5 millones de copias vendidas el primer año). Hay cosas que me llaman la atención en ese artículo, por ejemplo, que Barone, el programador, realmente no quería dedicarse a programar juegos (al menos profesionalmente). Y luego terminó trabajando durante 4.5 años 12 horas al día (el artículo está lleno de datos que no tienen sentido alrededor de esto y otras cosas, pero eso no es importante, la vida de un programador es incomprensible desde cualquier punto de vista). Como quiera que sea, me gustaría saber que se siente tener esas ambiguedades en la vida. Yo, a los 20 años, descubrí que me gustaba la programación y me he dedicado a eso toda mi vida. (claro, trabajé 16 años como vendedor de tecnología (Sun) pero eso fue por otra cosa, si quieres saber cuál cosa te voy a dar una pista: es la respuesta a 99 de cada 100 preguntas, está en el párrafo 1, página 1 de todo libro de ventas: sí, eso mismo: dinero).

También me llamó la atención (es de resaltar como dicen los políticos) detalles sobre la comezón del día a día del programador, por ejemplo esta perla: “Cada ajuste, de los cuales hubo miles, requirieron que él recargara el juego para refrescar  el código (“Each tweak, of which there were thousands, required him to reboot the game to refresh the game’s code“). “Refrescar el código” o reinicializar las variables y el estado del juego para estar seguro que todo funciona bien. Es una locura, es endemoniadamente repetitivo someterse a esto por el agotamiento que produce ver una y otra vez lo mismo en pantalla y tratar de devanar el cerebro pensando por qué funciona o por qué no. Lo cual me llevó a buscar estrategias, entre las cuales está el unit testing, que es una forma elegante de decir automatizar el testeo. Hay muchas posibilidades aquí, hay una librería altamente recomendable llamada Unit test cpp (UnitTest++), la cual por supuesto no uso ni voy a usar porque como buen inventor de la rueda no le veo sentido a usar una librería para implementar ES_IGUAL (algo, otra_cosa). Todo esto me llevó a considerar las razones por las cuales debería usar un lenguaje de scripting para acelerar el desarrollo (la idea es que al usar un lenguaje de scripting es más rapido implementar prototyping, nuevas características y modificarlas) pero también sirve para hacer pruebas. Yo odio Lua que es lo que todo el mundo suele usar en estos casos pero descubrí Wren que me luce más divertido (efectivamente en alguna parte de los manuales de Wren dice que a otros programadores en c++ les es raro usar Lua porque la sintaxis es diferente. Wren es  más del tipo c++). Claro que todo esto sería apartarse demasiado de mi objetivo de publicar kxpx, por lo que está de último en mi lista de cosas pendientes.

Pero lo que me llamó la atención del artículo (volviendo al artículo), la razón por la que lo menciono es por el proceso de Crear. Abandonar. Re-crear. ¿Suena conocido?