Diagrama de Gantt de desarrollo de videojuego: de la porción vertical al gold
Diagrama de Gantt editable de desarrollo de videojuegos: prototipo, puerta de porción vertical, código, arte y audio en paralelo, alfa, beta, espera de certificación de la plataforma y gold, con dependencias e hitos.
¿Qué es diagrama de gantt de desarrollo de videojuego: de la porción vertical al gold?
Un videojuego se planifica de otro modo que otro software porque su mayor riesgo no es si puede construirse, sino si es divertido. Nadie puede programar eso, así que el plan pone una decisión pronto: una pieza pequeña y terminada del juego, la porción vertical, que debe mostrar el aspecto, la sensación y el bucle central con una calidad próxima a la final. Hasta que se aprueba la porción, solo unas pocas personas deberían construir algo caro. Después, arte, audio y código pueden trabajar a plena escala, y cambiar la idea central sale muy caro. Un cronograma muestra cuánto trabajo espera detrás de esa puerta y dónde dolería un cambio tardío.
Esta plantilla tiene cinco grupos: Concepto y prototipo, Código y diseño, Arte y audio, Pruebas y certificación y Lanzamiento. «Redactar el concepto y los pilares del juego» (3 días laborables) es la única tarea de arranque. «Construir el prototipo en greybox» (8) la sigue, y «Desarrollar el estilo artístico y el arte conceptual» (7) empieza al mismo tiempo, de modo que se explora el aspecto mientras se prueba la sensación. «Probar el prototipo con jugadores» (3) va antes de «Construir la porción vertical» (12), que empieza 3 días después de que empiece «Producir los recursos de la porción vertical» (8), con un enlace de inicio a inicio, porque los primeros recursos hacen falta pronto pero no todos. «Porción vertical aprobada» es la primera puerta y espera a ambas.
Tras la puerta, el trabajo se extiende. Empieza «Construir los sistemas de juego principales» (20), y «Construir y ajustar los niveles» (18) empieza 6 días laborables después, para que el diseño de niveles use los sistemas a medida que se vuelven utilizables. «Producir el arte y la animación de producción» (36) y «Componer la música y grabar los efectos de sonido» (15) también empiezan en la puerta, que es el solapamiento seguro en un juego: el contenido se hace junto al código que lo llevará. «Alfa alcanzada» espera a los sistemas y a los niveles, no al arte. El contenido aún se está haciendo en la alfa, y «Corregir errores de la alfa y equilibrar» (10) corre a su lado. «Beta alcanzada» espera a esa corrección, al arte y al audio. Con las cifras ilustrativas, el arte es la cadena más larga: termina 2 días laborables después de las correcciones de la alfa, así que el arte, y no el código, fija la fecha de la beta.
El final del plan es una espera que no controlas. «Ejecutar la ronda de pruebas beta» (8) y «Corregir errores de la beta y pulir» (10) llevan a «Enviar la versión candidata» (1), y «Revisión de certificación de la plataforma» (10) es la revisión que la propia plataforma hace de la versión. Sustituye su duración por lo que te diga la plataforma, y mantén «Corregir los hallazgos de certificación y reenviar» (3) como colchón aunque esperes aprobar a la primera. Le sigue «Máster gold aprobado», y «Día de lanzamiento» cierra el plan a los 94 días laborables. «Preparar las páginas de tienda y el tráiler de lanzamiento» (8) empieza en la beta, porque las imágenes del tráiler necesitan una versión que ya parezca terminada, y tiene margen de sobra. Todas las duraciones son ilustrativas; sustitúyelas por las estimaciones de tu propio equipo.
Un cronograma programa el trabajo. No supera la certificación, no libera música, tipografías u otro material con licencia, ni hace divertido el juego. Un juego también se distingue de una versión de software corriente en lo que es caro cambiar tarde: una mecánica nueva tras la porción vertical, o un diseño de nivel cuando ya se ha construido el arte sobre él, cuesta mucho más que corregir un error en la beta. Para un plan que es solo código, consulta la plantilla de diagrama de Gantt de proyecto de software; para los pasos de lanzamiento de una aplicación, la plantilla de diagrama de Gantt de lanzamiento de software; y para ver cómo funciona la misma idea en una producción de estilo cinematográfico, la plantilla de diagrama de Gantt de producción de animación. El método de un plan con puertas, plazos compartidos y fecha fija está en la guía de diagramas de Gantt con plazos de entrega antes de la fecha de lanzamiento.
Qué cubre este diagrama de flujo
En esta plantilla
- Cinco grupos, Concepto y prototipo, Código y diseño, Arte y audio, Pruebas y certificación y Lanzamiento, con 22 tareas y cinco hitos: «Porción vertical aprobada», «Alfa alcanzada», «Beta alcanzada», «Máster gold aprobado» y «Día de lanzamiento».
- Una puerta creativa: «Porción vertical aprobada» espera a «Construir la porción vertical» y a «Producir los recursos de la porción vertical» antes de que empiecen las grandes tareas de producción.
- Arte, audio y código en paralelo: «Producir el arte y la animación de producción», «Componer la música y grabar los efectos de sonido» y «Construir los sistemas de juego principales» empiezan todos en la puerta, y «Construir y ajustar los niveles» empieza 6 días laborables después del inicio de los sistemas.
- Una separación entre alfa y beta: «Alfa alcanzada» espera al código y a los niveles, mientras que «Beta alcanzada» espera también al arte y al audio.
- Una espera de certificación: «Enviar la versión candidata», «Revisión de certificación de la plataforma» y «Corregir los hallazgos de certificación y reenviar» quedan entre la beta y «Máster gold aprobado».
Cuándo usar esta plantilla
- Planificas un juego desde el prototipo hasta el lanzamiento y necesitas un calendario que reúna código, arte y audio.
- Quieres ver si el código, el arte o la espera de certificación fijan la fecha de lanzamiento, y cuánto margen tiene el resto.
- Un editor o una plataforma espera hitos llamados alfa, beta y gold, y los quieres como puertas con fecha.
- Haces juegos con regularidad y quieres un plan estándar que ajustar a cada proyecto.
El plan, tarea por tarea
Todas las tareas del diagrama con su duración en días laborables y aquello de lo que dependen. Una dependencia es un número de paso; SS es inicio a inicio, FF es fin a fin y +n es un retraso en días laborables.
| # | Tarea | Grupo | Días laborables | Depende de |
|---|---|---|---|---|
| 1 | Redactar el concepto y los pilares del juego | Concepto y prototipo | 3 | |
| 2 | Construir el prototipo en greybox | Concepto y prototipo | 8 | 1 |
| 3 | Probar el prototipo con jugadores | Concepto y prototipo | 3 | 2 |
| 4 | Porción vertical aprobada | Concepto y prototipo | Hito | 5, 9 |
| 5 | Construir la porción vertical | Código y diseño | 12 | 3, 9SS+3 |
| 6 | Construir los sistemas de juego principales | Código y diseño | 20 | 4 |
| 7 | Construir y ajustar los niveles | Código y diseño | 18 | 6SS+6 |
| 8 | Desarrollar el estilo artístico y el arte conceptual | Arte y audio | 7 | 1 |
| 9 | Producir los recursos de la porción vertical | Arte y audio | 8 | 8 |
| 10 | Producir el arte y la animación de producción | Arte y audio | 36 | 4 |
| 11 | Componer la música y grabar los efectos de sonido | Arte y audio | 15 | 4 |
| 12 | Alfa alcanzada | Pruebas y certificación | Hito | 6, 7 |
| 13 | Corregir errores de la alfa y equilibrar | Pruebas y certificación | 10 | 12 |
| 14 | Beta alcanzada | Pruebas y certificación | Hito | 10, 11, 13 |
| 15 | Ejecutar la ronda de pruebas beta | Pruebas y certificación | 8 | 14 |
| 16 | Corregir errores de la beta y pulir | Pruebas y certificación | 10 | 15 |
| 17 | Enviar la versión candidata | Pruebas y certificación | 1 | 16 |
| 18 | Revisión de certificación de la plataforma | Pruebas y certificación | 10 | 17 |
| 19 | Corregir los hallazgos de certificación y reenviar | Pruebas y certificación | 3 | 18 |
| 20 | Máster gold aprobado | Lanzamiento | Hito | 19 |
| 21 | Preparar las páginas de tienda y el tráiler de lanzamiento | Lanzamiento | 8 | 14 |
| 22 | Día de lanzamiento | Lanzamiento | Hito | 20, 21 |
Cómo funciona
Decide qué tiene que demostrar la porción
Conserva «Porción vertical aprobada» como la puerta del gasto grande. Escribe en las Notas de la tarea lo que debe mostrar, y acorta o alarga «Construir la porción vertical» al tamaño de porción que de verdad vayas a juzgar.
Dimensiona los flujos en paralelo
Fija «Construir los sistemas de juego principales», «Construir y ajustar los niveles» y «Producir el arte y la animación de producción» según tus propias estimaciones y lee cuál termina última. Usa el enlace de inicio a inicio de los niveles para decir cuánto deben adelantarse los sistemas.
Define qué significan alfa y beta
Decide qué debe existir en «Alfa alcanzada» y en «Beta alcanzada» para tu proyecto y mantén sus dependencias en consonancia. Si tu alfa necesita el arte, añade ese enlace.
Sustituye la espera de certificación
Fija «Revisión de certificación de la plataforma» según lo que te diga la plataforma. Mantén «Corregir los hallazgos de certificación y reenviar» en el plan aunque esperes aprobar.
Comprueba la fecha de lanzamiento
Si el lanzamiento es fijo, da a «Redactar el concepto y los pilares del juego» un Inicio fijo y a «Día de lanzamiento» un Inicio fijo. El plan empieza en el primer Inicio fijo y se programa hacia delante: si el trabajo no cabe, «Día de lanzamiento» se marca con un conflicto que indica la fecha más temprana que permiten sus dependencias.
Añade responsables, comparte y exporta
Pon a la persona responsable de cada tarea en Personas, comparte el diagrama como enlace con tu editor o equipo, y exporta un PDF o PNG para las revisiones.
Preguntas frecuentes
¿En qué se diferencia el plan de un juego del de un proyecto de software?
Un plan de software suele poder dar el diseño por cerrado cuando lo están los requisitos. Un plan de juego tiene que descubrir si el diseño funciona, así que pone «Porción vertical aprobada» antes del trabajo caro, y lleva el arte y el audio como grandes flujos paralelos que condicionan la beta. También termina con una revisión de plataforma fuera de tu control. Si tu proyecto es sobre todo código, parte de la plantilla de diagrama de Gantt de proyecto de software.
¿Cuál es la ruta crítica en la plantilla?
Con las cifras ilustrativas, pasa por la porción vertical, luego el arte, la beta, la ronda beta, la revisión de certificación y el lanzamiento. Activa Ver ▸ Ruta crítica para iluminarla. La cadena de código es unos días más corta que la del arte, así que el arte fija «Beta alcanzada» hasta que cambies las duraciones.
Mi fecha de lanzamiento es fija. ¿Puede comprobarla el diagrama?
Sí. Da a la primera tarea un Inicio fijo y a «Día de lanzamiento» un Inicio fijo. El plan empieza en el primer Inicio fijo y se programa hacia delante, así que si la cadena desde el concepto hasta la certificación es demasiado larga, «Día de lanzamiento» se marca con un conflicto. Compara la fecha de fin con la que necesitas.
¿Puedo añadir más plataformas o más actualizaciones de contenido?
Sí. Duplica «Revisión de certificación de la plataforma» y su tarea de reenvío para cada plataforma que revise por separado, y enlaza cada una a «Máster gold aprobado». Las actualizaciones posteriores al lanzamiento pueden ser un segundo plan que empiece en «Día de lanzamiento».
¿Sustituye el diagrama a un gestor de producción?
No. Programa el trabajo y muestra cómo dependen las tareas entre sí. No guarda errores, listas de recursos ni números de versión, y no libera música ni middleware con licencia. Puede marcarse el progreso en cada tarea, pero el progreso nunca mueve las fechas.