28 junio, 2006

Artículos "light"

Artículos Light para otro tipo de lectores.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.

Ya han enseñado sus cartas. Ahora veremos quién se lleva el gato al agua.
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.

SpeedTree en acción
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.

Lo mismo, pero con mejoras gráficas.
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.

Okami es una experiencia diferente a lo que estamos acostumbrados.
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!

¡Novatos al poder!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

Os recomiendo que leáis (si no lo habéis hecho aún) la entrevista a Crawford realizada en Junio en Gamasutra con el exagerado título Video Games are Dead. Su punto de vista es alarmante, pesimista, pero en su frase de despedida, referida a su proyecto vital (storytronics), demuestra la certera mirada que de él esperábamos:
this is pioneering work and to learn it you have to unlearn a great deal of what you already know and start over, you have to re-learn from a completely new angle

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

Fahrenheit

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

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

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

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

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

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

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

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


Mostrar/ocultar resto...

27 junio, 2006

Como ser mejor diseñador

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

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

26 junio, 2006

Diseño del nuevo site

Listado de artículosComo 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...

23 junio, 2006

Storytronics

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

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

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

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

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


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

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

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

  • Honestidad
  • Bondad
  • Autoridad
  • Inteligencia
  • Atractivo

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

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

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

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

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


Mostrar/ocultar resto...

21 junio, 2006

Historia de tres estudios...

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

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

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

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

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

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


Mostrar/ocultar resto...

19 junio, 2006

Sobre prototipos

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

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

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

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

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

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

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

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

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

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


Mostrar/ocultar resto...

18 junio, 2006

El videojuego como auténtico generador de historias

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

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

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

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

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

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

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


Mostrar/ocultar resto...

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

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

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

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

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

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

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

06 junio, 2006

Toshio Iwai - Arte y videojuegos se encuentran

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

05 junio, 2006

De Juegos e Historias

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

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

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

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

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

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

04 junio, 2006

Hacer un videojuego en 7 días.

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

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

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

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

Tower of Goo: uno de los juegos más descargados del site.
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.

02 junio, 2006

Ken Perlin's Law

En GTA nuestros mensajes se mandan usando una UZIRecientemente 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...