20.7.07

Beret

Tengo pendiente tocar unos cuantos temas que me van surgiendo a la hora de desarrollar el proyecto en el que estoy metido ahora, un remake del mítico Green Beret. Tonterías aparentes como bajar o subir una escalera, o hacer que un enemigo llegue hasta donde estés de forma medianamente inteligente se pueden convertir en auténticas odiseas.

Sin más dilación, y esperando tener algunas tardes libres para hablar de lo chachiguay que me lo paso, os dejo con la versión en progreso (ahora mismo ya sale el camión del final con sus hordas atacantes, que en la captura aún no estaban implementados) de lo que llevamos del... BOINA. Otra de esas cosas que en inglés suena mejor, cachis...


8.7.07

Buhu's Adventure: material gráfico

Podéis encontrar parte del material gráfico en los siguientes enlaces (forman parte de la charla impartida en la VI Jornada de Gráficos de la UJI del pasado 2 de julio):

Portada
A. Gráficos: modelado, texturizado, animación: 1. Buhu
A. Gráficos: modelado, texturizado, animación: 2. Caracol
A. Gráficos: modelado, texturizado, animación: 3. Pájaro
A. Gráficos: modelado, texturizado, animación: 4. Ciervo
A. Gráficos: modelado, texturizado, animación: 5. Cuervo
A. Gráficos: modelado, texturizado, animación: 6. Otros
B. Otros gráficos: el escenario
C. Exportando
E. ¡Y más gráficos!
G. Vídeo del juego y créditos

Huelga decir que todo el material es propiedad de sus respectivos autores, y no está permitido su uso sin su consentimiento y aprobación, bajo las condiciones a las que la empresa les restrinja.

7.7.07

Buhu's Adventure: Prácticas de empresa en Nerlaska

Como parte de la licenciatura en Comunicación Audiovisual, hemos tenido que realizar una estancia en prácticas de 320 horas. Alicia Andrés y un servidor contactamos con Nerlaska para llevarlas a cabo.

Sobre la empresa

Nerlaska S.L. es una empresa con localización en Moncofa (Castellón), dedicada a la infoarquitectura y a la programación y diseño de software a medida. En el plano de la infoarquitectura destacan sus trabajos de reproducción de fachadas, ambientes, pisos pilotos, planos pintados y vídeos promocionales. En cuanto a la programación y diseño, podemos encontrar el diseño y creación de páginas web, y el desarrollo de aplicaciones de gestión para terceras empresas. No es menos importante su sección de infografía dedicada al diseño y creación de videojuegos (demos propias o juegos por encargo), en la que hemos desarrollado las prácticas.

Desarrollo de la estancia

El objetivo inicial previsto para la práctica era la realización de un videojuego a partir de un documento de diseño previo. El plan de trabajo previsto consistía en el modelado, texturizado y animación de personajes, modelado y texturizado de escenarios, programación de la lógica del juego en el motor de juegos propio de la empresa, composición de la banda sonora y búsqueda de sonidos. Este plan, sin embargo, debía desempeñarse hasta el punto en que nos permitiera la temporización de la misma, dado que la creación de este tipo de productos se suele extender bastante en el tiempo.

Durante el desarrollo de la práctica fuimos acotando el trabajo a realizar, hasta terminar decidiendo que finalizaríamos al menos una pantalla completa del juego (la primera fase) en todos los aspectos mencionados anteriormente. En cualquier caso, el documento de diseño sólo recogía al completo esta primera fase.

En los próximos apartados describiremos pormenorizadamente en qué consiste cada fase del desarrollo de un videojuego, y cómo se llevaron a cabo en nuestro caso en particular.

El documento de diseño

Al igual que en cualquier producción audiovisual, para una aproximada previsión de recursos se hace necesario contar con algún tipo de documento de preproducción en el que se bosquejen las guías del producto final. Raramente es un documento cerrado, ya que durante el desarrollo pueden aparecer obstáculos insalvables, fórmulas más eficientes, elementos más divertidos, etc.

En nuestro caso, podíamos haber optado por la creación desde cero de un videojuego ideado por nosotros, o por la realización de un diseño ya existente. Decidimos que sería más productivo para nosotros el ceñirnos a un documento ya existente, dado que suele ser el caso más común en la empresa, y siempre supone un plus de dificultad la consecución con éxito de la idea de un tercero.

El documento de diseño original fue responsabilidad de Ramón Nafria, un peculiar personaje en el panorama del videojuego español. Cuenta con amplia experiencia en este sector y es el principal impulsor del desarrollo del mundo empresarial en el sector a varios niveles, con iniciativas como la organización particular de concursos de videojuegos, entregas de reconocimientos a las empresas con mayor proyección a nivel nacional, o la creación de puntos de encuentro de desarrolladores de videojuegos como la asociación de Desarrolladores de Ocio Interactivo Digital (DOID) a nivel provincial y estatal.

En su último concurso de desarrollo de videojuegos, el “Tú también puedes”, instaba a los desarrolladores a presentar hasta el 4 de junio un videojuego (en cualquier plataforma y de cualquier género) que tuviera como única característica obligatoria que el primer personaje hostil que apareciera en el videojuego fuera un caracol, en honor a los primeros grandes títulos de la historia del videojuego.

El “Buhu's Adventure” es su propia contribución (aunque fuera de concurso) a esta idea. Reseñaremos aquí la historia del juego (de target juvenil) que transcurre en el bosque:

«Un cuervo malvado ha sometido bajo su maligna influencia a todos sus moradores con los poderes que le han otorgado unos “Libros de la Vida”, que ha robado al guardián de la sabiduría del bosque: el búho (o la lechuza, según la elección del jugador).

Este personaje, que tiene la habilidad natural de hipnotizar, tratará de recuperar los libros, atacando si es menester a los animales que se interpongan en su camino, y usándolos además como proyectil contra otros. Sin embargo, sabio como es, siempre preferirá optar por la vía pacífica: tratará de encontrar en cada fase una botella mágica (escondida por el cuervo) que le ayudará a liberar a los animales del espíritu maligno del cuervo.

Por supuesto, el cuervo no le pondrá las cosas fáciles...»

En el documento se recogían aspectos como los tipos de enemigos que nos íbamos a enfrentar a lo largo del juego, el aspecto de la primera fase, la mecánica del juego (similar a los míticos “Bubble Bobble” o “Snow Bros” con un toque más arcade) y la interfaz de juego.

La mecánica del juego consistía en lo siguiente: el búho se mueve a lo largo del escenario, donde se encontrará con los enemigos. Puede hipnotizarlos y, aprovechando su estado de hipnotismo, atacarlos para convertirlos en bolas que podrá usar a modo de proyectiles contra otros enemigos. Para ayudar a usarlos como proyectiles, aparecerá una flecha que indica hacia dónde se lanzará, según la posición del ratón. Pero, para fomentar la no-violencia, se obtienen más puntos si los esquiva, encuentra la botella mágica, y libera a cada uno de ellos.

La fase se considera completada cuando todos los enemigos han sido liberados o eliminados (lanzados en forma de bola o muertos por la colisión con una de estas bolas), y se termina si se pierden las cuatro vidas con las que se cuenta.

El personaje se manejará únicamente con el ratón, haciendo click con el botón izquierdo sobre el lugar al que queremos que se dirija, o doble click si queremos que se dirija más rápidamente hacia él. Con el botón derecho, el búho lanzará rayos hipnóticos. Si el enemigo ya estaba hipnotizado, haciendo click con el botón derecho sobre él, el búho lo atacará, convirtiéndolo en bola.

Pero si la botella (que el búho puede recoger y soltar al hipnotizar) está cerca del enemigo cuando es hipnotizado, se produce su liberación y aparece un espectro que se mueve del personaje hasta la botella.

El personaje podrá volar, pero sólo durante diez segundos. Un personaje hipnotizado dejará de estarlo tras cuatro segundos después de que el búho deje de hipnotizarlo. Una espiral de estilo cómic aparecerá sobre la cabeza del enemigo en ese estado.

En esta fase del desarrollo (en la que éramos libres de introducir cuantas modificaciones quisiéramos), comenzamos una división de tareas inicial, después de adecuar el entorno de trabajo instalando nuestras aplicaciones multimedia favoritas:
  • Primero, seleccionaríamos una serie de personajes para modelar y texturizar (los que iban a aparecer en la primera fase más algunos adicionales, por si acaso).
  • Después, crearíamos un escenario básico (modelado y texturizado) en el que integrar dichos personajes.
  • Posteriormente, crearíamos la serie de animaciones necesarias para cada personaje.
  • Programaríamos su comportamiento en el motor de juegos.
  • Finalmente, añadiríamos los sonidos y crearíamos la música.
Todas estas tareas estarían en completa realimentación, sujetas a posibles cambios y reajustes.

El modelado y texturizado

Esta fase consiste en la conversión de la idea o boceto inicial de los personajes y escenarios en modelos 3D (mallas poligonales) con texturas (imágenes) aplicadas a modo de “vestido” de la malla.

En el momento de comenzar las prácticas, Alicia tenía conocimientos medios del programa de 3D libre Blender a raíz de haber hecho algún curso en la Universidad Jaume I. Yo manejaba este software de forma avanzada, y tenía nociones de nivel medio de 3DStudio Max 8, por haber utilizado esta herramienta en el pasado, en su cuarta versión.

Dado que el motor de juegos (del que hablaremos más adelante) sólo tiene actualmente un exportador propio para los modelos desde 3DStudio Max, sabíamos desde el principio que nos acabaríamos teniendo que familiarizar con el estilo de uso del programa, a pesar de que intentaríamos en lo posible utilizar Blender y formatos de exportación desde este programa hacia el 3DStudio Max, para terminar exportando al formato del motor propio.

Por ello, mientras Alicia hacía los tutoriales incorporados con el 3DStudio Max, yo dediqué un tiempo a repasar la interfaz del mismo para adaptarme a los cambios.

Pasamos entonces al reparto de los personajes. Las restricciones del motor de juegos obligaban (como suele ser común en este campo) a que cada personaje fuera una única malla y las texturas, preferiblemente de un tamaño de imagen potencia de dos (optamos por 512x512). Las restricciones del documento de diseño trataban sobre el número máximo de polígonos por personaje y del formato de la textura a usar.

Se nos había dado como referencia el modelo y texturizado del personaje protagonista, creado por el infógrafo Tomás Álvarez para Ramón: un búho con una forma bastante “cartoon” pero con texturas fotorrealistas. Esto marcaría la estética a seguir en el resto de personajes y el escenario, para darle coherencia.

La lista de los personajes restantes del documento de diseño era la siguiente: caracoles, serpientes, pájaros, cazadores, osos, abejas, ranas, peces, ciervos, perros, linces, jabalíes, camaleones, cangrejos y, por supuesto, el cuervo.

El reparto de personajes quedó temporalmente así:
  • Yo me encargaría del ciervo, el pájaro, el cuervo y la serpiente.
  • Alicia se encargaría del caracol, el pez, el jabalí y el camaleón.

La selección se basó en la lista de los personajes que aparecían en el diseño de la primera fase (caracol, pájaro, ciervo y cuervo) y algunos extra que quizá pudiéramos necesitar (pez, jabalí y camaleón).

Para las texturas debíamos encontrar recursos fotográficos que poder usar como base para retocarlos. Utilizamos el programa de retoque fotográfico libre The Gimp para basarnos en fotografías genéricas encontradas en el buscador de imágenes de Google.

En este punto también modelamos y texturizamos los elementos del escenario de la primera fase. Yo modelé y texturicé la botella mágica y preparé los planos que harían de fondo (uno alejado de montañas y cielo, otro más cercano de monte) y de suelo, y los “impostores” que servirían para los árboles y arbustos secundarios. Alicia modeló y texturizó los tres grandes árboles que aparecen en ella, y dos tipos de rocas.

Un “impostor” es un plano con una textura que intenta engañar al espectador haciéndole creer que el objeto representado está modelado: un “trampantojo”. Utilizamos esta técnica dado que el número de polígonos de una vegetación modelada sería excesivo e innecesario (a menor número de polígonos en la escena, mayor fluidez de representación, por lo que conviene economizar al máximo este recurso).

El uso adecuado del número de polígonos para recrear formas reconocibles es, con mucho, el aspecto más complicado de esta etapa, que requiere de mucho bagaje técnico y de una “visión de futuro” para tener en cuenta cosas como el incremento de malla que será necesario en la parte de las articulaciones de los personajes para posibilitar su correcta animación en siguientes etapas.

En este punto tuvimos ciertos problemas de exportación de Blender a 3DStudio Max. Probamos el formato VRML como formato puente entre ambos programas, pero cada polígono de la malla se comportaba como separado del resto de la malla, resultándonos inservible a efectos prácticos. Terminamos decantándonos por el formato de malla abierto del Quake 2, el conocido MD2, por haberlo testeado con éxito en Blender en anteriores ocasiones.

Con este formato, aparecían posibles problemas de exportación con las coordenadas de texturas y el pintado de vértices:
  • Al aplicar una textura, le decimos a un polígono qué coordenadas de la imagen corresponden a cada vértice del polígono. Si las coordenadas de textura quedan fuera del rango de la imagen (una técnica útil para repeticiones de la textura, que se considera repetida infinitamente en todas las direcciones), 3DStudio Max no recuperaba correctamente la posición de dichas coordenadas.
  • El pintado de vértices es una técnica de iluminación que permite, sin necesidad de añadir luces, que una determinada malla tenga zonas de un color y/o intensidad distintas del resto. Es una técnica muy útil para crear sombreados estáticos sin sobrecargar su cálculo por parte de la tarjeta gráfica (el sombreado suele ser un proceso muy costoso en tiempo de cálculo). El problema con el MD2 es que no exportaba el pintado de vértices, razón por la cual utilizamos el propio 3DStudio Max para realizar el pintado directamente desde allí.
Las animaciones

Una vez finalizados los personajes de la primera fase llega el momento de insuflarles vida para que pasen de ser meras figuras de arcilla a seres “vivientes”.
Para ello, había que dotar a cada personaje de un esqueleto virtual. Cada hueso de ese esqueleto influenciaría a un conjunto de polígonos (en realidad, a los vértices individuales de esos polígonos) cercanos a dicho hueso. La mayor dificultad de esta actividad reside en otorgar a cada parte de la malla el peso adecuado para que se deforme adecuadamente al mover el esqueleto. Es especialmente complicado el pesado de vértices de las zonas de las articulaciones, que han de verse influenciadas por varios huesos a la vez.

Además, el sistema de huesos puede animarse de forma directa (en la jerarquía de huesos, cada hueso aplica sus transformaciones a los que dependen de él) o de forma inversa (al transformar uno de los huesos hijos, se transforman los huesos padres de la jerarquía).

En esta fase de nuevo nos vemos sometidos a una serie de restricciones. Por ejemplo, que el motor no permite que un vértice esté influenciado por más de dos huesos; si se da el caso, reparte el peso entre los dos huesos que mayor influencia tenga sobre cada vértice. Pero la principal es que el motor de juegos sólo admite animación por esqueletos: la información de la animación consiste en saber las rotaciones de cada hueso del esqueleto en cada momento, y la malla se deformará consecuentemente a los pesos que cada hueso tenga sobre cada parte de la malla. Existe otro tipo de animación por deformación de malla, en el que los datos de la animación consisten en “instantáneas” de la malla en cada momento dado, sin necesidad de esqueletos.

Desafortunadamente para nosotros, no existe (o no logramos encontrar) un formato de exportación común entre Blender y 3DStudio Max que respete la animación de esqueletos; el MD2 utiliza la animación por mallas, por lo que no nos servía para la animación.

Por lo tanto, terminamos optando por animar directamente en 3DStudio Max. De nuevo, tuve que reciclar los conocimientos que ya tenía de anteriores versiones, y Alicia echó mano de los tutoriales del programa en ese campo.

Como decíamos, una primera fase de la animación se ocupa de crear un esqueleto para la malla y asignarle a ésta factores de deformación distintos según de qué hueso se trate, de manera que permita animar la malla deformándose correctamente. Esta fase se conoce como “setup” del personaje (preparación para la animación).

La segunda fase se trata de la animación propiamente dicha. Una restricción del motor es que cada parte de la animación ha de tratarse en un archivo por separado. Por ejemplo, si queremos que el búho levante el vuelo y aterrice posteriormente, hemos de dividir la animación en tres: el despegue, el vuelo y el aterrizaje. Otros formatos (como el propio MD2) permitirían que el mismo archivo contuviera, como si se tratara de una película, toda la animación: de tal a tal fotograma estaría la secuencia de despegue, de tal a tal otro, la secuencia de vuelo, y de tal a tal fotograma, la secuencia de despegue.

Dividimos las tareas de la siguiente manera:
  • Yo me encargaría del setup del búho y del ciervo
  • Alicia se encargaría del setup del caracol, el pájaro y el cuervo
A la hora de animar, la distribución inicial era similar, pero las animaciones del pájaro dieron más problemas de los esperados y nos las repartimos.

La lista de animaciones comunes a los enemigos (excepto el cuervo) son: haciéndose bola, rodando hechos bola, muriendo, hipnotizados y caminando (o volando). Aparte, el ciervo cuenta con la animación de ataque (embistiendo), y una animación de “paciendo” para darle más dinamismo. El pájaro tiene una animación para las posibles colisiones contra el protagonista (se echa hacia atrás batiendo las alas), la animación de “estar posado en la rama” y algunos movimientos esporádicos de cabeza mientras está posado en la rama, también para mayor dinamismo. Además, requería la animación de despegue.

Por último, el personaje jugador es el que ostenta la lista más larga y compleja de animaciones: se_aburre (sirve para el estado de quieto, y para que dé unos saltos si hace un tiempo que no mueven al personaje), caminando, despega, vuela, planea, aterriza, colisiona (análogo a la de la colisión del pájaro), empieza_a_hipnotizar, deja_de_hipnotizar, ataca (desde el suelo), ataca_volando, y muriendo.

Hicimos alguna animación extra para algunos de los personajes, que finalmente optamos por no utilizar (como el aterrizaje del pájaro o la hipnosis del pájaro posado en una rama) durante los ajustes del diseño de la mecánica del juego.

A la hora de animar, 3DStudio Max ofrece facilidades para guardar la información de los pesos de los vértices y la animación de los esqueletos, así como “empaquetar” todo lo referente a la animación de un personaje en una especie de grupo llamado “character”. Esto nos resultaría muy útil para subsanar una serie de errores de diseño, que más adelante comentaremos.

Otras consideraciones

La forma en la que el motor de juegos controla las colisiones entre objetos es creando unos cubos auxiliares (llamados “dummy” en 3DStudio Max) que representan la “parte sólida” del personaje (o modelo, en general) y se asocian a la malla (o a uno de sus huesos, si la parte del objeto que queremos que colisione es móvil).

También utilizaremos estos dummies a la hora de definir posiciones del personaje que vayamos a necesitar posteriormente (por ejemplo, en los ojos del búho para que a partir de ellos aparezca un efecto de hipnosis, o en el culo del pájaro para que nos ataque lanzando sus deposiciones desde ese punto), o para definir qué lugares del escenario se comportarían como suelo.

Material gráfico adicional

Aparte de los personajes y escenarios, existen otros elementos gráficos en un videojuego tradicional, que en nuestro caso son: cursor de posición, puntuación, mapa de situación, elementos móviles de dicho mapa, barra de vuelo, rótulos de inicio y fin de fase, vidas restantes y, por supuesto, el menú del juego (con los diversos componentes que lo conforman).

Decidimos dibujar los elementos textuales de puntuación y rótulos de inicio y fin de fase con el representador de textos propio del motor de juegos. Para el resto de elementos utilizamos diversos programas de creación y retoque 2D, así como representaciones de los personajes hechos con el propio 3DStudio Max.
La creación mayoritaria de estos recursos fueron resueltos por Alicia utilizando el programa vectorial libre Inkscape, y el ya mencionado The Gimp.

Con Inkscape creó el mapa de situación, los círculos de colores que representan a los enemigos, la flecha de lanzamiento del enemigo y la espiral que indica que está hipnotizado. También se encargó de la representación del jugador y de la botella para el mapa, que más adelante lo cambiaríamos por un render de los mismos, hechos con 3DStudio Max. Además, con este programa también renderizó los fondos para los menús, y con The Gimp los retocó para crear y añadir el texto de los menús, conseguidos mediante la aplicación del filtro “contorno 3D” sobre una fuente divertida que buscó en internet.

El motor de juegos propio de Nerlaska: el NLKEngine

Un motor de juegos es un programa que facilita la tarea del creador del juego en tanto que gestiona de forma transparente al programador temas importantes como el dibujado en pantalla, la carga en memoria de modelos, imágenes o sonidos, la simulación del comportamiento físico del mundo (gravedad, colisiones, etc.) y otros aspectos básicos.

De esta manera, el creador puede limitarse a utilizar los recursos del motor cuando le sean necesarios, y dedicar el mayor tiempo útil posible a la programación de las interacciones en el uso de dichos recursos (el manejo del personaje, el comportamiento de los enemigos, la consecución de ítems, etc.).

El motor de juegos propio de la empresa, el NLKEngine, cuenta con un sistema de programación mediante un lenguaje propio, similar al lenguaje de programación “C”. Se basa en pequeños programas (llamados “scripts”) que determinan el comportamiento de los elementos del juego, desde la cámara hasta los personajes, pasando por recursos gráficos y sonoros.

Como efecto secundario del uso del motor de la empresa, contribuimos a la detección de algunos pequeños bugs (errores de programación) que Alberto subsanaba inmediatamente, gracias a la comunicación instantánea directa o vía mensajería virtual, si en ese momento no estaba presente en la empresa.

La programación del juego

La programación del juego consiste en la creación de un sistema que combine todos los recursos existentes hasta el momento: cómo se va a interaccionar con los personajes, qué comportamiento tendrán en la escena, de qué manera se moverá la cámara, etc.

Una vez contábamos con el material gráfico básico, era el momento de comenzar a programar con el NLKEngine para que el juego respondiera a las exigencias del diseño.

Recapitulando, la primera fase del juego se compone de un escenario (árboles, arbustos, piedras, fondo y suelo), el player (nuestro protagonista el búho), los enemigos (cuatro caracoles, un pájaro, un ciervo y el cuervo) y la botella mágica. Además, también incluye la citada serie de elementos visuales propios de un videojuego: puntuación, mapa de situación, barra de vuelo, vidas, etc.

Existe una jerarquía de directorios en el juego, en el que cada carpeta contiene una serie de recursos: hay una carpeta específica para mallas, animaciones, sonidos, música, texturas, scripts, fuentes, escenarios y mensajes.

Una vez guardadas las texturas en la carpeta correspondiente, utilizamos un exportador creado por ellos para exportar desde 3DStudio Max a su formato propio los personajes (su malla con su información sobre el pesado de vértices por un lado, y sus animaciones cinemáticas por otra) y el escenario.

Para exportar el escenario debíamos realizar la composición de la escena en un archivo de 3DStudio Max. En esta escena se colocan, en la posición deseada, los elementos que componen el escenario tales como árboles, piedras o arbustos. Además, se sitúan los actores (player y enemigos) en sus posiciones iniciales, es decir, en el lugar que queremos que aparezcan cuando comience el juego. Como en cualquier producción audiovisual, también es necesario tener una cámara para captar la escena, y al menos un punto de iluminación. A cada objeto se le asocia una información textual que indica qué malla se cargará en la escena donde aparezca ese objeto, y/o el script que tiene asociado, en el que se define toda la funcionalidad del mismo.

Una vez configurado el escenario había que programar estos scripts que definen el comportamiento del juego. En total, hemos necesitado trece programas que utilizan el motor de juegos NLKEngine. Básicamente, los programas se componen de propiedades del objeto, inicialización de parámetros, una serie de estados (en el caso de player o los enemigos), y una serie de funciones de gestión de movimiento, colisiones (con el escenario u otros actores) y otras auxiliares.

A continuación se describe con mayor detalle cuál es la función que realiza cada programa:
  • Loader: gestiona la carga de los recursos generales, para poder cargar las distintas escenas de las que se compone el juego, entre otras cosas.
  • Stage: se encarga de poner en marcha la escena que habíamos configurado. Carga los menús, texturas y músicas, crea los actores y la cámara, dibuja la escena y establece la funcionalidad de los menús.
  • Camera: establece la situación y movimiento de la cámara, así como los planos de recorte de la misma, el ratio o el ángulo de visión (sería equivalente al tipo de lente que utilizamos en una cámara convencional).
  • Fade: define funciones para poder realizar fades en la escena.
  • Player: este script se encarga del comportamiento del búho. Es el más complejo de todos por su interactividad. A partir del documento de diseño, programamos en nuestro player los siguientes estados:
    • Se aburre: cuando pasa un tiempo sin que hagamos nada con nuestro personaje, el búho comienza a dar saltitos, indicando así su estado de inactividad.
    • Despega: si el búho está posado en una rama o en el suelo y hacemos click con el botón izquierdo en algún lugar de la pantalla más elevado, el búho emprenderá el vuelo.
    • Vuela: mientras el indicador de tiempo de vuelo no esté a cero, nuestro personaje podrá volar en la dirección que le vayamos indicando con el botón izquierdo.
    • Aterriza: si nos queremos posar, haremos click cerca de una rama o el suelo y el búho aterrizará.
    • Planea: cuando se acaba el tiempo de vuelo, el búho cae planeando. Durante el planeo también podemos dirigir al personaje hacia alguna dirección.
    • Caminando: si estamos sobre una rama de árbol o sobre el suelo podemos caminar pulsando con el botón izquierdo en algún punto de la misma altura que el búho.
    • Empieza/deja de hipnotizar: el búho hipnotiza a sus enemigos para paralizarlos durante un tiempo. Para ello, pulsaremos el botón derecho del ratón: unas ondas naranjas saldrán de sus ojos.
    • Ataque: si hacemos click con el botón derecho sobre un enemigo hipnotizado, el búho se acercará y le dará picotazos hasta convertirlo en una bola.
    • Muerto: el búho dispone de cuatro vidas. Si colisionamos cuatro veces con algún elemento hostil, nuestro personaje morirá y la partida finalizará.
    • Hipnosis: carga y reproduce la animación del hipnotismo.
  • Enemy: es un programa que sirve de base para todos los enemigos y establece algunas propiedades y variables comunes a todos (posiciones iniciales, visibilidad, desplazamiento destino...).
  • Caracol: el caracol tiene un comportamiento bastante simple. Éste se limita a desplazarse en una dirección hasta que choque con algún objeto o actor, en cuyo caso da la vuelta y continúa desplazándose en dirección contraria. Los estados en los que puede encontrarse son los siguientes:
    • Caminando: el caracol se desplaza hacia la izquierda o hacia la derecha.
    • Hipnotizado: cuando el búho le hipnotiza, el caracol permanece inmóvil e hipnotizado durante cuatro segundos. Advertiremos que se encuentra en este estado porque aparece una espiral encima de su cabeza. La espiral desaparecerá antes de que el hipnotismo cese para que sepamos que volvemos a estar en peligro.
    • Bola: si el búho ataca al caracol mientras está hipnotizado se convertirá en una bola. Aparecerá una flecha que podemos dirigir con el cursor para decidir hacia dónde queremos lanzar la bola.
    • Bola Rodando: cuando has convertido a un enemigo en bola, no puedes moverte hasta que no lances esa bola. Para ello, tenemos que hacer click con el botón derecho una vez hayamos situado la flecha en la dirección deseada. Automáticamente, el búho atacará de nuevo y la bola saldrá despedida. Esta bola puede matar a otros animales, pero no causa ningún daño al búho en caso de colisión.
    • Muerto: si el búho lanza una bola y colisiona contra un caracol, éste morirá.
    • Liberado: si el búho hipnotiza al caracol y la botella está cerca, el caracol expulsará su espíritu maligno y se irá del escenario porque está liberado.
  • Pájaro: el pájaro se encuentra inicialmente parado sobre una rama. Cuando nos acerquemos, comenzará a volar y a lanzar excrementos que pueden dañarnos. Sus estados posibles son:
    • Quieto: el pájaro se encuentra en este estado al cargar la fase. Mientras no te acerques a él, permanecerá en la rama, moviendo la cola y la cabeza cada cierto tiempo.
    • Despega: si te acercas al pájaro, éste despegará de la rama para comenzar a volar.
    • Vuela: una vez ha despegado, el pájaro se desplaza volando de izquierda a derecha contínuamente, y lanzando excrementos.
    • Tirar atrás: si el pájaro choca contra el búho se echará hacia atrás y continuará volando.
    • El resto de estados (hipnotizado, bola, bola rodando, muerto y liberado) son análogos a los del caracol.
  • Cagada: carga la animación de la caca del pájaro y gestiona los sonidos asociados a la misma y sus distintos estados (cayendo/esparcimiento contra el suelo).
  • Ciervo: el ciervo es el enemigo más peligroso de la primera fase porque ataca de forma inesperada embistiendo al búho cuando se encuentra próximo a él. Sus estados son los siguientes:
    • Quieto: el ciervo está parado y come hierba.
    • Camina: el ciervo camina de izquierda a derecha. Éste estado se combina con el anterior para que el ciervo camine y pare a comer cada cierto tiempo.
    • Embiste: si el búho se encuentra próximo al ciervo, éste ataca embistiendo mientras le perciba en sus proximidades. Además, gira en la dirección en la que vaya el búho para seguir embistiéndole.
    • El resto de estados (hipnotizado, bola, bola rodando, muerto y liberado) son análogos a los del pájaro.
  • Cuervo: el cuervo aparece cuando consigues superar la fase. Se dirigirá hacia donde está la botella, la cogerá y desaparecerá del escenario, forzando al búho a seguirle.
  • Ítem: se encarga de hacer visible o invisible la botella según si el player la tiene o no. Además, gestiona dónde debe aparecer la botella cuando el búho la suelta.
Para separar estas tareas, yo me encargué de la implementación de la cámara y el player (por ser más extenso y complicado), y Alicia se ocupó del comportamiento de los enemigos. Posteriormente, sin embargo, todos los scripts sufrieron retoques y mejoras por parte de ambos. En concreto, yo me centré en la mejora de la lógica de las Inteligencias Artificiales y la optimización de los programas ya realizados, la programación principal del menú y algunos aspectos visuales (espectros y barra de vuelo). Alicia se encargó de la adición de los elementos sonoros y la mayoría de detalles visuales extra (flechas, espirales, mapa de situación, menús, etc.).

En general, todos los archivos estuvieron sometidos a un proceso de feedback constante por ambas partes.

Los problemas

Podemos clasificar el tipo de problemas con los que nos encontramos en tres grupos: de diseño del juego, de modelado y de programación.

De diseño: parte del comportamiento principal pensado para el juego no estaba del todo explicado (más tarde ampliaremos la información al respecto) y, por ejemplo, aparecían árboles en el escenario que el búho no podía sortear para seguir avanzando (que solucionamos “inventándonos” huecos en los árboles). En otras ocasiones, el modo de uso era bastante complicado de implementar y buscábamos alternativas que más tarde nos veríamos obligados a cambiar.

De modelado: tuvimos grandes y graves problemas causados por las diferencias de tamaños relativos entre los personajes, cambios de unidades métricas entre archivos y problemas de normalización del propio personaje.

Profundizando un poco, la transformación de un objeto en 3D puede estar influida por tres aspectos básicos: desplazamiento, rotación y escalado. Estas transformaciones se calculan con respecto a un punto del objeto denominado “punto de pivote”. Para un correcto exportado del objeto, debíamos tener en cuenta los siguientes aspectos:
  • El punto de pivote será utilizado para calcular el punto de colisión con el suelo.
  • El esqueleto debía aplicársele al objeto sin que éste tuviera ningún tipo de transformación de desplazamiento, rotación o escalado (podíamos utilizar herramientas que aplican estas transformaciones al objeto para que éste considere el estado transformado como su estado básico, y poderle añadir el esqueleto entonces).
  • Al modificar a posteriori cualquiera de estos aspectos sobre un objeto animado, las animaciones ya creadas sufrían importantes desperfectos. Esto nos obligó a invertir bastante tiempo en conseguir adaptar las animaciones anteriores a los nuevos tamaños y posiciones (hay que tener en cuenta el enorme número de animaciones; al modificarlas nos surgió también el problema de que algunos tamaños entre animaciones del mismo objeto eran ligeramente distintos, lo cual provocaba algunos incómodos cambios de tamaño durante el juego).
  • Asimismo, en ocasiones no habíamos pesado bien los vértices de los objetos, y al hacer una animación más extrema (por ejemplo, al convertirse en bola), nos dábamos cuenta de que algún vértice no se movía correctamente; entonces debíamos corregir el pesado del vértice e igualar de nuevo todos los pesos de vértices en el resto de animaciones. Es una de las desventajas de tener cada animación en archivos separados.
En cuanto a la programación, tuvimos todos los problemas que se pueden tener, más algunos extra: errores de tipografía en la escritura del programa, problemas de gestión de memoria, problemas en el importado de los modelos o la cámara, problemas de inicialización de valores, problemas con las colisiones, problemas con los sonidos, con la música...

La mayor parte de estos problemas estaban provocados por despistes y eran de rápida corrección. Los más serios llevaban varios días de depuración y, en ocasiones, acabaron necesitando rodeos en la filosofía de programación para implementar la acción de otra manera. Sobre todo, la gestión de colisiones fue el hueso más difícil de roer, aunque terminamos consiguiendo nuestros objetivos.

A veces, los problemas surgían por fallos en el motor de juegos. A pesar de tener una extensa documentación del motor, en ocasiones ésta tenía carencias o defectos. Como era bastante complicado saber si la responsabilidad era nuestra o no (aunque éramos conscientes de que la mayor parte de las veces lo era), comentábamos con Alberto el problema y él se aseguraba de que el motor hiciera lo correcto, y nos aportaba claves sobre qué podía estar fallando. En algunas ocasiones, estos problemas sirvieron para corregir algún fallo interno del mismo.

Los ajustes de jugabilidad

Como comentábamos, el documento de diseño original estaba bastante incompleto. A raíz de un encuentro personal con el diseñador, éste nos comentó que el documento era parcial a la espera de feedback con los desarrolladores y que, una vez le fuéramos enseñando cómo avanzaba el proyecto, podía ajustar mejor algunos aspectos.

Tras mostrarle los avances hasta el momento, surgieron varias discrepancias a la hora de entender el concepto de juego, que se resolvieron en una lista de cambios que tendríamos que seguir (por ejemplo, la forma de uso del ratón, los movimientos de cámara, algunos aspectos estéticos -aunque este campo siempre ha sido secundario-, etc.).

A partir de entonces (a mediados de estancia, aproximadamente), todos los cambios iban siendo comentados con Ramón, que a su vez actualizaba el documento de diseño en un documento compartido de Google. De esta forma, podíamos seguir en tiempo real las peticiones de cambios que debíamos realizar.

El sonido

Una vez terminamos una primera versión jugable de la fase, capturamos un vídeo del juego con una versión de prueba del programa de captura Fraps y lo montamos y comprimimos con el programa libre VirtualDub. Ramón se encargó de difundirlo por foros y blogs dedicados al desarrollo de videojuegos. A partir de los comentarios recibidos en dichos lugares, se llevaron a cabo algunos otros ajustes (algo más de dinamismo en alguna animación o cambios en la velocidad de algunos movimientos) o se apuntaron en la lista de cosas a cambiar en el futuro.

Una vez teníamos completada la jugabilidad de la primera fase (aunque se han ido corrigiendo y ajustando detalles hasta el último momento) había que proporcionar una banda sonora y algunos efectos al Buhu's Adventure.

Para la composición de la banda sonora (el tema del menú y el de la primera fase), utilicé un programa de composición electrónica de tipo “tracker”, basado en la reproducción de sonidos de instrumentos (que también hubo de buscar) según una partitura de filas secuenciales de reproducción. Después, exportó ambos temas al formato libre OGG, que es el formato comprimido que maneja el motor.

Para los efectos de sonido, Alicia realizó una búsqueda intensiva en algunos de los distintos bancos existentes en la red (por ejemplo, el banco de sonidos del Ministerio de Educación y Ciencia).

Cuando la banda sonora se encontraba en su fase final de postproducción y teníamos disponible un amplio abanico de sonidos que podían encajar con el estilo de juego, Alicia comenzó a introducirlos en la lógica del programa.

Realizando las primeras pruebas, advertimos que había que normalizar el volumen de los distintos efectos y proporcionarles un tono más unificado en algunos casos. También era necesario efectuar recortes en algunos de ellos para quedarnos con la parte que nos interesaba. Para efectuar estas modificaciones, utilizamos el software libre Audacity, que nos proporcionaba las principales herramientas de edición de sonido.

El resultado

Cumplimos prácticamente la totalidad de los objetivos que nos habíamos marcado para esta práctica. Sigue habiendo una lista importante de cambios a realizar, que deberán esperar a otra ocasión. Se pueden encontrar algunos vídeos del juego en movimiento en YouTube, y en las siguientes entradas de este blog mostraremos todo el material y partes más detalladas del proceso de creación.

Vida en la empresa

Nerlaska hace uso de las ventajas de las nuevas tecnologías para coordinarse y crear un flujo de información constante y dinámico. Un ejemplo de ello es el uso de mensajería instantánea para comunicarse entre los distintos miembros de la empresa.

En nuestro caso, hemos aprovechado algunas herramientas para facilitar nuestro trabajo y organización. La herramienta Google Calendar nos ha sido útil para anotar nuestras tareas diarias (con el fin de facilitar la posterior redacción de esta memoria), los progresos en el desarrollo del videojuego o los problemas que iban surgiendo. También hemos utilizado los documentos compartidos de Google para evitar la constante transferencia de archivos entre el diseñador del juego y nosotros. De esta forma, podíamos modificar y visualizar documentos en la red sin necesidad de descargarlos. También hemos hecho uso de youtube, foros y nuestros blogs personales para difundir el Buhu's Adventure.

Los horarios en la empresa han sido muy flexibles. Hemos podido disponer sin problemas de tiempo libre para exámenes o asistencia a eventos como la iParty. Durante la semana de exámenes, por ejemplo, hemos trabajado desde casa en el tema del sonido.

En cuanto a la toma de decisiones, teníamos total libertad para desarrollar el juego a nuestro gusto, si bien optamos por ceñirnos al diseño de Ramón Nafria. Incluso así, Alberto no ponía impedimentos para introducir cualquier variación que nos pareciera oportuna. Observamos durante la estancia en la empresa que confía en el saber hacer de sus trabajadores, y sólo les marca las directrices básicas oportunas.

Conclusiones

Esta estancia en prácticas en una empresa de videojuegos ha supuesto para mí la consecución de uno de mis más antiguas ilusiones a nivel de afición y puesta en práctica de mis habilidades como infógrafo, músico y programador.

El ambiente era francamente distendido y agradable, con una completa disposición de ayuda por parte de los demás empleados de la empresa, en concreto por nuestro supervisor y por Gus, el otro grafista.

A nivel de equipo, ha sido interesante experimentar los altibajos del desarrollo en grupo de un producto de estas características: la distribución de tareas, las discrepancias a nivel estético, las diferencias de conocimientos... La paciencia y el buen humor se convierten en aliados indispensables a la hora del trabajo en equipo: al final todo ha salido bien, y no ha habido que lamentar bajas humanas.

He podido ampliar y mejorar mis conocimientos en cuanto al diseño y producción de un videojuego, y además me han ofrecido un contrato con la empresa. Trabajar en un lugar en el que nadie te va a decir nada por jugar en horas laborales... ¿qué más se puede pedir?