Desarrollo de Blake's 7 (era "En qué estoy liado ahora...")

[kikems]

Último mensaje de la página anterior:

Jajj, esos ladrillos nos encantan en RW.

[Chema]

Pues igual suelto alguno entonces...

De momento ya tengo funcionando el cargado/salvado de la partida más o menos en su versión final (queda pulir cosas y probar y probar buscando fallos) pero la cosa es como comenté: el juego guarda automáticamente cuando el jugador hace algo relevante (hay un comando de script scSave(), así que es fácil hacerle grabar cuando sea necesario). Si, en arranque, se detecta que hay un juego salvado, tras la intro se presenta al jugador con un menú con la posibilidad de continuar jugando donde lo dejó o empezar un juego nuevo. El resto es automático. Si se ponen los guardados adecuadamente, el jugador no debería de tener ningún problema con el sistema.

He decidido, de momento, tener sólo un punto de guardado, porque es más simple y ahorro espacio de disco. Si dos personas quieren jugar a la vez (ya me extraña que lo haga una, pero en fin...) pues que se hagan dos copias del disco del juego. Tal y como es el guión no tiene sentido que un jugador tenga más de un punto de guardado.

He probado el sistema en todos los puntos donde graba y parece que funciona bien, pero quiero probar más, por si acaso.

También he estado trabajando con temas de temporizaciones, reescribiendo cómo se calculan algunas cosas. He metido en el menu principal la opción de elegir dos velocidades del texto hablado, normal y rápida para los que no tienen problemas con el inglés y les es demasiado lento el normal. También he puesto la opción de configurar el volumen (silencio, suave, normal y alto) y me falta la de redefinir las teclas.

Y, para terminar, he seguido con el desarrollo de la escena de la cárcel. Muy poco. La parte en que Vila te acompaña presentándote a la gente. Suena simple, pero ha quedado muy resultona.

Como tengo en la cabeza bastante más del guión de esta parte, a ver si puedo meterlo más o menos pronto para ir completando este segundo episodio. Digamos que tengo el diseño de la mitad y me quedan los detalles de la otra mitad

[Chema]

De momento, y para que nadie se impaciente, otra escena del juego (preliminar). En un momento dado, Blake y Avon intentan secuestrar la nave prisión accediendo y controlando su computadora mientras el resto del equipo busca la armería. Pero algo sale mal...

Es un buen momento para ir conociendo a los personajes, su carácter y trasfondo. Y para reproducir diálogos de la serie para los más frikis...

En otro orden de cosas mi compilador soporta el idioma Español y genera los códigos adecuados para el juego de caracteres (con tildes, eñes y signos de apertura de interrogación y exclamación). Eso quiere decir que es posible generar una versión en castellano, pero habría que ir buscando todos los textos en mil archivos y traduciendo, asegurándose de que los tamaños valgan, etc.

No sé si lo haré. Es mogollón de trabajo. En todo caso, al final o, al menos, mucho más adelante.

Bueno, ahí va el vídeo:
https://youtu.be/YNHyPHmBnDg

[jojo073]

Pues te felicito, te esta quedando genial!!! una pena que no este en cristiano... jaja

[kikems]

Me encanta. como ya dije antes, tengo que hacerme con un precioso Oric Atmos antes del lanzamiento del juego .

[dancresp]

Tiene un aspecto estupendo, pero lo que me empieza a quedar claro es que se va a tener que leer mucho. ¿Cierto?

[Chema]

Aún no lo sé. Desde luego todas estas escenas sí que tienen mucho texto porque intento mantener los diálogos originales de la serie. En la parte del juego hay algo menos, pero vamos, es una aventura. Así que...

[Silicebit]

¡¡Ja ja, que guapo!! ¡¡Me encanta!!

[Chema]

Me alegro de que os guste. Como curiosidad estuve dando vueltas a cómo diseñar las habitaciones dentro de la nave London para que fuesen diferentes y quedasen chulas y, al final fusilé me inspiré en los diseños del juego Oo-Topos. No hay demasiadas localizaciones aquí, así que...

Al final copio me inspiro en gráficos y diseños y métodos de aquí y de allá, incluso con el motor. No vaya a pensar nadie que, como decía mi madre, vengo a hacer caravana con el sombrero ajeno (vete tú a saber de dónde venía eso, pero se entiende... )

Y, reitero, sería posible una versión en cristiano, como dice jojo. Pero lleva curro.

[Chema]

¡Hala! Vamos allá... Si alguien consigue leerlo todo y quiere más información de algún punto, que levante la mano...



Avisados estáis

OASIS: un motor de juegos point&click para Oric

OASIS (Oric Advanced Script Interpreting System) es (o será pronto, espero) un motor para la creación de videojuegos de tipo aventura de “apuntar y pulsar” (point&click). Mejor dicho, es un conjunto de motores.

Sobre él estoy desarrollando mi próxima aventura basada en la serie “Los 7 de Blake” (Blake’s 7) que es una serie de ciencia ficción británica de finales de los 70 y que se emitió parcialmente en España algunos años después.

En este artículo intentaré describir los principios de diseño de OASIS, sin entrar en detalles técnicos de cómo se implementan las cosas en un Oric y sólo comentando las diferentes partes que lo integran y su funcionalidad a grandes rasgos. Puede ser interesante para todos aquellos que quieran tener una idea del trabajo que hay detrás del desarrollo de un motor como éste o como base para quienes quieran hacer algo parecido en otras máquinas.

Sólo un par de detalles: OASIS está inspirado en el increíble SCUMM.

Son Gilbert y Wilmunder los verdaderos genios que inventaron algo así para su fantástico (y rompedor) juego Maniac Mansion en el Commodore 64. OASIS es mi reinterpretación, escrita desde cero y con las particularidades específicas que quise darle. Hay muchas diferencias, no es ni siquiera un port parcial (nunca vi el código de SCUMM), pero las ideas de SCUMM (y de otros motores y de otros desarrollos de otra gente, como siempre) están ahí.

Al César lo que es del César.

Dicho esto, los motores que conforman OASIS principalmente son:

El motor de renderizado
Que se encarga del dibujado del área de juego con todos los elementos en la pantalla del Oric. Utiliza la misma técnica que el Skool Daze. Los fondos tienen una altura fija de 136 píxeles y hasta 762 píxeles de anchura y se dividen en tiles gráficos (caracteres de 6x8) para ahorrar memoria, al igual que los sprites. El motor se encarga de actualizar la imagen dependiendo del área del fondo mostrada en cada momento (si es el fondo es mayor que la imagen visible en pantalla) y redibujando sólo aquellos tiles que se modifican entre cuadros (frames). Ni que decir tiene que es aquí donde deben realizarse las mayores optimizaciones de código en velocidad.

Para dibujar los fondos con el modo gráfico que tiene el Oric (atributos serie) y convertirlos al formato que usa el motor, desarrollé una pequeña aplicación que me facilita el trabajo.

2016-12-14.png (50.81 KiB) Visto 4036 veces

Para dar sensación de profundidad, además de la imagen de fondo, se mantienen unas máscaras que se aplican o no dependiendo del plano-z al que está asignado un sprite en cada momento, para que éste aparezca detrás de otros elementos.

2016-12-14 (2).png (45.91 KiB) Visto 4036 veces

La interfaz de usuario
El módulo de interfaz de usuario se encarga de manejar las entradas de usuario y convertir las acciones que el jugador realiza con el cursor (apuntando y haciendo clic) en órdenes para el juego. Se encarga de mostrar los nombres de los objetos cuando se pasa sobre ellos (auto-highlight, algo que no se incluía en el Maniac Mansion original de C64), de detectar el verbo que el usuario quiere seleccionar resaltándolo (y teniendo la opción de tener verbos desactivados), de manejar el inventario y de componer la orden completa (verbo + objeto1 + objeto2-opcional) para su ejecución por el motor de acciones.

En OASIS se ha elegido la interfaz simplificada con 9 verbos que no apareció hasta el juego de LucasArts LeChucks Revenge: Monkey Island 2.

2016-12-14 (3).png (90.35 KiB) Visto 4036 veces

Juegos más modernos redujeron el conjunto de verbos hasta la mínima expresión. Finalmente los eliminaron para pasar a mostrar un menú contextual usando el botón derecho del ratón o métodos similares. En OASIS he preferido mantener los verbos para darle más aire retro, aunque es posible que en un futuro varíen algunos. Por ejemplo “Empujar” y “Tirar de” (Push/Pull) se pueden juntar en “Mover” y “Usar” (Use) es demasiado ambiguo.

Hay verbos que necesitan dos objetos en todos los casos (por ejemplo “Dar a” en “Dar Llave a Ana”). Esto se marca en unas banderas asociadas a los mismos y así el motor de interfaz sabe que no puede terminar de componer la acción hasta que el usuario no seleccione el segundo (“Ana”).

En otros casos es el propio objeto 1 el que sabe se necesita un objeto sobre el que actuar. El ejemplo típico es “Usar” en “Usar linterna” y “Usar llave con puerta”. La linterna puede usarse sola (se refiere a encenderse), pero la llave no. Por esto los objetos tienen también una bandera asociada que indica si se usan sobre otro objeto o no.

Todo esto debe tenerse en cuenta para simplificar la interacción del jugador y mejorar su experiencia de juego. Así, con el menor número de clics posible se compone la acción. Este principio también se tiene en cuenta para cambiar automáticamente a un verbo válido por defecto si es necesario. Supongamos que el usuario elige el verbo “Usar” y luego se arrepiente. Le basta hacer clic sobre cualquier zona de la pantalla y la acción pasa a ser “Caminar a” (Walk to), de manera automática. Es por esto que el verbo “Caminar a” no es necesario que esté en la lista: se toma de manera automática por defecto.

El motor de acciones
No hay tal cosa como un motor de Física en OASIS, porque no se contemplan colisiones ni dinámica a este nivel. Este motor se encarga de las acciones básicas en estos juegos, como la animación de los caracteres (la preparación del frame a mostrar por el motor de renderizado, se entiende), hacerlos hablar, mover la cámara realizando panorámicas, siguiendo a un personaje o de manera instantánea, etc. Pero sobre todo de hacer caminar a un personaje de un punto a otro de manera autónoma, decidiendo el camino a seguir y si el destino es alcanzable o no lo es e interpretar las acciones que realizan los personajes.

Todo ello de manera simultánea para todos los personajes y acciones, de modo que el motor (en cada cuadro) realiza un paso de todas las acciones en curso, por ejemplo, un paso de un personaje, un cuadro en la animación de otro que está hablando y un movimiento de cámara.

Enviando un personaje de paseo
Para realizar esta tarea, que a priori suena compleja, en el desarrollo de Maniac Mansion, Aric Wilmunder y Ron Gilbert inventaron el sistema de Walkboxes. Es una manera inteligente y simple de resolver el problema. Toda el área sobre el que un personaje puede caminar se divide en cajas numeradas. En memoria se mantienen las coordenadas de las cajas y otra información adicional, por ejemplo, si la caja está activa o no (si se puede caminar sobre ella en ese momento) o el plano-z asociado a un personaje que se encuentre en ella. En OASIS las cajas son rectangulares (se manejan de manera excepcional las que tienen bordes con esquinas para los laterales de la habitación), pero en juegos modernos pueden ser irregulares.

2016-12-14 (1).png (52.89 KiB) Visto 4036 veces

Sobre estas cajas se calcula la walkmatrix, una matriz que nos indica por cada entrada (i,j) la caja (intermedia) a la que el personaje se debe dirigir para alcanzar la caja j desde la i. Esta caja debe ser alcanzable (adyacente) desde la i.

Cuando el jugador hace clic sobre un punto en la pantalla para caminar hacia él, el motor calcula la caja más cercana y, a partir de ahí, dirige al personaje desde la caja en la que se encuentra hacia la siguiente (según la walkmatrix) por el camino más corto. Viene a ser como si dijésemos “¿quieres ir de la caja i a la j? Pues primero ve a la k”. Cuando se llega a la k se mira si es la caja de destino que buscamos y si no se repite mirando ahora la entrada (k,j).

Con esta información el motor calcula la ruta para ir de la posición actual hasta la nueva caja, es decir, el punto de contacto más cercano entre ambas. Cuando se alcanza la caja de destino, se calcula la ruta al punto elegido por el usuario.

Si por el camino, una caja intermedia está marcada como no activa (no se puede caminar sobre ella) el movimiento se detiene ahí. El personaje no puede pasar. De esta manera se pueden incluir fácilmente obstáculos tales como pozos, puertas cerradas, etc. Marcando la caja como activa, se permitirá el paso del personaje y se podrá saltar el obstáculo.
En OASIS la walkmatrix es pre-calculada desde el editor usando el mismo algoritmo que en ScummVM (según la documentación el algoritmo de Kleene, aunque se puede usar un Dijkstra) y exportada junto con la información de la habitación. En sistemas modernos se puede calcular de forma dinámica cuando se necesite y así buscar el camino más corto en cada momento.

Ron Gilbert explica muy bien la idea de las cajas en su blog acerca de Thimbleweed Park, su nuevo juego.

Interpretar las acciones
Interpretar una acción completa (verbo más objetos) no es solamente ejecutar la rutina que la lleve a cabo. Si queremos recoger un lápiz del suelo el personaje deberá acercarse a él primero y, si llega a él, entonces tomarlo.

El intérprete de acciones hace precisamente eso: controla que el personaje se mueva donde sea preciso y, si es posible, lanza la ejecución de la acción. Lo último depende del juego y por tanto consistirá en lanzar un script de usuario (más tarde hablaremos de los scripts). La primera parte sí que se implementa a este nivel.

Supongamos que la orden solo involucra a un objeto (por ejemplo “Examinar”). Lo primero que debe hacer el motor es determinar si el objeto está en nuestro poder (en el inventario) o no. En el primer caso no es necesario hacer nada y se puede lanzar el script asociado directamente. En el segundo, el personaje deberá moverse cerca del objeto para examinarlo.

Para cada objeto el motor mantiene información acerca de la posición donde un personaje debe situarse para interactuar con él y también hacia dónde debe de mirar. Si el objeto no tiene una posición fija (por ejemplo, otro personaje) el motor calcula dónde tiene que moverse el personaje sobre la marcha. En ambos casos se inicia el movimiento del mismo modo que se comentó anteriormente. Si se llega a la posición de destino, todo ha ido bien. Si no se puede alcanzar, entonces no se puede realizar la acción. La acción se busca en un script específico que incluye el código que se ejecuta cuando se interacciona con el objeto en cuestión y que es realizado por el diseñador del juego.

Si la orden involucra a dos objetos, el motor dirige al personaje hacia el primer objeto (si no está en el inventario) o hacia el segundo. El diseñador del juego puede decidir, de manera sencilla, si el personaje intenta coger el objeto y luego proseguir con la acción. El lenguaje de scripts proporciona potencia suficiente para ello.

El motor de sonido
El motor de sonido empleado en OASIS es el mismo que el utilizado en Oricium. Permite reproducir música y efectos de sonido sin ocupar demasiado (el motor ocupa del orden de 1.2Kbytes) y mantiene los ficheros de sonido con un tamaño también reducido (los pequeños temas que suenan en Oricium ocupan una media de 300 bytes cada uno).

El motor de sonido también proporciona mecanismos para activar eventos (poner bits de una zona de memoria a 1) a nivel de nota, para poder sincronizar otros procesos con la música.

Los efectos de sonido, además, incluyen una prioridad, de modo que se les asigna un canal libre si existe o reemplazan a efectos de menor prioridad si es necesario.

Este motor es simple y no permite hacer virguerías con el chip AY, pero es muy eficiente y usa pocos recursos, de modo que parce válido para un juego como éste.

El intérprete de scripts
Cuando Ron Gilbert y Aric Wilmunder desarrollaron Maniac Mansion en Lucasfilm Games (1987) crearon SCUMM (Script Creation Utility for Maniac Mansion) un intérprete de scripts que permitía desarrollar el juego en un lenguaje de alto nivel bastante potente que luego era interpretado por la máquina (un Commodore 64 en este caso).

SCUMM ha evolucionado hasta nuestros días, y versiones modernas se han utilizado en numerosos juegos (ver: SCUMM-Wikipedia). Otros fabricantes de videojuegos diseñaron sus propios intérpretes de scripts.

OASIS no es una versión de SCUMM para el Oric, pero su diseño está marcado por el funcionamiento de éste (y a veces de otros motores), por lo que no se puede decir que sea original, pese a estar escrito desde cero y ser incompatible y muy diferente en muchos aspectos.

El intérprete de scripts es una de las partes más complejas de OASIS. Básicamente OASIS funciona como una máquina virtual que ejecuta scripts de usuario de dos tipos posibles: código de objetos (respuestas a acciones de usuario sobre objetos) o scripts convencionales. Ambos siguen las mismas reglas y se ejecutan del mismo modo. La diferencia es que el primero contiene una tabla con offsets al código de respuesta para cada posible verbo o acción.

La máquina virtual posee un espacio de almacenamiento con dos secciones: variables de 8-bit y variables de 1-bit (banderas). Además, tiene dos tipos de memoria: global (compartido entre hilos de ejecución) y local (específico para cada uno).

OASIS proporciona servicios para ejecutar varios hilos en multitarea cooperativa (utilizando un mecanismo Round-Robin): las instrucciones se van ejecutando de un script hasta que se suspende por alguna razón, momento en el cual el flujo de ejecución se mueve al siguiente script. Cada script tiene la oportunidad de ejecutarse una vez por frame.

De esta manera es posible crear un script que simplemente se dedique a animar un reloj de pared, otro que controle si un guarda ve a un personaje hacer algo prohibido y actuar en consecuencia, otro que decida si determinado personaje entra en la habitación, etc. y lanzarlos simultáneamente.

Un script puede lanzar otro, como hijo para ejecutar en paralelo o cediéndole el control y esperando a su terminación. El sistema proporciona servicios de sincronización, pausa y reinicio, y parada completa de scripts que pueden llamarse desde el código.

Dos scripts son especiales en OASIS: el script 0 que es el punto de entrada del juego y el 1, para manejar acciones por defecto. Cuando arranca OASIS lo primero que hace es ejecutar el script 0, desde donde el desarrollador del juego puede cargar la introducción, realizar inicializaciones, lanzar otros scripts, etc.

El otro script especial es el script 1, que se llama siempre que una acción no puede realizarse porque el código del objeto no la soporta (es decir, no tiene el verbo en su tabla). En su versión más sencilla podría hacer decir al personaje “No sé cómo hacer eso” o algo parecido, pero puede complicarse tanto como se quiera para dar variedad.

El código usado en los scripts está altamente especializado y contiene desde operaciones aritméticas simples y saltos condicionales, hasta acciones complejas como cargar una habitación o un objeto, activar/desactivar walkboxes, hacer hablar o moverse a un personaje, mostrar/ocultar los verbos o el cursor del ratón, mover la cámara u ordenar la ejecución por parte de un personaje de una acción completa.

Describir aquí el lenguaje de scripts con sus comandos y funciones es imposible (actualmente contiene 69 comandos y más de 50 funciones diferentes). La especificación completa la estoy documentando y puede consultarse en este documento (en inglés).

Si alguien está interesado en el funcionamiento de este tipo de intérpretes, lo mejor es visitar la Wiki de ScummVM en el apartado de Technical_Reference.

Para simplificar el desarrollo implementé un compilador utilizando Antlr4 y C# que me permite usar un código más amigable, con estructuras de control, chequeo básico de tipos, y ese tipo de cosas. Además soporta no solo scripts, sino también la definición de otros tipos de recursos, como las cadenas de texto. Respecto a esto último, soporta los caracteres del español (¿¡ñÑ y vocales acentuadas) y los traduce a los códigos ASCII necesarios para que se vean correctamente con el juego de caracteres en el Oric.

A modo de ejemplo, este es el script que hace que Vila nos siga por la celda para ir presentándonos al resto de personajes:

Código: Seleccionar todo

/* Script that makes Vila be nearby when we walk */
script 200{   
   byte cb;
   byte cv;
   cb=sfGetCol(BLAKE);
   cv=sfGetCol(VILA);
   if( cb>cv ){
      if((cb-cv)>10)
         scActorWalkTo(VILA,cb-5,14);
   }
   else{   
      if((cv-cb)>10)
         scActorWalkTo(VILA,cb+5,14);
   }
   scWaitForActor(VILA);
   scDelay(50);
   scRestartScript();
}


O este código que realiza la introducción el Episodio 2

Código: Seleccionar todo

   // Disable Fade Effects
   scSetFadeEffect(0);
   scClearRoomArea();
   scLoadRoom(ROOM_EPISODE2);

   // Set the destination for ESC press
   scSetOverrideJump(here);

   scDelay(100);
   scClearRoomArea();
   
   // Pic with the exterior of the London ship
   scLoadRoom(200);
   
   // Prepare everything for camera pan
   scSetCameraAt(120);
   scBreakHere();

   scDelay(50);
   scPanCamera(0);
   scWaitForCamera();
   scDelay(80);
   scPrintAt(200,0,8,104);
   ...


También tiene bucles for, while, etc. Estos ficheros se pasan por el compilador que genera código fuente para el ensamblador del Oric con el formato correcto.

Gestión de recursos
Este tipo de motores se pueden optimizar para que ocupen poco espacio en memoria. De hecho, OASIS en su versión actual (aunque no está completo al 100%) ocupa algo más de 16 Kbytes. Sin embargo, los juegos que se realizan con ellos suelen ser muy ricos gráficamente y muy variados en cuanto a los textos, sonidos y acciones que ocurren en el juego.

Si queremos realizar un juego medianamente decente, no podemos utilizar sólo la memoria RAM del Oric. Es por eso que OASIS, al igual que SCUMM y que el resto de motores de este estilo, carga bajo demanda la información que necesita desde disco.

Para hacer esto todos los datos del juego están empaquetados en recursos, que se cargan cuando el motor los solicita. Los recursos pueden ser de varios tipos, por ejemplo, scripts de código, definición de una habitación, gráficos de un objeto, código de un objeto, paquetes con cadenas de texto, música, etc… A partir de aquí se utiliza una especie de gestor de memoria, que se encarga de cargar y liberar recursos de memoria según sea necesario.

Cuando el motor solicita un recurso, se busca en memoria y, si se encuentra, se aumenta su contador de referencias y se devuelve un puntero a él. Si no está, se busca en disco y se carga en memoria sobre la marcha. Si no hubiese memoria libre, se realiza recolección de basura y compactación. En el disco los recursos se encuentran comprimidos para ahorrar espacio y se descomprimen sobre la marcha, gracias a la aplicación FloppyBuilder incluida en el kit de desarrollo del Oric (¡gracias Dbug!) el OSDK.

En OASIS se utiliza una cabecera de 3 bytes para manejar los bloques de memoria. El primer byte contiene el tipo de bloque y unos bits especiales y los otros dos el tamaño del mismo.

Byte 1
Bit 7 Bloqueado (=1)
Bits 6-4 Contador de Referencias
Bits 3-0 Tipo de recurso o libre (=0)
Bytes 2 y 3 Tamaño del recurso

Un recurso en uso (contador de referencias distinto de cero) o bloqueado no puede ser eliminado de memoria, aunque puede moverse. El uso de ambos campos es necesario porque muchas funciones bloquean el recurso, utilizan los datos y lo liberan, mientras que el programador puede (por eficiencia) querer que el recurso no sea descartado de memoria hasta que lo desbloquee.

Si los bits 0 a 3 contienen el valor 0, el bloque está libre (no contiene información válida). En otro caso contiene un recurso. El identificador del recurso se indica en el primer byte tras el tamaño. El tamaño es un offset de 2 bytes que permite encontrar el siguiente bloque en la lista.

De este modo el algoritmo es muy simple. Cuando se quiere cargar un recurso de un tamaño determinado T se hace:

1. Recorrer la lista de bloques buscando el recurso.
2. Si se encuentra, se marca aumenta su contador de referencias y se retorna el puntero a los datos. Fin.
3. Recorrer la lista de bloques actual buscando uno marcado como libre y no bloqueado (bits todos a cero) cuyo tamaño sea mayor o igual que T.
4. Si se encuentra uno se divide en dos bloques: uno de tamaño T y otro libre con el resto del bloque antiguo (si no es vacío), se ajustan las cabeceras y se carga la información del disco en el primero. Se actualiza el contador de referencias y se retorna el puntero a los datos. Fin.
5. Si no se encuentra un bloque adecuado y aun no se ha compactado la memoria se lanza el proceso de compactación y se vuelve al paso 3.
6. Si no ha habido éxito se genera un error de memoria.

El proceso de compactación simplemente mueve al inicio de la memoria todos los bloques ocupados o bloqueados, juntando los bloques libres o recursos marcados como no usados (y no bloqueados) en un solo bloque libre.

Esta solución es muy simple, para que se pueda implementar de manera eficiente en un Oric. En computadores más potentes, se pueden usar otras aproximaciones que permitan más flexibilidad o eficiencia en la gestión de la memoria.

El sistema de recursos es muy complejo y esto es sólo un resumen de la idea principal. Existen dos tipos de recursos, por ejemplo: globales y locales (sólo tienen sentido en una habitación) que se tratan de manera ligeramente diferente y permiten ciertas optimizaciones importantes. También hay que tener en cuenta que, al compactar los recursos en memoria, los punteros que se tengan a ellos, dejan de tener validez. Actualmente existen muchos métodos para gestionar este tipo de cosas, en OASIS se actualizan los punteros necesarios tras la compactación antes de regresar de la rutina de carga.

El sistema de recursos tiene muchas ventajas. Por ejemplo, es posible separar los datos de un objeto (posición, tamaño, propiedades…), de su apariencia gráfica (recursos COSTUME – con, por ejemplo, frames de animación) y del código que se ejecuta cuando se interacciona con él. De este modo se puede cambiar la apariencia gráfica de un objeto, cargar frames con una animación específica, o compartir gráficos entre objetos. Además, sólo los datos que se necesitan se requieren en memoria en un momento dado, pudiendo liberar espacio para otros recursos.

Conclusiones
Esta descripción apenas es una introducción funcional de OASIS, motor que aún no está acabado al cien por cien (aunque está relativamente cerca de estar completo). Espero que sirva para aquellos interesados en conocer cómo puede ser la arquitectura de un motor para juegos de aventuras de “apuntar y pulsar” clásicas. Naturalmente con ordenadores modernos y más potentes, la arquitectura se puede complicar para dotar de más funcionalidad al juego (lo primero que se viene a la mente es la incorporación del 3D).

También espero que sirva para hacerse una idea de la cantidad de trabajo detrás de algo aparentemente tan simple. Lo que ocurre es que, si el diseño es bueno y potente, las posibilidades para el juego crecen exponencialmente, así como la facilidad de desarrollo del mismo.

OASIS se irá terminando según se vaya desarrollando el juego de Blake’s 7. Seguro que se irán incorporando funcionalidades según se vayan necesitando y se irán depurando aspectos según se encuentren problemas. Cuando el juego esté en versión BETA, también lo estará OASIS, aunque seguro que muchos errores quedarán ocultos incluso aunque el juego se pruebe a fondo, porque habrá cosas que el motor proporciona que no se habrán utilizado de todos los modos posibles.

Un proceso similar ocurrió con el desarrollo del motor isométrico WHITE+NOISE y la aventura Space:1999, así que soy optimista.

[dancresp]

Uno de los mejores ladrillos en RW en los últimos tiempos.

La gracia del proyecto no está solo en desarrollar el juego, que tela, sino que encima previamente el señor chema se ha currado todas las herramientas para poderlo desarrollar.

En resumen, una pasada.

Por cierto, ignoraba esto del "White+Noise" y por lo visto es un juego isométrico.
¿Existe realmente al 100%?

[Chema]

Gracias dancresp. Me alegra de que te haya gustado el ladrillo

Por cierto, ignoraba esto del "White+Noise" y por lo visto es un juego isométrico.
¿Existe realmente al 100%?

Es el motor (en dos capas) que implementé para Space:1999, originalmente se podía usar desde C, pero el juego se hizo en ensamblador 100%.

[Chema]

Hola otra vez.

Aunque parezca que no (y con una semana en cama por en medio) he avanzado bastante en el juego. De momento nada que se pueda enseñar sin fastidiar el argumento, pero diría que el 60% del Episodio II ya está listo y está diseñado el argumento y los puzzles como al 95%. Ahora toca diseñar algunas habitaciones para la parte final en el planeta Cygnus Alpha (unas 4-5 pantallas) y empezar con el argumento del Episodio III.

Llevo de momento 26 habitaciones diferentes, y me metido nuevos puzzles (espero que interesantes). Esta parte es un poco diferente a la hora de jugarla, porque se basa más en las interacciones y en resolver problemas puntuales con pocos recursos y en pocas habitaciones (como salir de la prisión). Y tiene muchas escenas automáticas y diálogos. Pero creo que funciona bien, que queda simpática e interesante. Espero que, al final, os guste.

Por desgracia me he tenido que pelear ya en un par de ocasiones con el límite de memoria. Hay una escena (la de la prisión) que tiene 6 personajes diferentes y mucho texto y que necesita mucha memoria para ejecutarse. Apenas me queda espacio libre para nada ahora mismo (como 500 bytes en memoria normal y menos de 200 en memoria alta) y me quedan cosas por programar, como poder redefinir el teclado o soportar el uso de joystick. Y las tablas con los datos de disco crecen según voy metiendo información, así que esto se va a volver un problema.

Al menos el motor está prácticamente finalizado.

Un aspecto interesante es que estoy probando cómo sería traducirla al castellano. El sistema ya está. Con poner #define SPANISH y compilar los menús y esas cosas aparecen en castellano (con tildes y eñes y eso). Eso sí, se requeriría traducir TOOOOOODO el texto. En los scripts es cosa de ir cadena por cadena, fijándose en que ninguna pase de los 39 caracteres que se pueden escribir por línea (más el atributo de color). Bueno, eso y no hacerlo crecer demasiado, porque ocupa más memoria...

Como las cadenas están en recursos que he llamado stringpack es algo así como tocar los archivos con el código así:

Código: Seleccionar todo

stringpack 200{
#ifndef SPANISH
"String 1";
"String 2";
...
#else
"Cadena 1";
"Cadena 2";
...
#endif
}

Se pueden añadir otros idiomas con el uso adecuado de directivas del preprocesador. Pero hay cadenas en otros sitios, como en los objetos (los nombres) y esos están más diseminados por los archivos de recursos.

Vamos un trabajo de chinos, pero factible. Como os dije en su día, prometo intentar tener una versión en castellano.

[jojo073]

Tener ese juego en castellano seria genial!!!
gran trabajo chema... a ver si esta semana te termino esos gráficos y te los mando...
saludos

[kikems]

Joer , la verdad que piensas en todo, en mi caso la mayoría de esos problemas que tu ves antes de empezar , yo me los encuentro cuando suele ser demasiado tarde y trabajoso resolverlo . En mi caso necesitaría hacer cada juego 3 o 4 veces para llegar a tener la previsión que tu tienes.

[Chema]

Venga, va... os muestro un diseño de los que estoy haciendo... Para que veáis los peligros que acechan

161 tiles usadas y un total de 2427 bytes.

dangers.png (34.91 KiB) Visto 3893 veces

[web8bits]

La verdad es que avanza muy, pero que muy bien el juego, eres un crack Chema, deseando catarlo en la máquina real.

Un saludo