Echando a perder se aprende: programación de aventuras conversacionales

En lo que refiere a la creación de ficción interactiva, pocas cosas son más desafiantes que la programación del relato interactivo en sí mismo, tema este del que he tratado muy poco en el blog.

Como ya he referido en otra ocasión, existe un trabajo creativo no menor previo a la, digamos, implementación de una aventura conversacional en cuanto a software; una labor de preparación que, si se hace bien, evita tropiezos y titubeos que luego pueden salir más bien caros: si no durante la construcción del programa aventurero, ciertamente en el testing, para no hablar de la experiencia del usuario final.

Pero nada de eso evita que de hecho sea obligado pasar eventualmente al computador para "dar a luz" al trabajo interactivo.

A estos efectos, existen hace ya rato múltiples sistemas de autoría de todo tipo: algunos se basan en ventanas, menús, íconos, opciones y requieren poca (que no ninguna) programación; otros son lenguajes de programación con más o menos soporte para controlar los errores de sintaxis, hacer pruebas durante el desarrollo, manejar extensiones o módulos en archivos separados, etc.

En todos ellos, a la postre, hay una curva no menor de aprendizaje... y eso nos lleva al centro de este artículo, a saber, los errores de programación, con su ardua y a veces agotadora dilucidación.

Hablemos pues del llamado debugging, situación esta que se complica según tanto cuanto el programador esté (o no) familiarizado con las particularidades del lenguaje de programación o el entorno de desarrollo (pequeños mundos por explorar) para no hablar ya del oficio de la creación de aventuras, labor de la cual se ha escrito mucho pero sobre la que quedan no pocas cosas por decir, máxime si el autor es novato: todo el trabajo que significa la definición y creación de las localidades, los objetos y los personajes, así como las casi inagotables interacciones con ellos y entre ellos, formen parte o no de un puzzle, sean obvias o no.

Yo mismo, autor con (detesto la falsa modestia) bastante experiencia a cuestas, no lo sé ni lo he visto todo y hay ámbitos en los que me muevo con poca soltura y ninguna gracia: la multimedia y la gestión del comportamiento de los personajes, por nombrar los que más me cuestan.

Sobre esto conversábamos hace poco en  uno de los canales del servidor Discord del CAAD, ocasión en la que quien esto escribe confesaba que:

Técnicamente, lo que yo hago es crear clases de habitaciones o localidades y modifico las respuestas del parser a una clase de localidades o a una localidad específica. Eso puede ser o no deseable para uno o alguno de los PSI, pero requerirá más trabajo de programación el codificarlo... como todo lo que propende a enriquecer la interactividad, por lo demás [...]  que el aprendizaje hace el oficio, no al revés. Mis primeras AC tampoco tenían clases ni casi nada de sofisticación: toda la programación era ad hoc a cada localidad/objeto/puzzle. Eran interactivas, sí, pero con muuuucho código repetido y sumamente burdo.

A la sazón de eso, Bert comentaba lo siguiente:

Es mi caso. mucho código repetido y solución chapucera, pero creo que puede ser interesante compartirlo igualmente. Cuando no sabemos de algo también tiene cierta virtud solucionarlo cómo podemos y con lo que sabemos en cada momento.

Luego, a propósito de ello Tranqui69 acotaba:

A veces una solución 'sencilla' es la mejor solucion. Y crear una especie de armarios para guardar esqueletos me parece una buena idea. Mi código es spaguetti redundante y me ha traido de cabeza miles de veces. Pero poco a poco, como dice Incanus, se alcanza la maestría.

Bert reflexionaba después:

Bueno, consuela saber que no estamos solos. Cada vez que actualizo algo se rompe algo que ya estaba consolidado.

A lo que Tranqui69, con una sabiduría y contundencia que solo años de programación dejan en el cuerpo, sentó catedra de esta guisa:

No hay cosa que de más ilusión que conseguir que salga un error distinto.

Cualquiera de mis lectores que tenga alguna experiencia con la programación no podrá sino sonreir y asentir solidariamente ante esta brillante síntesis de lo que es la depuración de programas, sean de aventuras o de cualquier otra cosa.

Y es que, como dice el refrán, echando a perder se aprende y todo aquello que es fruto de la experiencia debe por fuerza elevarse, desde la ignorancia o la inexperiencia hasta el conocimiento y la maestría, a través de esa senda sinuosa y accidentada que es el error, un profesor ingrato a momentos pero sin embargo tan pleno de satisfacciones cuando se lo supera con bien.

No es más, esta pequeña reflexión sobre el aprendizaje de programación de aventuras, que espero sirva de aliciente a quienes están en sus inicios como autores... y también como advertencia a quienes se lo están planteando: al final del camino las flores son hermosas, pero hay no pocas piedras en la vía.