ORCO (especificación)

De WikiCAAD, la enciclopedia aventurera.

Por Al-Khwarizmi


Contenido

Creando un front-end para la ejecución de aventuras de texto

Escribo aquí mis ideas sobre lo que podría ser el camino a seguir para la creación de un programa organizador para aventuras de texto, lo que llamaré proyecto ORCO (Organización de Conversacionales y Otras).


Especificación de requisitos de usuario y técnicos

La idea es que un usuario totalmente novato pueda instalarse un programa en su ordenador que ofrezca la siguiente funcionalidad:

  • Mostrar una lista de aventuras que se actualice cuando aparezcan aventuras nuevas.
  • Que la lista de aventuras sea clasificable/ordenable/filtrable según criterios como género, autor, plataforma, año, etc.
  • Que el usuario pueda consultar información sobre cada aventura (como la dicha, además de descripción y captura de pantalla) sin necesidad de descargársela.
  • Que el usuario pueda descargarse las aventuras de una forma totalmente transparente desde el mismo programa, sin tener que introducir para ello ninguna URL o similares.
  • Que los entornos de ejecución de aventuras (intérpretes) se descarguen del mismo modo, y que el usuario novato ni siquiera necesite enterarse de su existencia, aunque se incluyan opciones y facilidades de configuración al respecto para usuarios más avanzados.

Desde un punto de vista más técnico, se consideran además los siguientes requisitos:

  • Multiplataforma, en el sentido de que pueda funcionar al menos en los tres sistemas operativos más utilizados en la actualidad (windows, linux y mac). En un momento en el que la amplia supremacía de windows está empezando a ser cuestionada debido a la inestabilidad de vista y las mejoras de linux, parece imperativo no centrarse sólo en el sistema mayoritario (windows).
  • Que el protocolo utilizado permita la creación de otros programas alternativos a quien así lo desee. La idea es crear un formato o protocolo para representar todos los datos que una herramienta automática pueda necesitar para descargar, instalar y ejecutar aventuras; y proporcionar una implementación de referencia de una herramienta que utilice dicho protocolo. Pero el protocolo debe estar bien especificado de forma que cualquiera pueda hacerse su propia herramienta.
  • Que la gestión de listas de aventuras pueda llevarse a cabo también de manera independiente, de manera que el programa (implementación de referencia) sea totalmente configurable en cuanto a de dónde se toman los metadatos.
  • Que tanto la documentación del protocolo como la implementación de referencia estén bajo licencia libre.

El cumplimiento de estos requisitos técnicos nos proporcionaría un programa de vida útil larga, que además podría ser de interés para otras comunidades (relacionadas con aventuras de texto de otros países o hasta con otros tipos de juego), y garantizaría que hubiese el suficiente interés para mantener el software y las listas bien actualizadas.


Formato de datos

Lo primero que se ha de pensar si se quiere sacar adelante el proyecto ORCO es, por lo tanto, qué información necesita un cliente para descargar, instalar y ejecutar una aventura de texto sin intervención del usuario; pues ésta será la información que un servidor deberá proporcionar para que los front-ends la descarguen y utilicen para hacer su trabajo. Creo que el siguiente modelo de datos cubre adecuadamente los requisitos:

  • Se mantiene una lista de JUEGOS.
  • Cada juego se identifica por un título, pero puede haber diferentes VERSIONES identificadas por números de versión.
  • A cada versión se le asociarán los metadatos informativos para el usuario como fecha, descripción, o URL de una imagen representativa.
  • A cada versión se le asociará una o varias (por motivos de redundancia) direcciones URL donde el cliente se puede descargar el juego.
  • A cada versión se le asociarán unas "instrucciones de instalación" para describir cómo se ha de extraer el fichero descargado y colocarlo en un directorio local.
  • A cada versión se le asociará un FORMATO, identificado por un determinado nombre. Podemos definir un formato como un conjunto de aventuras que se pueden ejecutar de la misma manera o a través de la misma herramienta en cada plataforma que soporten. Por ejemplo glulx, z5, AGE, o .exe.
  • Se mantiene una lista de FORMATOS.
  • Cada formato se identifica por un nombre que puede incluir información de versión si ésta es relevante de cara a decidir cómo se va a ejecutar la aventura.
  • A cada formato se le asocia una lista de PLATAFORMAS (intérpretes, runtimes, etc.) que pueden utilizarse para ejecutar juegos en ese formato, así como qué versión mínima de la plataforma se requiere.
  • Se mantiene una lista de PLATAFORMAS.
  • Cada plataforma se identifica por un título que no incluye información de versión.
  • Cada plataforma puede tener una serie de VERSIONES, por ejemplo, gargoyle 1.0.
  • Cada versión puede tener una serie de BUILDS, por ejemplo, gargoyle 1.0 para linux. Un build se corresponde con una distribución de esa versión (normalmente para un determinado sistema operativo).
  • A cada build se le asociará una lista de sistemas operativos en los que funciona.
  • A cada build se le asociará una lista de requisitos adicionales, si los hay. (por ejemplo que tenga que estar instalada una máquina virtual java).
  • A cada build se le asociará una o varias (por motivos de redundancia) direcciones URL donde el cliente se puede descargar ese intérprete.
  • A cada build se le asociarán unas "instrucciones de instalación" para describir cómo se ha de extraer el fichero descargado y colocarlo en un directorio local.
  • A cada build se le asociarán unas "instrucciones de ejecución" para describir cómo se ha de usar, una vez instalada, para ejecutar una aventura.

Representando esto en XML, tendríamos estructuras como éstas:

<orco-games>

	<game title="El Archipiélago" version="1.0">

		<origdate>040211</origdate>
		<versiondate>040322</versiondate>

		(...) (datos de descripción, autor, URL de imagen...) 

		<local>
			<location dir="${GAMES}/archipielago10/"/>
		</local>

		<download>
			<location url="http://www.caad.es/descargas/archipielago.zip" to="${DOWNLOADS}/archipielago.zip"/>
			<location url="http://www.if-archive.org/downloads/a/ar/archipielago.zip" to="${DOWNLOADS}/archipielago.zip"/>
		</download>

		<install>
			<command name="deldir" arg="${GAMES}/archipielago10/"/>
			<command name="mkdir" arg="${GAMES}/archipielago10/"/>
                        <command name="extract" file="${DOWNLOADS}/archipielago.zip" todir="${GAMES}/archipielago10/"/>
			<command name="del" arg="${DOWNLOADS}/archipielago.zip"/>
		</install>

		<format name="glulx 2.0">
			<param name="file" value="${GAMES}/archipielago10/archipielago.glulx"/>
		</format>

	</game>

	<game title="Eudoxio" version="1.0">

		<origdate>970211</origdate>
		<versiondate>970322</versiondate>

		(...) (datos de descripción, autor, URL de imagen...) 

		<local>
			<location dir="${GAMES}/eudoxio/"/>
		</local>

		<download>
			<location url="http://www.caad.es/descargas/eudoxio.zip" to="${DOWNLOADS}/eudoxio.zip"/>
		</download>

		<install>
			<command name="deldir" arg="${GAMES}/eudoxio/"/>
			<command name="mkdir" arg="${GAMES}/eudoxio/"/>
                        <command name="extract" file="${DOWNLOADS}/eudoxio.zip" todir="${GAMES}/eudoxio/"/>
			<command name="del" arg="${DOWNLOADS}/eudoxio.zip"/>
		</install>

		<format name="windows executable">
			<param name="file" value="${GAMES}/eudoxio/eudoxio.exe"/>
		</format>

	</game>

</orco-games>

<orco-formats>

	<format name="glulx 2.0">
		<execution>
			<platform name="gargoyle" requiredVersion="2.2.4">
				<param name="file" value="${FILE}"/>
			</platform>
			<platform name="winglulxe" requiredVersion="1.0">
				<param name="file" value="${FILE}"/>
			</platform>
		</execution>
	</format>

	<format name="windows executable">
		<execution>
			<platform name="windows executable">
				<param name="file" value="${FILE}"/>
			</platform>
		</execution>
	</format>

</orco-formats>

<orco-platforms>

	<platform name="gargoyle">

		<version id="2.2.4">

			<build name="gargoyle for windows 2.2.4">

				<supportedOs name="windows"/>

				<local> <!--used to check existence, relative to platforms_path-->
						<location dir="gargoyle224/"/>
				</local>

				<download>
					<location url="http://www.if-archive.org/downloads/g/ga/gargoyle.zip"/>
				</download>

				<install>
					<command name="deldir" arg="${PLATFORMS}/gargoyle224/"/>
					<command name="mkdir" arg="${PLATFORMS}/gargoyle224/"/>
                                        <command name="extract" file="${DOWNLOADS}/gargoyle.zip" todir="${PLATFORMS}/gargoyle224/"/>
					<command name="del" arg="${DOWNLOADS}/gargoyle.zip"/>
				</install>

				<execute>
					<command name="exec" arg="${PLATFORMS}/gargoyle224/gargoyle.exe ${FILE}"/>
				</execute>

			
			</build>

			<build name="gargoyle for linux 2.2.4">
	
				<supportedOs name="linux"/>

				<local> 
						<location dir="gargoyle224/"/>
				</local>

				<download>
					<location url="http://www.if-archive.org/downloads/g/ga/gargoyle.zip"/>
				</download>

				<install>
					<command name="deldir" arg="${PLATFORMS}/gargoyle224/"/>
					<command name="mkdir" arg="${PLATFORMS}/gargoyle224/"/>
                                        <command name="extract" file="${DOWNLOADS}/gargoyle.zip" todir="${PLATFORMS}/gargoyle224/"/>
					<command name="del" arg="${DOWNLOADS}/gargoyle.zip"/>
				</install>

				<execute>
					<command name="exec" arg="${PLATFORMS}/gargoyle224/gargoyle -b ${FILE}"/>
				</execute>

			</build>

		</version>


	</platform>



	<platform name="age">

		<version id="0.7.2">

			<build name="age 0.7.2">

				<supportedOs name="windows"/>
				<supportedOs name="linux"/>
				<supportedOs name="macOs"/>

				<requires platform="java"/>	

				<local> <!--used to check existence, relative to platforms_path-->
						<location dir="age072/"/>
				</local>

				<download>
					<location url="http://www.irreality.eu/age/age072.zip"/>
				</download>

				<install>
					<command name="deldir" arg="${PLATFORMS}/age072/"/>
					<command name="mkdir" arg="${PLATFORMS}/age072/"/>
                                        <command name="extract" file="${DOWNLOADS}/age072.zip" todir="${PLATFORMS}/age072/"/>
					<command name="del" arg="${DOWNLOADS}/age072.zip"/>
				</install>

				<execute>
					<if os="windows">
						<command name="exec" arg="${PLATFORMS}/age072/age.bat ${FILE}"/>
					</if>
					<if os="linux|macOs">
						<command name="exec" arg="${PLATFORMS}/age072/age.sh ${FILE}"/>
					</if>
				</execute>

			
			</build>

		</version>

	</platform>


	<platform name="windows executable">

		<version id="-">

			<build name="native">

				<supportedOs name="windows"/>

				<alwaysPresent/>

				<execute>
					<command name="exec" arg="${FILE}"/>
				</execute>

			
			</build>

			<build name="emulated under linux">

				<supportedOs name="linux"/>

				<requires platform="wine"/>

				<execute>
					<command name="exec" arg="wine ${FILE}"/>
				</execute>

			
			</build>

		</version>

	</platform>

</orco-platforms>

De este modo, un front-end puede cumplir los requisitos de usuario como sigue:

  • Mostrar una lista de aventuras que se actualice cuando aparezcan aventuras nuevas.
  • Que la lista de aventuras sea clasificable/ordenable/filtrable según criterios como género, autor, plataforma, año, etc.
  • Que el usuario pueda consultar información sobre cada aventura (como la dicha, además de descripción y captura de pantalla) sin necesidad de descargársela.

El front-end se conecta a una URL que tiene especificada en su configuración (y que puede ser modificable) y se baja un fichero xml con la lista de "orco-games". En dicha lista está contenida la información de las aventuras.

Adicionalmente, el front-end puede tener almacenadas localmente, o bien bajarse del servidor, la lista de "orco-formats" y "orco-platforms" para así poder:

  • Mostrar sólo las aventuras que se pueden ejecutar en ese sistema operativo,
  • Diferenciar entre aventuras cuya plataforma ya está instalada o no.
  • Que el usuario pueda descargarse las aventuras de una forma totalmente transparente desde el mismo programa, sin tener que introducir para ello ninguna URL o similares.

La URL de descarga se encuentra en la lista de "orco-games". El front-end puede usar la información en el elemento "local" para determinar si una aventura está ya descargada o no. El directorio especificado bajo el elemento <local> debería crearse al instalar la aventura, así que si existe es que está instalada.

Por supuesto, adicionalmente el front-end puede hacer una gestión más robusta, como simplemente tener un fichero xml local donde marque como instaladas o no las aventuras.

Una vez descargada la aventura, el front-end ejecuta los comandos especificados en el elemento <install>. Todo front-end debería venir con un descompresor de los principales formatos de fichero comprimido para ejecutar los comandos de descompresión.

  • Que los entornos de ejecución de aventuras (intérpretes) se descarguen del mismo modo, y que el usuario novato ni siquiera necesite enterarse de su existencia, aunque se incluyan opciones y facilidades de configuración al respecto para usuarios más avanzados.

Con los entornos de ejecución se hace lo mismo que con las aventuras, su información está en "orco-platforms".

Se puede determinar qué plataforma necesita un usuario para ejecutar una aventura mirando el <format> de la aventura, yendo a la lista "orco-formats", mirando en qué plataformas se puede ejecutar ese formato, y cuáles están disponibles en el sistema operativo del usuario.

Si hay varias disponibles (¿gargoyle y winglulxe?), el front-end puede ejecutar una por defecto, o en un modo más avanzado preguntar al usuario o ser configurable sobre cuál se prefiere.

Para ejecutar una aventura en una plataforma, se va al campo <format> de la aventura, se cogen los parámetros especificados bajo <format>, se va a "orco-formats", al formato correspondiente, y se sustituyen los ${PARAMETRO} por el valor del parámetro asignándolos a parámetros de ejecución al seleccionar una plataforma. A continuación, se va a "orco-platforms" a la plataforma correspondiente, a la última versión para nuestro sistema operativo, se instala si no está ya instalada, y se usan las instrucciones de ejecución sustituyendo los ${PARAMETRO} por sus valores para ejecutar la aventura.

Arquitectura cliente-servidor

La idea es que el servidor tenga las tres listas (orco-games, orco-formats, orco-platforms), y que se actualicen frecuentemente, seguramente con ayuda de una herramienta GUI para ello que sería fácil de hacer.

El front-end, en una versión muy básica y ligera, puede no llevar absolutamente nada y descargarse las listas del servidor, bajándose cada plataforma "bajo demanda".

También se puede distribuir un front-end que tenga sus propias listas locales de plataformas y no tenga que confiar en el servidor para eso, o bien que tenga sus listas locales de plataformas y las actualice contra el servidor sólo cuando lo pida el usuario.

En suma, la elección de qué está en el cliente y qué está en el servidor corresponde a cada cliente o front-end que se implemente. Una buena solución es comenzar con plataformas y formatos en el cliente, bajarse las aventuras, tener la lista de aventuras cacheada en el cliente pero actualizarla cada vez que se ejecute con el servidor si éste está disponible y el cliente está conectado a internet, y por último actualizar la lista de formatos y plataformas llamando al servidor sólo si se encuentra en la lista de aventuras alguna referencia a una plataforma que el cliente no conoce.

La responsabilidad de la seguridad se coloca en el cliente. Obviamente, un cliente que confía totalmente en el servidor es inseguro, dado que nada impide a quien sirva el XML poner una línea diciendo que para ejecutar juegos en tal plataforma tienes que ejecutar tal exe (un virus). Pero creo que de momento no deberíamos preocuparnos mucho de estas cosas porque es improbable que algo así suceda a corto plazo, dado que no somos una comunidad tan grande como para que los crackers se fijen en nosotros y se trabajen algo así. En todo caso, se puede crear y distribuir sin mucho trabajo una versión "paranoica" de la implementación de referencia que nunca actualice las listas de plataformas con el servidor y que sólo conozca plataformas seguras como intérpretes Z y glulx, y eso sería totalmente seguro. Asimismo, se puede incluir esto como opción en una distribución genérica (modo paranoico o modo confiado).

A más largo plazo, parece viable asociar hashes MD5 a todo lo que se baje del servidor, y añadir la posibilidad de que el hash se contraste con varios servidores; pero creo que si metemos funcionalidad de ese tipo desde el principio lo que conseguiríamos sería aumentar la probabilidad de generar vaporware.

Herramientas personales