H. Hernan Moraldo - personal archive
home about faq contact website

Justificación del Game Design

Dated: Octubre 2002

El presente artículo fue escrito en formato de mail en 2002, para expresar en una lista de desarrolladores algunas ideas sobre game design. Lo republico sin modificaciones desde la versión de mayo 2003.



Justificación del game design

por H. Hernán Moraldo (octubre 2002)

Si se me permite, intentaré un breve análisis sobre la importancia del game design en el desarrollo de videojuegos (motivado por algunos de los mensajes en la thread 'Game design y Re: En busqueda de "otra rama de ADVA').

La visión natural del game design en estos días, que seguramente habremos compartido inintencionalmente todos los que participamos de esta lista en nuestros inicios, es la siguiente: game design es lo que obtenemos después de programar un juego. Es típico: un programador se sienta a programar su próximo juego, que supone será de lucha y será una ardua exposición del comportamiento de la sangre en el espacio, y después de un tiempo descubre que lo que ha estado programando funcionaría de una manera interesante si se le agregara un determinado comportamiento a sus contendientes; más tarde, en ensoñaciones diurnas, nuestro amigo programador descubre que sería fácil para él hacer que el indicador de vida de los luchadores sea en realidad una representación de su actual estado anímico; de igual manera, termina construyendo un juego a partir de las ideas que surgen durante su implementación.

Ya llega la justificación de mi frase "game design es lo que obtenemos después de programar un juego" para este caso: una vez que este programador ha terminado su juego, puede dar una amplia explicación de cual es el game concept de su juego ("mi juego", dice, "es acerca de dos tipos que pelean con espadas, uno gana cuando el otro cae en la más profunda depresión, cada vez que uno de ellos golpea al otro con su espada, éste se deprime un poco más, etcétera"), e incluso fundamentar sus decisiones de diseño y contar anécdotas sobre las mismas ("estaba a punto de usar postes de luz controlados por dinosaurios, pero finalmente preferí usar espadas y una ambientación medieval realista"). El game design del juego de nuestro amigo programador será, sin duda, lo que éste ha obtenido a partir de su trabajo en la implementación del mismo.

Podemos llamar a esta metodología "zen game development", parafraseando sobre "zen navigation", que es, según una definición ajena a la mía (y original de Joerg Heitkoetter, si no me equivoco):

"A methodology with tremendous propensity to get lost during a hike from A to B. Zen Navigation simply consists in finding something that looks as if it knew where it is going to and follow it. The results are more often surprising than successful, but it's usually being worth for the sake of the few occasions when it is both."

Análogamente, "zen game development" sería el desarrollo del concepto de un videojuego a través de su implementación, de una manera mayormente casual (la mayor parte de las ideas originales que surgen en el desarrollo de juegos con esta metodología aparecen a partir de efectos inintencionales en las implementaciones intermedias del mismo, a veces incluso de bugs)... de nuevo de manera análoga a la "zen navigation", nuestro "zen game development" tiene un obvio problema: el destino (el game design definitivo) es incierto y por tanto está mayormente fuera de control, el game design _es_ lo que surge, y para cuando ya ha surgido, generalmente es tarde para hacer cambios importantes en el mismo.

Ahora que todos hablamos el mismo idioma, puedo repetir que esta metodología es la más natural y obvia (fundamentación: se utilizó profesionalmente durante al menos los primeros 20 años de la historia del desarrollo [1961-1981], y además es la típica que usan los beginning game developers para comenzar, al menos en equipos unipersonales). Además, cuando se supone que no se está utilizando ninguna metodología de diseño para juegos, en realidad ésta es la que se está utilizando, como por defecto.

Muchas veces, el uso de esta metodología de diseño (que no estoy marcando como mala ni nada por el estilo, de hecho creo que es una metodología como cualquier otra, que debe ser aplicada con cuidado cuando sea adecuada) surge a partir de una negación del diseño del juego: se utiliza una metodología que determine el diseño del mismo a partir de su implementación, porque se considera que el diseño _debe_ surgir a partir de la implementación del juego. Un razonamiento sencillo puede ser: si el juego no existe sin su correspondiente código, el juego _es_ el código, y para hacerlo debe codeárselo, ni más ni menos. El diseño es inherente al código y surgirá de él.

Es un punto de vista. Si le damos un giro de 180 grados obtenemos el punto de vista contrario, que creo que es mucho más interesante y apropiada para los objetivos típicos de los desarrolladores.

El juego _es_ el game concept. Redoblamos la apuesta y afirmamos que un juego puede existir sin su correspondiente implementación. Un juego, el juego del Pac-Man por ejemplo, es la idea base del mismo desde un nivel más o menos alto de abstracción, y al mismo corresponde una gran variedad de posibles instanciaciones (implementaciones). El que crea el juego es el game designer, y el programador es meramente quien lo implementa (recordemos que simplemente estoy trabajando en un punto de vista que me parece interesante recorrer por las conclusiones y metodologías a las que conduce). Si regulamos el nivel de abstracción para que sea medianamente alto, podemos afirmar que el PacMan del ochenta y pico es una implementación del mismo juego que el modo classic de juego del PacMan de la Playstation, y del PacMan de Family. En un nivel más alto de abstracción podemos decir que Quake 1 y Quake 2 son implementaciones del mismo juego (o que son juegos equivalentes en cuanto a su game design). Siendo asquerosamente violentos, podemos afirmar que el Quake 2 _es_ el Doom (en el sentido de que equivale en cuanto a game concept), sólo en un nivel más alto podemos afirmar que el Wolfestein es el Q3 Arena (digo esto porque creo que las emociones en juego son muy diferentes en cuanto se agrega el factor social). En un nivel de abstracción suficientemente alto, todos los juegos son el mismo juego, lo cual es una clara muestra de que un nivel de abstracción mayor no es necesariamente más adecuado para nuestros propósitos.

Desde este punto de vista, obtenemos algunas ideas interesantes. En principio, una evidente justificación de por qué la metodología de zen game design y development prácticamente equivale a la construcción de juegos de manera casual. Si construimos un concepto abstracto a partir de su implementación, y sólo tenemos un conocimiento acabado del concepto abstracto cuando la implementación está lista, y para entonces el concepto abstracto resulta prácticamente inmodificable por el extraordinario trabajo de implementación requerido para hacer las modificaciones más importantes, quiere decir que estamos construyendo la abstracción (la fase más creativa del desarrollo) a partir de la implementación (la fase menos creativa del desarrollo), lo cual muy probablemente nos lleve a abstracciones menos creativas que las construídas con el proceso inverso (en el que la creatividad es intencional). Primer intento de conclusión: zen game development es un proceso que tiende a conducir a game concepts poco creativos e innovadores, y cuando un concepto creativo aparece a partir del zen game concept, éste suele ser obtenido de manera casual y arbitraria (hablamos de creatividad exclusivamente a nivel game concept).

Segundo intento de conclusión: un clon del Quake _es_ el Quake, _es_ el Doom, _es_ el Wolfestein, a cierto nivel de abstracción incluso es el Tetris :) Un game developer que trabaja en un FPS típico no es más que un nuevo implementador de un concepto que ya tiene diez años. Para hacer el desarrollo de videojuegos en su máxima expresión _tenemos_ que trabajar en el game design, tenemos que crear nuevos game concepts (o significativamente modificar viejos game concepts), de otra manera una gran parte de la expresión artística expuesta en el desarrollo no es más ni menos que ajena.

Usando zen game development de manera inintencional lo más probable es que logremos un mínimo grado de innovación, lo cual nos convertirá en nuevos implementators de viejos conceptos. Negar el game design no nos va a llevar más lejos que eso (salvo como resultado de la más pura casualidad: si caminando a la deriva llegás a un lado interesante, lo hacés sin mayor mérito que la buena suerte), al menos una persona en cada equipo de desarrollo interesado en llevar al desarrollo de videojuegos a su máxima expresión (a crearlos en todo sentido) debe ponerse en el lugar del game designer y hacer un esfuerzo consciente por llegar a game concepts que sean adecuados a sus objetivos. En los equipos unipersonales, está en el programador elegir si quiere ser un nuevo implementador (dejando sus decisiones de diseño limitadas a los medios y no a los resultados), o si quiere dedicarse a la creación de juegos. Si implementamos, sólo hacemos programación de videojuegos (frase que lamentablemente se usa mayormente como sinónimo de desarrollador de videojuegos) y no desarrollo, creación.

Lo dije en un mail anterior: el game design está en las cabezas de todos los desarrolladores, pero mayormente a modo inconsciente. Todos hacemos zen game design cuando no pensamos en el game design... ya que vamos a hacer game design mejor tomémonos la molestia de pensar en el asunto y poner nuestro máximo esfuerzo en lo que, en definitiva, es un juego: no dejemos que los árboles del código nos impidan ver el bosque del game design. Después no importa tanto qué metodología de game design se utilice, hasta la cómoda estrategia zen que menciono en este mail puede ser útil.

Escribo esto en un momento en que parece que todo el mundo quiere hacer el próximo nuevo Quake... yo desafío a quien quiera escucharme a que haga el próximo Tetris, Icy Tower o Sims, a que intente el próximo nuevo game concept. Es un desafío que yo estoy siguiendo para mi propio Randomedia, aunque sé que no es una garantía de nada (en realidad en cierto sentido es casi el beso de la muerte).

Bueno, estas son las cosas que me pasan cuando cada tanto se me da por escribir un mail chiquitito que después resulta no ser tal (sí, empecé este mail diciendo "intentaré un breve análisis"). En respuesta, espero sesudas reflexiones, acotaciones, comentarios, críticas, palazos, y sobre todo, aportes para esta discusión por definición polémica, que creo que es de vital importancia para nuestra pequeña pero creciente industria (que parece que resultó no ser la segunda de USA).



In categories: All Spanish Articles GameStudies GameDevelopment GameDesign 2002




Copyright 2000-2008 by Horacio Hernán Moraldo
All rights reserved