Desarrollando para el diseño

Posted in Latest Developments on 13 de Marzo de 2015

By Sam Stoddard

Sam Stoddard came to Wizards of the Coast as an intern in May 2012. He is currently a game designer working on final design and development for Magic: The Gathering.

El año pasado, pedí a Shawn Main que escribiese un artículo para Latest Developments y nos contase qué se sentía al ser el representante de diseño en un equipo de desarrollo. Pues bien, esa práctica es recíproca: los equipos de diseño también cuentan con un representante del departamento de desarrollo. Hacer que nuestros trabajadores polinicen otros equipos con sus virtudes es uno de los motivos por los que logramos crear expansiones de calidad de forma constante. En el caso de Dragones de Tarkir, yo fui el representante de desarrollo en el equipo de diseño y me encargué de trasladar las ideas de su departamento al nuestro.

Uno de los motivos por los que queremos que haya gente de todos los departamentos trabajando en cada colección es lograr que a ningún equipo le pille por sorpresa lo que se está haciendo en todas las colecciones. Aunque sería relativamente fácil comprobar estas cosas en la base de datos del Multiverso, eso implicaría detenerse a analizar las colecciones. Entre los departamentos de diseño y desarrollo, manejamos unas seis colecciones en etapas distintas del proceso de creación, así que es difícil tener el ojo puesto en todo.

Ojo de las Grayas | Ilustración de Daniel Ljunggren

Al equipo de desarrollo le interesa que uno de sus miembros informe de los planes que hay para futuras colecciones. De ese modo, podemos apoyarlas con cartas que saldrán antes y, lo que es más importante, no entorpeceremos accidentalmente el progreso de esas colecciones por haber creado cartas que las perjudicarán cuando lleguen a nuestro departamento. De manera similar, el representante de diseño colabora con nosotros para generar muchas cartas nuevas y asegurarse de que la labor de desarrollo no entre en conflicto con los planes del equipo de diseño.

Desarrollando una mentalidad de diseñador

La tarea del desarrollador en un equipo de diseño no es decir a los demás qué deben hacer y qué no, ni intentar cargarse todo lo que parezca inviable. Su cometido es actuar como diseñador y probar cosas bastante estrafalarias, tratando de mantener bajo control las más disparatadas, o de dar con la forma de que esas mecánicas puedan ponerse en cartas que llegarían a usarse en Construido. Hay mecánicas que pueden parecer muy divertidas e interesantes, pero si desarrollo no puede equilibrarlas, nos costará mucho crear cartas que la gente quiera conseguir. Por ejemplo, no es que desarrollo no pueda hacer cartas con tormenta que no estén rotas, sino que habría pocas que fuesen equilibradas y también interesantes.

Una de las cosas más difíciles para mí al trabajar en un equipo de diseño fue tratar de ignorar mis ansias de ajustarlo todo. Parte del trabajo de diseño consiste en probar cosas nuevas y fracasar inevitablemente. A menudo, yo quería saltarme las sesiones de pruebas y pasar directamente a "probar algo distinto". En realidad, fracasar forma parte del proceso, y descubrir qué partes de las mecánicas desechadas resultan divertidas es uno de los métodos para elaborar mecánicas atractivas. En muchas sesiones de pruebas, no cosecharemos mecánicas ni cartas viables, pero el equipo estará un paso más cerca de averiguar qué formas hay de expresar lo que cada colección pretende expresar.

Las cosas, por el buen camino

Aunque es importante no pasar mucho tiempo tratando de decirles a los diseñadores qué sobrevivirá al proceso de desarrollo y qué no, la labor del desarrollador es mantener las cosas por el buen camino y asegurarse de que las mecánicas y cartas creadas por el equipo de diseño sean manejables más adelante.

Por ejemplo, cuando al equipo de diseño se le ocurrió hacer cartas de dos caras, Tom LaPille era el representante de desarrollo. Aunque aquellas cartas iban a ser difíciles de ajustar, en realidad no supondrían un problema gravísimo para desarrollo. El reto lo tendrían otros departamentos del proceso, como el creativo, que iba a tener que encargar ilustraciones adicionales, y el de composición, que se encarga de maquetar las cartas y hacer que las impriman. Tom confiaba en que podríamos sacar adelante la mecánica y se esforzó al máximo para que las cartas fuesen divertidas y lo bastante buenas como para que otros empleados de I+D se entusiasmasen con ellas.

Una de las mecánicas que no nos sirvieron para Dragones de Tarkir fue la "auramorfosis". En los inicios del bloque de Tarkir, se planteó utilizar la metamorfosis con criaturas en Kans, con tierras en Destino y con cartas que no fuesen de criatura en Dragones. La primera versión que probamos en Dragones fue la auramorfosis, para generar cierta sinergia entre bloques gracias a la temática de encantamientos y auras de Theros.

Como representante de desarrollo, enseguida señalé varios problemas que detecté en aquel plan. No es que equilibrar las cartas fuese a resultar difícil, sino que el planteamiento tenía problemas mayores que no podrían resolverse fácilmente. Como las cartas con metamorfosis de Destino reescrito (por aquel entonces) no iban a ser criaturas, en el formato Limitado de Dragones era imposible que las cartas boca abajo se convirtiesen en criaturas más grandes. Es decir, que podías bloquearlas tranquilamente con una 2/3, porque solo la perderías si inflaban las cartas boca abajo con un hechizo, y esto quitaba mucha gracia a la metamorfosis.

Intentamos resolver el problema haciendo auras con efectos extraños, como que encantasen al oponente y fuese más barato darles la vuelta si no las bloqueasen, o auras negativas que se anexasen gratis a la criatura bloqueadora al darles la vuelta. Aun así, vimos que aquel plan no llegaría a buen puerto y decidimos explorar otras variantes para las criaturas con metamorfosis.

Si no hubiese habido un desarrollador en el equipo, los diseñadores habrían llegado a la misma conclusión tarde o temprano, pero el desarrollador tiene que anticiparse a estos problemas y orientar al equipo de diseño hacia conceptos con los que nuestro departamento pueda elaborar cartas divertidas y relevantes. Cuanto más tiempo pase el equipo de diseño trabajando con mecánicas viables, más tiempo tendrá para crear cartas que seguirán en la versión final, y esto hace que las colecciones sean mejores que cuando desarrollo crea demasiadas cartas.

Cuestión de costes

Uno de nuestros objetivos es que las sesiones de pruebas de diseño tengan un nivel de eficacia bastante plano. Eso no significa que todo deba ser exactamente igual de eficaz, pero procuramos que todas las estrategias y mecánicas de la colección resulten viables, para que las partidas de Limitado no sean en plan "bueno, los hechizos de anulación y las criaturas voladoras siguen siendo lo mejor". Por ejemplo, queremos que los hechizos de destrucción sean lo bastante buenos como para impedir que una criatura con un aura domine la mesa, pero no tanto como para que la gente se prive de utilizar auras. Básicamente, si la mayoría de los logros de diseño radica en la interacción entre cartas y mecánicas, podemos detectar enseguida si realmente son divertidas o no. Mientras no se añadan cartas descompensadas, no intervendremos, y si se hace, merece la pena dedicar un tiempo a pensar cómo podríamos volverlas viables durante el desarrollo.

Capataz demoníaco | Ilustración de Chris Rahn

En las reuniones de diseño, el desarrollador debe sugerir costes de maná y valores de fuerza y resistencia para las cartas. Más tarde, también podemos modificarlas al momento, pero es muy molesto pedir a todos que sumen un maná a un coste en plena sesión de pruebas. Por ese motivo, el desarrollador del equipo de diseño tiene que repasar el expediente con cierta frecuencia y ajustar los costes y valores para que las pruebas vayan lo mejor posible.

La mayoría de los diseñadores son razonables a la hora de asignar costes de maná a gran parte de las cartas. ¿Que tenemos una infrecuente 4/4 con volar y vínculo vital? Me sorprendería ver a un diseñador que no le pusiese un coste de seis manás. Ahora bien, muchas de las mecánicas nuevas son bastante más difíciles de evaluar; por eso, es bueno tener cerca a alguien con más experiencia en ajustar niveles de eficacia, para que haga los primeros cálculos.

Contar con un desarrollador en diseño ayuda a que, en teoría, ya haya cartas viables cuando el diseño concluye. El expediente no tiene por qué estar terminado, pero sería una lástima que desarrollo recibiese cartas y mecánicas que solo funcionan porque sus costes son demasiado bajos. Es fácil sentir inclinación por las cosas que son más eficaces que el resto. Si haces que una de las mecánicas de una colección sea superior a las demás, la gente te dirá cosas como "esta mecánica era muy divertida, pero las otras... ni fu ni fa". Es una cuestión natural: las cosas que funcionan son más atractivas; las que no, resultan frustrantes. Por tanto, el desarrollador del equipo de diseño debe procurar que todo esté a un nivel parejo, para que podamos ver qué resultará divertido cuando las cosas estén equilibradas.

Por otro lado, es importante que el representante de desarrollo se asegure de que la colección funcionará en el contexto del mundo real, y no solo en el marco de la colección. Cualquier mecánica puede ser viable si construyes toda la colección en base a ella, pero en desarrollo debemos procurar que las cosas no funcionen solo en Limitado, sino también en Estándar. Las mecánicas como las auras pueden servir en Limitado si haces que los hechizos de anulación sean muy malos, pero salvo que el plan sea cargárselos también en Estándar, las auras y demás no van a tener mucho impacto en el mundo real. Cuanto más oriente el representante de desarrollo hacia ideas que luego no haya que rehacer, más pulida estará la colección final y más se respetará la visión del equipo de diseño.

Eso es todo por esta semana. El viernes que viene, volveré para traeros la edición de Dragones de Tarkir de los M Files.

Hasta la próxima,

Sam (@samstod)

Latest Latest Developments Articles

LATEST DEVELOPMENTS

29 de Abril de 2016

Días del futuro futuro: Sombras sobre Innistrad by, Sam Stoddard

Hola y bienvenidos a una nueva edición de Días del futuro futuro, la sección de Latest Developments en la que comparto con vosotros algunas de las listas de mazos de la FFL. Hoy es el tur...

Learn More

LATEST DEVELOPMENTS

22 de Abril de 2016

Preguntas frecuentes sobre la FFL by, Sam Stoddard

Cuando publicamos nuevas colecciones, me gusta compartir con vosotros las listas de mazos de nuestra Future Future League, que a menudo generan muchas dudas. "¿Por qué usabais tal carta? ...

Learn More

Artículos

Artículos

Latest Developments Archive

¿Quieres más? Explora los archivos y sumérgete en miles de artículos sobre Magic escritos por tus autores favoritos.

See All