|
|
|
|
|
|
|
|
27/06/2001
- Os cuento cómo va todo después de la última actualización. En primer lugar, os diré que todo lo referente a la modelización, desde el punto de vista de codificado, de las entidades ya está hecho. Ya existen las clases que representan a las criaturas, items, objetos de escenario y paredes. Sobre las paredes he variado algo los conceptos que había escrito en el documento de diseño. A grandes rasgos, voy a considerar a los accesorios de pared (un antorcha, una ventana, etc) como ítems pero asociándoles un flag (una señal) que indique si ese ítem (accesorio de pared) es estático o bien es extraible. Si es estático no se podrá separar de la pared (por ejemplo, un ítem que represente una ventana o un lector de tarjetas) pero si es extraible podrá ser quitado de la pared (por ejemplo, la siempre recurrida antorcha). Según esto, dejarán de existir entidades de tipo accesorio de pared como tales y pasarán a existir simplemente ítems. Otra de las novedades al respecto de las paredes y sus accesorios es que sólo podrá existir un accesorio por lado de la pared. Recordar que las paredes pueden tener una orientacion al sureste, al suroeste o en ambas direcciones (caso de los bloques que he presentado en la última demo). A parte de las entidades, otro de los cambios que estoy realizando a nivel de código, y que sólo interesará a los programadores que estén leyendo estas líneas, es la progresiva sustitución de la estructura de datos árbol que había implementado por la map de las STL. Esto es debido a que después de leer unos capítulos del libro Game Programming Gems (que me llegó hará cosa de una semana y que recomiendo, como me lo recomendaron a mí, encarecidamente) y comprobar el tipo de árbol de que se trata, un Red-Black Tree, sigue manteniendo tiempos de acceso logarítmicos con un coste mucho menor que un AVL. Este hecho es el que me ha motivado a ir definitivamente a por él. Un árbol AVL puede invertir mucho tiempo reequilibrándose y ser un riesgo a la hora de buscar optimización en la búsqueda cuando los borrados y las inserciones son frecuentes. La clase utiliza los Red-Black Tree (árbol del que yo no tenía conocimiento, pero del que estuve documentándome el pasado fin de semana) que tiene las ventajas de los AVL y los árboles simples de búsqueda (que eran los que yo tenía implementados). Por el momento, he insertado ya map's en la clase CArea, que es la que se encarga de mantener en memoria los handles - instancias de las entidades que existen en la porción de universo cargada, pero paulatinamente iré insertando este tipo de estructura en el servidor de recursos, otro de los elementos claves de engine. - ¿Y ahora en qué estoy trabajando?. Llevo algo más de un día definiendo todo el sistema de interfaz o GUI para comenzar a programarlo en breve. El sistema primero necesita que se definan bien componentes lógicos y físicos como tipo botones, texto con formato, etc con los que poder luego construir todos las ventanas de interfaz como menús, manejo de inventario, cuadros de diálogo, etc. Naturalmente, el menú que sale ahora cuando hay interacción es código que voy a tirar (no así el subsistema que dará cobijo a los menús, que ya está gestado) así que voy a necesitar algo de tiempo para levantar bien todas este código. Espero que en la siguiente beta, se pueda ver un menú de interacción iconizado así como un interfaz principal (la ventana inferior que sale ahora en las betas con el logo del motor) tambíen operativa a su nivel más primitivo. - Como última novedad, citar que tanto Jaime Echagüe como Dracke han dado muestras de querer participar en la creación de gráficos para el motor. El primero probablemente pueda colaborar realizando los iconos de interfaz que sustituyan a los actuales y el segundo, junto al grupo al que pertenece, podrían participar realizando tiles y otros elementos de escenario, así como modelos de personaje. Si bien, no hay nada seguro debido al falta que tiempo que poseen.
22/06/2001
- Bueno, otra demo más colgada. En esta beta, la 0.6, se incluyen unas cuantas novedades importantes, pero también, no os voy a engañar, pasos atrás en temas que creía que tenía solucionados. La demo primero hará un travelling de cámara (el scroll está pendiente de ser optimizado) para dejaros donde está el jugador. Desde ahí le podréis mover o podréis interactuar con el escenario. Para mover o interactuar, deberíes de cambiar el estado del cursor. Bastará con que pulséis al botón derecho. Si pulsáis a la tecla SHIFT, el cursor de movimiento se dibujará sobre cualquier estructura. En fin, experimentad muchachos.
En la demo se pueden ver tres cosas principales. Primero, y más importante, el sistema de trasparencias en las paredes que tapan al jugador. Éstas se harán transparentes suavemente cuando detecten que alguna porción del jugador pueda estar oculta. Como veréis, si estas paredes no fueran de un tamaño de 128 pixels, el motor las haría transparentes igualmente. Es por ello, que siempre que se haga una pared, deberá de poseer ésta altura (el motor no realiza el grueso de los calculos a nivel de pixels por ahora, aunque necesariamente tiene que acceder a los mismos para determinadas operaciones). A todo esto, todos los graficos de los muros son cortesía del motor BlackFish, que ya sabéis que podéis hallar en: http://home.t-online.de/home/BuschnicK/ Por otro lado, todo el sistema de interfaz del motor isométrico ha sido reescrito. Esto me ha obligado a tomar dos decisiones fundamentales. Primera, que el scroll no va a ser algo que se controle desde el módulo del motor isométrico, tal y como venía haciendo hasta ahora, sino que la lógica estará incluida en la ventana de interfaz principal (que es la zona en donde ahora aparece el letrero de "CRISOLEngine"). Esta es la principal razón por la que no podéis realizar scroll. No es que yo lo haya desactivado, es que no está implementado en esta nueva versión del motor. Como mejoras asociadas a la nueva programación del interfaz, deciros que podéis girar al personaje de posición si desde el estado de movimiento ponéis el cursor sobre el mismo y pulsáis al botón izquierdo. También se señala qué sitios no son franqueables por el jugador. Os recomiendo que pulséis la tecla SHIFT si queréis ver el cursor resaltado sobre el resto de objetos de escenario (para que no sea tapado por paredes, por ejemplo). Como último tema importante, la selección de objetos ha madurado bastante y ya no sólo se detecta el cursor sobre ellos, sino que también se indica qué objeto se está seleccionando realizando un fade sobre el mismo. Esto es muy útil para avisar visualmente al jugador de la detección de una entidad. Todo esto, se puede hacer sólo desde el estado de interacción (pulsar al botón derecho y veréis un cursor con el que poder interactuar). - ¿Y los problemas?. Bueno, hay unos cuantos. El más importante es que tengo que volver a revisar en plan fuerte todo el módulo gráfico, ya que obtengo una bajada de rendimiento en los FPS injustificable. El motor gráfico creo que está bien pensado, es decir, hago el mínimo número de RenderStates, para los que conocéis Direct3D, y tengo todas las peticiones almacenadas de forma óptima en estructuras de datos, así que podría deberse a fallos en el Wrapper. No lo sé. Confieso que estoy un poco fastidiado y desorientado sobre el problema, ya que era algo que no me esperaba en absoluto. ¿Qué haré?. Voy a seguir hacia adelante y no volverme loco con ese problema por ahora, ya perdí una tarde con el, así que creo que a corto plazo no voy a hallar la solución. Pero está claro que tengo que preocuparme de él sobre cualquier otro "inconveniente". Los demás problemas vienen del algoritmo de búsqueda que aún necesita ser depurado bastante. No sólo en los temas comentados en la última actualización, sino también en otros que sí que se pueden considerar graves deficiencias del sistema, como el no hallar caminos que visualmente son esperables que el motor resuelva. En este ejemplo podréis comprobarlos por vuestra cuenta. El sistema de selección también tiene ciertos flecos menores (que he comprobado con esta demo) ya que no es todo lo preciso que debiera con las paredes. Bastará con cambiar el órden de comprobación en los tiles y creo que habré resuelto el problema actual. - El tema de los cursores tal y como lo véis ahora, no es nada bueno. Tengo ya ideado un sistema mucho más intuitivo para seleccionar posiciones que resultará, espero, bastante más amigable. Pero necesito voluntarios grafistas que se preseten a realizar tales iconos, ya que yo perderia mucho tiempo haciendolos y me quedarían bastante desastrosos. Posiblemente contacte con el grafista Jaime Echagüe, contacto proporcionado por Pablo Alarcón. Pero si alguno de vosotros quiere participar haciendo iconos para el ratón, Dracke creo que se presto voluntario en una ocasión, recibiría cualquier ayuda de buen grado y, por supuesto, os pondría en los créditos de cualquier beta que los llevara así como en esta página. De todas formas, no hay en absoluto prisa. - Y nada más por ahora. Mañana por la mañana me tomaré el día libre para hacer deporte, porque llevo muchos dias metido encima del motor, además vendrá bien para oxigenar la cabeza y pensar en el siguiente paso. Si véis cualquier problema en la beta o queréis comentarme cuantos FPS arroja en el foro, os lo agradecería.
20/06/2001
- Bueno, me tomo un descanso en la mañana programadora y os cuento como va el asunto. Actualmente estoy trabajando con el tema de la transparencia de las paredes cuando éstas tapan al jugador. En general, estoy implementado el motor suponiendo que TODAS las paredes (puertas, muros, torres, etc) tienen una altura de 128 pixels. De no dibujar dichos elementos así (cosa que el motor exije, pero que el artista puede trucar con solo dejar los primeros "x" pixels del objeto sin dibujar), éstos se harán transparentes sin tapar realmente a la entidad. La capacidad para hacer los objetos transparentes ya está implementada en sí y creo que funciona bastante bien. Además, la transparencia está realizada de tal forma que no se cambia de golpe el objeto a un 50% de transparente, sino que hay un fade que hace que todo tenga más calidad. Os adjunto dos capturas (de mala calidad). Una sin transparencia y otra con transparencia, para que veáis el funcionamiento actual (para los muros, estoy utilizando gráficos cortesía del engine BlackFish: http://home.t-online.de/home/BuschnicK/):
- Por lo demás, el motor está algo inestable ya que estoy ampliando y mejorando modulos. He implementado un sistema de "travelling" de cámara sin movimientos diagonales, de tal forma que desde el API se puede seleccionar un punto del universo y el motor automaticamente hara un movimiento que nos situará ahí. Esto es importante para cuando desde CrisolScript se quiera hacer una cutscene y posicionar el motor en un sitio determinado. Ahora mismo, los frentes en los que quiero trabajar antes de sacar una nueva beta son: * Arreglar un bug que aparece cuando hay desplazamiento en el mapa. El bug actua bajando los FPS de forma determinante cuando hay scroll en vertical (principalmente) y en horizontal, haciendo que existan saltos en el scroll. El problema es que llega un momento en que desaparece, por lo que es difícil saber exactamente a qué se debe (y creo que no hay pérdidas de memoria). Por otro lado, a veces al realizar el scroll el sistema se vuelve loco y comienza a bajar sin parar hasta que se produce una excepcion crítica. Posiblemente debido a la salida del rango del area y el acceso a una zona de memoria no permitida. Todo esto hay que solucionarlo y creo que el problema está en el comando de movimiento para el mapa. * Hay que reprogramar toda la manipulación en la entrada del usuario para hacer que funcione de forma más optimizada y con código más limpio. * Hay que encontrar un mecanismo para resaltar los objetos que son seleccionados. Posiblemente cambie el color de los vertices de forma reiterada mediante comandos fade, o bien realice un fade alpha in/out. * En el algoritmo de búsqueda hay que realizar los siguientes cambios:
14/06/2001
- Bueno, pues aqui pongo otra demo más del motor, la podéis conseguír en la sección de descargas. En esta ocasión, ya tenemos a un sprite danzando por el escenario. La verdad es que se ve poco de los avances que se han hecho internamente, si bien, no os voy a negar que he estado 2 dias y medio solucionando problemas de interpolación en las animaciones (con lo cual, hasta que no das con el resultado es como si no hicieras absolutamente nada). Ahora ya lo tengo todo bien en ese terreno pero (siempre tienen que haber peros) sigue existiendo el bug del raton en la localización de filas impares. He hecho un truco a la hora de hacer scroll, de tal forma que salvo que se llegue a la parte inferior, no aparecerá el problema. Aquí tenéis una captura de la nueva beta:
Podéis manejar al personaje como en el caso de la bola. Si pulsáis las teclas +/- cambiaréis el factor de oscuridad. Si pulsáis la tecla shift, la protagonista correrá y si lo dejáis sin pulsar seguirá andando. He tenido que optar por un decorado poco vistoso al disponer de muy poco material gráfico para los tiles (y para todo, la verdad), al menos, en general, creo que puede dar el pego en plan ambientación de ciencia ficción (bueno, poniendo mucha imaginación también de tu parte :). El sprite es gentileza de Hermann Hillmann, cuyas creaciones podéis encontrar en www.vbexplorer.com/charpack1.asp. Para salir de la demo bastará con que pulséis ESC. Como siempre, necesitáis tener tarjeta de sonido así como tarjeta gráfica 3D. Si tenéis tarjeta 3D y 2D no funcionará. ¡Ah!, que se me olvidaba, la demo no realiza el flip con sincronización, es decir, dibuja a bloque sin esperar retrazado, lo más rápido que puede, por lo que tendréis saltitos en las imagenes posiblemente. Lo hago para que me comentéis sobre cuantos FPS arroja el motor y así tener buenas referencias. Cuando esté acabado, haré flips a frecuencias de 60Hz, esperando retrazado, y todo irá "smooth", como dirían los ingleses :). Como opción no documentada en el readme.txt, os diré que si pasáis al modo de iteracción (botón derecho) y pulsáis sobre la protagonista (botón izquierdo) os saldrá un menú de texto a modo de opciones. Pulsando al botón derecho repetidamente, se avanzará de forma circular por el menú. Si pulsáis el botón izquierdo seleccionaréis una opción. Esto no es más para que veáis que el sistema de menús está dando ya sus primeros pasos (aunque sea muy sencillo, ya hay un embrión implementado) y que el sistema de detección de objetos funciona también. - Con respecto al resto de avances y futuros objetivos, deciros que el sistema para cargar sprites desde archivos grandes ya está implementado y de hecho, lo uso en esta beta (se trabaja cien veces mejor. Si recordáis, en la beta del guerrero andando de un lado para otro, partí la imagen en celdas. Ahora ya no haría falta con este sistema). El motor isométrico lo voy a dejar como está pero no descarto cambiarlo de arriba a abajo. No supondría un gran retraso, ya que lo único sería cambiar las tripas a la clase que lo representa, pues la interfaz está más que de sobra bien definida. Lo digo porque he encargado el libro sobre programación de motores isométricos que me comentaron desde RRC2 Software, y estoy seguro de que habrá cosas nuevas que aprenda y pueda implementar. Si bien, soy algo cauteloso debido a que trae unas 200 páginas de cosas básicas de DirectX y tengo miedo de que pueda ser un libro orientado para principiantes y que no aporte contenido que no se pueda hallar en Inet. Pero bueno, me arriesgo o luego me estaré arrepintiendo. - Con respecto a otros temas, comentar que mañana ya comienzo a meter caña al resto de entidades del universo como paredes, ítems, tiles base (voy a cambiar la forma de representarlos por otra que ahorre más recursos) así como seguir perfeccionando el sistema de menús. En el tema script, el fin de semana hice grandes avances planteando temas y demás, pero no quiero mojarme a escribir todo en un DOC para luego cambiarlo, así que según vaya avanzando el API, así iré madurando la idea del planteamiento del lenguaje script. - Finalizar con lo de siempre. Si sabéis de material gráfico, compartir conocimientos :). Ahora mismo me encantaria disponer de iconos de 32x32 para representar un ratón más chulo o ir haciendo los iconos de menú... a ver cómo lo planteo.
8/06/2001
- Sigo trabajando en el motor a una velocidad más o menos aceptable. Lo que más me ha retrasado esta semana ha sido el dichoso fallo de selección de tiles, que a veces falla. Lo pudistéis ver en la demo anterior. Pues bien, siento decir que no he conseguido solucionarlo aún, aunque ya se en qué momento se produce (cuando la posición del mapa comienza en un tile impar), lo que me ayudará bastante para solucionarlo. Lo más seguro es que este fin de semana me siente con calma y analice todas las fórmulas matemáticas o directamente vuelva a escribirlas todas. A parte del problema anterior, lo demás han sido avances en el sistema de selección de entidades (ya es posible poner el cursor en una entidad del universo de juego y el motor sabrá qué es lo que se está seleccionando), sistema de menú (ya aparece un menú cuando pulsamos sobre la entidad en modo interacción, aunque no pasa nada aún, claro) y saneamiento general del código (he dado un repaso a todo el proyecto para reafirmar que todo está bien organizado y libre de pérdidas de memoria). En estos momentos me estoy tomando un respiro para implementar, después de cenar, la capacidad de cargar sprites desde archivos grandes (archivos que tengan varios sprites) en el servidor de recursos. Actualmente hay que tener los sprites separados en archivos, lo que se hace muy pesado ahora que comienzo a querer crear "demos". Espero tenerlo listo esta noche y poder subir una nueva beta pronto, eso es lo ideal para llevar un ritmo más o menos constante de trabajo. - Aprovecho para agradeceros a todos la ayuda que me estáis dando con los tiles gráficos. También a Pablo Alarcón por proporcionarme ayuda muy valiosa de cara a implementar el sistema script. De los gráficos podré aprovechar elementos, sin duda, lo único problemático sigue siendo los tiles base, pues no he hallado unos que usen una relacion de 64x32. Bueno, miento, los de este otro motor isométrico (muy interesante, por cierto): http://home.t-online.de/home/BuschnicK/ sí que los utiliza. Quizás escriba a esta persona para pedirle prestado los gráficos de su motor, ya que encajan perfectísimamente :).
3/06/2001
- Bueno, unas cuantas cosas han sucedido desde la última actualización. En primer lugar pude hablar con mi director de proyecto sobre el tema de cómo implementar de la mejor forma el lenguaje script. Dos cosas creo que me han quedado bastante claras, por un lado que debo de crear un lenguaje con una sintaxis muy orientada a objetos, es decir, del estilo Player.Accion, de lo contrario será muy complicado que el usuario pueda desenvolverse bien. Y por otro lado, que construir un lenguaje script es una tarea bastante larga y que debo de tener muy claro hasta donde quiero llegar con el módulo script. He decidido que antes de lanzarme a diseñar nada, voy a terminar de crear el API del motor, ya que eso me permitirá luego poder trabajar disiñendo el lenguaje a partir de tener el motor levantado. Así pues, he estado toda la semana codificando pero teniendo en mente que el motor necesitará un lenguaje script. Cuando hablo del lenguaje script me refiero a CrisolScript, pues CrisolBuilder seguirá siendo un objetivo primario para poder ir trabajando mucho mejor. - He subido una nueva beta muy sencilla, eso sí, en la que podéis ver ya funcionando el sistema de selección de tiles, y el motor de búsqueda de caminos, que se basa en el algoritmo A*. El sistema de selección de tiles da algún problema porque a veces el cursor "se pierde" y no sitúa el tile correcto. Después de hacer scroll varias veces, suele colocarse correctamente. Aún no se porque pasa esto pero como no quiero romperme la cabeza en este problema, al poder trabajar bien por ahora, he decidido dejarlo anotado para solucionarlo más adelante. En esta captura:
"podéis" (lo pongo entre comillas porque está muy oscura, ya que he puesto un factor de oscuridad muy alto en el ambiente) ver el aspecto de la demo. Pulsando con el botón izquierdo moveréis la "bola" al destino requerido. Con el botón derecho pasaréis al estado de iteracción del motor, el cual no está aún implementado. En ese estado no podréis ordenar movimiento. Podéis descargaros la demo en la sección de siempre, en la descargas. - Me gustaría pediros si sabéis de algún sitio donde descargar sprites isométricos gratuitos ya que para trabajar ya me las empiezo a ver y desear. Me hubiera gustado mucho poner a un guerrerillo en lugar de ese huevo que he tenido que poner en la demo. De hecho, podréis imaginaros esta misma demo pero con un guerrero con una antorcha, por ejemplo. Sí, ya sé que el "sistema de iluminación" es bastante sencillo, pero mucha mayor ambientación sí que daría :). |
