Del género de rol: El sistema de clases

En este artículo me gustaría tratar algunas cuestiones sobre los RPGs, y concretamente de uno de sus aspectos, basándome en mis experiencias: El sistema de clases.

Hace no demasiado, jugando al WoW, me metí en un grupo que iba a una instancia de alto nivel. Todo fue bien hasta que matamos a un boss, que dropeó un anillo interesante. Este anillo tenía algunas características que me parecieron útiles, así que seleccioné ‘lo necesito’. El resto del grupo seleccionó ‘No lo necesito’, y me lo llevé. Ahí comenzó el lío.

Inmediatamente el tanque del grupo, un rogue, me acusó de haber ninjeado el anillo. Decía que, considerando las características de este, era más indicado para tanques, y yo era un caster (un warlock, para más señas). Y no es que él lo necesitara, de hecho decía tener uno mejor, pero yo había ‘robado’ un objeto que no correspondía a mi clase, y era un miserable ninja (en realidad usó otra palabra más contundente).

Al día siguiente consulté a mis ‘gurus’ del WoW, y estos me confirmaron que, independientemente de los malos modos de aquel tipo, yo había cometido un error cogiendo ese anillo, ya que sus características eran para tanques, y que no me correspondía cogerlo. Supongo que tienen razón: el anillo daba estamina, defensa y armadura. Ideal para tanques.

Sin embargo, pienso que en un juego llamado de rol, mi decisión debería haber sido aceptable. La libertad de decidir es crucial en el rol, y a mí lo que me gusta de los MMORPGs es hacer misiones en solitario. Soleando con un caster la estamina me interesa (siempre tenemos muy poca). La armadura también me venía bien (de nuevo los casters tenemos muy poca). De hecho, pese a que he seguido mejorando mi equipo, todavía sigo usando ese anillo. Pero eso no quita para que fuera una mala decisión social de cara al grupo, ya que en el WoW los casters deben ajustarse a su papel, y coger objetos de acuerdo con su clase.

Con todo, y a nivel teórico, un juego de rol consiste básicamente en crear un personaje único, y tomar decisiones. Siendo así ¿porqué debo ajustarme a unos caminos pre-establecidos? Desde luego, aquel objeto había sido diseñado para que lo usaran unas clases concretas, pero ¿es un delito configurarte tu personaje de un modo diferente al pre-diseñado? Quizá mi personaje sea más poderoso usando objetos específicos para él, pero creo que debería ser lícito no solo equivocarse, sino también permitir a los jugadores que especialicen sus propios personajes en base al equipamiento.

Por lo que he visto, no solo en el WoW, sino en otros juegos esto parece no caber en los planes de los diseñadores. En una etapa muy temprana del gameplay (generalmente al principio del juego) tienes que escoger una clase, y ceñirte a ella.

Durante un par de años jugué al Star Wars Galaxies, hasta que me harté de la incompetencia de sus desarrolladores. Uno de los elementos que me gustó del diseño original (rediseñaron el juego dos veces) consistía en que los jugadores no tenían que elegir clase. Tu personaje aparecía en el mundo, y había 32 profesiones a elegir, cada una con sus propias habilidades. Éstas estaban accesibles a todos los jugadores, y podían ser desarrolladas por partes. De este modo los jugadores podían elegir configurar sus personajes con algunas de las habilidades de las profesiones, las que más les gustaran. Este sistema te daba una sensación única de personalización de tu personaje, y era muy apreciado. Creo que es el único rol en el que he visto esta posibilidad.

De acuerdo, este razonamiento falla en la implementación. Los sistemas de clases son muy funcionales para los diseñadores, ya que permiten encapsular las habilidades y balancearlas mejor. De hecho, el SWG terminó por abolir ese diseño original, ya que cada vez que modificaban una profesión desbalanceaban el resto (siempre tendré la duda de si esto sucedía porque el sistema era erróneo en su concepto, o porque los diseñadores de dicho juego eran unos paquetes. Y creedme cuando os digo que son MUY paquetes).

Para terminar de rematar este problema con las clases, la elección de ésta se suele hacer muy al principio del juego, y los diseñadores, en un intento de salvaguardar la inmersión del producto, suelen describir las habilidades de cada clase de una manera muy ambigua, y decididamente poética, del estilo ‘esta clase permite una comunión con la naturaleza, aprovechando el poder de los elementos en tu ventaja’. ¿Qué puñetas significa esto? Dado que toda la experiencia de juego está asociada a la clase, esta elección capital se hace demasiado pronto y con demasiado poca información.

Yo comencé a jugar al WoW cuando salió a la venta en España, y para mi desgracia seleccioné para jugar dos clases ‘problemáticas’, al menos al ser aplicadas a mi manera de jugar. El druida es muy polivalente y difícil de matar, pero si no lo manejas muy bien tarda horrores en eliminar a sus enemigos. Subes niveles más lentamente que con otras clases. El warlock es una clase muy agradable cuando ya tienes cierta experiencia en el juego y tienes el suficiente dominio como para controlar no solo a tu personaje sino a un pet. Sin embargo, de entrada, requiere un control demasiado refinado para un principiante.

Como consecuencia de todo ello dejé de jugar, ya que el juego me resultaba frustrante. Lo retomé en fechas cercanas, y solo gracias a que tuve consejo constante por parte de jugadores más veteranos. Al inicio, yo hubiera agradecido más información sobre el auténtico gameplay de cada clase, más que textos genéricos de ‘esta clase domina las fuerzas oscuras’.

Supongo que, en definitiva, al diseñar un juego de rol un desarrollador tiene que tomar una decisión de peso: ¿permito al jugador crear un personaje único (lo cual puede terminar en que el jugador termine configurando una combinación tan extraña que no haya sido correctamente balanceada) o lo dirijo por unas pocas sendas seguras y perfectamente balanceadas?

Aparentemente, todos los desarrolladores optan por la segunda opción. Pero no puedo evitar el pensar cómo me gustaría que alguien optase por la primera opción, y además funcionase.Mostrar/ocultar resto...

Una propuesta metodológica: Patrones en el Diseño de Juegos

Hace algunas semanas un compañero de trabajo nos recomendó insistentemente un libro de diseño (no hace falta que diga que en inglés) que, según él, le había resultado extremadamente útil en su labor como diseñador. No tardamos en conseguirlo y procedí a leerlo con avidez, buscando en él las ansiadas respuestas a las sempiternas preguntas del diseño (para más referencias, acudir a cualquiera de las numerosas discusiones que ya se han vivido en este mismo lugar)

El libro en cuestión se llama "Patterns in Game Design" y, aunque por ahora no me ha resultado tan milagroso como a mi compañero, creo que sí que merece la pena echarle un buen vistazo o, al menos, saber qué es lo que plantean sus autores.


Los libros o artículos de diseño que me he encontrado hasta ahora suelen adolecer, siempre hablando en general, de algo que podría llamarse con un poco de mala fe, "utilidad". Entiéndase "algo útil" como "algo que tiene uso práctico". Vamos, que mucha teoría, mucho pensamiento profundo y filosofía del juego, pero luego uno se pone a escribir un documento de diseño y piensa algo así como "¿y ahora cómo puedo utilizar la narrativa interactiva, el viaje del héroe y la definición de "fun" para esto, precisamente esto?"

Lo que considero más interesante de este libro es que lo que persigue es un uso práctico. Para poder llegar a este uso necesita hacer una serie de consideraciones teóricas y definir unos cuantos conceptos, pero estoy muy acostumbrado a escritos que se quedan solamente ahí. "Patterns in Game Design" construye un herramienta y la cede al lector. Como siempre, te puede gustar más o menos, le puedes encontrar mil usos o ninguno, pero al menos te da una herramienta con la que te puedes poner a experimentar.


La herramienta, como habréis adivinado, son esos "patterns", a los que inmediatamente voy a rebautizar como patrones. Un patrón es algo que puedo incluir en mi juego y que va a modificar el resultado, la jugabilidad final del mismo. Dicho de otra manera, es algo que no puedo añadir a mi juego sin más, de manera inconsciente, porque en cuanto lo añada mi juego va a sufrir un cambio y, si de verdad soy un diseñador, debo decidir si ese cambio va a beneficiar a mi juego, si es algo deseado para llevar el juego al lugar que yo quiero.


Antes de seguir, os pondré un ejemplo, tosco pero pienso que válido, para que os hagáis una idea de lo que es un patrón.

Imaginaos que tengo, por un lado un juego de tablero como las damas, el go o el backgammon, y lo comparo con el ajedrez o el stratego. Evidentemente son juegos muy diferentes, pero yo me voy a centrar sólo en una cosa, en un patrón: "habilidades asimétricas" (las piezas de los primeros juegos tienen todas las mismas habilidades, pero un caballo no es igual que una torre, ni una bomba igual que el mariscal).

"Habilidades asimétricas" es un concepto que, de incluirlo en mi juego, lo va a afectar indefectiblemente. Podrá afectarlo en mayor o menor medida, depende de cómo yo lo use, pero es algo que nunca va a dejar inmutable la jugabilidad, es algo que va a variar la experiencia de juego final (como algo jugable; aquí no hablo de experiencia estética, emocional ni nada por el estilo, aunque como es natural ésta también puede verse afectada).

Igual que "habilidades asimétricas", puedo mencionar otros patrones cualesquiera, como "rey de la colina", "contenedor", "rejugabilidad", "economías cerradas", "puntos de spawn", "alianzas"… que creo que terminan por ilustrar, grosso modo, lo que es un patrón.


El libro además no sólo se limita a definir, clasificar y enumerar los patrones sin más, sino lo que es muy interesante, los relaciona entre sí, creando un gran entramado de patrones. Este entramado está generado exclusivamente a partir de de tres tipos de relaciones: "instanciación", modulación y conflicto.

Como adivinaréis por los nombres, la primera asocia a aquellos patrones que, con su mera presencia, provocan la aparición de algún otro. Por ejemplo, si yo introduzco el patrón "localizaciones estratégicas", automáticamente estoy introduciendo "memorización"; éste, a su vez, podría introducir otro nuevo, etc.

La segunda establece qué patrones pueden actuar como moduladores, modificadores, de otros; es decir, qué patrones, una vez introducidos, alterarán la manera en que estos otros afectan al juego. Así, introduciendo "daño", podemos alterar la forma en la que el patrón "vidas" afecta a mi juego.

La última relación nos indica que patrones son potencialmente incompatibles con otros, siempre bajo ciertas circunstancias. Si incluyo "muros invisibles" en mi juego puedo encontrarme problemas si quiero mantener también "lógica de realidad coherente"

En resumen: partiendo de un patrón cualquiera, los autores nos indican qué otros patrones se instancian, qué otros patrones se modulan, que patrones pueden modular a nuestro patrón, qué patrones pueden instanciarlo y qué patrones pueden entrar en conflicto con él. En el siguiente diagrama quedan ilustradas todas las relaciones:

A través de estas relaciones, siempre a juicio de los autores, podemos conocer las implicaciones que la presencia de cierto patrón tendrá en nuestro juego. Podemos encontrar información del tipo "si incluyo el patrón 'A', resulta que voy a introducir 'B', que resulta que es incompatible con 'C'" o "usando 'X' e 'Y' puedo modificar 'Z', quizá sea interesante incluirlos"


Ya sabemos, más o menos, lo que son los patrones y las relaciones que hay entre ellos. Aunque estoy convencido de que a muchos ya se os ocurren diversas maneras de emplearlos, voy a referenciar las que mencionan los autores.

Por un lado estarán aquellas que utilizan los patrones como herramienta de análisis (deconstructiva, dirían otros). Esto es, podemos usar los patrones para diseccionar la jugabilidad de un determinado juego, prototipo o modelo, ya sea partiendo de su diseño o experimentándolo directamente. Este proceso de análisis nos puede ayudar a comprender los pilares sobre los que se asienta determinado juego, a relacionar juegos entre sí, a aprender como la inclusión de un patrón concreto, o incluso una pequeña modificación, puede dar un resultado muy diferente,… en fin, a un gran número de posibilidades bastante interesantes.

Por el otro lado estarán las que los utilizan de manera constructiva, bien sea agrupando patrones para generar conceptos de juego, para desarrollar un juego o un diseño ya existente añadiendo, quitando o modificando patrones, para conseguir obtener algún tipo de jugabilidad concreta que se nos resiste, etcétera.

Por último, los patrones también pueden emplearse como herramienta de comunicación, como glosario de elementos de juego. El tema de El Glosario Único y de lo útil que sería creo que da para, al menos, otro artículo, así que lo voy a ahí y no voy a entrar a extenderme en él.


Personalmente, creo que son una gran herramienta para explorar nuevos conceptos de juego y ya los he utilizado efectivamente para entrever las dependencias o incompatibilidades que ciertos elementos de nuestro diseño pueden tener con otras partes del juego. También me han ayudado a mirar aspectos de los videojuegos más recientes de una manera más analítica, separando la jugabilidad pura y dura que, a fin de cuentas, es la que más me interesa, de la envoltura estética o funcional.

No me queda más que deciros que además los autores animan a generar patrones propios o a modificar los existentes si alguno no nos gusta o nos parece que no está bien planteado, no mostrando en ningún momento ningún afán de posesión de su herramienta. La inclusión de un CD con el libro, en el que podemos encontrar en formato html todos los patrones, usando los hipervínculos para ir de unos a otros, es, además de una eficiente manera de trabajar con ellos, una manera fácil (y económica) de acercarse a esta propuesta metodológica que, realmente, creo que merece la pena conocer.
Mostrar/ocultar resto...

De la influencia del cine en los videojuegos

El cine siempre ha ejercido una poderosa influencia sobre los desarrolladores de videojuegos. Atraídos por el glamour y las similitudes entre ambos medios, muchos creadores han buscado y buscan referencias en las películas. Esto ha permitido a muchos juegos dar un salto de calidad y marcar diferencias contra otros productos, pero también ha creado un buen número de malas prácticas que se han enquistado, y que es difícil extraer de los diseños actuales.

En este artículo me gustaría repasar aquellos que más me han llamado la atención (o incluso he sufrido):

- Las cutscenes: Tradicionalmente el préstamo más evidente del cine a los videojuegos. A excepción de las de los Final Fantasy (para mí lo único salvable de esta serie), muchas son pobres y excesivamente abundantes, incluso metidas con calzador. Una cutscene suele obligar al jugador a mirar la pantalla sin poder interactuar con nada. Creo que el Half Life 2 demostró que se pueden construir historias sin cutscenes, y resultar doblemente inmersivo.

- Creer que el jugador de videojuegos los consume como en una sala de cine: El espectador que ha pagado la entrada se queda en la sala hasta el final de la película (en general). Pese a que los videojuegos suelen ofrecer entre 5 y 10 veces más horas de ocio, muchos creadores enfocan sus diseños como si se tratase de una película. Esto suele conducir a malas prácticas de diseño:

1- Hacer videojuegos con historias tan complejas que requieren ser jugados del tirón: El KOTOR es un juego MUY largo. Además, tiene una trama principal tan densa y tantas tramas secundarias que, tras dejar de jugar unos meses, olvidé lo que se suponía que tenía que hacer y porqué lo estaba haciendo. Me costó bastante retomar el hilo de la historia. Hubiese agradecido que las misiones (y sus tramas) fuesen más episódicas.

2- Reservar lo mejor del juego (las emociones más fuertes, los enemigos más impactantes, las situaciones más espectaculares) para el final de la historia (el clímax) y por tanto el final del juego: En el cine hay que esperar apenas dos horas para que ese momento llegue, pero en un videojuego pueden ser más de 15. No todos los jugadores llegan a ese punto, y es un desperdicio de esfuerzo el que solo un puñado vean lo mejor del juego. Yo recomendaría prestar más atención al inicio del juego ya que, lamentablemente, es todo lo que muchos jugadores van a ver.

- La omnipresencia de la historia, aunque perjudique a la jugabilidad: Tengo esta sensación especialmente en muchos juegos japoneses, que ponen un desmedido interés (lo que incluye cutscenes, diálogos y textos) en contarte una historia generalmente mejorable. Este interés desmedido por la historia me hizo dejar los Metal Gear, ya que de tanto texto mi impresión fue que la jugabilidad estaba basada en charlar con la operadora. En muchas ocasiones no necesito saber las motivaciones de los que raptaron a la princesa. La rescato y punto. Yo animaría a los creadores a reflexionar sobre hasta qué punto necesita su juego una historia, o basta con un ‘Fight!’.

- La obsesión por los ‘momentos’ cinematográficos: En muchos juegos se pone mucho interés en crear momentos dramáticos (generalmente cutscenes, o situaciones escriptadas ingame) que sean impactantes (sí, F.E.A.R., te hablo a ti). No me parece una mala práctica, pero creo que el ‘lenguaje’ del videojuego debe estar basado en la interacción, no en la contemplación. Creo que se deberían explotar más los momentos interactivos. Ninguna cutscene me creó tanta tensión como desplegar mi ataque final contra los Zulúes en el Civilization. Mi propuesta en este sentido se basa en la combinación: en el CoD 2 mis momentos favoritos fueron aquellos que combinaban una situación escriptada con la posibilidad de interactuar, como tomar parte en el asalto de las playas de Normandía.

- Tendencia a la presentación ‘cinematográfica’ de los personajes: Estos suelen introducirse en la historia a través de diálogos, cutscenes o descripciones, en lugar de interactuando con ellos. El cine no puede hacer esto. Los videojuegos sí. No necesito realmente que me digan que mi NPC compañero de equipo tiene una personalidad agresiva a través de un message box, una cutscene y 8 líneas de diálogo, si en lugar de ello en la primera ocasión que actuamos juntos destruye 100 aliens con su lanzagranadas.

- La lucha por alcanzar el realismo visual del cine: No lo critico, desde luego. Hasta ahora hemos estado limitados por el hardware para lograrlo, y acercarse a ese límite es deseable y sin duda vende. Sin embargo en un futuro, cuando el fotorrealismo se haya logrado, espero que el público comprenda que el valor fundamental de los videojuegos se basa en la interactividad. Hoy en día salen muy pocos juegos que ofrezcan una experiencia realmente original.

Con todo, y pese lo anteriormente mencionado, me gustaría acabar diciendo que pese a las malas herencias del cine, hay muchas cosas que podemos aprender de esa industria. ¿Cuáles? Bueno, yo animaría a los diseñadores a buscar sus propias respuestas.

La mía sería el acercarnos al formato de ocio que el cine ofrece. A día de hoy un juego suele ofrecer en torno a las 15 horas de juego. Pocos jugadores llegan a jugarlas todas (asumiendo que no seas japonés). Yo trataría de hacer juegos más cortos, más sencillos y más baratos:

- Hacerlos más cortos tiene una mejor cabida en el día a día de los usuarios. Hoy los videojuegos pelean con muchas otras opciones de ocio, y (a excepción de la literatura) los juegos son la que exige más tiempo.

- Hacerlos más sencillos para todos los públicos (sin descartar incluir desafíos para jugadores más hardcore) debería garantizar que se juegue un mayor porcentaje del propio juego.

- Hacerlos más baratos debería garantizar que se consuman más juegos de gama media, y no solamente los Blockbusters. No tengo problema en que haya un GTA, pero para mí es el equivalente a Titanic. Y no te puedes estar todo un año viendo Titanic. Porque de vez en cuando, seamos honestos, también apetece ver Torrente.Mostrar/ocultar resto...

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...

De la frustración en los videojuegos

Tengo en mis manos mi copia del GTA San Andreas. Fallo por enésima vez una de las misiones del inicio, y decido que le estoy dedicando unos minutos de mi vida que nunca volverán, y que no me están resultando provechosos en absoluto. Trazo una parábola con la mano y el juego vuela hacia la papelera en bullet time. Stop. El juego flota en el aire.

Antes de que caiga en el olvido, me gustaría hacer un breve recorrido personal sobre aquellas fuentes de frustración que me han resultado más comunes:

- Mecánicas hostiles hacia el jugador: Me refiero a sistemas deficientes de salvado/checkpoints, penalizaciones excesivas sobre los recursos del jugador (vida escasa/munición insuficiente), o escasa información en el juego para afrontar los desafíos.

En el Shadow of the Colossus no te dan mucha información sobre cómo matar a los colosos. Unas pistas muy confusas, todo lo más. La única solución efectiva era… si, amiguitos, echar horas probando tácticas hasta dar con la apropiada, mientras mi barra de ira crecía exponencialmente. Me negué, y me pasé el juego gracias a un walkthrough de internet.

- Una única solución: Al hilo del punto anterior, muchos diseñadores proponen situaciones de juego al usuario que solo pueden ser superadas de un modo, situaciones en las que es fácil quedarse ‘bloqueado’ porque no das con esa maldita manera de pasar la fase. En estas situaciones los diseñadores se lo pasan mejor que el jugador, regodeándose por anticipado de las dificultades del desafío.

El limitarse a una única solución suele llevar aparejado otro problema: dado que solo hay una manera de solucionar el desafío, los diseñadores tratan de ocultar la solución para que el jugador no lo vea fácilmente, el reto sea mayor. En Half life 2 me quedé atrancado en un portón que no se abría. Le disparé, traté de saltar sobre él, lo ingravité, le lloré y supliqué. Nada. Resultó que la solución era relativamente sencilla, pero estaba oculta y no había ninguna pista que te condujera a ella.

- Dobles y triples penalizaciones al morir: De acuerdo, has muerto. Es aceptable ser penalizado. Pero ¿cuánto? En el Diablo, al morir no solo se interrumpía la acción, sino que perdías tu (trabajosamente ganado) equipamiento, debías volver al lugar de la muerte para recoger el equipo, y algunos de los objetos, por su escaso tamaño, eran difíciles de localizar (forzando al pixel search), especialmente si había una tribu de esqueletos saltando sobre tu espalda.

A los chicos de Blizzard este suplicio les debió parecer tan apropiado, que lo perpetuaron en el World of Warcraft, donde consumes una escandalosa parte de tu tiempo de juego buscando tu cadáver por Azeroth.

- Demasiados parámetros: Muchos juegos, especialmente los de estrategia, basan parte de su jugabilidad en centenares de parámetros que el jugador debe gestionar. Si se confunde complejidad con profundidad, puede conducir a dos problemas:

• La cantidad de datos a manejar es tan elevada que el diseñador decide que muchos no trasciendan al jugador para no agobiarle. Son los casos, como decía Sid Meier, en los que la máquina se lo pasa mejor que el jugador.

Como experiencia personal, puedo apuntar que en Imperial Glory el sistema de combate se basaba en un número importante de parámetros, que optamos por simplificar a 4 de cara al jugador para no liarle. Pero pese a que en la superficie el río parecía tranquilo, en la profundidad del código había tantos parámetros en juego que muchas veces sucedían… cosas inesperadas.

• La cantidad de datos es elevada, y todos están disponibles para el jugador. La consecuencia es una impresión inicial abrumadora, y una experiencia de juego basada en gestionar números, más que en divertirse. Si has jugado a cualquier rol basado en las reglas AD&D sabrás de lo que hablo.

- Descubrir que tu juego es otro: Juegas, terminas el juego incluso, y entonces descubres que el juego tiene un universo de cosas que puedes hacer que ni sospechabas.

Yo completé el Indiana Jones y la maldición de la Atlántida sin sospechar siquiera que había otros 2 finales. La elección no estaba lo suficientemente clara, era un diálogo como tantos otros, y eso me privó de la posibilidad de disfrutar plenamente de mi juego.

- Finales pobres: Un problema heredado de los años 80, cuando no había memoria suficiente para permitirse muchas alegrías. Actualmente, me parece innegociable: los jugadores que se han esforzado lo suficiente como para terminar el juego deben tener una recompensa adecuada al esfuerzo. Qué menos que un vídeo, una cutscene cuidada o desbloquear algún contenido interesante.

- Pulsad, pulsad malditos: Como punto de partida no estoy en contra de la mecánica de machacar botones. En algunos juegos está bien integrada. Sin embargo, el exceso conduce a situaciones no solo de frustración, sino directamente de riesgo para la salud. Recientemente el God of War me costó muchos ruegos al cielo para que las escenas de destrozar el pad terminaran cuanto antes, y aunque nunca fueron excesivamente largas, sí lo fueron para mi gusto. Fue una de las razones por las que no seguí jugando.

- English only: Sin ser mi caso, me solidarizo con los miles de usuarios no-angloparlantes. Muchos juegos se lanzan en España sin una localización apropiada, y fuerzan a sus compradores a un curso acelerado de inglés para el cual ni están preparados ni necesitan. Durante años fui el traductor de mi guild en el Star Wars Galaxies de los textos de las quests. Y como no podía ser de otra manera, los desarrolladores habían tenido buen cuidado de que estos textos fuesen interminables, confundiendo cantidad de texto con inmersión.

- Controles imposibles: Muchos juegos exigen del jugador un manejo de los controles solo accesibles para el Dr. Octopus. Es muy habitual en juegos de estrategia, en los que prácticamente todo el teclado tiene una función. Se podría pensar que es un problema exclusivo del PC, pero salta con cierta frecuencia a las consolas: el sistema de reconocimiento de voz de la Nintendo DS es deficiente, y ya veremos los juegos de la Wii…

Es por este tipo de mecánicas que sospecho que Hitler sigue vivo, y encontró trabajo de diseñador. En fin, el GTA vuelve a recuperar el movimiento, y cae a la basura, lugar al que pertenecen algunas de sus mecánicas y (que dios me perdone, porque sigo pensando que el GTA es uno de los conceptos de diseño más prometedores que he visto jamás) algunos de sus diseñadores.Mostrar/ocultar resto...

Flexible complejidad

Ya he leído el documento de diseño, hablado con los diseñadores y discutido con ellos cómo debe funcionar el sistema de alerta de los enemigos. En principio, es algo tan sencillo como que si ven al jugador, su nivel de alerta cambia de "patrulla" a "persecución", te buscan durante un rato y si te encuentran, te atacan, mientras que si consigues despistarlos, vuelven al estado de patrulla al cabo de un tiempo. Suena bien, es lógico y razonable, y la mayoría de los juegos funcionan así. Satisfecho y confiado me dirijo a mi puesto a implementar la funcionalidad.

Lo primero que observo es que no está claro lo que significa "ver" al jugador. Me entran las dudas de si será necesario algún tipo de cono de visión. O si también se podrá detectar al jugador oyéndolo, sin verlo. Es muy probable que los diseñadores quieran controlar externamente cuándo un enemigo está autorizado a ver al jugador y cuándo no. Además por supuesto, se deben poder configurar parámetros como distancia de visión, máximo ángulo vertical y horizontal, etc. Se me ocurre que será interesante también tener en cuenta si algún elemento externo afecta la visión de los enemigos, como el jugador destruyendo bombillas o lanzando una bomba de humo. Lo mejor será preparar un componente de percepción sensorial, que los enemigos usen. Dicho componente tendrá una lista de servicios genéricos que se registrarán en el mundo lógico para recibir eventos. Los eventos atravesarán una serie de filtros abstractos que se podrán añadir para restringir rangos y ángulos, u otras circunstancias como oscuridad o paredes que obstruyen tanto vista como oído. Para conseguir la funcionalidad básica, empezaremos por implementar el servicio de visión, y aplicaremos un filtro para detectar si la visión está obstruida que consista en lanzar un rayo contra el posible objetivo.

Claro, pero aunque el objetivo normalmente sea el jugador, es posible que queramos que los enemigos luchen a veces entre si. Necesitaré organizar los personajes en bandos, en facciones. Asociar cada uno a un bando y un grupo, y luego definir en algún sitio centralizado las relaciones entre ellos, si son enemigos, aliados o neutrales. En cada actualización de la percepción, los personajes evaluarán su entorno usando el sistema de percepción y podrán clasificar a los otros personajes según su bando. Además, las relaciones entre ellos pueden cambiar fácilmente durante el juego, así que puede haber alianzas inesperadas, o nuevos enemigos o compañeros para el jugador. Suena bien, ahora a ver cómo deben reaccionar.

Una buena forma de estar preparado por si en el futuro es necesario incorporar nuevas o diferentes reacciones es implementar un traductor, que convierta los estímulos externos recibidos por la percepción en estados emocionales del personaje. Así, si ve a un enemigo, podemos incrementar su hostilidad, aunque si el enemigo viene muy bien preparado, también afectará a su miedo. Con este sistema, debería ser fácil poner a los enemigos a huir del jugador, si hiciera falta. La implementación la haré usando un mapa cognitivo. Definiremos una lista de estados emocionales, y cada posible evento percibido llevará asociado su efecto, positivo o negativo, sobre dichos estados. También podemos relacionar unos estados con otros, de modo que si la hostilidad sube por encima de cierto valor, el miedo baja o desaparece para simular que el personaje está tan furioso que no le importa ni su integridad física. Por supuesto, los estados emocionales no son un absoluto. Uno no se siente enfadado en general, lo está con algo. Los estados emocionales por tanto deberán ir asociados a los elementos percibidos en el mapa.

Y no basta con trabajar con los personajes que estan siendo percibiendo en un momento dado. Es necesario mantener algún tipo de memoria del pasado, para que aunque pierda a un enemigo de vista el personaje recuerde que debe seguir tratando de acabar con él. Así, los elementos emocionales, con sus estados asociados, perdurarán en el tiempo. Si no se refrescan siendo percibidos directamente, una rutina especial se encargará de afectar a los estados emocionales hasta que acaben olvidando haber percibido el elemento. Esto servirá para que pasado cierto tiempo de ver al jugador, si no le ven de nuevo, dejen de perseguirle.

Ya sólo falta alguna manera de conectar estados emocionales a comportamientos. Eso será fácil con una máquina de estados controlada por los valores emocionales. Según ciertos rangos de valores, el personaje pasará de un estado a otro. Habrá que incorporar cierta histéresis, de modo que si pasamos a un estado (atacando) porque la hostilidad es 20, no volvamos al estado anterior en cuanto la hostilidad descienda a 19, sino que esperemos a un valor algo menor. Así evitaremos oscilaciones de comportamiento. Pero además de la máquina de estados necesitaremos un mecanismo de arbitraje, ya que tendremos varias máquinas corriendo en paralelo, evaluándo como reaccionar a todos los elementos detectados en el mundo. Hará falta un sistema por encima que mediante reglas o puntuación elija uno de los elementos, y haga que el personaje ejecute las acciones correctas para tratar con ese elemento.

Estoy empezando a pensar la lista de comportamientos (el de persecución lo pensaba hacer mediante filtros de partículas, que extiende una lista de puntitos por todo el mapa y hace que el personaje los vaya recogiendo, para hacerlo muy realista), cuando viene un diseñador y me pregunta cuándo podrá tener el sistema de alerta para probarlo.

- Pues dejame que mire, hmmm, dos semanas para el sistema de percepción, una para los bandos, tres para el mapa cognitivo, una la memoria, dos para la máquina de estados y una para integrar todo. Dos meses y medio. Eso sin contar el comportamiento de persecución, pero podrás ver que el enemigo está intentando perseguir al jugador porque aparecerá un texto encima de la cabeza.
- No lo entiendo. ¿Cómo puede tardar tanto? Parece algo sencillo.
- Si, pero no se trata de implementar simplemente lo que necesitais ahora. Voy a montar un sistema que facilitará cambios y nueva funcionalidad más adelante.
- Ya veo. ¿Y cuanto costaría hacer exactamente lo que necesitamos inmediatamente?

Pienso durante un rato. Habría que lanzar un rayo contra el jugador mientras el personaje está en el estado de patrulla. Si el rayo golpea al jugador, cambio el estado a persecucion y empiezo a ejecutar el comportamiento, mientras mantengo un contador cada vez que pierdo al jugador de vista. Si el contador llega a un límite, vuelvo a cambiar el estado, pero si tengo el jugador a tiro empiezo a atacarle.

- Una semana. Incluso daría tiempo de montar un sencillo comportamiento de persecución que se dirigiera a tu posición directamente.

El diseñador permanece en silencio durante un momento.
- Bueno, tú sabes lo que es mejor, pero dos meses y medio parece excesivo. - Se da la vuelta y vuelve a su sitio pensativo.

Y pensando también me quedo yo, cuestionando si realmente necesito toda la flexibilidad que había creído en un primer momento. Es fácil dejarse llevar por el ansia de cubrir todos los casos, de modelar las cosas siguiendo patrones de diseño y técnicas establecidas y generales. ¿Pero es esa realmente la mejor forma de desarrollar juegos? Antes de hallar una respuesta descubro que es la hora de ir a casa. Creo que lo consultaré con la almohada, y mañana veremos.

Mostrar/ocultar resto...