De la dificultad en los videojuegos

Imagina que vas al cine. Decides ver una superproducción, de gran presupuesto, que promete diversión sin límites. Pagas tu entrada y comienza la película.

Al principio la historia es interesante. Te engancha. Sin embargo pasada la media hora de metraje la trama se hace más compleja. Los personajes parecen hablar en una clave que desconoces, y los planos son tan oscuros que apenas te dejan ver qué está sucediendo.

¿Qué diablos está pasando? Bueno, es una gran producción. Quizá sea problema tuyo, quizá no prestas la suficiente atención. Te concentras en la pantalla para que nada se te escape.


Pero no es suficiente. Un rato después la trama es pura cábala, y los diálogos están en sánscrito. Te has perdido. Miras a tu alrededor y la mayoría de los espectadores parecen estar en tu misma situación. Con todo, hay un par de tipos en la sala que siguen la historia con pasión creciente, se ríen cuando tú no entiendes nada y te miran con cara de ‘pobrecillo, no está a nuestra altura’.

Llegados a este punto, el acomodador se te acerca y te dice: ‘Muy buenas, señor. ¿Le importaría decirme qué es lo que está pasando en la película ahora mismo?’. Avergonzado, confiesas que no tienes ni idea. El acomodador, con cara de autosuficiencia, te dice: ‘Ah, pues lo siento mucho, pero debe abandonar la sala. No cumple usted con la capacidad mínima para seguir viendo esta película’.

El tipo te acompaña a la salida. Te sientes humillado. No eres lo suficientemente bueno para ver la película que has pagado. Desde luego no te devuelven la entrada, ya que es culpa tuya no estar a la altura.

Naturalmente, esta situación te parecería inaceptable si sucediera realmente. Pues en realidad es lo que sucede diariamente con el 70% de los videojuegos. Casi todos cuentan con un tutorial básico que te enseña los fundamentos del juego, pero conforme juegas la curva de dificultad de los mismos va aumentando hasta que el nivel de excelencia del jugador para seguir progresando es sencillamente excesivo.

Tomemos como ejemplo el GTA. Cualquier GTA. Llegado al 10% del juego la dificultad de las misiones es elevada. Nada insalvable, pero si no eres un jugador avezado vas a necesitar dedicarle horas a cada una de las misiones para poder progresar.

Como consecuencia de esto muchos juegos son abandonados cuando el jugador apenas ha empezado. Has pagado tu buen dinero por un producto que lo único que consigue es frustrarte. ¿Pagarías dinero por un juego para que este te deprima si no estás a la altura de Fatality (famoso jugador profesional)? ¿Qué sentido tiene el trabajo de un grupo de artistas, diseñadores y programadores que generan horas y horas de contenido, si luego este no lo va a ver nadie porque el juego es excesivamente difícil?

De acuerdo, el GTA comete un fallo: no puedes elegir niveles de dificultad. Otros juegos sí los tienen, y en teoría deberían garantizar que cada jugador elige el nivel que más le conviene.

Sin embargo la información sobre los niveles es prácticamente nula. ¿Cómo sabes si tu nivel es ‘fácil’, ‘normal’ o ‘difícil’ si no has jugado nunca antes? Depende de la apreciación de los diseñadores. En realidad suele ser mucho peor, ya que muchos juegos incluyen nombres denigratorios para algunos de sus propios niveles, del estilo nivel ‘para bebés’, nivel ‘mamá no me dejes solo’, o nivel ‘macho-man’. Naturalmente es difícil escoger el nivel para bebés sin sentir que el juego se está riendo de tí.

De hecho, en muchos juegos solo tienes acceso al arsenal completo de armas, mecánicas y contenido desbloqueable si juegas en el nivel ‘nightmare’. Aparentemente los niveles inferiores apenas son un entrenamiento, un trámite que tienes que cumplir antes de jugar al nivel de los ‘hombres’. ¿Conocéis a alguien que se juegue un mismo juego varias veces? Yo pocos, y solo si ofrecen una experiencia de juego sustancialmente distinta.

Desde luego, esta situación no se aplica a todos los jugadores. Seguro que conoces alguno que te dirá con una sonrisa de superioridad ‘¿No puedes pasarte esa fase? Pues yo me la pasé a la primera’. O también ‘Si, era difícil, a mí me costó varias horas, pero al final me la pasé’.

Estos son los llamados ‘hardcore gamers’, gente que, o bien tienen una habilidad superior a la media a la hora de jugar un videojuego, o no tienen problema en invertir horas y horas para completar un desafío.

¿Y por qué es así esto? Echemos la vista atrás, a los oscuros inicios del diseño de videojuegos…

En los años 80 el diseño de los juegos estaba hecho por hardcore gamers para hardcore gamers. Ningún desafío era suficiente, ningún nivel era demasiado difícil. Casi se diría que el objetivo era conseguir que solo 3 o 4 de los compradores del mismo llegaran al final. Los hardcore gamers son así, les gustan los retos cuanto más complejos mejor, ya que no les importa emplear días, semanas de su tiempo en superarlos, porque cuando lo consiguen se sienten en la cima del universo.

Sin embargo, con los años, el videojuego se ha hecho un hueco en la industria del ocio, y ha llegado a públicos masivos. Estos ya no solo son jugados por hardcore gamers. Los llamados casual gamers son mayoría, pero no tienen la dedicación o la pasión de los hardcore. Los casual gamers quieren pasárselo bien, e invertirán algunas horas de su vida en el juego, pero si este les provoca más frustración que diversión, dejarán de jugarlo.

Esencialmente, yo soy un casual gamer. Me niego a invertir ni una hora de mi vida en masterizar un preciso movimiento para evitar en cierto punto a un jefe de nivel. Yo juego para divertirme. Quiero pasarlo bien en cada minuto que invierto en el juego que he comprado. Si no lo hace, e insiste en complicarme la vida, el juego es catapultado a la papelera.

Naturalmente, debe haber desafíos. Nadie pide que los desafíos de los juegos sean tan sencillos que los conviertan en una actividad fútil. El desafío es la esencia de la diversión. Pero a la hora de enfrentarte a ellos deben estar balanceados para que cualquier jugador pueda afrontar ese desafío, y superarlo. Cualquier jugador.

Es por eso que, pese a gustarme enormemente el diseño, abandoné el GTA San Andreas al 13%. Es por ello que he tirado a la papelera docenas de juegos prometedores. Es por ello que creo que la industria está fallando a la hora de proporcionar a sus usuarios con una experiencia de juego asociada a sus necesidades.

Soluciones

Criticar es fácil, pero hay que aportar soluciones. A mi entender, los tradicionales niveles de dificultad no son suficientes. Por ello yo sugeriría a los desarrolladores explorar los siguientes caminos:

- La industria debería hacer juegos más sencillos, más cortos (y más baratos).

- Dificultad dinámica autoadaptable al jugador

- Los niveles de dificultad deben estar mejor adaptados. Por ello debería haber mayor dependencia de focus groups ajenos a los testeadores profesionales.
Mostrar/ocultar resto...

De números y juegos

Tras una épica batalla entre dos imperios de la era napoleónica en Imperial Glory, se generaba un pequeño fichero. En él se podía leer, entre otras cosas, que la tropa con id 17 había logrado matar a su enemigo con id 33 gracias a un disparo en el minuto 4:55, cuando tenía 14 unidades de fusileros. El disparo había tenido bonificaciones por la formación de línea, proximidad y ángulo de tiro. La penalización gracias a la formación del enemigo no impidió que sus 4 unidades murieran.

Toda esta información, y mucha más, se almacenaba en una base de datos, donde se acumulaban resultados de decenas de partidas. Mediante consultas, la base de datos podía proveer estadísticas, como cúanto daño había sido causado en distancia (mediante disparos), frente a daño de melée o de artillería, o el daño causado frente al daño recibido por las tropas de caballería en general. Se podía consultar por partida o haciendo medias de varias partidas.

El objetivo de este sistema era conseguir un entendimiento mejor de los "números" del juego, principalmente para poder balancearlo correctamente. No era la única ayuda que existía. Mediante una orden especial, el juego grababa un fichero .csv que se podía abrir con Excel, y que contenía el resultado de una simulación de enfrentar las tropas todas contra todas, probando todas las combinaciones posibles de 1vs1 y 2vs1. La tabla permitía no sólo ajustar la potencia de tropas similares, sino observar el efecto "piedra-papel-tijera" que se suele usar para evitar estrategias dominantes.

Aunque la tabla de enfrentamientos fue razonablemente útil, el uso principal de la base de datos de partidas fue encontrar bugs en los algoritmos de simulación de combate. No es algo desechable, desde luego, pero dista mucho de lo que un sistema de estas características parece prometer.

Cuando hicimos esa herramienta, tuvimos que elegir entre hacerla sofisticada y fácil de usar, o ahorrar algo de trabajo (que dedicaríamos a otras tareas). Optamos por la segunda. Todo el sistema, incluyendo la instrumentación del código, la generación del archivo por partida, la instalación de la base de datos MySQL y la implementación de una sencilla aplicación en MFC para acceder algo más cómodamente a la información costó menos de 2 semanas/hombre. La recogida de información era bastante completa, pero las herramientas de análisis eran primitivas, y requerían un buen nivel de conocimiento del lenguaje SQL para hacer consultas sofisticadas. Difícilmente podían los diseñadores acceder a estadísticas sin un programador presente.

No estoy seguro de si la falta de un interfaz más amigable fue lo que hizo que nuestro sistema básico de "data mining" no alcanzara todo su potencial. Por un lado, es posible encontrar información muy valiosa gracias a análisis de este tipo. Es posible detectar anomalías, como puntos de una misión donde los jugadores mueren con bastante frecuencia, armas que apenas son usadas o que no son todo lo efectivas que deberían, desequilibrios por el uso generalizado de unas pocas tácticas en detrimento de otras, etc. Pero por otro lado, los juegos de hoy son complejos. Quizás son tan complejos que tratar de extraer conclusiones aplicables mediante simples técnicas de análisis numérico o teoría de juegos resulta casi imposible. De ahí que el balanceo se siga haciendo principalmente mediante instinto, ensayo-error y muchas horas de jugar y observar a otros.

La experiencia de Imperial Glory me demostró que las herramientas automatizadas pueden servir para analizar y equilibrar elementos de bajo nivel, como enfrentamientos directos entre tropas uno contra uno. Sin embargo, el fracaso de nuestro intento de obtener información sobre "dinámicas", sobre los números del juego cuando varios elementos interactúan entre sí, puede ser indicativo de que existe un límite de lo que se puede categorizar matemáticamente, aunque no es de momento prueba definitiva. Yo sigo pensando que hay algo interesante en explorar ese camino, aunque no está claro cuánto trabajo hace falta para obtener fruto.

Mostrar/ocultar resto...

Me encanta que los planes salgan bien

Dado que este es un foro centrado, de momento, principalmente en diseño, voy a intentar explicar una de las tecnologías de moda dentro del campo de la IA, desde el punto de vista de cómo lo puede percibir un diseñador. Me estoy refiriendo a los sistemas de Planificación Automática.

Para empezar, un poco de historia, y algunas referencias. La planificación como tecnología de inteligencia artificial existe desde los años 70 (el primer planificador se llamaba STRIPS), aunque apenas se hablaba de ello en el ámbito de juegos hasta que Jeff Orkin, coordinador del grupo de investigación sobre planificación y objetivos de la IGDA, decidió usarla para desarrollar la IA de F.E.A.R. (presentaciones aquí). Ahora mismo, promesas de una IA más dinámica, más flexible y, sencillamente, más inteligente, junto con el santo grial de menos trabajo para el diseñador, hacen que se haya puesto de moda muy rápidamente.

La forma de trabajar con un NPC con planificador es ligeramente distinta a la que se ve hoy en día. Probablemente el diseñador esté acostumbrado a definir con bastante precisión el comportamiento de un NPC: no sólo qué va a hacer, sino también cómo va a hacerlo. O sea, no le dirá: "Cuando el jugador aparezca por esa puerta, atácale sin usar granadas". Probablemente sea algo más como: "Cuando el jugador aparezca por esa puerta, dispara sin moverte durante 10 segundos o hasta que te acierten, y luego cúbrete, mantente dentro y fuera de cobertura hasta llegar al 10% de tu salud, y por fin cargas frontalmente". No hay nada de malo en hacer esta especificación, pero hay que tener en cuenta que es frágil frente a situaciones inesperadas (si no hay cobertura, ¿que hace el NPC? ¿disparar descubierto sin moverse?) y, dado que hay que rehacer la especificación para cada escenario posible, el coste de incorporar nuevas mecánicas es alto para el programador (si de repente queremos añadir que el NPC ruede por el suelo para esquivar, habrá que retocar todos los escenarios). En los desarrollos actuales estamos acostumbrados a estos problemas.

El sistema de planificación automática trata de aliviar la complejidad de organización y selección de comportamientos que se encuentran los NPCs. Especialmente si hablamos de NPCs bastante autónomos, la posibilidad de elaborar sus propios planes permite al NPC incorporar nuevos elementos que se añadan al juego posteriormente con mayor facilidad, a la vez que le proporciona la capacidad de reaccionar mejor ante situaciones inesperadas que si lo hiciera con un comportamiento "enlatado".

Para entender mejor la diferencia de la planificación con el enfoque tradicional, hay que hablar un poquito de la estructura típica de la IA de un juego. La complejidad de los diseños actuales hace que la IA tenga que dividirse jerárquicamente. Se empieza implementando acciones muy básicas, como pueden ser moverse o disparar, que a menudo son idénticas a las que ejecuta el jugador con el controlador. Luego se crea un nivel jerárquico por encima, que contiene un conjunto de comportamientos sencillos que añaden algo de funcionalidad, como la búsqueda de caminos, o el apuntado al disparar. En un siguiente nivel se utilizan estos comportamientos sencillos para montar otros más complejos, que seleccionarán cuáles de estos comportamientos sencillos tienen sentido en cada momento, en función de criterios de alto nivel. Así, podríamos implementar una táctica de combate que hiciera circle-strafe, moviéndonos alrededor del enemigo mientras le intentamos apuntar continuamente. El último nivel será el que elija la táctica idónea, siguiendo las guías que el diseñador haya dado para la personalidad del NPC o para una misión concreta.

Dentro de esta organización, tradicionalmente los programadores implementan tantos comportamientos de alto nivel como los diseñadores van identificando. Para cada comportamiento se hace una implementación distinta, única, típicamente usando técnicas bien conocidas como máquinas de estado o lenguajes de script. En ambos casos el NPC sigue un guión pre-escrito y rígido. Si nuestro NPC tiene la orden de hacer circle-strafe, eso será exactamente lo que hará, tal y como esté programado. La capacidad expresiva y de reacción de los NPCs viene directamente limitada por la capacidad de producción del equipo, tanto en términos de diseñadores identificando situaciones como, especialmente, de programadores implementando comportamientos para gestionarlas.

El sistema de planificación automática pretende cambiar todo esto. Cuando se identifica un nuevo escenario, en lugar de forzar la implementación de un nuevo comportamiento de alto nivel, basta con explicarle al NPC qué es lo que tiene que conseguir en este escenario, cual es su objetivo. El NPC, usando la planificación, "programará" un comportamiento de alto nivel capaz de cumplir ese objetivo sobre la marcha, decidiendo cuáles de los comportamientos de bajo nivel necesita utilizar. Así, en lugar de programar un circle-strafe, le diríamos al NPC que su objetivo es mantener a su enemigo en el punto de mira, mientras evita los ataques de éste (el objetivo para un comportamiento de más alto nivel sería incluso más genérico). Con este objetivo, en una zona abierta quizás el NPC acabe optando por algo similar a un circle-strafe, pero si se encuentra en un área donde se puede hacer uso efectivo de la cobertura, tal vez prefiera esta opción. Con este planteamiento, añadir un nuevo elemento es como darle al NPC una nueva herramienta con la que intentar llegar al objetivo marcado. Lo mismo se aplica si queremos restringirle el uso de un elemento. Además, con un buen planificador, el NPC será capaz de reaccionar ante imprevistos, y construir un nuevo plan que le lleve al objetivo.

Todo esto que parece magia, es en realidad conceptualmente relativamente simple. El truco consiste en etiquetar todos los comportamientos disponibles con sus requisitos y sus efectos. Los requisitos son condiciones que se tienen que cumplir para poder ejecutar el comportamiento con éxito. Si queremos disparar, tenemos que tener un arma cargada equipada, y necesitamos algún enemigo visible. El efecto es el resultado que se espera después de ejecutar el comportamiento. Así, tras disparar el arma es de esperar que el enemigo esté muerto, o tras lanzar el comportamiento de búsqueda de enemigos el resultado será tener un enemigo a la vista. Con esta información adicional, el NPC puede intentar encadenar inteligentemente comportamientos para conseguir el resultado final que el objetivo le indica. Así, si queremos que nuestro NPC intente matar al jugador, primero deberá recoger y equipar un arma, luego buscar al jugador y finalmente dispararle. El trabajo de construir la secuencia de comportamientos es completamente automático (aunque normalmente se puede regular mediante parámetros, que indican las "preferencias" del NPC).

Llegados a este punto quizás os preguntéis porqué no estamos todos usando planificadores automáticos y olvidando el pasado. La primera razón es que todavía es una tecnología relativamente nueva en el marco de videojuegos, así que por un lado hay algunas dudas sobre lo bien que se comportará con problemas suficientemente complejos, no está claro el coste de implementar el motor de planificación, y no todos los programadores están suficientemente formados en su uso. Desde el punto de vista de diseño, comparando directamente un planificador con un sistema tradicional, el planificador exige un mayor esfuerzo de abstracción inicial, ya que hay que dividir los comportamientos de los NPCs en pequeñas acciones que se puedan combinar bien, y especificar cómo se encadenan. Luego, al definir cómo se quiere que se comporte el NPC, en lugar de hacerlo explicándoselo a un programador hay que explicarselo al NPC, hablando su "lenguaje", sobre qué condiciones se tienen que cumplir en el mundo. Es posible además que el diseñador pierda algo de control "fino" sobre cómo se va a comportar el NPC. Los planificadores funcionan mejor cuando se les da autonomía para explorar opciones, y es en estos casos cuando rinden mayores beneficios. Si se quiere un control detallado sobre las acciones del NPC, habrá que implementarlo explícitamente, y no se ganará nada por tener el planificador. El resultado final que el jugador percibirá no tiene porqué ser distinto según el método que se elija. Depende más de hasta dónde llegue la capacidad de producción del equipo que de la tecnología usada.

Al final, la metodología tradicional resulta más eficiente cuando no hay excesiva variedad de acciones. A medida que la cantidad de acciones aumenta, es cuando el planificador sí puede brillar, ya que implementarlo tiene un coste inicial mayor, pues hace falta código extra dedicado a buscar la secuencia correcta de comportamientos sencillos (el motor de planificación), y todos los comportamientos tienen que llevar información adicional. Con el estado actual de los juegos, estamos en el límite del compromiso entre la complejidad del planificador y la del sistema tradicional con la cantidad de combinaciones que encontramos habitualmente. En cualquier caso, es bueno irse preparando, por si acaso.

Mostrar/ocultar resto...

Cómo hacer Grand Theft Auto

En la edición de julio de la Edge apareció un postmortem del primer Grand Theft Auto, desarrollado por DMA Design y publicado en 1997 por BMG Interactive.

El artículo es interesante, pero quizás más interesante, y desde luego más controvertido, es este post (link aquí) que encontró Jare en un blog llamado Lost Garden. El autor describe la razón por la que no existe aún competencia real de juegos como GTA, The Sims y Oblivion, argumentando que la causa es principalmente la dificultad de producir un juego con un diseño emergente tan sofisticado. No estoy seguro de estar de acuerdo 100% con lo que se dice, pero desde luego merece la pena leerlo.

Tema

En la mayoría de las grandes obras de la literatura, si las analizamos cuidadosamente, podemos encontrar uno o más mensajes subyacentes, análisis más o menos encubiertos sobre un aspecto humano de cierta relevancia. En Hamlet se ven las consecuencias de la venganza y la indecisión, en Cuento de Navidad se muestra cómo el egoísmo y la avaricia acaban aislando de la sociedad, Don Quijote nos enseña, satíricamente, la otra cara del héroe clásico, y hace una crítica a la sociedad de la época. Este mensaje suele llamarse tema.

El tema no es una cosa exclusiva de la literatura clásica. El Señor de los Anillos trata sobre las posibles manifestaciones del poder, y el resultado de abusar de él. El Código Da Vinci, independientemente de su trama estilo "caza del tesoro", hace una fuerte crítica a ciertos sectores de la Iglesia católica, a la vez que defiende la importancia histórica de la mujer. Incluso en cómics podemos detectar temas: Spiderman se cuestiona su responsabilidad en la sociedad, en contraste con su bienestar personal, mientras los X-Men luchan a favor de la tolerancia y contra la xenofobia.

Temas hay en mayor o menor medida en todas las historias. El tema ha traspasado la frontera del libro y se encuentra bien asentado en otros medios, como el cine y el teatro. Cuando vamos a ver una película que nos "hace pensar", probablemente sea porque el autor ha planteado un tema interesante, y ha sabido hilvanar una buena historia alrededor. La saga de Star Wars está repleta de temas, como por ejemplo los peligros y consecuencias de caer en tentaciones, y de dejarse llevar por "el lado oscuro".

Pero claro, en este site hablamos de videojuegos. ¿Tiene sentido aplicar un tema a un videojuego? Desde luego que sí. El videojuego es un medio expresivo tremendamente poderoso: no sólo es capaz de contar historias con gran variedad de recursos, sino que permite al jugador interactuar y experimentar en el mundo de juego. Imaginaos explorando las consecuencias de una decisión ética en un entorno controlado como el del videojuego. La mejor forma de aprender algo es haciéndolo, de entender un problema es viendo enfrente tuyo las posibilidades y sus resultados. ¿Habríais hecho lo mismo que Hamlet en su situación? ¿Hubiérais dudado? ¿Cómo os habríais sentido estando a punto de matar al rey?

Sin embargo, y pese a la idoneidad del videojuego como medio transmisor de ideas, la mayoría de los juegos existentes hoy día se pueden clasificar como "puro entretenimiento", o sea, no intentan transmitir apenas nada, sino hacer pasar un rato divertido. Son el equivalente a una película exclusivamente basada en la acción, que no provocará un debate a la salida del cine. Yo no sabría identificar el tema de Doom (o similares) o de los juegos de carreras o deportivos. Incluso juegos que dan más peso a la historia tienen dificultades para expresar ideas y suelen acabar en simples cruzadas heróicas sin ningún tipo de implicación moral. Por suerte, hay algunas notables excepciones. Además de la saga Ultima, que se esfuerza por plantear temas interesantes (las virtudes en Ultima IV, racismo en Ultima VI, o el peligro de las sectas en Ultima VII por poner algunos ejemplos), tenemos recientemente el intrigante ejemplo de Fable. El juego parte de la premisa de que tus acciones, tus elecciones, se reflejan en ti y en el mundo. Luego tiene ciertas dificultades encontrando mecánicas que apoyen el tema, por lo que acaba desarrollándose como un RPG más clásico, orientado a combate, pero aun así mantiene ese aspecto forzando al jugador a tomar decisiones difíciles, tentándole y haciéndole vivir con las consecuencias de sus actos.

Como no se cansan de repetir algunos de los mejores diseñadores y escritores del mundo, al igual que la historia, el tema no es algo que se pueda añadir a un juego a posteriori, como un pequeño adorno para hacerlo más atractivo. El tema es el corazón. Para un autor literario, o un cineasta, el tema es el motor de la obra. Es la razón por la que la obra existe en primer lugar, lo que hace que sea relevante desde un punto de vista artístico. El tema es lo primero que se decide. Luego vendrán la trama y los personajes, que estarán al servicio de la idea, para transmitirla de la mejor manera posible (mediante una historia interesante e inmersiva). En videojuegos, el tema afecta tanto a la construcción de la historia como al diseño de las mecánicas de juego. Cuando estéis buscando un concepto para un nuevo juego, o tratanto de definir el diseño de uno, elegid un tema lo antes posible. Buscad un tema que sea interesante, relevante, algo que os haga sentir pasión, que os haga arder la sangre. No hay nada como la motivación de trabajar en algo que habla de un tema en el que realmente crees, algo que llega hasta lo más profundo del ser. Desde luego, es preferible a clonar el último superventas, sin añadir ninguna esencia que haga del juego una experiencia memorable, que pueda llegar a cambiar la forma de pensar del que lo juegue.

Mostrar/ocultar resto...

Un...¿diseñador de juego?

Hace ya tiempo que hacen falta grandes equipos y gente muy especializada para hacer un videojuego. Sin embargo, aunque todos sabemos perfectamente lo que hace un programador o un texturador, queda menos clara la labor del diseñador de juego. Fijaos que digo diseñador de juego, que no es lo mismo que diseñador de niveles o, un puesto que existe en algunos estudios, diseñador de contenidos.

Asi que, ¿qué es un diseñador de juegos? ¿Es el que...

• ...define el mundo donde se desarrolla el juego, el objetivo del jugador, los conflictos y la motivación de los enemigos?
  
  • No, ese es el escritor
  
  
• ...define el aspecto que va a tener el juego, el estilo de iluminación a utilizar, el tipo de vestimenta que llevan los enemigos?
  
  • No, ese es el artista de concepto
  
  
• ...coordina el trabajo de arte y programación, definiendo los requisitos y haciendo el seguimiento de cuando se van entregando?
  
  • No, ese es el producer
  
  
• ...especifica cómo van a funcionar las herramientas que se usan para producir el juego, incluyendo scriptado, definición de propiedades y estructura de misiones?
  
  • No, ese es el programador de tools
  
  
• ...define como se va a estructurar y configurar el funcionamiento de los enemigos?
  
  • No, ese es el programador de IA
  
  
• ...define las misiones, plantea el espacio donde se van a desarrollar y elabora las situaciones que se pueden producir?
  
  • No, ese es el diseñador de niveles
  
  
• ...escribe el código de script, coloca a los enemigos y configura sus propiedades para implementar las misiones del juego?
  
  • No, ese es el scriptador
  
  
• ...juega con la versión para detectar anomalías, como problemas en el código o en los gráficos?
  
  • No, ese es el tester
  
  
• ...explica qué es lo que el público quiere y los juegos que tienen éxito comercialmente, para incorporar sus elementos?
  
  • No, ese es el analista de marketing
  
  
• ...escribe periódicamente informes de actividad, evaluaciones de progreso, estadísticas de datos definidos y planificaciones?
  
  • No, ese es el burócrata
  
  
• ...organiza documentación, selecciona tipos de letra, formatos, prepara índices y glosarios?
  
  • No, ese es el documentalista
  
  
• ...identifica las piezas que componen la jugabilidad: acciones del jugador (verbos) y elementos interactuables en el juego (nombres), define su funcionamiento e interacciones, y explica por qué son divertidos?
  
  • Si, efectivamente :-)
  
  
• ...juega con la versión o ve a otros jugar para identificar elementos que funcionan y que no, y potenciar los que sí y corregir los que no?
  
  • Si, eso también
  
  

Dicho esto, es perfectamente normal que una persona haga uno o más de estos trabajos, además del de diseño de juego, pero no hay que perder de vista que, mientras lo hace, no está diseñando el juego, propiamente dicho. Además, esta clasificación nos puede ser útil para tratar de identificar mejor los roles que va a desempeñar una persona, y ver si tiene las habilidades necesarias o ayudarle a desarrollarlas.

Lo que sí es cierto es que, en cualquier caso, el diseñador de juego va a tener dependencias con muchos de los roles aqui descritos. El tener conocimientos en esas áreas le será de gran utilidad. Igual de importante será a la inversa, que la persona que desempeñe el rol correspondiente entienda el trabajo del diseñador. Creo que la clave para funcionar bien es que cada uno haga lo que mejor se le da, y la comunicación sea fluida en los puntos donde haya dependencias.

Mostrar/ocultar resto...

Hablemos

En Febrero de 1999, en un artículo para la Game Developer's Magazine, Warren Spector (autor, entre otros, de Deus Ex) se lamentaba de la no existencia de un sistema de conversación con NPCs que funcionara bien.

En el artículo (que podéis leer aqui, en el apartado "Conversation with NPCs") hacía un repaso de cómo se abordaba el problema de la conversación en diferentes juegos:

• Árbol de conversación: el jugador selecciona una opción de una lista, y va de esa manera guiando la conversación y obteniendo respuestas del NPC. Este sistema convierte la interacción en un interrogatorio, donde el objetivo no es establecer un vínculo emocional con el otro personaje, sino resolver un puzzle para avanzar la historia.
  
• Palabras clave: similar en estructura al árbol de conversación, en vez de seleccionar una opción, el jugador escribe una palabra que, si es relevante, provocará una respuesta en el NPC.
  
• No interactiva: la conversación es como una cutscene, el jugador no tiene opción de elegir el contenido. Tiene la ventaja de que puede dar pie a conversaciones emotivas (con buenos actores), pero sufre la libertad del jugador, y típicamente el contenido será esencialmente el mismo si repetimos la conversación.
  
• Lineal con algunas opciones: para hacer menos rígida la conversación no interactiva, se pueden introducir opciones de vez en cuando, que permiten al jugador tomar decisiones. Funciona como un punto medio entre el árbol de conversación y la conversación puramente lineal.
  
• Reacciones: con este sistema, el jugador no elige el texto que dirá su personaje, sino únicamente el tono (enfadado, alegre, grosero, relajado). Puede ayudar a romper un poco la rigidez del árbol de conversación, pero la mecánica es básicamente la misma.

Resulta curioso ver como en System Shock, Spector decidió abolir las conversaciones completamente, haciendo toda la comunicación con el jugador unidireccional: no había personajes vivos, sino únicamente e-mails y grabaciones que avanzaban la historia.

Aún hay algunos sistemas más que Spector no menciona directamente. Recuerdo un juego antiguo, llamado Murder!, donde estabas al cargo de una investigación, y podías interrogar a los personajes componiendo frases para preguntarsles sobre otro personaje, un objeto, su coartada, etc. Seguro que hay muchos más ejemplos.

Me pregunto si las cosas han progresado en estos 7 años (para que os hagais una idea, el año 1999 era la epoca del Quake III y el Starcraft, y la Dreamcast acababa de salir). Y creo que la respuesta es: algo, pero no mucho, y no siempre para bien.

Cuando Spector escribió su artículo, no había salido aún Everquest, lo que, aunque Ultima Online ya estuviera en el mercado, puede explicar porqué no menciona el chat como mecanismo de conversación. Hoy en día, todos los juegos online (especialmente MMOGs) basan su comunicación en chat o, si los participantes se lo pueden permitir, en voz sobre IP. Por desagracia, y exceptuando pequeños experimentos como el uso de la tecnología de reconocimiento de voz (presente en el kit de desarrollo de Xbox) en juegos como Rainbow Six 3, o el (limitado) reconocimiento de texto en Façade, los NPCs siguen siendo incapaces de entender al jugador, bien por voz o por chat. Siete años después de que Warren Spector pidiera que esta tecnología se pudiera aplicar de manera realista, parece que aún nos falta bastante camino por recorrer.

Lo que nos lleva a otras alternativas, y aqui es donde la imagen tiene peor aspecto. Excluyendo juegos que han optado por incluir árboles de conversación (notablemente RPGs de Bioware, como Baldur's Gate, Neverwinter Nights, Jade Empire, y otros como Morrowind y Oblivion), la mayoría han tendido a eliminar completamente la conversación como mecánica o relegarla, si acaso, a cutscenes. Es notable el caso de Valve, que se enorgullece de que Gordon Freeman, protagonista de la saga Half-Life, no habla en ningún momento.

La eliminación de la conversación de la paleta del diseñador supone, en mi opinión, una fuerte limitación en las interacciones que se ofrecen al jugador. Nunca llegaremos a diseñar juegos que sean mucho más que Space Invaders si lo único que el jugador puede hacer es disparar un arma. Como anécdota, recuerdo haber oído a un programador de Halo reflexionar sobre la dificultad de hacer la IA de los aliados del jugador. Había un caso en que, yendo en un vehículo, el aliado tenía que decidir si acompañar al jugador cuando éste se bajaba o no, pues no era obvio si había llegado al destino o sólo quería recoger algo. Pues bien, si el aliado se bajaba, y el jugador le disparaba, el aliado entendía que no era lo que tenía que hacer y volvía a montarse. Halo, pese a ser un juego extraordinario, no permite al jugador comunicarse de otra manera.

¿Cuál es la razón de este aparente abandono de la conversación en los juegos modernos? Se me ocurren varias posibles causas:

• Costes de producción: hoy día los jugadores no quieren leer, quieren oir a los NPCs hablar. El coste de grabar todas las conversaciones (y todas las posibilidades de un sistema de árbol) como hacen Knights of the Old Republic o Jade Empire es muy alto, así que la conversación a veces se limita a lo esencial, o sea, se hace lineal.
  
• Falta de interés del jugador: una parte de la comunidad de jugadores no parecen estar interesados en que les cuenten una historia, solo quieren la jugabilidad en estado puro. Son los que cogen siempre la primera opción de un árbol de conversación sin leerla y los que se saltan las cutscenes. Puede que la aparente prevalencia de este tipo de jugador sea la que aleje a muchos juegos de incluir conversación.
  
• Complejidad: la conversación en un juego es una interacción muy potente, pero también puede llegar a ser compleja. Exige, potencialmente, un mayor grado de atención y paciencia por parte del jugador, que tiene que estar dispuesto a sumergirse en la historia. El miedo a que un jugador se aburra o frustre durante una conversación, y la intención de dar una jugabilidad más "rápida" o "fácil" puede estar detrás de que las conversaciones se hayan simplificado eliminando completamente la interactividad (de modo que el jugador no puede equivocarse).
  
• El fantasma de la aventura: es imposible negarlo, las aventuras gráficas no viven su mejor momento. La mera mención de incluir conversación en un juego recuerda "sospechosamente" los míticos juegos de LucasArts y Sierra, y la connotación hoy día no es positiva.
  
• Seguir el ejemplo: si GTA hubiera tenido un sistema de conversación, estoy seguro de que hoy todos los estudios buscarían la forma de incorporarlo (como ocurre con la jugabilidad emergente). El hecho, sin embargo, es que la mayoría de los juegos de éxito actuales no se apoyan en la conversación, lo que hace que no esté de moda incluirla.
  

En definitiva, resulta irónico que hace diez años existía más variedad y se veían más experimentos para hacer interacciones similares a la conversación que hoy día. Como programador, y visto el relativo poco interés que hay actualmente por resolver el problema, diría que técnicamente no va a llegar una solución en mucho tiempo. Corresponde al diseñador encontrar una alternativa viable.

La tecnología sí puede ayudar, sin embargo. Si hoy día se planteara hacer un motor profesional de reconocimiento de texto para una aventura conversacional (ahora llamadas ficción interactiva), sería sin duda órdenes de magnitud más potente que los que existían en la época (y sobreviven hoy). Aun sin ser capaz de entender todas y cada una de las frases que se le pudieran ocurrir al jugador, minimizaría enormemente el problema de "no entiendo lo que dices" y buscar la palabra exacta. La tecnología, y sobre todo la potencia de los ordenadores, ha avanzado lo suficiente como para permitir, al menos, esto.

Mostrar/ocultar resto...

Diseño de juego y de niveles, ¿juntos?

Recientemente me ha llamado la atención en varios juegos la intima relación que proponen entre diseño de juego y diseño de niveles, hasta el punto de tener mecánicas que sólo se encuentran en unas pocas ocasiones. Hablo por ejemplo del God of War, Fahrenheit, Half-Life 2... En todos ellos se pone un énfasis especial en ofrecer la mayor variedad posible en la jugabilidad, con retos de diferente naturaleza que no se repiten. Además, da la sensación de que las mecánicas y el nivel donde se utilizan van íntimamente ligados: Kratos se encuentra un laberinto de vigas sobre las que usa la mecánica de hacer equilibrios.

Obviamente, todos los juegos aspiran a tener variedad, y a sacar el máximo de sus mecánicas de diseño. Sin embargo, es típico plantear una serie de elementos de diseño a priori, y luego construir niveles donde aplicarlos. Los juegos de coches, FPS, RTS...la mayoría siguen esta premisa. Podemos analizar el Project Gotham Racing, el F.E.A.R. o el Warcraft III independientemente del nivel, puesto que la jugabilidad es siempre más o menos la misma. También los juegos que están basados en diseño emergente o mundos abiertos tienden a empezar por definir los elementos del juego y luego construir niveles o misiones. Es el caso de GTA, Oblivion, etc.

Supongo que debido principalmente a limitaciones técnicas y de producción, los juegos que hermanan diseño de juego y de niveles tienden a ser bastante lineales. No se pueden permitir el lujo de hacer contenido que el jugador no vaya a ver, ya que casi todo el contenido es único y resulta costoso de producir. No estoy seguro de qué prefieren los jugadores típicamente: una experiencia más lineal pero muy variada y rica, o una más libre, basada en un conjunto de elementos establecidos previamente, y donde se juega con las interacciones entre ellos. Parece que hay juegos que tienen éxito en ambas categorías.

A la hora de plantear un juego de este estilo, me vienen varias cosas a la cabeza. Primero, hay que establecer una relación muy estrecha entre diseñadores de juego y de niveles, quizás hasta el punto de no hacer distinción. En God of War tenían 4 diseñadores de niveles y 3 diseñadores de combate, pero ningún diseñador "de juego" (y sospecho que David Jaffe hacía un poco de uber-diseñador, diseñando el alto nivel de todo). El combate es la parte más trasladable y constante de God of War, así que creo que tiene sentido tratarla por separado, pero no me cuesta imaginar a los diseñadores de niveles introduciendo mecánicas nuevas.

La segunda consideración es que la forma de trabajar día a día cambia. Típicamente el número de mecánicas distintas en el juego será grande, y los diseñadores necesitarán experimentar mucho con ellas para hacer que mecánica y nivel encajen bien. Esto es como cambiar el diseño del juego con la misma facilidad con que los motores y herramientas de hoy permiten cambiar un nivel. Para programadores esta es la peor de las situaciones, ya que el programador prefiere una lista de requisitos inicial, pequeña y coherente. Cambios drasticos en el diseño y máxima variedad son enemigos de un código sencillo y elegante. Por otra parte, recuerdo a los programadores de Jak & Daxter mencionar que un aspecto muy importante para ellos es la capacidad de programar muchos comportamientos y escenarios únicos, usando un lenguaje de script especial (GOAL), lo que les distingue de la competencia.

En definitiva, un modelo de estructurar la jugabilidad opuesto a la moda del mundo libre y emergente, que creo seguirá vivo y triunfando aún durante largo tiempo.

Mostrar/ocultar resto...

Organiza tus ideas

Como dice el lema de nuestro querido site "Ideas are easy, the writing is the hard part". Y es que los videojuegos son quizás el ámbito creativo donde hay más elementos con dependencias internas a tener en cuenta.

Desde las propias reglas de una mecánica de juego, a las distintas features de un concepto, pasando por la ramificación del argumento, el diseñador debe tener en su mente una imagen clara de como se relaciona cada elemento con el resto, y sobretodo, qué implicaciones pueden tener las decisiones que se toman cuando se define o modifica alguno de estos elementos, casi nunca aislables del resto.

Para facilitar este proceso de organización y visualización de este tipo de información, os recomiendo Mindjet Manager.

Este software permite la cómoda creación de diagramas de flujo en los que ir relacionando los elementos que tiene nuestra mecánica/juego/argumento. Además, también podremos utilizarlo para organizar nuestras tareas (asignándoles duración, notas e iconos informativos), exportar nuestra organización como página web o adjuntar cualquier tipo de archivo a cada uno de los elementos de nuestro mapa (el programa está completamente integrado con Microsoft Windows).

Mejor pasaros por el "quick tour" del website (clicad aquí para acceder directamente) y me contáis que os parece ;)