Diseñando Assassin's Creed II

Al final resultó que los jugadores casuales no se adaptaban al sistema de navegación, mientras que los jugadores que el equipo percibía como más 'hardcore' maximizaban su potencial, sacándole mayor provecho y divirtiéndose más con la misión.

"Se decidió no cambiar la estructura. ¿Por qué? Porque los jugadores hardcore no parecían tener problemas, así que técnicamente funcionaba correctamente".

"En segundo lugar, la primera ciudad que los jugadores verían en el juego - Florencia - tenía edificios más bajos. Una vez los jugadores llegaban a Venecia, la última ciudad del juego, ya se habrían acostumbrado al free-running. Esa fue nuestra apuesta... que los jugadores casuales que llegasen a Venecia se convertirían en lo que llamamos un jugador hardcore. Pensarían que la navegación era lo suficientemente fluida".

Y la fluidez era capital, llevando al punto más crucial en la mejora del sistema de parkour. Edificios más altos implica que serían más largos de escalar, y el feedback de las pruebas decía que no parecía correcto. En el Assassin's Creed original, los jugadores escalaban y entonces volvían a un punto neutral antes de que se les permitiese escalar otra vez. En ACII esto se mejoró eliminando el punto neutro, facilitando lo que el equipo llama "escalada fuerte".

"El personaje alcanzaría el tejado el doble de rápido que en AC1", dice Plourde.

"Así que si tienes un edificio de cuatro pisos, tardarás lo mismo en llegar al tejado que en AC1. También cambiamos los entornos para que cada ruta de free-running condujese a los tejados. Los jugadores empezarían a hacer free-running y el diseñador los guiaría a los tejados y con ello... ¡a la felicidad!

Un reto más difícil surgido de las pruebas de juego fue el concepto de mezclarse entre las multitudes. Resumiento, aunque el diseño parecía estar bien, los jugadores no pillaban la idea y por lo tanto no lo usaban.

"El sistema funcionaba, lo probaba en la oficina y funcionaba para nosotros, entendíamos la matriz, pero la gente no lo comprendía", asegura Plourde con frustración.

"Era realmente simple - debías pulsar el botón B cuando estabas al lado de una multitud y entonces te mezclabas - caminabas automáticamente dentro del grupo. La gente no lo comprendía... teníamos que encontrar una solución. Cuando la gente dice que los testers irán a tu empresa y dirán cosas bonitas del juego porque eres su desarrollador, ¡no es el caso! Mezclarse entre la gente era algo que los jugadores puntuaban muy mal".

La idea fue hacer el sistema de mezcla totalmente automático, activándose solo según tu proximidad con la multitud. Pero los programadores no veían con buenos ojos reescribir un sistema tan importante del juego. La solución resultó ser sorprendentemente simple.

"Me senté en mi mesa pensando en por qué los jugadores no mantenían simplemente pulsado el botón B. ¡Era así de simple!", recuerda Plourde.

"Así que dejé pulsado el botón B. Es automático y funciona... quizás tardamos dos horas en programar un pequeño truco para que cuando caminabas se apretase el botón B automáticamente. Y tan pronto como lo hicimos las impresiones de los jugadores sobre el sistema de mezcla cambiaron de algo malo a algo bueno, así que acabamos contentos. Y no solo eso, sino que en cada misión que requería que el jugador se ocultase la dificultad bajó, incrementando el factor de diversión".

El último ejemplo de Plourde sobre la importancia de las pruebas de juego no tenía un final feliz. El feedback sobre el sistema de combate - uno de los pilares jugables - mostraban que el jugador pensaba que el proceso no tenía suficiente variedad.

"Sabemos - porque hicimos un seguimiento de lo que hacía - que no usó todos los movimientos", explica Plourde.

"Así que comparamos sus resultados con los de uno de los diseñadores que conocían el sistema. Realmente ves una diferencia en el uso y es así como percibe el sistema de combate. El problema es que no encontramos una solución y eso se ve en los análisis y las opiniones. Si hay una cosa que la gente ha dicho es que la lucha no funciona del todo bien y ahí es donde fallamos. Sólo quería dar ese ejemplo para decir que cuando estás haciendo las pruebas de juego a veces puedes analizar los problemas pero no siempre encontrarás una solución. Pero al menos esta vez tenemos una secuela (ambientada en Roma) donde podremos solucionarlo".

Así que 300 desarrolladores, 230 características y sin tiempo para hacer una revisión. Ahora sabes cómo lo hizo el equipo, y presumiblemente esos métodos se aplicarán en la secuela que saldrá a finales de año.

Para acabar su presentación de la GDC, Patrick Plourde habla sobre las lecciones aprendidas durante los años que ha estado creando los juegos de la saga Assassin's Creed.

"Al hacer juegos de gran presupuesto los fallos pueden tener un coste extremo. Si empieza a descarrilar una producción con 300 personas el desastre se puede producir muy rápido".

"También baja la calidad si la gente trabaja en cosas que al final no se incluirán. Crea trabajo innecesario, baja la moral. Ve a un programador que ha trabajado realmente duro en una característica durante dos meses, elimínala, y entonces dile que haga otra cosa. Mira cómo reacciona. Eso puede conducir a un montón de fallos".

"Los diseñadores pueden reducir el riesgo mirando lo que hay en el núcleo del juego y construyéndolo todo alrededor de ello, dándole al equipo de arte una documentación completa que encaje con sus necesidades de producción y maximizando las pruebas de juego para validar decisiones y hacerlas con fundamento. Y al final, ¡así creamos un proceso a prueba de fallos!".