4/1/2002

---

- Bueno, ya estamos en el 2002, como pasa el tiempo. Antes de nada, quiero agradecer a Manuel Moreno "Dracke" y a su amigo webmaster "Doom" que pudieron subir la beta cuando yo estuve ausente. El problema se debio a que el servidor no permite alojar archivos de más de 5 megas y ahora tenemos la beta en otro servidor no gratuito. Pronto se publicará una nueva edicion de la beta, que también estará en inglés y que posiblemente se haga usando el método de fragmentar el archivo para que podamos subir a este sitio web la misma sin problemas.

- También quiero agradecer a PHRoDo todo el interés y ayuda mostrada, tanto en el foro como personalmente. Gracias a él he logrado cazar un error bastante importante y que en la beta que actualmente está colgada existe. El caso es que la gente que no disponga de Windows 9x van a ver los textos en negro con toda seguridad.Esto ya está solucionado y estará solventado en la próxima actualización de esta beta.

- Ahora, pese a que aún quedan temas por implementar en el API del motor, además de depurar, ya estoy centrado en la creación del lenguaje script. En líneas generales tengo claro como va a ser pero me asaltan dudas a la hora de encarar la forma en la que este va a ser ejecutado. Estas dudas ya las he consultado con amigos programadores, pero si hay alguien leyendo esto que quiera colaborar dándome su opinión, yo estaré encantado de escucharle.
La idea que tengo para el lenguaje es que no sea interpretado a través de un intérprete puro, es decir, a través de uno que lea una instrucción y la ejecute directamente, tal cual está escrito el código en el lenguaje fuente, ya que la tasa de frames descendería (en teoría) peligrosamente si los script son medianamente largos o hay muchos de caracter idle (aquellos que se ejecutan automáticamente cada x tiempo). Esto me obliga a crear un lenguaje muy sencillo pero que sea interpretado usando un código intermedio, que hará que todo vaya (también en teoría) más rápido. Así, la idea de arquitectura sería:

• Se escriben scripts.
• Se compilan a código intermedio (y de paso, se realiza el análisis sintáctico y semántico, con lo que a la hora de ejecutarse tendré la seguridad de que no habrán fallos o incoherencias, cosa que no ocurre si es un interpretado puro pues se "comen" instrucciones sin haber realizado ningún tipo de chequeo previo)
• Se ejecutan cuando ocurra el evento al que estan asociados (Por ejemplo, el jugador pisa un tile, el motor comprueba si se ha asociado un archivo script al tile que se ha pisado en el evento de pisar tile. Si es así, se ejecutará el script pasando los parámetros adecuados).

El problema viene cuando quiero trabajar con variables de caracter global (muy importante en un juego, pues pensad que se usan masivamente flags globales para saber si ha sucedido tal o cual cosa en la trama principal) o para usar funciones también globales (muy importante pues hace que no se tenga que escribir una y otra vez la misma funcion en cada uno de los archivos con código script y, aunque podáis pensar en un simple copy - paste, hacer esto incrementa el tamaño de los archivos y, por consiguiente, disminuiría los recursos disponibles, además de que es la cosa menos elegante del mundo :) ya que los scripts van a ser muy independientes, es decir, el evento que puede tener asociado un script sólo necesitará un archivo con el código script. Por ejemplo, pensad en el código script como en un programa hecho en Pascal (para los que sepáis Pascal o Delphi) pero considerablemente más sencillo. Este podría ser el fichero Script_EspadaCogida.txt:

Script OnItemGet(ParametrosScript)
Const
// Constantes locales a TODO el script
Var
// Variables locales a TODO el script

function NombreFuncion(ParametrosFuncion)
Const
// Constantes locales a la funcion
Var
// Variables locales a la funcio
begin
// Funcion de apoyo local
end

begin
// Codigo del script, desde aqui se podra llamar a la funcion Prueba y este sera
// el codigo que comenzara a ejecutarse cuando se produzca la ejecucion del script
end

Si recordáis o conocéis Pascal y/o Delphi, en lugar de Program pongo Script y en lugar del nombre del programa, pongo un tipo OnItemGet que sirve para identificar el tipo de evento al que está asociado; cada evento tendrá un conjunto de parámetros obligatorios (si es que tiene) y esta palabra reservada me servirá para obligar a que se pongan y para comprobar que el script asociado a un evento es el correcto.
¿Qué ocurre ahora? pues bien, que si queremos usar variables globales no podremos declararlas en el mismo archivo con algo del estilo a:

Var
global string x;

Ya que cada vez que ocurra el evento dicha variable global se volvería a declarar. Peor aún, si se declara una variable global en un archivo script y dicho archivo script aún no se ha ejecutado, ¿cómo van a saber los otros archivos scripts que dicha vble global existe? aún más ¿cómo lo vamos a saber cuando toque compilar?. Esto mismo es extensible a las funciones globales (que pueden llamarse desde cualquier script).

Lo que había pensado era que las compilaciones de los scripts fueran a bloque, es decir, cuando llegara la hora de compilar que se compilaran todos y cada uno de los scripts definidos, de tal forma que usando un archivo de definiciones del tipo (imaginarios el archivo Scripts.txt):

Global
Const
// Constantes globales
Var
// Variables gloables

// Funciones globales
function f()
begin
end

// Scripts
Scripts
"Script_EspadaCogida.txt"

¿Con esto qué logro? pues se supone que lograría crear un espacio global donde meter las constates, variables y funciones globales. Una vez hecho esto, comenzaríaa a visitar cada uno de los archivos scripts definidos despues de Scripts pudiéndolos compilar con la seguridad de que la tabla de símbolos para las variables globales y funciones globales ya estaría creada y, por lo tanto, no podría existir ningín tipo de problema, sin incrementar, al menos eso creo yo, mucho la complejidad de implementarlo.

Con este sistema, si quiero compilar, me bastaría hacer algo del estilo a:

Compilador Scripts.txt
Obteniendo el código intermedio que yo necesito para que el intérprete embebido en el motor lo ejecute.

El único pero que veo por ahora, es que este sistema es que es muy lento en tiempo de compilación. Imaginaros que tengo 10 o 15 scripts y modifico una línea en el script número 6. Tendría que volver a compilar todo. O bien que quito una variable global, pues lo mismo, tengo que volver a compilar todo. Supongo que se podrá crear algún tipo de optimización para esto, es decir, que en el archivo con todos los scripts compilados a codigo intermedio, se incluyan pistas para cada archivo que nos sirva para saber si es realmente necesario o no recompilarlo después de un cambio pero... con el poco tiempo que tengo dudo mucho que me meta a eso, así que de usar este sistema lo dejaria así, teniendo que recompilar todo. Lo que está claro es que Crisolscript va a ser mi primer lenguaje script y que va a ser mucho más sencillo y simple que un Pascal o un Basic y los scripts que pueda usar la gente que quiera hacer algo con crisol no serán muy grandes, por lo que no creo que existan lapsos importantes de tiempo. Pero nunca se sabe y siempre es bueno tener estas cosas en cuenta.

Los programadores que hayan leido esto y quieran opinar pues estaré encantado de leerles en el foro (y digo en el foro, porque así se generara un debate más abierto a participaciones nuevas).

- Con esto finalizo la actualización, espero que podamos subir en breve la nueva versión de la beta con los gráficos que no llegaron a tiempo, además de la correspondiente versión en inglés y el error cazado por PHRoDo en la escritura de texto. También, la gente que ya la haya podido ver, si ha encontrado algún problema o quiera comentar los FPS que arroja o sus impresiones generales, pues estaría encantado de leerles en el foro. La siguiente actualización la anunciaré en stratos y sitios similares para que haya un chequeo más considerable.