# Plantilla de documento de diseño de juego (GDD)

Nueve documentos enlazados que cubren un juego desde el pitch hasta el registro de decisiones, cada uno con indicaciones sobre qué escribir y un ejemplo breve. Descárgalos como archivos Markdown: se abren en cualquier editor, muestran sus diagramas en GitHub y en Obsidian, y se importan en Nodary como un mapa.

Gratis, sin cuenta y sin correo. Úsala, modifícala, compártela.

[Descargar la plantilla (.zip)](https://nodary.ai/downloads/plantilla-documento-de-diseno-de-juego.zip)

## Lee cada página antes de descargarla

La visión general cabe en una pantalla y enlaza con ocho partes, una por disciplina, para que cada parte tenga un responsable y cada cambio siga siendo pequeño. Las líneas en cursiva dicen qué escribir; los ejemplos vienen de Saltmarrow, el juego de muestra que este sitio usa en todas partes.

- Documento de diseño de juego: La página que todos leen primero: pitch, pilares, público, alcance y un enlace a cada parte.
- Gameplay: Lo que hace el jugador de un minuto a otro, y por qué sigue haciéndolo.
- Sistemas y economía: Cada sistema, las reglas que sigue, los recursos que mueve y los números que hay detrás.
- Mundo, historia y personajes: La ambientación y sus reglas, la historia que vive el jugador y quienes la habitan.
- Niveles y contenido: Cada lugar al que va el jugador, la primera hora y cuánto contenido necesita el lanzamiento.
- Dirección de arte y audio: Cómo se ve y cómo suena el juego, con la precisión suficiente para que dos artistas que trabajan por separado encajen.
- Interfaz y accesibilidad: Pantallas, HUD y controles, y cómo se adapta el juego a cada jugador.
- Diseño técnico: Motor, objetivos de rendimiento, arquitectura y pipeline, y los límites que imponen al diseño.
- Plan de producción: Hitos, equipo, riesgos y el registro de cada decisión que cambió el diseño.

### Documento de diseño de juego

_Cómo usar esta plantilla: las líneas en cursiva son indicaciones. Sustitúyelas por tus propias palabras y luego bórralas. Los valores entre corchetes los rellenas tú. Que esta página ocupe más o menos una pantalla: es la que todos leen primero, y cualquier otra parte del diseño está a un enlace._

#### De un vistazo

| Campo | Tu juego |
| --- | --- |
| Título provisional | [Título] |
| Logline | [Una frase que un desconocido podría repetir] |
| Género | [Género y subgénero] |
| Jugadores | [Un jugador, cooperativo de 2 a 4, competitivo] |
| Plataformas | [PC, consolas, móvil] |
| Duración de una sesión | [Una sesión típica, en minutos] |
| Motor | [Motor y versión] |
| Equipo | [Tamaño actual y máximo previsto] |
| Modelo de negocio | [Precio, free-to-play, suscripción] |
| Próximo hito | [Nombre y fecha] |

#### Pitch

_Dos o tres frases: quién es el jugador, qué hace y qué hace distinto al juego. Escríbelo de forma que también funcione en una página de tienda._

_Ejemplo (Saltmarrow, un juego de muestra): Rastrilla sal, bucea en busca de recuerdos y vuelve antes que la marea. Un juego cooperativo de exploración y fabricación para hasta cuatro jugadores, ambientado en unas salinas de marea donde una ciudad archivo sumergida sale a la superficie dos veces al día._

[Tu pitch]

#### Pilares de diseño

_Entre tres y cinco reglas a las que debe servir cada funcionalidad. Un pilar que podría describir cualquier juego, como «combate divertido», no es un pilar. Una funcionalidad que no sirve a ningún pilar se recorta; una que rompe alguno se rediseña._

1. **[Primer pilar]**: [qué significa, en una frase]
2. **[Segundo pilar]**: [qué significa, en una frase]
3. **[Tercer pilar]**: [qué significa, en una frase]

_Ejemplo (Saltmarrow, un juego de muestra): La marea es el reloj. El tiempo es el único recurso que nunca crece: todos los sistemas leen la marea, y nada la detiene._

#### Público

_Para quién es el juego, a qué juega hoy esa gente y cuándo deja de jugar. Nombra juegos y hábitos reales, no solo una franja de edad._

- Jugadores principales: [quiénes son y cómo juegan]
- A qué juegan hoy: [tres o cuatro juegos]
- Dejan de jugar cuando: [...]
- Jugadores secundarios: [...]

#### Juegos comparables

_Tres o cuatro juegos que tu equipo y tus jugadores ya conocen. Di qué tomas de cada uno y, igual de útil, qué dejas fuera._

| Juego | Qué tomamos | Qué dejamos fuera |
| --- | --- | --- |
| [Juego] | [...] | [...] |
| [Juego] | [...] | [...] |
| [Juego] | [...] | [...] |

#### Alcance

_Qué incluye el primer lanzamiento y qué deja fuera de forma explícita. La segunda lista es la que impide que el alcance crezca sin que nadie lo note._

- En el primer lanzamiento: [...]
- Fuera del primer lanzamiento: [...]
- Por decidir más adelante: [...]

#### El resto del diseño

_Cada parte es un documento propio. Enlázala en lugar de copiar de ella, para que cada dato viva en un solo sitio y cambie en un solo sitio._

- [Gameplay](https://nodary.ai/es/templates/game-design-document#gdd-gameplay): el bucle de juego, las mecánicas, los controles y la progresión
- [Sistemas y economía](https://nodary.ai/es/templates/game-design-document#gdd-systems): cada sistema, sus reglas y sus números
- [Mundo, historia y personajes](https://nodary.ai/es/templates/game-design-document#gdd-world): la ambientación, la historia y quienes la viven
- [Niveles y contenido](https://nodary.ai/es/templates/game-design-document#gdd-levels): cada lugar, la primera hora y el presupuesto de contenido
- [Dirección de arte y audio](https://nodary.ai/es/templates/game-design-document#gdd-art): cómo se ve y cómo suena el juego
- [Interfaz y accesibilidad](https://nodary.ai/es/templates/game-design-document#gdd-interface): pantallas, HUD, asignación de controles y accesibilidad
- [Diseño técnico](https://nodary.ai/es/templates/game-design-document#gdd-technical): motor, objetivos de rendimiento, arquitectura y pipeline
- [Plan de producción](https://nodary.ai/es/templates/game-design-document#gdd-production): hitos, equipo, riesgos y el registro de decisiones

_Puedes usar, modificar y compartir esta plantilla libremente. Viene de_ [Nodary](https://nodary.ai/es)_, donde estos archivos se importan como un mapa de documentos enlazados._

### Gameplay

**Responsable:** [nombre] · **Estado:** borrador · **Última revisión:** [fecha]

_Lo que hace el jugador de un minuto a otro, y por qué sigue haciéndolo. Empieza por el bucle: todo lo demás de este documento cuelga de él._

#### Bucle de juego

_El bucle que más repite el jugador, en cuatro, cinco o seis verbos. Si el equipo no sabe dibujarlo, todavía no está cerrado._

```mermaid
flowchart LR
  n0["Planificar"]
  n1["Explorar"]
  n2["Recolectar"]
  n3["Fabricar"]
  n4["Mejorar"]
  n0 --> n1
  n1 --> n2
  n2 --> n3
  n3 --> n4
  n4 --> n0
```
_El bucle de juego, unos [n] minutos por vuelta_

| Fase | Tiempo típico | La pregunta del jugador |
| --- | --- | --- |
| [Planificar] | [2 min] | [¿Qué objetivo esta vez y qué me llevo?] |
| [Explorar] | [...] | [...] |
| [Recolectar] | [...] | [...] |

_Ejemplo (Saltmarrow, un juego de muestra): Cosechar o bucear, de 8 a 14 minutos: ¿rastrillar sal segura o bucear en busca de cristales que quizá valgan más? Cada fase debería plantearle una pregunta al jugador. Una fase sin pregunta es puro trámite._

#### Mecánicas

_Una fila por mecánica. La columna del pilar mantiene a raya cada mecánica: la que no sirve a ningún pilar va a la lista de recortes._

| Mecánica | Qué hace el jugador | Pilar al que sirve | Estado |
| --- | --- | --- | --- |
| [Mecánica] | [...] | [...] | [idea, prototipada, cerrada] |
| [Mecánica] | [...] | [...] | [...] |

#### Controles

_Los verbos del jugador y la sensación que debe transmitir cada uno. La asignación de botones de cada dispositivo está en_ [Interfaz y accesibilidad](https://nodary.ai/es/templates/game-design-document#gdd-interface).

- [Verbo]: [cómo se ejecuta y qué sensación debe transmitir]
- [Verbo]: [...]

#### Progresión

_Qué crece durante una sesión y a lo largo de todo el juego, y cómo ve el jugador que crece. Nombra el objetivo a largo plazo._

- Dentro de una sesión: [...]
- Entre sesiones: [...]
- Objetivo a largo plazo: [...]

#### Desafío y fracaso

_Cómo sube la dificultad, qué cuesta fracasar y cómo vuelve el jugador a la partida. Un fracaso que solo cuesta tiempo enseña menos que uno que cuesta una decisión._

- La dificultad sube mediante: [...]
- Fracasar cuesta: [...]
- Volver a la partida: [...]

_Ejemplo (Saltmarrow, un juego de muestra): Un buceador que sigue en el archivo cuando suena el cuerno pierde los cristales de su zurrón y sale a la superficie en la torre más cercana, pero conserva su sal._

#### Preguntas abiertas

- [ ] [Pregunta], [quién la responde], [para cuándo]

Ver también: [Documento de diseño de juego](https://nodary.ai/es/templates/game-design-document#gdd-overview) · [Sistemas y economía](https://nodary.ai/es/templates/game-design-document#gdd-systems) · [Niveles y contenido](https://nodary.ai/es/templates/game-design-document#gdd-levels)

### Sistemas y economía

**Responsable:** [nombre] · **Estado:** borrador · **Última revisión:** [fecha]

_Cada sistema del juego, las reglas que sigue y los números que hay detrás. Los números cambian cada semana: guárdalos en tablas u hojas de cálculo, y deja aquí el razonamiento._

#### Sistemas

_Una fila por sistema. Un sistema que no alimenta nada es decoración. Un sistema al que todo alimenta es la columna vertebral de tu juego y merece un documento propio._

| Sistema | Qué hace | Lee de | Alimenta a | Responsable |
| --- | --- | --- | --- | --- |
| [Fabricación] | [...] | [Inventario] | [Mejoras] | [nombre] |
| [Sistema] | [...] | [...] | [...] | [...] |

_Ejemplo (Saltmarrow, un juego de muestra): Todos los sistemas leen la marea: el rendimiento de la cosecha, la probabilidad de tormenta, los precios del pueblo e incluso cuánto tiempo está dispuesto a hablar un personaje._

#### Recursos y monedas

_Para cada recurso, de dónde sale (fuentes) y adónde va (sumideros). Una economía con más fuentes que sumideros se infla: rellena las dos columnas antes de ajustar nada._

| Recurso | Fuentes | Sumideros | Límite |
| --- | --- | --- | --- |
| [Oro] | [...] | [...] | [ninguno, o un número] |
| [Recurso] | [...] | [...] | [...] |

#### Recompensas y drop rates

_Tablas de botín, probabilidades de recompensa y cualquier regla de pity. Di qué debe esperar un jugador: cuántos intentos hacen falta para que la mitad de los jugadores consiga un objeto, y para que lo consigan nueve de cada diez. La_ [calculadora de drop rate](https://nodary.ai/es/tools/drop-rate-calculator) _gratuita lo calcula a partir de una tabla de pesos._

| Recompensa | Peso | Probabilidad por intento | Garantizada en |
| --- | --- | --- | --- |
| [Objeto] | [...] | [...] | [nunca, o el intento n] |
| [Objeto] | [...] | [...] | [...] |

#### Parámetros de ajuste

_Los pocos valores que un diseñador cambia para que el juego sea más fácil, más rápido o más generoso, con el valor actual y el rango ya probado. Cuando cambies uno, anota el motivo en el registro de decisiones del_ [plan de producción](https://nodary.ai/es/templates/game-design-document#gdd-production).

| Parámetro | Valor actual | Rango probado | Afecta a |
| --- | --- | --- | --- |
| [...] | [...] | [...] | [...] |

#### Preguntas abiertas

- [ ] [Pregunta], [quién la responde], [para cuándo]

Ver también: [Gameplay](https://nodary.ai/es/templates/game-design-document#gdd-gameplay) · [Niveles y contenido](https://nodary.ai/es/templates/game-design-document#gdd-levels) · [Plan de producción](https://nodary.ai/es/templates/game-design-document#gdd-production)

### Mundo, historia y personajes

**Responsable:** [nombre] · **Estado:** borrador · **Última revisión:** [fecha]

_Las reglas del mundo, la historia que vive el jugador y quienes la habitan. El lore que nunca llega al jugador va en documentos propios, enlazados desde aquí._

#### Ambientación

_Dónde y cuándo, en tres frases, y la regla de este mundo que el jugador nota al jugar._

_Ejemplo (Saltmarrow, un juego de muestra): Una ciudad biblioteca que intentó sobrevivir al mar cultivando sal. Funcionó: la sal conservó los libros y ahogó a los lectores. Dos veces al día, la marea la deja al descubierto._

[Tu ambientación]

#### Tono

_Tres palabras, cada una con un juego, una película o un libro que marque el listón. Después, lo que el tono no es: zanja más discusiones que lo que es._

- Tono: [...]
- Referencias: [...]
- Nunca: [...]

#### Esquema de la historia

_La historia tal como la vive el jugador, momento a momento, no el trasfondo. Anota cómo le llega cada momento: una cinemática, una línea de diálogo, un objeto encontrado, el propio nivel._

| Momento | Qué pasa | Cómo se entera el jugador |
| --- | --- | --- |
| [Inicio] | [...] | [...] |
| [Punto de giro] | [...] | [...] |
| [Final] | [...] | [...] |

#### Personajes

| Personaje | Papel en el juego | Qué quiere | Su voz en una línea |
| --- | --- | --- | --- |
| [Nombre] | [guía, mercader, rival] | [...] | [...] |
| [Nombre] | [...] | [...] | [...] |

_En cuanto un personaje tenga más de unas pocas líneas, dale un documento propio (una ficha, referencias, diálogos de muestra) y enlázalo desde esta tabla._

#### Reglas de escritura

_Las convenciones que sigue todo guionista: nombres y grafías, palabras que este mundo nunca usa, la línea más larga que cabe en pantalla. Si se escriben pronto, le ahorran semanas al equipo de localización._

- [Regla]
- [Regla]

#### Preguntas abiertas

- [ ] [Pregunta], [quién la responde], [para cuándo]

Ver también: [Documento de diseño de juego](https://nodary.ai/es/templates/game-design-document#gdd-overview) · [Niveles y contenido](https://nodary.ai/es/templates/game-design-document#gdd-levels) · [Dirección de arte y audio](https://nodary.ai/es/templates/game-design-document#gdd-art)

### Niveles y contenido

**Responsable:** [nombre] · **Estado:** borrador · **Última revisión:** [fecha]

_Cada lugar al que va el jugador y cada pieza de contenido que necesita el juego, con cuántas hacen falta de cada tipo. Esta lista se convierte en el backlog de producción, así que mantén las cifras honestas._

#### Lugares y niveles

| Lugar o nivel | Función en el juego | Mecánicas principales | Duración | Estado |
| --- | --- | --- | --- | --- |
| [Zona tutorial] | [enseñar el movimiento y el bucle de juego] | [...] | [10 min] | [blockout, pase de arte, final] |
| [Lugar] | [...] | [...] | [...] | [...] |

#### Reglas de diseño de niveles

_Reglas que se cumplen en todos los niveles: cómo se guía al jugador, cada cuánto hay un punto de control, cómo se señalan los secretos. Escríbelas una vez aquí en lugar de en cada nivel._

- [Regla]
- [Regla]

#### La primera hora

_La primera hora del jugador, paso a paso: qué hace, qué aprende y el primer momento que le contaría a un amigo. La mayoría de los jugadores que abandonan, abandonan aquí._

| Minutos | Qué hace el jugador | Qué aprende |
| --- | --- | --- |
| De 0 a 5 | [...] | [...] |
| De 5 a 15 | [...] | [...] |
| De 15 a 60 | [...] | [...] |

#### Presupuesto de contenido

_Cuántas piezas de cada tipo de contenido necesita el primer lanzamiento y quién las hace. Contrástalo con el_ [plan de producción](https://nodary.ai/es/templates/game-design-document#gdd-production) _antes de que nadie empiece a construir._

| Contenido | Cantidad | Hecho por | Notas |
| --- | --- | --- | --- |
| [Niveles o zonas] | [...] | [...] | [...] |
| [Personajes y criaturas] | [...] | [...] | [...] |
| [Objetos] | [...] | [...] | [...] |
| [Líneas de diálogo] | [...] | [...] | [...] |
| [Pistas de música] | [...] | [...] | [...] |

#### Preguntas abiertas

- [ ] [Pregunta], [quién la responde], [para cuándo]

Ver también: [Gameplay](https://nodary.ai/es/templates/game-design-document#gdd-gameplay) · [Mundo, historia y personajes](https://nodary.ai/es/templates/game-design-document#gdd-world) · [Plan de producción](https://nodary.ai/es/templates/game-design-document#gdd-production)

### Dirección de arte y audio

**Responsable:** [nombre] · **Estado:** borrador · **Última revisión:** [fecha]

_Cómo se ve y cómo suena el juego, con la precisión suficiente para que dos artistas que trabajan por separado produzcan piezas que encajen._

#### Reglas visuales

_De tres a cinco reglas sobre forma, color, luz y detalle. «Estilizado» no es una regla; «toda silueta se lee a treinta metros», sí._

- [Regla]
- [Regla]
- [Regla]

#### Referencias

_Añade imágenes de referencia bajo cada regla y di qué tomar de cada una: la paleta, la luz, las formas. Nunca «todo»._

| Referencia | Qué tomamos | Qué evitamos |
| --- | --- | --- |
| [Imagen o juego] | [...] | [...] |
| [Imagen o juego] | [...] | [...] |

#### Paleta

| Uso | Color | Notas |
| --- | --- | --- |
| [Fondo] | [#hex] | [...] |
| [Peligro] | [#hex] | [nunca la única forma de señalar el peligro] |

#### Familias de assets

_Qué tiene en común cada familia de assets, su presupuesto (polígonos, tamaño de textura, fotogramas) y quién la aprueba._

| Familia | Notas de estilo | Presupuesto | Aprobado por |
| --- | --- | --- | --- |
| [Personajes] | [...] | [...] | [...] |
| [Entornos] | [...] | [...] | [...] |
| [Props] | [...] | [...] | [...] |
| [Efectos] | [...] | [...] | [...] |

#### Audio

_El carácter de la música, los efectos de sonido y las voces, y la información de juego que transmite el sonido: avisos, recompensas, el paso del tiempo._

- Música: [...]
- Efectos de sonido: [...]
- Voces: [idiomas y número de líneas, o ninguna]
- Información que transmite el sonido: [...]

_Ejemplo (Saltmarrow, un juego de muestra): Dos minutos antes de que cambie la marea, suena un cuerno sobre las salinas. La marea se ve en pantalla, se oye en la mezcla y se siente en el mando._

#### Revisiones

_Quién aprueba el arte y el audio, y cuándo. Deja los comentarios sobre la propia imagen, fijados en el punto al que se refieren: te ahorra una ronda de «¿cuál, la de la izquierda?»_

- Aprueba el arte: [...]
- Aprueba el audio: [...]

#### Preguntas abiertas

- [ ] [Pregunta], [quién la responde], [para cuándo]

Ver también: [Mundo, historia y personajes](https://nodary.ai/es/templates/game-design-document#gdd-world) · [Interfaz y accesibilidad](https://nodary.ai/es/templates/game-design-document#gdd-interface)

### Interfaz y accesibilidad

**Responsable:** [nombre] · **Estado:** borrador · **Última revisión:** [fecha]

_Todo lo que el jugador lee, pulsa y recorre, y cómo se adapta el juego a quienes ven, oyen o se mueven de otra manera._

#### Pantallas y flujo

_Cada pantalla y cómo pasa el jugador de una a otra, desde que abre el juego hasta que lo cierra. Un diagrama encuentra los callejones sin salida antes de que se construyan._

```mermaid
flowchart LR
  n0["Pantalla de título"]
  n1["Menú principal"]
  n2["Jugar"]
  n3["Opciones"]
  n4["Pausa"]
  n0 --> n1
  n1 --> n2
  n1 --> n3
  n2 --> n4
  n4 --> n2
  n4 --> n1
```
_Flujo de pantallas_

#### HUD

_Lo que se queda en pantalla durante la partida y por qué cada elemento se gana su sitio. Lo que el jugador consulta menos de una vez por minuto puede ir en un menú._

| Elemento | Muestra | Cuándo es visible | Prioridad |
| --- | --- | --- | --- |
| [Salud] | [...] | [siempre, en combate, a petición] | [alta, media, baja] |
| [Elemento] | [...] | [...] | [...] |

#### Asignación de controles

| Acción | Teclado y ratón | Mando | Táctil |
| --- | --- | --- | --- |
| [Moverse] | [WASD] | [Stick izquierdo] | [...] |
| [Interactuar] | [E] | [A / Cruz] | [...] |
| [Pausa] | [Esc] | [Start / Options] | [...] |

#### Accesibilidad

_Marca cada punto o escribe por qué no aplica. Si se deciden pronto, la mayoría cuesta poco; si se añaden tarde, cuestan mucho._

- [ ] Todos los controles se pueden reasignar
- [ ] Las acciones de mantener pulsado pueden pasar a modo alternar
- [ ] Los subtítulos indican quién habla y su tamaño se puede cambiar
- [ ] Los sonidos importantes también tienen una señal visual
- [ ] Ninguna información se transmite solo con el color
- [ ] El texto se puede agrandar
- [ ] Los temporizadores se pueden ralentizar o desactivar
- [ ] El temblor de cámara y los destellos se pueden reducir

#### Textos e idiomas

_Los idiomas de lanzamiento y las reglas que hacen posible la traducción: ningún texto incrustado en imágenes, espacio para textos hasta un tercio más largos que en inglés, fuentes que cubran todos los alfabetos en los que salga el juego._

- Idiomas de lanzamiento: [...]
- Idiomas posteriores: [...]
- Fuentes: [...]

#### Preguntas abiertas

- [ ] [Pregunta], [quién la responde], [para cuándo]

Ver también: [Gameplay](https://nodary.ai/es/templates/game-design-document#gdd-gameplay) · [Dirección de arte y audio](https://nodary.ai/es/templates/game-design-document#gdd-art) · [Diseño técnico](https://nodary.ai/es/templates/game-design-document#gdd-technical)

### Diseño técnico

**Responsable:** [nombre] · **Estado:** borrador · **Última revisión:** [fecha]

_Las decisiones técnicas que dan forma al diseño y los límites que el diseño debe respetar. La arquitectura detallada puede vivir en documentos de ingeniería enlazados desde aquí._

#### Motor y herramientas

| Elección | Decisión | Por qué |
| --- | --- | --- |
| Motor | [Motor y versión] | [...] |
| Lenguajes de programación | [...] | [...] |
| Control de versiones | [...] | [...] |
| Builds y distribución | [...] | [...] |

#### Objetivos y presupuestos

_Las cifras con las que trabaja cada departamento. Sin ellas, los problemas de rendimiento se descubren al final._

| Plataforma | Fotogramas por segundo | Resolución | Memoria | Tiempo de carga | Tamaño de instalación |
| --- | --- | --- | --- | --- | --- |
| [PC, requisitos mínimos] | [...] | [...] | [...] | [...] | [...] |
| [Consola] | [...] | [...] | [...] | [...] | [...] |

#### Arquitectura

_Las partes principales del código del juego y cómo se comunican entre sí. Un diagrama de cinco cajas vale más que cinco páginas de prosa._

```mermaid
flowchart TD
  n0["Entrada"]
  n1["Estado del juego"]
  n2["Renderizado"]
  n3["Audio"]
  n4["Guardado"]
  n0 --> n1
  n1 --> n2
  n1 --> n3
  n1 --> n4
```
_Sistemas principales_

#### Guardado y juego en línea

- Guardado: [qué se guarda, cuándo y dónde]
- En línea: [nada, P2P, servidores dedicados]
- Datos de los jugadores: [qué se recoge y dónde se guarda]

#### Pipeline

_Cómo pasa un asset o una línea de texto de su autor a una build jugable, y cuánto tarda. Un pipeline lento recorta en silencio el número de iteraciones de un equipo._

[Tu pipeline]

#### Riesgos técnicos

| Riesgo | Impacto | Qué hacemos al respecto | Responsable |
| --- | --- | --- | --- |
| [...] | [...] | [...] | [...] |

#### Preguntas abiertas

- [ ] [Pregunta], [quién la responde], [para cuándo]

Ver también: [Interfaz y accesibilidad](https://nodary.ai/es/templates/game-design-document#gdd-interface) · [Plan de producción](https://nodary.ai/es/templates/game-design-document#gdd-production)

### Plan de producción

**Responsable:** [nombre] · **Estado:** borrador · **Última revisión:** [fecha]

_Cuándo sale el juego, quién lo hace, qué podría frenarlo y cada decisión tomada por el camino._

#### Hitos

| Hito | Fecha | Meta | Cumplido cuando |
| --- | --- | --- | --- |
| [Prototipo] | [...] | [el bucle de juego es divertido] | [...] |
| [Vertical slice] | [...] | [un nivel con calidad final] | [...] |
| [Alpha] | [...] | [todas las funcionalidades dentro, aunque sea en bruto] | [...] |
| [Beta] | [...] | [todo el contenido dentro, solo correcciones] | [...] |
| [Lanzamiento] | [...] | [...] | [...] |

_«Cumplido cuando» es la columna que la gente se salta. Sin ella, un hito no es más que una fecha._

#### Equipo

| Rol | Persona | Responsable de estos documentos |
| --- | --- | --- |
| [Dirección creativa] | [nombre] | [Documento de diseño de juego, Gameplay] |
| [Rol] | [nombre] | [...] |

#### Riesgos

| Riesgo | Probabilidad | Impacto | Qué hacemos al respecto | Responsable |
| --- | --- | --- | --- | --- |
| [...] | [baja, media, alta] | [bajo, medio, alto] | [...] | [...] |

#### Registro de decisiones

_Cada decisión que cambia el diseño: qué se decidió, quién lo decidió, por qué y qué documento cambió. Seis meses después, cuando alguien pregunte por qué funciona así, esta tabla responde._

| Fecha | Decisión | Decidido por | Por qué | Documento modificado |
| --- | --- | --- | --- | --- |
| [fecha] | [...] | [...] | [...] | [...] |

_Ejemplo (Saltmarrow, un juego de muestra): 12 de septiembre: sin combate, la amenaza viene solo de la marea y de las tormentas. Decidido por la dirección creativa y el diseñador de sistemas, para que el juego siga siendo tranquilo y su cuenta atrás, implacable. Documento modificado: los pilares de diseño._

#### Preguntas abiertas

- [ ] [Pregunta], [quién la responde], [para cuándo]

Ver también: [Documento de diseño de juego](https://nodary.ai/es/templates/game-design-document#gdd-overview) · [Niveles y contenido](https://nodary.ai/es/templates/game-design-document#gdd-levels) · [Diseño técnico](https://nodary.ai/es/templates/game-design-document#gdd-technical)

## Cómo usarla

### Escribe la visión general de una sentada

Rellena primero la tabla, el pitch y los pilares, en más o menos una hora, con las personas que van a hacer el juego. Todas las demás páginas se miden con ellos.

### Completa las partes a medida que decides

Deja una sección vacía antes que inventarla. Una sección vacía es una pregunta abierta y honesta; una inventada acaba construyéndose.

### Registra cada decisión

Cuando una decisión cambie el diseño, añade una línea al registro de decisiones del plan de producción y actualiza la página afectada. El registro dice por qué; la página dice lo que es cierto hoy.

### Dale un responsable a cada página

Cada parte indica su responsable y la fecha de su última revisión. Una página sin responsable es la primera en quedarse desfasada.

## Impórtala en Nodary como un mapa

Nodary es un espacio de trabajo para equipos de videojuegos donde los documentos se enlazan como estrellas en un mapa. Importa el .zip y la visión general llega con sus ocho partes ordenadas debajo, los enlaces entre páginas intactos y los diagramas dibujados. Después, tu equipo comenta pasajes, solicita revisiones y ve qué cambió desde su última visita, y los agentes de IA conectados por MCP leen el diseño antes de escribir en él.

1. Abre el mapa de un proyecto y elige «Importar».
2. Elige la pestaña «Carpeta o ZIP» y después «Elegir un ZIP».
3. Selecciona el archivo descargado, revisa el árbol e importa.

El plan Free admite diez documentos por espacio de trabajo, incluida la página del propio proyecto: los nueve de la plantilla caben en un espacio de trabajo nuevo y lo llenan. Los planes de pago tienen sitio para más.

## Cómo escribir un GDD que la gente lea de verdad

Un documento de diseño de juego fracasa de dos maneras: nadie lo lee, o todos leen una versión antigua. Estos hábitos evitan las dos.

### Una página por parte

Un archivo de sesenta páginas se lee una vez, al principio. Las páginas cortas y enlazadas se leen cuando hacen falta, y un cambio toca una página en lugar de cinco.

### Escribe decisiones, no deseos

«El combate tiene que sentirse bien» no decide nada. «Un golpe impacta menos de 100 milisegundos después de pulsar el botón» se puede construir y probar.

### Di qué sigue abierto

Marca como abiertas las preguntas sin respuesta, con quién las responde y para cuándo. Basta una suposición escrita como un hecho para que dos departamentos acaben construyendo dos juegos distintos.

### Enlaza, nunca copies

Cuando la página de la economía necesite los horarios de las mareas, que enlace con ellos. Un dato escrito en dos sitios pronto dice dos cosas distintas.

### Conserva el porqué

El registro de decisiones guarda por qué las cosas son como son, para que alguien recién llegado no deshaga una elección que el equipo ya pagó.

### Recorta lo que nadie lee

Si nadie ha abierto una sección desde que se escribió, fusiónala o bórrala. Un documento corto que es cierto vale más que uno largo que lo fue.

## Preguntas sobre el documento de diseño de juego

### ¿Qué es un documento de diseño de juego?

Un documento de diseño de juego, o GDD (game design document), describe el juego que hace un equipo: su pitch, sus pilares, mecánicas, sistemas, mundo, niveles, imagen y sonido, y el plan para construirlo. Lo leen diseñadores, artistas, programadores, productores y, cada vez más, agentes de IA, así que tiene que mantenerse al día mientras el juego cambia.

### ¿Qué debe incluir un documento de diseño de juego?

Como mínimo, una visión general de una página con el pitch, los pilares, el público y el alcance; el gameplay y el bucle de juego; los sistemas y sus números; el mundo y la historia; los niveles y el contenido; la dirección de arte y de audio; la interfaz y la accesibilidad; las restricciones técnicas; y un plan de producción con un registro de decisiones. Esta plantilla tiene un documento para cada uno.

### ¿Qué extensión debe tener un GDD?

La mínima que siga respondiendo a las preguntas del equipo. La visión general debería caber en una pantalla. Cada parte crece con las decisiones tomadas, no con las ilusiones: una página de reglas cerradas vale más que diez de posibilidades.

### ¿Los equipos indie y ágiles siguen necesitando un GDD?

Necesitan las decisiones por escrito, no una biblia redactada de antemano. Los equipos que iteran rápido usan el GDD como constancia de lo que el juego es hoy: páginas cortas, actualizadas cuando un playtest cambia algo, con los motivos guardados en el registro de decisiones.

### ¿En qué formato está la plantilla?

En Markdown: archivos de texto plano que abre cualquier editor. Los enlaces entre documentos son enlaces relativos, las tablas son tablas Markdown y los diagramas son Mermaid, que GitHub, Obsidian y Nodary dibujan. Nada depende de una herramienta concreta.

### ¿Puedo usarla en Obsidian, en GitHub o en otro editor?

Sí. Obsidian abre la carpeta descomprimida como un vault con todos los enlaces funcionando, y GitHub muestra los archivos con sus enlaces y diagramas. Las herramientas que importan Markdown archivo por archivo conservan el texto y las tablas; comprueba cómo tratan los enlaces entre archivos.

### ¿Cómo importo la plantilla en Nodary?

Abre el mapa de un proyecto, elige «Importar», luego la pestaña «Carpeta o ZIP», y elige el .zip descargado. Nodary muestra primero el árbol y después crea los nueve documentos con la visión general como documento padre, conserva los enlaces entre ellos y dibuja los diagramas. Cualquier carpeta o .zip de hasta 200 archivos Markdown se importa igual.

### ¿Puedo usar la plantilla para un juego comercial?

Sí. Úsala, modifícala y compártela para cualquier juego, comercial o no, con o sin cuenta de Nodary. Se agradece una mención, pero nunca es obligatoria.

La página: https://nodary.ai/es/templates/game-design-document