Autor: [EX3] (José Miguel Sánchez Fernández)
Nombre del proyecto: T.L.S.A. Engine
Descripción: Motor de juegos programable
Fecha de inicio del proyecto: sábado, 22 de marzo de 2004
Ultima actualización: Friday, 01 de October de 2004
Numero de versión actual: 0.1.694
Estado de la versión: Alpha

Índice de contenidos:

1.- Descripción de proyecto
2.- Registro de progresos del proyecto
3.- Próximos objetivos
 

1. Descripción del proyecto

T.L.S.A. son la siglas del nombre del juego que dio origen al proyecto dx_lib32, The Light Star Adventure. Dado mi nivel de ingles en su día me es fácil suponer que el nombre no tenga una sintaxis correcta, pero eso es lo de menos en estos momentos. TLSA iba a ser en sus comienzos hace ya algo mas de 4 años una aventura grafica debido a que era un genero fácil de llevar a cabo. Pero actualmente, con lo aprendido durante estos 4 años gracias al desarrollo de la dx_lib32 y de demás experimentos llevados a cabo con lenguajes como Div2, me decidí a cambiar el genero del juego a ROL en tiempo real isométrico mezclado con algo de plataformas al estilo Prince of Persia o Flash Back. La idea de mezclar en el juego dos géneros diferentes es para dotar al juego de diferentes perspectivas a la hora de jugar. La posibilidad de poder navegar por escenarios y perderse por pasadizos o cualquier otro tipo de estructuras y el poder navegar por niveles con obstáculos, abismos y demás características de un plataformas al puro estilo Prince of Persia.

Dado que la dx_lib32 ya esta preparada para poder llevar a cabo el desarrollo de juegos con ella decidí comenzar a diseñar el motor del TLSA. Estudie multitud de posibilidades. La que mas me gusto era la de poder crear un motor que se pudiese reutilizar para diferentes juegos y con la posibilidad de cambiar el mecanismo de los niveles que definen el genero. Algo así como permite el motor de Half-Life que modificando scripts y la dll del juego te permite hacer con un motor de shot-em-up un juego de carreras o un simulador de vuelo. Entones empecé a darle vueltas a la idea. Al final vi que lo mejor era hacer un motor que funcionase con scripts, scripts que definirían el comportamiento de las entidades, de como se deben generar los niveles del juego y demás funcionalidades internas del propio juego.

La idea es crear un programa que de una amplia base para el desarrollo de juegos. Esto significa que el motor en si ya ofrece ciertas funcionalidades y características necesarias para llevar a cabo el desarrollo de un juego. El motor controlara e inicializara la dx_lib32 por el usuario, comprobara si el sistema soporta el motor, si falta algo necesario (alguna dll o archivo especifico), dará soporte de recursos como hacen motores como el Quake, Half-Life, etc, mediante archivos paquetes con el formato PAK (el mismo formato usado por Quake, Quake2, Half-Life, Heretic2) dando así la posibilidad de utilizar cualquiera de los editores PAK disponibles para estos juegos, un manejador de recursos que se encargara de almacenar en memoria los recursos que necesite el juego mientras se ejecuta y facilitar el acceso a los mismos desde el script, un sistema de entidades que se programaran mediante scripts, un sistema para generar logs o registros de sucesos que puede ser llamado desde el script para registrar sucesos internos del juego, y un completo sistema de scripts basados en el lenguaje BASIC que facilitaran la programación de los mismos gracias a su sencilla sintaxis y a las funciones orientadas para el desarrollo de juegos añadidas.

El objetivo del motor no es mas que el de evitar la programación de la base o motor y programar única y exclusivamente los diferentes módulos que conformaran el juego: menús, pantalla de carga, sistema de niveles, consola de comandos, etc. Luego aparte se podrán cargar scripts para poder ampliar las funcionalidades del motor y del juego, algo así como plugins, ideal para crear modificaciones para el juego.

El motor esta siendo programado, al igual que la dx_lib32, en Visual Basic 6.0 con dx_lib32, que dota de soporte grafico, sonido, video, entrada de periféricos y funciones de sistema, y el Microsoft Script Control 1.0 que dota al motor de la base para crear un script rápido y personalizable con sintaxis idéntica al BASIC utilizado por Visual Basic (mas concreto Visual Basic Script ya que este esta muy limitado en comparación a Visual Basic tradicional). Tanto la dx_lib32 como el MS Script Control vendrán incluidos con el TLSA Engine.
 

2. Registro de progresos del proyecto

Sábado, 22 de Marzo de 2004
---------------------------
Inicio del proyecto. Se comienza a programar el arranque del motor: inicialización de la dx_lib32, comprobación sencilla del sistema. Si ocurre algún error durante el arranque el motor detiene la inicialización y muestra un mensaje de error describiendo el error ocurrido, sus posibles causas y posibles soluciones.

Miércoles, 24 de Marzo de 2004
------------------------------
Sistema generador de logs terminado. El programa genera en memoria el log durante la ejecución y al terminar lo guarda por fecha numero de ejecución en dicha fecha (Ej.: TLSA_LOG(24-03-2004)02.LOG)
Se comienza a programar la búsqueda de recursos de archivos PAK.

Jueves, 25 de Marzo de 2004
---------------------------
Sistema de búsqueda de archivos PAK terminada. El motor busca todos los PAK en una ruta especifica y según ruta donde se encontrara el juego por defecto "\DATA\TLSA\GameData\*.PAK". El motor después de buscar todos los PAK genera una lista con todos los archivos únicos englobando todos los PAK. El motor lista por orden alfabético los PAK encontrados y genera la lista siempre con las ultimas coincidencias localizadas entre los diferentes PAKs y restos de archivos únicos. Esto quiere decir que si tenemos un pak0.pak con un archivo y ruta "GFX\Fondo.bmp" y un pak1.pak con el mismo archivo y ruta "GFX\Fondo.bmp" el archivo del pak1.pak será el que se guarde en la lista de recursos que genera el motor. Este mecanismo esta basado en el de motores como el del Quake, Half-Life, JediKnight, etc...

Jueves, 15 de Abril de 2004
---------------------------
Se añade el MS Script Control al motor pero sin funcionalidad alguna, solo se añade en el arranque del motor. Se añaden nuevos pasos al sistema de arranque.

Miércoles, 5 de Mayo de 2004
----------------------------
Se crea la ventana que hará de interfaz para el motor. Se añade inicialización del modo de video a pantalla completa a una resolución estándar de 640x480x16.

Lunes, 10 de Mayo de 2004
-------------------------
Se añaden las primeras funciones al script, funciones de texto. Comienzan las primeras pruebas del script del motor con código compilado dentro del motor. Al iniciarse el motor aparece la ventana en pantalla completa a 640x480x16 mostrando una frase y un contador de cuadros por segundo (FPS) en la parte superior.

Jueves, 20 de Mayo de 2004
--------------------------
Se comienza a programar el sistema de carga del juego. Se trata que después de inicializar el motor buscara en la lista de recursos un archivo que es una lista de carga donde figura el script y recursos que se cargaran al terminar la inicialización del motor. Ahora el código script que ejecutara el motor se cargara desde los PAKs. La extensión para los archivo script o subprogramas será *.ex3.

Lunes, 14 de Junio de 2004
--------------------------
El sistema de carga de recursos aun esta sin definir. La idea ha sido estudiar la forma más sencilla para poder tener los datos que definan los escenarios y demás parámetros del juego y la lista de recursos que necesiten en un mismo archivo. Se ha creado un formato especifico para el TLSA Engine pero que permite personalizar una parte de el, el buffer de datos.

El archivo estará compuesto por una cabecera que definirá el formato para que el motor lo reconozca y que también contendrá valores como la versión del formato, numero de recursos a cargar, tamaño del buffer de datos y su posición de lectura dentro del archivo. Luego vendrá una lista donde aparecerán las rutas de los recursos a cargar con un valor que identificara si se trata de un grafico, sonido, video, etc... y otro valor que definirá si el recurso debe mantenerse en memoria hasta que el programa finalice su ejecución o si debe ser descargado en la siguiente carga de recursos. El resto del archivo será el buffer de datos, que el motor tratara como un array de datos Byte para ser más flexible y evitar la perdida de información de los datos (razón por la que no se trata los datos como Variant).

El buffer de datos será la parte que el programador definirá a su gusto cuando programe el motor, organizando los datos a su antojo para que luego el script que se encargara de construir los escenarios y demás partes del juego sepa como interpretar ese array de datos Byte, por ejemplo guardando datos de 3 registros que definan un grafico y su posición, una  variable, etc... Las funciones para lectura del buffer serán para lectura de cadenas de texto y de valores numéricos, a las que se les pasara un parámetro de posición de lectura y posiblemente un parámetro que defina la longitud de lectura. Esto ultimo se vera más adelante cuando el script y el formato del archivo estén más avanzados.

Martes, 17 de Agosto de 2004
----------------------------
El sistema de carga de recursos esta casi terminado, solo falta un detalle mínimo. Se ha añadido una consola de comandos  (estilo como la del Quake3) al motor para poder realizar operaciones de carga y algunas funciones más. Esto nos servirá para seguir los procesos del motor sin tener que esperar a que se genere el log al finalizar la ejecución del programa. Desde el script se podrá enviar mensajes a la consola. Posiblemente también se puedan añadir comandos a la consola desde un script. De momento el motor al cargar un archivo de recursos, después de cargar los gráficos y demás recursos, cargara el script motor que moverá el nivel (script principal). En este script se definirán las funciones para generar y "motorizar" el nivel del juego y también se podrán definirán las variables globales, para que así al añadir scripts secundarios estos puedan interactuar con el principal (ADDONS, Plugins, Mods, ...). Poco a poco iré añadiendo funciones al script (graficas, de sonido, de video, etc...). Después de esto se estudiara como implementar el sistema de entidades.

Miércoles, 08 de Septiembre de 2004
-----------------------------------
Se han corregido unos cuantos bugs del motor y se han añadido nuevas características como son la de generar un log en disco en tiempo de ejecución evitando así perder la información del log al no generarse por algún fallo grave de ejecución del programa.

La consola de comandos ya esta terminada y totalmente operativa.

Se ha habilitado la línea de parámetros en la llamada del programa pudiendo así configurar algunas características del motor como el modo de video, presentación (ventana o pantalla completa) y algunas características mas.

También se han realizado algunas modificaciones respecto algunas características implementadas inicialmente como por ejemplo ahora cualquier recurso (grafico, sonido, script, ...) que se cargue en memoria será descargado de la misma al cargar un archivo de recursos, ya no habrá opción para mantenerlo en memoria hasta el final de la ejecución del motor.

Ahora el ejecutable del motor es un programa independiente, no precisa de tener instalado las DLLs que necesita para poder ejecutarse (Runtimes del VB, dx_lib32 y MS Script Control). Estas DLLs ahora van integradas en el propio código del ejecutable haciendo mas fácil su portabilidad a otros equipos sin necesidad de instalar nada excepto MS DirectX.

Jueves, 09 de Septiembre de 2004
--------------------------------
La ventana ya adapta su tamaño al de la resolución utilizada por la clase grafica de dx_lib32 en modos que no sean pantalla completa.

Friday, 01 October 2004
--------------------------
Se ha modificado el tipo dato utilizado para tratar el contenido del archivo de recursos. Antes se interpretaba como un array de tipo Byte, pero como he tenido problemas a la hora de interpretar ciertos datos como los numéricos WORD, DWORD (Integer, Long en Visual Basic) he decidido interpretar el contenido del archivo como un array de tipo Variant (Los tipos Variant son un tipo de dato de 16 bytes que puede contener información de cualquier otro tipo de dato), esto quiere decir que cada elemento del array es un valor total: una cadena de texto, un numero... Esto supondrá algo de velocidad a la hora de trabajar los datos con el script, dado que Visual Basic Script solo trabaja con Variants, ya que no habrá que realizar conversiones pero se perderá un mínimo de optimización en cuanto a memoria se refiere dado que cada elemento del array ocupara 16 bytes sin importar lo que contenga mientras que el array de tipo Byte ocupara tantos bytes como elementos contenga. El buffer de intercambio entre scripts también será de tipo Variant. Esta modificación esta implementada de tal forma que en futuras versiones se podría cambiar de nuevo el tipo de dato a Byte y trabajar sin problemas cambiando solo un modulo de código. De momento se trabajara con datos Variant.

Se han implementado las funciones de lectura de entrada del teclado en el script.

Se ha implementado la primera función grafica del script. Es un simple enlace a la función MAP_DRAW() de dx_GFX, esto quiere decir que no usa la lista de renderizado del motor. Esta función solo esta implementada para realizar pruebas con el motor.

Próximos objetivos

> Crear el sistema de renderizado del motor y las funciones graficas para el script.
> Crear el sistema de entidades.
> Añadir mas funciones al script.

FIN DE IMPRESIÓN