PROYECTO UTOPIA

oFusion

2006-05-04T17:21:00.000+02:00

Ogre dispone de una de las mejores herramientas de exportación que he visto en años: oFusion. Únicamente he encontrado un pequeño problema, y es que el compilador octree de ogre funciona con ficheros en formato scene y oFusion exporta los archivos en formato osm. Pero por suerte tiene fácil solución ya que ambos archivos, que no son mas que una descripción bastante general de la escena, están en formato XML. Gracias a cygwin me preparé un pequeño script en perl para hacer la conversión:


#!/usr/bin/env perl

# The author(s) have made the contents of this file
# available under a CC-GNU-GPL license:
#
# http://creativecommons.org/licenses/GPL/2.0/
#
# A copy of the full license can be found as part of this
# distribution in the file COPYING.
# 
# You may use this software in accordance with the
# terms of this license. You agree that you are solely 
# responsible for your use of this software and you
# represent and warrant to the author(s) that your use
# of this software will comply with the CC-GNU-GPL.
#
# Copyright 2006, Victor Marzo (samsaga2@gmail.com)
# 

# USE: osm2scene.pl < demo.osm > demo.scene

use XML::Simple;
use XML::Writer;
use Data::Dumper;

my $xml_osm = XMLin('-');
my $xml_scene = new XML::Writer(DATA_MODE => true, DATA_INDENT => 4);

$xml_scene->startTag('scene', 'formatVersion' => '0.0');

my $id = 0;

for my $entities ($xml_osm->{entities}) {
 $xml_scene->startTag('nodes');

 for my $entity_name (keys %{$entities->{entity}}) {
  my $entity = $entities->{entity}->{$entity_name};

  $id++;

  $xml_scene->startTag('node',
   'name' => $entity_name, 
   'id' => $id);
  
  $xml_scene->emptyTag('position', 
   'x' => $entity->{position}->{x},
   'y' => $entity->{position}->{y},
   'z' => $entity->{position}->{z});

  $xml_scene->emptyTag('rotation', 
   'qx' => $entity->{rotation}->{x},
   'qy' => $entity->{rotation}->{y},
   'qz' => $entity->{rotation}->{z},
   'qw' => $entity->{rotation}->{w});

  $xml_scene->emptyTag('scale', 
   'x' => $entity->{scale}->{x},
   'y' => $entity->{scale}->{y},
   'z' => $entity->{scale}->{z});

  $xml_scene->emptyTag('entity',
   'name' => $entity_name,
   'id' => $id,
   'meshFile' => $entity->{filename},
   'castShadows' => $entity->{CastShadows});
   
  $xml_scene->endTag('node');
 }

 $xml_scene->endTag('nodes');
}

$xml_scene->endTag('scene');

Tendréis que instalaros los modules XML::Simple y XML::Writer pero usando el CPAN del perl no deberíais tener ningún problema.

Abril. Resumen del mes. Mes de infarto.

2006-05-02T17:43:00.000+02:00

Mes de infarto.

El mes de abril ha sido un mes de cambios ‘brutales’ en nuestro proyecto. Después de diversas pruebas con la primera demo, nos dimos cuenta de la gran perdida de rendimiento que nos causaba la librería Cal3D. Otros factores añadidos que afectaban al rendimiento nos hicieron retomar una idea que en tiempos ya habíamos barajado en el proyecto, usar un motor de render ya desarrollado. Necesitabamos que fuera fiable y se le viese continuidad a su desarrollo. Al final nos decidimos por Ogre. No será el mejor, pero se adapta a las necesidades que tenemos.

En un tiempo record para nosotros, se ha montado la primera demo sobre la que se estaba trabajando con todas las características que ya estaban incorporadas, como el motor de sonido y físicas. Samsaga2 se lo ha currado, si señor. Además, ya estamos añadiendo lo que será parte del control de IA.

No hemos tenido suficiente con estos cambios, y nos hemos reorganizado a nivel de coordinación de proyectos. Nuestro amigo Manolin se encargará a partir de este mes de la coordinación de gráficos permitiendo a Nwanda centrarse en guión.

Porque esa es otra. También estamos de reforma en guión. Pero sobre esto mejor no contaré nada. Que luego me regañan.

Saludos.

Marzo. Fin de mes.

2006-04-04T12:11:00.000+02:00

Soplan vientos de cambio en nuestro proyecto. A Marcus le gustan estas expresiones. :-)

Este mes, después de evaluar los resultados de la segunda demo del motor donde incorporábamos sonido, físicas y scripts, los resultados nos han demostrado que debíamos revisar en profundidad el núcleo de nuestro motor. Esto nos ha hecho recapacitar sobre varias de las ideas que hace tiempo estábamos barajando.

En breve comunicaremos cuales van a ser los cambios que vamos a realizar. Cambios que, seguramente, afectarán al motor de render y al motor de física del juego.

Saludos.

¿Está muerto Cal3d?

2006-03-21T08:21:00.000+01:00

La última versión apareció exactamente el día 12-01-2005, hace ya mas de un año. Nunca ha sido una librería que se actualice cada pocos meses y ya sospechaba hace tiempo que algo ocurría. En el foro uno de los desarrolladores se empeña en decir que Cal3d esta un poco congelado pero no muerto.

Una de las grandes lacras de cal3d es que no es una librería muy optimizada, se nota demasiado el escaso rendimiento que ofrece. Un par de modelos en pantalla se puede comer perfectamente mas del 30% del tiempo del render. Además no hace uso de técnicas más modernas como tirar de los vertex shaders para quitarle trabajo a la cpu.

Lo malo es que no hay muchas alternativas (Animadead es una de ellas).

Marzo. Primera quincena. Estado del proyecto.

2006-03-16T09:00:00.000+01:00

El repaso del estado del proyecto de esta primera quincena de marzo es muy animador.

El avance ha sido impresionante en estos últimos días en todos los frentes. Repasemos.

Se ha dejado establecido todo el proceso de exportación de modelos desde 3DMax a Cal3D controlando todos los problemas que puedan surgir. Avanzamos también en el editor de particulas y el gestor de niveles, todo esto en C#.

En IA y carga de niveles tenemos controlados gran cantidad de problemas. El avance esta siendo arrollador.

El sonido seguramente formará parte de esta demo. El motor de sonido aportado por Synchrnzr y el trabajo de nuestro nuevo músico nos permitirán incorporar sonido en 5.1 y posiblemente, en 7.1.

En gráficos también avanzamos. Esta costando mantener un equipo estable de personas pero creo que lo conseguiremos. En breve subiremos más pantallas con los personajes elaborados por ellos.

Como bien dice nuestro compañero Samsaga2, el objetivo que nos hemos marcado de aquí a dos meses, la segunda demo del motor, nos permitirá tener un porcentaje muy alto del motor terminado. Con lo que para la siguiente demo nos concentraremos en mejorar la calidad del render, eso si, sí el compilador de Shaders nos lo permite. :-)

EXPORTACIÓN DE MODELOS DESDE 3DMAX A CAL3D.

2006-03-13T12:28:00.000+01:00

INTRODUCCIÓN

Dentro del proyecto Utopía, una de las librerías externas que usamos es CAL3D. Esta librería permite la presentación de modelos en 3D con varias animaciones, permitiendo que se realicen transiciones entre ellas. Además, el modelo permite incorporar materiales y texturas.

Antes de comenzar ha explicar el proceso de exportación de un modelo desde 3DMAX a CAL3D, voy a comentar que ficheros componen un modelo en CAL3D.

La base de un modelo en CAL3D la compone el esqueleto. Sin esqueleto no es posible trabajar con un modelo en CAL3D. Así, previamente, todo modelo en 3DMAX deberá tener realizado su rigging para poder exportarlo. En las imágenes se puede ver el esqueleto y la malla con las texturas aplicadas.

El esqueleto para CAL3D esta identificado por los ficheros con extensión csf.

La malla que compone el modelo se puede exportar en uno o varios ficheros. Eso depende de cómo se haya modelado la figura en el 3DMAX. Por ejemplo, si un modelo se ha creado en tres partes, cabeza, tronco y piernas, se puede exportar con tres mallas. Esto es lo recomendable ya que se producen errores inesperados cuando se intenta exportar en una sola malla. En la figura se pueden observar las diferentes partes de la malla indicadas por los colores.

Las mallas en CAL3D están identificadas por los ficheros con extensión cmf.

Todo modelo puede tener varias animaciones. Y como ya he explicado en otro post es posible realizar transiciones entre ellas o aplicarlas en un momento dado. Las animaciones están identificadas por los ficheros con extensión caf.

Al hablar de materiales, debemos tener en cuenta varios factores. Si el modelo se ha dividido en varias mallas, deberá tener un material por malla. Un material indica de manera básica, como se aplicará la luz y las transparencias sobre el modelo.

CAL3D para un material usa los valores habituales para definir los colores y valor para el brillo:

ambientColor, diffuseColor, specularColor y shininess.

También, puede indicar que usa una o varias texturas. Los materiales están identificados por los ficheros con extensión crf.

No olvidemos que para facilitar la carga de un fichero se recomienda construir un fichero de texto donde indicamos cuales son todos los ficheros que forman el modelo.

Esto es, a grandes rasgos, los ficheros que forman la estructura de un modelo en CAL3D.

El contenido de un fichero cfg podría ser así:

################################################
#
# Marinero Futuro - Cal3d cfg File
#
################################################

scale=1.0

################# Skeleton #################
skeleton=marineroF-esqueleto.csf

################# Meshes #################
mesh=marineroF-malla.cmf

################# Animations #################
animation=marineroF-andando.caf

################# Materials #################

material=marineroF-cuerpo[0].crf
material=marineroF-cabeza[1].crf

EXPORTACION

Recordar que debemos tener los plugins de exportación del CAL3D instalados como indican las instrucciones en el 3DMAX. Comenzamos:

1º

La exportación siempre se debe comenzar con el esqueleto de la figura. El esqueleto de la figura se usará para controlar las mallas y animaciones que se pueden asociar a ese esqueleto.

Para eso en el 3DMAX seleccionamos únicamente el biped. Si lo seleccionamos en modo ‘figure mode’ la figura se exportará con la posición que por defecto adopta el biped.

Al exportar el biped se pueden seleccionar los nodos que queremos exportar aunque mi experiencia me ha demostrado que CAL3D no acepta fácilmente que se quiten nodos de un esqueleto.

2º

Una vez que tenemos exportado el esqueleto podemos exportar en cualquier orden las mallas o las animaciones.

Si se elige exportar primero las mallas, se debe tener en cuenta que pueden surgir algunos problemas. Si el modelo esta compuesto por varias mallas es mejor exportar cada una de ellas aparte. Se pueden prevenir problemas en la exportación, provocados por el esqueleto o los materiales. En algunos casos, el exportador falla estrepitosamente al intentar exportar todo un modelo en una sola malla.

En el ejemplo se ve que este modelo esta compuesto de una sola malla.

Al exportar una malla se debe seleccionar el esqueleto que le corresponde. CAL3D no acepta que se exporte una malla de un modelo sobre el esqueleto exportado de otro modelo.

Podemos indicarle el número máximo de huesos que influyen sobre un vértice y el peso mínimo que tendrá un hueso para esa influencia. Los valores que aparecen por defecto, en general, no es necesario cambiarlos.

Al exportar un modelo se puede seleccionar que nos calcule el ‘LOD’ de la figura para luego usarlo a la hora de reducir el número de polígonos que se mostrarán.

Por ultimo, nos pregunta si queremos hacer uso de un sistema que esta en fase de pruebas para el tratamiento de telas.

3º

Si vamos a exportar las animaciones, debemos tener la precaución de que el modelo no este ‘figure mode’. Si esta en este modo, no tendremos generada animación alguna en la exportación. Para exportar una o varias animaciones lo único que debemos hacer es indicar el esqueleto que se usará para el modelo. Se pueden activar o desactivar nodos. Con lo que se pueden dejar partes de un modelo sin animación o que se produzcan efectos no deseados.

Como se ve en la pantalla, es posible exportar partes de una animación o reducir el número de ‘frames’ que se usan en la animación.

4º

Para exportar los materiales debemos de tener cada uno de los materiales del modelo en un slot en la ventana de materiales del 3DMAX.

Además, cada material deberá tener asignado en su nombre un número entre corchetes empezando con el cero. Así, si tenemos tres materiales, uno para la cabeza, otro para el tronco y el último para las piernas se llamarán:

Cabeza[0]

Tronco[1]

Piernas[2] ...

O algo similar pero respetando que deben llevar los números en el nombre.

El orden de exportación se debe respetar, exportando cada uno de los materiales en su orden numérico. Además, los nombres en los ficheros exportados, deberán llevar también el mismo número que se ha usado en el 3DMAX.

Dicho orden se debe respetar en el orden de carga de los materiales y la asignación de las mallas ya que si no se hace así, el material se cargará pero no CAL3D no lo aplicará correctamente.

En el caso en el que se modifique una malla o se cambie un material, se deberá exportar otra vez, tanto la malla como el material. Si no se hace así, el resultado seria incorrecto y partes de la malla se presentarían sin texturas como se puede ver:

Y eso es todo. Si nuestra exportación es correcta el resultado se podrá comprobar en los visores de modelos que incorpora el CAL3D o en el programa para analizar los modelos que forma parte de nuestro proyecto. El resultado será el siguiente:

Espero que este tutorial os sirva para poder trabajar mas comodamente con las exportaciones. En breve, subiremos este tutorial a nuestra web en formato pdf para su descarga.

Saludos a todos.

Resumen de febrero.

2006-03-02T09:29:00.000+01:00

El mes de febrero lo finalizamos con algunos cambios de peso.

Se han establecido los nuevos estatutos de nuestro proyecto que en breve se publicarán en la Web. Con esto lo único que pretendemos es mejorar la seriedad de nuestro trabajo. Eso no quiere decir que nos vayamos a convertir en una empresa consultora de esas que pululan por nuestro mundo. O esas empresas desarrolladoras que solo ven en un juego un producto industrial. No nos vamos a volver serios en esa línea y seguiremos siendo ese grupo de amigos que se lo pasan bien haciendo algo que les gusta. Os lo juro sobre la escopeta del Doom.

Eso si. Queremos dinerito. Nuestro objetivo final es vender nuestro trabajo. Esperemos que así sea.

El objetivo de aquí a tres meses es tener una demo básica con algunos personajes que permitan evaluar como vamos avanzando en la inteligencia artificial, físicas, scripts y en general, los interiores del juego. Ya tenemos avanzado por parte de Synchrnzr el motor de sonido así que igual hasta podremos ofrecer música en nuestra demo.

Este es el primer paso para ir mostrando nuestro trabajo.

En breve, para facilitar la labor de los grafistas, publicaremos un tutorial de cómo realizar la exportación de modelos desde el 3Dmax para ser usados por Cal3d.

Saludos a todos.

NUEVOS ESTATUTOS

2006-02-25T10:32:00.000+01:00

Durante las últimas semanas hemos compaginado el trabajo cotidiano del desarrollo del juego con un debate abierto para la reelaboración de nuestros Estatutos, o sea, de las normas internas por las que nos regimos, funcionamos.
Tras ese proceso hemos terminado aprobando una nueva versión más completa de los Estatutos que teníamos antes, aclarando algunos puntos y mejorando otros. Hemos querido que todo el mundo se pueda sentir contento y satisfecho tanto con su trabajo como con su futura recompensa. Así, una de las cosas a la que le hemos querido dar mayor énfasis ha sido a esa cuestión: el que más se esfuerce y aporte para conseguir crear el juego, mayor recompensa tendrá en el futuro. Eso era un punto que antes no estaba muy claro, y que ahora sí lo está.

También hemos querido expresar con ellos una idea latente que, aunque no pronunciada, sí que es parte esencial de nuestro espíritu: que este proyecto va a ser difícil que muera. El tiempo que tardemos no nos importa, ni tampoco la posible recompensa futura, lo que más nos importa es el proyecto en sí mismo, la posibilidad de algún día verlo hecho realidad, con nuestros personajes vivos en un mundo virtual lleno de colorido y emoción.
No nos desilusionamos con facilidad, somos tenaces, persistentes, testarudos. Ni huracanes, ni tormentas, ni terremotos podrán amedrentarnos. Si hemos llegado al punto en el que estamos, difícilmente nos vendremos ahora atrás.

Podréis leer en breve la versión completa de nuestros Estatutos en la web del proyecto.

Mientras tanto nosotros seguimos en la sombra trabajando, lenta pero constantemente. Ocupados en mil quehaceres, y resolviendo cientos de problemas, para ir dándole poco a poco una forma más completa a nuestro trabajo.

Febrero. Primera quincena. Estado del proyecto.

2006-02-20T23:10:00.000+01:00

Con algo de retraso paso a recordar nuestro ultimo resumen quincenal.

Seguimos en la misma línea de trabajo y no hay cambios aparentes...

Si digo aparentes, es porque si se han planteando ciertos cambios técnicos.

Vamos a abandonar el uso de árboles BSP para la representación de los niveles interiores para decantarnos por el uso de octrees. Se están usando varios niveles de prueba para evaluar su funcionamiento y corregir algunos errores. Esto nos dará más libertad a la hora de diseñar los niveles con lo que ganaremos en calidad de diseño al no usar diseños demasiado cuadriculados.

Lo más importante es que nos hemos fijado el objetivo de tener una demo operativa dentro de tres meses. Un protagonista se deberá enfrentar a uno o varios enemigos como este:

Pronto, nuestros protagonistas, Adrián o Marcus, sentirán el aliento de algunos de los enemigos que habitan y dominan ese extraño lugar donde sus caminos se han encontrado.

Materiales

2006-02-06T08:44:00.000+01:00

Una forma bastante útil de mejorar la calidad del render del motor es usando un sistema de control de materiales lo más flexible posible. Hoy en día cualquier motor usa archivos de configuración (normalmente en formato texto) para poder controlar las propiedades de los materiales. En el wiki de Ogre podéis ver un ejemplo bastante claro.

Una opción interesante puede ser añadir una propiedad que defina la calidad de ese material. Si la calidad normal es, digamos, de 100 y el usuario quiere bajarla para que el juego funcione más fluido podemos hacer que el motor cargue los materiales con una calidad menor de 100. Además de ser una buena forma de controlar el hardware 3d que no soporta alguna característica avanzada, simplemente cargamos el siguiente material de la lista con menor calidad y listo.

Enero. Fin de mes.

2006-02-02T12:04:00.000+01:00

Seré breve.

El arranque de año ha sido lento pero ya tenemos cogido el ritmo. Repasemos cada modulo.

Programación:

Gracias a Samsaga2 ya hemos probado la primera demo interna y ver como se aplican las físicas en el nivel de pruebas. Seguro que Adrián esta sudando de tanto correr detrás de las esferas. Mejor será que coja aire ya que sé esta trabajando para incorporar los exteriores al motor del juego. Le va a tocar correr algunos kilómetros.

La IA va dando sus primeros frutos. El tema esta muy abierto ya que debemos de establecer cuan listos queremos que sean los personajes del juego. Pero se avanza que es lo importante.

Shaders. Esperando.

Offtime. Terminada la base del gestor de mapas, empezamos a trabajar sobre los detalles. El visor de modelos esta pendiente de modificar para trabajar con modelos compuestos (jinete-montura). Y ya estamos trabajando sobre el editor de partículas.

Gráficos:

Lento pero seguro. Algunos miembros no se dejan ver mucho pero se va viendo algo de trabajo. En breve, tendremos una sección especifica en la web para que se pueda ver el progreso de su trabajo.

Guión: Hay que animar a Nwanda. Le estamos estresando con tantas ideas. Pero da gusto ver como se va construyendo una historia sólida.

Web: En continua renovación. Es bueno. Que se vea que no estamos dormidos.

Solo deciros que los coordinadores estamos contentos de ver que el ritmo de trabajo no se pierde. Y que en breve, se plantearan objetivos definidos. Esto indica que todos tendremos que comprometernos para poder cumplir con esos objetivos.

Hasta dentro de 15 días.

¿Quienes somos?

2006-01-30T08:58:00.000+01:00

Si. Somos reales. De verdad. De carne y hueso. A veces, la Web genera demasiado anonimato. Hablas con una persona usando el correo, messenger, chat, irc. Y te haces una imagen de esa persona. Y seguro que no aciertas.
Para que no haya errores con nosotros, aqui estamos:
Nosotros en Utopia.
Faltan algunos. Si. Puede ser la timidez. O la falta de tiempo para subir su foto o su caricatura.
Porque la verdad es que no tenemos mucho tiempo. Estamos dedicados a preparar y planificar la temida lucha contra el Dios de Piedra.
Pronto. Muy pronto. No os confies, insensatos.

El infierno de los compiladores

2006-01-23T08:29:00.000+01:00

Una de las cosas que me menos me gusta del compilador Microsoft C (con gcc también ocurre pero no de forma tan evidente) son esos crípticos mensajes de error; una simple coma en un template puede desencadenar decenas, que digo decenas, centenares de errores. Además como salen todos por ahí desordenados te las ves y las deseas para encontrar aquella coma o aquel asterisco que te olvidaste.

A todo esto le podemos sumar los errores al enlazar las librerías. El compilador de C de Microsoft tiene una feature que a la hora de la verdad no hace mas que complicarlo todo. Y es que según compiles en modo debug o release te enlazará con unas librerías u otras (libcmt o libcmtd por ejemplo). Esto puede ocasionar problemas si usas diferentes librerías compiladas en diferentes modos con lo que puede resultar que el compilador no acabe encontrando algunas funciones que no son realmente necesarias.

Al final todos estos fallos son realmente culpa de programador ("usease" yo). Pero me fastidia que en lugar de simplificarnos las cosas no hacen mas que ir complicándonoslas cada vez más.

PD: dejo para otro post el infierno del CRT.

Proyecto. 1º Quincena de Enero.

2006-01-17T11:56:00.000+01:00

Comenzamos el año con fuerza. Y falta hace que nos acompañe.

Como bien ha comentado Nwanda, arrancamos el año con el objetivo claro de tener una primera demo de nuestro proyecto. Esta demo nos va a permitir evaluar muchas cosas.

La primera, la necesidad de ir montando un programa instalable para que todos podamos probarla. Eso nos permitirá evaluar en nuestras maquinas el rendimiento y poder ir controlando los diferentes errores, en el parque de ordenadores que tenemos. Esta demo es de uso interno pero en breve publicaremos una demo para que los amigos de nuestro proyecto puedan también participar en las pruebas.

La segunda y el resto, nos hacen ver que queda mucho camino por delante. Mucho trabajo. De un vistazo, estamos avanzando en:

La I. A. Pronto Adrián y compañía encontrarán el camino ellos solitos. Falta les hace, que ya son mayores.

Shaders. Necesitamos shaders. Hay que trabajar con las ultimas tecnologías y estamos esperando ver los primeros resultados de aplicar shaders en nuestro motor.

Y se abren nuevos horizontes. Se esta empezando a trabajar en la unión de los interiores con los exteriores. Adrián ya mismo saldrá de la cueva para pasear por el campo sin perderse y sin tropezarse, que para eso ya se está trabajando sobre las colisiones y dinámicas para exteriores.

Y cuando hablo de compañía, me refiero a que a Adrián pronto le perseguirán varios enemigos, ya que los grafistas ultiman los modelos de varios de ellos. En breve, pondremos algunas imágenes de los enemigos que vamos a ir añadiendo al juego.

paseando a Adrian

2006-01-16T17:14:00.000+01:00

Estamos contentos en general con la marcha del proyecto.

Hemos iniciado ahora un debate colectivo para reescribir los Estatutos, como ya anunciamos que haríamos. Todos los miembros están invitados a dejar su punto de vista de cómo creen que deberían ser nuestros Estatutos, nuestras normas internas de funcionamiento

Por otra parte... ayer por fin estuve dándole una vuelta a Adrian por el interior de la caverna. Había que poner cuidado de no caer por el precipicio, para no estrallarse. Lo mejor es que en el cutre ordenador (un atlhon 1500) que lo probé el rendimiento era bastante alto, no bajando de 200 FPS en ningún momento.

La lista de correo sigue tan animada como siempre. Perderla de vista una semana puede significar tener que leer 300 correos de una tacada para ponerse al día.

Estado del Proyecto

2006-01-03T20:00:00.000+01:00

Ya que Aris se ha tomado un respiro vacacional de una semana, y que no ha hecho su habitual resumen sobre el estado del proyecto, ya que ahora ha desconectado plenamente del mundo virtual, aunque sea con un poquito de retraso quiero suplirlo yo para seguir constatando que estamos vivos… y con muchas ganas de sacar pronto algo a la luz pública.

El 31 de diciembre mandé a la lista un correo, y un fragmento de ese texto podría bien servir de resumen a nuestro estado:

Parece que el trabajo marcha como es debido, y que vamos a tener que cambiar el nombre del proyecto, de utopía a realidad, porque poco a poco estamos convirtiendo esta quimera nuestra en algo real, factible, alcanzable. Ello nos ha hecho pensar en rescribir los estatutos, haciéndolos un poco más 'legales' y formales, un poco para intentar ir sellando huecos y posibles lagunas futuras, para evitar enojos ajenos y propios, tratando de que si tenemos que formalizar una empresa surjan el menor número de problemas posibles. Haberlos los habrá, los problemas (que siempre los hay, como las brujas, aunque éstas no existan), pero la idea es la de intentar que sean los menos.

Llega un año nuevo... y formulo aquí un deseo (aunque ni crea en el año nuevo ni en los deseos, más bien en la voluntad y la constancia): A ver si con el nuevo año hacemos todos esos estúpidos propósitos de enmienda, y cuando el planeta donde vivimos vuelva a dar una vuelta completa a esa estrella que llamamos sol podamos tener nuestro juego vendido :-), o por lo menos muy cerca de ello.

Si no fuera así, que por lo menos todos estemos mejor de lo que estamos ahora.

Ha pasado un año en el que se han producido muchos cambios, entre los más importantes el de encauzar el engine a unos derroteros distintos de los elegidos al principio (menos arriesgados), destacando la decisión de valernos de algunas aplicaciones de software libre para agilizar y facilitar las cosas. Ya las hemos nombrado muchas veces: el Cal3d, el LUA, y por último para las físicas, tras descartar por algunos problemas el ODE, el Newton Physics.

Hace poco al ojear el Fallen Lords, un juego comercial de Novorama que ha salido recientemente a la luz, comprobé con satisfacción que ellos también se han valido para su juego comercial del Cal3d y del LUA, entre otras aplicaciones de software libre, lo que un poco ha venido a confirmarnos que estamos por el buen camino.

Entre los sucesos más significativos que puedo destacar:

Hemos encontrado a un grafista que parece bastante bueno (como modelador/ texturizador), y que de momento está trabajando a un ritmo bastante bueno, y con una calidad también notable. Espero que siga haciéndolo así de bien ;-) Por si queréis saber más de él, también colabora en un MOD del Half-Life 2.

Javier nos comentaba que algunas circunstancias le han impedido trabajar sobre su motor de shaders, pero que ahora cree que se podrá poner con él y tener algo usable en pocos días… Estamos deseando poder hacer uso del motor de shaders, porque eso nos permitirá implementar verdaderas virguerías que mejorarán notablemente la calidad de nuestro.

Por último, samsaga2 está a las puertas de finalizar la primera demo. En pocos días los del proyecto podremos probarla y valorar así la potencia de nuestro engine.

Pronto, muy pronto, más noticias.

Versiones inestables

2005-12-27T20:21:00.000+01:00

Es que nunca escarmiento, esta manía mía de tener que usar siempre lo último de lo último no para de darme un problema tras otro. Esta vez ha sido cal3d, la librería de animación por huesos. La última versión es la 0.10.0 de la que únicamente conozco un bug relacionado con el LOADER_ROTATE_X_AXIS. Bug que está solucionado en la versión en desarrollo (que se puede bajar desde el servidor CVS de SourceForge). Pero la versión del CVS parece tener otro problema con las animciones cíclicas.

¿Con cual me quedo?
Solucionado... downgrade a la versión estable ;-)

Diciembre. 1º Quincena.

2005-12-18T11:58:00.000+01:00

Toca hacer un repaso breve de como vamos a mitad de mes.
En programación estamos contentos. Si. Contentos. El avance es claro. O deberia de decir, en ocasiones, veo a Adrián andando. La demo que Samsaga2 esta ultimando ya permite ver al motor trabajando. Aunque queda mucho por hacer. En IA se han aclarado muchos conceptos. Las bases van quedando claras y la complejidad, también. Esta claro que hacer andar a un personaje y que no se vaya dando tortas con todas las paredes o se pierda en su cuarto de baño, no es trabajo trivial. Y mas, si queremos que tampoco parezca que se sabe el camino porque es un perrito piloto.

Aparecen nuevos problemas, como bien adelanta Victor, recordando esa obra maestra que es 'platero y yo'. Que buenos platos de carne asada me he tomado en el pueblo donde nació su ilustre escritor. Y todo porque a nuestro astrologo se le ha ocurrido que los personajes del juego se cansan si van andando de un sitio a otro. Así que a montarlos a caballo o en burro o en lo que sea...

Graficos y guión van avanzando bien. Los grafistas sacan tiempo de donde no tienen y estan realizando un trabajo magnifico. En breve veremos mas de su trabajo en la web. Nuevas incorporaciones se producen que esperemos que se queden un tiempo largo con nosotros.

Se han cambiado algunas cosas del guión que nos abren nuevos retos. Pero nos gustan los retos.
Si no nos gustaran, ahora no estarias leyendo esto.

Platero y yo

2005-12-16T08:42:00.000+01:00

¿Como manejar la animación de un personaje montado a caballo? Puede llegar a suponer un problema ya que se puede atacar desde muy diversos ángulos. El grafista necesitara modelar el personaje y el caballo a la vez por lo que habrán dos esqueletos diferentes en una misma escena. La librería de animación que usamos, cal3d, en principio soporta dos esqueletos pero son necesarios algunos retoques en el archivo final del modelo para poder indicar a que esqueleto pertenece cada malla de la escena.

¿Después como lo hacemos en el motor? ¿Tratamos al caballo y al personaje como dos objetos independientes en la escena o es mejor tratarlo como si de uno se tratara? Esta claro que la mejor opción es la segunda, porque no nos interesa luchar contra el problema que supondría el mantener el jinete montado por culpa del motor de físicas.

¿Y las colisiones? Una simple elipse no nos serviría para envolver al caballo y calcular las colisiones contra el entorno ya que dejaría demasiados huecos vacíos y deseamos que la envoltura de colisión se lo mas ajustada posible. Habrá que tirar de varios tipos de envolturas, una para el caballo y otra para el jinete como mínimo. Lo ideal seria una envoltura por cada pata del caballo además de la del cuerpo pero esto ya seria, tal vez, cargar demasiado el motor.

Sobre séptima edición de la CGAMES

2005-12-11T19:29:00.000+01:00

Buenas noches gente, llevo tiempo queriendo sacar un rato para escribir... perdonad el retraso.

Hace pocos días estuve en Angôuleme (Francia) y la verdad es que me quedé bastante sorprendido del esfuerzo que hacen las autoridades de aquella zona por conseguir asentar allí un poco de tejido de la industria multimedia.

Por un lado las autoridades han creado en Angôuleme lo que ellos llaman el Polo de la Imagen, que es una zona urbana en torno a la Avenida del Cognac donde dan facilidades para el asentamiento de empresas relacionadas con la producción de comics y materiales audiovisuales afines (como pueden ser los videojuegos).

El epicentro del Polo de la Imagen lo ocupa el Centre national de la Bande Dessinée et de l'Image (CNBDI), un edificio vanguardista construído sobre una antigua abadía en ruínas y que alberga entre otras cosas un museo dedicado al comic y un salón de actos ideal para la realización de conferencias y eventos similares.

El CNBDI es también sede de la Ecole Nacional de Jeu et Medias Interactifs Numériques (ENJMIN). La finalidad de esta escuela es impartir masters a titulados universitarios para que se formen en áreas concretas del desarrollo de videojuegos.

La escuela comenzó su andanza hace un año pero fue inaugurada oficialmente el 29 de Noviembre de este año, con la asistencia del ministro de cultura francés. Mi compañero de trabajo Francisco Gallego y yo asistimos a la inauguración en calidad de testigos casuales.

Durante el primer año de andanza del curso, los alumnos han trabajado bastante bien y el ambiente parece envidiable. Los responsables del centro dan a los alumnos un trato humano y personalizado que se traduce en un ambiente bastante propicio para la creación. Esta impresión la obtuvimos hablando directamente con los alumnos del centro.

Con motivo de los actos de inauguración de la ENJMIN tuvimos ocasión de ver algunos de los trabajos que habían realizado los alumnos y nos sorprendieron gratamente por su calidad y originalidad (y de verdad que no exagero).

Si comparo esta iniciativa con lo que yo he visto en la zona donde vivo (la costa de Alicante en España), tengo que decir que me llevo una decepción bastante grande con la actuación de los políticos de mi tierra.

En Francia hay gente lúcida que ve conveniente formar una pequeña industria para satisfacer una demanda creciente de materiales audiovisuales para el ocio y además se lleva la tesis a la práctica con éxito. En cambio, en mi tierra, yo sólo he visto fomentar la urbanización descontrolada y la cultura del pelotazo.

Coincidiendo con la inauguración de la ENJMIN se llevaron a cabo dos actividades que si bien eran independientes del CNBDI, tuvieron en aquel ambiente unas circunstancias muy propicias: la séptima edición de la conferencia Computer Games (CGAMES) y la también séptima edición del Internation Forum for Animation Technologies (FITA).

El verdadero objeto de nuestra presencia en Francia era precisamente asistir a la CGAMES, donde mi compañero y yo enviamos un par de contribuciones contando algunas cosas que venimos haciendo en el laboratorio de Informática Industrial e Inteligencia Artificial (I3A) de la Universidad de Alicante.

La asistencia a la CGAMES fue bastante productiva y nos valió para poder ver algunas cosas novedosas en el campo de los videojuegos.

Como comenta Nwanda, también es cierto que se coló algún fake en la sección de short papers, pero dejo como ejercicio para el lector el conseguir una copia de los proceedings y juzgar por sí mismo ;)

De forma breve puedo decir que la CGAMES es una conferencia interesante para la gente involucrada en la producción de videojuegos y que en ella tienen cabida cosas que otros sitios como la Game Developer Conference uno nunca esperaría encontrar.

Tampoco puedo hacer una comparación con la GDC porque nunca he asistido a ella, pero el espíritu de la CGAMES parece más orientada a la investigación y a las aplicaciones serias de los videojuegos que a la comercialización y distribución de productos finales.

Por poner un ejemplo, en esta edición aparte de artículos meramente técnicos sobre programación o diseño, hemos podido escuchar ideas interesantes sobre cómo aplicar los videojuegos en la educación.

En cambio no vino nadie a hablarnos de la última superproducción millonaria que desarrolla su ejército de programadores zombies, miembros del club de las cien horas (de trabajo semanales) :)

Prometí subir al blog mi contribución sobre render de terrenos porque era un tema que pensaba dar por finalizado antes de cambiarme a otra tarea pendiente en el trabajo, pero finalmente me han dado la orden de que no lo de por finalizado aún hasta que no lo complete y lo corrija para enviar un artículo extendido a otro lado.

Como tengo que ceñirme a unas normas de trabajo de nuestro grupo de investigación, os puedo decir que dejaré disponible una copia electrónica de la versión final extendida cuando haya sido enviada a su destino final... Seguro que en unas semanas haya alguna sorpresa por mi parte.

Espero que lo entendais y espero también seguir sacando tiempo de debajo de las piedras para poder dedicarlo a Utopía.

últimas noticias

2005-12-08T17:48:00.000+01:00

Estamos muy cerca de poder probar la primera demo del juego :-)
Será una demo muy simple, pero será también un paso muy importante dentro de nuestra andadura. De momento, va a ser en exclusiva una demo interna, que no pondremos a disposición de la gente en nuestra web. Pero en un futuro cercano, cuando añadamos más cosas, sí que la pondremos a dispocisión de la gente a través de nuestra página web. Samsaga2 es quien la está preparando, cuando se corrijan algunos pequeños problemas en los que estamos trabajando, la montará. Esperemos que antes de las fiestas que se aproximan ;-).
Nos ilusiona mucho a todos mover a Marcus y a Adrian dentro del escenario.

La sección de gráficos, la que más nos preocupa, sigue incrementando su ritmo de producción y dándonos alegrías. Aunque también algunas complicaciones, porque debido a una serie de cosas y causas que no vienen a cuento, algunos de los gráficos que hicimos tendremos que volver a hacerlos. Pero por suerte de una manera escasa aunque constante recibimos solicitudes de colaboradores que esperamos consigan integrarse en nuestro proyecto, y aportar su grano de arena para que terminemos de construir la montaña que será nuestro videojuego. Es un trabajo casi comparable al de una pirámide... un esfuerzo descomunal. Si cortamos bien los bloques, y los ordenamos y montamos debidamente, esperamos llegar a construir una pirámide tan sólida y duradera como las famosas pirámides egipcias.

Abel volvió de Francia. Tras estar unos días por allí, ver algunas presentaciones sobre otros trabajos de innovación sobre videojuegos, hacer la suya propia, regresó con nosotros.
Como me comentó él mismo, observó una cantidad de fakes enorme entre los proyectos presentados (es decir, proyectos falsos con conclusiones inventadas), y otros proyectos poco menos que curiosos, como el de una máquina para acariciar gallinas a distancia.

Como dice nuestro querido Luroc muchas veces en sus mensajes en la lista de correos:
Seguiremos informando.

Debugeando que es gerundio

2005-12-02T08:29:00.000+01:00

Seguro que mas de una vez habéis escuchado eso de que tirar de printf para hacer una sesión de debug es pura chapuza. No sólo puedo afirmar que es una falacia si no que además para demostrarlo Microsoft ha sacado una nueva herramienta en el Visual C++ 2005.

Si habéis observado bien hay un nuevo tipo de breakpoints: tracepoint. Ya no os hará falta ni tan siquiera tener que escribir el printf para averiguar que valor tenía esa variable en aquel trozo de código, sólo tenéis que añadir un tracepoint y Microsoft se encarga del resto.

Noviembre. Estado del proyecto.

2005-12-01T08:46:00.000+01:00

Se nos acabó noviembre y es el momento de repasar nuestro estado de proyecto.

Programación se acerca a cumplir varios de los objetivos marcados.
Se esta finalizando una parte del visor de modelos, quedando solo por pulir algunas cosas que el CAL3D no presenta claro, como la transición entre animaciones o el ejecutar en release. No nos rendimos. El TREN se ha ido a Francia. Estamos deseando tener noticias de el. El gestor de mapas se pasa a C#. Las nuevas tecnologías empujan fuerte y habrá que ir cambiando de lenguaje.
Pronto tendremos una versión demo de un nivel. Estamos deseando ver a Marcus pasear su garfio por algún nivel de prueba. Ya lo hemos visto días atrás, volar, pero creemos que no es lo apropiado para un pirata.

Gráficos ha resurgido con fuerza. Las nuevas incorporaciones están trabajando bien y los miembros antiguos no pierden las fuerzas. Adrián ya camina, que no es poco. Ya mismo tenemos iguanas y conejos pegando saltos por el nivel de pruebas. Y Marcus esta aprendiendo movimientos nuevos, que de apuntar y disparar no solo viven los piratas.

¿Qué decir de guión?. Se avecinan grandes cambios para nuestras historias. Cambios importantes, aunque alguien, en esa isla misteriosa, sigue esperando para demostrar todo su poder.

Y nuestra pagina UTOPIA, como muchas otras, esta en obras. Como la M-30. Solo decir que las fotos que ha puesto nuestro compañero Kanc, no son nuestras, excepto Tere, que es la unica chica del proyecto. A ver si se animan mas. Espero que pronto ponga nuestras verdaderas caricaturas o fotos. Pero sus contenidos seguirán creciendo. Al igual que Utopía.

Abel se nos va a Francia

2005-11-25T08:22:00.000+01:00

El domingo a las 7 de la mañana sale para allá. Pero no se va para siempre: si no le sucede algo que cambie redicalmente su vida volverá en un par de días.

Va a presentar su TREN en un congreso internacional sobre videojuegos en un lugar que prefierio omitir, bien por salvaguardar su seguridad, o bien porque no me acuerdo de dónde se celebraba el evento, o por ambas cosas... ;-)

Tras el congreso -dependiendo de cómo le vaya- decidirá qué licencia va a darle a su TREN, decidiendo principalmente si va a liberar el código, permitiendo que otros ayuden a desarrollar y mejorar el engine. También hará público un artículo que escribió con la ayuda de algunos de sus profesores sobre el TREN, con suerte lo haga hasta desde Francia.

Creo que hablo en nombre de todos al desearle MUCHA SUERTE en el congreso y en el viaje, y que por lo menos se lo pase muy bien esos días que va a estar en el país del vino y los 'croasanes'.

estamos vivos

2005-11-18T14:35:00.000+01:00

Algunos más vivos que otros, pero vivos.

Os comento los sucesos más significativos, las últimas noticias:

Podéis pasaros por nuestra web, que está de obras, adquiriendo un diseño completamente profesional ;-).

En la web iremos añadiendo más contenido. Ahora mismo si la visitáis podéis acceder al video promocional que hicimos para el último s2e, y también echarle un ojo a algunas imágenes más. Estamos planteándonos, a sugerencia de su autor, Aris, la posibilidad de subir su visor de modelos a la web para ponerlo a disposición del que lo quiera usar. El visor soportará muchos formatos bastante populares. Pensamos también sobre la posibilidad de liberar también el código.

Los nuevos grafistas se van integrando poco a poco, algunos más rápidos que otros, y van aportando su granito de arena junto al resto del equipo. También hemos fichado a un programador bastante prometedor :-)

Nuestra lista de correo sigue moviéndose a un ritmo frenético, de más de 100 correos a la semana; aparte de los que nos mandamos individualizados, y de nuestros contactos vía msn.

Javier nos dio un alegrón al pasarnos el código de su compilador de shaders, que es muy prometedor, y nos aseguró que intentará tener algo bueno operativo antes de final de mes; por lo menos para los ps 2 (pixel shaders 2, que no playstation2, xD). Ya está subido al servidor ;-).

Algunos pequeños problemas han hecho que samsaga2 tenga que retocar ahora el compilador de bsp. Seguro que consigue tenerlo listo en breve.

Para facilitar las cosas, vamos a hacer cambios en el guión, después de mucho meditarlo y mucho hablarlo. Queremos hacer un guión excelente, un guión que no tenga nada que envidiarle a los que escribía Billy Wilder para sus películas, que nuestro juego atrape a la gente, la enganche con la misma fuerza con la que la isla de Piedra atrae a los náufragos, y que los retenga en ella con la misma robustez con la que lo hace la misteriosa niebla que la envuelve.

Pronto, muy pronto, más noticias.

Moviendo personajes

2005-11-11T17:14:00.000+01:00

Uno piensa que el simple hecho de mover un personaje en el nivel es tan facil como actualizar sus coordenadas. Nada mas lejos de la realidad.

Cada vez que muevo un personaje tengo que volver a recolocarlo en el nivel pero intentando hacerlo de forma optima, no es cuestion de consumir ciclos de CPU cuando no hace falta.

Ademas el simple hecho de moverlo teniendo integrado un motor de fisicas es una odisea en si. Por ejemplo en Newton, que es el que estamos usando, algunas de las cosas que hay que controlar son:

* Asegurarme que no haya friccion entre el nivel y el personaje.
* Controlar en cada momento si el personaje esta pisando el suelo lanzando un rayo hacia los pies y calculando la distancia con el suelo.
* Si quiero moverlo hacia adelante tengo que obtener la matriz de posicion y rotacion del personaje, eliminarle el vector de posicion, multiplicarla por el vector de direccion en la que deseo moverlo y finalmente añadirle el vector resultante como una fuerza en el cuerpo que representa el personaje.
* Hay que intentar no pasarse al mover el personaje porque movimientos demasiado rapidos hacen que literalmente atraviese la pared sin inmutarse.

Adios a los viejos buenos tiempos de 'personaje.x = personaje.x + 10 * reloj'. Con lo bien que me lo pasaba yo moviendo la paleta para arriba y para abajo en el Pong.

Octubre. Estado del proyecto.

2005-11-02T21:12:00.000+01:00

Como todos los meses, comentaremos el estado del proyecto. Aunque estas revisiones pasarán a realizarse quincenalmente.

PROGRAMACIÓN:

Runtime:
Interiores BSP/PSV Octrees: Para la parte de carga de niveles al 95% del trabajo.
Exteriores: 80% del trabajo. El TREN esta operativo pero falta unirlo al nucleo del juego y controlar la compresión de los niveles.
Fisicas: En fase inicial de desarrollo. Al 10%. Queda un gran trabajo por adelantar. Estamos trabajando con Newton ya que ODE generó muchas dificultades.
Scripts. Usamos LUA. A un 60% del trabajo necesario.
Shaders: Al 40% del trabajo necesario.

Offtime:
Visor de modelos: Al 70% del trabajo. Mejorando la carga de animaciones. Usamos para las animaciones y modelos la libreria Cal3D.
Editor de niveles o mapas: al 20%. Esta montada la estructura basica con la la carga de mapas. Queda añadir todo el proceso de asignación de elementos en el mapa.
Editor de particulas: Al 10%. Las clases existen pero hay que remodelarlas para adaptarlas al motor y al sistema de scripts.

Esto es el trabajo que esta abierto. Las partes que no se comentan es porque en estos momentos estan detenidas o en fase de analisis.

GRAFICOS:

Los cuatro personajes principales estan diseñados. Tres estan modelados en alta. Uno esta pendiente de texturas. Queda por modelar otro personaje aunque se ha retrasado su modelado debido a cambios en su diseño.

Existen diseñados y modelados diversos personajes secundarios, niveles, objetos del entorno, etc. Aunque queda un gran trabajo por delante. Necesitamos grafistas en 2d, 3d y de niveles.

GUION:

El guión esta bastante avanzado. Se han definido cuatro tutoriales de inicio, cuatro zonas principales de juego divididas en varios niveles. En este momento, los tutoriales estan finalizados junto con la primera zona de juego. Tampoco podemos adelantar mucho ya que se revelaria parte del guión. :-)

WEB:

Se ha subido una versión basica de la web pendiente de mejoras esteticas. Seguiremos ampliando sus contenidos.

SONIDO:

Se ha empezado a trabajar en la elaboración del sonido, tanto musica ambiental como efectos.

Nuestro objetivo inmediato es el de presentar a primeros de año una demo con el primer nivel tutorial del juego.

Como podeis ver tenemos mucho trabajo por delante pero contamos con un buen equipo con muchas ganas de continuar con este proyecto que sigue siendo una Utopia.

Saludos.

Nos encantan las criticas :)

2005-10-27T10:09:00.000+02:00

Se ha abierto un hilo en el foro de Stratos bastante interesante con criticas (bien merecidas creo yo) sobre si el proyecto Utopia es viable o no.

No voy a reponder que de aqui saldra un juego por mis cojones porque seria un gilipollez (perdon por los tacos) asi que intentaremos ir respondiendo las dudas una por una.

Copio y pego una pequeña reflexion en respuesta a las dudas de ses y otros foreros stratoperos:

Es normal que la gente tenga prejuicios con el proyecto Utopia y se que algunos sospechais que esto comienza a ser vaporware. Nos estamos tomando muy seriamente el proyecto, nuestro objetivo es hacer algo real y de la forma mas profesional posible. Estamos limitados por nuestro tiempo, pues todos tenemos nuestro trabajo y al poco tiempo libre que tenemos le restamos horas que dedicamos al proyecto. Puede que no seamos los numeros uno del mundo mundial, que nuestro motor no acabe superando al del Half-Life 2 pero prometemos una oportunidad a todo aquel que quiera participar y formar parte de un proyecto interesante y del que esperamos poder estrujar todo nuestro potencial.

¿Cuantos de vosotros teneis proyectos personales que acaban abandonados por una falta de interes? Nosotros radiamos ganas a raudales :) y creemos que tenemos el potencial suficiente como para llevar el barco a buen puerto.

El pasado pasado esta, y hemos ido aprendiendo (y mucho) de nuestros errores.

Más Guantis

2005-10-26T09:24:00.000+02:00

No sólo programadores, también necesitamos incorporar grafistas. Al menos un animador que domine el 3dsmax, y un texturizador ducho en el mismo software. Los grafistas interesados en unirse a nuestro Proyecto, por favor escríbanme sin miedo a: nwanda@stratos-ad.com

WANTED

2005-10-25T09:35:00.000+02:00

Como ya habreis visto si os habeis pasado por Stratos estamos en proceso de ampliación del grupo. Creemos que estamos en el momento idoneo para que el proyecto reciba un empujón gracias a sangre nueva.

Perfil que se necesita: Programador de IA.

Programador de IA. Con conocimientos de IA de juegos, y metodologías prácticas para aplicar la IA en el juego. Trabajamos con el lenguaje de programación C++ orientado a objetos, y el lenguaje de scripting que tenemos integrado en nuestro engine es el LUA.

Perfil que se necesita: Programador de físicas

Con conocimientos de programación de física en general. Y preferiblemente con nociones de motores de física en particular, como el ODE o el Newtonphysics, y sea capaz de integrar esos motores con nuestro engine, e incluso modificar los mencionados motores para ajustarlos a nuestras necesidades. Estamos trabajando con C++ orientado a objetos.

Interesados podeis escribirme a samsaga2@gmail.com. Se valorará mucho que presenteis código fuente de proyectos realizados (no importa que estén sin acabar).

La web del proyecto

2005-10-22T01:10:00.000+02:00

Por fin tenemos nuestra web publicada. Estamos en obras. Así que no seas muy critico con nosotros.
Pero puedes ver algo de nuestra historia, quienes somos o quienes pasaron por nuestro proyecto en: http://www.stratos-ad.com/utopia/

Adrian Wilson

2005-10-14T20:23:00.000+02:00

Como la web se está retrasando mucho más de lo que esperábamos, ahí va una imagen de otro de los protas del juego, nuestro piloto de SpitFires y destacado miembro de la RAF Adrian Wilson.

Objetos en LUA

2005-10-11T10:36:00.000+02:00

Me he vuelto majara buscando la forma en que se crean los objetos en el lenguaje de script LUA. El problema ha sido la gran cantidad de informacion antigua que circula por la red.

Para cualquier persona interesada un pequeño ejemplo autoexplicativo:

function Vector()
  return {
    x = 0,
    y = 0,
    print = function(self)
      print(self.x)
      print(self.y)
    end
  }
end

v = Vector()
v:print()

¿Facil no? Pues intentad buscar lua objects en el google y vereis como no lo es tanto ;-).

Offtime. Herramientas propias.

2005-10-10T11:35:00.000+02:00

El trabajo en un videojuego se puede dividir en dos líneas muy claras, el videojuego, propiamente dicho, y las herramientas que han permitido elaborarlo. A algunos, a estas partes les gusta llamarlas el Runtime y el Offtime.

Hablemos un poco del Offtime. O del trabajo que no se ve. Que esta por debajo del resultado final. Y hagamos un comentario breve sobre el editor o diseñador de niveles. Juegos de gran nivel, en la mayoría de las ocasiones, van acompañados de estos programas que nos permiten modificar o añadir el entorno donde transcurre el juego. Algunos son tan conocidos como el mismo videojuego para el que se elaboraron. Otro día hablaremos sobre esto.

Otras herramientas no se llegan a conocer pero tienen un uso tan importante como el diseñador de niveles. Herramientas que comprueban la música y el sonido del juego, estudios de físicas, visor de modelos y animaciones, control de texturas, etc, etc.

En nuestro proyecto, usamos la librería Cal3D, como ya hemos comentado. Aunque la exportación de los modelos desde el programa de modelado es muy efectiva, es necesario comprobar si el modelo se ha exportado correctamente. Hay que revisar si la animación, los materiales y texturas se aplican como es debido.

Para comprobar eso, lo mejor es usar un programa que nos muestre previamente el resultado de esa exportación. Y que nos permita hacer diversas pruebas para comprobar que todo esta correcto. Aquí os muestro una imagen del visor de modelos que estamos preparando. Todavía le faltan algunas opciones importantes, pero ya permite ver los resultados de una exportación.

Software libre

2005-10-05T10:34:00.000+02:00

Asusta la cantidad de software libre que se usa hoy en dia en el desarrollo de juegos. Sin ir mas lejos en nuestro proyecto usamos:

- Cal3d para las animaciones por bones de los personajes
- Blender para algunas pruebas 3d
- Lua como lenguaje de scripting
- ODE para el motor de fisicas

Echadele un vistazo a la cantidad de proyectos profesionales que hechan mano de LUA (Escape from Monkey Island por ejemplo) o de ODE (SoftImage XSI).

¿Os imaginais la cantidad de tiempo que seria necesario si no existieran estos proyectos? Sobretodo con el motor de fisicas que es, de lejos, la parte mas compilcada de implementar.

Marcus Smith

2005-10-03T17:22:00.000+02:00

Un poco como anticipo a la Web que vamos a sacar en breve, una imagen del modelo Low-Poly de Marcus Smith, uno de los protagonistas del juego. Esta junto a otras imágenes se podrán ver en la Web, además de algunas cosillas más.
Esperamos que os guste nuestro pirata.

Libreria Cal3d

2005-09-29T13:03:00.000+02:00

En nuestro proyecto, decidimos usar la librería Cal3D para la carga y control de animaciones de los personajes de nuestro videojuego. Veamos brevemente que nos ofrece.

Las características mas importantes de esta librería las podemos resumir en dos:

- Permite asociar diferentes animaciones a una malla.

- Tiene diversos exportadores de ficheros para los programas de modelado mas importantes como Maya o 3DMax. El numero de exportadores se va ampliando para incluir otros de uso generalizado como el Blender.

Cal3D ha establecido una serie de ficheros que forman la estructura básica de todo personaje a animar. Así, cada modelo esta compuesto por los ficheros siguientes:

- Skeleton. El esqueleto de la figura. La base jerárquica de la animación.

- Malla del modelo.

- Ficheros de animaciones. Cada uno contiene un ciclo completo de animación.

- Materiales. Se pueden tener diversos ficheros de materiales para la iluminación del modelo y sus texturas.

Estos ficheros se forman a partir de un modelo y animación realizado con nuestro programa de modelado favorito, para después, exportar cada uno de los ficheros necesarios.

Este tipo de formato ahorra bastante tiempo a los modeladores, ya que permite usar la misma malla y su esqueleto para las diferentes animaciones que se vayan a usar en el juego. Y en programación el trabajo ahorrado es descomunal ya que con unas pocas funciones es muy sencillo usar las diferentes animaciones, realizando transiciones suaves entre cada una de ellas.

Hablemos de las animaciones. Cal3D define dos tipos de animación: Ciclos y Acciones.

Los ciclos son animaciones, que como bien indica el nombre, repetimos en un bucle. Un ejemplo de animación de este tipo puede ser la de andar de un personaje.

Las acciones, son animaciones que ejecutamos en un instante dado. Por ejemplo, nuestro personaje va andando y en un momento dado, da un salto.

Hay que resaltar que cualquier animación puede ser tratada como ciclo o como acción, diferenciándose solamente por el tipo de función usada para procesar la animación.

Para tratar una animación como ciclo usaremos dos funciones:

BlendCycle() y clearCycle().

BlendCycle() ajusta el peso de una animación en una cantidad de tiempo determinada. La función tiene tres argumentos:

- Identificador de la animación.

- Peso de la animación.

- Tiempo de transición.

Estos valores se usan para asignar una transición con suavidad entre dos ciclos (animaciones) diferentes.

Para las acciones usaremos la función executeAction(). Tiene tres parámetros:

- identificador de la animación.

- Tiempo de transición inicial.

- Tiempo de transición final.

Las acciones se ejecutan automáticamente.

No debemos olvidar el control del tiempo. Para que la animación se presente con suavidad, el control del tiempo se ha de realizar en un proceso cíclico. Esto envuelve evaluar el tiempo en cada momento y los valores de transición para la animación que esta activa en cada momento. Esto se realiza mediante la función update(). Solo acepta un argumento que son los segundos transcurridos desde la ultima llamada a la función.

Veamos un pequeño ejemplo de código:

void CvisorModelosUtopiaView::actualizar(int idAnimacionUso)

{

float elapsedSeconds;

elapsedSeconds = (float)(GetTickCount() - m_lastTick) / 1000.0f;

if(!ejecutaAccion)

{

m_calModel->getMixer()->blendCycle(idAnimacionUso, 1.0f, 0.0f);

}

else
// Se ejecuta como accion la animación elegida.

{

m_calModel->getMixer()->executeAction(idAnimacionUso, 1.0f, 1.0f);

ejecutaAccion=false;

idAnimacion=idAnimacionCiclo;

}

m_calModel->update(elapsedSeconds);

m_lastTick = GetTickCount();

}

En este ejemplo, la función actualizar() recibe el identificador de la animación a procesar. Si el valor de la variable ejecutaAccion es verdadero se ejecutará la animación como una acción. Si es falso se ejecutará como un ciclo.

En breve seguiremos comentando mas posibilidades de esta librería.

Las dificultades de ver una caja rebotando

2005-09-29T08:17:00.000+02:00

Una de las últimas grandes incorporaciones al mundo de los videojuegos en 3d es la física realística. Nadie en su sano juicio comenzaría a día de hoy un motor de físicas desde cero si quiere ver un producto acabado antes de tres o cuatro años, es realmente algo complicado. A día de hoy hay dos grandes pesos pesados Havok y ODE. Havok es un producto comercial de gran calidad, y creo que puedo decir sin caer en la exageración que es el rey, el uso en productos como Half Life 2 o Painkiller así lo demuestra. ODE, en cambio, es lo que se llama la alternativa, un producto OpenSource de calidad consolidada y usado en gran variedad de productos comerciales. Puede que Havok sea de una calidad superior pero no os podéis ni imaginar la gran ayuda que supone el poder disponer del código fuente, desde resolucion de problemas via debugger (puedo saber exactamente en que línia del motor peta el programa y así averiguar en que estoy fallando) a averiguar en que forma trabaja para asegurarme que lo estoy exprimiendo al máximo.

[BSP/PVS] Capitulo 1. Vectores

2005-09-21T10:34:00.000+02:00

Imagino que los que estáis leyendo esto ya conoceréis bastante bien como funcionan los vectores. Lo que realmente me interesa es que tengáis claro al 100% el Dot product y el Cross product que serán una de nuestras herramientas básicas a la hora de construir el árbol BSP. No me pondré a explicar las otras operaciones. Los que estén interesados en una explicación mas detallada de los vectores pueden visitar la página web Vector Math for 3D Computer Graphics.

Dot product

El Dot product entre dos vectores u y v es:

u · v = |u| |v| cos θ

O dicho de otra forma:

cos θ = u.x * v.x + u.y * v.y + u.z * v.z estando u y v normalizados.

Donde |u| y |v| se refiere a los vectores normalizados (su longuitud es 1) y θ a el ángulo entre los vectores u y v. Si tenemos los dos vectores normalizados podemos extraer el ángulo más fácilmente, es por esta razón que normalmente en los motores gráficos siempre trabajan de esta forma.

Nos será enormemente útil sobretodo en los cálculos con planos.

Cross product

El cross product o producto cruzado es un vector w perpendicular a los otros dos vectores u y v (u x v):

w.x = u.y * v.z - u.z * v.y
w.y = u.z * v.x - u.x * v.z
w.z = u.x * v.y - u.y * v.x

El nuevo vector forma un ángulo recto (de 90º) con los vectores u y v. Seguramente habreis oido hablar sobre la regla de los dedos; si formais un angulo recto con el dedo gordo (el vector u) y el indice (el vector v) formando una L y estirais el corazón hacia adelante (el vector w) tendreis una idea de como funciona esta fórmula.

Una de sus utilidades es la de calcular la normal de un polígono. Imaginad que tenéis un triangulo con tres vértices P1, P2 y P3. A partir de los vértices del triangulo podemos obtener dos vectores uno que va desde P2 a P1 y otro desde P3 a P1:

u = P2 - P1
v = P3 - P1

Ahora con los vectores u y v nos es fácil encontrar la normal haciendo:

normal = u x v

Proximamente...

Con estas dos formulas nos será mucho mas fácil comprender como extraer los planos de los polígonos y en otro futuro capítulo como cortar polígonos.

Esas tediosas esperas

2005-09-19T11:53:00.000+02:00

Una de las cosas que vamos a intentar evitar son esas esperas aburridas a la hora de cargar los niveles. Considero que los ordenadores de hoy tienen suficientes recursos como para cargar los recursos de forma instantanea o, mejor dicho, hacer creer al usuario que la carga es instantanea.

Nuestro modulo de recursos posee un hilo de ejecucion aparte con el que podremos hacer, por poner un ejemplo, que al acercarse el jugador a un area del mapa se vayan cargando los modelos de nuevos enemigos consiguiendo evitar que aparezca una horrible pantalla con el texto de Loading...

estado del proyecto

2005-09-18T23:18:00.000+02:00

En la actualidad estamos trabajando como condenados para tener el engine plenamente operativo. Estamos pendientes de integrar el motor de terrenos TREN con el engine, junto al motor de interiores que está operativo funcionando con bsp / pvs y con octrees gracias al gran trabajo de samsaga2. En el debe tenemos también la tarea de integrar el ODE (), pues hemos decidido finalmente usar ese motor de físicas, ya que es bastante potente, en lugar de programarlo nosotros. El Cal3d, que es el exportador que vamos a usar, nos estaba dando algunos ligeros problemillas que vamos a tratar de resolver usando el visor de modelos que Aris ha preparado.
En lo que respecta al resto, el trabajo de los grafistas se nos antoja demasiado lento, pero poco a poco van entregando algún material con el que se van haciendo pruebas, y además algunos modelos de personajes, armas, y otras cosas que serán definitivos. En el debe tenemos la tarea de mejorar el ritmo de trabajo en el apartado de gráficos.
Y por último, en lo que se refiere a guión (que es la parte que más me toca) se avanza más lentamente de lo que me gustaría (mea culpa) pero se va un pasito por delante, suficiente para ir suministrando trabajo a las demás áreas.

Por cierto, que aunque todavía no lo haya dicho, aquí estoy utilizando un nick distinto al que utilizo en el proyecto. Puede que más de uno de los miembros del proyecto se haya preguntado quién cojones será el Astrólogo, pues dentro del grupo todos me conocen como Nwanda. En realidad debo confesar, y confieso, que tengo muchos nicks distintos; empleo cada uno de ellos para denominar a cada una de mis distintas personalidades (que son muchas más de las aconsejable; a algunas las tengo controladillas con los medicamentos, pero otras son más durillas y se dejan caer de cuando en cuando)

Grupos de desarrolladores de videojuegos

2005-09-15T08:35:00.000+02:00

Si siempre habeis querido formar parte de un grupo de gente con clara intencion de desarrollar algun que otro videojuego esta es vuestra pagina. Aun es relativamente nueva y hay poca gente apuntada pero todo es cuestion de tiempo.

TREN

2005-09-14T15:49:00.000+02:00

A la izquierda acabo de enlazar TREN. Pinchen y accederán a nuestro engine de terrenos, algo programado por Abel.

Abel me ha pedido también que ponga un enlace a su espacio personal. En breve él hará un post resumiendo un artículo que está escribiendo, y ofreciendo un enlace para descargar el artículo.

Tutorial sobre arboles BSP/PVS

2005-09-14T14:52:00.000+02:00

Voy a comenzar una serie de posts a modo de introduccion sobre el complejo tema de los arboles BSP/PVS. Voy a evitar a toda costa introducir codigo (que no pseudocodigo) para que vosotros tambien tengais que trabajar un poco. Ire leyendo los comentarios que me dejeis para intentar resolveros cualquier duda.

El temario sera mas o menos este (por orden de aparicion y sujeto a cambios):

[BSP/PVS] Introduccion
[Mates] Vectores
[Mates] Planos
[Mates] Poligonos
[BSP/PVS] Fabricacion de un BSP simple
[BSP/PVS] BSP Leafy
[Portales] Creacion de portales a partir de un arbol BSP
[BSP/PVS] Y la traca final... PVS

A pesar de lo que hayais leido por ahi no es ni mucho menos tan complejo como os quieren hacer creer. Con que os concentreis un poco en seguir la mecanica basica lo entendereis enseguida.

Quién espera a quién?

2005-09-14T14:03:00.000+02:00

Esa es la pregunta. ¿Gráficos espera a programación? ¿O es al revés?.
Podríamos decir que depende del punto de vista.

Si la opinión nos la da un grafista-modelador-animador, seguro que nos dirá que él prefiere esperar a los programadores. El trabajo de modelar la figura, su animación, las texturas, se deberán realizar según se vaya a usar el modelo. No es lo mismo usar un modelo en una animación que usar un modelo que se incluirá en el motor del juego. A nadie le gusta trabajar sobre un modelo o una animación y que luego le digan que tiene que reducir los polígonos a la mitad o que la animación tiene demasiados frames para el motor del juego.

El programador nos dirá que necesita muchos modelos para trabajar sobre el motor. Muchos ejemplos. Muchas pruebas. Y es verdad. El motor del juego podría ir muy bien moviendo determinado personaje pero con otros, se descubrirá que la animación no se presenta correctamente o que las texturas no se aplican bien.

De todo esto se deduce que es necesario buscar un punto de equilibrio. Y la experiencia nos enseña que en todos los juegos se desechan una gran cantidad de bocetos, modelos, imágenes y texturas.
Como también se busca un limite a la programación del motor y se desechan muchas características.

Puede parecer una tontería pero seguro que muchos grafistas y muchos programadores recordarán horas de trabajo perdido por no tener esto en cuenta.

¿Cómo solucionarlo?

Pues aceptando que parte de nuestro trabajo no se podrá usar en el juego y manteniendo una buena comunicación entre las dos partes para que ese trabajo perdido sea el mínimo

Seguiremos contando...

Indie

2005-09-14T08:21:00.000+02:00

Indie es un termino americano muy usado en peliculas independientes. Denota que detras de una produccion no hay un gran empresa si no un grupo de gente motivada con ganas de hacer algo con la maxima calidad posible. Tambien es aplicable a videojuegos y, creedme, hay una gran variedad de juegos indie. Lo podeis comprobar vosotros mismos.

logo y mascota del proyecto

2005-09-13T19:29:00.000+02:00

Os adjuntamos una imagen del logo y la mascota del proyecto. Esperamos que os gusten, ;o)

página web del proyecto en preparación

2005-09-13T13:38:00.000+02:00

Puede que el que lea esto se sienta bastante confuso y no sepa de lo que estamos hablando. Pero pronto esperamos contar con una página web pública del proyecto en la que seguramente aclaremos un poco más quiénes somos y de qué estamos hablando.
Hablaremos un poco en ella de nuestra historia y del juego que queremos hacer. Anunciamos ya que para principios o mediados del año que viene esperamos tener cosas en tiempo real funcionando.

Juegos de tablero

2005-09-13T09:32:00.000+02:00

Me gusta programar en C pero algunos van demasiado lejos.

encuentro en sevilla

2005-09-12T17:50:00.000+02:00

El viernes algunos miembros del equipo nos vimos en persona por primera vez, después de muchos contactos vía mail y msn.
Los primeros en llegar fuimos Alejo y yo. No nos habíamos visto en nuestras vidas. No sabíamos cómo éramos físicamente, porque no habíamos tenido siquiera la preocupación de mandarnos una fotografía. Nos cruzamos un par de veces, mirándonos llenos de dudas, sin atrevernos a preguntar a un rostro sin nombre si era de Utopia. ¿Será o no será? Finalmente él se volvió a cruzar conmigo, se puso en una esquina cercana, y llamó a mi móvil. Yo lo observaba mientras lo hacía, y no hizo falta más que un toque para ponerme en movimiento hacia él.
Después llegó Aris, que sin ninguna vacilación fue directo a nosotros y se presentó. Y un poco más tarde comiendo se nos unieron Kanc, Tere y otro conocido de Aris.
Estuvo bien, y aunque no hablamos mucho sobre el proyecto, sí que sirvió como base para establecer un contacto más estrecho.