5.1 Herramientas para Compilar
6.2 ¿Porqué reinventar la rueda?
1 ¿Qué es Tubbie Hunter?
Básicamente se trata de un juego tridimensional (3D), clasificable como un FPS (First Person Shooter). El mismo es un emprendimiento gratuito y abierto, por ende, de esta página es posible descargar, tanto los ejecutables, como todo el código fuente para compilar uno mismo los ejecutables (más adelante se especificarán las herramientas necesarias). Para los más entendidos se trata de un proyecto que actualmente ronda en las 11797 líneas de código C++ (ver sección Detalles Técnicos).
Durante el año 2006 cursé la materia electiva Computación
Gráfica II (2do semestre, 4to año de Ingeniería en Informática, Universidad
Católica del Uruguay). Entre varios trabajos interesantes que fuimos
desarrollando durante el semestre, uno de ellos fue el render
(dibujado) de terrenos, y particularmente en la generación de terrenos mediante
patrones aleatorios, y sus respectivas texturas. En este punto del curso, mi
profesor, Gabriel, señaló que mi terreno se asemejaba bastante al que aparecía
en la serie animada para niños de
A partir de esto, y como entrega final del curso, se me ocurrió, ir integrando todo lo hecho hasta el momento en un solo proyecto final. Dado que otras materias me requerían ;), y que hacer un juego que se parezca a algo como tal, es más que una buena gráfica (a diferencia de Computación Gráfica II donde el objetivo fundamental era obtener la mejor renderización en el menor tiempo posible), no pude terminar el proyecto con todas sus reglas, lógica, física y demás agregados correspondientes.
Finalmente, una vez terminado el semestre, al tener más tiempo, invertí largas horas para dar vida a Tubbie Hunter. Es importante aclarar que no soy muy bueno para la parte de art-work o arte del juego (leáse PhotoShop, CorelDraw, 3D Studio, etc, etc…), por ende no esperen maravillas, hice lo mínimo y necesario para obtener un render respetable, si hay algún artista entusiasta que quiera pretender mejorar el juego en futuras versiones (si las hay…), bienvenido sea!. Lo mismo vale para programadores, tanto para corregir bugs, como agregar nuevos features. Como lo mencioné, se trata de un proyecto abierto, por lo tanto cualquiera que quiera aportar, adelante!
Nadie sabe bien cual es la razón, pero repentinamente los Tubbies han comenzado a experimentar ataques de pánico, esquizofrenia y algunos han llegado hasta los extremos más oscuros de la locura absoluta. Las malas lenguas comentan que estos acontecimientos son producto del constante acoso por parte de los adultos, al tratarlos de individuos homosexuales frente a sus propios hijos (fieles televidentes de la serie…). Se ha contratado a un exterminador para que Tubbie-Elimine a estos alocados Tubbies que no paran de andar sin rumbo fijo sobre las colinas de TubbieLandia. Así que no dudes en disparar si un tierno Tubbie-Psicopata se cruza en tu camino.
A ver valor… que tipo de historia esperabas?... es un arcade en 1era persona, con un arma adelante, no la ultima versión del Final Fantasy ;).
2.1 Requerimientos
Sistema Operativos probados: Windows 98 /
Windows XP.
Versión Run-Time de DirectX 9.0 (o superior…).
Hardware probado con altos niveles de FPS (Frames Per Second,
o cuadros por segundo):
· Celeron 1.0 GHz.
· 256 MB de RAM.
· Tarjeta Gráfica GeForce 4 MMX con 64 MB DDR de memoria gráfica.
2.2 Controles
Teclado:
· W - Avanzar
· S - Retroceder
· A - Moverse Izquierda
· D - Moverse Derecha
· Izquierda - Girar Izquierda
· Derecha - Girar Derecha
· Arriba - Mirar Arriba
· Abajo - Mirar Abajo
· C - Cambiar cámara modos: Aéreo / Terrestre
· Q - Inclinarse Izquierda (Solo modo Aéreo)
· E - Inclinarse Derecha (Solo modo Aéreo)
· R - Subir (Solo modo Aéreo)
· F - Bajar (Solo modo Aéreo)
· T - A qué te suena: ¿Truco o Trampa?
· Enter - Pausa total
· Espacio - Modo paso a paso
Mouse:
· Vista 360 Grados con Mouse (MouseLook)
· Botón Izquierdo Mouse (o Insert en NumPad) - Disparar
· Botón Derecho Mouse - Saltar
2.3 Configuración
Es importante destacar que cada vez que se reinicia el juego, se auto genera aleatoriamente la geometría del terreno (por ende en cada partida es distinta). Esto se logra mediante picos al azar e interpolación de funciones Splines sobre estos picos distantes entre si, a su vez todos los objetos del terreno como la vegetación, el clima, las casas, etc, serán posteriormente alojados de forma aleatoria sobre la superficie del terreno.
Para aumentar la velocidad del juego, si el
mismo funcionara lento en una máquina, se permite alterar el archivo
“Terreno.txt” dentro de la sub-carpeta donde se
encuentre almacenado Tubbie Hunter:
\Config\. Aquí se muestra un ejemplo para esclarecer
el formato del archivo:
#
En este archivo se especifica el número de objetos a cargar según el tipo,
sobre el terreno de Tubbie Hunter.
# Número
de nubes y soles diabólicos para el cielo azul.
Nubes
8
Soles
4
#
Número de casas sobre el terreno.
Casas
20
#
Número de árboles según nivel de altura del terreno: Nivel 1 (más bajo) a Nivel
3 (más alto).
ArbN1 280
ArbN2 220
ArbN3 100
#
Número de plantas y pastitos sobre la costa.
Plant 200
Pasto
800
#
Número de plantas acuáticas, ubicadas en los fondos de los lagos del terreno.
PAgua 200
#
Número de sistemas de partículas en los picos nevados (Nivel 4).
Nieve
18
#
NOTA: A mayor nivel de altura para un objeto terrestre (excluye Nubes y Soles),
menor superficie para ubicar el objeto,
# y por lo tanto, debido a las colisiones con otros objetos ya
ubicados, si se ha seleccionado un "gran" número de instancias,
# los tiempos de carga al inicio de Tubbie Hunter podrían aumentar considerablemente en estos casos.
Render Sistemas de
Partículas:
· Nieve
· Sangre
· Balas Arma
· Fuegos Artificiales
Render terreno a
partir de un HeightMap o Autogenerado
mediante Splines.
· ROAM para optimización de mallas de triángulos en el terreno.
· Autogeneración de texturas y reubicación de objetos aleatorios.
Render Mesh Objetos desde archivo con formato en *.model.
· Cálculo de promedio de normales para superficies curvas.
· Iluminación de objetos, y soporte para diferentes tipos de luces.
Render Sprites:
· Distintos tipos: Posición fija / BillBoards según ejes de coordenadas.
· Sub clase para Sprites animados con animación de textura según punto de vista de la cámara.
Render de objetos
transparentes, usando el orden adecuado.
Culling de objetos a
alto nivel por distancia y volumen de vista.
Cámara con seis grados de libertad.
Inteligencia de enemigos ante el peligro.
Simulaciones básicas para el jugador: saltos,
nados, temblor por disparos consecutivos, etc.
2.5 Edad para Jugar
Supongo que la suficiente como para que un TeleTubbie no te produzca ternura je ;).
Aquí va una lista de las imágenes más representativas que pude obtener (creo ;). Imágenes popularmente conocidas entre la jerga de los “Gammers” (y ahora si, sin más palabras por favor), como ScreenShoots:
q Viernes, 29 de diciembre de 2006:
Que puedo decir: al fin salió Tubbie Hunter en su primer Release 1.0!
Quiero y necesito dormir un poco más, fueron
días largos estos últimos :(
Tubbie Hunter fue enteramente desarrollado en el lenguaje de programación C++ y usando el API gráfica DirectX, (más específicamente el sub módulo de librerías de bajo nivel: Direct3D), no se integra o utiliza ningún tipo de Engine, o FrameWork.
Se utilizaron estructuras de datos y funciones de apoyo como vectores, listas, etc, del STL (Standard Template Library), en algún caso usó una clase vector que desarrollé hace algún tiempo por mi cuenta (ahora ya saben por donde arrancar a buscar los memory leaks ;). El único código no escrito por quien escribe, es el encargado de inicializar la aplicación: registro de la venta al SO, obtención del puntero al device, etc… para ello se utilizan las Common clases del SDK desarrolladas por Microsoft. Alternativamente, el proyecto incluye una inicialización propia, pero que dada su simplicidad (entre otras cuestiones no soporta Full Screen) se opta por la del SDK.
Se trata de algo así como un mini-engine 3D, como consecuencia del admisible nivel de abstracciones, que casi sin demasiado diseño fueron surgiendo. Por ende no esperen la elegancia al 100% de la orientación a objetos, porque no la van encontrar, la optimización a veces se contrapone a estas ideas: punteros que violan la encapsulación, variables estáticas, etc, etc.
Esto último es todo un tema a parte, y lo podemos discutir horas, costo/beneficio de optimización a bajo nivel vs. hard potente (me quedo con las dos ;), de todas formas, y si sirve, les cuento, todo el proyecto fue desarrollado en mi prehistórico portátil: Celeron 900 Mhz, 54 MB RAM y 8 MB de video, pobremente acelerado, corriendo sobre la basura de Windows 98 alias “Blue-Death”. Vale aclarar que la versión final (la compilada que está en esta página para bajar), se arrastra en dicha máquina, durante el desarrollo trabajaba con versiones debug (# ifdef DEBUG… les suena ;).
5.1 Herramientas para Compilar
Estas fueron las herramientas usadas en mi caso, quizás sirvan nuevas versiones, aunque como sabemos, la compatibilidad hacia atrás, lamentablemente, muchas veces es una utopía:
Visual C++ 6.0 (sin Service
Packs de ningún tipo, si! el del año 98, todo un
"museo" andante).
SDK DirectX 9.0 (año
2002).
5.2 Posibles Mejoras y Bugs
Una mejora visible podría ser utilizar Sprites (como BillBoards), en lugar de emisores de partículas, para simular las balas del arma como se hace actualmente. El problema de usar partículas, mediante Point Sprites, es que muchas veces hay otros objetos con transparencia que están más cerca del jugador que las balas, y se dibujan antes que éstas, haciendo un cálculo inadecuado del Alfa Blending para las transparencias. Para ser ordenadas correctamente por la clase encargada de esta tarea, la balas deberían ser independientes y no ser parte de un sistema de partículas, que tiene un render de los Point Sprites en batch. Originalmente esto se hizo así debido a que era fácil e intuitivo extender un emisor genérico a un emisor de balas, pero al ir agregando objetos trasparentes a la escena (léase sobretodo: árboles) comencé a notar este bug.
Para los archivos de datos de los modelos 3D (sub-directorio \Modelos\, por ahora solo dos tipos de casitas), en ambos objetos, los efectos de iluminación están desactivados, esto se debe a que en la versión Relese del proyecto, si se activa el cálculo de luces para estos modelos, los mismos aparecen opacos en el render, a diferencia de exactamente el mismo código en versión Debug, donde el cálculo resulta aparentemente adecuado (esto lo detecté a última hora, y no he podido investigar las causas, parece raro… pero siempre hay algo que uno está haciendo mal, eso me ha reafirmado una vez más este trabajo ;).
Hay muchas, pero sin lugar a dudas algunas de las mejoras ineludibles para aumentar la calidad del código, sería quitar varios parámetros incluidos a “fuego” en código. La opción más fácil podría ser obtener esta información desde archivos de texto con configuraciones al estilo de “Terreno.txt”.
Por último, quizás no se note demasiado, pero al estar ante una situación en la que destruye a más de un Tubbie casi simultáneamente, la explosión en pedazos del primer Tubbie derribado, desaparece mágicamente, al iniciarse la del segundo. Esto se debe a que los sistemas de partículas no soportan una lista con la información de las partículas vivas, asociadas a cada instancia del objeto, sino que es única e igual para todas. Por lo tanto la solución más fácil y rápida para evitar de que se reiniciara un sistema que ya estaba en explosión, era desaparecerlo, y reiniciarlo como una nueva instancia sobre la siguiente colisión en el tiempo.
Por un lado se tiene la inicialización simple que no se utiliza para nada, pero que en al algún momento se podría mejorar, como para no usar las clases del SDK. Quizás esto podría ser particularmente útil para cambiar de device (léase resoluciones, opciones del render, etc.) en tiempo de ejecución, ya que he tenido algunos problemas al intentar hacer esto con las clases estas del SDK.
Uno de los features que finalmente no integré a Tubbie Hunter fue una laboriosa implementación de un terreno basado en ROAM (Realtime Optimally-Adapting Meshes), para optimizar en tiempo de ejecución el render de los triángulos que van simulando la topología del terreno. El uso de esta clase, una vez ya programada (como es este el caso) tiene dos dificultades principales:
1. Lograr una heurística adecuada, o sea el punto de control para parar de dividir un triángulo dado, según la posición del jugador.
2. Crear áreas de no optimización, en donde se alcance un mínimo aceptable de triángulos, debido a la existencia de objetos cercanos. Este punto sería problemático en Tubbie Hunter, ya que prácticamente en cada espacio del terreno hay algún tipo de objeto.
5.3 Estadísticas y CppDoc
Esta página, tanto como los fuentes del proyecto (off-line), contienen un resumen de las estadísticas generales del código del juego, realizados con “Understand for C++”, además de un resumen de las interfaces de las clases, al mejor estilo JavaDoc, realizado por la herramienta CppDoc.
Para ver estas secciones on-line hacé clic acá [ambas incluyen el código fuente completo de Tubbie Hunter]:
Aquí van un par de experiencias, cuestionamientos y reflexiones vividas a lo largo de todo este gran “parto” que fue TubbieHunter. Atención, aviso que los contenidos de esta sección podrían llegar a ser extremadamente nerds, por ende: populares, malones, porristas, etc… (por más referencias ver American Pie o similares), abstenerse.
Es verdad, un estudiante de ingeniería puede divertirse haciendo juegos, pero no todo es color de rosas, y hacer juegos no es puro juego:
Si hubo algo que me jodió [sepan disculpar el
exabrupto, pero era toda una necedad…], buena parte del proyecto, fue una
aparente falla en el Z-Buffer, que me hacía desaparecer triángulos, casi al
azar, y sin demasiada aparente explicación. Le eché las culpas a D3D, al código
de iniciación del SDK, etc, etc… sometí a Gabriel toda una clase de CGII,
frente a mi máquina para vislumbrar la luz, y nada. Hasta que al final,
comparando y comparando con otros códigos de la vuelta, vi que estaba armando a
la matriz de proyección con una distancia de
Quizás a alguien más le pase que en VC++ 6.0 no
pueda compilar Release o Debug
(en mi caso dependiendo del SO, 98 / XP), encadenando con D3D9. Todo va bien,
compila los cpp, hasta que el linker
se cae por falta de un par de métodos en algún .lib,
proveniente desde alguna lejana galaxia ;). Después de mucho foro en
GameDev.com, sin mucha suerte, encontré en otro foro, a un tipo que le pasaba
lo mismo, con las mismas herramientas, y que lo había solucionado, simplemente
cambiando en el IDE, el orden en el que se especificaban los directorios para
ir a buscar las librerías importadas (Tools->Options->Directories).
Supuestamente sería una posible colisión de librerías de varias versiones de DX
(Run-Time y SDK juntos por ejemplo), y que al poner
primero los directorios del SDK que se está usando, el problema se
solucionaría.
Esto no fue un bug,
pero sí fue gracioso: intentando debaguear un bug en donde no estaba (y… el hombre es bicho de costumbres
;), me tope con un hecho enormemente bochornoso, desde un cuadro (frame) al otro del render, todas
las partículas de un sistema como con 5.000 de ellas, desaparecían
instantáneamente, y eso era imposible… ¿Quién las mataba? El código escrito
parecía bien… de hecho estaba bien, solo era que al estar en debug y tomar el tiempo entre cuadro y cuadro del sistema,
los delay en la ejecución eran enormes respecto a los
habituales tiempos de render, por ello, la edad de
las partículas crecía demasiado rápido, lo que les provocaba una muerte
instantánea y segura… en definitiva, obviamente el bug
que buscaba (y posteriormente encontré) no estaba ahí, pero toda esta confusión
me robó un buen tiempo.
A este último punto me da cierta vergüenza
ponerlo acá, pero bueno, no viene mal reírse de uno mismo cada tanto: resulta
en todo el proyecto se utiliza notación húngara para los nombres de las
variable, por lo tanto una variable miembro de una clase del tipo float quedaría m_fAlgo, pues
bien, muy convencido escribí la siguiente declaración y seguí de largo: “int m_fAlgo”, como se imaginarán
hay veces que un Algo en float provoca cierto
comportamiento y un int en Algo otro… por ejemplo:
hacía “m_fAlgo += 0.Algof;”
que al ser un int m_fAlgo,
siempre me quedaba en el valor inicial, no demoré tanto en darme cuenta, pero
fue muy humillante ;).
6.2 ¿Porqué reinventar la rueda?
Quizás algunos de ustedes se pregunte porqué no usé un engine 3D, como algunos de esos que hay en la vuelta -prolijos, portables, eficientes y gratuitos en algunos casos- lo que hubiera simplificado notablemente el trabajo. Bueno, como saben (si han venido leyendo secuencialmente esta página) por un lado originalmente se trataba de un trabajo académico, en donde había requisitos específicos a cumplir, y por el otro, creo que para aprender a usar en su máximo potencial a las herramientas como una caja negra, no hay nada más saludable en un principio (al menos alguna vez en la vida), entender cómo funcionan internamente, y aún mejor, hacer sub-implementaciones uno mismo, intentando que disten lo menos que sea posible del "mundo real". Esto último incluye a las herramientas que se usan para los proyectos reales: DirectX, OpenGL, etc… o sea, haber hecho Tubbie Hunter en Flash, ShockWave, etc, no me dejaría dormir tranquilo.
En primera instancia a Gabriel Gambetta, mi profesor en UCU de Computación Gráfica I y la electiva Computación Gráfica II. Sin su ayuda y guía constante, este proyecto nunca podría haberse realizado. Es admirable ver a un docente con tanto interés en los temas curriculares y extra curriculares de su área, sin lugar a dudas es todo un ejemplo a seguir y me siento todo un afortunado por haberlo tenido en estos dos cursos como profesor, y más particularmente en un tema que tanto me apasiona. Gracias por tu paciencia, tiempo y dedicación, gracias por haberte bancado todos esos mails, por darme todos esos buenos consejos, por las charlas interminables sobre temas extra curriculares (es un problema NP-Completo intentar encontrar algún tópico dentro del área que el tipo no conozca ;), y sobre todo por la motivación para seguir adelante, tanto en los "pifies", como en los aciertos (cada vez que superábamos un bug, Gabriel sufría de mi hostigamiento por exceso de felicidad ;).
A los amigos, y fundamentalmente a Ale (compañero de UCU), todo un referente académico (y si se trata de darle palitos al tío Bill, hablen con él... je ;), quien hace algún tiempo me dio una gran mano en mis primeros pasos en C++, y con quien durante este semestre también, invertimos buen tiempo juntos "hablando" en C++, para quizás otro de los trabajos más interesantes de la carrera, el compilador L+, en el marco de un trabajo obligatorio para la asignatura Compiladores.
Y finalmente a mis viejos por apoyar a semejante sanguijuela, ya que sin lugar a dudas, haber cursado 4to de Ingeniería (y sobretodo este segundo semestre en el que cursé Computación Gráfica II, además de otras cuatro materias, o sea todo el semestre curricular), sin estar laburando particularmente durante este periodo, fue lo que me permitió dedicarle tantas y tantas horas a Tubbie Hunter!!!.
Ahora si, lo importante no?... aquí van los archivos completos del proyecto [esperar 24 segundos para que aparezca el botón “Download” en “filesend.net”]:
Ejecutable instalador
auto-ejecutable (todo lo que necesitas para jugar).