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?