Designer Diary 15 – Vision Control

En los últimos meses, pasé mucho tiempo hablando sobre diseño, pero no he entrado en cómo organizamos nuestros cronogramas de desarrollo. Con el lanzamiento del kit público de print-and-play, parecía un buen momento para hablar sobre cómo funciona el desarrollo del juego. Al menos, para decir algunas cosas sobre cómo hacemos juegos aquí.

Diseño vs. Desarrollo

Debo decir de inmediato que no veo mucha diferencia práctica entre «diseño» y «desarrollo» en términos de los tipos reales de trabajo que se esperan tanto de un diseñador como de un desarrollador. Podría arrojarte todo tipo de tópicos, pero básicamente son parte del mismo proceso. Para hacer un juego necesitas diseñar un sistema y luego debes seguir iterando y ajustando esos sistemas hasta que capture la tensión que quieras aportar al juego. El diseño requiere desarrollo y el desarrollo requiere diseño.

A menudo escuché que algunas personas sugieren que el diseñador establece el rumbo general del juego y desarrolla algunos de sus sistemas principales. Un desarrollador itera dentro del marco ofrecido por el diseñador para realizar el juego. Cuando se trata de títulos de trabajo, creo que es una distinción justa, pero aún no dice mucho sobre la diferencia entre el trabajo de desarrollo y el trabajo de diseño. Incluso en ese ejemplo, tanto el diseñador como el desarrollador están esencialmente haciendo el trabajo de diseño iterativo.

Quería decir todo esto por adelantado porque, por el bien de esta pieza, voy a usar ambas palabras bastante y quería asegurarme de que todos entendieran que los muchos tipos de trabajo detrás de la creación de un juego sangrar el uno al otro. Por esa razón, voy a tratar de centrarme en los trabajos y procesos por los que pasamos un juego antes de que se imprima. Para aquellos que desean una distinción inteligente entre diseñar y desarrollar, lo siento.

Nuestro proceso

Muy bien, comencemos. En Leder cada juego tiene un «Período de diseño» donde se incuba un juego. Esto podría llevar varias semanas, meses o años. Durante este tiempo, una sola persona (a la que a menudo llamamos un «diseñador») repetirá y meditará e impulsará sus diversas ideas hasta que tomen una forma que parezca prometedora, y tal vez, si entrecierras un poco, como algo que podría publicarse.

En este punto, se destinan más recursos al proyecto. Esto podría incluir algo de arte conceptual, pero la mayoría de estos recursos están compuestos por el tiempo del líder del proyecto. Básicamente obtienen la capacidad de pasar una parte significativa de su día empujando el juego aún más. La iteración se intensifica, y quizás otros miembros del personal son arrastrados a sesiones de prueba de juego.

Luego se piensa mucho si este juego se ve o no como algo que deberíamos poner en el calendario. Tenemos que pensar en nuestra audiencia, nuestra marca, nuestra misión y nuestros gustos. ¿Es este el tipo de cosas con las que nos sentiríamos cómodos vendiendo algo? ¿Debería existir esto?

Suponiendo que la respuesta es sí, echamos un vistazo a un proyecto y tratamos de averiguar cuánto tiempo llevará realmente un proyecto. Esta es una evaluación complicada e imperfecta, pero tenemos varias personas en el personal que han ayudado a llevar los juegos a través del proceso de publicación y, como grupo, tenemos un buen conjunto de experiencias para aprovechar. Durante esta conversación, generalmente me encuentro hablando en términos de «responsabilidades de diseño», es decir, elementos de diseño inestables o nuevos que podrían ser realmente problemáticos y amenazar con descarrilar un proyecto. También hablamos un poco sobre el presupuesto, las demandas de producción y sobre qué otros recursos editoriales / creativos / operativos podríamos necesitar utilizar para crear el juego. A partir de aquí, creamos un horario suelto y nos dedicamos al negocio de hacer un juego.

Cuando hablo sobre el desarrollo en el contexto de Leder Games, generalmente estoy hablando del período posterior a la utilización de los recursos del estudio hasta el momento en que el juego está en la fábrica. Es menos un tipo de trabajo o un título de trabajo que una fase del proceso de creación del juego.

Entonces, para Oath, estoy sirviendo como un líder y gerente de proyecto. También encabezo el diseño, organizo el desarrollo y hago todo lo posible para ayudar en la estrategia de marketing del juego y el diseño del producto. ¡Eso seguro hace que parezca que estoy haciendo mucho! Y si bien eso es cierto, también desmiente el hecho de que también soy miembro de un equipo más amplio de desarrolladores, editores, diseñadores gráficos, gerentes de producción, comercializadores y otros que hacen posible el juego. No somos una gran empresa, por lo que se espera que todos ayuden en la creación de juegos.

Pruebas de juego y control de versiones

Alrededor de este tiempo, también reúno a un grupo de expertos en juegos que creo que serán adecuados para el proyecto. En general, no hago llamadas de prueba públicas. En cambio, trato de encontrar jugadores que consideren críticos (en todos los sentidos) y desafiados por el proyecto de tratar de entender el juego.

Si incluye jugadores de prueba, es por esta época que el «equipo» detrás de cada juego va de una persona a más de veinte o treinta. Eso significa que mi propio papel comienza a pasar de ser un «artista solitario» a algo más como un gerente de nivel bajo o medio. Toda esa gestión de proyectos que me ayudó a terminar la escuela de posgrado ha pagado algunos dividendos importantes en el mundo del diseño de juegos.

Escribiendo sobre este cambio ahora, me sorprende cuán seriamente diferentes son las demandas de cada una de estas fases entre sí. Durante la primera fase, es decir, antes de que el desarrollo comience en serio, realmente no necesito preocuparme por la estructura de archivos de los activos del juego o su control de versiones. Piensa en ello como un taller. Una persona que trabaja solo requiere una habitación pequeña. Pero un equipo de treinta personas requeriría una gran suite, con salas comunes y un calendario de reuniones para asegurarse de que la información pase entre los diferentes miembros del equipo.

Cosas como el control de versiones pueden ser bastante complicadas. Por lo general, tendré una versión innovadora del juego que estoy usando para probar internamente. A veces ramifico este diseño y tengo una versión secundaria que también se está probando dentro del estudio. Hay muchos ajustes que se realizan a diario. Cuando aprendí por primera vez el arte del diseño, compartía estos hallazgos con mis expertos en juegos casi tan pronto como los había investigado (a veces antes). Chico, fue un error. Las versiones del kit de prueba de juego hicieron un ciclo tan rápido que agoté a docenas de excelentes grupos de prueba de juego.

Para detener esto, introduje algo de un búfer. En el estudio, felizmente iteraría y me ajustaría al contenido de mi corazón, pero evitaría hacer iteraciones en el juego a menos que haya una solución crítica necesaria o hayan transcurrido al menos dos o tres semanas. (Como puede suponer, hay muchas excepciones a esto. Root se repitió muy rápidamente con un excelente cuerpo de expertos en pruebas. Oath probablemente tendrá actualizaciones menores aproximadamente cada dos semanas durante el próximo mes y luego se instalará en actualizaciones una vez cada tres semanas.)

Tiendo a pensar en la versión de prueba actual del juego como su «versión adecuada». Hago esta distinción porque a veces tendré que tomar esta versión y crear una copia para los kits públicos de print-and-play. Una impresión y reproducción pública está básicamente desactualizada en un par de semanas después de su lanzamiento. No ofrecemos ningún soporte para ellos fuera de los archivos iniciales. En su mayoría, son un regalo para las personas fuera de nuestro equipo para ver cómo se ve el juego y para darles la oportunidad de disfrutar y explorar lo que hemos hecho hasta ahora.

Hay algunas otras arrugas en este sistema también. Además de los grupos de prueba remota, tenemos varios grupos locales que juegan los miércoles por la noche en la oficina. Estos grupos juegan una rama del juego que, en la práctica, está en algún lugar entre mi rama de última generación y la versión de prueba de juego. También tenemos que enviar una vista previa y revisar copias que son un poco como las impresiones y jugadas públicas, ya que son instantáneas de la versión de prueba. Por lo general, la demora en la publicación de cualquier pieza sobre una versión de prueba de juego es una o dos versiones desactualizadas para el momento en que se publica. Creo que probablemente hay kits para media docena de diferentes sabores de juramento flotando en este momento.

Gran parte de este proceso está diseñado en torno a un problema logístico central: los kits tardan en construirse y enviar. Entonces, en un esfuerzo por no fatigar a mis jugadores de prueba, hago lo que puedo para protegerlos de la iteración generativa que está en el centro del proceso. Esencialmente, estoy cambiando el problema logístico de otra persona por uno administrativo con el que tengo que lidiar.

Esta es otra razón por la cual mantenemos cerrados nuestros principales esfuerzos de prueba de juego. Cada grupo de pruebas de juego nos exige a mí y al equipo aquí. Esas demandas pueden incluir cosas como soporte técnico y preguntas sobre reglas o simplemente el tiempo dedicado a leer los comentarios que brindan. Los mejores grupos de evaluación a menudo exigen la mayor parte de mi tiempo. Afortunadamente, hay muchos sistemas que uno puede implementar para ayudar a mitigar esta pregunta. Estamos utilizando un nuevo sistema de comentarios para Oath que se basa en formularios de Google, hojas de Google y un sólido canal de discordia. Funcionó muy bien y creo que esencialmente nos permitirá duplicar o incluso triplicar nuestra capacidad de prueba de juego principal.

Esto es genial, porque tenemos mucho trabajo por delante. Aunque Oath está mucho más terminado ahora que la mayoría de los juegos, he ayudado a Kickstart, pero aún queda mucho por hacer, y el tiempo que pasamos administrando equipos de pruebas de juego es un tiempo bien invertido.

Los beneficios de las pruebas externas

Nuestros expertos en juegos nos dan tres cosas: una mejor comprensión del juego, la capacidad de poner a prueba el equilibrio de ciertos elementos del juego y una audiencia para probar la usabilidad y accesibilidad de cosas como reglas y componentes. Críticamente, no me importa si a los jugadores de prueba les gusta o no el juego. Eso siempre es una buena ventaja, pero no es su trabajo. No confío en los evaluadores para la investigación de mercado ni me importa si les dicen a sus amigos que lo compren (o no lo compren). Quiero que me ayuden a comprender lo que estamos haciendo juntos.

Los meses de trabajo que generalmente siguen a un Kickstarter se tratan de desarrollar un conocimiento profundo del espacio del juego y las preguntas que orbitan alrededor del diseño. A medida que esas cosas se enfocan, la naturaleza de las pruebas de juego cambia hacia el intento de crear el espacio de decisión más amplio posible para los jugadores en el juego: a menudo llamo a este trabajo equilibrar un juego, aunque a veces se equilibra en el sentido tradicional. No tiene nada que ver con eso.

Mientras continúa el proceso de equilibrio, comenzaremos a desarrollar nuestros estudios de usabilidad. Algunos de estos se llevan a cabo en nuestras oficinas en Saint Paul y otros ocurren de forma remota, principalmente bajo la atenta mirada de nuestro editor, Josh Yearsley. Durante estas pruebas, trabajamos duro en el diseño físico, ajustando la redacción y tratando de construir ayudas de juego que hagan que el juego sea más fácil de jugar y pensar. Josh ha escrito bastante sobre este proceso antes e imagino que en el futuro escribirá más sobre Oath.

A medida que termina la usabilidad, comenzamos a limpiar los archivos y preparar el juego para imprimir. Este proceso implica que entregue los archivos de trabajo que tengo a los diseños gráficos del personal que los ponen en forma tanto para los especialistas en impresión de la fábrica como para los futuros socios de idiomas que podamos obtener después del lanzamiento de la primera impresión.

Durante esta etapa tardía, todavía es posible para mí hacer cambios en el diseño, pero con cada día los cambios se vuelven costosos en términos de la mano de obra que se necesitaría para realizar el cambio. Los cambios también se vuelven mucho más riesgosos. Muchos de los sistemas de supervisión que guiaron el desarrollo del juego están en proceso de cierre, por lo que comienzas a carecer de la capacidad de examinar lo que estás haciendo.

Esta es una de las grandes paradojas del desarrollo de juegos. A medida que tu conocimiento del juego se profundiza, tu habilidad para intervenir se debilita. Fue mucho más fácil hacer grandes cambios cuando todo estaba en unas pocas páginas en su cuaderno.

Despues de las imagenes

En los años transcurridos desde la publicación de Root, a menudo me preguntan cuántas pruebas realizamos en el estudio. ¿Cómo podría comenzar a responder esa pregunta? La versión impresa final del juego se jugó solo unas pocas veces antes de que la enviáramos a fábrica. Pero, seguramente las jugadas de las versiones casi finales también contaron para algo. Cientos de juegos se registraron en el estudio y miles más si incluyo a mis equipos de prueba. Llevamos el juego a través de una montaña de pruebas de usabilidad y verificación y lo mostramos a amigos cercanos y confidentes, pero ninguna de esas versiones fue el juego final. Eran solo precursores, fantasmas de un futuro juego. Realmente, ese es el trabajo de desarrollo y publicación de juegos. Durante el proceso de desarrollo, el juego no es solo una cosa. Es una docena de cosas, tal vez cientos. Todos esos pequeños fantasmas extraños se parecen a algo que quieres que exista, pero ninguna imagen parece capturar todo el proyecto. Con cada semana y cada mes de trabajo, estos fantasmas se deshacen hasta que solo te queda una imagen indeleble. A veces, esa imagen final no es del todo perfecta; podría estar obsesionada por otras versiones que no fueron del todo descansadas pacíficamente. Pero, cuando funciona bien, el juego aparece en foco perfecto: la suma única de todo ese trabajo.

Y luego, por supuesto, envía ese paquete de archivos a una fábrica para su duplicación.

Deja una respuesta

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Salir /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Salir /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Salir /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Salir /  Cambiar )

Conectando a %s