Esta entrada fue escrita originalmente en italiano por Paolo Gambardella. Ha sido traducida por un agente de inteligencia artificial y puede contener imprecisiones.
Cuando se habla de game design document, de documentación de diseño, enseguida se pasa a plantillas y formatos estándar. En mi opinión, así se pierde la oportunidad de ver el panorama general. El formato, de hecho, es solo un aspecto de una de las cinco partes de una buena documentación de diseño.
Hace unos meses escribí sobre la diferencia entre documento y documentación. Este post retoma desde ahí: una vez que tenemos claro que estamos documentando algo concreto, ¿qué debe contener el documento?
Cinco puntos de vista
Para hacerlo más concreto usaré un ejemplo sencillo: el boost en un juego de carreras.
Conocimientos. Ante todo, un documento de diseño se estructura en torno a una serie de conocimientos que el juego, o la feature en cuestión, debería transmitir a los jugadores. En el pasado he hablado de la player experience narrative, es decir, el relato del juego o de la feature escrito desde el punto de vista de un jugador apasionado. Esto nos ayuda a identificar los componentes de lo que vamos a describir, y por tanto los skill atoms, los conocimientos que vamos a transmitir. La diversión nace siempre de un proceso de descubrimiento, similar al creativo: jugar es aprender.
En el caso del boost, los skill atoms podrían ser: entender cuándo la barra está llena, descubrir que usar el boost en curva hace perder adherencia, aprender a guardarlo para la recta final. Cada uno de estos es un pequeño descubrimiento, y cada uno debe describirse.
Objetivos. En segundo lugar, el documento recoge los objetivos que tenemos desde el punto de vista del juego. Estos se concretan en comportamientos específicos que esperamos de los jugadores y, a veces, también en emociones que queremos provocar. Normalmente se parte de los game pillars (si los tenemos) y se explica así la meta que debemos alcanzar.
Para el boost, el objetivo podría ser que el jugador lo use al menos una vez por vuelta y que sienta una descarga de adrenalina en la recta. Un pillar solo tiene valor si nos obliga a renunciar a algo: si el pillar es “velocidad”, el documento debe decir también qué sacrificamos para mantenerla, por ejemplo, ningún menú durante la carrera. Y si esperamos un comportamiento concreto, escribimos también cómo lo vamos a medir. Un objetivo que no podemos observar en un playtest o en los datos se queda en buena intención.
Gameplay. Después se pasa a planificar el gameplay, concretando los objetivos del jugador, los contenidos, las actividades y las posibles estrategias que puede seguir para superar los obstáculos. En esta sección aparecen con mucha frecuencia diagramas de flujo, listas con viñetas y similares.
Aquí es donde entra en juego el formato. La forma en que presentamos el gameplay debe estar al servicio de quien lo lee. Para el boost, un diagrama con los estados (vacío, cargando, lleno, activo) le dice al programador más que tres páginas de texto, mientras que una tabla con velocidades y duraciones es más útil para quien se encarga del balanceo. El formato se elige según el contenido y el lector, y puede cambiar de sección en sección.
Sistemas. Un buen documento de diseño no puede evitar considerar los sistemas. Un sistema es un grupo de mecánicas que, juntas, enseñan algo al jugador: por eso lo veo como un conjunto de experiencias de aprendizaje. También existen dinámicas no planificadas, que a veces conseguimos identificar y que luego pasan a formar parte del metagame.
Scott Mercer cuenta en un breve vídeo cómo diseñó a Gruul the Dragonkiller, un boss de World of Warcraft: Burning Crusade. Quería recrear la emoción de las sillas musicales, cuando la música para y todos corren a buscar un sitio. La primera mecánica, Shatter, inflige daño a quien esté cerca de otros jugadores, así que estos aprenden a dispersarse. Mercer ya prevé una dinámica no planificada: la raid podría asignar a cada uno un punto fijo, y la gracia desaparecería. Añade entonces Ground Slam, que lanza a cada jugador en una dirección aleatoria y le obliga a improvisar. Luego está la latencia: en 2007 muchos jugadores seguían con conexión por módem, y cada uno veía a los demás en posiciones ligeramente distintas. Llega entonces una ralentización progresiva, que da tiempo a los clientes para sincronizarse y, de propina, añade tensión. Por último, cuantos más jugadores mueren, más espacio queda para dispersarse, con lo que el enfrentamiento se volvería demasiado fácil. Un aumento gradual del daño mantiene a todos motivados para sobrevivir.
Cada mecánica tapa el agujero que dejaba la anterior, y cada una cambia lo que el jugador aprende. Por eso, si la feature que estamos documentando forma parte de un sistema más grande, o si afecta a otros sistemas, debemos demostrar que hemos entendido el conjunto e intentar anticipar cómo funcionará. Volviendo a nuestro ejemplo: si el boost se recarga recogiendo objetos en la pista, también cambia la forma en que el jugador elige sus trazadas, y el diseño de niveles necesita saberlo.
Producción. Por último, una buena documentación de diseño ayuda a resolver problemas y retos de diseño, y guía a programadores y artistas en la realización de todos los assets necesarios para el éxito de la feature o del juego en cuestión. Para el boost esto significa listar efectos visuales, sonidos y movimientos de cámara, y señalar las preguntas que siguen abiertas: ¿qué pasa si el jugador activa el boost durante un salto?
Las plantillas tienen sus límites
Cuando nos centramos demasiado en el formato final, corremos el riesgo de perder la visión de conjunto y de omitir partes que quizás una plantilla contempla y otra no.
Tomemos el documento de una página, el one-pager. Es estupendo para alinear al equipo o presentar una idea a un publisher, pero los sistemas y sus interacciones no caben ahí dentro. Muchas plantillas clásicas de GDD, en cambio, tienen secciones interminables sobre gameplay y ninguna sobre los conocimientos que el jugador debe adquirir. Cuando elijo un formato, ya sé cuál de los cinco puntos estoy sacrificando, y lo documento en otro sitio.
Por eso uso las cinco partes como una checklist, antes incluso de abrir una plantilla: conocimientos, objetivos, gameplay, sistemas, producción. Si falta alguno, el documento tiene un agujero, sea cual sea el formato.
