¡Buenas! ¿Pensabais que este blog estaba muerto? Pues un poco sí, la verdad. En su día hablé de todo lo que tenía que hablar sobre aventuras y sencillamente se me acabaron los temas. A pesar de todo he publicado ocasionalmente un artículo cada x meses, cuando de pronto surge una idea que me parece lo bastante interesante. Y aquí me tenéis una vez más.
Y todo porque estaba yo tan tranquilo escuchando el podcast de CAADtv mientras jugaba a Cyberpunk 2077, en el que hablaban de cierta aventura donde tienes un casco que puedes usar como contenedor para recoger aceite, y en otro momento de la aventura tienes que recoger agua con una botella, pero NO puedes recoger el agua con el casco. Y de pronto alguien empieza a hablar de modificar el motor de la aventura para definir algunos objetos como líquidos y establecer qué pueden recoger los contenedores y qué no y crear atributos de tamaño también etc etc… concluyendo que todo eso sería probablemente demasiado complejo de desarrollar y por eso el juego es así.
Y a mí me empezó a salir humo por las orejas, porque este es un tema que tengo ahí en un rincón oscuro de mi mente desde hace años, aunque por el motivo que sea nunca me dio por escribir un artículo. Pero aquí estoy para poner solución a esa negligencia por mi parte.
Creo que hay mucho desarrollador de aventuras con mente de programador. El programador siempre lo quiere automatizar todo para que funcione por sí mismo de base. Y a veces es algo complicado de hacer. Y a veces crea problemas imprevistos cuando el jugador acaba haciendo algo que se supone que no debería hacer pero que la funcionalidad del motor lo permite.
Me recuerda a un chiste que vi por ahí hace tiempo, donde un programador explicaba a otro miembro del equipo todas las complejidades y cambios en el código por las que había pasado toda una noche sin dormir para conseguir simplificar una tarea específica. El otro le preguntaba: «¿Y cuántas veces vas a usar esa función?» Y este respondía: «Una».
Traducido al idioma de la gente normal sería como la diferencia entre construir una silla a mano o construir una máquina de hacer sillas perfectamente eficiente y automatizada. Pero ¿la necesitas? ¿Vale la pena el tiempo y el esfuerzo si solo quieres una silla?
Yo, que no me considero programador, siempre prefiero hacerlo todo a mano para tener un mayor control sobre el juego. A veces resulta práctico y a veces es simplemente una manía que tengo. Y, en mi opinión, una aventura de texto media tiene suficientes pocos objetos, puzles, personajes y situaciones como para poder controlar todo el sistema por ti mismo como desarrollador, sin necesidad de esa automatización. Si en una aventura se puede usar un casco como contenedor para recoger aceite y una botella para recoger agua, pero no al revés, me parece un fallo del autor por no haber previsto algo tan obvio que mucha gente va a intentar. Sin excusas. Por supuesto que el casco debería permitir recoger ambos líquidos, y la botella igual (o quizá si el casco es multifunción ya no necesites la botella).
Creo que a veces se exagera la complejidad que supone crear una aventura de texto hoy en día. No es tan complicado. Hay que ponerle ganas. No creo que ninguna aventura tenga tantos objetos, puzles o tanta complejidad como para no prever estas cosas. Y programarlas a mano una por una. En serio, yo he programado docenas de interacciones que no son necesarias para terminar la aventura. Pero son lógicas, sé que la gente las va a intentar, y yo lo resuelvo usando el código más básico del parser. Hacer que un casco pueda recoger indistintamente agua o aceite, y que si ya está lleno de un líquido se niege a coger el otro, o que pase algo divertido si mezclas ambos, es algo que yo -al menos en Adventuron- te lo programo en 5-10 minutos. No es más que un puñado de líneas del tipo «si el jugador hace esto, responde esto y cambia esta variable».
Y hablando del motor Adventuron, un problema que siempre tuve con él (y admito que puede que sea manía de viejo cascarrabias) es la cantidad de funciones que tiene, solo porque alguien le pidió al autor que las incluyera, y que muchas de ellas probablemente solo las va a usar un desarrollador concreto en una aventura concreta. Y aclaro que hablo de funciones que no están en el manual básico, porque llegó un punto en el que el desarrollo se desbordó y ya no se documentaban muchas cosas. Adventuron es un iceberg y lo que vemos en el manual es solo la punta. El problema -para mí- es que crear esas funciones consumía tiempo de su autor que podría haber dedicado a cosas más útiles o urgentes, convertían las guías oficiales y extraoficiales en un caos, y potencialmente creaban nuevos bugs (ya que según cierta ley, cuanto más complejo es un sistema más posibilidades hay de que algo falle). Y de hecho me pasó que tuve que comerme alguno de esos problemas imprevistos, con algo que antes funcionaba bien y de pronto tras x actualización no documentada ya no funcionaba.
Muchas de esas funciones implementadas en el propio motor se podían haber apañado simplemente programando esa situación concreta a mano con el código que ya tienes. No todas, hay cosas que no se podían hacer de otra manera que modificando el motor, y de hecho Chris creó para mí algunas funciones específicas que no se podían simular de ninguna otra manera y que me ayudaron a mejorar mis juegos. Pero sospecho que más de la mitad de esas funciones se podrían haber resuelto usando el código básico del Adventuron, sin necesidad de tocar el motor. Haciéndolo a mano en lugar de intentar automatizarlo todo.
Por otro lado también está el problema de limitarse a desarrollos de 8bits, lo cual puede servir como excusa para no dar soluciones o respuestas «por falta de memoria», pero yo siempre digo y repito que hoy en día desarrollar aventuras para 8bits me parece que es ponerse palos en la rueda para nada. Pero bueno, esto sería otro debate y estoy seguro que mucha gente está en desacuerdo conmigo, lo dejo ahí.
En resumen: No creo que haga falta modificar el motor de la aventura para crear una nueva funcionalidad cada vez que queremos hacer algo que se sale mínimamente del «sota, caballo y rey», cuando se puede crear o incluso sobreescribir esa funcionalidad a mano usando el propio código del motor. Y sobre todo cuando solo la vas a utilizar una vez, en una aventura concreta. Al final es hacer de forma complicada algo que podría ser mucho más simple. Pero, como dije antes, hay que ponerle ganas. El motor no lo va a hacer todo por ti.
