|
|
|
|
|
|
|
|
24/05/2001
- He subido una nueva versión del documento (la 0.4.3). La podéis encontrar en la sección de descarga. Los cambios son significativos, pero me resisto a pasar a una versión 0.5 hasta no tener todo los temas de CrisolBuilder y CrisolScript estables. En esta ocasión, los cambios se han centrado en la eliminación del atributo de AIState de las criaturas, tal y como se había venido definiendo ahora. Ese atributo, a partir de ahora, no necesitará que se defina su dominio en el módulo de reglas y también lo pasarán a poseer los ítems, los objetos de escenario, las paredes y los accesorios de pared. Por otro lado, he realizado unas ampliaciones / cambios en CrisolBuilder que son dependientes completamente de lo que he introducido en CrisolScript. A groso modo os diré que gira en torno a la asignación de los triggers y los scripts de AI. Ahora será todo mucho menos engorroso que antes, en donde obligaba a que el diseñador se peleará con el concepto de filtro en los triggers y scripts de AI. También quiero comentar que en CrisolScript está todo ya mucho más asentado. Falta hablar de las funciones de API, pero he tocado muy bien el tema de los scripts de AI, que además de a Npcs, se podrán asociar a objetos de escenario, ítems, paredes y accesorios de pared, de este modo el mundo quedará muchísimo más vivo. - Mañana viernes día 25 iré a hablar con mi director de proyecto, espero sacar cosas muy claras sobre la implementación de la máquina virtual y discutir con el la idea que tengo para gestionar todo el "tinglado" para implementar la gestión de scripts y demás, así que espero ordenar bien las ideas. Aprovecho para solicitar ayuda a programadores que tengan experiencia construyendo compiladores, pues necesito documentación sobre los apartados de generación de código y construcción de la máquina virtual. Os estaría muy agradecido. - Sigo esperando vuestras opiniones en el foro sobre qué os pareció el sistema de "noche/día" mostrado en la última versión beta que publique. Os lo agradecería porque me daría mucha más seguridad para seguir trabajando en esa dirección. A fecha de hoy ya tengo implementado el sistema de iluminación también en el motor isométrico, el cual sigo reestructurando, pero sin probar aún. He pausado la implementación durante día y medio con motivo de elaborar esta nueva documentación y preparar los temas que quiero preguntar a mi director de proyecto mañana. Durante el fin de semana espero poder volver a la implementación.
20/05/2001
- He subido una nueva versión del documento. Sin embargo, la he considerado como una mejora / correción de la versión 0.4 que la semana pasada. En esta nueva edición, he vuelto a especificar el concepto de plantilla de animación y he dado un repaso importante a CrisolBuilder, que ya está muy cerrado, a falta de definir el módulo de especificaciones generales para el motor. Pero, lo dicho, está prácticamente perfilado. Podéis encontrarlo en la sección de descarga. - He subido una captura del Visual C++ en acción. Lo he hecho con el único objetivo de que las personas que tengan intención de poner sus manos en el código, una vez que el motor este finalizado, se hagan una idea de la forma en la que estoy estructurando todo el código.
Espero que a los programadores os de sensación de que será fácil rastrear todas las líneas. Podéis ver esta captura ampliada si vistáis la sección de capturas. - La demo publicada ayer os dará problemas si intentáis cambiar de aplicación. Aún no he chequeado el cambio de tareas con el subsistema de audio activo, así que os recomiendo que no cambiéis de tareas :). En la primera demo publicada no pasa nada de esto porque el subsistema de audio no estaba habilitado aún.
19/05/2001
- Ya he acabado de reestructurar el módulo gráfico y de recursos a las nuevas especificaciones del motor. En el primero de los casos, he reimplementado completamente el "pipeline" de dibujado que tenia por otro que es mucho más ahorrativo en recursos y flexible. De hecho, ya se contempla el sistema de iluminación que os había comentado en otros post. Lo mejor de todo, es que he subido una nueva beta que ya trabaja con el concepto de iluminación que os presenté. No usa el motor isométrico porque este es un módulo que tiene que rehacerse por completo y lo dejo para la proxima semana (y siguientes, me temo). Lo que he hecho es trabajar directamente con una imagen y animacion 2D tradicional (Crisol esta desarrollado de tal forma que realizar esta demo no cuesta trabajo ninguno. Simplemente he tenido que deshabilitar el motor isométrico). Por otro lado, el subsistema de recursos ya contempla el trabajo con el nuevo formato de texturas, con ficheros de audio WAV, con las nuevas especificaciones de las plantillas de animacion también y con texto. En estos dos últimos casos, aunque ya puedo hacer pruebas, necesito tener CrisolBuilder levantado para trabajar directamente con los archivos que esta herramienta genere. - El subsistema de audio sí que es un componente completamente nuevo y ya se encuentra implementado en su primera versión. Es capaz de trabajar con ficheros WAV y MIDI. En ambos casos, de forma básica. Es decir, realiza reproducción lineal o cíclica sobre los sonidos y coordina de forma correcta las peticiones de reproducción. Estaría por contemplar la implementación, en el caso de los ficheros WAV, de la posibilidad de variar el "altavoz" por donde se oiga el sonido. Esto es un caso muy interesante en la beta que os presento, donde el guerrero podría oirse por el altavoz izquierdo, derecho o por lo dos, según su posición en pantalla. Implementar esta característica no requiere esfuerzo alguno desde el punto de vista del uso de las DirectX, pero sí que hay que tener cuidado en pensar su inclusión desde el punto de vista de la localización en la arquitectura del motor. De todos modos, estos aspectos yo los considero "colaterales", es decir, que son secundarios con respecto a lo que son otros apartados del motor. - En la beta que os presento, os muestro dos cosas muy importantes. Por un lado, el sistema de audio, es decir, se os tiene que escuchar un fichero MIDI de fondo (fichero musical) y los pasos que da el guerrero al andar. Por otro lado, y lo más importante quizás, es la presentación de la filosofía de iluminación que voy a utilizar para el motor. Necesitaría que en el foro me digáis qué opinas. ¿Da el pego?. ¿Realmente parece que se hace de noche y luego de día?. Espero oir vuestras opiniones. Aquí os dejo dos capturas de la beta. En la de la izquierda, el factor de oscuridad está a 0, en la de la derecha a 255 (máximo).
He puesto una luz de factor 100 en todo el puente y en los alrededores de éste, de tal forma que cuando se va haciendo de noche esas zonas quedan mucho más iluminados que la parte superior e inferior de la imagen. En fin, ya me diréis que os parece. Como siempre, para que os funcione la beta debéis de tener instaladas las DirectX 7.0a y tener una tarjeta gráfica 2D/3D de al menos 2 megas. Por supuesto, esto es una beta, así que podría no funcionaros, aunque creo que no tendréis muchos problemas. También he decidido no empaquetar los gráficos, para que los que sois grafistas veáis como va todo al trabajarse con texturas. Os vendrá bien para entender en concepto de iluminación. Sólo teneís que pensar que cada una de los ficheros tga pueden tener asociada una luz. Como siempre, basta con que os paséis por el apartado de descargas para haceros con esta beta. - Después de esta actualización, mañana domingo lo voy a dedicar a revisar bien CrisolBuilder y es muy probable que cuelgue una versión 4.1 del documento con el apartado de CrisolBuilder prácticamente completado. Eso sería, desde luego, lo ideal. - Y ya, completamente off-topic, ¿habéis visto el vídeo de Duke Nukem Forever?. ¡Woow!, es una pasada :). Bueno, hasta la próxima actualización.
13/05/2001
- Como comentaba en la actualización de ayer, ya tengo lista la versión 0.4 del documento. La podéis conseguir en la sección de descarga. Antes de nada, comentar una serie de cosas. Los apartados sobre CrisolBuilder y CrisolScript no son definitivos. Aún necesito mascarlos más (sobre todo CrisolScript) pero el perfil que tendrán será el que aparece en la documentación. Probablemente, para los que no sepan programación, la documentación de CrisolScript pueda resultar un poco complicada. No os preocupéis, ya que este documento no es un manual de usuario, así que no me entretengo a enseñaros a programar en CrisolScript, simplemente indico el formato que tendrá. CrisolBuilder, al ser muy fácil, supongo que no os presentará demasiados problemas. De todos modos, lo comentado ayer, estaré encantado de que me escribáis si véis que lo que he puesto es demasiado oscuro. Como esta documentación no la he chequeado mucho, en cuanto a errores o redundacias, es probable que a lo largo de esta semana vuelva a actualizar el documento añadiendo correcciones sobre lo que hay o, incluso, ampliando. He decidido quitar la figura que muestra las diferentes plantillas gráficas para las entidades visuales porque he cambiado algunas especificaciones en las dimensiones y me resultaba muy pesado volver a rehacer las figuras. Hasta que no tenga todo bien aprobado y codificado, a este respecto, no la volveré a incluir. Acordaros de chequear el apartado 0 del documento para ver qué es lo nuevo. - Mañana ya comenzaré a codificar de nuevo. Aún no he decidido qué será lo primero que retome. Lo más probable es que acuda a cerrar el wrapper de DirectX que tengo. En concreto, me falta el wrapper para DirectSound y DirectMusic. Por fortuna tengo código base ya implementado, así que iré bastante rápido. Probablemente publique un ejemplo para comprobar si el sistema de wav y midi os funciona bien. Después de cerrar el Wrapper de DirectX, deberé de dedicar un tiempo a adaptar el código que tengo a las nuevas especificaciones. Confio en que no me de muchos dolores de cabeza. Paralelamente a esta vuelta a la codificación iré cerrando progresivamente los temas que tengo pendientes en relación a CrisolBuilder (primero) y CrisolScript (después). - Dracke me ha mandado un email con sugerencias y preguntas sobre temas del motor. Tengo el email pendiente de contestarle pero como creo que es de interés para todos pues voy a contestarlo aquí directamente. * Tema de altitud en el terreno. Sería factible pensar en un motor que trabajara con el factor altitud en los tiles. De este modo, se podrían crear elevaciones del terreno, depresiones, etc. Lo que pasa es que en esta primera versión de Crisol, nada de eso se ha previsto así que no formará parte del motor, pero sí se contemplaría el incluirlo en una segunda versión. La recomendación que me das de crear el suelo de un escenario con 3D Studio o Maya y luego importarlo a Crisol no la veo nada clara, a no ser que luego tú conviertas ese suelo en tiles. La lógica interna de motor, desde el punto de vista de la programación, implica que éste deba de trabajar con el escenario como si fuera un tablero de ajedrez, donde cada casilla es un tile. Sí se podría crear una "malla" del escenario e importarla para que fuera el suelo, pero entonces estaríamos hablando de un motor 3D y Crisol es un motor 2D aunque utilice Direct3D para mejorar el rendimiento y aspecto 2D. No lo olvidéis. * Tema de los vídeos. Sí, estoy completamente deacuerdo en que el no poder reproducir un vídeo en el motor para crear una introducción es realmente un punto en contra para Crisol. El principal problema por el que no lo incluyo es que estoy trabajando con la versión 7 de las DirectX y el SDK para poder reproducir vídeos ya es muy difícil de conseguir, pues es la versión 6, y Microsoft ya no la tiene colgada de su página web. Con la salida de las DirectX 8, el DirectMedia se integró con las DirectX, con lo que no tendría problema si convertiera el wrapper actual para que fuera capaz de trabajar con la última versión de las DirectX 8. Ahora no puedo plantearme eso, ya que implica aprendizaje (que no sería muy largo, ya que las DirectX 8 han ganado en sencillez) y reprogramación del wrapper actual (que sí implicaría mucho tiempo, pues la estructura de las DirectX 8 es bastante distinta). Por lo tanto, al disponer de muy poco tiempo para eso, he decidido no contemplar reproducción de vídeos para la primera versión. De todos modos, he diseñado Crisol con el objetivo de que las "CutScenes", secuencias automáticas, se generen desde el propio motor, así que la posible "intro" de un juego estaría pensada para ser ejecutada con el propio engine. * Utilidades gráficas. Como ya comenté en otra actualización, el objetivo de CrisolBuilder será el de suplir la carencia de tools para esta primera versión. Si bien, si tuviera tiempo, crearía un sencillo editor para que fuera capaz de permitir el diseño de lo que son las áreas del juego, que es la parte verdaderamente más pesada y compliada de definir con CrisolBuilder. No me comprometo pero sí que sería la primera tarea que llevaría a cabo si me sobrara algo de tiempo. De hecho, lo ideal sería desarrollar un set de herramientas que no sólo contemplara el trabajo para definir el contenido del juego, sino que también tuviera un entorno de trabajo con CrisolScript. * Lucha lateral. La lucha lateral que propones es muy propia de los rpg's japoneses. Crisol no está pensando para crear ese tipo de rpg's. La captura siguiente te mostrará un combate en el Fallout. Este juego es la principal fuente de inspiración a la hora de diseñar Crisol (no, mi juego prefiero no es el Fallout, sino el Ultima VII, The Black Gate :). Echad un vistazo a esta captura, muestra una situación de combate en el citado Fallout:
Como podéis comprobar, mientras se combate se mantiene intacto el entorno de juego. Incluso el jugador puede desplazarse por el escenario (bueno, eso no lo podéis ver, obviamente) y realizar acciones normales en él, como abrir una puerta, registrar un cadaver, etc. Esto permite que la inmersión sea muchísimo mayor. Desde el punto de vista del diseño, cuanto más se aconstumbre el jugador a ver secuencias automáticas, combates, acciones, etc en el mismo entorno donde juega, mucho mejor para su inmersión en el universo de juego. Esta es una de las lecciones que aprendí jugando al Ultima VII, donde sólo había una intro al comenzar y al finalizar el juego. Todas las secuencias intermedias, combate, etc, eran llevadas a cabo por el propio motor. Personalmente, jamás he jugado a un juego de rol que me haya presentado un universo más inmersivo. Por lo tanto, por pura decisión personal, Crisol no contará con representación lateral para la lucha. * Tema actualizaciones. ¿Una vez que la primera versión de Crisol esté acabada, qué pasará con su mantenimiento?. Muy buena pregunta. La idea fundamental será liberar el código fuente para que otros programadores puedan dar continuidad al proyecto, aprovechar lo que ya hay, etc. De hecho, me he comprometido a colgar todo el código fuente en Stratos. Lo más probable es que yo siga realizando actualizaciones "oficiales" en el motor, ahora bien, no podría garantizar la periodicidad de las mismas, pues mi situación laboral y personal cambiará mucho una vez que presente el proyecto fin de carrera. De todos modos, no descarto mi continuidad manteniendo el motor, así como tampoco afirmo que vaya a existir. Lo único que os puedo garantizar es que el código fuente estará disponible y para cualquier grupo de desarrollo que cuente con un programador de nivel medio en C++, no le debería de costar mucho moverse por los módulos básicos del motor y modificar aquello que crea conveniente para adaptarlo a las exijencias del juego que quiera crear su grupo de desarrollo. El código está implementado pensando para que otros programadores que quieran modificarlo, puedan hacerlo sin volverse locos. - Bueno, por hoy ya está ralizada toda la actualización. Por mi parte sigo intentando sacar algo de tiempo para jugar un poco más al Arcanum, pero la verdad es que casi no lo encuentro. Quizás me de un respiro por lo que queda del día y juegue un poco más con él. De lo poco que he probado sigo sacando conclusiones y aprendiendo. Lo que más me llama la atención es el potente sistema de conversación que tiene. Desde luego, no creo que haya juego de rol en el mercado con un sistema más inteligente de conversación que éste, en el que dependiendo del perfil del personaje las posibilidades para dirigir las conversaciones son muy variables. Por lo demás, el número de mini aventuras es bastante elevado, los gráficos no tienen una calidad sobresaliente pero son notables y el sistema de iluminación no parece muy potente, pero cumple. Eso sí, se nota que se han apoyado en las Direct3D para mejorar el aspecto gráfico (alpha blending y coloreado de tiles).
12/05/2001
- Perdonad por el retraso en la actualización y, sobre todo, a ciertas personas que no he contestado el email, pero me hallo muy pillado de tiempo y al ir aplazando compromisos uno nunca acaba por contestar los emails. En esta actualización lo más importante que tengo que deciros es que ya tengo perfilado CrisolBuilder y CrisolScript y estoy a punto de cerrar la versión 0.4 del documento. Es más, espero poder subirla mañana domingo para que los interesados la echéis un vistazo y, sobre todo, me digáis que impresiones tenéis sobre los lenguajes (a CrisolBuilder me da cierto reparo llamarlo lenguaje), si todo resulta muy complejo (para los que no sepan programar y lo lean), si se os ocurren mejores formas de plantear todo (para los programadores que lo lean), etc. El único pero es que la documentación no es un manual de usuario de esos dos lenguajes, por lo que quizás puedan parecer oscuros cuando en realidad no lo son. Ahora no me puedo poner a realizar un manual de usuario por dos motivos: 1) que aún no están cerradas ni completadas las especificaciones (pero si bastante avanzadas) de los mismos y 2) que ahora no es el mejor momento de ponerme a realizar eso. Por lo tanto, espero que mañana domingo pueda subir el nuevo documento y contestar a varias preguntas que tengo pendientes. También hablaré de temas que he contestado en emails privados, para que todo el mundo pueda leerlos y opinar. ¿Decuerdo?. Pues entonces, si todo va bien, mañana espero subir una nueva actualización del documento y comentar muchas más cosas. De hecho, si todo marcha bien, el lunes dia 14 volvería ya a codificar y diseñar en paralelo, después de más de un mes rediseñando y retocando temas técnicos.
04/05/2001
- Ya estoy de vuelta de las vacaciones que me tome. Aunque más que vacaciones fueron unos cuantos días muy especiales. Ahora mismo tengo un pequeño gran lío de temas pendientes. Hoy lo he dedicado por completo a leer todas las anotaciones que realicé antes de marcharme hará hoy una semana. He revisado el sistema de iluminación y he reescrito todas las notas que tomé, ahora está todo mucho más claro. También he aprovechado para disponer todo para que mañana pueda comenzar sin falta a pensar en el sistema de selección de objetos. La verdad es que me gustaría que este fin de semana tuviera ese tema más o menos resuelto y también hubiera comenzado a embestir ya la definición mucho más formal del sistema de archivos, pues me permitiría trabajar ya también en la definición de CrisolBuilder. - Me ha llegado un email en el que me preguntan si pienso subir la documentación de implementación. Sí, desde luego que tengo pensado subirla, pero antes tengo que ponerme con ella. Ahora mismo sólo tengo notas hechas a mano y no voy a pasarlo a word porque la programación es algo bastante inexacto como para definir las pautas que vas a tomar en un documento formal. Por ello, siempre prefiero tener toda la documentación de implementación a mano. De esta forma, modificarla (cosa habitual) me es mucho más sencillo. Lo que sí que iré haciendo será poner las decisiones técnicas que he tomado para implementar tal o cual cosa y lo explicaré aquí o en el foro. Tan sólo tenéis que preguntármelo y si sé responderos pues intentaré no quedar demasiado mal :). Sobre los libros que estoy utilizando y las fuentes de información, pues la verdad es que lo primero que hice fue buscar por Internet todos los motores de la misma temática que Crisol, con el fin de saber qué es lo que la gente ya ha realizado, cómo la ha hecho, cuáles son las premisas principales, por dónde se han guiado, sus mayores virtudes y defectos, etc. A parte, pues siempre cuento con una bibliografía básica para salir del paso. Libros como "Programación en Windows 95" de Charles Petzold, "El Lenguaje de Programación C++" de Bjarne Stroustrup, "Effective C++" de Scott Meyers, "Desing Patterns" de Gamma, Helm, Johnson y Vlissides, "DirectX Complete" de Root Boer, "Game, Architecture and Design" de Andrew Rollings y Dave Morris, "Thinking in C++" de Bruce Eckel, revistas como "Game Developer" o páginas en internet como Macedonia, Stratos, GamaSutra, FlipCode (donde de vez en cuando Javier Arévalo de Pyro Studios y su hermano dejan post muy interesantes) o GameDev (con foros muy vivos) son fuentes de inspiración y búsqueda de soluciones. Pero naturalmente, antes hay que romperse los cuernos pensando cómo hacer algo de forma eficiente y elegante, porque de lo contrario habrá que tirar código a la basura más adelante (cosa que me ha pasado a mi por no haber definido todo completamente bien, y que me ha hecho perder casi dos meses de duro trabajo). - No sé si os distéis cuenta, pero la demo de Arcanum ya ha sido publicada en Internet. La podés incontrar aquí. Yo la bajé ayer jueves y apenas he podido jugar. Lo que he visto digamos que no me ha defraudado pero tampoco me ha entusiasmado. No he jugado mucho a la misma para dar una opinión más formal, pero noto que le falta ese "punto" que no sabes nunca qué es, pero que sirve para hacer grande a un juego. Espero jugar a la demo más a fondo, eso sí saco tiempo pues este fin de semana también tengo que trabajar en temas de Macedonia. |
