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

6 Comments:

At 20/6/06 11:13, Blogger Saül said...

Interesante temática.

Cómo dices, prototipear fórmulas jugables es importante para "asegurar el tiro": a más innovación jugable, más riesgo de fallo y, por lo tanto, más necesidad de saber cuánto antes el potencial éxito/fracaso de ese "feature". Cuando un prototipo no funciona empieza una fase muy interesante de análisis del prototipo en la que debemos recapacitar los motivos de ese fracaso e intentar encontrar una solución. ¡Es de lo más excitante del diseño!

Nosotros para el "Fallen Lords: Condemnation" utilizamos prototipos que nos permitían testear cada una de los "pilares de jugabilidad": comandos de tropas, combate, vehículos, magia, etc. No obstante nos sucedió uno de los problemas que citas en tu artículo: por tiempo muchos de estos prototipos salieron en la versión final "tal cual" y eso afectó a la calidad final del producto. Es decir, que pese a tener muy buenas ideas, no tiene un acabado óptimo. (NOTA: Opinión personal. Compañeros de Novarama, no me fustiguéis). Ahora con el "Wild Sumer!" estamos creando prototipos "cómo debe hacerse" o, al menos, como creemos que se debe hacer, teniendo la certeza de que no estarán en la versión final y tan solo son eso, prototipos temporales.

Creo que una de las cosas más importantes para esta fase de prototipeo es saber decidir qué prototipos se van a hacer exactamente. Nos podría pasar que creásemos 10 prototipos “perfectos” pero estos, entre ellos, no encajaran. Por eso creo que también es importante crear un "prototipo de combinación" en el que se testea la comunicación entre los diferentes “features”.

Ejemplo: estamos creando el Prince of Persia y ya tenemos dos prototipos, el de combate y el de agilidad que, pese a sus pequeños bugs de implementación, parecen funcionar a la perfección. Al juntarlos en una versión "guarrilla" podemos crear un prototipo de "nivel tipo" para fijar ideas de diseño de niveles. A veces esto puede llegar a modificar el propio diseño de juego básico puesto que puede suceder que dos elementos que, individualmente, funcionaban, juntos necesitan un "puente" o "pegamento" que les permita mezclarse de forma natural. Y aquí es donde entraría el “prototipo de combinación”.

Level Design: Creo que aprovechando el esfuerzo para crear estos “prototipos de combinación” también deben generarse prototipos de niveles a partir de estos "trozos" de prototipos ya creados. Sin añadir nuevos requisitos, utilizando lo que ya hay, para poder ver qué tipo de retos funcionan, cómo interconectarán entre sí, si hace falta algo más para hacer los niveles suficientemente divertidos, etc. Para visualizar el conjunto y tener una idea clara de cómo va a ser el juego definitivo. Además, este prototipeo de niveles marcará la orientación del trabajo de los level designers.

Es evidente que el nivel resultante de juntar 2 o 3 prototipos puede ser una "patata" (peta por todos lados) pero es importante, creo, para empezar a marcar la dinámica que se le quiere dar al juego acabado.

P.D.: "chapeau" por el mini-código de "mostrar/ocultar", llevaba tiempo buscando la opción en los "settings" del blogger. Me copiaré esa porción de código a partir de ahora para los posts largos :p

 
At 20/6/06 14:44, Blogger sgarces said...

No estoy seguro de que sea buena idea el tratar de integrar varios prototipos distintos para ver las interacciones entre ellos. Los chicos del Spore no lo recomiendan y mi instinto me dice que si construyes los prototipos "como debe hacerse" (o sea, son un poco guarros) no van a soportar la integracion y se van a desmoronar como un castillo de cartas. Al final funcionará el mega-prototipo, pero el trabajo será grande y no agradable (a nadie le gusta trabajar con algo que falla por todos los sitios).

Veo dos soluciones. En una, al prototipar un elemento, intentamos ver qué dependencias (o relaciones) tiene con otros elementos del diseño. Una vez somos conscientes, intentamos incorporar una versión muy simplificada de estos elementos en el prototipo. Por ejemplo, si quiero hacer un prototipo para la mecánica de taxista en GTA, no tengo que hacerme una ciudad viva y controlada por la IA: puedo colocar coches aparcados estratégicamente para dar la "sensacion" de que se están moviendo por ahí. No es lo mismo, pero nos acerca a ver cómo se relacionan ambos conceptos (modelo de taxista de cargar/descargar gente y densidad/composición del tráfico).

Otra opción sería encomendarse al divino o apoyarse en la experiencia o la intuición e ir a por el vertical slice, tras los prototipos individuales. Probablemente haga falta hacerlo en cualquier caso porque lo pida el publisher, y es el momento adecuado de ver la funcionalidad integrada, y arreglar lo que no funcione.

Es importante tener en cuenta que estamos hablando aquí de una pre-producción orientada a pequeños prototipos. Hay otras maneras de llevar la pre-producción que pueden ofrecer distintas estrategias y soluciones.

Es interesante lo que comentas sobre Level Design. Yo creo que los pequeños prototipos son más útiles para definir las mecánicas durante el diseño de juego, y que el diseño de niveles se puede beneficiar más de tener una cadena de producción pensada para favorecer la experimentación. Me explico. En Praetorians teníamos la posibilidad, usando el editor, de pintar un mapa simplemente indicando qué tipo de terreno tenía cada casilla (mapas podian tener entre 150x150 y 300x300 aproximadamente). Tras rellenar la cuadrícula, marcando casillas como bosque, mar, plano, etc, el diseñador pulsaba un botón y el mapa se exportaba a formato jugable, con gráficos de pega. Ese mapa era inmediatamente utilizable para jugar en red o incluso contra la IA (que no necesitaba anotaciones adicionales). En single player, el diseñador podía colocar enemigos y hacer un script rudimentario en muy poco tiempo también.

Este sistema fue una auténtica bendición, y nos permitió diseñar en tiempo record los mapas de multiplayer (especialmente), ahorrando a la vez esfuerzos innecesarios en el departamento de gráficos. La clave está en soportar lo que a veces se llama un "fast path" para pasar de una idea de un nivel a algo jugable y feo en muy poco tiempo. Que duda cabe que si estás haciendo un juego 3D moderno puede ser más complicado, técnicamente. Pero a día de hoy existen editores sencillos (Sketchup) que puede usar cualquier diseñador y se pueden incorporar en la cadena de producción, y también algoritmos para explorar un mapa y generar automáticamente información de IA. Yo creo que las ventajas que se obtienen en calidad final, al favorecer la experimentación y las iteraciones rápidas, más que justifican el esfuerzo. Pero esta es otra historia.

 
At 20/6/06 19:18, Blogger Saül said...

Tienes razón, los riesgos de mezclar dos prototipos en una sola aplicación quizás sea demasiado alto.

Quizás si que lo que yo llamo "prototipo de combinación" debería ser más bien una simulación independiente de las posibles combinaciones/interacciones entre los "resultados" de cada uno de los prototipos. Para hacerlo "barato" (clave) debería emularse a groso modo los posibles resultados que pueda dar cada uno de los mini-prototipos. O sea: lo que apuntas con el ejemplo del mini-juego de hacer de "taxista" en el GTA3.

Pero como en mi empresa la fase de pre-producción no existe, debemos producir el juego a la vez que prototipeamos nuevos elementos y tratamos de combinarlos con los anteriores/previstos/etc. Es decir, que estos prototipos no pueden ser una aplicación “tipo flash” de una única core con la que podemos testear si eso funciona o no. Lo que hacemos es incorporar una de estas core mechanics en “fase prototipo” al motor que ya tenemos, y así lo testeamos con el resto a la vez que decidimos su idoneidad o no. A veces puede parecer una pérdua de tiempo, pero realmente nosotros ese tiempo extra para dedicarle a un “prototipo puro” no lo tenemos.

Como ejemplo más claro, estan las demos que debemos desarrollar para las ferias, tipo E3, en las que debemos enseñar “todo lo que tenemos” prototipos se pueden ver conjuntamente para que el público (y nuestro publisher) puedan hacerse una mayor idea del conjunto. Esto nos ha ayudado muchas veces a ver errores de integración entre "core mechanics" que de otra forma (ni con aproximaciones) hubiéramos sido capaces de detectar. Y la desventaja es clara: se pierde mucho tiempo en juntar prototipos.

Sobre el prototipeo del Level Design, estoy totalmente de acuerdo con lo que dices. Es exactamente lo que comentaba en mi anterior post. Das al level designer TODAS las herramientas y él decide, junto al respectivo “lead”, cómo se pueden utilizar, cómo explotarlas, etc. Es una fase realmente excitante para cualquiera que quiera dedicarse al diseño ya que el level designer puede generar cualquier idea que se le pase por la cabeza (dentro de los límites que le marque el lead, evidentemente). Son los que yo llamo "prototipos de level design". Nosotros lo hicimos así en el Fallen Lords, juego de acción, en el que teníamos un editor de niveles con el que básicamente el diseñador colocaba triggers (volúmenes), enemigos, geometría, etc. y después toda la lógica funcionaba a través de un LUA simplificado (orientado a nuestra experiencia/funcionalidades/etc). La ventaja de este método es que tienes libertad para hacer "lo que quieras", todos los prototipos que te dé la gana. Además, en novarama coincide que cada vez que se integra algún "core" terminado al motor, los level designers ya pueden trastearlo para hacer sus pruebas y ver qué cosas funcionan y cuales no. Aunque estas cores aún estén muy “verdes” y den algún que otro pete.

 
At 20/6/06 23:12, Blogger sgarces said...

Es interesante lo que comentas de no tener fase de pre-producción y producir el juego mientras se va definiendo el diseño. Es como tradicionalmente se han hecho las cosas en Pyro (con bastantes problemas) y ahora hay una corriente muy fuerte para cambiarlo, y pasar a un método de "cascada" mucho más puro: se hace el diseño en papel, y luego se implementa el código. Estoy preparando un post para reflexionar sobre esto. Manteneos atentos :-)

Sobre el tema de diseño de niveles, me gustaría que estuviera aquí algún programador "hardcore" para hacer de abogado del diablo y decir que somos unos paquetes y queremos hacerles la vida imposible a los programadores, pidiendoles cosas imposibles. Que aunque yo sea programador, soy un blando ;-) y no es divertido discutir si estamos de acuerdo...

 
At 21/6/06 08:49, Blogger Saül said...

Hombre, si quieres guerra podemos crear un par de pseudónimos falsos y meter un poco de caña :D

 
At 24/6/06 01:28, Anonymous Jare said...

Es que escribis unos ladrillotes de mucho cuidado, para cuando el tipico lector internetero con Sindrome de Déficit de la Atencion llega al final ya no se acuerda de lo que

;)

Ahroa mismo tengo los plomos demasiado fundidos como para aportar nada, pero la discusion es muy interesante. Los prototipos son los grandes desconocidos, y estoy convencido de que nadie nace sabiendo hacerlos; aunque algunos perfiles de programador (como el "enreda" que menciona Sergio) se prestan más a ello, la labor de prototipar a nivel de equipo es muuucho más complicada.

Esperemos saber hacerlo bien algun dia. :)

 

Publicar un comentario en la entrada

Links to this post:

Crear un enlace

<< Home