28/11/2001

- No esperaba que fuera a actualizar tan rápido, pero todo ha ido estupendamente bien desde la última ocasión, así que os cuento qué novedades hay en el motor. Fundamentalmente, son dos los añadidos que se han realizado al mismo. Ambos son añadidos básicos, esto es, estaban previstos desde siempre en el sistema, aunque uno de ellos, el primero que voy a comentar, no lo estuviera con tantos añadidos como al final ha sido construido.

- En primer lugar, os diré que está implementada la interfaz gestora de la creación de presentaciones en el motor. Una presentación es una especie de secuencia de pantallas que sirven para mostrar algún tipo de información de manera más o menos narrada. Algo así como las presentaciones que se pueden hacer con un powerpoint, por ejemplo. Toda presentación será definida usando un archivo de texto especial. Cuando queramos cargar una presentación y mostrarla al usuario, podremos hacerlo si estamos en el área principal de juego o bien en el inventario del jugador. Cada presentación se compone de un número particular de "slides" (diapositivas). Cada slide puede constar de una imagen de fondo estática, animaciones asociadas a determinadas posiciones para esa imagen estática, un sonido WAV cíclico, un sonido WAV linear, música MIDI, texto (que se podrá poner directamente o bien mandando que se lea desde un archivo) y un efecto FadeOut y FadeIn personal (en el FadeIn se puede especificar la velocidad a la que sucederá y en el FadeOut, tanto el color como la velocidad). Los Fades, al igual que los anteriores elementos comentados, serán opcionales para un determinado slide.

Otra de las posibilidades que implementarán las presentaciones, es que se podrá indicar que el pase de slides sea automático, asignando un tiempo máximo en el que éstas serán vistas en pantalla. También se podrán pasar manualmente (mediante la pulsación del botón izquierdo del ratón) e incluso se podrá, o no, habilitar la tecla ESC para que el usuario pueda interrumpirla. Otras particularidades, es que a la hora de cambiar de diapositiva, se podrá mantener la imagen de la anterior y sus animaciones, se podrá pasar de sin realizar Fades, seguir con el mismo sonido MIDI o WAV cíclico, etc.
El sistema de presentación, pretende suplir la no inclusión en el motor de un reproductor de vídeos, ya que no es algo que yo contemplara en el diseño del mismo (y ahora no quiero perder tiempo yendo a ese elemento "extra", máxime, cuando no tengo aún terminado el motor). El sistema de presentación comentado, puede generar secuencias muy interesantes si se sabe usar bien. También servirá para cuando en el motor se quiera mostrar una imagen aislada (imaginemos que el jugador posee un mapa y que cuando desde el inventario se selecciona observar mapa, queremos que se muestre una imagen del mismo) con la ventaja de que, además, podrá tener sonido, texto asociado, música particularizada, animación en determinadas zonas, etc.

El sistema de presentación se utilizará para mostrar los créditos del motor, así que el diseñador deberá de construir al menos uno. Cuando se publique la beta incluiré una presentación para mostrar los créditos y así os haréis una idea de lo que se puede hacer.

- La otra novedad, ya visual, es la referida al sistema de iluminación. Hoy he empleado el día entero a trabajar en su reescritura. Si recordáis, en las primeras pruebas tecnológicas de Crisol ya os comenté que tenía la intención de usar un sistema noche - día e incluso programé un sistema de iluminación para una de las primeras betas. Bueno, ese sistema de iluminación no era muy decente y lo tuve que desechar casi en el mismo momento en que me puse a programar en serio el motor. Hoy acabo de implementar el nuevo modelo. Consume FPS que da gusto :) pero es realmente interesante las cosas que se pueden hacer con él. Dejaré para el futuro la optimización porque sería una tontería y una pérdida de tiempo ponerme ahora a mejorar los FPS del motor. Eso siempre tiene que ir al final.
Os muestro unas capturas del sistema de iluminación. Como siempre, pulsar para agrandar.


Nuevo sistema de iluminación dinámica.

En la primera captura (la primera por la izquierda), podéis ver al jugador y a la espada de fuego con la que hemos venido trabajando. En ella, he asignado una luz ténue a la espada de fuego, para que veáis que se resalta. En la siguiente, además de la espada de fuego, el jugador pasa ahora a tener una luz asociada de intensidad máxima y en la última he movido al jugador, he quitado a la espada de fuego y estoy interactuando con una columna. Como véis, el efecto es realmente interesante (y necesario) para el motor. En todas las capturas, la hora de juego son las 5:43 de la madrugada.

La filosofía general de este nuevo sistema de iluminación es el siguiente; toda entidad del universo de juego puede tener asociada una luz. Una entidad puede ser una criatura, un item, un objeto de escenario, una pared o un tile. En el caso de los items, el funcionamiento luminoso de los mismos tiene algunas particularidades. Si un item tiene una luz asociada y hay una criatura que transporta dicho item, la luz del item se mostrara SOLO si la criatura tiene equipado el mismo. Esto me ha hecho modificar la definición que tenía y que decía que todo ítem equipable en un slot principal (mano) era un arma ofensiva o defensiva. La nueva definición sería que todo ítem equipable en un slot principal, será un arma ofensiva si tiene asociado puntos de uso para golpear en modo combate (ya se que es difícil de entender en una simple actualización, pero bueno, yo lo comento).

Otra cosa importante sobre la luz es que podrá variar en intensidad entre 1 y 255 (una intensidad de 0 supondrá que no hay luz). A más intensidad, más capacidad de abarque tendrá. La intensidad estará íntimamente relacionada con dos factores: la distancia hasta la que llega la luz y la claridad de la misma. Una luz de 255 llega muy lejos y hace que se vean perfectamente todos los objetos. La luz es dinámica en cuanto a que un cambio en la posición de una fuente luminosa, hace que varíe por completo la iluminación de la escena.

- Y con esta actualización, os comento que el siguiente objetivo será el trabajo con los techos de los tiles que tengan, pues eso, techo :). La idea es que aquellos tiles que posean otro en calidad de techo, desaparezcan si el jugador se coloca debajo. No va a ser sencillo realizar el planteamento. Y otro de los aspectos que tengo apuntado, será el trabajo con los ítems que pueden estar asociados a una pared (una antorcha puesta en una pared, una ventana puesta en una pared, etc) que está previsto pero no programado y convenientemente documentado. Espero que todo siga como hasta ahora de fluido, ya que el motor cada vez esta más cerca de poder pasar al trabajo con script (aunque no estén todos los flecos hechos, el API principal estará ya lo suficientente acabado para dar el salto).

25/11/2001

- ¡Al fin actualizo!. Pido disculpas por todo el inmenso tiempo que ha pasado desde la última vez que lo hice, pero he estado muy centrado en el avance del motor. Las mejoras que he implementado son tanto visuales como internas, pero intentaré ir paso a paso para comentarlas. Espero no dejarme muchas en el tintero. También aprovecho, antes de nada, para agradecer a todas las personas que están ayudando de forma directa o indirecta en la creación del motor, pues juegan un papel muy importante para que el avance en el mismo no resulte un pequeño infierno. El monstruito ya es considerablemente grande (más de 300 archivos .cpp y .h) y uno corre el riesgo de desbordarse un poco ahora, que ya está cada vez más cerca la finalización, pero también los bugs aparecen por generación expontánea y al arreglarlos, hacen acto de presencia nuevos y... :)

- El sistema gestor de combate ya ha sido implementado, a falta de lo que suponga introducir el trabajo desde script. El modelo utilizado se basa en que las entidades que quieran comenzar un combate deberán de alinearse en uno de los dos posibles "bandos" existentes: el del jugador y el de los enemigos del jugador. El jugador siempre estará alineado (cuando se halle activo) en el bando suyo propio (en el del jugador) mientras que el resto de criaturas que entren en combate, podrán elegir. Crisol comprueba, en cada ciclo de IA, si existe alguna criatura viva en el bando del jugador y en el de enemigos del jugador. Si esto fuera así, inicializará el modo de combate automáticamente. También será capaz de finalizarlo automáticamente si, estando activo, detecta que no hay, de forma simultánea, al menos una criatua en el bando del jugador y de enemigos del jugador viva.

Todo lo referente al trabajo con los puntos de acción por criatura y turnos de combate está implementado. Cuando a una criatura le llegue el turno, aparecerá una barra horizontal (de las que ya habéis podido observar en alguna captura del motor) con el nombre y puntos de acción actuales y totales de la criatura. Al mismo tiempo, cada criatura tendrá un selector de combate. El selector será una especie de circulo, rombo o señal que irá por debajo de esta para indicar al bando al que pertenece. Cuando la criatura esté en el turno de combate, dicho selector sufrira un efecto de fade para ayudar a que el jugador distinga rápidamente la criatura con el turno actual.
En la siguiente captura, podéis ver un ejemplo simulado (recordar que al no estar implementado el sistema script, que es lo que dará inteligencia al motor, no puedo hacer otra cosa más que simular situaciones programándolas en código) de combate. Pulsar en la imagen para agrandar:

Modo combate activo.
Derfel tiene el turno.

Si os fijáis en la captura, veréis una serie de detalles interesantes. En la parte superior izquierda, aparece la barra que os comenté. El motor permite que podáis situar esa barra donde queráis dentro de la pantalla, así como definir el color de las letras e incluso el grosor y longitud de la barra de porcentaje. Por otro lado, veréis que las dos criaturas que estan en combate (lo siento, andamos escasos de gráficos y no queda más remedio que usar clones :), tienen un selector inferior de distinto color (mirad el rombo que está bajo sus pies). Tambíen podéis comprobar que en la barra de interfaz aparecen dos nuevos botones, que son "Sig". y "Huir". Los dos funcionan nada más cuando el jugador posee el turno (como es el caso) y sirven para pasar al siguiente turno (aunque no se hayan gastado todos los puntos) y para huir si eso es posible. La huida será posible cuando el jugador esté, de la criatura enemiga más cercana, a una distancia que se especificará en el archivo de reglas. En tales casos, el motor validará la huida vaciando los bandos de combatientes.

El sistema gestor de combate también posee implementado todos los mecanismos para que el jugador contabilice los puntos de acción ante determinados eventos como andar, manipular, observar, usar ítems de inventario, etc.
También está implementado el sistema mediante el que una acción que necesite, desde el punto de vista lógico, que el jugador se halle sobre un tile (por ejemplo, recoger un ítem) o sobre otro que sea adyacente a este último (por ejemplo, manipular un objeto de escenario) acerque antes al jugador. Naturalmente, esto también se reflejara en combate, decrementándose los puntos de acción. Los costes serán totalmente definibles en el archivo de reglas.

- Otro sistema muy relacionado con el del combate, es el sistema de ataque o golpeo, que también se encuentra implementado. Existirán dos tipos de armas: las ofensivas o las defensivas, pero sólo con las ofensivas una criatura podrá atacar o golpear. Crisol entenderá que todo objeto que se pueda equipar en un slot de equipamiento principal (mano derecha o izquierda), será un arma. En caso de que el jugador no tenga equipada ningún arma, aparecerán sus manos, cosa ésta que se representará con un gráfico por defecto que el diseñador deberá de establecer. Para atacar, será necesario que un arma ofensiva, o en su defecto una de las manos, esté seleccionada. Cuando esto ocurra, en el caso de pasar a modo de interacción encontraremos una diferencia fundamental cuando posemos el cursor sobre una entidad. Mientras que en el modo de interacción sin arma seleccionada aparecía el nombre de la entidad seleccionada y al pulsar el botón izquierdo las acciones que podíamos realizar sobre la misma, ahora aparecerá, si la entidad es una criatura, datos relevantes sobre la misma y si es otra entidad distinta de un ítem (ya que los ítems no se podrán seleccionar en el modo de ataque), su nombre (al igual que en el modo de interacción). El cambio fundamental vendrá cuando apretemos al botón izquierdo, ya que no aparecerán las acciones que podemos realizar sobre la misma, sino que se generará un evento de golpeo. Fijaros que no se pasará al modo de combate, sino que se generará un evento de tal forma que el diseñador deberá de programar si la entidad que recibe el golpe (en el caso de que sea una criatura) se alinea en contra del jugador (que es quien le ha golpeado) o no.

De la última línea anterior, podréis deducir que el modo de ataque o golpeo podrá estar activo tanto en modo combate como en modo fuera de combate. En la captura siguiente, os muestro una serie de detalles interesantes, pulsar para agrandar como siempre:

Hay un arma seleccionada y se está
eligiendo un NPC como objetivo.

En primer lugar, veréis que el jugador tiene equipada una espada en la mano derecha. Dicha espada se llama "Espada de Fuego" y así aparece sobre el slot de equipamiento. Está selecionada porque podéis ver que el color de fondo del slot es rojo (cosa totalmente modificable, tanto en color como en valor alpha, por el diseñador). El siguiente aspecto, y el que más salta a la vista, es que estamos señalando a un NPC en modo interacción y que, como tenemos un arma seleccionada, aparece toda la información que nos pueda ser útil sobre el mismo: Nombre, Salud, Nivel y el Tipo y Clase del mismo.

- Estos dos sistemeas comentados, son los que más tiempo me han llevado de implementar. Sobre todo el gestor de combate, ya que en él había una importante sincronización en lo referido a la consumición de puntos de acción. Pero hay más añadidos nuevos. Ahora ya es posible asociar un sonido por tipo distinto de tile, de tal forma que si el jugador o un NPC cualquiera anda sobre hierba, emitirá un sonido distinto a si lo hace sobre marmol. En cualquier caso, siempre será algo opcional añadir este tipo de sonidos por tipo de tile. Esta novedad no os la puedo mostrar con una captura, pero os aseguro que es realmente diferente el efecto de oir al personaje andar por tipos distintos de terreno y que se oigan tambien los pasos de forma diferente.

- El sistema horario también sufre añadidos importantes. Ahora será posible saber la situación horaria en la que se se halla el juego. Si os fijáis en la captura anterior, veréis una especie de rectángulo transparente con la palabra "RESTO". Os lo muestro a continuación ampliado:


Gestor de horas sin seleccionar y seleccionado.

La palabra "RESTO" realmente no tiene nada que ver con lo que significa este gesto. El gestor tendrá asociado una imagen para cada hora posible (en total, 24 imagenes) de tal forma que cuando el motor se halle en una hora determinada, se establecerá la imagen relacionada con dicha hora. Dicha imagen aparecerá dibujada con un valor de transparencia que el diseñador podrá determinar y sólo pasará a sólido cuando se establezca el cursor sobre el mismo. En caso de que se pulse el botón izquierdo, se mandará un evento de pulsación al script. ¿Cuál es el objetivo?. El objetivo será que desde script, el diseñador pueda lanzar, a su vez, un cuadro de diálogo en donde preguntar al usuario las horas que desea dormir o el tiempo de juego que desea adelantar. De esta forma, Crisol sigue sin imponer ningún tipo de reglas específicas para avanzar horas y deja todo en manos del diseñador. Por otro lado, dicho recuadro podrá desactivarse de juego pulsando una tecla, si su uso resultara molesto.

- También, referido al interfaz, el jugador podrá conocer de inmediato los síntomas que parezca el jugador (recordar que este sistema se basa en que el diseñador pueda establecer estados del tipo envenenado, encantado, maldito, etc, etc a una criatura). Cada síntoma podrá aparecer en una posición de pantalla y todos ellos tendrá un valor alpha a definir para que no molesten en pantalla. Al igual que con el gestor horario, se podrán desactivar para que no aparezcan en pantalla y activar cuando se quiera. En las capturas que os he ido mostrando, aparecían en la parte inferior izquierda de la pantalla. Os muestro una ampliación:

Síntomas activos en el jugador.

En este caso en concreto, se puede ver que el jugador poseería los síntomas 1, 2 y 4 activados (de un total de 16). Es importante tener en cuenta que los iconos asociados a los síntomas serán totalmente definibles por el jugador.

- ¿Y hay más cosas nuevas?. Pues sí, hay un par de cosas nuevas que merecen ser comentadas, pues son muy importantes. Por un lado tenemos el sistema de sombras, que ya está implementado. Toda entidad podrá tener asociada una sombra. Digo podrá porque no será algo obligatorio. Al asociar una sombra, ésta se dibujará siempre antes que la entidad y quedará reflejara en todas aquellas otras entidades que estén por debajo de la misma. Lo normal es que las sombras no sean más que la silueta de la entidad a la que representan en color negro y en diagonal. El motor además, incorpora una característica muy interesante para su manejo y es que permitirá asingar un valor alpha diferente dependiendo de la zona horaria (el diseñador deberá de establecer dicho valor alpha). De esta forma, cuando esté amaneciendo, la intensidad con la que se proyectará una sombra será menor que cuando sea mediodía. A continuación os muestro una ampliación de una sombra (mal hecha y mal puesta pues está realizada por mi :) asociada a un arbol y que cae sobre un baúl. Lo importante es que os fijéis el efecto que tiene la sombra sombre las entidades sobre las que se cae, ya que cambia por completo dependiendo de la posición donde se encuentren éstas últimas:


La forma en la que se refleja la sombra varía.

- El último añadido que queda por comentar, es el de la implementación del subsistema encargado de manejar los efectos especiales. Realmente, este subsistema ya ha sido introducido, pues es el encargado de mantener los alphas que tienen las sombras. Pero aquí os voy a comentar otras dos nuevas presencias del mismo. Por un lado, permite que las criaturas se puedan dibujar con transparencia, de tal forma que puedan parecer fantasmas o que están invisibles, etc. Y por otro lado, y más importante, ya se encarga de manejar los gráficos GFX. Los gráficos de GFX son unos gráficos que pueden asociarse a cualquier entidad y que tienen como objetivo simular algún tipo de efecto especial: explosiones, mágias, o cualquier otra cosa del estilo. Los GFX pueden tener un tiempo determinado para su finalización, de tal forma que pasado dicho tiempo, desparecerán. Una entidad podrá tener un número indeterminado de gráficos GFX asociados, siempre que sean distintos.
Todos los gráficos GFX se definen en un archivo destinado a tal efecto. Por cada perfil de gráfico GFX definido, podremos asociar una plantilla de animación (que sólo podrá tener un estado y orientación de animación, es decir, será cíclicas), la forma en que queremos que finalice (manual o bien por tiempo), el lugar de dibujado con respecto a la entidad (encima de la entidad, a la altura de la entidad, en la base de la entidad o por debajo de la entidad) y la posibilidad de asociar, para cada vértice del quad que forma el GFX, un valor Alpha y otro RGB, teniendo así la ventaja de producir efectos realmente dispares sobre un mismo gráfico.

Para que os hagáis una idea de a lo que me estoy refiriendo con este tipo de gráficos, os muestro un ejemplo en el que el jugador tiene activado un GFX a modo de borrador. Le he añadido valores RGB distintos por vertices así como Alphas. En esta captura no lo podéis ver, pero pasados 15 segundos, el GFX desaparece sólo. También, comentaros que en la captura, el GFX aparece dibujado a la altura del jugador.

Un ejemplo de GFX a modo de magia.

Como véis, la utilidad es más que evidente para dar realismo a los juegos que se desarrollen con el motor.

- Antes de acabar esta actualización, comentar que estoy ya muy cerca de poder ponerme a trabajar en el script. Antes deberé de actualizar mi equipo porque ya se resiente muchísimo el trabajar con él. También espero que pueda publicar una beta antes del día 27, que será cuando me tome mis minis vacaciones de navidad hasta el 1 de Enero. En la beta no creo que haya nada interesante salvo la posibilidad de ver los cambios y añadidos al motor, pero no esperéis un mini juego ni nada parecido, porque no está implementado el sistema script. Tampoco puedo asegurar al 100% que podrá existir una beta por esas fechas, pero yo espero que sí.
En la actualidad hay un par de errores graves que aún no he podido solucionar, al menos están localizados, espero poder tenerlos "acorrarlos" aún más durante esta semana. La siguiente actualización no sé cuando se producirá, posiblemente cuando haya nuevos avances significativos.

6/11/2001

- Bueno, después de una pausa más o menos prolongada desde la última actualización os cuento el estado actual de desarrollo. En primer lugar os contaré que la última semana, aprovechando el puente, me la he tomado casi libre para oxigenar la cabeza, que buena falta me hacía. Antes del puente pude avanzar en otros frentes muy importantes referidos a lógica interna. También realicé el borrador de lo que será la implementación del sistema de combate. El sistema de combate sí que será el apartado más complejo de los que me toque desarrollar a partir antes de ponerme con el lenguaje script. También será lo último que haga antes de desarrollar el citado apartado sobre el lenguaje script. Nada más que actualice la página me pondré a revisar dicho borrador.

- Es muy probable (todo dependerá del tiempo del que disponga) que lance una beta tan pronto tenga el sistema de combate acabado y depurados ciertos detalles. La idea será lanzar una beta pequeña pero que sirva para que comprobéis todo el aspecto que ha alcanzado ya el motor, así como sus posibilidades.

- Y bueno, por ahora poco más. Supongo que pasarán varios días antes de que pueda actualizar para decir que el sistema de combate está cerrado en su primera versión y que puedo pasar un nuevo capítulo en Crisol.