Del 80 que juega el 20

De manera recurrente escucho a muchos profesionales de la industria repetir una frasecilla, ‘El 80% de los jugadores solo juega un 20% del juego’, con la que generalmente terminan conversaciones sin dar posibilidad a la réplica.

Esta afirmación se ha convertido en un lugar común que nadie cuestiona, y sobre la cual se toman decisiones de peso. En uno de los últimos proyectos en los que participé, el productor nos animaba a esforzarnos en que las dos primeras fases del juego fueran especialmente espectaculares. Ya que la inmensa mayoría de los jugadores iban a jugar solo al primer 20%, argumentaba, al menos que este fuese interesante. El resto del juego era menos prioritario.

¿Por qué un consumidor compraría un producto, y luego apenas le dedicaría unas horas antes de descartarlo? Podríamos apuntar:

- Mala información sobre el producto: Quizá compró el juego bajo una información errónea, o el empaquetado del juego vende una experiencia de juego sustancialmente diferente a la real.

- Dificultad inadecuada: Hay excelentes juegos cuya curva de dificultad hace desistir a muchos jugadores, como el GTA: un excelente diseño que rechaza a miles de jugadores por no tener niveles de dificultad.

- Confusión: El arranque de algunos juegos sitúa al jugador en un entorno extraño, sin apenas información sobre los acontecimientos que van sucediendo. Conforme la trama avanza, el usuario va descubriendo las claves de lo que sucede. Pienso, por ejemplo, en los inicios del System Shock 2 o algún Silent Hill. Con todo, hay jugadores que parecen apreciar esto, y les motivan los momentos de ‘no-entiendo-nada’ para seguir adelante.

- Aburrimiento: El juego es, sencillamente, aburrido. Suele deberse a la repetición: mecánicas ya vistas, conflictos ya experimentados, historias trilladas…

Con respecto a la primera razón no podemos hacer nada. Es algo que atañe a los chicos de márketing. Con respecto a las dos siguientes sí podemos hacer algo desde el diseño, pero trataremos estos temas en otros artículos.

Aquí voy a tratar el cuarto punto, ya que mi opinión sobre la frasecilla en cuestión es que hay cierta verdad en ella, y está relacionado con que muchos juegos se vuelven repetitivos tras un inicio explosivo, o los diseñadores no ponen interés en mantener la tensión. Es decir, si se abandona un juego tras el primer 20% se debe generalmente a un fallo de diseño que se puede corregir. Asumir como inamovible que la mayoría de los jugadores no van a pasar de las dos primeras fases del juego es, según mi opinión, enquistar el problema.

¿Qué medidas se pueden tomar? Bueno, no tengo la verdad absoluta sobre esta cuestión. Más bien animo a reflexionar sobre ello. Cada uno verá la guerra de un modo distinto, en base a sus ideas y formación. Desde mi formación en cine y televisión, creo que ambas industrias tienen una larga experiencia en mantener el interés de sus consumidores durante horas, meses o incluso años. ¿Por qué no aprender de su experiencia?

Desde mi trinchera, y para conseguir que los jugadores sigan jugando una mayor atención a los personajes, yo señalaría hacia un mayor interés hacia la trama y la variedad de mecánicas del juego. Para ello apuntaría:

- Mejor desarrollo del personaje principal: Imagina que te presento a un gafotas mudo que viste un traje naranja chillón, aficionado a golpear cajas de madera con un palito. ¿Te suena prometedor como protagonista de un videojuego? A los de Valve sí. Se llama Half Life 1 & 2. Es tan poco carismático que tienen que poner regularmente NPCs que cantan tus alabanzas para que te creas importante. En general, la creación del protagonista en los videojuegos se aparta poco del tradicional ‘raptaron-a-mi-chica-se-arrepentirán’ de tooodos los juegos de Mario.

Echando un vistazo al cine, si tienes un personaje principal original, con conflicto interior y objetivos, tienes ganado al espectador durante horas. Pienso en el inicio de Buscando a Nemo, o en el de Gladiator: En 5 planos te muestran un personaje original (un romano que sueña, la primera película de ese género en que se muestran los sueños del prota), con conflicto interior (un general que desea la paz) y posteriormente un objetivo, la venganza.

- Renovación de las mecánicas: muchos juegos muestran lo mejor que tienen en las primeras dos horas de juego, y el resto es una repetición infinita de ese esquema. ¿Has jugado al F.E.A.R.? Ya sabes de lo que hablo. No sugiero que el juego se reinvente a sí mismo en cada fase, o que vayas saltando de género cada media hora de juego (empezamos con plataformas, luego puzzles, luego shooter, luego rol online persistente…), sino que haya un trabajo de diseño de niveles lo suficientemente serio como para generar unas iteraciones variadas de las mecánicas iniciales.

Los guionistas de de las series semanales de televisión saben que repetir una y otra vez la misma trama es un suicidio. Cada semana ponen a los protagonistas en nuevas y originales situaciones, pero siempre dentro de unos límites (Grissom de C.S.I. siempre tiene que averiguar quién fue el culpable, Mulder se encuentra con un fenómeno paranormal, los de Urgencias a tramas personales y enfermos…).

- Puntos de giro: Los puntos de giro en Storytelling son aquellos momentos de la trama en que esta da un cambio radical, lo cual representa una sorpresa y renovación en los objetivos del protagonista. Estos puntos de giro suelen conllevar un espectacular aumento del interés del espectador por la trama, ya que se abren múltiples e interesantes posibilidades. Es ese momento en que la chica de la telenovela le dice al protagonista, que empuña un arma contra el malvado de turno, la frase de rigor ‘no puedes matarlo, porque es… ¡Tu hermano!’ (corte a publicidad).

Estos giros no son ajenos a los videojuegos. Sin ir más lejos en el Quake 4 a mitad de juego eres capturado y te transforman en un Strogg.

La industria de la televisión ha llegado a perfeccionar estos puntos de giro hasta conseguir meter uno cada 11 minutos (en las sitcoms norteamericanas). Estoy convencido de que se podrían integrar más de este tipo de giros en los videojuegos, y lograr así mantener la atención del jugador de un modo mucho más estable. Quizá incluso un giro en cada nivel, o en cada grupo de misiones...

Como conclusión, estas son solo algunas ideas, extraídas de otras industrias del ocio, para conseguir una mayor implicación del jugador con el juego. Estoy convencido de que si cada diseñador, individualmente, reflexiona sobre ello encontraremos más y mejores formas de evitar que la mayoría de los jugadores abandonen el juego prematuramente, lo cual considero en parte un fallo del diseño del juego. Siempre habrá jugadores que dejen de jugar, pero un 80% es excesivo.Mostrar/ocultar resto...

¿Por qué no podemos ser amigos?

A veces parecemos políticos. Y no, no me refiero al "talante" de Zapatero, sino más bien a la continua regañina de Rajoy y sus compinches.

Está en los genes del hombre pelearse y organizarse en tribus, pero el conflicto entre diseñadores y programadores, tan antiguo que Ugh el cavernícola ya pensaba que Bork le había dado mal las especificaciones para organizar la caza del mamut, no beneficia a nadie.

Yo soy programador. Es cierto que he estudiado durante varios años para serlo, y me gusta pensar que este tiempo me ha proporcionado ciertas habilidades, más allá de las peculiaridades del C++, y me ha ayudado a desarrollar una forma de pensar estructurada. Me gusta analizar las cosas, me gusta tener algo claro antes de empezarlo. Me gustan la simplicidad y el orden. Si encuentro un problema, mi cerebro se pone a dividirlo en subproblemas y analizarlo antes de que pueda hacer algo para impedirlo.

Ahora bien, cuando me pongo a intentar inventar algo nuevo, a generar ideas revolucionarias, a ejercitar el pensamiento lateral, esa es otra historia. La creatividad se alimenta del desorden, del experimento fallido, de combinar lo que no tiene sentido combinar. Nos gusta trabajar en videojuegos porque es un entorno creativo, innovador. El diseñador es el responsable de ser creativo, y ese es un trabajo importante.

Ya hemos dicho en muchas ocasiones que el desarrollo de juegos no es una ciencia exacta. Incluso hacer una sencilla página web la mayoría de las veces tampoco lo es, y pocas cosas podría haber mejor estudiadas en los últimos años. Salvo que estemos haciendo un clon del Tetris, y aún en ese caso, va a haber aspectos del juego y de su construcción que desconoceremos, y que nos tocará aprender por el camino. A golpes, como suelen aprenderse la mayoría de las cosas. Esto vale para el diseñador que acaba teniendo que cambiar la mecánica de disparo, porque no encajaba con el ritmo de juego esperado, o para el programador que tiene que rehacer la pipeline de procesado de texturas porque había un problema con el canal alfa.

Es posible que durante este proceso de aprendizaje, desarrollo y crecimiento, el programador tenga un enfoque más analítico para solucionar problemas. Es posible que diga "ahora no es realista hacer una herramienta para colorear la sintaxis del script en el editor". También es posible que espere una visión más nítida del proceso de la que es realista esperar. El programador querrá saber cuantas balas por segundo y con qué ángulo de dispersión disparará el AK-47 antes de que se haya decidido si el juego es o no futurista.

El valor del diseñador en todo este proceso no está sólo en introducir unos números y colocar unos enemigos en el editor. Está en saber qué números y qué enemigos. Está en idear nuevas números que introducir, y nuevos tipos de enemigos que colocar. Al diseñador no le gusta cerrarse puertas. Posiblemente diga algo como "vamos a probar poniendo 30 unidades en cada tropa, pero esto puede cambiar". Y le gustaría poder convertir el juego de un Doom a un Fifa o a un Starcraft ajustando unos números en un fichero.

Ambos perfiles están destinados a enfrentarse, pero condenados a entenderse. Un equipo es la suma de toda la gente que hay en él. Toda. Si los programadores no respetan a los diseñadores, probablemente vean los cambios como caprichos, como el resultado de no saber lo que se está haciendo, y no como ideas fallidas, que en su momento parecían dignas de mérito, y que sirven de peldaño para llegar a las buenas ideas. Si los diseñadores no respetan a los programadores, pedirán herramientas imposibles y lo justificarán apuntando a otros paquetes de software y señalando que todo eso está ya funcionando, sin pensar que el esfuerzo de un desarrollo así quizás sea difícilmente recuperable y podría tener un impacto duradero.

A todos nos gustaría trabajar en ese estudio maravilloso, donde los programadores escriben código óptimo y sin bugs a velocidad de vértigo, y los diseñadores presentan documentos precisos y detallados, con todos los aspectos definidos y resueltos. Pero no existe, así que tenemos que salir adelante con lo que tenemos. Si a los diseñadores les falta experiencia, entonces los programadores tendrán que hacer un esfuerzo extra para facilitarles el aprendizaje, y compensar los errores que puedan cometer. Si es el equipo de programación el más débil, entonces los diseñadores tendrán que asumirlo y entender que posiblemente las herramientas sean sencillas y tengan bugs, que quizás tengan que ser más selectivos con los cambios que introducen, y que les tocará también hacer un esfuerzo extra para introducir el contenido.

Pero ante todo, hay que evitar caer en el error de cavar un foso alrededor de un equipo, para "protegerlo" del otro. No hay que dejarse llevar por el ego y menospreciar el trabajo, la dedicación y la ayuda que el otro equipo puede prestar. Ni es práctico que los diseñadores escriban un documento de 500 páginas y lo tiren por encima de la valla para que los programadores lo construyan, ni lo es que programación se cierre en banda y se niegue a escribir código o cambiar nada hasta que exista una definición milimétricamente precisa, o decida escribir algo ignorando los requisitos.

Apoyándonos unos a otros, siempre con honradez y camaradería, será más fácil sacar adelante el juego, habrá mejor convivencia, y los errores de unos y otros pesarán mucho menos. Es hora de terminar con la rivalidad y la sospecha. Hora de ponernos en el lugar del otro sin juzgarlo, y trabajar juntos con un objetivo común.

Mostrar/ocultar resto...

Cuestión de puntería

Todo aquel que haya jugado alguna vez a un FPS en consola sabrá lo frustrante que puede llegar ser el sistema de apuntado en este tipo de juegos. Sólo después de muchas horas de práctica y frustración empezaremos a dejar de pensar que nos estamos enfrentando al controlador y podremos, por fin, disfrutar de nuestro shooter.

Sin embargo, la mayoría de jugadores habrán desistido mucho antes. Sus cinco primeros minutos en el juego, supuestamente excitantes, se habrán limitado a estar constantemente compensando de un lado a otro el punto de mira con ligeros toques al stick.

Ante tal demostración de habilidad en el arte del apuntado, que haría sonrojar al mismísimo Torrente, nuestros enemigos empezarán a mirarnos con compasión, y nos daremos cuenta que no nos aciertan tampoco ellos. Los diseñadores se dieron cuenta durante la fase de testeo que tenían que hacerles medio ciegos para evitar que el jugador estuviera muriendo constantemente.

Este artículo pretende ilustrar con algunas soluciones prácticas cómo se puede mejorar el apuntado en juegos de disparos que utilicen un stick analógico para ello. La mayoría de estas soluciones se exponen ya en el siguiente artículo de Gamasutra y se han utilizado en algunos juegos ya publicados (Halo sigue siendo el ejemplo a seguir) así que la idea de este artículo es resumir las más interesantes allí expuestas, proponer otras no contempladas allí y tratar de encontrar, a modo de pequeño brainstorming colectivo, algunas más que se nos vayan ocurriendo entre todos.

Empecemos entonces con las principales soluciones propuestas:

1. Respuesta no lineal a inclinación del stick analógico: un mapeado lineal del controlador nos arruinará la experiencia de apuntado porque el desplazamiento de la retícula en la pantalla requiere de mucha mayor precisión de la que podemos obtener moviendo con nuestros dedos el stick analógico. La solución más obvia es hacer que la respuesta sea no lineal y ajustable según el rango de inclinación, de modo que podamos, por ejemplo, reducir la sensibilidad en giros muy suaves (mejorando asi la precisión) a la vez que que incrementando la respuesta a partir de cierta inclinación del stick (asegurando que los cambios de orientación de cuerpo que quiera hacer el jugador respondan con suficiente celeridad). Cómo estaréis intuyendo, el modo más visual de controlar este tipo de ajuste será normalmente una gráfica, en la que uno de los ejes es el grado de inclinación del stick analógico, normalmente destinado al apuntado, y el otro la respuesta del punto de mira (expresada en grados por segundo, por ejemplo).
   
   
2. Reducción de la sensibilidad en movimientos verticales del punto de mira. Normalmente no necesitaremos orientar verticalmente nuestro punto de mira más allá de un ángulo de 30 grados, así que podemos reducir su sensibilidad de respuesta, evitando así que nuestro jugador se encuentre mirando al suelo o al cielo constantemente por haber inclinado en exceso el stick. Lógicamente, en caso de juegos donde los tiroteos en distintas alturas son constantes, esta solución debería tener en cuenta un ángulo coherente al diseño de niveles.
   
   
3. Autoapuntado suave (o "soft lock", en inglés). Magistralmente utilizado por Halo, els sistema consiste en hacer que el punto de mira tienda a quedarse sobre los objetivos cuando se encuentra encima de ellos, facilitando que permanezcan dentro de él incluso cuando el objetivo se mueve. Idealmente, el jugador no se dará cuenta que el juego le está ayudando, manteniendo por tanto la sensación de ser él el que está realmente apuntando a los enemigos.
   
   
4. Autoapuntado forzado. A diferencia del sistema anterior, el trabajo realizado por el sistema es percibido por el jugador, ya que éste dispone de un botón exclusivo para fijar el punto de mira en el objetivo más cercano a la posición del punto de mira antes de tal pulsación. Podemos encontrar dos tipos de utilización de este sistema de apuntado, según si una vez fijado el objetivo utilizando el botón éste sigue fijado indefinidamente hasta que se suelta el botón de lock (caso de Metroid: Prime Hunters), o si el objetivo se fija tras la pulsación pero no se vincula en caso que éste se mueva o sea el jugador el que mueva el punto de mira (ver la versión de XBOX 360 de Call of Duty 2).
   
   
5. Autoapuntado forzado ajustable. Esta es una variación de la solución anterior. La diferencia aquí es que, una vez fijado el objetivo en nuestra retícula, el jugador puede aún mover el punto de mira con el controlador, sin salirse del objetivo, apuntando por ejemplo distintas partes del cuerpo.
   
   
6. Combinación de sistemas de autoapuntado. También relacionada con las dos soluciones anteriores, en este caso se trata de un sistema que se fundamenta en utilizar un sistema de autoapuntado forzado dentro de otro. El primer sistema fijaría uno de los objetivos, de los distintos que puede haber en pantalla, según la posición de nuestro punto de mira y después de la pertinente pulsación del botón de lock. Una vez fijado el objetivo, el segundo sistema permitiría movernos directamente entre distintos sub-objetivos (partes de un coche o un enemigo, por ejemplo), inclinando el stick de modo acentuado hacia el sub-objeto al que queremos ir o utilizando otro botón que ciclará entre los sub-objetos presentes, por ejemplo.
   
   
7. Autoapuntado inteligente. En este caso, la solución consiste en hacer que el juego haga que nuestras balas impacten correctamente en aquellas situaciones en las que el punto de mira no está exactamente ubicado sobre nuestro objetivo. El modo de camuflar este pequeño truco es presentar en pantalla un punto de mira suficientemente grande como para que el jugador no se dé cuenta. El problema que implica, sin embargo, es que puede complicar la efectividad de los sistemas de daño localizados al no ser completamente controlable qué parte del cuerpo recibirá un impacto cuando el juego haga impactar en el enemigo una bala que no hubiera impactado si se hubiera hecho caso de la posición central del punto de mira.
   
   
8. Compensación de apuntado en salto. Esta sencilla solución, cuya funcionalidad está ya cubierta por los sistemas de "soft lock", consiste en reducir automáticamente la altura de la orientación vertical del punto de mira cuando el jugador efectúa un salto. De este modo, se consigue facilitar el apuntado sobre enemigos que permanezcan en el suelo.
   
   
9. Ajuste de la velocidad de ascensión/caída en saltos. Un salto es por definición un movimiento brusco; por lo tanto, su ejecución no va ayudar al proceso de apuntado. Sin embargo, si por la experiencia de juego que buscamos va a resultar necesario disparar durante la ejecución de un salto, deberemos reducir tanto cómo sea posible la velocidad a la que ascendemos/caemos. De este modo (Halo es, una vez más, un buen ejemplo de esta solución) daremos más tiempo al jugador para que pueda apuntar a sus objetivos de un modo efectivo. El lado negativo de esta solución es que la percepción visual del salto va a estar afectada inevitablemente por este tipo de ajustes, generando normalmente la sensación que estamos bajo gravedad lunar.
   
   
10. ...

Mostrar/ocultar resto...

Sufridos diseñadores

Una vez que la fase de documentación ha recedido un poco, el día a día de un diseñador varía mucho dependiendo del estudio en que trabaje.

En términos generales, el diseñador tendrá que empezar a construir el juego "de verdad", escribiendo scripts, rellenando ficheros de datos, colocando enemigos. Lo que varía es la forma de hacerlo.

Cuando llega a trabajar por las mañanas, Alice lo primero que hace es arrancar su editor de texto. Lo tiene preparado para colorear la sintaxis y ayudarle un poco a editar una pila de ficheros de script (escritos en lua) que usa para definir el funcionamiento de las misiones. Los scripts son relativamente sencillos, y el juego los carga directamente, aunque siempre se cuela ese error ocasional y en vez de escribir AttackEnemy(enemy01) la pobre Alice escribe AttackEnemy(enmey01) y pierde quince minutos discutiendo consigo misma sobre porqué el NPC no se mueve para atacar.

De vez en cuando, Alice también tiene que introducir nuevos tipos de enemigos y armas en el juego. Para ello, tras conseguir de los grafistas un modelo exportado y preparado para que el juego lo cargue, y sin separarse de su viejo editor de texto, se pone a escribir un fichero de definición, en XML, donde asigna un nombre al nuevo personaje, define sus características y el fichero gráfico asociado. Desde el editor coloca una instancia en el mapa, y carga el juego para verlo en acción. Esta vez funciona a la primera, aunque la otra vez había un problema en la carga y tuvo que llamar a un programador para que lo mirara.

En el edificio de enfrente, Bob mira con celos por la ventana mientras espera a que la herramienta que compila los datos para que el juego los cargue (que llaman El Señor Lobo) termine de procesar. Bob también escribe ficheros con un editor de texto pero, en vez de cargarlos directamente, tiene que hablar con El Señor Lobo para que los convierta a un formato binario especial, casi místico, que el juego necesita para funcionar eficientemente. La ventaja es que, cuando detecta un error, El Señor Lobo no se lo calla, e incluso le da a Bob alguna pista sobre cómo solucionarlo. El clásico problema de que falta un fichero, y no sabes cual, queda ya como un mal recuerdo.

De todos modos, lo que despierta angustiado a Bob por las noches es pensar en la fase de equilibrado. Ajustar el daño de las armas, la vida de los enemigos y la velocidad con que se mueven va a ser un infierno si necesita que El Señor Lobo trabaje entre 30 segundos y un minuto cada vez que quiere probar un cambio en el juego. Y es que El Señor Lobo es eficiente y siempre produce resultados, pero se toma su tiempo.

Mientras tanto, en la otra punta de la ciudad, Charlie se recuesta en la silla pensando en su fin de semana. Ha terminado ya de trabajar hoy, en buena parte gracias al nuevo editor que los programadores terminaron hace unas semanas. Cuando lo arranca, en una ventana aparece el juego, que se puede controlar igual que siempre: W,A,S,D o el joystick para moverte, botones para disparar, etc. En el resto tiene todo tipo de controles para modificar las definiciones de los objetos de juego, aunque Charlie ha descubierto que con su formación de programador (siempre le ha gustado enredar con ordenadores) le resulta más práctico editar directamente el fichero de texto y dejar que el editor descubra que ha cambiado y lo recargue. Lo bueno de este editor es que los cambios se reflejan inmediatamente en el juego. Cambia el gráfico de una silla y puedes ver al instante que tal queda la nueva decoración del salón. Si hay algún procesado que el juego necesita, Charlie ni lo sabe ni le interesa.

El editor no tiene nada especial para escribir scripts, Charlie lo hace igual que Alice y Bob, pero también está atento para cuando un script ha cambiado, y permite recargarlo y probarlo sin perder tiempo. Charlie está ahora muy contento, pero todavía se acuerda de la semana pasada, cuando por un bug en el motor del juego el editor se colgó y perdió el trabajo de una hora, que no había grabado. Luego estuvo toda esa tarde sin poder trabajar hasta que el bug se solucionó, y tuvo que quedarse el día siguiente. Pero bueno, ha valido la pena esperar a que todo funcione, piensa satisfecho mientras apaga el ordenador para irse a casa, y de fin de semana.

Mostrar/ocultar resto...

Estructuras

Mucho se ha hablado en los últimos años de drama managers, quizás demasiado, hasta el punto en que su mera mención despierta automáticamente el escepticismo en unos y una visceral defensa en otros. Todo viene de un aspecto muy importante, que es la estructura que gobierna el desarrollo de un juego. Así que, aun a riesgo de iniciar una pequeña guerra dialéctica, voy a intentar hablar un poquito de estructuras, incluyendo drama managers, de la forma más práctica y pragmática posible.

La estructura del juego es la que define los elementos y el orden que conforman la experiencia de juego. Controla la manera en que se desarrolla la historia, y establece qué misiones o situaciones estarán disponibles para el jugador en cada momento. La estructura es muy importante, ya que marca el ritmo de juego, e influye directamente en la libertad que tendrá el jugador para ir a sitios o hacer cosas. La estructura puede ser muy sencilla, como veremos ahora, o puede estar controlada por un sofisticado módulo de inteligencia artificial, que sería el famoso drama manager.

La estructura más simple, y que es la que el videojuego comparte con la gran mayoría de libros y películas, es la estructura lineal. Las escenas se suceden una tras otra en un orden prefijado. Fijaos que, aunque es la más sencilla, existen muchas posibilidades sobre cómo establecer la relación entre la estructura y el tiempo (de ahí vienen los flashbacks, por ejemplo). En el siguiente gráfico se puede ver un ejemplo de estructura lineal. Donde dice "escena", puede haber una misión de juego, una cutscene no interactiva o cualquier otra división que tengamos en el juego. Las escenas son atómicas, no se pueden dividir más, y típicamente se centran en un espacio concreto (un nivel) y el conjunto de mecánicas usado no cambia.

La estructura lineal ofrece el máximo control al diseñador, ya que puede controlar perfectamente el ritmo en todo momento (asegurándose de que no hay ningún momento aburrido), pero limita la libertad del jugador, sus posibilidades de interacción. Es posible forzar historias lineales mediante barreras físicas, como hace por ejemplo Half-Life 2, o simplemente "castigando" al jugador si se desvía del camino óptimo (golden path), como se ve en Dragon's Lair.

Una posibilidad para ampliar la estructura es añadir pequeños callejones sin salida que complementen la línea principal.

Esta estructura es muy útil cuando tenemos una trama principal, y queremos incluir pequeñas subtramas laterales, que no afecten directamente a la principal. También sirve para definir mini-juegos que se incluyen en un contexto concreto. Estas subtramas son opcionales, ya que el jugador puede llegar al final del juego sin pasar por ellas.

Si pensamos en estructuras no-lineales, la primera que suele aparecer es la estructura ramificada (branching). Desde cada escena el jugador puede elegir entre varias escenas posibles, marcando de esta forma su propio camino. Es posible montar la estructura para que existan varios finales posibles, o hacer que todas las posibilidades confluyan en un mismo final.


Es poco frecuente ver una estructura ramificada compleja en un juego comercial, ya que el jugador, en cada partida, sólo ve un porcentaje pequeño del total del juego. Con el coste que tiene la producción de un juego hoy día, no se puede desaprovechar nada de contenido. Como mucho, algunos juegos como Indiana Jones and the Fate of Atlantis ofrecen unas pocas líneas paralelas que el jugador puede elegir.

Esta no es la única forma en que se puede tratar de limitar la cantidad de contenido que el jugador no disfruta. Una muy popular consiste en introducir ciertos puntos de control a lo largo de la estructura, donde las ramas confluyen. Por una parte, se evita la explosión combinatoria de la estructura ramificada pura, y por otra, se mantiene un cierto control sobre el desarrollo y el ritmo del juego.

Esta estructura tiene muchos nombres: bottleneck, hub, foldback, choke point, etc. Cuando se abren diversas opciones, el jugador puede encontrarse con que cualquiera de ellas le permite avanzar, o que necesita jugar varias (o todas) antes de poder seguir adelante. En el primer caso, la estructura es como la del gráfico anterior y su comportamiento, localmente, es como la de ramificación. El segundo caso lo representamos agrupando las escenas juntas.

En este último ejemplo, la no-linealidad se debe a que es posible variar el orden en que se juegan las escenas, pero sigue siendo necesario jugarlas todas para avanzar, con lo que nada de contenido se desperdicia. Alterar el orden sí puede afectar, sin embargo, al ritmo. Las dos variantes se pueden combinar si se desea, haciendo que sea necesario jugar un cierto número de escenas, pero no todas, para avanzar en el juego. Debido a su versatilidad, esta estructura es muy popular y, por ejemplo, la podemos encontrar en la mayoría de los juegos de Bioware.

Hasta ahora hemos visto historias relativamente simples, tanto para el diseñador como para el jugador. Un ejemplo algo más complejo sería el de la estructura de red (web).

En este caso, ya no hay una o varias líneas claras en las que avanza el juego. El jugador es el que marca por dónde quiere ir, recorriendo la maraña de conexiones que une las escenas. La red es una estructura difícil de utilizar, especialmente si estamos acostumbrados a pensar linealmente, ya que es muy distinta la estructura tradicional de tres actos: no hay un principio, un medio y un final claros.

Una estructura similar es la estructura modular. La diferencia con la red es que no hay caminos concretos entre las escenas, cualquier escena está accesible en cualquier momento. Así perdemos el último resquicio que había de control en la estructura.

Como se puede observar en la mayoría de los MMOGs, que tienen una estructura modular, la flexibilidad para el jugador es total, pero es mucho más difícil mantener la misma fuerza narrativa que tienen las estructuras más lineales.

Y es aquí donde entran los drama managers. Idealmente, el drama manager se ocupará de o bien ayudar al jugador a seleccionar una escena relevante (desde el punto de vista narrativo o de ritmo de juego), o bien de ajustar la escena que el jugador elija para que mantenga alto el interés y enganche bien con las escenas previas. Hay gente que defiende incluso que, con un buen drama manager, él se ocupará de generar escenas sobre la marcha, así que no hará falta ni siquiera definir una estructura inicial. Hoy en día, todo esto está entre un prometedor futuro y un lejano sueño.

Técnicamente, la lógica que dirige cualquiera de las estructuras explicadas podría considerarse como un sencillo drama manager. Darse cuenta de esto nos abre una puerta interesante. Si necesitamos ejercitar más control sobre las estructuras menos lineales, podemos introducir cierta lógica (más o menos compleja) que nos ayude a evaluar en todo momento la calidad de la experiencia y a alterar elementos de una escena o guiar al jugador para mejorarla. Algunas de las posibles características de un sistema con drama manager podrían ser:

• Definir requisitos en ciertas escenas. Una escena necesita de un objeto, o necesita una escena previa (no es necesario que sea justo la anterior). Del mismo modo, si dos escenas son auto-excluyentes, el drama manager puede ocuparse de deshabilitar una cuando el jugador participa en la otra.
  
• Tener una lista de parámetros que pueden variar en una escena. El drama manager elegirá un buen valor según la trayectoria del jugador hasta ese momento. Si, por ejemplo, uno cualquiera de dos personajes puede traicionar al jugador, el drama manager recordará quien fue, y mantendrá la coherencia en futuras escenas.
  
• Indicar el "tipo" de escena. Una escena puede servir para introducir un personaje, puede contener conflicto, acción o puzzles. Con una idea global de qué ritmo queremos proporcionar al juego, el drama manager puede proponer escenas de un tipo tal que mantengan ese ritmo.

Ahora mismo es tema de investigación encontrar un sistema genérico que pueda actuar como drama manager en la mayoría de situaciones. Hay algunos ejemplos como Façade, el trabajo de la Universidad de Michigan con SOAR, o el Storytronics de Chris Crawford (del que ya hablamos aquí). Ninguno de ellos es, de momento, completamente satisfactorio, aunque sí consiguen acercarse más a la idea de proporcionar al jugador control sobre el desarrollo global del juego, hacer que sienta que tiene un efecto en la estructura de la historia y en su desenlace.

Mostrar/ocultar resto...

Retroalimentémonos

Hace ya casi dos meses y medio que empezamos esta aventura, y aunque nosotros nos lo estamos pasando muy bien escribiendo los artículos, nos gustaría conocer vuestra opinión.

Es por eso que desde hace un par de días este blog dispone de una dirección de correo electrónico, designostic.staff@gmail.com, y queremos que se convierta en vuestro canal de comunicación.

Queremos saber lo que os gusta y lo que no, qué cosas cambiariáis o qué otras echáis de menos. Felip y Saül están preparando la web a la que nos migraremos y queremos que nos ayudéis a que sea lo mejor posible.

Así que ya sabéis, ya podéis agregar designostic.staff@gmail.com a vuestra lista de contactos ;)

El diseñador a examen

Navegando por la tupida red de blogs que hablan de temas relacionados con juegos encontré este artículo que me pareció interesante, porque trata de un tema del que ya hemos hablado aquí: cómo averiguar si un diseñador (novato) tiene talento o no.

Tras argumentar que las típicas pruebas que se pueden hacer en una entrevista, como analizar artículos escritos por el candidato o charlar de proyectos pasados, no son suficientes para identificar si el diseñador tiene talento en las áreas cruciales del trabajo de diseño, Tadhg Kelly propone una prueba: diseñar un juego en 4 horas usando el siguiente material:

• 1 mazo de cartas
  
• 4 dados de seis caras
  
• 1 cuaderno y 3 bolígrafos de diferentes colores
  
• 1 paquete de tarjetas en blanco
  
• 1 pizarra y 1 rotulador
  
• 1 bolsa de 50 fichas negras y 1 bolsa de 50 fichas blancas
  
• 2 raquetas de ping-pong
  
• 1 pelota de ping-pong

La lista limitada de elementos representa que el diseñador tiene que estar acostumbrado a trabajar con restricciones. Además, para evaluar la capacidad de transmisión del diseñador, no podrá presentar personalmente el juego, sino que deberá documentarlo.

Esta no es la única posible prueba que se puede hacer. En alguno de los comentarios se critica que las posibilidades son muy grandes, lo que permite mayor creatividad al candidato, pero obliga al entrevistador a hacer un esfuerzo mayor. Quizás una prueba más concreta, como diseñar un juego con una premisa dada, pueda ofrecer una idea más clara, especialmente si el diseñador opta a un puesto concreto.

Por supuesto, todas las otras habilidades del diseñador (capacidad de comunicación, conocimiento de juegos, experiencia) tienen su importancia, así que yo no limitaría la entrevista a este test. De hecho, mejor que hacerlo durante la entrevista, probablemente se lo encargaría al candidato para hacer en su casa, haciéndole enviar la documentación de su juego en un tiempo limitado, quizás un día o dos. Aún en el caso que el diseñador tenga ya algún juego preparado en su casa, probablemente tenga que retocar algo para no salirse de los materiales requeridos. Luego, si el candidato promete, se puede usar la entrevista para hablar sobre el juego y así observar la capacidad de presentación del diseñador, al igual que otras pruebas que puedan ser oportunas.

En programación existe una eterna discusión sobre la utilidad y procedencia de hacer tests a los candidatos, donde se hacen preguntas de C++, matemáticas, algebra, algoritmos y estructuras de datos, etc. He entrevistado a candidatos que parecían competentes en una entrevista personal, pero luego por desgracia tenían problemas en el día a día, y la calidad de su trabajo no se correspondía con la impresión que daban en la entrevista. Creo que el uso de tests técnicos, con el riesgo que conlleva de perder a un buen candidato por nervios o pura mala suerte, minimiza mucho la probabilidad de contratar a alguien que no esté a la altura de las expectativas que genera en la entrevista, y mi experiencia así lo ha demostrado. Por ello me parece interesante encontrar una prueba similar para diseñadores. Obviamente, en lugar de hacerles escribir un programa en la pizarra, el diseñador tendrá que diseñar un juego.

Mostrar/ocultar resto...