Ayer leyendo barrapunto, cosa que por cierto cada vez hago menos, estoy hasta las napias de leer críticas destructivas a todos tipo de información, pero bueno, vi una noticia interesante "Empresas de videojuegos en España". No me quedó más remedio, después de leer el artículo al que apuntaba de 20 minutos y los comentarios _desinformados_ del person, que escribir este comentario que he remodelado un poco y que he enviado a la redactora de la noticia en 20 minutos.
"Me alegra muchísimo que se trate el tema de los videjuegos en la sección, pero me gustaría aportarle un poco más de información que seguro le resultará útil para futuros artículos.
En el mundo de los videojuegos, además de las superproducciones de empresas como Pyro y SGA, existen otros mercados, como es el de las revistas, ventas por internet, distribuciones a nivel nacional,etc que dan beneficios a un montón de empresas.
Estas fechas son muy buenas para hablar de videojuegos, porque en menos de un mes tenemos artfutura ( www.artfutura.org ) y precisamente en ella hay un concurso de videojuegos. Bien, según cifras oficiales (http://www.stratos-ad.com/forums/index.php?act=ST &f=39&t=5321), hay unos 50/60 juegos presentados y la gran mayoría de los que se han visto en stratos (web por excelencia del desarrollo hispano de videojuegos) son de una calidad más que aceptable. Me arriesgaría a decir que algunos poodría comercializarse con muy poco trabajo. Ah! y recordemos que son proyectos sin una fuerte inversión, sólamente la de unos chavales(!) con ganas.
Pero no quiero quedarme en enumerar una serie de proyectos que puedan parecer amateur, en España tenemos muchísimas más empresas de videojuegos facturando , además de la archiconocida Pyro, que paso a enumerar (fuente: http://www.stratos-ad.com/forums/index.php?act=ST&f=7&t=5337 ): Arvirago, Legend, Exelweiss, Ubi Studios, Digital Legends, Novarama, Gameloft, Microjocs, Revistronic, Mercury Steam, Virtual Toys, Gaelco, Tragnarion, Nebula, FX Interactive. 16 empresas, cuando hace 5 años había 2, está bien no?.
Y voy aún más lejos, existe un mercado, muy poco conocido en España, de juegos casuales, esto es, juegos de corto desarrollo, de muy alta jugabilidad y diversión que hacen furor en países cono Estados Unidos o Inglaterra y que tienen un mercado floreciente. En España tenemos también gente trabajando en esa línea, sacando al mercado juegos interesantísimos como son "the cursed wheel" (funmangames, www.funmangames.com ) o breakout (nurium games, http://www.nurium.com/ ) todo un éxito de ventas.
Un saludo"
9.29.2005
9.28.2005
Desarrollo de Makefight (I)
Bueno, en este post y los que le siguen voy a comentar los aspectos más destacados del desarrollo de MakeFight. Supongo que muchos de los que lean esto no sabrán qué es. MakeFight es un juego desarrollado por devilishgames y un servidor para presentarlo en el concurso de videojuegos de art futura 05.
.Los Comienzos.
Allá por junio de este año, medio en broma medio en serio, zwitter, miembro del núcleo de devilishgames me propuso hacer un juego que tenía en mente. Como no podía ser de otra forma acepté el reto, sabiendo que yo nunca había creado un juego y el tiro podía salir por la culata. En cuanto le dije que sí, zwitter se puso manos a la obra con el concepto.
.El concepto.
El concepto es simple, la creación de un juego de peleas de coches construídos por el usuario. La idea me parecía interesantísima, incluso alguna vez se me había pasado por la cabeza realizar algo así. Enseguida empecé a pensar en qué herramientas usar, cómo enfocarlo, etc, etc. No tardé mucho en darme cuenta que el desarrollo no sería fácil porque, aunque el concepto es simple, llevarlo a cabo no lo es tanto.
La primera imagen que me envió es el punto de partida para todo el desarrollo. Viendo dos meses después el resultado final no se parece demasiado, pero la idea permaneció. En la imagen las pelotas son el cerebro director de la máquina y en el caso de tocar el suelo se perdería la partida.
. Primeros pasos .
Lo primero fue plantear la idea general y cómo llevarla a cabo. Mi idea era hacerlo con física real, aprovechando que había estado trasteando con ODE, usando opengl como renderer y usando python como lenaguaje de programación (el primer "error").
Lo primero fue probar a ver si python era capaz de usar ODE con soltura y para ello creé unos cuantos modelos y los probé. Cubos y más cubos fueron pasando por mis manos, después pasé a esferas... python era capaz de manejar con soltura gran cantidad de objetos sin problema. Obviemente era capaz porque todo el cálculo de la física se hace con un módulo programado en C, python solo introduce cierta sobrecarga.
. La lógica principal .
La idea principal y lo que me estaba comiendo el tarro fue la de crear estructuras rompibles. La primera idea fue crear unos palos y unirlos mediante fixed joints, esto es, uniones fijas. Todo a las mil maravillas hasta que puse el método de integración rápido que tiene ODE, en aquel momento todo empezó a oscilar. Una verdadera lástima porque en ese caso la forma de romper una unión era tan simple como romper el Joint. Navegué un poco y encontré la forma de "unir" geometrías sin necesidad de recurrir a uniones, el truco, glue geoms. El mecanismo es tan simple como asociar múltiples geometrías a un único cuerpo. La idea parecía cojonudísima, y sabía que me daría problemas a la hora de calcular las roturas, pero continué. En la imagen se ve la primera prueba, una estructura simple funcionando. En ese momento ya tenía el diseño definitivo de la clase estructura (cosa que me facilitó mucho las cosas después).
. Primeros coches .
Además del bastidor, el coche debía tener ruedas (JUAZ). El modelo físico dela rueda es un cilindro, aunque una de las restricciones de pyODE es que no da interface para crear un cilindro normal, si no un capped cilinder, que es un cilindro con las caras con esferas... A pesar de todo cotinué y lo metí unas ruedecillas, unos botones que controlaran las ruedas y zumbando. En la imagen aparece un coche algo más completo (creado sin editor, a manita con código).
Mañana más :)
.Los Comienzos.
Allá por junio de este año, medio en broma medio en serio, zwitter, miembro del núcleo de devilishgames me propuso hacer un juego que tenía en mente. Como no podía ser de otra forma acepté el reto, sabiendo que yo nunca había creado un juego y el tiro podía salir por la culata. En cuanto le dije que sí, zwitter se puso manos a la obra con el concepto.
.El concepto.
El concepto es simple, la creación de un juego de peleas de coches construídos por el usuario. La idea me parecía interesantísima, incluso alguna vez se me había pasado por la cabeza realizar algo así. Enseguida empecé a pensar en qué herramientas usar, cómo enfocarlo, etc, etc. No tardé mucho en darme cuenta que el desarrollo no sería fácil porque, aunque el concepto es simple, llevarlo a cabo no lo es tanto.
La primera imagen que me envió es el punto de partida para todo el desarrollo. Viendo dos meses después el resultado final no se parece demasiado, pero la idea permaneció. En la imagen las pelotas son el cerebro director de la máquina y en el caso de tocar el suelo se perdería la partida.. Primeros pasos .
Lo primero fue plantear la idea general y cómo llevarla a cabo. Mi idea era hacerlo con física real, aprovechando que había estado trasteando con ODE, usando opengl como renderer y usando python como lenaguaje de programación (el primer "error").
Lo primero fue probar a ver si python era capaz de usar ODE con soltura y para ello creé unos cuantos modelos y los probé. Cubos y más cubos fueron pasando por mis manos, después pasé a esferas... python era capaz de manejar con soltura gran cantidad de objetos sin problema. Obviemente era capaz porque todo el cálculo de la física se hace con un módulo programado en C, python solo introduce cierta sobrecarga.
. La lógica principal .
La idea principal y lo que me estaba comiendo el tarro fue la de crear estructuras rompibles. La primera idea fue crear unos palos y unirlos mediante fixed joints, esto es, uniones fijas. Todo a las mil maravillas hasta que puse el método de integración rápido que tiene ODE, en aquel momento todo empezó a oscilar. Una verdadera lástima porque en ese caso la forma de romper una unión era tan simple como romper el Joint. Navegué un poco y encontré la forma de "unir" geometrías sin necesidad de recurrir a uniones, el truco, glue geoms. El mecanismo es tan simple como asociar múltiples geometrías a un único cuerpo. La idea parecía cojonudísima, y sabía que me daría problemas a la hora de calcular las roturas, pero continué. En la imagen se ve la primera prueba, una estructura simple funcionando. En ese momento ya tenía el diseño definitivo de la clase estructura (cosa que me facilitó mucho las cosas después).
. Primeros coches .
Además del bastidor, el coche debía tener ruedas (JUAZ). El modelo físico dela rueda es un cilindro, aunque una de las restricciones de pyODE es que no da interface para crear un cilindro normal, si no un capped cilinder, que es un cilindro con las caras con esferas... A pesar de todo cotinué y lo metí unas ruedecillas, unos botones que controlaran las ruedas y zumbando. En la imagen aparece un coche algo más completo (creado sin editor, a manita con código).
Mañana más :)
9.23.2005
MakeFight
Bien, pues después de un mes de intensísimo coding he terminado la primera beta del juego.
El juego trata, en pocas palabras, de la creación de coches en base a palos y ruedas y pelear es un ring. Pongo unas imágenes y en los próximos días comentaré todo el desarrollo :)
3 contra 1
El editor de coches, poniendo ruedas a placer :)
Modo dos jugadores
2 contra 1 en el escenario de la lava :)
El juego trata, en pocas palabras, de la creación de coches en base a palos y ruedas y pelear es un ring. Pongo unas imágenes y en los próximos días comentaré todo el desarrollo :)
3 contra 1
El editor de coches, poniendo ruedas a placer :)
Modo dos jugadores
2 contra 1 en el escenario de la lava :)
9.06.2005
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 :)
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 :)
9.04.2005
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 :)
9.02.2005
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.
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.
Suscribirse a:
Entradas (Atom)