26/04/2001

- Sigo trabajando en lo que es el boceto general de la implementación en base al documento v:0.3 de Crisol. Para que os hagáis una idea, os cuento mejor lo que me queda por esbozar:

* Algoritmo de selección de objetos.
* Definir la estructura de los archivos de datos más claramente.
* Concretar el flujo de ejecución de Crisol en la clase principal.
* Definir la implementación del subsistema de interfaz.
* Concretar aspectos del módulo CWorl, encargado de coordinar todo el universo de juego.
* Concretar CrisolBuilder (no muy dificil una vez que se definan los archivos).
* Concretar CrisolScript.

La concreción de CrisolScript será la parte más complicada, pues necesitaré definir el lenguaje, tener claros los eventos de juego y las funciones de API. Al contrario que en el resto de los módulos, en este apartado sí que será necesario tener por escrito todo a un nivel profundo de detalle, ya que buena parte del alma del motor residirá ahí. En los otros módulos, tener la idea general de las estructuras de datos, lógica y clases que van a intervenir, me basta.

En la actualidad ya tengo implementados los subsistemas pilares del engine, esto es, módulos encargados de lidiar con el subsistema de ficheros, recursos, entrada, manejador de memoria, subsistema de alarmas, subsistema gráfico y de fuentes, logger, temporizador, bucle basado en tiempos fijos, wrapper DirectX y el propio motor isométrico. Si bien, muchos de ellos van a tener que ser modificados de forma más o menos importante. Esto se debe al fallo que cometí (y que comenté en otra actualización). Estoy seguro de haber tirado por ello bastante más de un mes de trabajo duro.

- La novedad principal de esta actualización radica en que finalmente existirá, con toda probabilidad, la representación del día y de la noche en el motor desde el punto de vista gráfico. No había plasmado este detalle en el documento porque era algo de lo que no estaba muy seguro, de cara a su implementación y tiempo requerido. En dos tardes he conseguido una primera aproximación teórica sobre la implementación de este sistema de iluminación que, aunque será bastante simple, creo que podrá dar bastante bien el "pego" a la hora de trasmitir la idea de que se está jugando de noche, de que estamos en una cueva y llevamos una antorcha, etc. Repito que tengo teoría escrita en papel y que es un sistema básico, por lo que si no me convence una vez que esté implementado no lo incluiré. De todas formas, tengo la seguridad de haber ideado algo que servirá.

Básicamente, lo que haré será jugar con los componentes RGB de cada vértice. Esta ventaja de trabajar con Direct3D me permitirá dibujar los objetos más o menos oscuros, con lo que tendremos el efecto deseado. Llevar una luz o situar una luz sobre una celda del mapa, significará que el posible factor de oscuridad que haya en el "ambiente" no afectará a los objetos que se encuentren sobre la celda. Esto a grandes rasgos, por supuesto. Según pasen los días antes de ponerme a codificar de verdad, supongo que iré madurando la idea que ahora tengo plasmada en 2 o 3 hojas.

- Otra de la novedad importante, es que he incorporado un foro a la página. De esta forma, podrá existir una comunicación más fluida entre vosotros y yo, de cara a aclarar conceptos, aportar sugerencias, etc. No espero que el foro sera un punto bullicioso, porque esta misma página está lejos de querer aspirar a algo así, pero sí confío en que pueda crearse un lugar interesante para todos. Me he reservado el nick Crisol para escribir en el foro, de esta forma podréis localizar fácilmente qué mensajes son los emitidos por mi.

- Aprovecho también para responder a la pregunta de "¿cuándo estará Crisol disponible?", que ya me la habéis formulado algunos, debido a que estáis interesados en utilizarlo. Bien, Crisol es mi proyecto fin de carrera en la Ingeniería Técnica de Informática de Sistemas que curso en la universidad de Oviedo (para más señas, mi director de proyecto es José Manuel Cueva Lovelle). El que sea mi proyecto fin de carrera sólo significa una cosa: Crisol no será "varporware", es decir, será concluido. "¿Tendrá todo lo que hay en el documento de diseño?". No lo sé (aunque ese es mi objetivo), pero será concluido. Lo ideal sería tenerlo concluido en septiembre del 2001 y como muy tarde diciembre del 2001. Por esas fechas, sobre todo por la primera, trabajaré. Espero que esto pueda daros una idea de mis planes. Naturalmente, espero sacar demos para que el motor se vaya probando.

- Para terminar la actualización de hoy, comunicaros que estaré fuera de mi ciudad cinco días. Durante ese tiempo no podré trabajar en Crisol ni actualizar la página, asi que disculpar por los retrasos.

20/04/2001

- Ya he terminado la parte fundamental del documento de diseño. En esta versión se recogen todos los puntos que se deberán de tener en cuenta para poder implementar Crisol. No he entrado a desarrollar los apartados destinados a CrisolBuilder y CrisolScript pues aún necesito tener más asentados ciertos conceptos. De todas formas, entiendo que dichos apartados forman parte del desarrollo propiamente dicho. No dejan de ser más que herramientas de soporte, así que el documento es suficientemente válido con lo que hay ahora, pues cumple con los objetivos para los que está pensado: definir qué es Crisol.

Podéis encontrar el documento en la sección de descargas. Esta vez ocupa mucho menos que antes pues he separado las figuras del archivo word y las he puesto en un fichero html. Bueno, pasaros, son 44 hojas muy trabajadas. Si hay algún valiente que sea capaz de leerse el documento, o alguna parte del mismo, y quiera comentarle qué le parece, estaría encantado de atenderle.

- En la sección de descripción he modificado el punto en donde enumero las características de Crisol para ajustarlos a la realidad del documento actual. Principalmente, se han suprimido los elementos relativos al sistema de automapa o comercio. También el punto en donde se cita el uso de herramientas visuales ya que es seguro que para esta versión no existirán herramientas visuales (mal que nos pese a todos).

13/04/2001

- Ya he terminado de definir el esquema global del motor. Ahora mismo tengo todos los apartados que debo de considerar a desarrollar, salvo el de eventos (para lo cual necesito tener todo absolutamente claro) y ciertos elementos de CrisolScript. Principalmente los relativos a la forma en que se conectarán los eventos con las entidades correctas del juego. También necesito trabajar más en la definición de la estética asociada al interfaz, ya que la lógica interna la tengo perfilada ya (es decir, sé perfectamente qué es lo que va a figurar en la interfaz, pero lo que aún no he terminado de consolidar es el aspecto que ésta tendrá en pantalla).

- La parte en que más he estado trabajando ha sido la relativa a la forma en que el diseñador podrá definir el contenido del juego. Para ello, he diseñado un nuevo lenguaje, CrisolBuilder, completamente independiente de CrisolScript. Este lenguaje será únicamente sentencial, no habrá bucles ni nada por el estilo (ni funciones tampoco, sólo trabajo con variables y órdenes) de tal forma que su uso será ridiculamente sencillo. Un ejemplo de la sintáxis de CrisolBuilder sería el siguiente (corresponde a la definición de items, que luego se usarían para crear instancias):

.ItemDefs
.ItemAnimTemplates
ItemAnimTemplate_0;
AnimState = "estado_0";
Frames = "frame0.tga";
.ItemDefs
ItemDef_0;
Name = "Excalibur";
Type = SWORD;
Class = TWO_HANDED_SWORD;
AnimTemplate = ItemAnimTemplate_0;

En este ejemplo hemos definido una plantilla de animación llamada ItemAnimTemplate_0 (que tendrá un sólo frame y un sólo estado de animación) y después una definición de Item denominada ItemDef_0. Esta definición tiene asociada un nombre, tipo, clase y plantilla de animación (que, como se puede observar, es la que se difinió antes). De esta forma, desde CrisolScript o desde otras partes de CrisolBuilder, se podrán crear instancias a este tipo de item con sólo indicar ItemDef_0.
Como se puede observar, pese a que CrisolScript y CrisolBuilder tengan asociadas tareas distintas, compartiran información. Cosa ésta muy importante y potente para poder crear universos flexibles.

- El principal motivo de la definición de CrisolBuilder es el relativo a que Crisol, al menos en principio, no va a contar con un set de herramientas visuales. Este hecho hace que toda la definición de datos asociados a un área del universo de juego, a la interfaz o al propio jugador, deberán de establecerse "a pelo" por el diseñador. He planteado CrisolBuilder de tal forma que ahorre, en todo lo posible, tiempo y líneas al diseñador (aún así, lo ideal sería contar con unas herramientas visuales, pero creo que será imposible para la primera versión operativa de Crisol). Si en un futuro se desarrollaran herramientas visuales, CrisolBuilder seguiría siendo válido ya que lo único que harían éstas sería construir los ficheros fuentes de CrisolBuilder.

El desarrollo de este sencillo lenguaje de definición de contenido, me ha venido muy bien para poder pensar y establecer mejor las capacidades de Crisol. La siguiente versión beta del motor, debería de tener este lenguaje ya implementado, pudiendose mostrar contenido definido con él.

- Ahora mismo tengo un buen taco de hojas con anotaciones "a mano". Necesitaré dos o tres días para pasar todo a formato word y darle luego un visto bueno general, así que ese es el motivo de que no haya podido subir aún un nuevo documento word. Mi filosofía es no tocar nada de código hasta que esté completamente seguro de lo que estoy haciendo y de que lo que estoy haciendo es eficiente. Si bien, reconozco que he cometido algunos fallos de principiante a la hora de abordar el diseño de Crisol, pues he implementado partes que deberán de ser modificadas.

- Para los amantes de los juegos de Rol por ordenador (supongo que todos los que estéis leyendo estas líneas), os comunico que ha salido un nuevo trailer, bastante espectacular, de Arcanum. El juego de rol que el equipo de Tim Cain (productor de FallOut) está llevando a cabo. Tiene una pinta soberbia y el universo sobre el que se va a desarrollar la acción, fascinante.

- Aprovecho para comunicaros que a día de hoy, Macedonia Magazine ha salido otra vez adelante. Esta publicación es una referencia casi obligada para todo desarrollador hispano y ya tiene unos cuantos añitos a sus espaldas (desde finales de 1997). No dudéis en pasaros y participar con algún artículo de vuestra cosecha. A mi me veréis a menudo por la revista con algún artículo (eso, si esta criatura de deja algo de tiempo libre :).