Guía maestra de desarrollo de videojuegos

00Cómo usar esta guía

0.1 Los tres documentos

0.2 Principios rectores

1. Encontrar la diversión antes de escalar. Ningún volumen de contenido arregla un núcleo jugable que no funciona. El dinero grande se gasta después de demostrar el core loop.
2. Reducir riesgo en el orden correcto. Primero el riesgo de diseño (¿es divertido?), luego el técnico (¿se puede construir?), luego el de producción (¿se puede construir a escala, a tiempo y en presupuesto?), luego el de mercado (¿lo va a comprar alguien?).
3. Decisiones por puertas (stage-gates). Cada fase termina con una revisión formal con criterios objetivos. Se aprueba, se repite o se cancela. Cancelar pronto es un éxito de gestión, no un fracaso.
4. Documentación mínima suficiente, siempre actualizada. Un GDD de 400 páginas que nadie lee es peor que una wiki de 40 páginas que todos consultan. El documento sirve al equipo, no al revés.
5. Pilares como filtro. Cada feature, asset o línea de diálogo debe servir a los pilares de diseño. Lo que no los sirve se corta.
6. El jugador decide. Playtests tempranos y frecuentes con jugadores reales del público objetivo. La opinión del equipo no sustituye a la evidencia.
7. Calidad y sostenibilidad. Planificar contingencia (15–25 %) para no depender del crunch. Un equipo quemado produce peor juego y pierde talento.
8. Diseñar para todo el ciclo de vida. Localización, accesibilidad, telemetría, guardado, plataformas y live ops se diseñan desde el día uno; añadirlos al final cuesta entre 3 y 10 veces más.

0.3 Glosario rápido de fases

Concepto → Preproducción (prototipos) → Vertical slice → Producción (First Playable, Alpha, Beta) → Postproducción (pulido, certificación, Gold) → Lanzamiento → Live ops → Fin de vida.

01Mapa del ciclo de vida

1.1 Fases, objetivos y duración orientativa (AAA)

Un juego indie o AA comprime estas fases (concepto de semanas, preproducción de 2–6 meses), pero no se salta ninguna: solo cambia la escala de cada entregable.

1.2 Hitos (milestones) estándar de la industria

1.3 Puertas de aprobación (stage-gates) y sus criterios

Cada puerta la preside un comité de greenlight (dirección del estudio, publisher o inversor, dirección creativa, técnica, de producción, marketing y finanzas). Resultado posible: Aprobar, Aprobar con condiciones, Repetir fase o Cancelar.

Puerta 0 → Concepto aprobado

• High concept y pilares claros y diferenciados.
• Público objetivo definido y validado con datos de mercado.
• Análisis competitivo: dónde encaja, qué lo hace distinto.
• Hipótesis de modelo de negocio y rango de presupuesto.
• Riesgos principales identificados.
• Equipo núcleo disponible.

Puerta 1 → Fin de prototipos

• El core loop se ha demostrado divertido en playtests con externos.
• Los 3–5 riesgos técnicos principales tienen respuesta (prototipo o investigación).
• Elección de motor y arquitectura justificada.

Puerta 2 → Greenlight a producción (tras Vertical Slice)

• Vertical slice a calidad final, jugada por gente ajena al equipo con resultados positivos.
• GDD, TDD, biblias de arte/audio/narrativa en versión 1.0.
• Pipelines de contenido probados (se sabe cuánto cuesta producir un nivel, un personaje, un minuto de cinemática).
• Plan de producción con estimaciones basadas en esos costes reales.
• Presupuesto, calendario, plan de contratación y outsourcing.
• Plan de negocio y de marketing preliminar.
• Registro de riesgos con mitigaciones.

Puerta 3 → Alpha: feature complete, rendimiento dentro de un margen razonable del objetivo, todas las plataformas arrancan el juego.

Puerta 4 → Beta: content complete, sin bugs bloqueantes conocidos de larga duración, localización en curso, plan de certificación.

Puerta 5 → Gold / Go-live: certificación aprobada, cero bugs de severidad A/bloqueante, infraestructura probada bajo carga, plan de lanzamiento y soporte listo.

02Fase de concepto e ideación

2.1 Objetivo

Convertir una idea en una propuesta de producto defendible ante un comité: qué es, para quién, por qué ahora, por qué nosotros, cuánto cuesta y qué puede salir mal.

2.2 Elementos que hay que definir

2.3 Herramientas de ideación

• Brainstorming estructurado: generar 20–50 ideas, filtrar por pilares, combinar.
• Matriz de evaluación de conceptos: puntuar cada concepto por originalidad, viabilidad, tamaño de mercado, encaje con el estudio, coste, riesgo.
• MDA (Mechanics–Dynamics–Aesthetics): diseñar de la experiencia deseada (estética) hacia las mecánicas.
• Game jams internas: 48–72 h para probar conceptos jugables.
• Paper prototyping: probar reglas con papel, cartas y dados antes de tocar el ordenador.
• Análisis de mercado: SteamDB, Gamalytic, VG Insights, Sensor Tower, data.ai, Newzoo, Circana, informes de plataformas.
• Encuestas y entrevistas a jugadores del público objetivo.

2.4 Entregables del concepto

1. One-pager (1 página): título, high concept, pilares, público, plataformas, comps, imagen clave.
2. Concept document (5–20 páginas): todo lo anterior desarrollado.
3. Pitch deck (10–20 diapositivas) para el comité o el publisher.
4. Concept art y key art inicial: 3–10 imágenes que venden el tono.
5. Mood boards visual y sonoro.
6. Prototipo en papel o de juguete (opcional, muy recomendable).
7. Análisis de mercado y competencia.
8. Registro de riesgos inicial.
9. Estimación de alto nivel de coste, equipo y plazos.

2.5 Estructura típica del pitch deck

1. Título y key art · 2. High concept · 3. Fantasía del jugador · 4. Pilares · 5. Core loop · 6. Qué lo hace único (USP) · 7. Público y mercado · 8. Comparables y posicionamiento · 9. Mundo y narrativa · 10. Estilo visual · 11. Modelo de negocio · 12. Plataformas · 13. Equipo · 14. Plan y presupuesto · 15. Riesgos y mitigación · 16. Lo que se pide (the ask).

03Preproducción: el corazón de la guía

3.1 Objetivo

Eliminar la incertidumbre antes de gastar el grueso del dinero. Al final de la preproducción el equipo debe saber qué va a construir (diseño), cómo (tecnología y pipelines), cuánto cuesta cada pieza (métricas de producción reales) y con quién (plan de equipo).

3.2 Flujos de trabajo en paralelo

3.3 Prototipado: tipos y propósito

Reglas del prototipado: cada prototipo tiene una pregunta escrita antes de empezar y un criterio de éxito; se tira el código del prototipo (no se "reutiliza" en producción sin reescribirlo); se juega con gente externa; se documenta la conclusión.

3.4 Vertical slice frente a horizontal slice

• Vertical slice: una porción pequeña del juego a calidad final en todas las capas (arte, audio, UI, narrativa, rendimiento). Demuestra que se puede alcanzar el listón y sirve para medir costes reales de producción. Suele usarse también como demo para publisher o anuncio.
• Horizontal slice: todo el juego de principio a fin en baja fidelidad (greybox). Demuestra la estructura completa, el ritmo y la progresión. Muy recomendable antes de producción en juegos con historia o progresión larga.

Lo ideal en AAA es tener ambos antes del greenlight a producción.

3.5 Métricas de producción (lo que hace posible planificar)

Durante el vertical slice se cronometran y documentan los costes unitarios:

• Días-persona por personaje principal, secundario, NPC genérico.
• Días-persona por prop pequeño, mediano, héroe.
• Días-persona por metro cuadrado de entorno o por nivel/misión.
• Días-persona por minuto de cinemática (previs, mocap, limpieza, iluminación).
• Coste por línea de VO por idioma.
• Coste por palabra de localización.
• Coste por animación de gameplay.
• Velocidad del equipo (puntos de historia por sprint).

Con estos datos, el plan de producción deja de ser una suposición: unidades de contenido × coste unitario × factor de riesgo.

04Documentación de diseño

4.1 El ecosistema documental

4.2 Índice completo de un GDD AAA

1. Visión: high concept, fantasía del jugador, pilares, USP, público, plataformas, experiencia objetivo.
2. Resumen del juego: descripción narrativa de una sesión típica de juego ("un día en la vida del jugador").
3. Loops de juego: core loop (segundos), loop secundario (minutos), meta loop (horas/días/semanas). Diagramas.
4. Mecánicas: cada acción del jugador con reglas, inputs, feedback, estados.
5. Controles: esquemas por plataforma, remapeo, sensibilidades.
6. Cámara: modos, comportamiento, colisiones, opciones.
7. Personaje del jugador: atributos, habilidades, estados, customización.
8. Sistemas: combate, IA, físicas, crafting, inventario, diálogo, relaciones, simulación, clima, día/noche, etc. (cada uno con su spec).
9. Progresión: niveles, XP, árboles de habilidad, desbloqueos, curvas.
10. Economía: monedas, fuentes, sumideros, precios, inflación, simulación.
11. Mundo y niveles: estructura (lineal, hub, mundo abierto), lista de niveles/zonas, ritmo global.
12. Narrativa: resumen de la historia, estructura, personajes (referencia a la biblia narrativa).
13. Misiones y contenido: tipos de misión, lista, actividades secundarias, coleccionables.
14. IA: comportamientos de enemigos, aliados, NPCs, sistemas sociales.
15. Dificultad y balance: modos de dificultad, ajuste dinámico, curvas.
16. Onboarding / FTUE: primera hora de juego, tutoriales, enseñanza progresiva.
17. UI/UX: HUD, menús, flujos (referencia a guía de UX).
18. Multijugador y social: modos, matchmaking, coop, competitivo, clanes, chat, moderación.
19. Monetización: modelo, tienda, ofertas, pase de batalla, ética y regulación.
20. Live ops: temporadas, eventos, cadencia de contenido.
21. Accesibilidad: lista de opciones.
22. Audio (resumen funcional; referencia a biblia de audio).
23. Telemetría: eventos a registrar, KPIs de diseño.
24. Guardado: qué se guarda, cuándo, nube, slots.
25. Requisitos de plataforma que afectan al diseño (logros/trofeos, actividades, suspensión).
26. Lista de features priorizada (MoSCoW: Must / Should / Could / Won't).
27. Glosario del proyecto.
28. Registro de cambios y decisiones.

4.3 Plantilla de spec de feature

FEATURE: [nombre]                  Propietario: [diseñador]   Estado: [borrador/revisión/aprobada/implementada]

1. Objetivo: qué problema resuelve y qué pilar sirve
2. Experiencia del jugador: qué siente, en una frase
3. Descripción: reglas completas
4. Flujo: pasos, estados, diagrama
5. Casos límite y errores
6. Parámetros ajustables (tuning) y valores iniciales
7. UI/UX: wireframes, feedback visual y sonoro
8. Arte, animación, audio y VO necesarios (lista de assets)
9. Dependencias técnicas y con otras features
10. Telemetría: eventos y KPIs
11. Accesibilidad y localización
12. Criterios de aceptación (Definition of Done)
13. Riesgos y preguntas abiertas
14. Estimación por disciplina

05Diseño de juego en detalle

5.1 Capas del diseño

5.2 Especialidades de diseño

• Diseño de sistemas: reglas generales, simulación, balance, economía.
• Diseño de combate: armas, habilidades, enemigos, encuentros.
• Diseño de niveles: espacios, flujo, ritmo, encuentros, guía del jugador (wayfinding).
• Diseño de misiones (quest design): estructura de objetivos, ramificaciones, recompensas.
• Diseño narrativo: integración de historia y jugabilidad.
• Diseño de economía: monedas, precios, monetización.
• Diseño de progresión: curvas y desbloqueos.
• Diseño de UX: usabilidad, flujos, comprensión.
• Diseño técnico (technical design): scripting, herramientas para diseñadores, implementación de lógica.
• Diseño de IA: comportamientos y percepción.
• Diseño de monetización: ofertas, tienda, pase de temporada, con criterios éticos.
• Diseño de live ops: eventos y temporadas.

5.3 Balance y economía

• Modelar la economía con fuentes (de dónde entra valor) y sumideros (por dónde sale), con tasas por hora de juego.
• Simular 100–1 000 jugadores virtuales con perfiles distintos (casual, medio, hardcore, pagador) antes de implementar.
• Definir parámetros de tuning en datos (hojas de cálculo exportadas a JSON/tablas del motor), nunca en código.
• Definir los KPIs de balance: tiempo hasta cada hito, tasa de victoria, uso de cada arma o estrategia, abandono por zona.
• Herramientas: Excel/Google Sheets, Machinations.io, Python/Jupyter, simuladores propios.

5.4 Onboarding (FTUE, First Time User Experience)

• Diseñar minuto a minuto los primeros 60 minutos.
• Enseñar haciendo; una mecánica nueva cada vez; dejar dominarla antes de introducir otra.
• Medir con telemetría y playtests el abandono en cada paso del embudo.
• Separar tutoriales obligatorios de consejos contextuales y permitir saltarlos a jugadores expertos.

06Narrativa, mundo y guion

6.1 Componentes narrativos

6.2 Estructuras narrativas habituales

• Lineal en tres actos: planteamiento (25 %), confrontación (50 %), resolución (25 %).
• Viaje del héroe (Campbell/Vogler): 12 etapas, útil para aventuras.
• Ramificada: árbol de decisiones; el coste crece exponencialmente, por eso se usan técnicas de ramificar y reconverger (branch and bottleneck), estados ocultos y variables de reputación.
• Modular / storylets: piezas narrativas pequeñas con condiciones de activación que el sistema combina (muy adecuada para simuladores y juegos de vida).
• Episódica / por temporadas: arcos cerrados dentro de un arco largo (live service).
• Sistémica / emergente: el diseño narrativo crea reglas, personajes con objetivos y un narrador que detecta y destaca historias.

6.3 Fichas de personaje (por cada personaje con nombre)

Nombre · rol en la historia · edad, origen · aspecto (referencia a concept art) · personalidad (rasgos, virtudes, defectos) · deseo externo y necesidad interna · arco · relaciones con otros personajes · forma de hablar (vocabulario, muletillas, registro) · voz (referencias de casting) · secretos · escenas clave · restricciones (qué nunca haría).

6.4 El guion de un videojuego

A diferencia del cine, un guion de juego no es un documento lineal. Contiene:

Formato de producción: cada línea tiene un ID único, personaje, texto, contexto/dirección para el actor, emoción, condiciones, archivo de audio asociado, límites de caracteres y notas para localización. Se exporta a hojas de grabación de VO y a herramientas de localización.

Herramientas: articy:draft, Ink (Inkle), Yarn Spinner, Twine (prototipos), Final Draft o Fade In (cinemáticas), Arcweave, hojas de cálculo y herramientas internas.

6.5 Diseño de misiones

Cada misión documenta: objetivo narrativo, objetivo jugable, desencadenante, pasos, ramificaciones, fallos posibles, recompensas, personajes, localizaciones, duración estimada, assets necesarios, VO, dependencias y telemetría.

6.6 Proceso narrativo

1. Biblia narrativa y premisa aprobadas → 2. Esquema global (outline) → 3. Escaleta por capítulo/misión (beat sheet) → 4. Primer borrador → 5. Lectura de mesa (table read) → 6. Revisión con diseño y producción (viabilidad y coste) → 7. Integración en el juego con texto provisional y TTS → 8. Playtest narrativo → 9. Guion bloqueado para grabación → 10. Grabación de VO → 11. Integración final y ajustes → 12. String lock y localización.

07Storyboards, previsualización y prototipos visuales

7.1 Tipos de visualización previa

7.2 Proceso de cinemáticas AAA

Guion → storyboard → animatic → previs → casting → captura de interpretación (mocap + facial + voz) → edición de la captura → animación y limpieza → layout y cámara → iluminación → VFX → render en tiempo real o prerenderizado → música y mezcla → localización (lip-sync por idioma).

08Arte y dirección visual

8.1 Biblia de arte (contenido)

1. Visión visual y pilares de arte.
2. Referencias (sí / no).
3. Estilo: realista, estilizado, low-poly, pixel art, cel-shading, pictórico.
4. Lenguaje de formas (shape language) para personajes, entornos y facciones.
5. Paleta de color global, por zona, por facción, por estado emocional; color scripts.
6. Iluminación y atmósfera.
7. Materiales y texturas (PBR o no, nivel de detalle, desgaste).
8. Proporciones y escala (altura del personaje, puertas, escalones, métricas de nivel).
9. Personajes: siluetas, legibilidad, variaciones.
10. Entornos: módulos (kits), reglas de construcción, densidad.
11. UI art: estilo, iconografía, tipografía.
12. VFX: estilo, densidad, legibilidad en combate.
13. Animación: estilo, timing, exageración.
14. Budgets técnicos: polígonos, texturas, materiales, huesos, draw calls.
15. Convenciones de nombres y estructura de carpetas.
16. Ejemplos de assets aprobados ("gold standard").

8.2 Disciplinas y pipeline de arte

Pipeline estándar de un asset: brief → concept → aprobación → blockout/proxy en el juego → modelado → revisión → texturizado → integración → LODs y colisiones → revisión en contexto → optimización → aprobación final → mantenimiento.

8.3 Outsourcing de arte

En AAA, entre el 30 % y el 60 % del arte puede externalizarse. Requiere: biblia de arte impecable, guías técnicas, plantillas, un Outsourcing Manager, revisiones por lotes, contratos con cesión de propiedad intelectual y pruebas pagadas a cada proveedor antes de encargar volumen.

8.4 Arte generado con IA

Puede usarse para exploración interna, referencias y aceleración de tareas, con cautelas: la protección por derechos de autor de contenidos generados sin autoría humana suficiente es limitada o nula en varias jurisdicciones; las plataformas (por ejemplo Steam) exigen declarar el uso de IA generativa; hay riesgo reputacional y de relaciones con el equipo y los sindicatos. Definir una política de IA por escrito antes de preproducción: qué herramientas, para qué fases, con qué datos de entrenamiento, y qué nunca va al producto final sin intervención humana.

09Audio

9.1 Biblia de audio

Visión sonora, referencias, paleta instrumental, estructura musical, estilo de SFX, dirección de voz, reglas de mezcla, prioridades (qué se oye siempre), plan de espacialización, estándares técnicos.

9.2 Componentes

9.3 Herramientas y estándares

• Middleware: Wwise, FMOD, o el sistema nativo del motor (MetaSounds en Unreal).
• DAWs: Reaper, Pro Tools, Nuendo, Ableton Live, Logic.
• Bibliotecas de sonido con licencia comercial verificada.
• Estándares de sonoridad: objetivo habitual alrededor de −23/−24 LUFS integrados para consola/PC (recomendaciones de Sony ASWG-R001) y algo más alto en móvil (≈ −16/−18 LUFS); true peak por debajo de −1 dBTP.
• Contratos de VO: sindicatos (SAG-AFTRA en EE. UU., Equity en Reino Unido), cláusulas de uso de voz e IA, derechos por territorio y medio.
• Música: contratos de encargo con cesión de derechos (o licencia exclusiva); para música licenciada, derechos sync (composición, editorial) y master (grabación), territorio, duración y uso en marketing y streaming.

10UX, UI y accesibilidad

10.1 Proceso de UX

Investigación (jugadores, comps) → arquitectura de información (mapa de pantallas) → flujos de usuario → wireframes → prototipo clicable → test de usabilidad → diseño visual (UI art) → implementación → test en juego → iteración.

10.2 Entregables

• Mapa de pantallas y flujos (incluye primer arranque, cuentas, consentimiento de privacidad, ajustes, pausa, tienda, multijugador).
• Sistema de diseño de interfaz: tipografía, colores, componentes, estados, animaciones, iconos.
• HUD: qué información, cuándo, dónde, con qué prioridad.
• Especificación de navegación por mando, teclado, ratón y táctil.
• Guía de textos: longitud máxima y expansión por idioma (el alemán ocupa ~30 % más que el inglés).
• Requisitos de plataforma: zonas seguras de pantalla, botones de confirmar/cancelar por región, terminología obligatoria.

10.3 Accesibilidad (diseñar desde el principio)

Referencias: Game Accessibility Guidelines, Xbox Accessibility Guidelines (XAG), CVAA (EE. UU., comunicaciones en juego), European Accessibility Act (aplicable desde junio de 2025 a ciertos servicios y productos digitales).

Opciones mínimas recomendadas:

• Motoras: remapeo completo, alternativas a mantener o machacar botones, ajustes de sensibilidad, modos de asistencia.
• Visuales: tamaño de texto y UI escalables, modos para daltonismo, alto contraste, reducción de movimiento y de destellos, lector de menús (texto a voz).
• Auditivas: subtítulos configurables (tamaño, fondo, nombre del hablante), indicadores visuales de sonido, mezcla separada de voz.
• Cognitivas: recordatorios de objetivos, ajuste de dificultad, pausas en cualquier momento, tutoriales consultables.
• Advertencias de contenido y fotosensibilidad.

11Tecnología e ingeniería

11.1 Elección de motor: matriz de decisión

Opciones habituales:

• Unreal Engine 5: calidad visual máxima, código fuente, Nanite/Lumen, Blueprints; licencia con royalty del 5 % sobre ingresos brutos por encima de 1 millón de dólares por producto (verificar condiciones vigentes).
• Unity 6: muy versátil, fuerte en móvil, 2D/3D estilizado, simulación y juegos de gestión; C#; licencias por puesto según ingresos (verificar condiciones vigentes).
• Godot 4: código abierto (licencia MIT), sin royalties, ligero; ecosistema y soporte de consola más limitados (requiere terceros para consolas).
• Motor propio: solo justificable para estudios grandes con necesidades muy específicas (Frostbite, Decima, RE Engine, Snowdrop, id Tech).
• Otros: GameMaker y Defold (2D), O3DE, Bevy (Rust), motores web.

11.2 Contenido del TDD (Technical Design Document)

1. Visión técnica y objetivos (resolución, FPS, plataformas).
2. Motor, versión y política de actualización.
3. Arquitectura de alto nivel: módulos, capas, dependencias, patrones (ECS, data-oriented, MVC para UI).
4. Arquitectura de datos: formatos, bases de datos de contenido, serialización, versionado de datos.
5. Sistemas de juego: diseño técnico de cada sistema del GDD.
6. Renderizado: pipeline, iluminación, sombras, post-proceso, escalado (DLSS, FSR, XeSS, PSSR).
7. Física, animación, IA (navmesh, behaviour trees, utility AI, GOAP).
8. Audio: integración del middleware.
9. Red y online: modelo (cliente-servidor, P2P, rollback, autoritativo), backend, servicios.
10. Guardado y nube.
11. Streaming de mundo y carga.
12. Herramientas internas para diseño, arte y narrativa.
13. Pipeline de assets: importación, validación, cocinado (cooking), empaquetado.
14. Build y CI/CD: compilación, pruebas automáticas, distribución de builds.
15. Control de versiones y ramas.
16. Budgets de rendimiento y memoria por plataforma.
17. Telemetría y analítica.
18. Seguridad, anti-cheat y anti-tamper.
19. Localización técnica (i18n): cadenas, fuentes, formatos, RTL.
20. Accesibilidad técnica.
21. Requisitos de certificación de plataformas.
22. Estándares de código, revisiones, documentación.
23. Riesgos técnicos y planes de mitigación.

11.3 Budgets de rendimiento (ejemplo de referencia)

Además: presupuesto de memoria por categoría (texturas, mallas, audio, código, streaming), tiempos de carga máximos, tamaño de instalación y de parches, consumo de batería y temperatura en móvil.

11.4 Infraestructura de desarrollo

11.5 Prácticas de ingeniería

• Estándares de código y revisión obligatoria (code review) de todo cambio.
• Pruebas automatizadas: unitarias, de integración, smoke tests de cada build, pruebas de rendimiento automáticas, bots que recorren niveles.
• Builds diarias (o por commit) en todas las plataformas.
• Datos separados del código: diseñadores ajustan sin programadores.
• Instrumentación de rendimiento y memoria desde el primer día.
• Política de ramas (main, release, features) y de congelación.
• Gestión de deuda técnica: un porcentaje de cada sprint reservado.
• Seguridad: gestión de secretos, accesos, protección de builds filtradas (marcas de agua).

11.6 Online, backend y multijugador (si aplica)

Cuentas y autenticación (plataforma y propias), progreso en la nube, matchmaking, servidores dedicados, chat y moderación, amigos y grupos, tablas de clasificación, tienda y transacciones, inventario del servidor, eventos en vivo y configuración remota (remote config), contenido generado por usuarios (UGC) con moderación, sistemas antitrampas, escalado automático, monitorización 24/7 y planes ante caídas, cumplimiento de privacidad (consentimientos, borrado de datos), soporte cross-play y cross-progression.

12Producción y gestión del proyecto

12.1 Metodología

En AAA se usa casi siempre un híbrido: estructura en cascada para hitos y presupuesto (fases, puertas, contratos con publisher) y Agile/Scrum dentro de cada fase (sprints de 2–3 semanas, revisiones de sprint jugando la build, retrospectivas). El trabajo de contenido repetitivo (assets) se gestiona mejor con Kanban.

12.2 Organización de equipos

• Departamentos (disciplinas): arte, diseño, programación, audio, etc. Gestionan carrera, estándares y calidad.
• Equipos de feature / pods / strike teams: multidisciplinares, organizados por área del juego (combate, mundo, narrativa, online, UI). Entregan valor jugable.
• Matriz: cada persona pertenece a una disciplina y trabaja en un pod.
• Equipos centrales (core): motor, herramientas, build, QA central.
• Equipos satélite: otros estudios de la compañía o co-desarrolladores externos.

12.3 Artefactos de producción

12.4 Presupuesto: partidas típicas

Personal interno (normalmente 60–75 % del coste de desarrollo) · outsourcing y co-desarrollo · licencias de motor, middleware y herramientas · hardware y kits de desarrollo · captura de movimiento y estudios de grabación · actores y VO · música (composición, orquesta, licencias) · localización · QA externo · certificación y ratings · servidores e infraestructura · asesoría legal · user research · marketing (en AAA puede igualar o superar el coste de desarrollo) · contingencia (15–25 %).

12.5 Gestión de alcance

• Priorización MoSCoW y lista de cortes preparada de antemano (qué se cae primero si hay retraso).
• Timeboxing: las fechas y la calidad se fijan; el alcance es la variable.
• Revisión del alcance en cada hito.
• Evitar el feature creep: toda feature nueva pasa por el comité de cambios y desplaza otra.

12.6 Salud del equipo

Política explícita contra el crunch, planificación con contingencia, seguimiento de horas extra, rotación de guardias en lanzamiento, cultura de seguridad psicológica (los problemas se reportan pronto), post-mortems sin culpables.

13Roles, equipos y agentes involucrados

13.1 Dirección y liderazgo

13.2 Diseño

Lead Game Designer · Systems Designer · Combat Designer · Level Designer · World Designer · Quest/Mission Designer · Narrative Designer · Economy Designer · Progression Designer · Monetization Designer · UX Designer · UI Designer · Technical Designer / Scripter · AI Designer · Encounter Designer · Puzzle Designer · Multiplayer Designer · Live Ops Designer · Data Designer (tuning).

13.3 Programación e ingeniería

13.4 Arte

Art Director · Lead Artist · Concept Artist · Illustrator · Storyboard Artist · Character Artist · Environment Artist · Prop Artist · Hard-surface/Vehicle Artist · Texture/Material Artist · Technical Artist · Rigger · Animator (gameplay) · Cinematic Animator · Facial Animator · Mocap Technician/Director · VFX Artist · Lighting Artist · UI Artist · Motion Graphics Artist · Cinematic Director/Layout Artist · Photogrammetry Artist · Procedural Artist (Houdini) · World Builder · Art Outsourcing Manager · Art Producer · Marketing Artist / Capture Artist.

13.5 Audio

Audio Director · Composer (interno o externo) · Orquestador · Music Supervisor (licencias) · Sound Designer · Foley Artist · Dialogue/VO Director · VO Producer · Casting Director · Actores de voz e interpretación (performance capture) · Dialogue Editor · Audio Implementer / Technical Sound Designer · Audio Programmer · Mixing Engineer.

13.6 Narrativa

Narrative Director · Lead Writer · Writers / Guionistas · Narrative Designer · Quest Writer · Lore Master / Worldbuilder · Script Editor · Script Coordinator (control de IDs, versiones, exportaciones) · Consultores culturales y de sensibilidad.

13.7 Producción

Executive Producer · Senior Producer · Producer (por pod o disciplina) · Associate Producer · Production Coordinator · Project Manager · Development Director · Scrum Master · Outsourcing Producer · External Development Producer (co-desarrollo) · Localization Producer · Release Manager.

13.8 Calidad (QA) e investigación de usuarios

QA Director/Manager · QA Lead · QA Analyst · QA Tester (funcional) · Compliance/Certification Specialist · Compatibility Tester · Performance Tester · Localization QA (LQA) · Network/Multiplayer QA · Automation Engineer · Embedded QA (dentro de los pods) · User Research Lead · UX Researcher · Playtest Coordinator · Biometrics/Eye-tracking Specialist.

13.9 Datos, negocio, marketing y comunidad

13.10 Funciones corporativas y de soporte

Legal (contratos, propiedad intelectual, privacidad, cumplimiento) · Recursos Humanos y Talent Acquisition · Finanzas · IT y seguridad de la información · Administración y oficinas · Salud laboral · Diversidad e inclusión.

13.11 Agentes externos

13.12 Agentes de IA en el pipeline

Un estudio moderno debería definir explícitamente qué agentes de IA participan, con qué supervisión y bajo qué política:

13.13 Evolución del equipo por fase (AAA de referencia)

13.14 Matriz RACI de decisiones clave

R = realiza · A = aprueba (responsable final) · C = consultado · I = informado

14Calidad: QA, testing e investigación de usuarios

14.1 Plan de QA

Estrategia y alcance · tipos de prueba por fase · matriz de plataformas y hardware · criterios de entrada y salida de cada hito · flujo de bugs · métricas · recursos (internos, externos, automatizados) · herramientas.

14.2 Tipos de prueba

14.3 Gestión de bugs

• Severidad: A/Bloqueante (crash, pérdida de progreso, bloqueo de certificación) · B/Mayor · C/Menor · D/Cosmético.
• Prioridad: decidida por producción según impacto y momento.
• Ciclo de vida: nuevo → triado → asignado → en curso → resuelto → verificado → cerrado (o reabierto).
• Comité de triaje diario en fases finales.
• Métricas: bugs abiertos por severidad, tasa de entrada frente a tasa de cierre, tiempo de resolución, crashes por hora de juego.

14.4 Investigación de usuarios (UR) y playtesting

Cada playtest tiene objetivos escritos, perfil de jugadores, protocolo, y genera un informe con hallazgos priorizados que se convierten en tareas del backlog.

15Legal, propiedad intelectual y cumplimiento normativo

15.1 Estructura y contratos

• Sociedad adecuada (en España, normalmente S.L.), pacto de socios, reparto de participaciones, vesting.
• Contratos laborales con cláusula de cesión de propiedad intelectual al estudio y confidencialidad.
• Contratos con freelancers y proveedores: obra por encargo con cesión de derechos explícita (todos los medios, territorios y duración), garantías de originalidad, confidencialidad.
• NDA antes de compartir información.
• Acuerdo de publicación (publishing agreement): financiación, recuperación de la inversión (recoup), reparto de ingresos (revenue share), propiedad de la IP, hitos y pagos, derechos de secuelas y adaptaciones, territorios, plataformas, terminación.
• Acuerdos de plataforma: cada fabricante exige registro como desarrollador, acuerdo de licencia y cumplimiento de sus requisitos.
• Contratos con actores: derechos de imagen y voz, uso en marketing, cláusulas sobre IA, sindicatos.

15.2 Propiedad intelectual

• Marca: búsqueda y registro del nombre y el logo (OEPM en España, EUIPO en la UE, USPTO en EE. UU.; clases 9, 28 y 41 habitualmente). Comprobar dominios y redes sociales.
• Derechos de autor: el código, arte, música y textos están protegidos desde su creación; documentar autoría y cadena de cesiones.
• Licencias de terceros: motor, middleware, fuentes tipográficas, bibliotecas de sonido, assets comprados, software de código abierto (cuidado con licencias copyleft como GPL), música licenciada.
• Marcas y productos reales en el juego: coches, armas, marcas comerciales, personas reales o lugares reconocibles requieren licencia o un análisis de riesgo.
• Contenido generado por IA: verificar condiciones de la herramienta, la protección limitada de lo generado y la obligación de declararlo en tiendas.
• Patentes: raras en diseño de juegos pero existen (revisar sistemas muy concretos).

15.3 Regulación y cumplimiento

15.4 Documentos legales de cara al jugador

EULA o términos de servicio, política de privacidad, política de cookies, código de conducta, términos de compras y monedas virtuales, política de contenido generado por usuarios, avisos legales y créditos de licencias de terceros.

16Negocio, financiación y estrategia comercial

16.1 Modelos de negocio

16.2 Vías de financiación

Fondos propios · friends & family · publisher · inversores de capital riesgo y fondos especializados · acuerdos con plataformas (exclusividad, catálogos de suscripción) · subvenciones públicas (en España: ayudas del Ministerio de Cultura y de comunidades autónomas, ICEX para internacionalización; en la UE: Europa Creativa MEDIA) · incentivos fiscales · crowdfunding (Kickstarter, Fig) · early access · preventas · licencias y co-producciones · deuda (préstamos ENISA, bancos).

16.3 Business case (contenido)

1. Resumen ejecutivo.
2. Mercado: tamaño, tendencias, segmento, competencia.
3. Producto y diferenciación.
4. Público objetivo y alcance estimado.
5. Modelo de negocio y precio.
6. Previsión de ventas o ingresos en tres escenarios (pesimista, base, optimista) a 1, 3 y 5 años.
7. Costes: desarrollo, marketing, operación, plataforma (comisión típica del 30 %, a veces 12–20 % según tienda y volumen), publisher, impuestos.
8. Cuenta de resultados (P&L), punto de equilibrio, ROI, flujo de caja.
9. Riesgos y sensibilidad.
10. Plan de salida o continuidad (secuelas, DLC, adaptaciones transmedia).

16.4 KPIs de negocio

• Premium: wishlists, tasa de conversión de wishlist a venta, unidades vendidas, precio medio neto, reembolsos, reseñas, curva de ventas en rebajas.
• F2P / live service: DAU/MAU, retención D1/D7/D30, duración de sesión, conversión a pagador, ARPDAU, ARPPU, LTV, CPI (coste por instalación), ROAS, churn.
• Comunidad: seguidores, interacción, sentimiento, menciones de creadores.

16.5 Precio y estrategia de plataforma

Definir precio base por región (paridad de poder adquisitivo), ediciones (estándar, deluxe, coleccionista), política de descuentos, exclusividades temporales, lanzamiento simultáneo o escalonado por plataforma, cross-buy y cross-progression.

17Marketing, comunidad y relación con creadores

17.1 Plan de marketing (fases)

17.2 Activos de marketing

Logotipo y guía de marca · key art (versiones horizontal, vertical, cápsulas de tienda) · trailers (anuncio, gameplay, historia, lanzamiento, aceptación de la crítica) · capturas · GIFs · página de tienda optimizada (descripción, etiquetas, vídeos) · press kit · sitio web · redes sociales · diarios de desarrollo · demo · merchandising · banda sonora.

17.3 Comunidad

• Discord oficial, redes sociales, Reddit, foros propios.
• Community Managers desde el anuncio (o antes, en desarrollo abierto).
• Programa de creadores de contenido: acceso anticipado, kits, códigos, acuerdos de patrocinio transparentes.
• Políticas claras de moderación y código de conducta.
• Bucle de feedback: lo que la comunidad dice llega al backlog con datos.
• Política de streaming y uso de música (evitar reclamaciones de derechos sobre la música licenciada).

18Localización y culturalización

• Internacionalización (i18n) desde el día uno: nunca texto escrito en el código; tablas de cadenas con IDs; soporte Unicode; fuentes con todos los glifos necesarios; formatos de fecha, número y moneda; textos de derecha a izquierda si se incluye árabe o hebreo; UI que se adapta a la longitud del texto.
• Niveles de localización: solo textos (subtítulos), audio parcial, doblaje completo.
• Idiomas habituales: inglés + FIGS (francés, italiano, alemán, español de España) como base; español latinoamericano, portugués brasileño, ruso, polaco, turco, japonés, coreano, chino simplificado y tradicional, árabe según el mercado.
• Proceso: kit de localización (glosario, guía de estilo por idioma, contexto y capturas, referencias de personajes, límites de caracteres) → traducción → revisión → integración → LQA en el juego → corrección.
• Culturalización: revisar símbolos, gestos, colores, religión, historia, mapas y fronteras, contenido sensible por mercado.
• Proveedores: Keywords Studios, Lionbridge Games, Localsoft, Altagram, Pole To Win, entre otros; herramientas como memoQ, Crowdin, Lokalise, XTM, Smartcat.

19Datos, telemetría y analítica

19.1 Plan de telemetría

Se define en preproducción junto al GDD. Para cada feature: qué eventos se registran, con qué parámetros, para responder qué pregunta. Incluye taxonomía de eventos, identificadores de sesión y jugador (pseudonimizados), consentimiento y privacidad, retención de datos, volumen y coste.

19.2 Preguntas que debe responder

¿Dónde abandonan los jugadores? ¿Cuánto tarda cada misión? ¿Qué armas, rutas, personajes o estrategias se usan? ¿Dónde mueren? ¿Qué opciones de accesibilidad se activan? ¿Cuál es el rendimiento real en el hardware de los jugadores? ¿Qué compran y cuándo? ¿Qué hace volver a un jugador?

19.3 Herramientas

Cuadros de mando por audiencia (dirección, diseño, live ops, marketing), mapas de calor de niveles, embudos de onboarding, cohortes de retención, alertas automáticas de anomalías, pruebas A/B y configuración remota.

20Postproducción: pulido, certificación y Gold

20.1 Secuencia final

Beta → content lock → string lock (localización completa) → UI lock → pulido y optimización → code freeze → Release Candidate → certificación de plataforma → (si falla, corrección y reenvío) → Gold Master → preparación del day-one patch → lanzamiento.

20.2 Certificación de plataformas

Cada fabricante tiene una lista de requisitos técnicos y de experiencia: Sony (TRC), Microsoft (Xbox Requirements, XR), Nintendo (Lotcheck/guidelines), Apple App Review, Google Play Policies, Steam (revisión de build y página). Incluyen manejo de suspensión y reanudación, desconexión de mandos, cuentas de usuario, guardado, terminología oficial, logros/trofeos, rendimiento mínimo, privacidad, clasificación por edades.

Recomendaciones: tener un especialista en cumplimiento desde la Alpha, hacer pre-cert interna, reservar las ventanas de envío con meses de antelación y prever al menos un reenvío en el calendario.

20.3 Pulido (polish)

Ajuste fino del game feel, transiciones, feedback visual y sonoro, iluminación, mezcla de audio, ritmo, legibilidad de UI, tiempos de carga, eliminación de hitches, coherencia de textos.

21Lanzamiento

21.1 Checklist de lanzamiento

• Build Gold aprobada y day-one patch certificado.
• Páginas de tienda completas en todos los idiomas y plataformas; precios por región; preventa configurada.
• Clasificaciones por edades obtenidas en todos los territorios.
• Servidores escalados y probados bajo carga; plan de colas de acceso.
• Equipo de guardia 24/7 (war room): ingeniería, live ops, comunidad, soporte, PR.
• Monitorización: crashes, rendimiento, servidores, pagos, sentimiento en redes.
• Plan de comunicación de incidencias (estado de servicios, mensajes preparados).
• Soporte al jugador: base de conocimiento, FAQ, plantillas, herramientas de ticketing.
• Embargo de reseñas y envío de códigos a prensa y creadores.
• Campaña de lanzamiento activa.
• Plan de los primeros 30, 60 y 90 días de parches y contenido.

21.2 Estrategias de lanzamiento

Global simultáneo · escalonado por región · soft launch (móvil, en países de prueba) · early access · acceso anticipado para ediciones premium · lanzamiento en catálogos de suscripción.

22Live ops y post-lanzamiento

22.1 Componentes

22.2 Calendario de live ops

Roadmap público (aproximado) y roadmap interno detallado, cadencia fija (por ejemplo, temporadas de 8–12 semanas), contenido producido con 1–2 temporadas de adelanto, ventanas de mantenimiento comunicadas.

22.3 Fin de vida (sunset)

Anuncio con antelación (mínimo 60–90 días en juegos online), cese de ventas de moneda virtual, reembolsos según ley, modo offline o servidores comunitarios si es posible, preservación (archivo de código, assets y documentación), post-mortem del proyecto completo y actualización de esta guía maestra con lo aprendido.

23Lista maestra de entregables por fase

24Mapa de herramientas por área

25Riesgos frecuentes y antipatrones

26Definition of Ready: condiciones para empezar el desarrollo

El desarrollo a escala (producción) no empieza hasta que todas estas casillas están marcadas:

Visión y diseño

• High concept, fantasía del jugador, pilares y USP aprobados.
• Core loop, loop secundario y meta loop definidos y validados en prototipo con jugadores externos.
• GDD 1.0 con specs de todos los sistemas núcleo.
• Lista de features priorizada (MoSCoW) y lista de cortes.
• Modelo de economía y progresión simulado.
• FTUE (primera hora) diseñada.

Narrativa

• Biblia narrativa aprobada (mundo, personajes, tono, reglas).
• Estructura de la historia completa (outline) y sistema narrativo definido.
• Guion del vertical slice escrito e integrado.

Arte y audio

• Biblia de arte y biblia de audio 1.0.
• Concept art de personajes y zonas principales.
• Assets "gold standard" de referencia.
• Pipeline de assets probado con costes medidos.

UX

• Mapa de pantallas, flujos y wireframes principales.
• Sistema de diseño de interfaz.
• Plan de accesibilidad.

Tecnología

• Motor elegido con justificación documentada.
• TDD 1.0 y arquitectura.
• Riesgos técnicos principales resueltos con prototipos.
• Budgets de rendimiento y memoria por plataforma.
• Control de versiones, CI/CD, builds automáticas funcionando.
• Plan de telemetría, guardado, localización técnica y online (si aplica).

Producción y negocio

• Vertical slice terminado y validado.
• Plan de producción basado en costes medidos, con hitos Alpha, Beta, Gold.
• Presupuesto con contingencia y financiación asegurada.
• Plan de equipo, contratación y outsourcing.
• Business case y modelo de negocio.
• Plan de marketing preliminar.
• Registro de riesgos con mitigaciones.

Legal

• Sociedad, contratos y cesiones de propiedad intelectual en orden.
• Búsqueda de marca del título.
• Licencias de motor, middleware y herramientas.
• Política de IA y de privacidad.

27Plantilla de la Guía aplicada (para un juego concreto)

Este es el puente entre la guía maestra y el desarrollo. Se crea un documento con exactamente estas secciones y se responde cada una para el juego concreto. Cada respuesta enlaza a su entregable.

Secuencia recomendada para rellenarla: A1–A3 (identidad y mercado) → A5–A6 (diseño núcleo) → A12 (prototipos que validan A5) → A4 (tecnología, tras saber qué se necesita) → A7–A11 (narrativa, arte, audio, UX) → A14–A17 (equipo, plan, dinero) → A18–A25 → A13 (vertical slice) → A26 (puerta a producción).

28Glosario

Guía maestra v1.0 · noviembre de 2026. Documento vivo: se revisa tras cada puerta de aprobación y tras el post-mortem de cada proyecto. Las condiciones comerciales de motores, plataformas y la normativa citada cambian con frecuencia y deben verificarse en la fuente oficial antes de tomar decisiones.