Un GDD (Game Design Document) es el documento donde escribís cómo es tu juego: qué se hace, cómo se siente, qué sistemas tiene, por qué. Sirve para que todo el equipo apunte al mismo lado y para no olvidarte de cosas que decidiste hace tres meses. No hay formato oficial. Hay GDDs que son PDFs de 80 páginas y otros que viven en una sola página de Notion. Lo que importa no es el formato: es que vos y tu equipo estén tomando decisiones reales mientras lo escriben.
Lo que vas a sacar de esta guía
- →Qué es un GDD y para qué sirve realmente
- →Las secciones mínimas que necesita el tuyo
- →Plantilla práctica para juego solo o equipo chico
- →Errores comunes al armar el primer GDD
- →Cuándo conviene un one-page GDD y cuándo no
Descargá la plantilla GDD
15 secciones listas para llenar (pitch, pilares, core loop, sistemas, scope, riesgos). Editable en Word, Google Docs o cualquier editor de Markdown. Gratis, sin registro.
¿Qué es un GDD?
GDD significa Game Design Document. Es la descripción escrita de tu juego: la mecánica principal, los sistemas, el control, los enemigos, los niveles, la progresión, el arte, el audio, la narrativa. Lo escribe el game designer (o el dev solo) y lo lee todo el equipo.
Para qué sirve de verdad
La función del GDD no es "documentar el juego". Es forzarte a decidir antes de programar. Cuando te sentás a describir el sistema de combate en palabras, ahí saltan los huecos que tu idea tenía cuando solo estaba en tu cabeza. Lo cual es buenísimo: cuesta menos cambiar un párrafo que tirar dos semanas de código.
Lo que un GDD NO es
- No es un contrato cerrado. Va a cambiar muchas veces durante el desarrollo.
- No es una novela. No describas cada detalle del lore en 50 páginas.
- No es un pitch. Esos son documentos distintos (one-pager, deck).
- No tiene que ser bonito. Tiene que ser útil para vos y tu equipo.
¿Hace falta un GDD si trabajo solo?
Sí, pero no necesitás 80 páginas. Aunque seas vos solo, escribir te ayuda a pensar mejor. Lo que cambia es el formato:
| Situación | Formato recomendado | Tamaño |
|---|---|---|
| Solo, juego chico | One-page GDD o página de Notion | 1 a 3 páginas |
| Equipo de 2 a 4 | Doc compartido (Notion, Google Docs) | 5 a 15 páginas |
| Equipo de 5 a 10 | GDD modular + wiki interna | 20 a 50 páginas |
| Estudio mediano | GDD principal + docs por sistema | 50+ páginas |
| Pitch a publisher | Pitch deck + one-pager (no GDD) | 10 a 20 slides |
Secciones mínimas de un GDD
No hay un estándar oficial de la industria. Cada estudio arma su propia plantilla. Pero hay un núcleo de secciones que casi siempre aparece. Estas son las que recomiendo si estás armando el tuyo desde cero:
| Sección | Para qué sirve | Tamaño típico |
|---|---|---|
| 1. Resumen / pitch | Una idea clara en 2 a 3 párrafos | 1 página |
| 2. Objetivo del juego | Qué hace el jugador y por qué | ½ página |
| 3. Mecánica principal | La acción central, repetida una y otra vez | 1 a 2 páginas |
| 4. Sistemas | Combate, progresión, economía, inventario | 2 a 5 páginas |
| 5. Personajes y enemigos | Stats, comportamiento, diseño | 1 a 3 páginas |
| 6. Niveles / mundo | Estructura del mapa, progresión | 1 a 3 páginas |
| 7. Arte y estética | Estilo visual, paleta, referencias | 1 a 2 páginas |
| 8. Audio | Música, SFX, voz | ½ a 1 página |
| 9. UI / UX | HUD, menús, controles | 1 a 2 páginas |
| 10. Plataformas y target | Para quién es, dónde se vende | ½ página |
Plantilla práctica (one-page extendido)
Esta es la plantilla que recomiendo para indie solo o equipo chico. Cubre lo importante sin que sea un libro. Llenala en este orden:
Pitch en una frase
Una sola frase que describa tu juego. Ejemplo: "Roguelike 2D donde el héroe pierde un órgano por cada muerte". Si no podés condensar tu juego en una frase, todavía no sabés qué juego estás haciendo.
Pilares de diseño (3 a 5)
Los pilares son las palabras o frases que guían todas las decisiones. Cuando dudes si agregar algo o no, mirás los pilares y decidís. Ejemplos: "Tensión constante", "Cada muerte enseña algo", "Soledad opresiva".
Mecánica principal (core loop)
El bucle que el jugador repite todo el juego. Ejemplo en un roguelike: elegir camino → pelear → recolectar items → mejorar → morir → empezar de nuevo. Describilo en 5 a 8 pasos. Si no se entiende solo, replanteá.
Controles y feel
Lista de inputs y qué hacen. Pero más allá de "A para saltar": anotá coyote time, buffer de input, cancelaciones, qué se siente al apretar el botón. El feel es la mitad del juego. Si te inspirás en Hollow Knight, decilo así: "tipo Hollow Knight pero con dash a 4 direcciones". No vas a copiar, vas a comunicar rápido.
Sistemas
Cada sistema en una mini-sección de 1 a 5 párrafos. Combate, progresión, economía, inventario, crafteo. Para cada uno: qué hace, cómo se gana, cómo se pierde, cómo se siente.
Estructura del mundo
Cómo está organizado el mapa: lineal, hub, mundo abierto, niveles separados. Cuántas zonas o niveles tiene. Qué cambia entre cada uno (enemigos, mecánicas, estética).
Estética y referencias
Pegá imágenes. No describas el arte con palabras: mostrá referencias. Mood board con 6 a 12 imágenes vale más que 3 párrafos sobre "atmósfera melancólica".
Scope
Cuántas horas de gameplay, cuántos niveles, cuántos enemigos, cuántas armas. Tener números explícitos te ayuda a no agregar contenido sin pensarlo.
Plataforma y target
Dónde se va a jugar (Steam, mobile, consolas) y para quién es. Si es Steam, fijate qué etiquetas le ponés y a qué juego se parece.
Errores comunes al armar el primer GDD
Empezar por el lore
Describir 30 páginas de mundo, historia y personajes antes de tener la mecánica clara. El lore puede esperar; la mecánica no.
Ser demasiado vago
"Combate divertido y satisfactorio" no es diseño. Es marketing. Necesitás describir cómo funciona, no cómo se siente en abstracto.
No escribir scope
Si no decidís cuánto contenido tiene tu juego, vas a estar agregando para siempre. Los números explícitos son un freno saludable.
Tratar el GDD como sagrado
Va a cambiar muchas veces. No te frustres cuando descartes una sección entera tras un playtest. Es lo esperable.
Sobre-documentar
Escribir 80 páginas para un juego de 6 meses es procrastinación con buena estética. Documentá lo que tu equipo realmente va a leer.
No pegar referencias
Sin imágenes y sin links a juegos similares, el doc queda abstracto. Una imagen vale más que 3 párrafos descriptivos.
¿En qué herramienta lo escribo?
Casi cualquiera sirve. Lo importante es que tu equipo pueda leer y editar al mismo tiempo. Estas son las opciones más comunes en estudios indie:
| Herramienta | Mejor para | Notas |
|---|---|---|
| Notion | Equipos chicos a medianos | Bases de datos para enemigos, items, niveles |
| Google Docs | Equipos chicos, comentarios rápidos | Edición simultánea, fácil compartir |
| Confluence | Estudios medianos a grandes | Wiki seria, integración con Jira |
| Markdown en repo | Equipos técnicos | Versionado con git, queda en el repo del juego |
| Miro / FigJam | Diagramas, mapas, flowcharts | Bueno para core loop visual |
Si querés profundizar más
El GDD es la parte que se escribe. Atrás hay decisiones de game design que conviene tener masticadas antes. Si querés entrar a esos conceptos sin pagar nada, el curso gratis de Game Design de Codearte es el atajo más corto en español que conozco para llegar a un GDD que sirva de verdad.
Curso gratis de Game Design
19 lecciones, 1h 58m. Cubre MDA, level design, feedback loops, balance. Para que tu GDD tenga buenas decisiones de diseño detrás.
Ver el curso gratisSi estás definiendo el alcance de tu primer juego, también te puede ayudar la guía de cuánto tarda hacer un videojuego para no escribir un GDD imposible para tu tiempo disponible.
Preguntas Frecuentes
¿Qué es un GDD?
GDD significa Game Design Document. Es el documento que describe cómo funciona tu juego: mecánica, sistemas, niveles, personajes, arte, audio. Sirve para alinear al equipo y obligarte a tomar decisiones antes de programar.
¿Existe una plantilla oficial de GDD?
No. Cada estudio usa su propio formato. Lo común es que cubra: pitch, mecánica core, sistemas, personajes, niveles, arte, audio, UI y plataforma. El tamaño depende del juego y el equipo.
¿Cuánto debe tener un GDD?
Para indie solo: 1 a 3 páginas (one-pager). Equipo de 2 a 4: 5 a 15 páginas. Estudios medianos: 20 a 50. Más que el tamaño importa que esté actualizado y que tu equipo lo lea.
¿El GDD se puede modificar después?
Sí, va a cambiar muchas veces. Después de cada playtest, prototipo o feedback de jugadores tiene sentido revisarlo. Tratalo como un documento vivo, no como un contrato.
¿Qué diferencia hay entre GDD y pitch deck?
El GDD es interno: lo lee tu equipo para construir el juego. El pitch deck es externo: lo usás para venderle el proyecto a un publisher o inversor. Son documentos distintos con audiencias y objetivos distintos.
¿Necesito GDD si trabajo solo?
Sí, pero corto. Un one-pager o página de Notion alcanza. Aunque seas vos solo, escribir te obliga a decidir cosas que en la cabeza eran ambiguas. Cuesta menos modificar texto que código.
¿Querés feedback sobre tu GDD? Subilo al Discord de Codearte y lo revisamos.
Más contenido de game design en el canal de YouTube.
¿Quieres crear tus propios juegos?
Aprende a programar videojuegos desde cero con nuestros cursos en Unity. Más de 3,000 estudiantes ya empezaron su camino.
Ver cursos gratuitos
