Crawford contra el mundo

Os recomiendo que leáis (si no lo habéis hecho aún) la entrevista a Crawford realizada en Junio en Gamasutra con el exagerado título Video Games are Dead. Su punto de vista es alarmante, pesimista, pero en su frase de despedida, referida a su proyecto vital (storytronics), demuestra la certera mirada que de él esperábamos:

this is pioneering work and to learn it you have to unlearn a great deal of what you already know and start over, you have to re-learn from a completely new angle

La contrapartida no podía ser mejor: en Question of the Week Responses: Is Crawford Right?, entendidos en la materia dan respuesta, si son capaces, al pesimismo del reputado autor de "The Art of Computer Game Design".

Fahrenheit

Con motivo de la aparición del post-mortem del Fahrenheit (también llamado Indigo Prophecy, 85% en GameRankings.com), me he animado a retomarlo, ya que creo que es un juego cuando menos atípico, si no innovador.

Lo primero que llama la atención es lo bien narrada y atmosférica que es la historia. Se nota en el post-mortem y en el juego que han cuidado de manera exquisita todos los detalles: brillante caracterización de los personajes (con rostros memorables y estilo propio), uso de motion capture para conseguir una gran variedad y realismo de las animaciones, excelente actuación en las voces, filtros de post-proceso para lograr una imagen muy cinematográfica, pantalla partida como en la serie 24 para aumentar la tensión, etc, etc. Me resulta imposible no compararlo con otro juego muy conocido, The Longest Journey que, aunque también trataba de desarrollar una historia inmersiva e interesante, fallaba estrepitosamente en la producción, quedando reducido muchas veces a personajes inmóviles, hablando con un diálogo que dejaba bastante que desear y se hacía eterno (el juego tiene muchas otras virtudes).

En el post-mortem David Cage explica algunas de las técnicas que usó para conseguir la potencia dramática que Fahrenheit tiene. Llama la atención en particular la manera de construir personajes, partiendo de un arquetipo sobradamente conocido (plano) y, más adelante, añadiéndole elementos para hacerlo más único y redondo. Dadas las limitaciones actuales del videojuego para expresar personalidades complejas, me parece un enfoque muy razonable e interesante.

Un aspecto muy importante, que el juego explora, es la interacción entre historia y juego. No creo que consiga resolverlo en absoluto, por desgracia, ya que, la estructura de la trama es única (salvo algunos elementos del final que funcionan como un libro de "Elige tu propia aventura"). Lo más interesante es la ilusión de interactividad que provoca en el jugador al permitirle jugar las escenas variando pequeños detalles que, sin embargo, no afectan a la trama principal.

La experiencia de juego es atípica para una aventura: en muchas ocasiones consiste en apretar botones adecuadamente (como en un juego de baile), y no hacerlo supone la muerte, como pulsar la tecla equivocada en Dragon's Lair. Quizás lo más destacable es el intento de potenciar la inmersión tratando de hacer sentir al jugador lo mismo que el personaje. Hablo de cosas como un interfaz que simule las acciones que el personaje lleva a cabo (estilo el mando de la Wii, pero mucho más primitivo), o agobiar al jugador cuando el personaje está en un momento estresante. Yo creo que funciona moderadamente bien y fortalece la relación del jugador con el juego.

Yo me he sentido algo incómodo con el interfaz. Controlar al personaje a veces resulta complicado dentro del baile de cámaras, y los movimientos, aunque muy realistas, no responden todo lo bien que sería deseable. Además, la acción contextual se ejecuta con el stick derecho, pero hay que hacer una acción "similar" a la que el personaje va a hacer, y no siempre resulta obvio (p.ej. para abrir una puerta, coger algo, etc).

El juego ha sido muy criticado por algunas secuencias de acción, y creo que con razón. Resulta frustrante repetir una y otra vez una sucesión de secuencias en las que tienes que acertar a mover los sticks acorde a lo que el juego pide y pulsar los gatillos alternadamente a toda velocidad. Es más difícil de lo que debería, y resulta repetitivo y aburrido al cabo de un rato.

En definitiva, los chicos de Quantic Dream han hecho un excelente trabajo, aunque desde el punto de vista de diseño creo que hay cosas que pulir y perfeccionar. Si no lo habeis visto ya, no os perdais el video que presentaron en el E3 (Heavy Rain), con su nueva tecnología. Absolutamente impresionante. En atmosfera y caracterización, creo que no les gana ni Square Enix.

Mostrar/ocultar resto...

Como ser mejor diseñador

Jare me ha mandado este link sobre 40 formas de ser mejor diseñador de juegos (en ingles), en el blog de Raph Koster.

Es una lista interesante, que incluye aspectos como abstracción, playtesting, reuniones, documentos de diseño y robar (buenas) ideas, entre otros.

Storytronics

Como ahora sale hasta en la sopa, le di un nuevo repaso a la tecnología de Interactive Storytelling del siempre pintoresco Chris Crawford, llamada Storytronics.

Es dificil hacer un juicio del resultado que se puede obtener, ya que hay muchos detalles que no están explorados lo suficiente en el sitio web, y además depende muchísimo de la capacidad del storybuilder (constructor de historias). Desde el punto de vista de usabilidad, parecen haber puesto mucho enfasis en hacerlo accesible a gente no técnica. Veremos que tal resulta. Lo primero es describir un poco la tecnología, pero empezando por explicar lo que Crawford entiende por Interactive Storytelling.

Lo importante en una historia interactiva para Crawford, no son los gráficos o la presentación, ni construir una simulación realista y coherente de la realidad. En Storytronics, los escenarios son simples fotografías, los personajes se mueven instantáneamente de un escenario a otro, y están representados únicamente por una cara que indica emociones. La parte interesante está en interactuar con los personajes, que son autónomos y reaccionan tanto a lo que el jugador hace, como a lo que hacen otros personajes. El trabajo del storybuilder consiste en construir la madeja de posibles interacciones que pueden ocurrir en el mundo (no los llaman juegos sino storyworlds) asegurando la coherencia y el interés dramático.

El corazón del sistema es lo que llaman Verbos. Cada verbo representa una acción que cualquier personaje puede decidir ejecutar. El storybuilder tiene que definir uno a uno todos los verbos que pueden suceder en el storyworld, especificando:

• Los personajes que se ven afectados por la acción. Es lo que llaman Roles. Por ejemplo, si un personaje le da un puñetazo a otro, típicamente habrá dos roles, el que sacude y el que recibe, aunque puede haber más si es necesario, como la novia del que recibe (caso de tenerla) o un policía que observa lo sucedido.
  
• El efecto que produce la acción. Depende, lógicamente del rol. Viene definido en términos físicos y emocionales. Puede producir un cambio de escenario o el cambio en un atributo (un personaje está muerto tras recibir la acción matar), o un cambio en el modelo emocional de cualquiera de los participantes. Así, el que recibe el puñetazo pensará que el que se lo dio no es una buena persona.
  
• Los posibles verbos a los que los participantes podrán optar tras la acción. Es aquí donde se hila la trama, donde se monta una red de verbos que define las posibles situaciones que se pueden producir. Típicamente los personajes tendrán varias opciones para elegir tras cada verbo, y lo harán en función de su personalidad y estado emocional.
  

Para llevar a cabo la edición de estos verbos Storytronics propone un sistema de script editado visualmente. Decidir si un personaje tiene que adoptar un rol en una acción, actualizar el mundo o las emociones de los personajes, y evaluar las opciones disponibles, todo se define mediante scripts. El lenguaje es funcional: se edita anidando llamadas a funciones que retornan un valor sin modificar nada internamente (sin efectos laterales). Por ejemplo, podríamos especificar que un personaje puede adoptar un rol si "es un hombre y la acción fue ejecutada sobre el". En la imagen se puede ver el aspecto que tendría el script.

Los mecanismos de decisión se basan en un sencillo sistema de pesos (también llamado de puntuación). Mediante unas simples fórmulas matemáticas se evalúan unos números para cada una de las opciones disponibles, y luego se elige el número mayor. En mi opinión, la edición de estas fórmulas mediante el lenguaje de script funcional es algo engorroso: una sencilla fórmula puede tener un aspecto muy complejo. Las matemáticas también se usan para actualizar los valores del modelo de emociones de los personajes, tras un verbo.

El modelo emocional está explicado muy por encima en los tutoriales, así que haré una descripción un tanto superficial. Todos los personajes, salvo el jugador, tienen características de personalidad (traits) que usan para decidir qué opción elegir tras la ejecución de un verbo. Hay tres "dimensiones" en el modelo: las características que uno tiene, las que uno cree que otro tiene, y las que uno cree que otro piensa que un tercero tiene. Fijaos en la complejidad de relaciones y malentendidos que se pueden conseguir con este modelo, junto con el sistema de "cotilleo" (los personajes se cuentan unos a otros lo que han ido viendo en la historia, o lo que les han contado). La lista actual de rasgos es la siguiente:

• Honestidad
  
• Bondad
  
• Autoridad
  
• Inteligencia
  
• Atractivo
  

Esta es la lista inicial, que parece puede ser ampliada si el storyworld lo requiere. Además de estos rasgos de personalidad, también hay características físicas, que llaman atributos: Fuerza, Altura, Agilidad, Salud, Riqueza, Edad, Energía, Sensualidad, etc. Tanto los valores de personalidad como físicos vienen definidos por un número entre -1.0 y 1.0.

Un aspecto interesante del sistema es que, para comunicarse, tanto el jugador como los demás personajes usan un lenguaje inventado llamado Deikto. Es una especie de subconjunto del inglés, representado gráficamente mediante palabras conectadas, generado proceduralmente a partir de los verbos disponibles en la historia. El uso del mismo lenguaje (aunque sea sencillo) por parte del jugador puede ayudar mucho a acostumbrarse rápidamente y quedar inmerso en la historia. Además, sirve para limitar lo que el jugador puede hacer o decir en cada momento, manteniéndole dentro de los límites del storyworld (con lenguaje natural sería más difícil forzar esta limitación). De momento no he podido encontrar mucha más información acerca de Deikto, así que habrá que esperar para emitir un juicio final.

El último elemento que queda por mencionar son los props, objetos que se pueden usar o requerir para ejecutar un verbo. Al igual que los personajes, cuentan con una serie de atributos que ayudan a definir mejor su efectividad u otras posibles consecuencias.

Como punto de vista personal, diría que el sistema funciona aparentemente como una máquina de estados extendida (o una red de petri), que los personajes comparten. El jugador y cada personaje parten de un estado y se van moviendo por la red provocando que los otros personajes también lo hagan. Los estados son los verbos, y es necesario definir las consecuencias de alcanzar dicho estado y las posibles transiciones (ojo, tanto para el sujeto, que ejecuta la acción, como para otros personajes implicados). La red de estados, que típicamente deberá ser jerárquica para mantener un nivel de complejidad accesible, es la columna vertebral de la historia. Es algo más potente que el clásico libro de "Elige tu propia aventura" porque todos los personajes pueden utilizar la red, no sólo el jugador (y además el ordenador es capaz de procesar redes más grandes con facilidad).
El principal inconveniente del sistema es que, inevitablemente, todo el trabajo de definición de todos los posibles acontecimientos del storyworld recae sobre el storybuilder, y su única herramienta es un sencillo lenguaje de script. Para cada acontecimiento hay que definir, a mano, todas las posibles acciones que pueden ir a continuación, y priorizarlas. En una historia moderadamente compleja hablamos de cientos o miles de verbos. Además, aunque viniendo de un programador esto no sorprenderá a nadie, yo preferiría ampliamente un editor de texto, con más potencia y flexibilidad, que el limitado y "supuestamente sencillo" editor actual. Prefiero escribir "0.5+Autoridad(Actor)/2" que una larga lista de operaciones anidadas.

Al final, la tecnología demostrará su utilidad o falta de ella una vez empecemos a ver ejemplos concretos de su uso. De acuerdo con los planes del equipo de Crawford, esto empezará a suceder a finales de este año o principios del que viene. Espero con ansia.

Mostrar/ocultar resto...

Historia de tres estudios...

Este es un pequeño ejercicio que hice para tratar de aclarar las diferencias entre los diferentes enfoques durante pre-producción. La definición de pre-producción es sólo una guía: es el periodo en el que se van definiendo los detalles del diseño y se preparan los sistemas necesarios para empezar a hacer niveles del juego "como churros". Si no teneis un proceso de pre-producción como tal, sentíos libres de adaptar las situaciones aqui descritas a vuestra forma de trabajar.

Estos son algunos posibles enfoques de diferentes estudios para desarrollar un juego nuevo, innovador, durante pre-producción.

El Estudio A decidió que lo mejor era coger el toro por los cuernos, y empezó con un equipo mediano (4 diseñadores, 9 programadores y 17 grafistas, incluyendo modeladores, texturadores y animadores) ya desde el principio. No había problema, ya que cada equipo trabajaba en paralelo y no había muchas dependencias.
Los diseñadores se pasaban el día reunidos definiendo la jugabilidad, el interfaz, algunos niveles de prueba, etc. Todo quedaba reflejado en el documento de diseño.
A partir del concepto inicial, programación trabajaba tanto en preparar las herramientas lo antes posible, como en desarrollar la tecnología necesaria para el juego.
Los grafistas por su parte, desarrollaban conceptos y definían la dirección de arte, mientras empezaban a construir algunos modelos de personajes y entornos que serían usados en los primeros niveles.
Tras unos meses, en los que el equipo creció algo más, programación había empezado a implementar algunos de los elementos que los diseñadores habían incorporado, mientras los grafistas intentaban integrar los modelos en el nuevo motor. Una vez todo estuviera integrado, la jugabilidad se podría ver en la primera versión del juego que incorporaría todos los elementos básicos.
Con esta versión esperaban poder pasar a producción, una vez probado que el diseño funcionaba y era posible implementarlo.

El Estudio B tenía dudas sobre la idea inicial, así que arrancó el proyecto con un equipo muy pequeño: 2 diseñadores, 4 programadores y 3 grafistas. Eso sí, decidieron poner ahí a su mejor gente, a pesar del riesgo de que el proyecto fuera cancelado.
Para definir mejor el juego, el equipo empezó a trabajar en formas de prototipar los elementos menos claros o más arriesgados, individualmente.
Así, un grafista trabajó en varios conceptos mientras otro colaboraba con uno de los programadores para tratar de averiguar, mediante render, el aspecto visual que la tecnología podría permitir.
El tercer grafista daba soporte a los dos diseñadores que, trabajando con los programadores, construían pequeños prototipos (de usar y tirar) donde respondían a sencillas preguntas de diseño: ¿funciona la ilusión de libertad? ¿es el interfaz intuitivo? ¿es una cierta mecánica divertida?
A la par, uno de los programadores trabajaba en resolver las dudas más complicadas sobre los límites de la tecnología, también con pequeños prototipos: ¿qué limitaciones nos impone el streaming? ¿funcionará bien el sistema de script que hemos diseñado?
Después de un tiempo trabajando en responder estas preguntas, el equipo tenía confianza en que el juego era sólido y sería divertido y rentable. Con una idea clara (basada en los prototipos) y sin dudas, empezaron a crecer para desarrollar el código y los gráficos finales (el código y arte de los prototipos se tiraría a la basura).
El desarrollo iba rápido porque sabían exactamente lo que tenían que hacer, y las principales dudas tecnológicas habían sido resueltas. En poco tiempo esperaban terminar el primer nivel y poder pasar a producción.

El Estudio C creía que lo mejor era desarrollar el juego incrementalmente, poquito a poco. Así, empezó también con un equipo pequeño: 3 diseñadores, 5 programadores y 5 grafistas.
En un par de meses los programadores montaron la primera versión ejecutable. Era apenas jugable, pues sólo incorporaba la funcionalidad más básica, tenía gráficos que obviamente no eran definitivos y las herramientas eran difíciles de usar.
Sin embargo, los diseñadores jugaban con esa versión periódicamente, y la usaban para descubrir problemas que había en el diseño, cosas que no eran divertidas, o anti-intuitivas. Cada semana identificaban estas carencias y proponían cambios, que los programadores incorporaban en el juego.
Los grafistas también, por su parte, utilizaban la versión para detectar puntos mejorables y experimentar con valores como número de polígonos, tamaño de textura, materiales, etc.
Los programadores, obviamente, trataban de mantener una base de código muy ágil y modular, y estaban al servicio de diseño y gráficos, no implementando nada que no fuera específicamente solicitado. Era un requisito indispensable que la versión siempre estuviera estable y jugable.
Durante varios meses se fueron incorporando elementos y eliminando otros (que se demostró que no funcionaban). El equipo fue creciendo poquito a poco. Tanto el juego como las herramientas habían ido evolucionando, y habían progresado hasta un punto de usabilidad razonable.
En poco tiempo esperaban llegar a un punto de evolución en que el diseño de la jugabilidad ya se hubiera estabilizado, tener un nivel de prueba, y entrar en producción y preparar el resto de niveles para el juego.

¿Qué opináis? ¿Quién miente? ¿Donde os gustaría trabajar?

Mostrar/ocultar resto...

Sobre prototipos

En la GDC de este año, quizás lo más interesante era escuchar post-mortems de cómo se había abordado el desarrollo de algunos de los juegos de más éxito (en un próximo post polemizaré un poco al respecto ;-)

Un detalle sin embargo llamaba especialmente la atención: el énfasis en el uso de prototipos durante la fase de pre-producción. Lo mencionaron para el Civilization IV y, especialmente, para el Spore aqui y aqui (no olvideis leer las anotaciones si mirais las presentaciones).

Existen varios tipos de prototipos: de jugabilidad, tecnológicos (para ver la viabilidad de implementar un requisito), visuales, etc. Centrándonos en los de jugabilidad, su principal objetivo es "demostrar" que un elemento del juego funciona bien y es divertido, sin tener que esperar a tener el juego medio terminado. Durante la fase de pre-producción, mientras se refina el diseño, la jugabilidad se va evaluando mediante prototipos, descartando con un coste pequeño (el coste de implementar el prototipo) aquellas ideas que no encajan. Muchas veces prototipamos elementos de nuestro juego casi sin darnos cuenta. Si estamos haciendo un juego RTS, nos fijamos por ejemplo en cómo funcionan las formaciones en otros juegos hasta que encontramos uno que nos gusta (y ese juego es nuestro prototipo!).
En el peor de los casos, si durante la pre-producción el concepto del juego no se consigue concretar de ninguna manera, cancelar el juego tendrá también un coste bastante asequible. Ni que decir tiene que, cuanto más arriesgado o innovador es el diseño, mayor es la probabilidad de que haya que tirar muchas de las ideas durante la experimentación, y usar prototipos es la manera ideal de distinguir las buenas de las malas.

Yo he tenido la ocasion de ver y participar en varios prototipos y, a pesar de que el concepto suena muy bien, en la práctica es más difícil de sacar adelante con éxito de lo que puede parecer. El camino está plagado de trampas, que hay que conocer para poder evitar.

La idea del prototipo resulta anti-intuitiva para muchos programadores. Acostumbrados a estrictas (y necesarias) prácticas de ingeniería del software, a escribir código robusto, flexible, óptimo, fácil de mantener y bien documentado, muchos programadores se sienten incómodos escribiendo un prototipo cuyo principal requisito es minimizar el coste (en tiempo y recursos) de implementar cierta funcionalidad. Olvidados quedan criterios de eficiencia, mantenibilidad e incluso (gasp!) limpieza y elegancia. Otro pequeño obstáculo es que frecuentemente resulta más eficiente prototipar en lenguajes de alto nivel, como Python o C#, pero la mayoría de programadores se sienten más cómodos programando en C++ que, aunque genera programas más eficientes, requiere más tiempo para hacerlo.
El mejor perfil de programador para prototipar es el en ocasiones llamado "enreda". Es un programador que va directo al objetivo, y combina elementos y usa todos los trucos para llegar lo más rápido posible. Su trabajo se ve muy facilitado si cuenta con una base de código compuesta de elementos modulares, bien encapsulados, y que se pueden combinar fácilmente. No ayuda si para pintar un gráfico en pantalla es necesario, por ejemplo, inicializar el sistema de red, debido a dependencias que pueden tener sentido en el juego final, pero que suponen una carga innecesaria para el prototipo. Muchos motores pecan de demasiada rigidez en su estructura, dificultando su uso para pequeños programas de variada naturaleza y desarrollo corto, como son los prototipos.

Desde el punto de vista de filosofía, o visión, es imprescindible que el equipo crea en el sistema de prototipos para que éste tenga éxito. No es infrecuente pecar de exceso de confianza en que el diseño que se ha planteado en papel va a funcionar, aun cuando no hay ninguna prueba objetiva de que sea así. Otra posibilidad es la incredulidad en que se pueda probar que el juego es divertido hasta que está prácticamente hecho, y la mayoría de los elementos están integrados. En el mejor de los casos, eso lleva a prototipos muy grandes, llamados "vertical slice", que simulan una pequeña porción de juego, pero lo hacen con calidad casi final. El inconveniente es que el coste de implementarlos es mayor que el de pequeños prototipos individuales, y puede no resultar obvio, si el vertical slice no funciona bien, qué elementos son los responsables. El vertical slice es una buena idea, pero debe ir prececido de pequeños prototipos para aclarar dudas en elementos conflictivos. En cualquier caso, el error que nunca se debe cometer es decir "bueno, no es divertido aún, pero en cuanto incorporemos la característica X lo será". Si el juego o alguno de sus elementos no funcionan, hay que corregirlo en el momento, o correr el riesgo de pagar un precio mucho mayor más adelante.

Incluso si el equipo tiene fe en prototipar, a veces no resulta evidente cómo dividir el diseño del juego en pequeños elementos que se puedan prototipar independientemente. Esto típicamente conduce a que se trata de hacer el prototipo equivocado, y luego o bien resulta complicado de implementar, o es difícil extraer conclusiones relevantes. No se debe caer en la trampa de intentar prototipar demasiados elementos a la vez, ya que la complejidad aumenta exponencialmente. Idealmente, hay que diseñar un prototipo que busca responder, con un simple sí o no, a la pregunta de si un elemento del juego funciona. Por ejemplo, ¿es divertido/fácil usar gestos con el ratón para controlar el juego? ¿qué tal se apunta en un FPS con un pad de consola? ¿es divertido mover una pelota a la que se pegan objetos? ¿funciona conducir y disparar a la vez? Otros elementos, más abstractos, son más dificiles de aislar: ¿cómo prototipamos la sensación de libertad en GTA? Concretendolo más, podríamos prototipar si es divertido hacer de taxista, saltar en las rampas, buscar los paquetes ocultos, etc. Al final, las interacciones existentes en GTA son finitas. Separándolas y analizándolas una a una quizá no tengamos la absoluta certeza de que vayan a funcionar bien juntas, pero la probabilidad de que así sea será mayor. Además, la necesidad de concretar los elementos nos sacará del bloqueo de no saber elaborar en que consiste la "sensación de libertad". Otra ventaja de hacer la pregunta correcta al diseñar un prototipo es que las conclusiones que se extraigan serán mucho más claras y evidentes.

Los prototipos pueden tener un efecto positivo sobre la moral. En efecto, en muy poco tiempo estamos viendo elementos del juego en accion. Hay que ser precavidos, sin embargo. No es bueno crear una falsa sensación de progreso. Aunque el prototipo funcione, no tiene calidad final, y es posible que el trabajo necesario para producirlo sea grande (en términos de código, robustez, gráficos, testeo, etc).

Un aspecto importante de los prototipos es que funcionan mejor cuando se realizan como resultado de trabajo en equipo, conjunto y casi me atrevería a decir informal. Si intentamos imponer una disciplina al prototipo, dividiendo las responsabilidades, estableciendo requisitos claros, usando procedimientos de planificación y seguimiento, etc, sólo lo estaremos cargando con una burocracia innecesaria. Podemos fácilmente llegar al absurdo de que la documentación necesaria para construir el prototipo cuesta más que el prototipo mismo. Es mejor formar un mini-equipo, un programador y un diseñador, con un grafista si hace falta, y darles un tiempo (lo más reducido posible, probablemente días o pocas semanas) para elaborarlo. Durante ese tiempo, trabajan juntos, haciendo rápidas iteraciones hasta que o se obtiene el resultado esperado, o se ve que el camino no es el correcto. Lógicamente esto funciona mejor cuando tenemos gente senior en estos roles, pero es lo deseable en cualquier caso: queremos los mejores diseñadores y programadores durante la fase inicial de un proyecto, dado que tendremos mayores posibilidades de que tengan éxito.

Estos son sólo algunos apuntes sobre situaciones que pueden surgir durante la fase de prototipado. En las presentaciones del Spore se entra en detalle algo más técnico en algunos de estos aspectos, como la división que hacen del diseño en varios ejes que luego tratan independientemente. Muy recomendable.

Mostrar/ocultar resto...

El videojuego como auténtico generador de historias

En un reciente artículo se habló de la división entre Interactividad e Historia. Creo que esta separación es un gran punto de partida para un gran 'topic', aunque podemos llevarlo un poco más allá, hacia la frontera donde el videojuego se separa del cine.

Lo interesante de esa división es que, como apuntaba Saül, es una división artificial o, mejor dicho, perjudicial para los videojuegos narrativos (aquellos que pretenden contar algo). Al intentar separar el hecho del 'juego' del hecho de la 'historia' (como el 90% de juegos narrativos han hecho hasta el momento) estamos asumiendo que la forma de explicar historias del videojuego es similar a la del cine (una historia lineal y pre-establecida), cuando creo que la verdadera riqueza de este nuevo arte es la posibilidad de separarse de otras artes a través de su principal virtud (la interactividad).

Y es en la generación de historias a través de la intervención del jugador-protagonista que esto se hace más evidente y donde se abren múltiples caminos hacia la (todo hay que decirlo) complejísima narrativa configurativa, aquella que permite la creación de narrativa en tiempo real, no lineal, no pre-establecida. Por lo tanto, lo que en una película no es posible (la intervención del espectador), se convierte en los videojuegos en una circunstancia de incalculable valor, no sólo para el hecho de la 'diversión', sino tambien a la hora de contar historias. Se trata, pues, de analizar a qué cotas podemos llegar y a qué precio es esto posible.

La principal ventaja de esta nueva narrativa es, como antes he mencionado, la posibilidad de erigir al videojuego como arte narrativo independiente de otras formas lineales como la literatura o el cine. Y esto tiene un valor tan enorme que vale la pena intentarlo. Y más allá de algo tan académico, está la sensación del jugador de estar viviendo siempre una historia diferente, creada (esta vez sí) por él mismo.

Los inconvenientes son, por desgracia, también enormes:
- las horas de diseño/programación/arte irremediablemente(?) aumentan en gran medida,
- y lo que es más peliagudo: la satisfacción que pueda producir una historia así generada (cada vez distinta, siempre en tiempo real, sin montaje?) es dudosa: ¿cómo, por ejemplo, esperar que de las acciones de un jugador 'emanen' por sí solas historias/eventos tan apasionantes como los que podemos experimentar en Half-Life o Halo (que ahí estan pre-generados, por mucho que el usuario los pueda ver en tiempo real)? ¿Cómo esperar que de los violentos actos de un experimentado jugador de GTA3 Capítulo X, pueda surgir una pieza narrativa como la que podemos degustar en 'Goodfellas', de Scorsese?

Hoy en día, en esa 'pieza' generada por el jugador faltaría de todo: intensidad, giros de guión, riqueza de personajes, profundidad... ¿Es simplemente una cuestión de IA? Tal vez. Pero antes deberemos comenzar a pensar las historias que queremos ver en los videojuegos de forma muy distinta a como se viene haciendo hasta ahora, que era imitando al cine. Deberemos sobreestimar las posibilidades narrativas del videojuego, y con ello ganará el videojuego como arte...

Con esto tenemos para años de disputas...

Mostrar/ocultar resto...

Quizás la mayor base de datos de videojuegos del mundo

Los que conozcáis IMDB sabréis de la utilidad de esta enorme base de datos sobre el mundo del cine. En ella podéis encontrar cómodamente toda la información de cualquier película o personaje de la industria.

Además de imágenes, valoraciones de usuarios, y todo lo que normalmente esparíamos encontrar, en muchas ocasiones podremos acceder a ver el trailer de la película consultada e incluso leer las frases de diálogo más celebres.

Ese es el hueco que empieza a rellenar MobyGames para nuestra industria. La base de datos de MobyGames nos permitirá buscar por año, plataforma, género y compañia los miles de título que están recogidos en su base de datos.

Una de las opciones más interesante que nos permite consultar la base de datos es la "juegografía" de algunas de las estrellas de la industria del videojuego y examinar la carrera de cada uno de ellos.

Como simple ejemplo, podemos ver como Will Wright trabajó en 14 juegos que incluyen el vocablo "Sim" en su título antes de trinfar diseñando uno de los videojuegos más vendidos de la historia: "The Sims". A día de hoy, el total de juegos Sim asciende a 27 (pinchad aquí para ver todos los títulos en los que ha trabajado Will).

Ahora entendemos la cara que se le ha quedado al hombre :)

De Juegos e Historias

Hoy he vuelto a leer un artículo acerca de “juego e historia” (games vs storytelling).

Para los que os pille de nuevas, es un tema de discusión clásico en este mundillo, que trata de determinar si es o no posible contar una buena historia a través de un juego; es decir, de usar el juego como una herramienta narrativa, igual que hace el cine o la novela. Lo verdaderamente importante de esta pregunta es que hay muchos que piensan que es un paso esencial para lograr hacer de este medio de expresión un arte.

El artículo en cuestión (que ya tiene unos añitos) lo podéis encontrar aquí y, la verdad, aunque hay una serie de cosas con las que discrepo cuando lo leo, me gusta porque va haciendo una breve revisión de un buen número de géneros que parecen ir evolucionando de modo continuo desde “historia” hasta lo que llamamos “videojuego”. Al fin, sin embargo, propone una solución al problema con la que estoy sumamente de acuerdo.

Yo pienso que sí es posible contar una buena historia (en el sentido clásico; algo más o menos lineal) a través de un juego, y podría poner algún ejemplo. Pero no que ésta sea imprescindible para crear una obra de arte (aquí, mientras alguien demuestre lo contrario, entra ya la definición de arte que cada uno tiene).

Lo que hace divertido un juego es su interactividad, lo que lo hace interesante es su historia. Y son dos cosas diferentes. Hay juegos muy divertidos con una historia bastante floja, y juegos no tan divertidos con una historia atractiva. Son juegos para momentos diferentes y estados de ánimo diferentes, y no son unos peores que otros. Ni siquiera son unos más artísticos que otros.

Así que, ¿por qué dedicamos nuestros esfuerzos a crear videojuegos y no a discutir si la historia hace falta o no?Dejemos estas cuestiones en manos de los teóricos.

Hacer un videojuego en 7 días.

Quizás alguno de vosotros haya oído hablar de Experimental Gameplay. En este refrescante site podéis encontrar juegos que se pueden descargar libremente y que, y esto es lo más interesante, se han desarrollado siguiendo las siguientes premisas.

1. Cada juego se ha hecho en menos de 7 días.
2. En su desarrollo sólo ha participado una persona.
3. Cada juego está insipardo alrededor de un tema en concreto (la gravedad, la vegetación...).

El objetivo del proyecto es promover la utilización del prototipado rápido como una herramienta de investigación con la que los creadores de juegos testen nuevos conceptos de gameplay que hasta ahora corrían el riesgo de quedarse en el el olvido de un documento de diseño.

Para los que creáis que estamos hablando de juegos simplones y aburridos, provad el Tower of Goo, uno de los más recomendables.

Los que queráis conocer de primera mano cómo funcionan este tipo de desarrollos tan cortos, pasaros por este artículo de Gamasutra. Sumamente interesante.