Tras
un tiempo de pausa, estoy de
vuelta
con vosotros con un juego completamente realizado con Blender y que
utiliza su motor de juegos.
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".
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.
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.
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).
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.
