Plantilla de documento de diseño de juegos: una página viva
Resumen
Una plantilla de documento de diseño de juegos funciona mejor como una sola página: propuesta de concepto, pilares, bucle central, lista de sistemas y preguntas abiertas. Añade trasfondo, números y notas de producción solo cuando las partidas de prueba demuestren una mecánica. La guía explica cómo hacer que los pilares puedan vetar funciones, dónde debe vivir el trasfondo, qué herramienta elegir y en qué punto la IA ayuda sin decidir por ti.
Una plantilla de documento de diseño de juegos debería caber en una sola página al principio, y crecer solo cuando el juego se lo gane. Empieza con cinco bloques: propuesta de concepto, pilares de diseño, bucle central, lista de sistemas y preguntas abiertas. Todo lo demás, desde el trasfondo hasta las notas de niveles, se añade cuando una partida de prueba demuestra que la mecánica funciona. Abajo tienes la plantilla que usamos en proyectos de rol de mesa y videojuegos indie, y los puntos donde cada sección tiende a pudrirse.
¿Por qué la mayoría de los documentos de diseño mueren en la tercera semana?
El fallo habitual es la ambición. Alguien abre un archivo en blanco, pega un esquema de veinte secciones sacado de un foro y pasa el fin de semana rellenando casillas para mecánicas que nadie ha probado. A la tercera semana el juego ha cambiado y el documento no. Nadie lo abre y nadie lo admite.
La guía de GDD de Game Dev Beginner lo dice sin rodeos: los documentos grandes y demasiado detallados exigen mucho trabajo por adelantado, casi siempre quedan desfasados y se vuelven una camisa de fuerza cuando el diseño todavía se mueve. Su solución es ir por fases. Escribe primero una página, luego diez cuando el juego tome forma, y la versión completa solo cuando haya contenido en producción.
Eso pesa más en el diseño de rol de mesa que en el de videojuegos. Quien diseña un juego de rol suele ser a la vez guionista, responsable de sistemas y probador. No hay un ingeniero esperando una especificación. El documento tiene una sola misión: impedir que te contradigas entre la sesión cuatro y la sesión cuarenta.
Descarta la plantilla de 40 páginas si trabajas solo. No la vas a mantener. Incluso la definición estándar describe el GDD como un documento vivo, lo que significa que nadie espera que esté terminado el primer día.
¿Qué incluye una plantilla de documento de diseño de juegos que la gente realmente abre?
Cinco bloques cubren el primer mes de casi cualquier proyecto. Mantén cada uno lo bastante corto como para leer toda la página en dos minutos.
Propuesta de concepto. Dos frases. Quién juega, qué hace y en qué se diferencia del juego más parecido que ya tiene en su estantería.
Pilares de diseño. Entre tres y cuatro afirmaciones contra las que se prueba cada decisión posterior. "Cada combate cuesta algo permanente" es un pilar. "Divertido y envolvente" no lo es.
Bucle central. Lo que el jugador repite. En un dungeon crawl puede ser explorar, elegir, arriesgar, gastar. En una campaña política, intriga, palanca, consecuencia, secuela.
Lista de sistemas. Solo nombres, con una línea cada uno. Todavía no especifiques números.
Preguntas abiertas. La sección más útil de la página y la que las plantillas suelen dejar fuera. Anota lo que no sabes, y pon fecha.
Añade al final un registro de cambios, aunque sea una línea por semana. Cuando una partida de prueba mata una idea, anota la baja y el motivo. Si no, tu yo futuro volverá a probar la misma idea.
¿Cómo se escriben pilares de diseño que puedan perder una discusión?
Un pilar se gana su sitio vetando algo. Si no puedes nombrar una función que el pilar rechazaría, es decoración.
Pon a prueba cada pilar con una lista de recortes. Toma las tres funciones a las que más cariño le tienes y pregúntate qué pilar sirve cada una. Una función que no sirve a ninguno va a la estantería de "quizá más adelante", y esa estantería puede ser todo lo larga que haga falta. Es la hora más dura de todo el proceso, y vale más que cualquier sección de cualquier plantilla.
Te dejo un ejemplo trabajado, de una ambientación de campaña con una peste en el centro. Pilar uno: la escasez es visible, así que cada recurso de curación se lleva la cuenta sobre la mesa. Pilar dos: las facciones quieren curas distintas, así que ningún tratamiento lo resuelve todo. Pilar tres: el mapa se encoge, así que viajar cuesta más a medida que avanza la historia. Ahora llega la propuesta de un hechizo de resurrección. El pilar uno la rechaza. La decisión tarda diez segundos en lugar de un debate de cuarenta minutos.
Dato útil: los pilares no son un eslogan de marketing. Son internos y directos, y pueden sonar algo ásperos. No pasa nada.
¿Dónde va el trasfondo en un GDD y dónde estorba?
El trasfondo es la sección que más crece y menos se lee. La mayoría de documentos lo entierran al final bajo un título de "Historia", o dejan que se coma el archivo entero. Ninguna de las dos cosas funciona.
Separa el material según lo que hace. El trasfondo que cambia la partida, como el rencor de una facción que desbloquea una misión o una maldición que da forma a una clase, vive dentro de los sistemas que afecta. El trasfondo que solo pone ambiente vive en una página aparte del Codex, que nadie necesita abrir para tomar una decisión de diseño. La prueba es sencilla: si borrar el párrafo no cambia una mecánica, una tirada o una decisión del jugador, pertenece al Codex.
Esa separación también protege el canon. Cuando un dato vive en dos sitios, los dos acaban divergiendo. Elige un único hogar para cada dato y enlázalo desde los demás lugares. El canon es una promesa, y cada incoherencia la rompe.
Los diseñadores de juegos muy narrativos suelen añadir una página corta de cronología y una lista de "quién sabe qué". Las dos cosas cuestan poco y ahorran sesiones enteras de rehacer trabajo cuando una revelación tardía tiene que caer bien.
¿Qué herramienta debe alojar tu plantilla: Notion, Obsidian o un documento simple?
La herramienta importa menos que quedarse en el lugar donde ya trabajas. Un documento que vive en una pestaña que nunca abres está muerto.
Notion es la opción por defecto para equipos pequeños, porque las páginas se enlazan entre sí, las bases de datos guardan objetos y facciones, y los colaboradores no necesitan configuración. Existen plantillas hechas, incluida una plantilla de GDD para Notion, con secciones de controles, bucle de juego, diseño de niveles y reglas. La pega es la dependencia del proveedor y la tentación de montar bases de datos para cosas que no las necesitan.
Obsidian sirve al diseñador en solitario que quiere archivos Markdown planos en su disco. Los backlinks hacen un trabajo real: enlaza una facción con cada escena donde aparece y tendrás una comprobación de coherencia gratis. Sobrevive a que el proveedor desaparezca, algo que importa si el proyecto dura años.
GitBook funciona cuando el documento tiene que ser público o semipúblico, por ejemplo para un grupo de prueba o una página de mecenas en una campaña de financiación colectiva. Un Google Doc sencillo basta para una game jam. Evita cualquier modelo de permisos pesado, salvo que una editorial lo pida.
Elijas lo que elijas, fija una regla: el documento se actualiza al final de cada partida de prueba, antes de que nadie se vaya a casa. Diez minutos, sin excepciones.
¿Qué añadir cuando el prototipo sobrevive a las partidas de prueba?
Tras tres o cuatro sesiones con jugadores reales, la página de una sola hoja se gana su siguiente capa. Añade secciones en este orden, y solo cuando aparezca el dolor.
Detalle de sistemas. Números, tablas de valores, casos límite. Escríbelos cuando cierres un sistema, no antes. En un juego de rol aquí van la economía de acciones, los rangos de daño y los costes de recursos, junto con el texto de las reglas tal como está escrito. En un videojuego, añade las tablas de datos que leerán los ingenieros.
Listas de contenido. Objetos, enemigos, facciones, lugares. Usa una lista con una línea por entrada, y al final de cada línea el pilar al que sirve. Las entradas que no sirven a ninguno son candidatas a recorte.
Interfaz y flujo. La maqueta de la ficha de personaje en el rol de mesa, o el flujo de pantallas en lo digital. Dibújalo a mano antes de describirlo en texto.
Notas de producción. Hitos, alcance, riesgos, qué entra en la primera versión y qué no. Si piensas vender el resultado en DriveThruRPG o Itch.io, aquí empiezan también el texto de tu página y tus supuestos de precio.
Un apartado de presentación o de marketing es un documento aparte para un lector distinto. Editoriales y mecenas quieren contexto de mercado y argumentos de venta. Tus probadores quieren reglas. Mezclarlos produce un archivo que no sirve a ninguno de los dos.
¿Puede la IA ayudarte a escribir un documento de diseño de juegos, y dónde se queda corta?
Ayuda con borradores de las partes aburridas y falla en las que importan. Pide a un modelo que convierta una lista de sistemas en una lista de casos límite y obtendrás una primera pasada decente en un minuto. Pídele que elija tus pilares y obtendrás pilares que suenan a cualquier otro juego. Genera rápido. Las decisiones siguen necesitando una pasada humana.
El uso práctico es la comprobación de coherencia. Dale el Codex y la lista de sistemas, y pregúntale en qué páginas se contradicen dos datos. Herramientas pensadas para una biblia narrativa larga, como Novelcrafter, están hechas para este tipo de cruce. Trata la salida como una lista de sospechosos, no como un veredicto, y verifica cada alerta contra tus propias páginas.
Una regla firme: el modelo nunca escribe la sección de preguntas abiertas. Esa página es tu lista honesta de lo que no sabes, y cederla arruina el sentido de todo.
¿Qué conviene saltarse y qué conviene conservar?
Salta la plantilla completa hasta que una mecánica haya sobrevivido al menos a tres sesiones reales. Salta el ensayo sobre el público objetivo si no puedes nombrar a cinco personas reales que jugarían. Salta las secciones detalladas de monetización en un juego que todavía no ha encontrado su bucle. Salta cualquier sección que no puedas imaginar leyendo en voz alta a un colaborador.
Conserva los pilares, las preguntas abiertas y el registro de cambios. Esos tres hacen casi todo el trabajo. Un documento que solo tenga esos tres, actualizado cada semana, gana a un archivo pulido de 30 páginas que nadie ha abierto desde marzo.
La plantilla es una promesa a tu yo futuro sobre lo que decidiste y por qué. Mantenla lo bastante corta como para poder cumplirla.