Diseñando Assassin's Creed II

Podrías pensar que los asesinatos en si mismos serían uno de los pilares de la jugabilidad, pero no es así. Es simplemente la culminación de usar a la vez el sistema de combate, la navegación y la infiltración social en harmonía. Es la recompensa por tu trabajo duro.

"Para nosotros, en ACII el asesinato es el resultado del jugador usando el núcleo jugable en los confines de la fantasía", clarifica Plourde.

"Así que básicamente tengo un objetivo que matar. Me retará en el núcleo jugable, que es la navegación, la lucha y la infiltración social para alcanzar un objetivo y una vez lo encuentre, pulsar X y matarlo. Y así la dirección de diseño era no tener un reto een ejecutarlo y realmente mostrar que la vida es barata en Assassin's Creed".

El proceso de asesinato en el juego también se cambió, mejoró y refinó con respecto a la primera entrega debido a la frustración de parte de la audiencia.

"Es algo que mucha gente nos comentó de AC1, que a veces era difícil cometer un asesinato", reconoce Plourde. "Se supone que eres un maestro de asesinos, se supone que no ha de ser difícil. Ahora el asesinato se percibe como una recompensa para el jugador".

Assassin's Creed II es realmente una producción mastodóntica, con un equipo de casi 300 personas que trabajaban en distintos continentes: Ubisoft Montreal se encargaba del núcleo del juego, mientras el el estudio de Singapur se encargaba de las misiones lineales y Ubisoft Annecy (en Francia) implementaba la Villa.

Esto suponía un desafío logístico único. Como diseñador principal, Patrick Plourde reconoce que no puede recordar ni la mitad de los nombres de la gente que contribuyó en el juego, y que como muchos de ellos trabajaban en otros países no podía ir a su mesa a contarles las ideas que tenía.

"Como diseñador tienes que estar seguro de lo que haces. Debes tener el coraje para decir 'este es el juego que estamos haciendo', entenderlo y basar las decisiones en ello. ¿Cómo puedes comunicarte de forma eficiente con tu equipo? Con un buen proceso de documentación".

Plourde señala que una documentación fuerte tiene tres grandes ventajas. La primera es que al tener la ideas es papel estás forzado a pensarlas en tu cabeza y eso hace que identificar fallos sea mucho más fácil. En segundo lugar, el mero hecho de documentarlo todo hace que no olvides ninguna idea. Y finalmente reduce el número de preguntas innecesarias por parte de otras secciones del equipo.

"Al decir que limita las preguntas no quiero dar a entender que no quiero comentarios o feedback de la gente del equipo. Todo el mundo está invitado a mi mesa para traer sugerencias y escucharé todos los comentarios, porque no creo que haya ninguna idea mala", añade Plourde.

"Lo que quiero decir es que no quiero que un programador gaste media hora, quince minutos o cinco segundos en una pregunta que se puede responder con un sí o un no. El programador puede preguntar '¿el diseñador quiere esto azul o rojo?', pero yo quiero que tengan algún tipo de guía, que puedan decidirlo al momento y centrarse en el trabajo en el que realmente es bueno - programar código. Eso es lo que le gusta, y así es como puede maximizar el esfuerzo de todos los miembros de tu equipo".

Pero el elemento final del proceso de documentación es el más crucial en un proyecto en el que casi cada característica que produces debe estar bien hecha a la primera.

"Cuesta menos fallar en la documentación que en la producción. Cuando revisamos los documentos de diseño del juego sabemos que es mejor eso que revisar tres o cuatro semanas de trabajo de un programador".

Tampoco cree en las biblias de diseño de juegos, y piensa que la documentar una explicación de los conceptos o las ideas sobre la jugabilidad no ayudan al programador en su trabajo diario escribiendo código. Al escribir la documentación de diseño, Plourde habló con el equipo para ver que querían de ella, y lo que sería más útil.

"Hicimos los documentos de diseño con la ayuda de los programadores, les preguntamos que era lo que necesitaban que les diésemos".

"Separamos cada característica: lo que ocurre en el bucle jugable, el control, la reacción de la IA, el sonido, etc. y para cada una de esas células escribíamos líneas y cada una de ellas necesitaba tener la respuesta a una pregunta - ¿funciona? sí o no".

Muchas de las variables del juego se destacan en el documentos con corchetes. Estos contienen los valores recomendables para una gran variedad de aspectos de la jugabilidad - por ejemplo, cuanto se tarda en recoger objetos de un cadáver.

"Todo lo que está entre corchetes es un valor que queremos tener disponible en datos, así que esos números no están codificados".

"Estas variables están disponibles en las mesas de los diseñadores del juego para que puedan modificarlas y probarlas en el juego. Es realmente útil en los últimos estadios de la producción, en la que quieres que los programadores depuren el juego y que el diseñador se limite a pulir. Así que cuando digo que no teníamos tiempo para hacer revisiones, sí teníamos tiempo para pulir la mecánica usando datos variables, y también se eliminan debates estériles".

En un equipo apasionado con su trabajo, las discusiones sobre minucias pueden tener un impacto importante en el tiempo de producción. El sistema de variables permite que el equipo juegue en vez de debatir.

"Lo divertido no está en el documento, es lo que creas en el juego, así que cuando usas corchetes pruebas un valor en el juego. Y además ayuda a comunicarle al programador lo que para el diseñador es importante en esa característica".

El equipo de ACII fue metódico en su trabajo con los documentos de diseño, con un escrupuloso mantenimiento hasta los últimos días de producción.

"Ahora mismo puedes mirar la base de datos de documentos de ACII y verás que es lo que lanzamos al mercado. Es importante porque si la gente deja de crear en la documentación, entonces ésta resulta inútil", asegura Plourde.

"El programado se hará una pregunta: '¿es esto realmente lo que quiere el diseñador? ¿ha cambiado de idea recientemente?' No queremos que la gente se haga estas preguntas sobre las cosas que se supone deben hacer. Simplemente queremos que lo hagan lo mejor posible".