Esta entrada fue escrita originalmente en italiano por Paolo Gambardella. Ha sido traducida por un agente de inteligencia artificial y puede contener imprecisiones.
Una de las responsabilidades principales de un game designer es escribir documentación de diseño. Cualquiera es capaz de escribir documentos, pero un designer se dedica a la documentación, que es algo diferente.
Un documento contiene pensamientos, ideas, lo que sea. La documentación, en cambio, es un tipo de documento específico sobre algo concreto. Una investigación sobre un juego de la competencia. El resultado de un playtest. Una feature que hemos construido y observado en acción. Un prototipo que ha respondido a una pregunta concreta.
Para entender por qué esta regla se viola tan a menudo, conviene pensar en cómo se acumula el conocimiento durante el desarrollo de un juego.
Concept DOCUMENTS
Al principio de un proyecto, casi todo es incierto.
- Constraints | Hay cosas que ya sabemos: la plataforma objetivo, el género, quizás el presupuesto.
- Frontiers | Hay preguntas que sabemos que tenemos que responder: cómo funciona el core loop, cuánto dura una sesión típica.
- Risks | Hay cosas que aún no sabemos que no sabemos. Los problemas de diseño que solo emergen cuando el jugador tiene el mando en la mano. Las interacciones entre sistemas que parecían obvias sobre el papel y resultan un desastre en la práctica. Las suposiciones que nadie ha cuestionado nunca porque parecían tan evidentes que no merecían atención.
Un concept document vive casi por completo en esa tercera capa. No es documentación, es una instantánea de la imaginación del equipo en un momento concreto.
Game Design DOCUMENTATION
La documentación de verdad llega después. Después de haber prototipado y descubierto que la mecánica que parecía brillante no funciona como pensábamos. Después de haber analizado cómo otro juego ha resuelto el mismo problema. Después de haber testeado y observado. En ese momento sí tenemos algo que documentar de verdad.
Documentos y Documentación
Un documento sirve a un objetivo temporal. Las notas de una reunión son un documento. Un concept doc es un documento. Una lista de ideas apuntadas antes de una sesión de brainstorming es un documento. Son herramientas de trabajo válidas, necesarias, y tienen una vida útil natural: sirven ahora, luego pasan a la historia.
La documentación, en cambio, está pensada para durar.
- Debe ser clara para alguien que no estuvo en esa reunión.
- Debe ser práctica, una referencia que se pueda usar de verdad, no solo leer.
- Debe inspirar a quien la lea seis meses después, cuando el entusiasmo inicial se ha enfriado y hacen falta puntos de apoyo concretos.
- Y debe ser atractiva: no como ejercicio estético, sino porque si nadie abre un documento, ese documento no existe. Yo aplico esta fórmula: el 60% del espacio debe estar ocupado por elementos visuales (diagramas, imágenes, vídeos…). El 30% por datos y tablas. El 10% por texto. ¡La documentación no es un tratado ni una novela para leer!
No todos los documentos son documentación; el proyecto requerirá distintos tipos de documento. Tu equipo, en cambio, necesita documentación.
Cómo es una documentación de verdad
Una buena documentación de diseño responde a pocas preguntas de forma inequívoca: ¿qué es este juego? ¿Por qué es interesante? ¿Cuál es la fantasy, la promesa emocional que le hace al jugador? ¿Cuáles son las features core —no todas las features, solo las que definen la identidad del producto—? ¿Cómo funciona exactamente este sistema? Y suficiente contexto de producción como para que el documento sea accionable.
Hay un principio que me resulta especialmente útil en este sentido: si un equipo no es capaz de explicar su juego de forma clara y concisa, probablemente el diseño todavía no está suficientemente claro. La claridad de la documentación refleja la claridad del pensamiento. Un documento denso, lleno de secciones y subsecciones que intentan cubrir cada eventualidad, es a menudo la señal de que aún no sabemos lo suficiente para documentar.
Y esto nos devuelve a la regla número 1. Si todavía no tienes algo concreto que documentar, quizás no es el momento de escribir documentación. Es el momento de investigar. De construir un prototipo. De testear. De responder a las preguntas que aún no sabes que tienes. De aprender y descubrir.
¿Esto documenta algo que existe, o algo que queremos construir?