En un Fregocles meeting como otro cualquiera…

— Ilustrador: Entonces, tengo que diseñar la máquina tragaperras para el puzzle, ¿no?
— Modelador: Así es querido amigo, confío en tu destreza artística que tantas veces nos ha sorprendido. ¡Una máquina de piedra sencilla estaría bien!
— Ilustrador: ¡Claro tío! peeeero… —el diseñador entra en estado creativo— ¡Por qué no, para hacerlo más original, en vez de una máquina-cuadrada-sencilla-de-modelar ponemos una máquina-tragaperras-con-forma-de-busto-griego-chungo-de-modelar!
— Modelador: ¡Y una mierda!
— Ilustrador: ¡Así se habla! pero ya he tomado la decisión, y ya sabes que cambiarla supondría una bajada de calidad del producto y una discusión interminable que nos llevaría inevitablemente a una máquina-tragaperras-con-forma-de-busto-griego-chungo-de-modelar.
— Modelador: *suspiro*
— Ilustrador: ¡A dibujar!
— Modelador: …

El modelador higieniza su cavidad nasal durante cinco segundos

— Modelador: ¡Ya has terminado! eres un genio tío, lo eres. ¿Puedo verlo?
— Resto del equipo: ¡Ohhhhh, como mola!
— Modelador: …

— Ilustrador: Gracias tíos, os aprecio casi tanto como vosotros a mi.
— Modelador: ¿Quién dices que iba a modelar eso?
— Ilustrador: Eso en 20 minutos lo tienes listo.
— Modelador: Hijo de Satán… ¿podrías al menos hacerme una vista frontal y lateral?
— Ilustrador: Eso en 20 minutos lo tienes listo.
— Modelador: Algún día todos os arrepentiréis de vuestros pecados, de vuestras malas acciones, de vuestros bocetos de mierda y de la sobreexplotación de modeladores inocentes *suspiro* ¡A modelar!
— Ilustrador: Eso en 20 minutos lo tienes listo.

Bien, aquí estoy frente a mi ordenador… tengo que reprimir mis ganas de partir las piernas al ilustrador y concentrarme en mi odisea. A ver, volvamos a ver ese boceto del infierno… ¡ARRRRRRGGG! ¡Noooo! debo soltar la katana y dejar de pensar en el cuello del ilustrador. Vayamos al lío.
¿Por donde empezamos? ¿un cubo? ¿una tetera?… bueno, creemos una esfera. Movamos un vértice, movamos otro, miremos el boceto, mierda… Esto no va por buen camino, es como esculpir una miniatura con un martillo a dos manos +10 al daño percutivo de superficie. De momento tenemos una patata.

Centrémonos en la patata. De esa patata tiene que salir una cabeza… extruyo, roto, muevo, me arrastro, sangro sudor y parece que hay una boca y unos ojos por ahí… creo caras que no debieran estar ahí, olvido las reglas de modelado e intento trabajar con los ojos cerrados, con mi mente, con mi visión espacial interna. Cargo el backup porque lo he desajustado todo. Venga, pongamos un poco de barba, un poco de pelo… ¡esto coge forma!

Sigo luchando con la visión espacial de un boceto sin mucha información volumétrica. Los compañeros de equipo me dicen que voy muy bien. Soy feliz. Ahora debo terminar la boca-rodillos de máquina tragaperras, ponerle cuello, tronco… ahora esto es mucho más fácil. Mi patata tiene forma, mi patata me habla, me dice cosas bonitas; soy su padre y la quiero, es mi hija y me quiere.

Venga, los detalles finales, ponle un pie al busto, el hacha, el collar… ¡esto marcha! ya lo tengo practicamente terminado, voy a enseñárselo a alguien.

— Crítico tocapelotas: ¿Y ese hacha?
— Modelador: La del boceto.
— Crítico tocapelotas: No mola nada… ¿Y ese collar?
— Modelador: El del boceto…
— Crítico tocapelotas: Puff, pues quítalo.
— Modelador: Pero si es cosa del boceto, a mi no me…
— Crítico tocapelotas: Haz lo que quieras…

No lo hagas, si los matas a todos tendrás que buscar un equipo de desarrollo nuevo. Contrólate. No saben lo que dicen. Al final se queda así y no hay más peros. No es el modelado perfecto, pero son 2076 triángulos para un jodido objeto cualquiera de un escenario cualquiera y no se merece más cariño.

Hoy, pequeños amigos, vamos a hablar de un tema ciertamente descuidado por los desarrolladores indie: ¡La web!

No es nada raro ver videojuegos indie (y no tan indie) muy cuidados gráficamente, con una pinta estupenda, un argumento currado… pero con una triste web que echa de espaldas.
Y es que aún cuesta pensar que la web es la primera impresión del videojuego que se van a llevar nuestros potenciales jugadores. Y si la web hace llorar los ojos de nuestros visitantes, estaremos disminuyendo las posibilidades de que corran a descargarse ansiosos nuestro videojuego o demo.

Ná, esto le hago yo en un momentín una web con el Frontpage, la cuelgo de Geocities, que es gratis, y listo!

Esta triste frase, que recuerda irremediablemente a los 90, parece que aún se sigue aplicando hoy día. Y es el peor favor que le podemos hacer a los millones de horas que lleva nuestro videojuego a las espaldas. Realmente no cuesta nada cuidar más este aspecto final del producto, sólo hace falta tener en cuenta que es necesario hacerlo. Desde delegar esta tarea a alguien que disponga de los conocimientos necesarios para hacerla hasta, a unas malas, optar por la opción de una plantilla gratuita, eso sí, con una mínima adaptación, claro está.

Contrata un buen hosting

En nuestro caso, tenemos lo que hemos comentado muy asumido y creemos que el resultado habla por si sólo. Desde el principio estaba claro que no podíamos dejar el asunto en manos de un hosting gratuito, poco fiable, poco modificable y que introdujera publicidad y diera una sensación cutre a los visitantes. Necesitaríamos tanto espacio web propio como un dominio en condiciones. Y sí, evidentemente esto significa dinero, pero si realmente has invertido las horas que se han invertido en Fregocles, sabes que es lo menos que puedes hacer por tu criatura.

Hablando sobre hostings y dinero, nos permitiréis un pequeño anexo patrocinado (ejem)…

Un buen diseño hace mucho

La primera versión de Fregocles, que se puso online para ArtFutura’06, lucía el mismo diseño que luce la actual sólo que no disponía del blog integrado. Era una página sin posibilidad de interacción con el usuario, y evidentemente sin la posibilidad de crear contenidos adicionales al videojuego en sí, pero que cumplía muy bien su finalidad: que la gente se descargase el juego. Gestionada mediante PHP y plantillas nativas para mantener bien separaditos contenido y lógica, no necesitaba hacer uso de base de datos y fue programada desde cero.

El diseño gráfico de la web fue especialmente tedioso porque el artwork del que se disponía no se realizó teniendo en cuenta el formato web. Lo ideal habría sido que nuestro ilustrador hiciera una nueva ilustración para la web con la asistencia del diseñador en cuestión, pero debido a «exigencias del guión» (y a otras variedades, ejem) no fue posible.

Asi que hubo que adaptar lo que teníamos a formato web, y encima a velocidad de espanto porque la fecha de ArtFutura se nos echaba encima. Lo más complejo del diseño sin duda fue intentar que fuera un diseño semi-líquido, es decir, que si la web estaba realizada con la resolución 800×600 como base y se veía con una resolución mayor, no vieras las ilustraciones «cortadas». Un claro ejemplo de esto serían las nubes de la esquina superior derecha. (Nota: IE6 se sacrificó en este aspecto, ley del mal menor)

Entre eso, la ubicación original de los elementos en la ilustración que impedían que hubiera un mínimo espacio para contenidos, los degradados, la forma en que los elementos de la ilustracion se entremezclaban, el cross-browsing, el maldito Internet Explorer, y un sin fin de tiquismiqueces varias, hicieron que el desarrollo fuera «todo un reto» (…) La solución más evidente fue usar transparencias PNG de 24 bits junto con el diseño semi-elástico. Esto así sólo suena muy bonito, pero trajo consigo el consiguiente quebradero de cabeza para IE6 que no le gustan los PNG, el consiguiente testeo de hacks para remediarlo (unos no funcionaban para unas cosas, otros para otras) y la consiguiente toma de decisiones regida por el lema del mal menor previamente comentado.

Integrando el blog

Inicialmente el blog iba a ser una sección independiente, con otro diseño mucho más simple y flexible, y que no tuviera las restricciones que teníamos en el diseño basado en ilustración previamente comentado. Y si finalmente no se hizo así fue por un motivo muy simple: ¿dónde narices metíamos el enlace al blog, si en el menú no entraba?

Una soberana tontería como esa, el no haber contemplado un posible crecimiento del menú, junto con la poca flexibilidad que nos daba el diseño, fue lo que hizo que el tema se planteara de una forma mucho más seria. Y después de meditarlo se llegó a la conclusión de que el blog no debería ser algo secundario sino que tenía que tener mucho más peso en la página general, ya que era lo que más frecuencia de actualización tendría (ironías del destino). Y fue cuando nos dimos cuenta de que habría que darle la vuelta al concepto, y no añadir el blog a lo ya existente, sino hacer que el blog contemplara lo ya existente.

Así que hubo que rehacerlo todo, desechando el sistema anterior, para pasar a integrar lo existente con WordPress (el software de blog usado). Evidentemente todo el diseño se podía aprovechar, sólo hubo que adaptarlo a un theme de WordPress. Para los curiosos, he aquí el theme usado como base. El resto fue encajar la información que se iba a mostrar en el diseño, de una forma más o menos coherente; y buscar plugins que hubo que adaptar para distintas funcionalidades (compartir, página de contacto, funcionalidad con los feeds, etc.)

La verdad sea dicha, en esta segunda revisión de la web para integrarla con el blog, no fue una prioridad la validación del marcado. Sencillamente se tomó el theme mencionado como base, para lo bueno y para lo malo, con objeto de reducir el tiempo que llevaría el desarrollo y poder sacar el blog en un tiempo relativamente aceptable. Si se hubiera prestado un poco de atención a este aspecto habría sido fácilmente resuelto ya que la mayoría de errores de marcado que nos indica el validador son «tonterías».

Y hasta aquí este post sobre la importancia de una buena web. El tema, como véis, da para mucho. Aquí ni siquiera hemos entrado en temas de posicionamiento en Google, que es otro factor relevante a la hora de crear una buena web para nuestro videojuego. Eso lo dejamos para futuras entregas ;)

Cada escenario del juego posee, a parte de lo que es el modelo 3D y sus texturas, una serie de propiedades y entidades que deben definirse mediante un editor de niveles. Como no se tenía tiempo ni ganas de crear un editor propio, hubo que ceñirse a la limitada información que proporcionaba el exportador del programa 3D usado y completarla mediante archivos de texto.

Usando el nombre de los objetos

Tras la exportación al formato .B3D desde el programa de modelado (del que ya se comentó alguna limitación en este post), se pierde toda la información sobre las cámaras o luces, así como la metainformación de los objetos (que podría asignarles propiedades específicas como ser colisionables o animables). Lo único práctico con lo que se contaba tras la exportación era el nombre asignado a los objetos.

De forma que para poder exportar algo de información interesante en el caso de las cámaras y luces, se usaron objetos pivote (dummies, que sí se exportaban) y diferentes palabras o caracteres clave, que insertadas en el nombre de los objetos permitían al engine reconocer su naturaleza (luces, cámaras, etc.)

Las palabras clave son:

• «Luz» + número: Para indicar la posición de las luces puntuales (luces en tiempo real, que afectan únicamente al personaje).
• «LuzAmbiente» y «LuzAmbienteP«: En este caso, se usan dos objetos para indicar el vector dirección de la luz ambiente (la del sol, luna…).
• «Cámara» + número y «CámaraP» + número: Posición y vector dirección de las diferentes cámaras de la escena.
• «Salida» + número: Para las diferentes ubicaciones en las que puede aparecer Fregocles al entrar en la escena.
• «Objeto» + número: Define los objetos que tienen un script asociado, ya sea para cogerlos, usarlos, animarlos, etc.

Los caracteres:

• «/«: Colocado en el nombre de cualquier objeto, lo hace colisionable para Fregocles. En la entrada sobre la búsqueda de caminos ya se habló de las colisiones en los ejes X y Z. En este caso se refiere a la colisión de Fregocles con el suelo, para saber a que altura tiene que estar, se podría decir que es la colisión con el eje Y. Es la que le hace subir rampas o escaleras, o simplemente evita que se caiga al infierno más profundo.
• «*«: El asterisco hace a un objeto sensible al ratón. De forma que al hacer click encima, Fregocles se acercará lo más posible. No tienen que ser necesariamente objetos que se reconozcan en la frase de acción (Ir a maceta), por ejemplo, todo el suelo tiene esta característica para poder andar por él y en ningún momento se identifica Ir a suelo.

En la imagen de ejemplo (extracto de un escenario de la primera parte del juego) podemos ver los siguientes nombres de objetos:

• «Cámara03» y «CámaraP03«: Dummies que definen el vector de la camara 3.
• «Colisión*/«: Objeto no visible que define el suelo de la escena. Se utilizó un objeto diferente a los visibles (la tierra y las baldosas) para suavizar el terreno y usar menos polígonos en la detección de colisiones. Además, tiene el carácter «*», de forma que detecta cuando se hace click encima para mover al personaje a ese punto.
• «Salida01«: Fregocles puede aparecer en esa posición y con esa orientación al entrar en la escena. En este caso no necesitamos un vector para definir la orientación, con el ángulo del objeto nos basta.
• «Objeto023*«: Otro objeto no visible que identifica al objeto «matojo». Se usa un cubo transparente para simplificar la detección del objeto y que no sea complicado seleccionarlo. No detecta la colisión ya que un simple matojo no impide que Fregocles pase por encima. Al tener la palabra «Objeto», tiene la posibilidad de ejecutar scripts; de forma que puede mirarse, usarse, cogerse, etc.

Completando la información

Para terminar de completar la información que se escapaba a la exportación y los nombres de objetos, se usaron ficheros de texto plano (ASCII). Ahora que XML se usa hasta en la sopa, algún espabilado podrá decir «¿y por qué no usaron XML que es mejor y más chachi?» y nosotros diremos «¡mirad! ¡¡un ñu con tres cabezas!!» … ejem… En fin, hay muchas mejoras en mente para el engine, algunas realizables ahora, otras para más adelante.

A continuación la lista de archivos más importantes que acompañan a cada escena (no tienen extensión):

• ambient: Contiene una lista de las luces en tiempo real y el color de cada una.

===Ambiente===(r,g,b)
99
120
187
===luz01===(Rango,r,g,b)
20
125
25
45

• cameras: Matriz que determina que cámara enfoca a Fregocles en las distintas zonas del escenario.
• characters: Personajes que hay que cargar en escena y sobre cuál se tiene el control.
• collisions: Mapa de durezas para la búsqueda de caminos.
• fovs: Contiene el FOV con el que debe enfocarse cada cámara (ya se habló algo en este post).
• sounds: Lista de sonidos que deben cargarse para usar en la escena.
• transitions: Marca la velocidad de transición con la que una cámara se moverá. En caso de ser 0, la transición será instantánea. Un ejemplo:

["Ncam1 to Ncam2=Velocidad"]
1 to 2=350
3 to 4=250
1 to 3=0
2 to 4=0

• objects: Lista de archivos con los scripts asociados a los objetos e información sobre el estado visual y de animación de éstos. Estos son los archivos que más información del juego contienen, todos los puzzles, conversaciones, etc. están aquí.

#usar
if ( $MaderaAtrancaPuerta = 1 )
.iracoor ( blo=1, int=0, per=-1, x=13, y=7, a=-90 )
.muestra ( obj=31 )
.animaper ( blo=0, int=1, per=-1, mod=3, vel=0.25, seq=5, trn=10 )
.animaobj ( blo=1, int=1, obj=10, mod=3, vel=0.25, seq=1, trn=10, fra=0 )
.colision ( x=12, z=6, est=0, cam=4 )
.oculta ( obj=13 )
endif
if ( $SaltaMuro = 1 ) and ( $MaderaAtrancaPuerta <> 1 )
$SaltaMuro = 1
.iracoor ( blo=1, int=0, per=-1, x=13, y=7, a=-90 )
.dice ( blo=0, int=0 )
(-1)La puerta sigue cerrada
endif

Al final el proceso de creación de una escena es algo tedioso al no tener toda la información bien centralizada en un editor, que además empaquetara todo en un sólo archivo, etc. Pero en un principio no se esperaba que el proyecto creciera tanto y seguramente el tiempo empleado en hacer dicho editor de niveles habría retardado el desarrollo hasta el infinito, como ya ocurrió en otra ocasión que quizás comentaremos en un futuro.

La primera limitación venía de mano del formato .B3D de Blitz, que no soporta animación por vértices. La única posibilidad de deformación de la malla es mediante huesos. Preparar con huesos un setup que deformase boca y rostro en general era muy tedioso, así que lo simplificamos todo lo que pudimos. Dejamos la expresividad a cargo únicamente de la boca y los ojos, e intentamos que éstos fueran totalmente reutilizables de un personaje a otro. De forma que se decidió que serían objetos a parte, que se importaran sobre el modelo base y que mediante alguna modificación terminaran la caracterización.

Boca

La idea de usar un toroide (un donut…) la impuso el modelador al diseñador. Con pocos huesos se podía deformar perfectamente y ensanchando o apretando el labio superior o inferior se podían conseguir diferentes tipos de bocas.

Para el interior de la boca se optó por cerrar el interior del toroide con un color plano. Debía estar también modelado, para que se adaptara a las deformaciones de los labios y cubriera todo el «hueco» fuera lo grande que fuera. La práctica obligó a aumentar el número de polígonos de este interior de la boca y colocarle un hueso propio para que no atravesara la cabeza del personaje. En la imagen se puede ver como se corrige este problema moviendo el hueso hacia adelante.

Para los labios, después de probar con versiones de 8 y 6 huesos, se simplificó a 4. Una boca-donut no merecía más, la boca nunca se vería muy grande y debíamos optimizar un poco el modelo… Hubo que jugar mucho con el peso de los vértices para que la deformación soportara caras forzadas. Escalando cualquiera de estos 4 huesos, puede modificarse el aspecto de la boca y hacer que parezca más de una mujer o de un forzudo cabezón. Moviendo y rotando se le da el movimiento

Ojos

Como puede verse en las imágenes de arriba, los ojos no pueden ser mas simples… y, al igual que con la boca, la razón estaba en simplificar un aspecto general de los personajes para poder ahorrar tiempo a la hora de modelar. Preparar una cavidad ocular en las caras o hacer unos párpados que quedaran bien con esas cavidades requería de un modelado especial para cada personaje.
Los párpados son dos semiesferas (uno para el inferior y otro para el superior) y las pupilas se hicieron también con geometría para poder cambiar su tamaño durante la animación. Las pupilas inicialmente no iban a tener textura, pero en el caso de Euclínea se ha hecho una excepción y se le ha perfilado un poco el ojo.

De forma que las únicas limitaciones a la hora de diseñar los personajes han sido los ojos y la boca, el resto del personaje era tarea libre del diseñador. Otra limitación era que las faldas o togas no bajaran de las rodillas (no por morbo, sino por simplificar el enhuesado del personaje), pero el dibujante se lo tomó a la torera… y ahí está Euclínea y su maravillosa falda larga (y las horas echadas en hacer que se deformara bien).

La historia

La historia debe estar clara. Escribir una historia general, desglosarla en capítulos y definir todo lo más posible. De aquí ya se puede hacer una lista con las ubicaciones principales del juego, las situaciones importantes que habrá, los personajes involucrados o incluso los puzzles más genéricos.

Los puzzles

Definir los puzzles en función de la historia. No es estrictamente necesario que los puzzles se piensen con la historia ya escrita, hay muchos puzzles que pueden pensarse de antemano y colocarlos en cualquier parte del juego, pero nos arriesgamos a tener que meterlos con calzador. Los objetivos de los puzzles deben estar claros para el desarrollador y, más importante aún, para el jugador. Si un puzzle se sale demasiado del hilo argumental, el jugador probablemente se canse al no ver la relación que guarda el puzzle y su resolución con el resto de la historia.
A partir de los puzzles se completa esa lista de ubicaciones, objetos necesarios, personajes, planos, situaciones, etc.

La historia más los puzzles = El escenario

Los puzzles y la historia describen como debe ser un escenario y no al contrario, bocetar un escenario antes de saber bien que tiene que ocurrir en él puede traer muchos problemas.
La historia marca unas ubicaciones principales, los puzzles terminan de completar los escenarios secundarios y definen todos los objetos y situaciones; esto crea el esqueleto de la escena.
Este esqueleto debe tenerlo muy claro quien sea el encargado de hacer el diseño final (bocetos, dibujos, modelos), para que todo cuadre y no aparezcan incongruencias a última hora. Ya pueden definirse los planos, cámaras y fondos para que todo lo que vaya a ocurrir se vea correctamente.

Objetos seleccionables

Dentro de los objetos seleccionables del juego habría que destacar aquellos que son estrictamente necesarios para la resolución de los puzzles y sin los cuales no se podría avanzar en el juego. Estos objetos deben de estar lo más integrados posible en el escenario, pero a su vez destacar lo sufiente para que no sea la casualidad la que haga dar con ellos (aunque puede que en algún caso, este sea el puzzle). Su diseño es básico para que el puzzle tenga coherencia.

El resto de objetos seleccionables no son sin embargo menos importantes. Aportan información sobre el entorno, dan ambiente, proporcionan pistas para los puzzles, aumentan la dificultad (con solo tres objetos en escena las combinaciones se reducen mucho), etc.
Deben de ser objetos que no puedan y que no parezca que pueden cogerse, ya que tampoco queremos que se llene el inventario de objetos sin una finalidad clara. Y por supuesto, no deben incitar a soluciones lógicas erróneas de los puzzles. Si la solución aparentemente más lógica no es la correcta, el jugador puede frustrarse (aunque hecho a drede, ésto también puede ser un puzzle en sí mismo).

Todo lo que queda es trabajo del grafista, ese personaje tan importante y que nunca tiene tiempo de nada. En sus manos está transformar todas esas aburridas restricciones que ya hemos comentado en un bonito escenario que realmente de ganas de jugar.
En entradas venideras se tocarán los aspectos técnicos de la creación de escenarios en Fregocles. Hasta entonces canten, rían y limpien como si el mundo terminase en tres días.

En nuestra particular y peculiar evolución en El Neutrino Raro, hemos pasado por todos los estadios posibles en lo relativo a organización y forma de trabajo.

Los inicios

En los albores del proyecto, casi antes de estar constituido El Neutrino Raro como tal, nuestra forma de trabajo en grupo era bastante casual y de los esporádicos encuentros que manteníamos siempre surgían nuevas ideas y posibilidades que usualmente eran reflejadas en un documento .doc en guerrilla. Este documento empezó recogiendo ideas sueltas, proposiciones de puzzles, conversaciones, etc. y poco a poco fue evolucionando hacia algo que ya sí podríamos considerar como un documento de diseño, a la vez que fue creciendo y fragmentándose en varios documentos para mantener la modularidad.

Sin duda era un buen enfoque. Estaba claro había que llevar una serie de documentos de diseño del videojuego, que se fueran actualizando y modificando convenientemente y ésta no era una mala manera. Pero pronto nos dimos cuenta de que también estábamos muy limitados con este sistema. Funcionaba bien para recoger las ideas que surgían, pero no siempre estábamos todos reunidos cuando a alguien se le ocurría algo. ¡Y nuestro pobre griego no podía esperar tanto entre reunión y reunión! Había que evolucionar en la forma de trabajo en grupo y como el avezado lector se habrá percatado ya, Internet sería nuestro caballo de Troya en este asunto.

La evolución

Teníamos claras varias cosas:

1. todo el equipo debería poder editar estos documentos cuando quisiera, y…
2. todo el equipo debería poder consultar una versión actualizada en cualquier momento.

La solución más natural, dado el punto de partida del que disponíamos, era un sistema de revisiones aplicado a los documentos que ya teníamos, y éstos colgados en Internet. Mmm, y si esta solución cumple nuestros dos requisitos anteriores… entonces ¿por qué huele a podrido en Dinamarca? Quizás olvidamos un punto:

3. la edición debería ser taaan fácil que realmente te den ganas de editar y contribuir, ¡y no todo lo contrario!

Aha, ahora sí. Estaba claro que el sistema de revisiones de los documentos que planteábamos iba a acabar siendo utilizado por uno, que sería el pringado que lo montara, y que acabaría recibiendo mails para hacer él mismo las ediciones de todos. No, este sistema tampoco nos ayudaba mucho.

Y entonces el concepto wiki llegó a nuestras vidas. Eran los principios de este enfoque de páginas colaborativas y realmente era tosco y feo. Muy tosco y muy feo. Tanto, que hubo que convencer seriamente a más de uno para que lo usara, bajo amenaza de repudio de nuestra limpia sociedad.
Pero aunque asustara de primeras, era simple y con una curva de aprendizaje muy baja. Y permitía lo que habíamos estado buscando, una edición colaborativa sencilla, con un sistema de revisiones añadido y una alta disponibilidad. Para satisfacer vuestra curiosidad, nuestro experto en nuevas tecnologías se decantó por MoinMoin como engine wiki, y claramente su decisión vino dada por ese nombre tan cachondo que tiene.

Actualizado: Por aquí una interesante tabla comparativa de wiki engines, para todo aquel que se encuentre buscando su wiki ideal.

La situación actual

El mecanismo de trabajo con el wiki empezó teniendo una doble personalidad. Por un lado era un lugar donde quedaba recogido lo definitivo, es decir, lo que ya había sido discutido y consensuado por todos; y por otro lado también era un foro de discusión para alcanzar ese consenso que convertía una propuesta en definitiva.
Al principio esta doble personalidad no nos daba problemas dado el poco contenido definitivo que teníamos y que muchas veces la mayor parte del proceso de discusión tenía lugar en el mundo real y no en el virtual. Pero actualmente hemos tenido que dividir estas dos funciones, dejando al wiki sólo la responsabilidad de base de conocimiento del videojuego, y delegando la parte de discusión a una herramienta más propicia para ello: una lista de correo interna.

¿Por qué una lista de correo y no otra cosa? Bueno, veamos, el enfoque de un foro también nos vendría bien pero sin duda está bastante sobredimensionado para lo que necesitamos. Una lista de correo nos da la posibilidad de no emplear nada que no empleemos ya (curva de aprendizaje cero), de comunicar algo de forma rápida a todo el equipo, de poder mantener hilos de discusión (threads) sobre algo y de mantener estos hilos en forma de Archivos que se pueden consultar a posteriori. Amén de ser algo relativamente fácil de mantener, muchísimo más fácil que otras opciones.
El wiki también podría haber sido usado para esta función, pero manteniendo una clara distinción entre páginas de contenido consensuado y páginas de discusión, y como esa línea en muchas ocasiones podía ser bastante fina, nos decantamos por la opción ya comentada.

En una segunda parte de este post veremos más en profundidad como se distribuye y organiza la información en el wiki de Fregocles, desde el nuevo esquema jerarquizado que estamos empleando para los puzzles de la segunda parte, hasta los objetos; y sobre todo nuestros más secretos e íntimos trucos para mantenerlo limpio y ordenado. Porque si bien es importante usar un buen «continente» para tus necesidades, también lo es tener una buena gestión y organización del «contenido» en sí; y lamentablemente una cosa no implica la otra.

Pero eso, queridos amigos, es harina de otro costal.

En la última entrada se dieron unas pinceladas sobre cómo encontrar el camino para llegar de un sitio a otro. Ésta se centrará por un lado en el movimiento del personaje a lo largo de ese camino y por otro en el movimiento que se produce cuando hay una transición de cámara.

El Personaje

Fregocles se mueve principalmente en dos dimensiones (X y Z o largo y ancho). Todo movimiento en su componente Y es “automático” adaptándose a la altura del terreno. De forma que inicialmente se mueve al personaje en X y Z y posteriormente se le coloca a la altura del suelo (Y). Como contrapartida con este sistema Fregocles no anda más lento o más rápido por subir o bajar cuestas, pero era el comportamiento que se buscaba.

Para ese movimiento en el plano transversal (el suelo) se diferenciaron dos cosas:

1. La trayectoria entre puntos de la búsqueda de caminos, es decir, las posiciones por las que pasaría el personaje de Fregocles. Para generar la trayectoria, inicialmente se usó un algoritmo basado en curvas Bézier, pero se descartó al ver que no respondía todo lo bien que se esperaba en curvas muy cerradas. Posiblemente se podría haber ajustado para que funcionara bien… pero se optó por la premisa “vamos a no complicarnos la vida”.
   
   Finalmente se generó de una forma mucho más sencilla. Partiendo de la posición y orientación inicial de Fregocles, se da un «paso» (se avanzan x unidades) hacia adelante. Posteriormente la trayectoria gira un poco para ir orientándose hacia su futuro destino (la siguiente casilla calculada en la búsqueda de caminos). A cada «paso» se orienta más hacia su destino, llegando un momento en el que ya va en línea recta hacia él. Esas pequeñas correcciones del ángulo van determinadas por la fórmula:

   angle = oldAngle + ( (newAngle - oldAngle) / speed )

   que da un movimiento suave y que nos permite controlar la velocidad de esa corrección. Se puede ver un ejemplo de la trayectoria en el caso 1 de la imagen. Cuando el personaje está muy cerca de la pared (caso 2 en la imagen), esa velocidad de corrección del ángulo se hace mucho mayor para que la trayectoria no penetre en el muro.

2. El ángulo del personaje durante la trayectoria. Mientras Fregocles se mueve a velocidad constante por el recorrido, va modificando su ángulo. Lo normal sería que el ángulo de Fregocles fuera similar a la tangente del camino, asi miraría siempre hacia delante. El problema es que en algunas curvas, el giro del personaje se hacia demasiado brusco. Por esto se decidió dar un cierto retardo al movimiento angular de Fregocles. El sistema es similar al anterior, el personaje va cambiando su ángulo poco a poco para ir orientándose hacia la posición final, usando la misma fórmula y una velocidad algo más lenta. En el dibujo se puede ver como el personaje tarda más en estar completamente orientado hacia el destino que la propia trayectoria.

La Cámara

Otro movimiento «suavizado» fue el de la cámara. La cámara cambia de posición según la situación de Fregocles o el contexto del juego, y muchas veces lo hace con transiciones a modo de «scroll». Estas transiciones modifican la posición y el FOV de la cámara.

Cada posición de la camara (cada «plano») tiene un FOV distinto. La transición de una camara a otra cambia el FOV siguiendo una fórmula similar a la descrita para el movimiento del personaje.

Por otro lado, el cambio de posición de la camara sigue una fórmula diferente. Si se hubiera usado la misma fórmula que en el FOV (en un principio fue así), el movimiento habría sido inicialmente muy brusco, y habría ido decelerando conforme llegaba al final. Como la pretensión era que acelerase poco a poco y se frenara al final, se recurrió a la función coseno. Esta función devuelve, entre 0 y pi (Π) radianes, valores de 1 a -1 de forma gradual, similar a lo que se buscaba.

Para aplicarla, se partió de un movimiento de cámara uniforme, en el que cada frame el incremento en el movimiento de la camara era el mismo. Luego ese incremento se «ponderó» según la función coseno para que fuera pequeño al principio, grande a mitad de camino y de nuevo pequeño al final. Aunque finalmente se añadieron algunas constantes para que el movimiento quedara mejor, el código se simplifica en:

coeficiente = (Cos ( pi * abs( oldCoor - actualCoor / newCoor - oldCoor ) ) + 1) / 2
incremento = incremento * coeficiente
coorFinal = actualCoor + incremento

Todo podría haber estado mucho más suave, pero siempre hay que encontrar ese punto intermedio en el que la toalla está gustosa pero a la vez tiene la dureza necesaria para exfoliar la piel.

Lo primero que vio la luz de ese motor fue la búsqueda de caminos. No es una parte muy específica, pero algún iluminado creyó que sería lo más difícil y que si se superaba, el resto sería coser y cantar. Sin profundizar técnicamente, aquí se muestra el proceso de desarrollo del algoritmo. Podéis bajar los binarios de una compilación de marzo de 2004 haciendo clic aquí.

La búsqueda se desarrollaría en un entorno 3D, pero en una aventura gráfica no es especialmente necesario disponer de varios niveles (en altura), teletransportes, etc. y ya que desde un punto de vista cenital, el personaje se mueve solo en 2D (aunque luego al andar se adapte a las alturas del terreno), la búsqueda trabajaría únicamente en dos dimensiones.

Otra decisión que había que tomar era si trabajar con una matriz de posiciones o mediante un grafo de nodos (como las aventuras clásicas en 2D). Usar nodos permite llevar a tu personaje justo a la posición que quieres y permite tener nodos no conectados muy cerca (por ejemplo a cada lado de un muro). Pero nos decantamos por el otro método, teniendo una cuadrícula que marca las posiciones en las que puedes estar. Esto limita bastante los movimientos del personaje, pero es más fácil de implementar, principalmente porque no necesita ningún editor específico para esto. De forma que solo era necesario una matriz que indicara las casillas por las que se puede pasar y las que no, un origen y un destino. El algoritmo genera una lista de casillas por las que hay que pasar para llegar al destino sin chocar.

Cada habitación tiene su propia matriz de colisiones, la cual es generada a partir de una imagen BMP donde el color negro significa “muro” y cualquier otro color indica “camino”. Más tarde el color de la parte caminable se utilizó para definir que cámara es usada en cada momento, pero eso es otro tema.

Lo básico estaba hecho, ahora había que refinarlo. El primer problema era ¿qué ocurre si origen y destino no están comunicados? Se optó por buscar la casilla más cercana al destino que si comunicara con el origen, así el personaje quedaría lo más cerca posible de donde se le había indicado que fuera.

El segundo problema era que el personaje se movía solo en ángulos de 90 grados, y eso no quedaba muy natural cuando una diagonal habría sido el camino más lógico. Se solucionó repasando el camino desde el final, intentando saltarse nodos innecesarios, usando diagonales y sin chocarse (contando además con que el personaje no es un punto y ocupa una superficie). En la imagen puede verse la casilla de origen (O) y la de destino (D), en color verde el camino inicial (solo giros de 90º) y en rojo (marcando los nodos con círculos) el nuevo camino con diagonales. Podrían existir caminos más cortos aun, pero con este simple sistema quedaba bien.

Se añadieron algunas optimizaciones para realizar varias búsquedas simultáneas, y la posibilidad de varios personajes esquivándose unos a otros. Con todo esto, una mopa y abrillanta suelos, se obtiene un camino limpio hacia cualquier parte.