Designostic

Gameto, la nueva cara de Designostic

2006-12-19T19:20:00.000+01:00

Hace un tiempo os informamos que designostic era tan solo una solución temporal (ver) hasta que tubiéramos preparado el site definitivo. Finalmente, tras 8 meses aquí y más de 8000 visitas en total, Designostic muda su piel para convertirse en gameto, "un espacio sobre la creación de videojuegos".

Gameto es un proyecto que nace con el objetivo de ofrecer una plataforma de debate y reflexión sobre el desarrollo de videojuegos. Un site destinado a aumentar la calidad de los artículos y debates que se realizan sobre la creación de videojuegos en castellano.

Por ello, desde el primer día asumimos que nuestro principal compromiso es con la calidad y claridad de los contenidos, orientados tanto a los profesionales de la indústria como a todos aquellos que deseen aprender o introducirse en ella.

El site debe conceder a todos sus participantes la posibilidad de nutrirse mútuamente mediante el intercambio de conocimientos en un marco de tolerancia y meditación.

Los noveles podrán informarse sobre las prácticas y metodologías necesarias para introducirse en la indústria, mientras que los profesionales podrán desarrollar nuevas ideas, exponerlas y debatirlas con el resto de participantes.

Pedimos a todos aquellos que deseen expresar su opinión a través de las herramientas del site, un respeto total al resto de contertuliantes y a sus opiniones, así como la reflexión previa a la declaración de los ideales propios en pro de nuestro principal objetivo: el nutrimiento recíproco de todos los participantes.

Si tenéis cualquier duda o sugerencia, no dudéis en enviar un e-mail a editores@gameto.es.

Muchas gracias por visitar gameto. Esperamos que la estancia allí os merezca la pena.

Del género de rol: El sistema de clases

2006-12-08T19:26:00.000+01:00

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

2006-11-24T14:46:00.000+01:00

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

2006-11-01T21:01:00.000+01:00

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

2006-10-15T00:22:00.000+02:00

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?

2006-10-05T19:30:00.000+02:00

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

2006-09-29T16:35:00.000+02:00

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

Triple A

2006-09-18T10:01:00.000+02:00

Hace poco recibíamos en nuestro e-mail para consultas, dudas y sugerencias, designostic.staff@gmail.com, la siguiente pregunta de Fernando Claros de Luna: "¿Qué diferencia un juego AAA, un A y un B?". Este post pretende dar una respuesta a esta duda.

La clasificación AAA, A y B se establece básicamente por la cantidad de dinero invertido inicialmente en el desarrollo del juego.

- AAA -

Son todos aquellos juegos que parten de un presupuesto inicial de varios millones de euros y, lógicamente, se espera recuperar ampliamente la inversión vendiendo millones de copias.

Vendrían a ser como los “blockbusters” de Hollywood tipo “Titanic”, “El Señor de los Anillos”, “Harry Potter”, “Piratas del Caribe”, etc. Desde la propia concepción del proyecto se diseña para ser un producto de masas.

Estos juegos acostumbran a ir acompañados de grandes campañas de marketing que aseguren que la publicación de este título es un gran evento mediático. Cuanta más gente conozca tu producto, más potenciales compradores tendrás.

En cuanto a la calidad del producto final, dada la gran inversión realizada, se espera que un triple A tenga un excelente acabado que asegure que la puntuación media de este no baje del 90% o el 80%. Un juego AAA debería asegurar unos gráficos "a la última", un sonido alucinante, etc. y una jugabilidad enfocada al mayor rango de público posible (aunque no necesariamente innovadora en ningún sentido).

Ejemplos de triple A:
- Metal Gear Solid 2
- Final Fantasy XIII
- Half Life 2
- GTA San Andreas
- Halo 2
- Assassin’s Creed
- Gran parte del catálogo de PS3 y XBOX360

El concepto triple A a veces se utiliza, sobretodo en prensa, de forma un poco ambigua refiriéndose tan solo a la calidad del producto final.

Además, actualmente algunas pequeñas y medianas desarrolladoras afirman que, con un presupuesto menor, pueden realizar un juego triple A. Eso no es más que una técnica de venta basada en el mal uso del concepto y refiriéndose, de nuevo, tan solo a la calidad final del producto. Para hacer un triple A se necesita un diseño de producción y un soporte mediático basados en un presupuesto inicial que probablemente no tienen ni tendrán en ningún momento estos supuesto “vendedores de AAA a precio de A”.

- A -

En esta categoría entrarían aquellos juegos que tienen un presupuesto medio o discreto, pero sin llegar a ser un juego tipo “budget”.

Algunos de estos juegos han llegado a dejar su “marca” en la indústria tanto por la calidad o innovación del producto, como por la positiva respuesta de los consumidores a esa idea jugable. Un A puede llegar a vender más que un AAA, pero nunca será tildado como tal puesto que desde su concepción (el presupuesto inicial) la cantidad de dinero invertido es menor.

Normalmente los A que venden grandes cantidades de copias acaban siendo AAA en sus secuelas.

Ejemplos de A que han acabado vendiendo como un AAA:
- Commandos: Behind Enemy Lines
- GTA 3
- Shogun: Total War
- LEGO Star Wars
- Pro Evolution Soccer 1
- Half Life 1

Otros ejemplos de A:
- Okami
- Dance Dance Revolution
- Armored Core
- Zone Of The Enders
- Gran parte del catálogo de PSOne, PS2 o XBOX

- B -

Son los juegos normalmente llamados “Budget” o “Económicos”. Se realizan con presupuestos muy bajos y tienen un acabado y diseño de producción acordes con la inversión de dinero inicial realizada.

Como en la anterior categoría, eso no quiere decir que no puedan llegar a vender mucho más que cualquier AAA o A y sean mucho más rentables. Un símil en el cine sería "The Blair Witch Project", que con un presupuesto discreto, llegó a un amplio sector del público y tubo muy buenas recaudaciones.

Ejemplos de B:
- Deer Hunter
- Bomberman
- Puzzle Bobble
- Brain Training
- Wario Warez
- Pokemon original
- La mayoría de juegos para móbiles, pequeñas portátiles y XBOX Live Arcade
- ...

Para más información sobre este tema:
Raphcoster.com
Deffmute.com
Stardock.com
Mostrar/ocultar artículo...

Flexible complejidad

2006-09-18T05:16:00.000+02:00

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

El futuro de los "videojuguetes"

2006-09-10T19:43:00.000+02:00

Suena el timbre de casa. Me levanto para abrir. Es el amigo de mi hermano pequeño, que como cada día en las últimas dos semanas, viene a casa para jugar al GTA: San Andreas. Le pregunto cuando se va a comprar una PS2, que acaba de bajar de precio. Luego por qué misión va; más que nada por saber si tuvo el valor de completar la persecución que me apeó del GTA hace un par de días.

Me dice que él no juega las misiones. ¿Cómo que no juegas las misiones? ¿Nunca? Me siento en el sofá y me dispongo a observar.
Cargar partida. 0% del juego completado. 0 secretos descubiertos. 25 horas de juego.

CJ aparece con un ramo de margaritas en la mano. El amigo de mi hermano pulsa un montón de botones en una rápida sucesión, invocando con ella a un tanque ruso de 8 metros. Sin soltar el ramo de flores, CJ se sube en él y empieza la locura. Durante los siguientes 120 segundos pasa lo siguiente:

Mueren 67 NPCs (8 de los cuales aplastados debajo las cadenas del tanque).
Explotan 32 vehículos (un carrito de golf entre ellos).
Están a punto de ser atropelladas 3 ancianas que iban hacia el bingo (una de ellas es la mismísima abuela de CJ).
El amigo de mi hermano no puede borrar de su cara una enorme sonrisa de satisfacción, soltando una carcajada cuando la abuela de CJ esquiva el tanque por segunda vez con un brinco de metro y medio que la hace chocarse de cabeza contra el único semáforo que se mantiene en pie de toda la calle.

Este artículo pretende, utilizando lo que nos cuenta el caso anterior, reflexionar acerca de los conceptos juego y juguete, intentando descifrar qué papel puede jugar el juguete en una industria que hasta ahora referencia casi exclusivamente al concepto de juego.

Se acostumbra a definir juego como aquella actividad recreacional donde los participantes siguen una serie de reglas para conseguir unos objetivos conocidos y que, en última instancia, definen cuando el juego ha acabado y cual de los participantes ha sido el ganador. Un juguete, sin embargo, se define simplemente como un objeto con el que se entretienen los niños.

Comparemos nuestro caso de estudio con un deporte, por ejemplo el fútbol. El fútbol también puede considerarse como un juego porque hay un reglamento complejo que define las reglas que deben seguir los participantes para la consecución del objetivo principal del juego (marcar más goles que el contrario).

Pero al igual que el GTA, el fútbol puede ser igual o más divertido si se practica sin seguir esas reglas, sin plantearse un objetivo que lleve a la victoria o la derrota, simplemente experimentando con su mecánica base (golpear un balón esférico con cualquier parte del cuerpo a excepción de las manos, en el caso del fútbol).

La competitividad ha sido hasta la fecha uno de los sustentos básicos que han atraído al usuario del videojuego, y como consecuencia, la pauta de diseño primordial que ha seguido la industria de desarrollo. Conceptos como "Puntuación máxima", "Récord", "Victoria", "Derrota" atraen al jugador que busca retos donde demostrar su valía y habilidad.

Sin embargo, a medida que los juegos se convierten en un medio de entretenimiento de masas, el jugador medio empieza a diversificarse, convirtiéndose poco a poco en el "jugador casual", que no va a prestarle más de media hora de su timepo a un videojuego si tiene que dedicarle más esfuerzo y paciencia de lo que está dispuesto a invertir en cualquier otro tipo de oferta de ocio.

Esto significa que nuestro jugador casual no va a regalarle cinco horas de sufrimiento al Counter Strike (los que queráis profundizar en esta experiencia recomiendo leeros el artículo de Sergio en este mismo site acerca de este tema), confiando que a partir de la sexta hora todo va a cambiar y empezaremos a divertirnos.

Competir implica esforzarse, y no siempre queremos esforzarnos en nuestro tiempo de ocio; nos vale con divertirnos. Permitir, quizás inconscietemente, que un videojuego sea experimentado sin las ataduras que implican objetivos y relgas, es en mi opinión una de las razones por las que GTA ha vendido millones de copias en todo el mundo. Algo parecido pasa con los Sims, otro de los videojuegos más vendidos de los últimos tiempos, o con Nintendogs, otro éxito indiscutible.

Como el GTA, los Sims, Nintendogs o el cada vez más popular Second Life, son propuestas donde la experimentación está permitida, donde el jugador puede expresarse y disfrutar de la experiencia interactiva sin la presión de equivocar un salto que implicará repetir 10 minutos de retos superados, no encontrar una pista indispensable para continuar o olvidarse de grabar la partida antes de un enfrentamiento especialmente difícil. Son, posiblemente, algo más cercano a un juguete que a un juego.

Me considero un jugador casual, por suerte o por desgracia como la mayoría de jugadores de videojuegos actuales. Por eso creo que los "videojuguetes" van a ir adquiriendo mayor protagonismo en los próximos años.

No estoy diciendo que deban desaparecer los videojuegos competitivos. Voy a seguir jugando al Pro Evolution Soccer o al Unreal Tournament, porque me gusta competir en ellos. Pero no tengo tiempo de ser competitivo en todos los juegos que me atraen. Así que prefiero un "videojuguete" que me divierta y sorprenda, a 20 "videojuegos" que me recuerden constantemente que no soy suficientemente bueno para ellos. Me gustan los "videojuguetes".
Mostrar/ocultar resto...

Diseñar es diseñar para las personas

2006-09-03T22:30:00.000+02:00

En mi primera contribución para Designostic os voy a presentar un libro. Un libro sobre diseño, obviamente. Y un libro que creo que todos los diseñadores deberían de haber leído al menos una vez en su vida.

¿De qué habla este libro? De puertas que son difíciles de abrir, interruptores de la luz incomprensibles y duchas que son imposibles de manejar. Y de centrales nucleares que se funden y aviones que se estrellan. El libro se llama “The Design of Everyday Things” y su autor es Donald A. Norman.

Siendo un poco más técnicos, el libro trata sobre el “user centered design” o, dicho en cristiano, el diseño centrado en el usuario. El libro analiza todo tipo de objetos de uso cotidiano y trata de averiguar por qué hay tantos objetos que, siendo tan simples en su concepción, son tan complicados de manejar en la práctica.

¿Qué tiene todo esto que ver con los ordenadores? Y, lo que es aún más importante, ¿qué tienen que ver las puertas, interruptores o duchas con los videojuegos? Los objetos en sí, muy poco. Pero su diseño, todo.

Como el mismo autor confiesa en la introducción a la edición del año 2002, aunque raramente se dice algo explícitamente sobre ordenadores en el libro, todo el libro está hablando, queda y sutilmente, sobre ordenadores. ¿Por qué no hablar directamente, pues, de ordenadores?

La historia de la interacción de las personas con los ordenadores tiene dos partes: los ordenadores y las personas. Los ordenadores, sus programas y sus periféricos, cambian a toda velocidad. La tecnología en general cambia muy rápidamente y es imposible prever con algún grado de certeza cómo serán sus frutos dentro de cinco o diez años. La cultura y la sociedad, sin embargo, cambian algo más despacio. En algunos aspectos, apenas cambian de generación a generación. Y, evolutivamente hablando, los cerebros están completamente estancados. El cerebro con el que estás leyendo estas líneas es exactamente igual, hasta donde los paleontólogos y antropólogos han averiguado, al de un hombre que viviera hace 50.000 años.

En la historia de la interacción de las personas con los objetos sólo tenemos una constante. Y esa constante es el elemento, sin duda, más importante: cómo las personas y sus cerebros se enfrentan por primera vez al uso de objetos que les son desconocidos.

A lo largo de las poco más de doscientas páginas de texto el autor ataca de una manera extraordinariamente efectiva a todos aquellos objetos que son innecesariamente complicados de manejar, desesperadamente difíciles de comprender o que no tienen piedad a la hora de suavizar los efectos de los inevitables errores que cometerán sus usuarios. Y puede hacerlo porque los principios básicos del diseño son los mismos estemos hablando de una cafetera o de una consola de última generación.

Así que olvidémonos por unos momentos de videojuegos y jugadores. Tratemos de ver un poco más allá de la tecnología; una tecnología que, en cualquier caso, tiene los días contados apenas es introducida en el mercado. ¿Cuáles son los principios de diseño fundamentales a la hora de diseñar algo para que pueda ser usado? Es imposible resumir el libro en el espacio disponible, pero echemos un vistazo a algunas de las cosas de las que habla el libro:

Modelos Conceptuales (Conceptual Models): el cerebro humano es una máquina de dar sentido a aquello que parece no tenerlo. No lo podemos evitar. Las personas tienden a crearse modelos mentales del funcionamiento de los objetos que manejan. Cuando el modelo del usuario es más o menos correcto, no hay problema. Pero cuando el modelo del usuario es incompleto o, peor aún, manifiestamente falso, ¡ay del usuario que se encuentre con un problema! No podrá regular la temperatura de su frigorífico, a la central nuclear se le fundirá el reactor o, lo más terrible de todo, el jugador borrará todas sus partidas grabadas pensando que únicamente estaba borrando un perfil. Es tarea del diseñador crear un sistema que facilite a sus usuarios la creación de un modelo conceptual correcto. Y este libro te ayudará a hacerlo.

Retroalimentación (Feedback): los usuarios sólo pueden averiguar los verdaderos efectos de sus acciones sobre un sistema si el propio sistema les da alguna pista. Es fundamental que el estado actual del sistema pueda ser fácilmente interpretado y comparado con el estado buscado por el usuario. Para cada acción, cualquier acción que el usuario pueda realizar, el sistema tiene que hacer obvio que se ha dado por enterado y hacer los efectos de la acción visibles. Éste es un tema del que los diseñadores de videojuegos somos muy conscientes pero, aún así, es sorprendente la cantidad de ocasiones en las que nuestro diseño es algo menos que perfecto.

Limitaciones (Constraints): la mejor manera de asegurarse de que el usuario no pueda equivocarse es hacer que el objeto o el sistema no pueda manipularse mas que de una manera; y que además esa manera sea la manera correcta. Las limitaciones, físicas o lógicas, ayudan a acotar los árboles de búsqueda que los usuarios deben recorrer a la hora de llevar a cabo aquello que quieren hacer. ¿Por qué no facilitarles el trabajo? Para eso están los diseñadores, ¿no? A mí personalmente me parece increíble el esfuerzo que requiere insertar la clavija de un dispositivo USB. ¿Qué impidió diseñarlas de manera similar a las de los monitores o los altavoces?

Mapeos Naturales (Natural Mappings): la distribución, visibilidad, forma y uso de los controles de un sistema es otro de los temas de los que trata el libro. Una distribución ‘natural’, que utilice restricciones geométricas, antropométricas y culturales, puede facilitar mucho el aprender a usar un sistema. ¿Es que hay alguien aquí que NO se haya equivocado alguna vez al encender el fogón deseado en una cocina? ¿Por qué hay cuatro controles en fila? ¿Por qué no estarán dispuestos los controles en forma de cuadrado? Éste es otro tema increíblemente importante para los diseñadores de videojuegos. Sólo comprendiendo principios abstractos y generales podremos enfrentarnos a un controlador como el de la Wii sin haberlo visto antes con algo más que intuiciones en la cabeza.

Este libro habla de todas éstas y muchas más cosas: de cómo los usuarios planean y llevan a cabo sus tareas; de cómo funciona la memoria y qué implicaciones tiene; de cómo clasificar, detectar, prevenir y corregir los distintos tipos de errores de los usuarios; etc.

Como habréis podido ver, el libro habla básicamente de interfaces, tanto de entrada como de salida. Pero habla de interfaces sin hablar de ordenadores. Si estáis buscando libros que os den recetas de cómo hacer un FPS perfecto, no os va ayudar en absoluto. Pero si queréis ir un poco más allá y entender en qué consiste en realidad el diseño y la tarea del diseñador, este libro es lectura obligatoria. Y su valor, incalculable.

Además, es tremendamente entretenido y, a veces, desternillante. Que nunca es una mala cosa en un libro con implicaciones tan serias como éste.

Mostrar/ocultar resto...

Se trata de ganar

2006-09-01T21:48:00.000+02:00

¿Deben los juegos estar bien equilibrados y ser justos para tener exito? Yo solia pensar que si, hasta que jugue a Counter Strike.

Puede que este post sea el resultado de mi frustracion con el juego (desde luego no estoy esperando que los marines intenten reclutarme gracias a mi extraordinaria habilidad), o puede que haya algo de verdad en la idea de que Counter Strike esta terriblemente desequilibrado a favor de los jugadores mas habiles, y eso es en parte lo que lo hace tan irresistiblemente atractivo.

Para empezar, veamos el concepto de realimentacion. En un juego continuo, el exito en una mision suele tener un efecto en el rendimiento en futuras misiones. Puede ser que hayamos conseguido mejores armas, subido nuestras estadisticas, o hayamos eliminado parte del enemigo. La realimentacion es el hecho de que acciones presentes se "realimentan" en el sistema, y modifican su estado.

El resultado de esta modificacion puede variar. Si al jugar muy bien un nivel obtengo facilidades y me resulta mas facil avanzar en los siguientes niveles, lo llamamos realimentacion positiva. Cuanto mejor juego, mas a favor lo voy teniendo, y mejores resultados obtendre. Es como una bola de nieve. Cada vez lo tengo mas y mas facil, y lo hago mejor y mejor.

El opuesto es, claro, la realimentacion negativa. Si lo hago muy bien, el juego varia para compensar y no darme ventajas, o incluso hacerse mas dificil. De esta manera el desafio tiende a estabilizarse. Si meto mucho la pata, el juego me sigue dando oportunidades, hasta llegar a mi capacidad. Si, contra todo pronostico, lo hago muy bien, el juego ira introduciendo handicaps, hasta alcanzar un equilibrio.

Los ejemplos mas claros de realimentacion se ven en lo que se llaman juegos de suma-cero (zero-sum games). En este tipo de juegos, como en los negocios, para que un jugador gane otro tiene que perder. Durante el desarrollo del juego, si tenemos realimentacion positiva, en cuanto un jugador que obtenga una pequeña ventaja la realimentacion la amplificara, plantando una alfombra roja que el jugador puede seguir comodamente hasta la victoria final. Por contra, con realimentacion negativa, el jugador que va perdiendo nunca esta demasiado lejos de recuperarse y hasta tomar la iniciativa, con lo que la emocion y la lucha se mantienen hasta el mismo final.

Veamos Counter Strike. En una partida cualquiera, dos equipos compiten uno contra otro. Un desafortunado terrorista estaba mirando hacia otro lado al doblar una esquina y se encontro con una bala entre ceja y ceja. En Counter Strike, una vez mueres estas muerto. Fin de la historia. Eso significa que la habilidad del policia con la SMG, no solo le ha valido un frag, sino que ha dejado al equipo contrario en inferioridad. Ahora los policias son mas, y lo tienen mas facil. No solo eso, las armas del difunto estan a disposicion del policia, en caso de que quiera esa granada extra que el terrorista nunca tuvo tiempo de lanzar. Pero no acaba ahi, no. La velocidad con la que puedes resultar muerto en Counter Strike es alarmante. Un solo disparo, bien colocado, y eres historia. No hay demasiada opcion para rectificar un error: si te sorprenden eres picadillo. Esa es la definicion de diccionario de realimentacion positiva, aunque podria ser incluso peor. Imaginad que en vez de matar al enemigo, lo pudieras pasar a tu bando con un arma especial. En ese caso, la realimentacion positiva seria aun mayor. Convertir a un terrorista le restaria un integrante a su bando, y aumentaria la potencia de combate de las fuerzas de ley y orden, al mismo tiempo.

Asi que tenemos realimentacion positiva en una partida. Veamos el juego en general. Una mecanica basica de Counter Strike es que cuando mueres pierdes todas tus armas y proteccion. Termina una partida vivo (victorioso o no) y tu shotgun y tu traje de kevlar seguiran ahi, preparados para mas accion. Las armas son, obviamente, importantes, y para comprarlas hace falta una sustancial cantidad de dinero, que hay que reunir laboriosamente, bien ganando rondas o al menos matando enemigos. De nuevo se premia ampliamente a los que han tenido exito y se castiga a los que no. Si yo tengo algo mas de habilidad que tu, lo mas probable es que de media consiga mas dinero, y ademas necesite gastar menos, ya que conservare mis armas. Voila. Realimentacion positiva en accion.

Obviando los tecnicismos, el resultado observable empiricamente en los ciber-cafes es que las partidas de Counter Strike suelen ser rapidas y decantarse para uno u otro bando (exceptuando ese policia que se esconde con el rifle de sniper, y que exaspera a todo el mundo), y ademas uno de los dos bandos suele derrotar al otro con frecuencia. Asi que, si eres un buen jugador de Counter Strike, enhorabuena, podras dar tremendas palizas a los novatos, y raramente te sorprenderan, como suele suceder en algunos juegos de lucha (donde gana habitualmente el que pulsa los botones sin criterio a mayor velocidad).

Claro que si eres novato... Y esta es la parte que mas me sorprende. El atractivo de Counter Strike para los novatos es, por una parte, la ocasional hazaña heroica en la que, contra todo pronostico, mataste de un tiro con la pistola a ese terrorista que habia liquidado a tres compañeros y venia con la ametralladora a todo meter, y por otra, morir y morir repetidamente de formas estramboticas, tras vaciar dos cargadores y dibujar la silueta del adversario sin acertarle un tiro, que de tan vergonzosas resultan inmensamente divertidas.

Por supuesto, tras un cierto numero de veces de encontrarse accidentalmente con balas enemigas, uno empieza a perder su sentido del humor, y hace cosas como escribir posts en un blog. Oh, vaya. Otra partida. Bueno, a jugar otra vez.

Mostrar/ocultar resto...

Del 80 que juega el 20

2006-08-25T17:46:00.000+02:00

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

¿Por qué no podemos ser amigos?

2006-08-22T06:45:00.000+02:00

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

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

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

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

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

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

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

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

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

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

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

Mostrar/ocultar resto...

Cuestión de puntería

2006-08-20T00:13:00.000+02:00

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

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

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

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

Empecemos entonces con las principales soluciones propuestas:

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

Mostrar/ocultar resto...

Sufridos diseñadores

2006-08-17T09:07:00.000+02:00

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

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

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

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

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

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

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

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

Mostrar/ocultar resto...

Estructuras

2006-08-08T04:45:00.000+02:00

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Mostrar/ocultar resto...

Retroalimentémonos

2006-08-01T20:47:00.000+02:00

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

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

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

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

El diseñador a examen

2006-08-01T13:06:00.000+02:00

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

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

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

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

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

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

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

Mostrar/ocultar resto...

La regla de los tercios

2006-07-30T17:18:00.000+02:00

Generalmente la mayoría de juegos en 3ª persona no tienen en cuenta uno de los conceptos más básicos de la fotografía: "la regla de los tercios", creada por la cultura griega y aún utilizada en la actualidad.

Aplicar esta técnica en un videojuego otorga más dramatismo a la imagen y contribuye positivamente a la immersión del jugador en nuestro mundo así como a destacar varios objetos y personajes y las relaciones entre estos.

El objetivo de este artículo es dar a conocer la teoría y la práctica de esta técnica a los diseñadores de videojuegos que no han recibido una formación de fotografía (como yo) para que lo tengan en mente al diseñar la disposición de los elementos en la pantalla (y no me refiero a la GUI).

La regla

La regla de los tercios afirma que toda imagen se puede dividir en 9 partes iguales dibujando (virtualmente) 2 líneas verticales equidistantes y 2 horizontales (también equidistantes). La imagen quedaría dividida así:

Los cuatro puntos creados en las intersecciones se pueden utilizar para alinear elementos importantes en la imagen. Alinearlos de esta forma aumenta la tensión, energía e interés de la escena representada. El resultado es mucho más "dramático" que simplemente centrarlo en la imagen, como podéis ver a continuación:

Utilizando la misma idea podemos reforzar la dirección en la que se mueve un personaje colocándolo en la interesección más cercana al lado opuesto al que se dirige. Esto también le da más aire a la imagen porque vemos que el personaje colocado de esta forma tiene espacio para correr.

El elemento posicionado siguiendo la "regla de los tercios" no tiene por que ser siempre el protagonista de nuestro juego. A veces enfocaremos a otros personajes o localizaciones importantes para enfatizar su relevancia y llamar así la atención del jugador hacia ellos.

Por ejemplo, podemos representar el enfrentamiento y tensión entre dos personajes de una escena situándolos en las dos líneas verticales, mirándose entre sí. De esta forma ambos personajes parece que están intentando moverse hacia la posición de la pantalla que ocupa el otro.

Un uso exagerado del recurso anterior se conseguiría otorgando a uno de los objetos rivales muchos más tercios de imagen que el otro. Eso daría la sensación de que "se va a comer a su rival". Un uso opuesto de la técnica sería orientar a ambos personajes en direcciones opuestas para reforzar que existe tensión entre ellos pero esta no es física.

Por otro lado, si lo que queremos es darle importancia a los entornos entonces lo que haremos es colocar el horizonte en el tercio superior de la imagen (1 o 2). También procuraremos que el resto de objetos que componen la escena respeten la norma de los tercios.

Aplicación a videojuegos

Estas técnicas muchas veces deberán ser descartadas a favor de la jugabilidad. Siempre que nos dispongamos a corregir la composición de la cámara deberemos asegurarnos que no afecta negativamente a la experiencia jugable. Si en algún momento debemos elegir, siempre decidiremos favorecer a la jugabilidad, no a la composición.

Un caso extremo es cuando el avatar del jugador debe llegar a desaparecer de la pantalla para favorecer la composición de la imagen. Esto es un error que no nos podemos permitir puesto que el avatar es la única referencia que tiene el jugador sobre su posición en el mundo virtual. Vendría a ser como dejar la pantalla en negro en un FPS en el fragor de una batalla sin motivo alguno.

Tampoco puede suceder esto con los objetos o sitios cruciales para la jugabilidad, puesto que el usuario se sentirá frustrado si no puede ver dónde están.

Por lo que la principal premisa al utilizar esta técnica será siempre: "que se vea el avatar y todos los elementos importantes para la jugabilidad del momento".

Ejemplos prácticos

Max Payne

Tu personaje siempre está ligeramente desplazado del centro, tanto vertical como horizontalmente. Eso ayuda a que la experiencia jugable sea mucho más envolvente, puesto que todos los planos de cámara son más sugerentes que un simple "protagonista en el medio". Enfatiza la idea de que Max debe moverse hacia allí. Todo enemigo que se sitúe en esos tercios, se opone a nuestro recorrido.

La técnica llega a su máxima expresión en los "bullet times", donde nuestro personaje ocupa mucho menos espacio en pantalla dando toda la importancia a los enemigos a los que debemos disparar.

Como nota negativa hay que apuntar que a veces tu personaje desaparece de la pantalla, pero sucede en muy pocas ocasiones y por períodos de tiempo cortos, por lo que no llega a afectar de manera crítica a nuestras probabilidades de "triunfar" en el juego. Este defecto se nota sobretodo si durante los bullet times apuntamos a un sitio elevado.

Shadow of the colossus

Este juego hace un uso magistral de la técnica de los tercios.

Cuando nos desplazamos por el mundo, la cámara sitúa al avatar automáticamente en uno de los puntos inferiores para darle más importancia al entorno y hacernos sentir "pequeños". Eso se hace más notorio aún cuando vamos a caballo, donde el desplazamiento del foco de la cámara es mayor. El cielo, cuando es visible, también acostumbra a ocupar uno o dos tercios de la imagen para enfatizar así su importancia y ayudar a la composición de la imagen.

Cuando nos enfrentamos a un coloso la cámara acostumbra a alinear a ambos personajes, protagonista y gigante, en las dos líneas verticales para enfatizar la idea de enfrentamiento entre ambos. Además, el coloso ocupa más tercios que el personaje principal, por lo que se exagera aún más la sensación de "David contra Goliath".

De todas formas, hay que hacerle un pequeño "tirón de orejas" al Shadow of the colossus ya que algunas veces la cámara nos hace malas pasadas dejando a nuestro protagonista fuera del encuadre durante un buen rato. Esto se ve acentuado cuando luchamos contra los dos colosos finales, que por su tamaño hacen más difícil la aplicación de esta técnica

+ info en: worldstart.com, DCmagazine y rule of thirds challenge.

Mostrar/ocultar artículo...

Cuando un "hardcore" se convierte en "novato"

2006-07-28T18:16:00.000+02:00

Leyendo la revista EDGE nº164 encontré un artículo sobre la nueva generación de consolas en el que el autor utilizaba un pie de foto muy sugerente: "When hardcore gamers become newbies...". El artículo explicaba, entre otras cosas, la curiosa situación que se produjo en el "booth" de Nintendo, donde los jugadores "de toda la vida" de repente descubrían que todos sus años detrás de un gamepad no les servían de nada: ahora competían al mismo nivel que los noveles.

Evidentemente, estamos hablando de algo que sucedió en el E3, donde dudo sinceramente que asista algún "novato"... pero me encendió la "llamita de la duda" y me pregunté...

¿Pasará lo mismo con los desarrolladores? ¿Se convertirá EA en una colegiala?

Muchas veces sucede que algunos diseñadores padecemos de, confesémoslo, un pequeño "defecto" profesional: utilizar la gloriosa técnica de "copy-pastear" lo que ya conocemos. Es decir, copiar/adaptar a nuestro juego lo que vemos que funciona y huir de los fallos que anteriormente hemos cometido. Pero... ¿Qué sucede si no tenemos ninguna referencia? ¿De dónde nos copiamos "lo bueno"? ¿De dónde deducimos "lo malo"?...

Un controlador nuevo significa diversión potencial sin descubrir. Y eso se traduce en que los diseñadores deben estudiarla, hacer pruebas y aprender a dominarla. Conocer sus límites, saber qué funciona y qué no, etc.

Los diseñadores debemos aceptar el reto y aprender, otra vez, "desde cero".

Esto también se puede interpretar como una gran oportunidad para aquellos equipos que desean entrar en la indústria y no morir en el intento.

Una empresa pequeña que no puede ni soñar en competir con mega-producciones para PS3 y 360, sí que puede dedicar gran parte de sus esfuerzos a investigar esta nueva jugabilidad. Si lo hacen bien, podrán presentar un producto que destaque del resto sin ninguna "gran franquicia" detrás.

Además probablemente las grandes compañías, sobretodo al inicio, dudo que desarrollen productos específicos para esta plataforma. Publicarán conversiones de algunos juegos que ya están desarrollando para las otras 2 consolas limitándose a adaptarlos ligeramente al nuevo mando. Irán a asegurar, vamos.

Así que no estarán aprovechando la "potencial diversión" que pueda ofrecer esa nueva máquina. Y, ¡qué curiosidad!, precisamente lo que la gente reclamará son juegos que saquen el máximo partido al nuevo controlador. Y aquí es donde creo que hay una buena oportunidad.

A mi, personalmente, me parecería apasionante poder investigar estos nuevos "horizontes". Creo que con esta nueva herramienta podemos crear experiencias diferentes a lo visto hasta ahora. Así que desde aquí os pido, diseñadores que tengáis la posibilidad de trabajar en un proyecto de Wii/DS, ¡que os rompáis los sesos en ello y me "obligéis" a comprar la consola!

+ info en: Web oficial de nintendo wii. Web oficial de DS.

Mostrar/ocultar resto...

De la dificultad en los videojuegos

2006-07-26T14:48:00.000+02:00

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

Estructura narrativa - Análisis demo Prey

2006-07-25T10:11:00.000+02:00

Dado que últimamente hemos dedicado mucho tiempo a hablar de la Narrativa Interactiva en este site, he analizado desde este punto de vista la demo de uno de los últimos FPS que han salido al mercado: Prey. Podéis descargar la demo aquí.

La sinopsis del juego dice así: "Tommy es un mecánico sin suerte, atrapado en medio de quién-sabe-donde, en una reserva olvidada donde los nativos americanos viven completamente aislados de la sociedad. Pero lo impensable sucede... la tierra se convierte en la presa de los deprededadores más grandes de la galaxia..."

Si nos basáramos tan solo en este pequeño resumen, el juego nos podría parecer el típico guión hecho en 5 minutos para justificar una sangría de alienígenas... pero la demo demuestra que los chicos de "Human Head Studios" parece que saben lo que hacen...

- Estructura de 9 actos -

El análisis de esta demo lo he realizado basándome, en parte, en la estructura de 9 actos que propone David Siegel en su site. Recomiendo la lectura de su tesis para un mejor seguimiento del análisis que realizaré a continuación.

- Hero's Journey -

También haré muchas referencias a la obra de Joseph Campbell de la que podéis encontrar un resumen aquí.

- El análisis -

Lo dividiré en escenas entendiendo que "una escena es una acción que se produce a través de un conflicto en un tiempo y en un espacio más o menos continuos, que cambia por lo menos uno de los valores de la vida del personaje de una forma perceptiblemente importante" (Robert McKee, El Guión).

· Escena 0 - (no aparece en el juego) background del juego, biografías personales y "prehistoria" del lugar. Intuido durante toda la experiencia jugable.
· Escena 1 - en la que una nave interrumpe la vida cotidiana de un BAR y abduce a sus ocupantes.
· Escena 2 - En la que los personajes abducidos contemplan el horror que se avecina.
· Escena 3 - En el que el héroe y su objetivo se nos presentan.
· Escena 4 - En el que el héroe hace un paso sin vuelta atrás.

Escena 0 & Escena 1 - Las últimas copas

Breve resumen: Se presentan los 3 personajes principales: Tommy, Jane y el abuelo. Tommy quiere largarse con Jane "a la ciudad" pero esta no quiere abandonar sus orígenes. El abuelo tampoco está de acuerdo con esa decisión. De repente unos "garrulos" se meten con ella. Tú les das una paliza pero Jane te lo reprocha. Mientras discutís, sin previo aviso aparece una raza alienígena en escena que os abduce.

Básicamente en esta escena se refuerzan las ideas de la "escena 0" (prehistoria, biografias y background del juego). También se plantea el conflicto (aliens vs tommy) y nuestro objetivo (que nadie haga daño a nuestros seres queridos/vengar su muerte).

Corresponde a los actos 0, 1 y 2 de la estructura de 9 actos.

Desarrollo de personajes
· En el primer plano del juego el personaje explica sus sentimientos e intenciones: marchar de la reserva con Jane. Todos los personajes, incluso los "garrulos", actúan alrededor de este sentimiento reforzando constantemente la idea de que tommy quiere marcharse de la reserva pero Jane y el abuelo no están de acuerdo.
· Tommy desprecia cualquier cosa relacionada con sus raízes cherokeee e incluso tilda al abuelo de "tarado", totalmente coherente con el anterior punto. El resto de personajes actúan también en contra de este sentimiento que más adelante descubrirás que es absurdo.
· El abuelo le da un cierto aire místico a todo lo que dice y trabaja un poco de "oráculo". De hecho se nos hace entender varias veces que su presencia en el BAR no es habitual, lo que remarca lo "especial" de ese dia y de sus poderes, que más adelante veremos que no son una "tontería" como cree Tommy.
· Jane es un personaje bastante plano que ama a Tommy pero no desea abandonar la reserva.

Preparación del desastre
· Jane te da una llave inglesa, porque eres mecánico, y que más adelante te sirve para machacar a los "garrulos"
· Abuelo sabe que va a pasar algo. Afirma que los aires están cambiando y que Jane necesitará la ayuda de tommy... pero, como buen oráculo, nadie le cree. Los lobos primero y la transmisión especial de la televisión reforzarán su teoría hasta que se demuestra, con la aparición de los alienígenas, que el abuelo decía la verdad.

Ambientación
· Todo el rato tenemos una ambientación "natural" en la que oímos tan solo sonido ambiente (radio) y conversaciones entre personajes. El aspecto gráfico es realista y "usual".
· Cuando sucede "el desastre" se cortan todos los sonidos, se oyen redobles de tambores y se enciende el televisor para anunciar que se han visto "objetos extraños" sobre cielo norteamericano. Se corta la transmisión de golpe otra vez.
· Al cortarse el anuncio volvemos a la ambientación "normal" (radio y silencio fuera) para remarcar la "rareza" del momento.
· En el exterior aparecen unas luces y oímos la nave. Nos abducen.

Escena 2 - por patas 1

Los 3 personajes son arrastrados en una escena "tipo Half Life" en la que vemos como nos desplazan, atados, por el escenario. Un extraño ser libera a Tommy. Acabamos esta escena "en el suelo", preparados para la acción.

Básicamente en esta escena se refuerza lo que ya sabíamos: que nos han capturado y que son muy malos.

Extensión del acto 2 (de la estructura de 9 actos).

Desarrollo de personajes
· Relación de tommy-jane: mediante las constantes peticiones de esta a tommy para que le salve. Tommy, evidentemente, le promete que van a salir de esta. Objetivo: salvar a Jane.
· Posición ante "tema cherokee": Jane reza, Tommy se lo reprocha.
· Refuerzo de la peculiaridad de tommy (misterio): al ser observados por alienígenas 1 de ellos le señala, alarmado, parece haberlo reconocido (qué raro...). Además un extraño ser te salva A TÍ, de forma consciente y premeditada, tiene un plan y tu formas parte de él.

Ambientación
· Vemos la tierra de fondo. Estamos en una nave de alta tecnología.
· Oímos gritos de mucha gente. Es un ataque a escala mundial.
· La gente está sufriendo, no quieren nada bueno.

Escena 3 - por patas 2

Nos movemos por el lugar extraño, descubrimos los portales. Acaba cuando presenciamos la muerte de nuestro abuelo.

En esta escena se apunta a tommy como el protagonista indiscutible del juego, el héroe que lo deberá solucionar todo. También nos dicen claramente nuestro objetivo: salvar a Jane.

Corresponde al acto 3 de la estructura de 9 actos.

Desarrollo de personajes
· Peculiaridad tommy: vemos a tommy en varios monitores durante todo el recorrido. Parece que nos vigilan con atención. El ser "ayudante" aparece de nuevo para abrirnos una puerta cuando no teníamos salida y nos empuja a continuar después del "bajón" de ver morir a nuestro abuelo, nos fuerza a hacer el "treshold".
· Relación tommy-jane: la vemos pasar un par de veces gritándonos a nosotros pidiendo ayuda (refuerzo también del objetivo, salvarla). En varios videos vemos que nos enfocan a nosotros, a jane y al abuelo.
· Relación tommy-cherokee: al presenciar la muerte del abuelo, este nos dice "te espero en el mundo de los ancestros..."

Ambientación
· Estamos entrando en el "corazón" de la nave: una ambientación muy orgánica, antes parecía mucho más mecánica.
· Extraño sitio: personaje hace muchos comentarios al respecto. Hay gente "loca" esparcida por el mapa. Tommy se marea al utilizar el primer portal. Vemos que la idea de "arriba-abajo" no nos servirá en este mundo al presenciar escenas donde se desafían las leyes de la gravedad.
· Nos quieren hacer "pupa": muchos gritos de fondo, videos "desagradables", bichos atacándonos, mecanismos "torturadores", etc.
· Uso de los videos de seguridad es genial. Se utilizan para reforzar el "daño" que hacen en esas instalaciones, el que te están controlando, tu relación con el resto de personajes, etc.

Escena 4 - descenso

Nos metemos "de lleno" en ese mundo extraño entrando por un portal que nos han abierto. El personaje "ayudante" nos dice que debemos apresurarnos, que ya no hay vuelta atrás... Más adelante morimos y el abuelo nos acoge en el mundo de los ancestros, donde nos muestra los poderes ocultos que tenía tommy.

Esta escena es el camino que empezamos a recorrer para conseguir el objetivo que nos han marcado.

Corresponde a los actos 4 y 5 de la estructura de 9 actos.

Desarrollo de personajes
· Tommy es el elegido: siguen ayudándonos, nos persiguen, etc. Tiene poderes ocultos que debe liberar.
· Abuelo pasa a ser el mentor: cada vez que muramos nos acogerá y nos dirá la solución para regresar al mundo de los vivos.

Escena X ...

El resto ya pasa a ser una reutilización contínua de las técnicas anteriores que refuerzan la historia y los personajes así como nuestro objetivo. Realmente esta demo me ha dejado con un buen sabor de boca. Espero que la versión final disponga de algún giro narrativo (acto 6 de la estructura de David Siegel)que nos enganche definitivamente a la história y nos incite a continuar.

Así que, al final, nos quedamos con:

· Tommy: héroe indiscutible que deberá modificar su modo de ver el mundo para poder salir adelante. Las creencias cherokees, que despreciaba, son la clave para solucionar el conflicto.
· Jane: Ha sido capturada y tommy la ama. El deber de tommy es, automáticamente, salvarla. Ella confía en él. Si no se apresura lo más probable es que muera.
· Abuelo: mentor de tommy. Le enseñará las habilidades "cherokee" pese a la negación inicial de su nieto. Sabe mucho más de lo que dice. Su muerte "física" marca un antes y un después. A partir de entonces nos asiste en el mundo espiritual.
· Misterioso alienígena: es un aliado que nos ha liberado y que constantemente nos va abriendo camino. ¿Cuáles son sus intenciones?¿Realmente podemos confiar en él? No tenemos otra opción que hacerle caso.
· La muerte: Cada vez que mueres debes luchar contra unos espíritus malignos de colores rojo y azul que, dependiendo de lo bien que lo hagas, te permitirán volver al mundo de los vivos con más o menos "poder".
· El enemigo: No conocemos sus intenciones ni a su "capo", pero es lógico que no quiere nada bueno. Están planeando un ataque a escala mundial. Por alguna extraña razón, conocen a tommy.

Mostrar/ocultar resto...

De números y juegos

2006-07-25T00:50:00.000+02:00

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

2006-07-20T07:25:00.000+02:00

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

2006-07-18T07:07:00.000+02:00

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

2006-07-17T08:05:00.000+02:00

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

Sigamos hablando...

2006-07-14T11:12:00.000+02:00

Este post está relacionado con uno anterior de Sergio, "Hablemos".

Además de los habituales problemas en cuanto a costes de desarrollo de los sistemas de conversaciones interactivas actuales se refiere, personalmente creo que el handicap de base en cuanto a la incorporación de estas conversaciones como una "key feature" en los videojuegos actuales son el ritmo, la flexibilidad y la finalidad que ofrecen a la experiencia global del juego junto al factor ruido al que normalmente están sometidos. Me explico...

Ritmo

Crear una forma "trepidante" (ritmo) o "emocionante" (finalidad excitante) de conducir una conversación en un juego es complicado. Lo más "excitante" que he visto es el sistema utilizado en "Fahrenheit" que, desde mi punto de vista, no deja de ser un "SCUMM con timing" (ver postmortem)o el "modo ligoteo" del último "Larry", en el que debes jugar a un minijuego mientras dos personajes hablan y la conversación discurre positiva/negativamente dependiendo de tu progreso en el minijuego. Personalmente creo que son dos métodos un tanto "intrusivos" que te enseñan el "esqueleto" del juego al momento, rompiendo el suspension of disbelief (recordándote que estás en un juego, no en una conversación).

Esto en parte se debe a que las conversaciones son tratadas de forma completamente distinta a la jugabilidad básica del juego rompiendo así el ritmo anterior completamente. El usuario pasa a tener una interacción del tipo: "oír/leer... seleccionar opción + apretar botón... oír..." de forma intermitente. Esto es lógico teniendo en cuenta que las acciones/decisiones a tomar en una charla son, normalmente, totalmente distintas a las del resto del juego (correr, saltar, buscar objetos, etc.) así como el ritmo (timing de decisiones) de estas. Además en la vida real básicamente lo que hacemos en una conversación es eso: oír y responder.

Personalmente creo que las conversaciones deberían ser respuestas a estímulos generados por el propio usuario en el mundo simulado, no tanto a un botón "talk" que nos adentra en una nueva modalidad de juego.

Y eso nos lleva al tema de la flexibilidad...

Flexibilidad

En general el jugador siempre debe seleccionar una respuesta de un listado de posibilidades que previamente ha creado el diseñador/guionista y, por lo tanto, el resultado y "path" de la conversación ya están predefinidos completamente de antemano. En una conversación el usuario pasa de tener una libertad de movimientos total (correr/saltar/investigar/etc.) a deber elegir entre tan solo X opciones mostradas "tal cual". Esto viene a ser como jugar al "Dragons Lair" de forma pausada.

De esta forma el usuario identifica immediatamente el "esqueleto" de la conversación y entiede que su deber es, simplemente, seleccionar entre un conjunto de opciones las posibles respuestas correctas para llegar al "final bueno" (si es que hay alguno malo...). Si falla, vuelta a empezar. Vamos, que no puede preguntar "lo que quiera" (lógico, por costes utilizando este sistema) y debe seleccionar respuestas del tipo "¿perdone, cómo puedo destruir el talismán demoníaco creado para dominar el mundo?" ó "¿me puedes repetir lo de la llave roja?".

Personalmente creo que un buen método podría ser la utilización de sistemas más flexibles basados en objetos que representan a las entidades que componen el mundo. Me explico: Se crea un listado de objetos/personajes/situaciones/lugares/etc. (relevantes) que conforman este mundo. El usuario puede utilizarlos como si fueran una especie de item para "mostrárselo" a cualquier NPC. Vendría a ser como "proponer un tema para charlar". El NPC responde a ese estímulo. Todos los NPCs (o tipos de...) deberían tener una opinión sobre cualquiera de estos objetos, aunque sea genérica, por lo que las conversaciones pasan a estar guiadas por los mismos elementos del mundo y al usuario le dará más sensación de control, libertad y evitaremos que vea el ritmo "roto" puesto que no se deberá entrar en ningún momento en un "modo conversación", simplemente mostrará uno de estos objetos que ha acumulado dentro del propio mundo para ver qué reacción provoca eso en el NPC. Esto incluso podría generar situaciones de gameplay aún más interesantes si la respuesta a estos estímulos a veces nos obliga a utilizar otro "feature" del juego (lucha, correr, etc.). Pero esto dependerá, obviamente, de cada proyecto y de lo que se pretenda conseguir a través de las conversaciones.

Finalidad (u objetivos)

Hasta ahora he hablado siempre de conversaciones que tienen la finalidad de "avanzar en la historia". Pero si el objetivo final es, precisamente, lo bien que llevemos una conversación... entonces la cosa cambia (y el sistema de objetos es más complicado de aplicar). Pero con esto no me refiero a la estructura de "Bioware" (árbol de conversación y X finales "buenos" + la posibilidad de volver a empezar siempre que queramos), me refiero a una modificación progresiva de los sentimientos de los personajes que modelarán su rango de acciones/decisiones hacia ti. Esto podría funcionar muy bien en un juego tipo "The Sims", donde tu objetivo principal no es conseguir la "llave de la puerta roja", sino modelar los comportamientos y ver como interactúan entre sí los personajes. Pero Will Wright eludió cualquier profundizado en la conversación... Aquí es donde entra Façade, pero se encuentra con el problema de la "identificación de texto". A no ser que utilizaras "objetos"...

Aparte de los juegos anteriormente mencionados, normalmente siempre el objetivo final de una conversación es "saber el siguiente paso a realizar". El resto es "ruido" que el usuario no va a querer escuchar. Porque el usuario es práctico y cuando reconoce un patrón (conversación = demasiado ruido = hago "skip") lo repetirá continuamente para optimizar su llegada hasta el final del juego. Esto podría solucionarse dando las claves para resolver un enigma en la propia conversación, sin ninguna pista más tipo reminders, notas, etc. consultables una vez finalizada esta, pero entonces el juego sería extremadamente difícil, ya que si lo dejamos 1 día, habremos olvidado completamente lo que debíamos hacer. Sería el mismo "error" que obligar a ver el detalle en una cinemática para poder pasarte un juego. De aquí la tremenda importancia que creo debe darse a eliminar el "ruido" de las conversaciones, a ser "eficientes".

"Ruido"

He detectado que a veces, por un intento de hacerlo demasiado literario, los personajes te "pegan rollos" completamente abismales para decirte, simplemente, la puerta se abre con "X" sin prácticamente poder interactuar más que seleccionando opciones a lo "SCUMM" (en el mejor de los casos). Como dije antes, este creo que es uno de los principales motivos de la tendencia a "skippear" las conversaciones. Creo que con mucho menos se podría comunicar mucho más. El ruido, o información no relevante, no hace más que embrutecer el mensaje (ver minimalismo de "shadow of the colossus").

Más vale tener 1 frase precisa y directa que resuma tanto el mensaje que se debe transmitir como la personalidad del personaje (intuida) que pegar un rollo inhumano en el que el personaje nos explica hasta el último detalle de su vida privada para, definitivamente, decirnos lo que queríamos escuchar de inicio.

Ejemplo: Joe está en una carpintería construyendo una mesa. Tú debes saber dónde se encuentra Molly.
(A - clásico)
acción: hablar con Joe y seleccionar la opción "Molly"
resultado: Joe te explica lo difícil que és construir una mesa y lo tremendamente ocupado que está en ese momento. Tú insistes en que debes ver a Molly urgentemente, pero él te dice que está trabajando y ahora no la puede llamar. Tras insistir varias veces, te acaba diciendo dónde encontrarla. (esto podría hacerse mediante varias selecciones de respuesta durante la conversación, pero no dejaría de ser "otro ritmo")
qué hará probablemente el usuario: si lleva un buen rato jugando, hará un skip a toda la conversación para acabar viendo el "reminder" final de tu misión.

(B - objetos)
acción: encontrar foto de Molly en estancia y entregarsela a Joe
resultado: "Vaya, te diría dónde está, pero ahora estoy muy ocupado"
acción: encontrar cualquiera de las herramientas de carpintero en la estancia y entregársela a Joe.
resultado: "Hombre, gracias! acércame también ese martillo..."
acción: coger martillo y entregar
resultado: "Gracias chaval, la verdad es que a veces me haría falta una mano aquí. Acércame es agenda"
acción: recoger agenda y entregársela a Joe
resultado: "Mira, esta es la dirección de su trabajo. Está por allí de 9:30 a 18:30"
Qué hará probablemente el usuario: le has "obligado" a interactuar con el mundo simulado para avanzar en su relación con el NPC. La conversación pasa a ser una forma natural de desenvolverse por el juego totalmente mezclada con el resto. Pero esto dependerá de cada tipo de proyecto, es evidente.

A mi me ha sucedido con el último "Dreamfall", aventura gráfica, que al principio "me tragué" todas las conversaciones hasta que descubrí que me daban demasiada información innecesaria, pues no me servía ni para profundizar en el conocimiento del mundo, ni en la personalidad de los personajes y al final lo único que me interesana era el "dime qué tengo que hacer". Además han añadido un cómodo dispositivo digital que te recuerda tus objetivos, por lo que realmente no necesitas escuchar ninguna conversación (más razón para pasarlas). Hay algunos puntos en los que puedes elegir un tipo de respuesta u otra, pero pese a influir en la propia conversación, no lo hacen en el resultado final de esta (tu nuevo objetivo es X).

No creo que haya 1 única solución, cada proyecto es un mundo, pero creo que la utilización de un sistema de "objetos" daría mucha más consistencia al juego y solucionaría algunos de los problemas anteriormente citados. Pero repito: dependerá de los objetivos marcados.

Mostrar/ocultar resto...

Un...¿diseñador de juego?

2006-07-11T11:01:00.000+02:00

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

2006-07-06T21:33:00.000+02:00

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?

2006-07-05T16:54:00.000+02:00

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

Ron Gilbert hace un repaso de la industria

2006-07-03T20:02:00.000+02:00

En esta entrevista en gamasutra, Ron Gilbert, creador de juegos míticos como Monkey Island, Maniac Mansion, Indiana Jones y Full Throttle y los más actuales Diablo 2 y Total Annihilation, hace un repaso al actual estado del "Interactive Storytelling" y de la creatividad en la indústria del videojuego.

Os he escrito un resumen de lo que, personalmente, creo que son los puntos "clave" de la entrevista añadiéndole un par de observaciones personales y deducciones. Si este "formato" funciona, postearé otras síntesis que tengo por aquí.

En la entrevista afirma que no se está haciendo un buen trabajo en la creación de narrativa interactiva actualmente. Cree que más que historias interactivas, se están creando “entornos” en los que se presenta una situación inicial mediante cinemáticas y simplemente se va recordando en ciertos momentos de la experiencia, con otras escenas no-interactivas, el "entorno" en el que toma parte el juego.

Ron cree que es el flujo de la história alrededor del juego, o viceversa, lo que define una buena narrativa interactiva.

Pone como ejemplo a "no seguir", en cuanto a narrativa interactiva, la jugabilidad emergente del GTA3. Afirma que es un mal enfoque del concepto, puesto que, pese a que mucha gente diga que "está creando su propia história", él afirma que la mayoría de veces estas historias generadas son de tan baja calidad que no se pueden ni considerar una história. Compara la calidad de estas historias a las generadas en un partido de béisbol, donde el 90% del tiempo no hay historia interesante que contar.

Con eso no quiere decir que una historia no pueda ser modificada por el jugador pero, según él, una historia es una historia: una descripción de la condición humana creada con un ritmo e intencionalidad concretos por un autor conocedor de todas las técnicas de "storytelling". Afirma que es muy común en los videojuegos ver como personas deconocedoras de estas técnicas crean historias sin un ritmo ni un flujo trabajados. De aquí la asociación de "videojuegos = mal argumento" y la consiguiente mal recibimiento de los pocos juegos que basan su experiencia en la historia.

Aunque con eso tampoco reclama que todos los juegos deban tener historia, puesto que hay muchos tipos de jugadores o estados de ánimo en los que tan solo se busca "matar a marcianos". Pero el problema de las malas historias, o la falta de juegos con buenas historias interactivas, tira para atrás a muchos jugadores (clientes) potenciales para estos juegos que sí que podrían tener una buena historia.

Y a todo esto, ¿qué puntos clave debe cumplir una buena história?, según él:

- Conflicto: todas las historias deben tener un conflicto. Sin conflicto, no hay drama. Nota: el conflicto no tiene por qué ser violento.

- Motivación de los personajes: ¿Cuál es su papel en este conflicto?

- Evolución: Los personajes deberían evolucionar durante el curso de la historia y llegar a ser personas diferentes al final del juego.

Afirma que recrear la misma estructura que sus míticos juegos (Monkey, etc.) no funcionaría actualmente: la gente ha cambiado y su sensibilidad ha evolucionado con el tiempo. Por eso su próximo proyecto es un RPG con una fuerte importancia en la historia y sus personajes que aseguran una mezla de acción-descerebrada (tipo Diablo) conducida por unos puzzles e historia más típicos de un juego de aventuras.

En la entrevista también critica la pobre distribución que reciben los productos basados en historias. Afirma que los publishers se hechan siempre atrás al oír "historia" y/o "juego de aventuras". Por eso opina que, al no contar con unos ingresos importantes (y no necesitarlos, como veremos más adelante), es básico tener unos costes de desarrollo bajos. Según él, la plataforma ideal es el PC, aunque posiblemente también sería viable desarrollar este tipo de género en consolas portátiles como la NDS o la PSP. No lo ve en consolas “next-gen” por los costes de desarrollo y el tipo de público que se pretende conseguir. También afirma que la distribución online es una buena vía (seguramente pq así tampoco debes pasar por un distribuidor).

Critica la tendencia de los publishers a intentar desarrollar siempre juegos de 10-15 M$ para asegurar un "triple A", puesto que eso cierra la entrada a nuevas ideas/equipos y limita la experimentación (cuando te juegas tanta pasta quieres "asegurar el tiro").

Afirma que en la madura industria del cine también se hacen grandes proyectos que cuestan millones de dólares, pero que han sabido crear un espacio para el desarrollo y la distribución de proyectos más pequeños, de 1-4M$ que permiten el desarrollo del cine alternativo. Insiste en que las distribuidoras de videojuegos solo quieren “Home Runs”, super-hits, nada de "medianezas", y que su interés es puramente económico, no desde un punto de vista artístico o creativo como sí tenemos los desarrolladores.

De todas formas, puntualiza que en Europa sí que se ha creado un pequeño espacio para la distribución de aventuras gráficas más "económicas" a través de otros canales (por ejemplo, quioscos). Y tienen el suficiente éxito para seguir haciéndolo. El problema viene cuando quieren pasar a un "mass market" haciendo una super-producción con el mismo "appeal" que la producción de bajo coste y ofreciendo el mismo tipo de experiencia. Es entonces cuando la cantidad de público no está "a la altura" del presupuesto (despilfarro de dinero).

Afirma que ha propuesto varias veces, sin éxito, que grandes compañías como EA creen una sub-rama que destine unos 5M$ de presupuesto anual al desarrollo de juegos independientes que puedan utilizar sus canales de distribución y marketing ya creados para llegar a este público potencial. Algo parecido a Disney (family entertainment) y su filial Miramax (Pulp Fiction).
Mostrar/Ocultar el resumen...

Consejos para mejorar como diseñador de videojuegos

2006-07-03T19:18:00.000+02:00

Siguiendo la estela de "40 ways" y "400 project" os propongo crear nuestra propia lista de consejos para mejorar como diseñadores de videojuegos.

Es una lista de caracter general que se irá actualizando a medida que se añadan nuevas propuestas o correcciones en los comentarios de este artículo.

Si le cogemos el "gustillo" a esto, podemos crear en el futuro site listas más específicas del estilo: "consejos para mejorar un documento de diseño", "consejos para trabajar en un equipo creativo", etc. e incluso tocar otros temas como producción, coding, cómo entrar en la indústria, curiosidades, etc.

¿Qué os parece, empezamos?

Listado de consejos para mejorar como diseñador de videojuegos

- Aprende a comunicarte: de nada te sirve saber diseñar si no eres capaz de comunicar tu trabajo a tus compañeros.

- Madura tus ideas: habla con otra gente, discute, acepta sugerencias, compara tus ideas con las de otros. Trabájalas hasta que veas claro que no las puedes mejorar. Más adelante repásalas, nuevos puntos de vista te pueden ofrecer soluciones diferentes, a veces más acertadas.

- Convierte tus ideas en algo palpable: no te quedes con tus ideas sobre el juego en la cabeza, escríbelas. Aunque ahora mismo no puedas aplicarlas, algún día a lo mejor sí, pero aunque tampoco fuera así, nunca habrás perdido de tiempo, el solo hecho de escribirlas te servirá de entrenamiento.

- Discretiza tu diseño: Convierte cualquier idea en algo palpable a nivel jugable. De poco te sirve querer hacer "un juego de relaciones sociales con jugabilidad emergente" si no eres capaz de decir "qué tipos de personaje hay", "qué valores utilizarán para relacionarse entre sí", "como interactuarán con el jugador", etc.

- Aprende a vivir con los límites: debes conocer tus propios límites y/o los de tu equipo. Si no eres consciente de ello, no podrás diseñar juegos, tan solo tendrás "ideas de juego" que quedarán en el tintero o a medio hacer.

- Escucha: Estate atento a todos los argumentos que utilizan tus compañeros para aprender de ellos tanto como puedas.

- Sé flexible: si alguien pone en duda un diseño tuyo, es por algo. Piénsalo de nuevo, trabájalo más. Si además esa persona tiene más experiencia, tómatelo como un consejo.

- Lee sobre diseño: paséate por webs de esta temática (como la nuestra, jejeje), cómprate libros, imprímete todo lo que te parezca interesante, estúdialo, resúmelo y saca tus propias conclusiones/tesis. Un arquitecto/médico sigue estudiando incluso una vez finalizadas sus carreras de 5 años, un diseñador debe estudiar constantemente, si no queda "obsoleto".

- Sé un profesional: Te pagan para diseñar, para cumplir unos objetivos, no para hacer el juego que a tí te gustaría hacer.

- Auto-motívate: Ten la fortaleza mental de convertir cualquier proyecto en algo excitante para tí. Incluso un juego de "El pony de Barbie" debes convertirlo en un proyecto excitante.

- Usa el método "Stanislavsky": estudia conciencudamente lo que pretendes representar en tu juego. Cuanto más conozcas lo que quieres implementar, mejor serás capaz de hacerlo. Si quieres hacer un juego de bicicletas... alquílate una bici e intenta recordar después qué sensaciones te dió. Ahora conviértelas en algo concreto y jugable. Eso sí, mantenlo siempre accesible al tipo de público al que diriges tu producto.

- Documéntate: infórmate intensivamente de lo que vas a hacer. Dedícale el mayor tiempo que puedas/se te permita. Así basarás tus decisiones en argumentos mucho más sólidos y consistentes.

- Recuerda el objetivo original: cada vez que tengas una duda importante, repasa la idea original e intenta que tus dudas se ajusten a ello.

- Ten a tu target en mente: no es lo mismo hacer un juego para "fans del Doom" que para "freaks del Gran Turismo" o para "adolescentes de +16". Tenlo siempre en mente.

- Juega: dedícale un tiempo de tu trabajo a probar juegos y ver qué nuevas ideas hay en el mercado. Debes conocer el medio y las posibilidades que te ofrece. Al igual que un director de cine, que no puede hacer películas sin tener cultura cinematográfica.

- Alimenta tu creatividad: ve al cine, lee novelas, visita museos, pasea por parques, etc. busca aficiones. Cuanto más variado sea tu espectro de inquietudes, más flexible serás a la hora de diseñar y más capacidad tendrás para expresar ciertos conceptos en un videojuego.

¿Cuántos centenares de brico-consejos me he dejado? ;)

Mostrar/Ocultar el listado

Organiza tus ideas

2006-07-02T07:18:00.000+02:00

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 ;)

Artículos "light"

2006-06-28T20:05:00.000+02:00

Una revista de videojuegos independiente y de distribución electrónica, nextgamers, me ofreció hace un tiempo la posibilidad de escribir un artículo para su revista.

¿Y por qué os martirizo explicándoos mi vida?

Pues por dos buenas razones:

La primera es que me echéis un cable dándome vuestra opinión sobre lo que he escrito, proponiendo modificaciones, etc.

Y la segunda es una pregunta. ¿Qué os parecería redactar semanal o mensualmente artículos menos "densos", como este, para ofrecer también otro tipo de contenidos? Podríamos entre todos proponer temáticas generales que creamos que pueden ser de interés general y redactarlo conjuntamente o de forma "rotativa" (cada semana le toca a uno).

- NEXT GEN -

El pistoletazo de salida

El recibimiento de las consolas de nueva generación en el E3 por parte del público ha sido más bien discreto. Imagino que algunos se habrán llevado una decepción creyendo que esto iba a ser una especie de revolución que cambiaría nuestras vidas para siempre. Como pasó con el “efecto 2000”, nuestras vidas siguen igual.

Mejores gráficos, más resolución, nuevos tipos de shaders, HDRI,… el avance gráfico es claro, pero, ¿realmente esto es lo único que podemos esperar de esta next-gen? No.

Sony, Nintendo y Microsoft son muy conscientes de ello y por eso ofrecen, cada uno a su manera, funcionalidades complementarias para sus consolas con el fin de ser los “reyes del salón”: Microsoft con XBOX Live, un maduro servicio de red; Sony con compatibilidad Blue-ray y un Eyetoy2 integrado que promete dar mucho de qué hablar; y Nintendo con su original idea de controlador.

Esto tampoco es algo realmente nuevo, o “next” como le llaman ahora, pues en la anterior generación Sony vendía como funcionalidad “rompedora” la posibilidad de reproducir películas DVD en la PS2, Microsoft su recién nacido XBOX Live y Nintendo su maravilloso controlador… ¿estamos ante un “previous-gen v.2.0”?

¿Y qué es lo que deparará esta nueva generación para los desarrolladores?

Mucho trabajo. De hecho, muchísimo trabajo.

Para competir en esta nueva generación la exigencia gráfica es mucho mayor, y dado que los costes de producción de arte para un videojuego son, aproximadamente, un 60% del presupuesto total, un incremento en este campo supone que la inversión necesaria para desarrollar un juego se vea afectada de forma crítica. Vamos, que es mucho más caro lanzar un producto al mercado.

Esto puede tener un gran impacto sobre las empresas de pequeño y mediano tamaño, que deberán centrar prácticamente todos sus esfuerzos económicos en producir estos gráficos y competir con los grandes. Esto podría hacer que otros aspectos como el diseño del juego y la diversión que aporta, se queden en un segundo plano. Y esto no es bueno.

Estos costes de producción tan elevados pueden cerrar la entrada a la “next-gen” a muchas empresas que quizás aportarían nuevas propuestas refrescantes a la industria.

Una buena forma de impedir este desastre es mediante la utilización de empresas externas de desarrollo de paquetes de arte, a quienes tú pagas una suma razonable de dinero para que te proporcionen una parte del arte necesario para tu juego. Un buen ejemplo de ello es Oblivion, que utiliza “SpeedTree”, un generador procedural de árboles, y “FaceGen”, un motor de creación y animación de personajes, para abaratar estos costes de desarrollo de arte y así poder dedicarle más tiempo, y dinero, a otros aspectos del juego… sin morir en el intento.

Pero… ¿Qué tipo de juegos podemos esperar de la next-gen?

Al ser necesarias unas inversiones mayores, imagino que algunos publishers querrán asegurar el tiro y quizás tiendan, sobretodo al principio, a no complicarse la vida y apostar por las antiguas fórmulas… con gráficos next-gen. El dinero no sale de debajo de las piedras, y si un proyecto que antes costaba X Millones de € ahora cuesta el doble, querrán asegurar su inversión. Y la opción más fácil parece ser, en un principio, repetir los éxitos del pasado maqueándolos para que parezcan algo nuevo.

Es decir, que continuaremos viendo un montón de secuelas de juegos como FIFA, Need For Speed,… eso sí, todos ellos con HDRI, polígonos para parar un tubo, texturas de alta definición, resoluciones de pantalla HD, etc. ¿Suena emocionante? Creo que no. ¿Cuántos FPS con 300 efectos gráficos “nextgen” habéis visto ya anunciados para las nuevas consolas? A eso me refiero. Pero un juego no se sostiene tan solo por los gráficos, y los “next-gamers” son conscientes de ello.

Resumiendo, creo que al principio sucederá algo parecido a esa época en la que se invadieron los cines con películas repletas de efectos especiales. La gente iba al cine a ver esos asombrosos efectos y eso, por sí solo, justificaba el pago de una entrada de cine… pero cuando el público se acostumbró a ellos ya no provocaban ningún efecto en el público y, por consiguiente, las productoras tuvieron que empezar a buscar nuevas formas de atraer al público.

Los gráficos son importantes, es evidente, sobretodo si tu competencia más directa apuesta fuerte en ese sentido. Pero, en todo caso, eso no es lo que debería definir una experiencia de juego. Prueba de ello la tenemos en las sagas “Pokémon” o “Los Sims”, seguramente los videojuegos más vendidos de la historia… Y no basan su experiencia precisamente en su potencial gráfico. Digamos que un videojuego es, o debería ser, “diversión en estado puro”. Si quisiéramos tener una experiencia meramente contemplativa, iríamos al cine o a un museo.

Por eso creo que esta generación lo que traerá son: jugadores next-gen, “Next-gamers”. Y es que en un medio cada vez más maduro, es lógico que sus consumidores, los jugadores, empiecen a exigir algo más que tan solo unos gráficos llamativos, que busquen nuevas experiencias jugables que “calen” más hondo, que no se queden en una simple matanza de alienígenas o una carrera de vehículos tuneados.

Aquí es donde entra la habilidad de cada desarrollador para exprimir el hardware disponible y crear una experiencia diferente, capaz de ofrecer un juego inolvidable que se diferencie del resto por su temática, ambientación o posibilidades de interacción. Pero también estos “next-gamers” tienen parte de responsabilidad, pues deben empezar a reclamar estas experiencias únicas que hagan de esta generación algo realmente “next”.

Mostrar/ocultar artículo...

¡Novatos a la carga!

2006-06-28T19:46:00.000+02:00

Hace tiempo leí un artículo sobre la valoración de los productores novatos en una desarrolladora de videojuegos y su comparación con la de un programador: http://www.edery.org/2006/03/what-does-top-entry-level-talent-cost-nowadays/

De este artículo y de lo que comentan algunos de los contertuliantes, saqué estas conclusiones también aplicadas a los diseñadores novatos:

La valoración de un programador o un artista “novatos” en una empresa de videojuegos es mayor que la de un productor o un game designer. Esto se debe a que el resultado del talento y conocimientos de un artista/programador nuevo en la empresa se pueden palpar de forma prácticamente inmediata desde el primer día en que entran a formar parte de la plantilla.

El productor y el diseñador novatos, en cambio, tan solo ven recompensados sus esfuerzos una vez el proyecto ha avanzado lo suficiente, puesto que entonces se demuestra que su intuición era la correcta y que las decisiones tomadas durante el desarrollo del juego apuntaban a un objetivo que finalmente se ha conseguido.

El trabajo del Productor pasa la mayor parte del tiempo por contactar con agentes externos a la desarrolladora y hacer números de los que los integrantes de la plantilla ni siquiera son conscientes, por lo que es un trabajo que para la plantilla es difícil de valorar, porque no lo ve.

El Diseñador tiene un contacto más directo con la plantilla pero la mayoría de veces sus decisiones se analizan de forma aislada, sin tener en cuenta la visión global que el diseñador sí que debe tener sobre el conjunto del proyecto. Cambiar estos casos aislados sin tener en cuenta el juego al completo comporta, algunas veces, errores graves de coherencia que después afectan a la calidad del diseño del producto final.

Con todo esto no vengo a decir que ser un buen artista o un buen programador sea más fácil, sino que demostrar su valía es, en la fase inicial, más sencillo. A un productor o un diseñador se les debe dar confianza y esperar a que los resultados de sus decisiones hablen por sí mismos una vez se ha avanzado lo suficiente en el proyecto y empiezan a verse los frutos. Pero hasta entonces... hay que fiarse de la intuición del que "fichó" a ese diseñador o productor.

Quizás esto también se deba a que el producto del trabajo de un diseñador o productor depende del trabajo del resto del equipo. Por ejemplo, para un diseñador es difícil, a veces, expresar a alguien que no se dedica a diseño que un documento que él ha creado, con su concepto, listado de reglas, condiciones, funcionamiento, etc. tendrá como resultado algo "divertido". Y más cuando el programador no quiere un documento con los motivos (llamados habitualmente "pajillas") sino uno con las 4 tablas que resuman el comportamiento lógico que le permita crear ese "trozo de código".

¿Vosotros qué opináis?

Mostrar/ocultar resto...

Crawford contra el mundo

2006-06-28T11:04:00.000+02:00

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

2006-06-28T05:51:00.000+02:00

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

2006-06-27T13:07:00.000+02:00

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.

Diseño del nuevo site

2006-06-26T09:12:00.000+02:00

Como estaba previsto, el site recibirá en un futuro no muy lejano una remodelación gráfica y funcional completa. La utilización de Blogspot es tan solo un "apaño temporal" (prototipo) que utilizamos para testear si realmente valía la pena hacer un esfuerzo para crear un site de estas características.

Creo que los resultados hablan por sí solos. Esperamos tener listo para Septiembre el nuevo site con servidor y dominio propios.

Muchas gracias a todos los colaboradores por el tiempo dedicado a postear noticias, comentarlas, etc. Ni una coma de nuestras opiniones se perderá, puesto que se migrará toda la información al nuevo servidor. Así que a continuar currándonoslo :)

¿Y qué nos ofrecerá el nuevo site? Aquí tenéis un breve "preview"...

El site está creado para llegar a ser una plataforma de debate y reflexión sobre el desarrollo de videojuegos, tanto desde un punto de vista profesional como teórico. Intentaremos fomentar en todo momento la discusión de temáticas en base a fundamentos sólidos y argumentos trabajados para que cualquier discusión aporte conocimientos al resto de contertuliantes/lectores.

En cuanto a diseño gráfico, ya habéis podido ver en la imagen superior el excelente trabajo que Felip Ladrón está realizando. Un site estilizado en el que prima la funcionalidad sobre ninguna pretensión artística pero a la vez conservando un estilo propio y atractivo.

Sobre la funcionalidad, en la que estamos trabajando concienzudamente, a continuación os ofrezco una breve descripción distribuida en los futuros apartados que tendrá el site. No hace falta decir que, una vez tengamos el site en marcha, cualquier sugerencia de cambio/mejora/etc. será bienvenida. Debemos crear una herramienta que nos sirva a todos nosotros para llegar a los motivos previamente citados.

ARTÍCULOS

Esta sección es el alma del futuro site.

Será bastante parecida a lo que actualmente estamos haciendo aquí, en blogspot: cualquier usuario con permisos podrá generar un artículo sobre cualquier temática y el resto podrá debatir ese tema, añadir otros conceptos, aclarar/corregir otros, etc.

La gracia especial que aportará el nuevo site es el filtrado de los artículos por temáticas. Podremos ver todos los artículos, de cualquier temática, o dedicarnos tan solo a observar las de "Game Design" o "Coding" o "Arte", "Producción", etc. Además, cada temática contendrá varios sub-temas con los que también podras filtrar las noticias que en ese momento quieres consultar: "Interactive Storytelling", "Level Design", "Prototyping", etc. Con eso, cada día podrás entrar en el site y consultar realmente lo que te interesa.

Podéis ver todas estas funcionalidades en la imagen superior.

Pero no contestos con esto, al crear un artículo, podrás relacionarlo con otro ya previamente creado, y eso establecerá un vínculo directo entre ambos artículos, de forma que si en algún momento lees un artículo que, por lo que sea, te parece interesante, puedes ver con qué lo ha relacionado el autor y visitar esos otros artículos. Esto creo que fomentará la "meta-navegación" a través del site y la rápida información de los visitantes.

También tendremos opciones de personalización tipo: artículos favoritos, últimos 10 artículos visitados, los 10 artículos más vistos del sites, los mejor valorados, etc. Y un cómodo "ver todos los artículos desde mi último login" al que también le puedes aplicar cualquiera de los filtros anteriormente mencionados.

Si conseguimos que esta navegación funcione bien y de forma intuitiva, puede ser realmente cómodo. Las pruebas que de momento estamos haciendo no parecen indicar lo contrario :)

Además en esta misma sección se podrán proponer tesis. Cualquiera de nosotros puede hacer una sobre cualquier tema, y esa tesis se marcará de forma especial para que los usuarios vean que no es un "simple" artículo sino algo más elaborado. Estas tesis las propondrá uno de los usuarios, que hara la versión v1.0. A partir de aquí, en los comentarios de esta tesis podemos citar correcciones, propuestas, ampliaciones, errores, etc. que irán añadiéndose a esta tesis hasta que consideremos necesario. Evidentemente, a cada modificación de la tesis, se variará el número de versión. En principio hacemos esto para fomentar el valor formativo de nuestro site y poder llegar a ser algún dia una referéncia a nivel de desarrollo de videojuegos en habla hispana.

NOTÍCIAS

Esta es una de las secciones más simples del site. aquí podremos incluir noticias del estilo "Will Wright dimite!" o... "EA compra Novarama" o... "Novarama adquiere el 98% de las acciones de EA"... etc. Ya nos entendemos, para estar un poco al día.

LUDOTECA (en las imágenes, "juegos")
Aquí crearemos fichas de videojuegos/prototipos/proyectos/etc. que podrán ser referenciadas desde cualquier artículo/tesis, de forma que si, por ejemplo, nos interesa ver de qué se ha hablado sobre el GTA en el site, tan solo debemos visitar la ludoteca, entrar en el GTA y ver qué artículos hacen referencia a este juego. Es otra herramienta de "meta-navegación" bastante útil.

EXTRAS

Aquí es donde estarán los links permanentes a webs externas, posibles mini-juegos en flash, etc.

NOMBRE DEL SITE

Deberíamos decidir ya el nombre para nuestra criatura... Debemos comprar dominios, registrarlos, etc.

Las opciones que más éxito han tenido hasta el momento son:

gamegnosis: game + gnosis (búsqueda de conocimiento): creo que la asociación de estos dos términos habla por si misma y resume bastante bien el concepto de nuestra idea original de site.

gamegnostics: game + gnostics (los que buscan el conocimiento): parecida a la anterior pero con matices.

gamaleon: game + camaleón (mutable): tiene cierta vertiente "spanglish". Remarca el perfil "camaleónico" (variable) de los profesionales de los videojuegos, que debemos adaptarnos a cada proyecto... o adaptar el proyecto a nosotros :)

He creado un "online poll" para facilitar las votaciones. Intentad reprimir vuestros instintos tramposillos, no votéis 500 veces al mismo nombre ;)

Para los curiosos que tan solo queráis ver los resultados sin votar (o para los que ya hayáis votado): aquí podéis verlos.

Para todos aquellos que tengáis nuevas propuestas para el nombre, posteadlas como respuesta a esta noticia. Serán añadidos lo más rápido posible al online poll para que el resto podamos votarlos.

Mostrar/ocultar resto...

Storytronics

2006-06-23T02:17:00.000+02:00

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

2006-06-21T16:13:00.000+02:00

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

2006-06-19T18:29:00.000+02:00

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

2006-06-18T18:22:00.000+02:00

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

2006-06-18T13:27:00.000+02:00

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 :)

Toshio Iwai - Arte y videojuegos se encuentran

2006-06-06T00:54:00.000+02:00

En breve saldrá en España, para Nintendo DS, la última creación de Toshio Iwai, Electroplankton, del que podéis ver un video aquí. Esta experiencia interactiva encaja perfectamente dentro de la tendencia actual de Nintendo, que pretende abrir el mercado del sector de los videojuegos buscando nuevos tipos de usuario. Si queréis más información aquí tenéis el site del producto.

Previamente a este proyecto, Iwai ya había creado un juego para SNES llamado "Sound Fantasy" que fué cancelado y lanzado para PC bajo el nombre de "Sim Tunes". Este programa permite crear "pinturas musicales", es decir: utilizando una interfaz tipo "paintbrush" tú dibujas una figura y unas pequeñas criaturas interactúan con lo que has creado tocando una nota musical en cada "píxel" de tu dibujo. El programa auto-corrige los sonidos para que la canción que has creado siempre tenga una sonoridad adecuada. Actualmente se puede adquirir en tiendas de segunda mano o dentro del pack de juegos para niños "SimMania".

El próximo proyecto de este creador es el "Tenori-On". Para los que no tuvisteis la oportunidad de verlo, aquí tenéis el video de la interesante presentación que hizo en artFutura05 de este proyecto, un nuevo instrumento que será fabricado por Yamaha y distribuido en cualquier tienda de electrónica convencional. Si queréis más información del producto, podéis verla en la web de la propia YAMAHA.

Personalmente, creo que la aparición de creadores con el perfil de Iwai confirman que nuestro medio está madurando.

Mostrar/ocultar resto...

De Juegos e Historias

2006-06-05T13:15:00.000+02:00

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.

2006-06-04T21:13:00.000+02:00

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.

Ken Perlin's Law

2006-06-02T20:25:00.000+02:00

Recientemente Ernest Adams ha publicado un artículo en gamasutra bastante relacionado con la temática que tratamos en "Gonzalo Frasca - Thoughts about GTA3". Si queréis leerlo, aquí tenéis el link.

Presenta el artículo con estas ideas:
"For a long time now, we game designers have assumed that player freedom is a good thing, especially in the context of fictitious game worlds where the player can move around and explore. This assumption goes all the way back to the original text-based adventure game, Adventure (or Colossal Cave). Adventure was different from other computer games of its day because it didn’t print a list of commands for the player to choose from. Instead, it simply put a prompt on the screen and said, “type anything you want to.” It pretended that you could do anything.

Of course, after five minutes of play you realized that this was an illusion; the game didn’t really understand that many commands. But, among those of us who are optimistic about the potential of computer games, it created a fond hope, a utopian dream: Someday we will create a game in which you can do anything! And this dream has been at the back of game designers’ minds from that day to this."

Pese a lo prometedor de los anteriores párrafos, el artículo se queda un poco corto a mi entender. Creo que el concepto que intenta "vender" es tan idealizado como lo mismo que "critica".

El problema lo plantea claramente, precisamente en estos dos párrafos, pero la solución que propone creo que no es, ni mucho menos, la óptima. Parece que en vez de replantearse desde inicio el propio diseño del mundo (entorno, posibles interacciones, economía, etc.) para que el usuario no se dé cuenta de estas limitaciones reales que nos da la tecnología/costes/...(tal y como GTA hace a la perfección a diferencia del Shenmue), quiera corregirlo a posteriori con lo que el llama "credibility prices". Una curiosa teoría que él resume en esta frase: "The cost of an event in an interactive story should be directly proportional to its improbability". Es decir, que cada "tipo de interacción" lleva incorporado un "credibility price" que modifica el "credibility budget" total. El usuario no puede superar con sus interacciones este valor total establecido... una especie de subjuego de valores dentro del mismo juego. Pero lo curioso es que el programa que él propone es capaz de hacer precisamente lo más complicado: detectar elecciones "no previstas" y, además, darles un valor numérico. Si el diseñador ya lo ha tenido en cuenta, pues él ha creado esta tabla de valores, ¿para qué necesita estos "credibility values"? Ya no pasa a ser una reacción imprevista, ¿no?

Quizás mi incredulidad se deba a que no he sabido leer entre lineas. Si os rompéis los sesos con el artículo y le sacáis algo "especial", pues parece que E.Adams está realmente emocionado con este "hallazgo", por favor explicádmelo.

Mostrar/ocultar artículo...

Strange Analyst

2006-05-31T15:37:00.000+02:00

Strange Agency, una empresa dedicada a crear bases de datos de videojuegos, ha publicado una demo gratuita de su software "Strange Analyst" que podéis descargar aquí.

Este programa da acceso durante 20 días a una base de datos con más de 18'000 juegos analizados por los profesionales de Strange Agency que, mediante varios reviews de internet, han listado la importancia que le da la gente a cada "feature" de cada juego, de forma que puedes comparar estos features (y su peso) entre diferentes juegos o incluso con tu idea de proyecto.

Un software bastante útil para designers en proceso de brainstorming inicial o productores que buscan posicionar su producto en el mercado actual.

Las únicas pegas que le he encontrado son:
- Hay bastantes juegos que no tienen datos (entre ellos Fallen Lords)
- Los "features" que han creado en algunos casos son demasiado ambiguos
- No puedes seleccionar si quieres que se omita algún feature o crear uno nuevo
- La interfaz es bastante complicada de utilizar
- Una vez creado un "TAB" con varios juegos, no puedes quitar ninguno de ese tab
... Quizás estos problemas se deban a que es una versión de demo y tiene algunas funcionalidades desactivadas.

Aquí abajo tenéis una imagen de una comparación entre Jak&Daxter y Mario 64. Parece mentira que dos juegos tan similares prácticamente no tengan nada en común en este comparador.

Ese es otro punto negativo, que como deben resumir los juegos en X features, pasa a veces que lo que ellos consideran más detacado de un juego no coincide con lo más destacado de otro juego que tu consideras bastante similar al primero (caso Jak&Daxter - Mario64).

De hecho, si comparamos Jak&Daxter con GTA3, al que también se asemeja en algunos sentidos, vemos que la comparación es más fructífera.

Al final he optado por ver qué juegos considera el programa similares (hay un botón para hacerlo) y veo que, según mi criterio, faltan algunos juegos importantes en la lista. Además cita a otros de los que no he entendido demasiado bien la similitud con Jak&Daxter.

Ver lista de similitudes.

Para solucionar este tipo de problemas sería bastante útil poder crear tus propias categorías/puntuaciones/etc. y que estas se compartieran en red con el resto de usuarios. Así la base de datos aumentaría constantemente con nueva información introducida por gente de la industria y se iría adaptando a los criterios de comparación que utilizan los usuarios... por pedir que no falte.

Quizás todo se deba a mi falta de práctica utilizando el software. Si lo probáis, decidme qué os ha parecido el programa. En todo caso, si este software se pule, que seguro que lo harán en próximas versiones, puede ser una herramienta muy útil tanto para designers como para producers.

Mostrar/ocultar análisis...

¿Se cuentan bien las historias en los videojuegos?

2006-05-28T11:47:00.000+02:00

Revisando el archivo de Gamasutra he encontrado este artículo sobre cómo mejorar el modo en que los videojuegos cuentan historias aplicando técnicas utilizadas en otros medios, más maduros que el nuestro en este arte.

Para que os hagáis una idea de los planteamientos del autor, en el artículo se discute la efectividad de las cut-scenes de Halo, donde vemos al Jefe Maestro diciendo o haciendo cosas que no puede controlar el jugador.

Por el contrario, se defienden y analizan las técnicas sutiles y inmersivas con las que se define la personalidad de algunos de los personajes de Half Life 2.

Si Alyx os sedujo y no sabéis exactamente por qué, echadle un ojo.

Gonzalo Frasca - Thoughts about GTA3

2006-05-26T16:30:00.000+02:00

Seguramente muchos ya lo habréis leído, pero para los que no, aquí tenéis un artículo sobre el GTA3 bastante interesante.

El autor nos argumenta algunas de las razones por las que, según él, GTA3 se ha convertido en un juego tan especial y bien valorado por el público. Para un mayor entendimiento de sus ideas, lo compara con Shenmue y las posibilidades de interacción con el mundo simulado, que es lo que marca la diferencia entre ambas propuestas.

Resumiendo el artículo a groso modo (y con el riesgo que esto conlleva):

La sensación de libertad del GTA3 es la clave de la experiencia pese a que las posibilidades de interacción en las que se basa son bastante limitadas. Esta falta de opciones no es detectada por el jugador puesto que la propia temática de juego y el objetivo final del mismo, ser un simulador de mafia, son totalmente coherentes con el 'set of rules' que nos plantean los diseñadores de Rockstar. Todos tus métodos de comunicación en el mundo simulado se basan en la violencia (disparar, atropellar, hacer estallar,...) y nunca te plantearás "hablar con una abuelita" o "llamar a una puerta", puesto que a tu personaje no le hace ninguna falta hacerlo.

Shenmue, por otro lado, ofrece un tipo de interacción que de buen principio definiríamos como más 'realista' o 'humana', dado que para avanzar en la historia debemos charlar con muchos personajes. Y es eso mismo lo que pone en evidencia que estamos ante un videojuego, puesto que trabajar una IA capaz de responder de forma igualmente realista sería demasiado costoso (ver Façade). El juego digamos que se queda "a medias" rompiendo así el "suspension of disbelief".

¿Qué opináis vosotros?

Mostrar/ocultar resumen...

Rock Jonson: el gurú

2006-05-23T10:54:00.000+02:00

Ha nacido un nuevo ídolo para todos los diseñadores de videojuegos: se llama Rock Jonson y, por fin, ha aceptado compartir una pequeña parte de su conocimiento infinito a través de este site:

Es bastante curioso. Lo mejor, a mi parecer, es su "biblia del diseño", descrita en el artículo "Design 101" del que destaco esta apoteósica frase: "It doesn’t matter if the player isn’t having fun right away, if it’s important to the story then put it in, because there’ll be plenty of time for fun later on."

El tío se las da de genio pero en el fondo se está cachondeando de algunos de los errores más típicos de diseño. Digamos que vendría a ser una especie de "Jean Luc Godard" o un "Ferran Adrià" de los videojuegos (por el tema de "deconstruir" el diseño). Pero todo con un tono gamberro y sobrado que lo hace bastante gracioso.

Ya me diréis qué os parece.

Modelo de comportamiento humano

2006-05-18T15:52:00.001+02:00

En este enlace hay explicado un modelo de comportamiento humano enfocado a videojuegos.

Se basa en una categorización de la conducta humana en 3 grupos básicos a los que añade 3 combinaciones de estos 3 primeros grupos "puros", haciendo un total de 6 tipos de conducta. Explica las posibles interacciones de estos entre sí, de las ventajas/desventajas de cada uno de estos grupos, etc.

La aplicación práctica en un videojuego es difícil, si más no utilizando las mismas premisas de clasificación que ellos, pero creo que vale la pena leerlo para comprender el funcionamiento del sistema y la forma de razonar que han seguido para crear estas relaciones entre grupos.

Sobre el tiempo y el espacio...

2006-05-18T15:52:00.000+02:00

A través de los foros de IGDA he encontrado este enlace. Es un interesante ensayo sobre el tiempo y el espacio en los videojuegos actuales. El autor presenta un par de ideas que, creo, abren un buen tema de debate.

Sobre el título del site...

2006-05-18T15:40:00.000+02:00

Hay que elegir un título para el site.

Temporalmente tenemos "designostic", pero no puede quedarse así: es demasiado complicado de recordar y además en el futuro site (que Felip está preparando) no solo se va a hablar de diseño. Será una web modular donde programación, arte, etc. también tendrán su espacio.

Si siguiéramos por la vía "gnóstica" (de los que buscan el conocimiento), podría quedar algo del estilo: 'gamegnostics', 'gamegnosis',... pero quizás es demasiado complicado.

Tenemos que elegir un nombre para el site. ¿Vosotros qué opináis?