lo malo de catbox siempre han sido los diálogos. o sea, entre otras cosas, siempre han sido los diálogos. para hacer un juego como el que quiero, necesito que el motor tenga un sistema de diálogos completo. y cuando digo completo, me refiero a todo lo que uno pueda querer poner en un diálogo.
la primera iteración del motor de diálogos dejaba bastante qué desear. las líneas de texto (y sus "características", un concepto bastante absurdo) estaban almacenadas en arrays dentro de cada actor, y el objeto principal "leía" éstas líneas en orden. ¿problemas? muchos: cada nueva característica que quisiese añadir al sistema de diálogos iba acompañada de una nueva característica para las líneas, ergo había que actualizar todo el motor para hacer algo tan sencillo como, no se, ser capaz de cambiar el gráfico de la cara en una ventana de diálogo. ésto restringía el motor a héroes mudos. dudo que 2079 tenga un héroe que hable, pero honestamente no pretendo usar el motor únicamente para 2079, y eventualmente, si yo (o alguien) quisiese hacer un juego en que el protagonista hablase, tendría que modificar el código brutalmente.
la segunda iteración del motor de diálogos era un poco más aceptable: diálogos, cambio de valor en triggers y variables, sonidos, items, ejecución de código, caracteres de control, etc. ¿problemas? el sistema seguía siendo esencialmente el mismo, sólo que un tanto más flexible. ésta iteración del motor de texto se vino abajo cuando intenté implementar diálogos alternativos. así, tal cual estaba, cada actor sólo podía contar con un diálogo alternativo.
la tercera iteración del motor de diálogos ya era más aceptable. en realidad, y pese a ser una reescritura total, mantenía toda la funcionalidad de su forma anterior (exceptuando la llamada a una tienda, más que nada porque todavía no había un sistema de tiendas reescrito para llamar) sólo que ridículamente más flexible. la principal diferencia era la posibilidad de infinitos "bancos" de diálogo alternativo, gracias a que cada diálogo estaba almacenado por índices. éste sistema se vino abajo cuando intenté implementar algo tan esencial como respuestas múltiples.
ahora, en teoría un sistema de respuestas múltiples es algo sencillo. en teoría. llevarlo a la práctica es un poco más complejo de lo que parece.
la actual iteración del motor de texto, la cual acabo de dejar funcionando, aún no la implementa, pero es una reescritura mayor del motor. para comenzar, ya no es una lista de texto con propiedades, si no una suerte de "secuencia de comandos" que un script, haciendo de intérprete, ejecuta. en todas las iteraciones anteriores, cada línea tenía en sus propiedades cosas como el nombre a mostrar en la ventana de diálogo, el gráfico de la cara, cómo funcionaba la línea de texto, etc. esencialmente, todas las líneas eran líneas de texto, sólo que algunas funcionaban de formas levemente distintas. eso ya no es así. ahora cada línea de una secuencia de diálogos es una instrucción a ejecutar, completamente independiente de la anterior. ésta foram de ordenamiento me permitió hacer cosas bacanes, como deshacerme de los índices. o sea, no es que me haya deshecho de los índices, igual, cuando haga el juego, cada actor va a llamar a un script que va a estar almacenado bajo un índice numérico en un script, pero ahora, por ejemplo, dentro de la misma secuencia puedo hacer bloques condicionales y, por ejemplo, mostrar cierta parte del código sólo si cierto trigger lleva cierto valor.
Otra cosa que hice fue reimplementar los triggers. Me pareció mucho más sensato implementarlos como una estructura de datos que como un array. Antes el límite de los triggers era la cantidad de escenarios del juego X un número fijo. ahora el límite es la memoria ram disponible. otra cosa buena es que, en lugar de asignarles índices numéricos, ahora se les asignan llaves como strings de texto. por lo que en vez de 4,2 ser el abierto o cerrado de la primera puerta, ahora "primerapuerta" es el trigger correspondiente a ésa puerta.
en fin, diálogos. la otra cosa que me permite el motor nuevo es crear nuevas instancias de posibles comandos a ejecutar en un diálogo sin necesidad de crear nuevos scripts para implementarlo. en una de las iteraciones tenía ejecución de código, derechamente. no puedo negar que ésto es más práctico, pero también es mucho más engorroso y destinado a la perdición, pues las funciones que ocupaba ya estan obsoletas. ahora, con un solo script puedo hacer funcionar los 11 comandos actuales del sistema de diálogos. pretendo seguir ampliandolo. lo mejor de todo es que éste dinamismo me permite crear scripts de uso rápido de forma mucho más sencilla. un ejemplo: en una de las iteraciones anteriores usaba un script sin entrada de texto para la entrega de items, cosa que todas las entregas de items tenían el mismo texto "¡Has recibido
los planes a futuro para el sistema de diálogos es implementar el sistema de respuestas múltiples. se me ocurrió más o menos cómo se hace (una lista temporal donde se almacenan las opciones ingresadas desde un string, separadas por un caracter, y donde el índice de cada item de la lista representa un valor en una variable general, denominada "respuesta" o algo así, y dentro de la sencuencia de diálogo referir que si la variable tiene tal o cual valor, hacer tal o cual cosa), reimplementar caracteres y frases de control para ciertas cosas (nombres de héroes y actores en general, valor de variables y triggers, cuestiones de tiempo, cosas así) y, por qué no, un sistema de pseudoscripting para escribir los diálogos en código, sin tener que estar llamando a otros scripts, entonces un diálogo quedaría escrito algo así:
>Esto es una línea de diálogo
>Y esta es otra línea de diálogo
>¿Que les parecen éstas líneas de diálogo?
?Son muy buenas|Meh|Son horribles
/El hombre de las nieves
!0
>Me gusta que le gusten. Me alegro.
_
!1
>Meh.
_
!2
>Eres un vil y asqueroso ser. Ojalá mueras.
_
@"trigger"|true
%"trigger"|true
>Ésto sólo debería salir si el trigger "trigger" está activado.
>Dado que lo activamos sólo dos líneas atrás, es buena idea asumir que está activado.
>Además estás leyendo ésto
_
>Eso, chao.
éste tema del pseudoscripting es muy a largo plazo, y sólo lo implementaría después de terminado todo el motor. por lo demás, el resto de los planes a futuro para los diálogos son bastante aterrizados. probablemente tenga algo terminado para la próxima semana.
