Más Blender

Lo que tiene el estar pillado de tiempo es que no lo pierdes en crear código o herramientas que no usarás. En el juego que estamos preparando tiene un contenido de física bastante importante y para ahorrar unos cuantos ciclos de máquina hacemos por separado los escenarios (malla, texturas) y su modelo físico.

Como tengo cierta experiencia con blender, decidí crear un exportador para agilizar las cosas, así no tenía que ajustar los modelos físicos por código (un rollo). Busqué cosas que tenía hechas de un exporter que hice para un raytracer, hice unos cambios y solucionado. Como además los escenarios tendrán partes móviles y objetos por ahí, decidí también exportar animación y posiciones de “otros objetos”. Todo esto es exportado a un fichero del tipo ini de windows, tenía pensado hacerlo a binario serializando los datos, pero era más cómodo para editar (si sabes interpretar matrices 4x4 XD).

Qué mejor que una imagen para ilustrar el proceso.

A la derecha se tiene el modelo físico (que se ha adaptado en base a la malla del escenario), a la derecha arriba la curva de animación de un objeto, en concreto un cubo que se ve en la parte superior de la vista 3D que va de un lado a otro y por último la ventana del script de exportación.

Lo mejor del proceso es que después hay un script del nivel que permite hacer todo lo que se quiera, desde meter nuevos objetos, crear sistemas de partículas… sería simplísimo crear un juego de plataformas con esto, pero ese tema ya lo comentaré otro día…, incluso podreis toquetear, incluso los usuarios de linux… e incluso los de maxos XDD

Blender rocks :)

resultados de summer of code

Después del todo el verano las pelas de google dan sus frutos. Blender estaba dentro del programa y sacó en su día unos cuantos proyectos a realizar, de los cuales aprobó los de este enlace. Mirando un poco por encima he encontrado algunas cosas a destacar, la primera un simulador de fluídos (que tanto ansiaban los grafos que usan blender) que parece que da unos buenos resultados. Otro que me ha llamado la atención ha sido, por su simplicidad, un pluggin para creación de texturas hecho con python. Blender ya tenía un interface implementable en C para la creación de texturas, pero un lenguaje de script resulta desde luego mucho más cómodo, aunque seguro que mucho más lento. Por útlimo, mirando un proyecto para la integración de ODE en blender me he quedado asombrado con el currículum del que lo ha llevado a cabo. Al final del txt hay un pequeño resumen de su vida y destaco las certificaciones de física que tiene el pavo, en mi vida había oído hablar de algo así :(.

En mi opinión Blender debería ir por el camino de la simplicidad, de mejorar lo que tiene en vez de añadir más, de hacer intuítivo el interface, que son las asignaturas pendientes. A pesar de ello yo sigo usando blender para hacer las 4 gilipolleces de siempre :)

Algoritmos para juegos

En el juego que estoy preparando para art futura me encuentro con algunos problemas, unos derivados de la propia dinámica del juego y otros en los que me meto yo solito, sin ayuda ni nada ¿eh?.

El primero de mis problemas es el de la cámara. El juego es de lucha, no es la lucha convencional, pero es lucha, y como lucha necesita de almenos un par de entidades dándose cera. Hay momentos en los que las entidades se separan en el escenario y lógicamente la cámara no puede perder de vista a ninguna de ellas. Como me decían un gran porcentaje de profesores durante mi etapa académica todo está inventado, y tratando de ser un buen alumno he pensado en que juego de los que he jugado en mi larga vida de friki juegalo-todo. Dándole vueltas he recordado el tekken, algún mortal kombat, uno que tenía “espada” en su nombre que salió por aquellos maravillosos años de PSX (sí, la “uno”)… pero qué mejor ejemplo que una obra maestra de la jugabilidad como el mario 64?. Hay momentos en los que mario se enfrenta a bichos enormes en unos rings improvisados, en la lava, en el suelo o en lo alto de una montaña. Ni corto ni perezoso he arrancado mi emulador, mi rom del mario 64 (tengo que decir que tengo la N64 y el juego original, no incurro en ningún delito ni falta, nisiquiera moral XD) y me he ido a una de las primeras pantallas donde te das bien de cera con una gran bola explosiva, me he dado caña con él y lo he grabado todo en video para anañizar los movimientos de la cámara en función de la posición de los dos, mario y la pelota gorda.

El algoritmo es bastante simple, busca el punto medio entre las dos entidades y aleja o acerca la cámara una cantidad proporcinal a la distancia, siempre y cuando los dos elementos estén en pantalla, jústamente lo que había pensado. Un buen planteamiento de la cámara sería mirar el frustrum, esto es, el espacio de visión de la ésta y calcular la distancia justa para que las entidades estuvieran en pantalla, pero haciendo algunas pruebas, basta con poner una constante a ojo y funciona muy bien :)
El código, simple y claro XD:
p1 = vec3(self._target1Pos.getPos()) ;
p2 = vec3(self._target2Pos.getPos());
diff = p2-p1;
dir = (self._pos.getPos() - vec3(self._target) ).normalize()
self._target = p1+ 0.5*diff;
sep = 4 + 2*diff.length();
self._target = p1 +0.5*(p2-p1);
pos = self._target + dir*sep;

El segundo “fregao” en el que me he metido ha sido en el de la repeticion de las mejores jugadas. Para ello puse un post en stratos para ver cómo se las ingeniaba la gente para guardar replays. Mi idea era la de guardar los valores de las pulsaciones de teclado, idea que pensando un poco es ciertamente descabellada, pero que después de implementarlo no ha funcionado tan mal en mi PC, posiblemente a causa de la regularidad del tiempo de frame. Hasta el mismo Jare ha respondido aportando una información cuanto menos interesante.

Hasta aquí la pollada del día, a seguir codeando.

Mi escritorio hoy

Este es mi escritorio a día de hoy. Se pueden ver algunos ficheros .py abiertos con gvim (y algún pluggin que comenté en otro post), el típico PDF de documentación - en este caso de ode -, carpetas de código y, como no, un par de líneas de comandos verde sobre negro :). Ah! y el winamp con un buena recopilación de música. El escritorio no tiene nada de espectacular, la única peculiaridad es que tengo la barra a la derecha porque es mucho más cómodo para mi teniendo pantalla panorámica.

links

En estos días de coding intensivo he encontrado unos buenos links que he ido viendo en barrapunto, pythonhispano, stratos, escena.org y algunos sitios más.

-scripting para juegos: un artículo muy buena acerca de la implementación de un sistema de scripting bastado en una implementación de python en la que puedes usar threads que no usan el modelo habitual. El artículo explica un modelo muy similar al que usar el unreal engine.

generación de mesh para intros 64kb: iq de RGBA explica la técnica usada en la intro que presentaron en la última euskal. Muy interesante, aunque dice cosas que si has leído un poco ya se sabían.

-GLEST tiene su primier MOD: Después de la salida de glest, su port a linux, ahora hay gente haciendo un MOD, qué será lo siguiente? :).

-flipcode muere: Después de 6 años de una excelente web de programación de juegos cierra sus puertas. Una pena :(.

-un par de juegos interesantes que vi en un -inusualmente interesante- post de barrapunto. En el post hay otros juegos interesantísimos, amateur al poder.

- google talk: Después de unos meses de rumoes google lanza su cliente de MI. Como se rumoreaba usa jabber y permite charlas mediante voIP, que por cierto he probado hoy y me han sorprendido gratamente por dos razones: la primera es la calidad que se consigue con una conexiónde 512kbps con emule y la segunda por que he encontrado una utilidad al micro que hay encima de la pantalla del portátil, un lujo :)