Tras
un tiempo de pausa, estoy de
vuelta
con vosotros con un juego completamente realizado con Blender y que
utiliza su motor de juegos.
Steampac
1.0 (Linux 64)
Steampac
1.0 (Linux 32)
Steampac
1.0 (Linux. Paquete .deb cortesía de Luciano Javier Lagassa)
Steampac
1.0 (Windows 32)
Si estáis interesados en más detalles concretos sobre este él, no dudéis en comentar y cuando disponga de tiempo intentaré resolver dudas o postear más material relacionado con este trabajo.
Saludos.
Actualización con bugs conocidos:
Observaciones:
Vídeo con SteamPac 3D 1.0 en
funcionamiento
Características generales:
Steampac es un juego de laberinto inspirado por el popular Pac-man (también conocido en España como "Comecocos"), aunque con una estética diferente (mezcla de estilo "Toon" y "Steampunk") y con personajes y escenas en 3D.
Este juego está totalmente desarrollado con Blender y utiliza su motor de juego.
Salvo un par de líneas de código en Python, toda la programación se ha llevado a cabo mediante "logic bricks".
Steampac es un juego de laberinto inspirado por el popular Pac-man (también conocido en España como "Comecocos"), aunque con una estética diferente (mezcla de estilo "Toon" y "Steampunk") y con personajes y escenas en 3D.
Este juego está totalmente desarrollado con Blender y utiliza su motor de juego.
Salvo un par de líneas de código en Python, toda la programación se ha llevado a cabo mediante "logic bricks".
Capturas del videojuego en funcionamiento
Características técnicas:
El reproductor autónomo tiene una resolución de 640x480 y utiliza un sombreado GLSL.
El Lenguaje OpenGL Shading (GLSL) necesita una tarjeta gráfica y controladores que lo soporten. Consulta la lista de tarjetas gráficas admitidas en el documento "readme.html" que se incluye en el juego.
El reproductor autónomo tiene una resolución de 640x480 y utiliza un sombreado GLSL.
El Lenguaje OpenGL Shading (GLSL) necesita una tarjeta gráfica y controladores que lo soporten. Consulta la lista de tarjetas gráficas admitidas en el documento "readme.html" que se incluye en el juego.
Capturas del videojuego en desarrollo
A título personal:
Tras algún tiempo sin tocar el módulo de juegos de Blender (desde su versión 2.49) y con ganas de probar algunas de sus novedades, me adentré en lo que "a priori" parecía un proyecto sencillo: la realización de un videojuego de laberinto que siguiera el esquema de juego del Pac-man, aunque modificando los elementos visuales y dotándolo de un escenario en 3D.
Esto que parece algo relativamente fácil ha ido complicándose por momentos hasta adquirir rasgos de proyecto inalcanzable (No me quiero imaginar a la gente que se embarca en la realización de juegos tipo FPS en solitario).
La preparación del material que lo compone (personajes, texturas, animación, etc.) quizás ha sido la parte menos pesada puesto que estoy más acostumbrado a manejarme con ello. Aunque, claro, siempre surgen ciertas cuestiones: retoques de modelos para bajar la densidad de la malla, ajustar las texturas en las nuevas mallas, etc.
El apartado de programación en Blender ha sido la parte más "entretenida". A partir de unos esquemas en los que se abordaban cuestiones como el propio diseño y los comportamientos de jugador y enemigos, fui construyendo toda la lógica. Pero el reto más importante era que sólo debería emplear "logic bricks". Quería ver si un juego aparentemente sencillo podría construirse sólo mediante los bloques lógicos de Blender, sin utilizar python (o al menos, haciéndolo en su mínima expresión).
La buena noticia es que, efectivamente, es factible hacer un juego de este tipo empleando sólo "logic bricks" (de hecho, al final sólo he incluido dos líneas de código en python para mostrar y ocultar el cursor en determinados momentos). La mala noticia es que, o tienes las ideas muy claras en la organización y desarrollo de tu proyecto o éste "morirá entre terribles sufrimientos". Es vital utilizar distintos "estados" en los personajes para mantener cierta coherencia en la construcción y, sobretodo, tener un mínimo de organización. Además, como suele pasar con este tipo de trabajos, cuando arreglas una cosa aparecen otros problemas que irremediablemente te conducen a otros en una espiral casi infinita de problemas o fallos (en este punto es donde te darás cuenta si has organizado adecuadamente tus elementos, ya que intentar localizar un problema dentro de un caos de objetos y "logic bricks" puede acabar con tu salud mental).
Otra cuestión que me ha dado bastantes quebraderos de cabeza ha sido la optimización del juego. Efectivamente, en mi equipo (no muy potente, pero con una gráfica reciente) no hay mayores problemas a la hora de ejecutarlo: fácilmente alcanza los 60 FPS y se nota fluido. Ahora bien, al realizar las pruebas con otros equipos de menores prestaciones, los FPS pueden llegar a caer a la mitad. El mayor problema está en la utilización de "GLSL" como "shader" en lugar de "Singletexture" o "Multitexture" para poder visualizar materiales complejos realizados con nodos (el efecto "Toon" de los personajes). Además, tuve que crear librerias de materiales y cambiar el formato de las texturas de .jpg y .png a .dds (direct draw surface) puesto que parece que se mejora la carga de imágenes.
Tras algún tiempo sin tocar el módulo de juegos de Blender (desde su versión 2.49) y con ganas de probar algunas de sus novedades, me adentré en lo que "a priori" parecía un proyecto sencillo: la realización de un videojuego de laberinto que siguiera el esquema de juego del Pac-man, aunque modificando los elementos visuales y dotándolo de un escenario en 3D.
Esto que parece algo relativamente fácil ha ido complicándose por momentos hasta adquirir rasgos de proyecto inalcanzable (No me quiero imaginar a la gente que se embarca en la realización de juegos tipo FPS en solitario).
La preparación del material que lo compone (personajes, texturas, animación, etc.) quizás ha sido la parte menos pesada puesto que estoy más acostumbrado a manejarme con ello. Aunque, claro, siempre surgen ciertas cuestiones: retoques de modelos para bajar la densidad de la malla, ajustar las texturas en las nuevas mallas, etc.
El apartado de programación en Blender ha sido la parte más "entretenida". A partir de unos esquemas en los que se abordaban cuestiones como el propio diseño y los comportamientos de jugador y enemigos, fui construyendo toda la lógica. Pero el reto más importante era que sólo debería emplear "logic bricks". Quería ver si un juego aparentemente sencillo podría construirse sólo mediante los bloques lógicos de Blender, sin utilizar python (o al menos, haciéndolo en su mínima expresión).
La buena noticia es que, efectivamente, es factible hacer un juego de este tipo empleando sólo "logic bricks" (de hecho, al final sólo he incluido dos líneas de código en python para mostrar y ocultar el cursor en determinados momentos). La mala noticia es que, o tienes las ideas muy claras en la organización y desarrollo de tu proyecto o éste "morirá entre terribles sufrimientos". Es vital utilizar distintos "estados" en los personajes para mantener cierta coherencia en la construcción y, sobretodo, tener un mínimo de organización. Además, como suele pasar con este tipo de trabajos, cuando arreglas una cosa aparecen otros problemas que irremediablemente te conducen a otros en una espiral casi infinita de problemas o fallos (en este punto es donde te darás cuenta si has organizado adecuadamente tus elementos, ya que intentar localizar un problema dentro de un caos de objetos y "logic bricks" puede acabar con tu salud mental).
Otra cuestión que me ha dado bastantes quebraderos de cabeza ha sido la optimización del juego. Efectivamente, en mi equipo (no muy potente, pero con una gráfica reciente) no hay mayores problemas a la hora de ejecutarlo: fácilmente alcanza los 60 FPS y se nota fluido. Ahora bien, al realizar las pruebas con otros equipos de menores prestaciones, los FPS pueden llegar a caer a la mitad. El mayor problema está en la utilización de "GLSL" como "shader" en lugar de "Singletexture" o "Multitexture" para poder visualizar materiales complejos realizados con nodos (el efecto "Toon" de los personajes). Además, tuve que crear librerias de materiales y cambiar el formato de las texturas de .jpg y .png a .dds (direct draw surface) puesto que parece que se mejora la carga de imágenes.
Esquemas de trabajo
Descargas:
Ahora que ya sabéis algo más sobre este proyecto, podéis descargarlo desde sourceforge.net, o desde los enlaces que aparecen más abajo, en sus versiones para Linux y Windows (pronto espero tener preparada una versión para Mac OS X).
Ahora que ya sabéis algo más sobre este proyecto, podéis descargarlo desde sourceforge.net, o desde los enlaces que aparecen más abajo, en sus versiones para Linux y Windows (pronto espero tener preparada una versión para Mac OS X).
Steampac
1.0 (Linux 64)
Steampac
1.0 (Linux 32)
Steampac
1.0 (Linux. Paquete .deb cortesía de Luciano Javier Lagassa)
Steampac
1.0 (Windows 32)
Si estáis interesados en más detalles concretos sobre este él, no dudéis en comentar y cuando disponga de tiempo intentaré resolver dudas o postear más material relacionado con este trabajo.
Saludos.
Actualización con bugs conocidos:
- Si el jugador entra en la zona de nacimiento de de los enemigos, caerá hacia abajo a través del mundo virtual y se tendrá que reiniciar el juego (corregido, cambios en la próxima versión).
- Problema en el cambio de apariencia de los enemigos en el momento del parpadeo del "warning" que confunde sobre su verdadero estado. Al añadir nuevos estados en la sustitución de las mallas se soluciona el problema. (corregido, cambios en la próxima versión).
- Puede suceder que en ocasiones no se contabilice la colisión del "jugador" con el "punto" de modo adecuado. Si esto sucede, no se alcanza el "marcador" necesario para cambiar el nivel y se quedará atrapado en dicho nivel. Ese fallo de colisión puede pasar cuando la "física" del juego trata de interpretar varios "contactos" con apenas diferencia de tiempo y al juego no le da tiempo a contabilizarlos.
Observaciones:
- No se trata de un "bug" sino de una característica no implementada, pero en el cambio de nivel NO se produce un cambio de apariencia del escenario, en realidad acorta el tiempo de caza de los enemigos y los hace algo más activos. Si dispongo de tiempo intentaré añadir algún escenario más en la próxima versión.
