Trókola
Estaba aburrido, esto es lo único que puede decir en mi descargo. Hoy
traigo un nuevo vaporware, por supuesto maravilloso, que veremos
acabar en ningún sitio, en cuanto aparezca un nuevo proyecto más nuevo
y por tanto mucho más emocionante. El caso es que en el artículo
anterior ya os hablé de mi redescubrimiento de mi olvidado
Tcl/Tk
. ¿Sería conveniente hacer algo con él para afianzarlo? Sí,
claro... y ¿qué hago? Me vino una idea perversa a la que no pude
resistirme: Hacer un sistema o una librería para programar aventuras
conversacionales con Tcl. Muy bien, pero mejor no cuento nada, porque
al final seguro que se queda en nada como el 99% de los proyectos de
programación y... ¿qué dices? ¡Si tienes un blog casi en
barbecho. Pues nada, aquí estoy para cansinaros un rato.
El proyecto
Se llama «Trókola». Sí, ya sé, a algunos les sonará lo de la «junta de la trócola» como excusa de mecánico caradura para inflar la factura. No tengo una idea muy clara de por qué lo he llamado así, más allá de porque no se me ocurría otro. Pero como es mi proyecto lo llamo como me apetece.
Hay quien afirma que cada jugador de conversacionales tiene el sueño
de programar la suya ─la más maravillosa del mundo mundial─ y que todo
programador de conversacionales anhela hacer su herramienta de
creación, ─por supuesto, también la mejor del mundo mundial─. Ese no
es mi caso: no creo que Trókola aspire a ser el sistema definitivo,
ni tan siquiera creo que nadie lo vaya a utilizar nunca. Incluso no
creo que esto lo lea nadie del mundillo de las aventuras
conversaciones. Tampoco me he puesto objetivos que cumplir, ni sé
hasta dónde quiero llegar, de momento, me conformo con unas pocas
cosas, la primera y fundamental, como he dicho, lo de afianzar el
lenguaje para mis necesidades del futuro. Por otro lado, me he
encontrado que también lo podré utilizar en el móvil a través de
Termux
(y he comprobado que funciona el poco código que hay).
Como digo, no me planteo que sea el mejor sistema del universo, pero me gustaría trabajar varias características que me parecen importantes y que otros sistemas obvian o lo hacen casi de perfil.
- Multilingüe
- La mayoría de los sistemas están programados en inglés para la lengua inglesa, con su gramática y sintaxis. Adaptar posteriormente cualquier otro idioma se hace muy complicado. Sobre todo cuando ese idioma tiene una gramática más compleja que el inglés. Lo voy a diseñar por tanto en español con su sintaxis más compleja, pero con el Esperanto en mente, con una sintaxis mucho más simple, para trabajar los mecanismos de ajuste y simplificación.
- Rolero
- La mayoría de sistemas contemplan el escueto «la violencia no es el camino» o cualquier otra similar para eludir el hecho de la complejidad que se esconde cuando hay que simular combates, puntos de vida, características de los personajes, etc. Y, por supuesto, porque matar orcos puede ser también divertido.
- Abierto
- Quizás no es la palabra adecuada. Con abierto quiero decir que los personajes no estén enclaustrados en lo que contiene la clásica room. Es decir, que puedan oír o ver lo que hay en localizaciones adyacentes o alcanzables mediante los sentidos, que si hay una ventana en una habitación, pueda ver el personaje lo que hay en el patio, por ejemplo. Y que el creador del juego no tenga que trampear el sistema para que eso se pueda hacer.
Estas son los objetivos de partida para lo que quiero hacer y si por casualidad termina no siendo tan vaporware como creo, me gustaría también tener en cuenta algunos otros aspectos, digamos secundarios, que trabajar en el futuro:
- Distribución
- ¿Cómo se podría distribuir un juego con este
sistema? Hay intérprete de
Tcl
para casi cada sistema operativo (en GNU/Linux seguramente está instalado en la mayoría de máquinas). Pero quizá no está bien pedir a los posibles jugadores que se lo instalen sólo para un juego y habría que hacer un intérprete simple, para cada sistema, que corra el juego. Por tanto, me quiero limitar a sólo utilizar lo básico deTcl
. Nada de librerías de programación orientada a objetos, ni de ningún otro tipo. Sólo utilizando las estructuras de datos que proporciona el lenguaje de base: listas, arrays, diccionarios, etc. Quizá es una limitación autoimpuesta superflua porque no creo que haya nunca un juego terminado con él, pero no quiero añadir mierdas de las que luego me puedo arrepentir. Cuanto más simple y menos dependencias mejor. - Multijugador
- Jugar siempre es más divertido cuando juegas con alguien. Sería un lujo, poder jugar varias personas, bien llevando el mismo personaje o, mucho mejor, llevando cada uno un personaje distinto y que puedan jugar una conversacional al estilo de un MUD pequeñito para tres, cuatro o cindo jugadores a lo sumo, cada uno con su correspondiente personaje. Además, una de sus posibles utilidades para mí, iría por hacerlo multijugador, aunque fuera de pocos jugadores pero que cada uno llevara su personaje.
- Un poco de multimedia no hace daño
- Son aventuras de texto, puro y duro, pero tampoco se hacen ascos a algún gráfico o sonido que ilustren lo que dice el contenido. Que no den pistas extra o despisten, pero que aporten un poco más de refinamiento.
Inicio del proyecto
De momento hay poco que enseñar, más que las ganas de hacerlo. Pero he
empezado ya con ello. He creado un repositorio fossil
e incluso he
escrito las primeras líneas de código, sincronizando el remoto en mi
nube personal de Nextcloud.
Cómo y por qué fossil
Ya dije que llevo tiempo utilizando fossil
para mis proyectos
particulares, aún a riesgo de que me critiquen los más puristas de la
filosofía Unix. Por esto, empezaré por los porqués y luego hablaré
de cómo.
Algunos proyectos son privados, es decir, los hago sólo para mí y no
creo que le puedan interesar a nadie más o directamente no son de la
incumbencia de nadie más, como por ejemplo, mi contabilidad. He venido
utilizando algunos subterfugios como utilizar Nextcloud
como
servidor remoto para poder llevarlos. Sin embargo, me encuentro
siempre con problemas con git
y lo mal que se lleva Nextcloud con
los archivos y directorios ocultos. git
guarda la información en un
sin fin de archivos de nombres incomprensibles y se da, de vez en
cuando, el caso de que Nextcloud da error en alguno de ellos. Por
contra, fossil
utiliza sqlite3
, lo guarda todo en una base de
datos y todavía no se me ha dado el caso de que falle una
sincronización. Además, allá donde copie ese fichero, tengo un
repositorio completo.
Utilizando git
además necesito siempre un archivo donde anotar ideas
y todo lo relacionado con el proyecto que no forma parte del proyecto
propiamente. Otro(s) para la documentación, etc. En el caso de
fossil
, el mismo repositorio cuenta con wiki, gestión de tareas
(tickets), foro, chat... bueno, vale, el chat no lo uso conmigo
mismo, pero todo lo demás sí: en el foro abro hilos sobre las
características que me gustaría que tuviera y me creo un ticket por
cada tarea que debo hacer, en el wiki voy escribiendo documentación
del proyecto, etc. La interfaz UI es una página web, que si bien
no tiene el más glorioso diseño, funciona bien y rápido. Y cualquier
anotación en él, bien sea en el foro, en la wiki, sea en el código o
en los tickets, se añade a la línea de tiempo y tengo referencia de
cuándo se hizo, puedo filtrar las modificaciones del repositorio que
quiero ver: todas, wiki, foro, tareas, o que oculte alguna. En fin,
toda esto me da una visión más completa de la historia del proyecto.
Por ejemplo, lo poco que hay hecho del proyecto se ve así:
Por otro lado, como curiosidad, todo este mundillo de fossil
y
sqlite3
, Tcl/Tk
, etc. parece formar un ecosistema un tanto
endémico. Si vas a la página Tcl
tiene toda la pinta de ser un
repositorio fossil
, igualmente con sqlite3
. Además, fossil
y
sqlite3
son del mismo autor. El primer lenguaje con soporte para
squlite
fue Tcl
, hecho por el mismo autor, que embebe una versión
minimalista del tclsh
como lenguaje de script para su herramienta
de gestión de repositorios fossil
.
Utilizar un repositorio fossil
no es muy distinto de hacerlo con
otras herramientas de control de versiones. La documentación viene
incluida y se puede consultar con fossil help
. Por resumir, lo
primero que debemos hacer es iniciar el repositorio. En nuestro caso:
fossil init ~/Nextcloud/repos/trokola.fossil
ese comando creará el fichero sqlite3
que hace de repositorio. La
extensión .fossil
es opcional, podemos utilizar cualquiera, sin
embargo, la uso, porque en el caso de utilizar fossil
en modo
servidor simplemente lanzo:
fossil server ~/Nextcloud/repos --port 8081
De este modo, todos los archivos con la extensión .fossil
en ese
directorio, se sirven como repositorios remotos. Basta con añadir el
nombre del fichero a la dirección del servidor y entras directamente
en el repositorio:
Como se puede apreciar, al utilizarlo en modo servidor pide usuario y contraseña para poder modificar cualquier cosa del mismo. En modo local te logea con tu usuario.
Hasta aquí sólo hemos creado el repositorio en un sitio que vamos a tratar como si fuera remoto, puesto que es el fichero que se va mantener en la nube de Nextcloud. Ahora debemos crearnos la copia local.
cd proyectos mkdir trokola cd trokola fossil open ~/Nextcloud/trokola.fossil
Esta acción nos crea otro archivo, en este caso oculto .fslckout
que
contiene el repositorio local. Una cosa es abrir nuestro repositorio y
otra sincronizarlo. Para hacer que sincronice con el repositorio
puesto en Nextcloud como remoto debemos añadirlo a la lista:
fossil remote add origin ~/Nextcloud/repos/trokola.fossil
Ese comando añade nuestro repositorio con el nombre origin
. A partir
de ahora basta con que hagamos fossil push
para subir nuestros
commits al repositorio remoto. O si tenemos varios remotos y sólo
queremos actualizar uno de ellos fossil push repositorio
, donde
repositorio
sería el nombre que hemos utilizado para ese remoto.
Primer código
El código hasta ahora es muy simple, pero ya comprende el primer comando o acción del sistema: salir. No voy a extenderme mucho en explicaciones que seguramente os resultarán cansinas.
De momento todo está embutido en un solo fichero llamado trokola.tcl
que consiste, en el siguiente código:
#!/usr/bin/tclsh # ##################################################################### # Trokola - Herramienta de ficción interactiva con Tcl/Tk # Copyright (C) 2022 -- Notxor <notxor@nueva-actitud.org> # # This program is free software: you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by # the Free Software Foundation, either version 3 of the License, or # (at your option) any later version. # # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU General Public License for more details. # # You should have received a copy of the GNU General Public License # along with this program. If not, see <https://www.gnu.org/licenses/>. # ###################################################################### proc prompt {{t "> "}} { puts -nonewline $t flush stdout } proc terminar {{despedida "Adiós."}} { puts $despedida exit 0 } proc procesa {linea} { switch $linea { abandonar {terminar} default {puts "Has dicho: $linea"} } } ############################################################################### # Bucle Principal # ############################################################################### while {true} { prompt set linea [gets stdin] procesa $linea }
He eliminado, en este listado del código fuente, los comentarios de las funciones donde se explican los parámetros que reciben y lo que devuelven y hacen.
De momento al hacerlo funcionar lo que hace es entrar en el bucle
principal y repetir todo lo que le enviemos sin procesar, de momento,
nada más. En el procedimiento procesa
si la línea es «abandonar»
llama a al procedimiento terminar
que sale de nuevo al sistema
mostrando una despedida.
Supongo que estaréis pensando ¡Qué mierda de código!, y os doy la razón. Pero esto es sólo la semilla de la que nacerá el nuevo inútil sistema.
Conclusión
Un amiguete me dice que no cuente nada, que cuando lo cuentas, los proyectos se gafan de alguna manera y no salen. No tengo esas supersticiones, los proyectos salen o se ponen según el empeño de los que los llevan a cabo. Sé que programaré con mucho empeño, compaginándolo con otros proyectos en marcha, en ratos libres, durante dos o tres meses. Si he terminado algo decente en ese tiempo, se lo enseñaré a alguien y si no, pues se quedará en el motón de pendientes. Pero seguro que por el camino encontraré buen aprendizaje.
Comentarios