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.

#· 02 Sep 2005

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.

#· 31 Aug 2005

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 :)

#· 24 Aug 2005

Código fuente del quake3 liberado

Después de creer que ID lo sacaría estas navidades, ahora lo hacen público una semana después de que anunciaran que lo sacarían en breve. Un 10 para ID, no solo por sacar el código del quake3, si no por todos los anteriores: quake2, quake, doom, hexen y una larga lista. Muchas de las cosas que sé yo ahora de programación las aprendí leyendo el código del quake2.

Por último un paste de lo que han “soltado”:

# Quake III Arena source code ( renderer, game code, OS layer etc. )
# bot routes compiler source code
# the retargetable C compiler ( produces assembly to be turned into qvm bytecode by q3asm )
# assembly to qvm bytecode compiler
# map compiler ( .map -> .bsp ) - this is the version that comes with Q3Radiant 200f
# Q3Radiant map editor build 200f ( common/ and libs/ are support dirs for radiant )

#· 20 Aug 2005

VIM

Actualmente uso GVIM para programar en python y no tengo demasiados problemas. Calculo que usaré un 2% de todo lo que VIM da, más que nada por la pereza que me da leer la documentación. Sin embargo hoy me ha dado por buscar info debido a que empiezo a tener una cantidad alta de ficheros y bastantes líneas en cada uno (unas 1500 aprox). Después de hacer unas búsquedas en google terminé por ir a la página oficial y echar un vistazillo. La página no es nada del otro mundo en cuanto a aspecto visual, como todas las de los grandes, sin embargo mirando un poco encuentras cosas muy interesantes.

Entre los miles de pluggins que hay he encontrado 3 bastante interesantes:
- taglist: permite tener una ventana en un lateral con las funciones, clases, etc de código en C,C++ y lo más importante para mi, python. Me ha sorprendido gratamente y me está resultando muy útil.

- minibufexpl: Es un complemento perfecto para el anterior ya que añade una ventana con los buffers que tenemos abiertos. Se pueden abrir todos los ficheros e ir navegando de uno a otro. Lo mejor de todo es que el pluggin anterior se va actualizando con los tags del fichero activo, un verdadero lujo.

- python: El nombre lo dice todo, permite identar código, ir de clase en clase, etc. No lo he sacado mucho partido, pero promete.

A la página oficial hay una lista enorme de pluggins, seguro que me quedan sorpresas por descubrir.

#· 16 Aug 2005

Older posts

Newer posts