Ser o no ser...

Seguramente estamos todos de acuerdo que enfundarse en el traje de un personaje es divertido. Dentro o fuera de un videojuego, nos permite meternos en su piel y actuar del modo que imaginamos lo podría hacer.

Nos gusta sobre todo porque nos permite vivir experiencias que nos son inalcanzables en el personaje que encarnamos en la vida real pero también, porque no tenemos que pagar ni dar explicaciones por lo que hacemos dentro de nuestro personaje de alquiler. Y esto nos hace sentirnos predispuestos a experimentar.

Los que nos leemos en este blog nos disfrazamos de héroe repetidamente, y sin rechistar, en la mayoría de juegos. Pero, ¿están utilizando los videojuegos todo su potencial cuando se trata de hacernos participar en sus mundos a través de sus personajes?

Este artículo reflexiona acerca de cómo aprovechar del modo más interesante posible lo que hace único a nuestro medio, o sea, la posibilidad de interactuar con un mundo que reacciona a nuestras acciones. Desde este prisma se enfocará precisamente cómo los videojuegos que cuentan historias utilizan los personajes como mediadores de esta interacción.

Si lo pensamos un poco, creo que podemos llegar a la conclusión que cuando jugamos controlando un personaje de ficción en un videojuego, no estamos haciendo nada muy distinto que disfrazarnos para interpretar el papel de un personaje en una representación teatral, por ejemplo. Me explico.

Es cierto que en el contexto de un videojuego normalmente tendremos un mayor espacio para la interpretación de ese personaje, más que nada porque como jugadores con un dispositivo de entrada en nuestras manos tenemos la posibilidad de controlar ciertas acciones que hace el personaje dentro del sistema de reglas y mecánicas que propone el juego. Aún así, como veremos a continuación, seguiremos estando dentro de un camino estrecho, del que pocas veces nos dejarán alejarnos.

Por ejemplo, cuando somos Lara Croft nos van a dejar saltar entre piedras, disparar a los malos mientras damos volteretas, empujar cajas para activar puzzles, mmm... poco más. La personalidad de Lara, tan plana como voluptuoso su torso, se definirá superficialmente en alguna cutscene que normalmente vamos a saltarnos para llegar a nuestra siguiente dosis de saltos y disparos.

Conclusión, mientras jugamos, lo único que hacemos con el traje de Lara entre puzzle y combate es admirar lo bonito que es, pero ni empatizamos con un personaje mínimamente interesante, ni se nos permite experimentar con él más allá del conjunto de acciones de las que hemos hablado, que por otro lado, encontramos en otros muchos juegos similares.

Otro ejemplo. Cuando nos vestimos de CJ nos dejan: conducir, pegarle a las viejecitas, robar toda clase de vehículos , disparar muchas armas distintas, ponernos todo tipo de ropa, hacernos tatuajes, cortarnos el pelo y... muchas cosas más.

El camino es más ancho sí, pero nada que nos permita alejarnos del macarrismo que por otro lado, tanto nos divierte practicar. Aunque la variedad de acciones y la profundidad de la interacción se han incrementado, el juego sigue sin permitirnos salirnos del esteorotipo de macarra, ni empatizar demasiado con él (al menos en mi caso) al tratarse CJ de un personaje más bien plano y simplón.

De acuerdo, es cierto que en algunos géneros, principalmente el de los juego de rol, se nos plantea la posibilidad de personalizar nuestro/s personajes, tanto en su aspecto estético cómo de personalidad. Sin embargo, seguimos estando dentro de un contenedor bastante restringido. Veamos algunos ejemplos.

En The Elder Scrolls: Oblivion podemos seleccionar oficio, raza, ajustar de mil modos distintos nuestra apariencia, comprar caballos e incluso tomar ciertas decisiones supuestamente morales como por ejemplo, si entrar a hurtadillas en una tienda y robar unas raíces mágicas o llamar a la puerta, esperar a que nos abran y pagar religiosamente por las raíces.

El ancho del camino se amplía notablemente, pero una vez más, ni se define un personaje suficientemente interesante con el que empatizar, ni se plantean las descritas elecciones morales de modo que se puedan tomar sin tener en cuenta el sistema de recompensas y castigos artificial con el que se regula el juego.

Esto es, en Oblivion robamos un caballo porque es el camino más corto para conseguir uno, y si no lo hacemos no es porque nos parezca inmoral, sino porque vamos a estar constantemente incordiados por los guardias de ahora en adelante como castigo por haber cometido el robo.

Otros ejemplos como Knights of the Old Republic o Fable siguen la misma tónica, sin conseguir tampoco plantearle al jugador decisiones morales realmente efectivas que consigan desvincularse del sistema de recompensas y castigos del juego.

Por lo tanto, aunque siendo pasos interesantes, no consiguen mantener la "suspension of disbelief", ya que no se le permite al jugador tomar este tipo de decisiones sin tener que estar pensando en una barra de progreso que alimentar o una potencial adquisición de habilidades con las que mejorar su futura eficacia en el juego.

¿Qué provoca esta utilización de los personajes? Por un lado impide que los jugadores, debido a la preponderancia de las acciones físicas como principal lenguaje de interacción, nos expresemos de modos complejos dentro de la coraza del personaje. Por el otro dificulta que los personajes nos atraigan pos sí solos, ya que su construcción, en la mayoría de casos, está lejos de acercarse a los estándares de los medios narrativos convencionales.

Además, cómo hemos visto anteriormente, tratar de utilizar recursos no interactivos como cut-scenes o textos para definir con mayor detalle estos personajes no sienta demasiado bien a la naturaleza interactiva del videojuego.

Si observamos los medios narrativos convencionales nos damos cuenta que, aunque carecen del componente de interacción que hace único al videojuego, las buenas obras de ficción consiguen, con sus personajes, un grado de afectación al lector/espectador cualitativamente más eficaz, en mi opinión, que el que normalmente consigue el videojuego narrativo y los personajes que encarnamos en ellos.

Desde mi humilde punto de vista, la mayor diferencia es que el autor de toda obra narrativa convencional construye sus personajes para comunicar su visión acerca del tema que trate la película o novela, mientras que el diseñador del videojuego se centra exclusivamente en la funcionalidad que necesita del personaje para que soporte las mecánicas de juego que ha planteado.

En consecuencia, los personajes de películas y novelas están cuidadosamente definidos por la elección de sus rasgos que hace el autor para cada uno de ellos. En este caso no se nos permite controlarlos directamente pero sí se consigue a través de su personalidad que aprendamos algo de cada uno de ellos, e idealmente, que sintamos empatía por el protagonista.

¿Es posible un juego en el que la personalidad de nuestro personaje la definamos nosotros con nuestras acciones como jugadores? No lo sé. El mejor ejemplo hasta la fecha de algo parecido sigue siendo Façade, aunque más que un juego es un ejercicio de narrativa interactiva.

Aún así, y considerando que la calidad de la narración en este ejemplo no es especialmente brillante, los que lo hayáis probado me reconoceréis que el grado de expresión que nos permite Façade a través del personaje que controlamos es mucho más complejo y profundo que en cualquier videojuego.

Lo interesante aquí es que el personaje que controlamos está aún menos definido que la mayoría de personajes de videojuego, pero la gran diferencia, y el hito que marca este ambicioso proyecto, es que las herramientas con las que interactuamos a través del personaje nos permiten expresarnos a través de él de un modo creativo, jugando y experimentando como nunca lo habíamos hecho antes en una experiencia interactiva. Y lo que es mejor, sin referencias a barras o ítems que nos peguen un codazo cada cinco minutos para recordarnos que estamos sólo en un juego.

Utilizar el lenguaje verbal como substituto del sobado repertorio de acciones físicas parece mostrarnos un valioso modo de ensanchar el camino. Ahora sólo falta ver quien es el valiente que hace un videojuego con esto... esa es la cuestión :P

Mostrar/ocultar resto...

¿Cómo debe escribirse un documento de diseño?

En una industria tan joven como la del videojuego, donde aún estamos aprendiendo todo lo que estos pueden dar de sí y el lenguaje con el que se escriben, es normal que estemos cometiendo errores en su proceso de creación. Uno de los puntos clave de este proceso es la elaboración del documento donde se va a definir en qué consiste el juego que se pretende crear: el documento de diseño.

Cómo deben escribirse estos documentos sigue siendo aún un laberinto del que no hemos conseguido salir. Sin la experiencia de medios más asentados como el cine, donde más de un siglo de rodajes han permitido que sus metodologías hayan podido consolidarse, ésta es sin duda una discusión sin una solución clara, cuando hablamos de la industria del videojuego.

El siguiente artículo me parece un perfecto punto de partida para afrontar esta discusión. Quizás no nos sirva para encontrar la salida del laberinto, pero debería ayudarnos a acercarnos a ella, o al menos, divertirnos mientras nos chocamos contra sus paredes. ¿Entramos?

El autor del artículo, Tadhg Kelly, muestra su desacuerdo con el modo en qué industria y diseñadores están afrontando esta tarea. Las siguientes ideas son las que me han parecido más significativas e interesantes de comentar, aunque recomiendo leer el artículo entero.

Una de las ideas clave que se comunican es que el documento de diseño no tiene que ser concebido como un documento técnico. Del mismo modo que un guión cinematográfico se centra en explicar cómo transcurre la historia y no en definir de cuantos vatios tienen que ser las bombillas de las luces de relleno o qué lente debe utilizarse para la cámara, el documento de diseño debe transmitir la visión del diseñador, o dicho de otro modo, la experiencia de juego que se pretende conseguir con cada elemento del juego.

Por ejemplo, un programador de IA no necesita que un diseñador le explique cómo crear una arquitectura de comportamientos y objetivos. El programador ya sabe, y mucho mejor que el diseñador, cómo construirla. Lo que necesita el programador es que el diseñador le detalle qué necesita que la IA le proporcione de acuerdo con la experiencia de juego que se ha marcado como objetivo.

Veamos otro ejemplo, otra vez de la industria del cine. Como explica Robert McKee en El guión, los buenos actores no van a querer trabajar en un guión donde se les diga qué cara deben poner en una cierta escena. Un buen guión contiene los elementos dramáticos, muchas veces implícitos, y es el actor el que interpreta cómo plasmarlos en cada momento con su actuación, teniendo en cuenta la construcción de la escena y de los propios personajes. Dicho de otro modo, el actor, al menos el que es bueno, no es una marioneta manejada con unos hilos, sino un profesional que sabe hacer su trabajo específico mejor que el guionista, el director o el técnico de iluminación.

¿Cuales son las razones por las que la mayoría de los documentos de diseño pecan de ser demasiado técnicos? Tadhg Kelly comenta que uno de los motivos principales es la paranoia que sufre el diseñador, que siente no disponer de suficiente poder de decisión dentro del equipo de desarrollo.

Eso le hace dudar de si su trabajo será respetado por los profesionales que se encargan de la implementación técnica. Cómo medida de defensa, el diseñador supone que si especifica absolutamente todos los detalles técnicos que afectan a su diseño, está reduciendo la probabilidad de que el resto de profesionales puedan interpretar cómo implementar la feature, poniendo en riesgo que la feature acabe funcionando como el diseñador quería.

En la práctica, esto supondrá que el diseñador acabe metiéndose a menudo en berenjenales técnicos de donde no sabrá salir, y en los que sus lógicos errores harán desconfiar al programador que esté leyendo el documento de la validez del propio diseño. Y lo peor no es que la percepción que tiene el programador del diseñador empeora, sino que los propósitos de juego que el documento pretendía plasmar pasarán probablemente inadvertidos debajo de una fallida exhibición de conocimientos técnicos.

Para solucionar el problema anterior, Tadhg Kelly comenta que el arma principal con la que debe contar un diseñador es la comunicación. Con ella debe transmitir de modo claro y detallado al resto del equipo cuál es el propósito de cada feature y cómo va afectar a la experiencia de juego.

En mi opinión, esto es bastante más importante que el conocimiento técnico que tenga; y lo es simplemente porque la especialización del diseñador en este tipo de conocimiento es lo que le va a permitir ser más eficaz en lo que realmente debería saber hacer mejor que cualquier otra persona del equipo de desarrollo.

Una de las citas más significativas en relación a este tema, creo que la leí en el libro Game Architecture and Design, es la que dice algo como que “el programador no puede ver el bosque por culpa de los árboles, mientras que el diseñador no puede ver los árboles por culpa del bosque”. Si metemos al diseñador a buscarse la vida en medio de la maleza técnica, en la que además siempre estará en inferioridad respecto a los nativos (los programadores), será más difícil que pueda concentrarse en conseguir que el juego mantenga la visión con la que fue concebido, lo que debería ser su principal objetivo.

Ojo, esto no significa que el diseñador se convierte en visionario soñador que se dedica a lanzar conceptos inaplicables y a esperar a que las primeras versiones jugables del juego le muestren el camino que no ha sabido anticipar. Lo que significa es que el diseñador centra toda su capacidad intelectual en detallar el funcionamiento que tendrá el elemento cuando el jugador esté interactuando con él, no cuando el programador empiece a programar la feature.

Esta tarea incluye lógicamente detallar tanto como sea posible cuales son los elementos que definen el funcionamiento de estas mecánicas de juego (sistemas de reglas, parámetros que deben controlarse...), pero no hacer un intento de tutorial que el programador acabará ignorando por sus lagunas técnicas.

No voy a alargarme tratando de encontrarle puntos negativos a esta concepción del documento de diseño (de esto ya os encargaréis vosotros :P). Por el momento, sigo pensando que deberíamos replantearnos qué es lo que necesitamos de los diseñadores y de sus documentos.
Mostrar/ocultar resto...