Tu juego no está atrasado por falta de talento
Alguien reserva su tarde para integrar y se la pasa esperando un archivo que no llegó. La build se genera el último día y nadie alcanza a jugarla antes de entregarla. Y el proyecto lleva meses «casi listo», porque cada semana aparece algo nuevo y nadie puede decir cuánto falta.
Más horas no lo arreglan. Lo que te falta es ver a tiempo qué está pasando, con una forma de producir pensada para un equipo que no coincide en horarios y que no puede gastar en administrar el proyecto las horas que necesita para hacer el juego.
Qué recibes
El Playbook (PDF). Cinco capítulos que siguen el recorrido de un sprint. Cada uno termina con una práctica que haces con tu propio proyecto, a partir de un ejemplo resuelto, e incluye un glosario con los términos de la industria en español e inglés.
El spreadsheet de producción (Google Sheets). Backlog, tablero, ficha del sprint, registro de cada build, registro de decisiones y retrospectivas en un solo lugar. Haces tu copia con un clic y no tienes que pagar ninguna herramienta.
¿Ya trabajas en Jira, Trello u otra herramienta? Puedes seguir en ella. El Playbook explica el criterio, y el spreadsheet queda como recurso para quien no tiene dónde llevar el trabajo.




Un sprint completo, de principio a fin
- 1
Instalar el sistema
La lista de trabajo pendiente, el tablero, cuándo una tarea está terminada y los acuerdos del equipo.
- 2
Planificar el próximo sprint
Elegir el trabajo según las horas que cada persona tiene de verdad esa semana.
- 3
Ejecutar y cerrar la build
Integrar temprano, avisar apenas algo cambia y cerrar la entrada de cambios antes de entregar.
- 4
Aprender y decidir
Jugar la build, separar lo que viste de lo que supones y decidir qué sigue.
- 5
Mejorar la forma de trabajar
Una retrospectiva sencilla para ajustar los acuerdos del equipo.
Para quién es
- Tienes un juego en marcha con un equipo indie pequeño.
- Tu equipo trabaja a tiempo parcial y en horarios distintos.
- Sabes qué es una build, un bug o una prueba de juego, pero nadie en tu equipo se dedica a la producción.
Si desarrollas solo, también te sirve, porque cada capítulo cierra con la sección «Si eres SoloDev», que adapta lo que acabas de leer a una sola persona.
Para quién no es
- Para quien todavía no empieza a hacer juegos.
- Para quien busca aprender a programar o a diseñar juegos. Este es un sistema para administrar tu proyecto con prácticas que vienen de equipos profesionales.
- Para estudios con producción formal, que ya tienen sus procesos y personas dedicadas a esto.
Lo que no te va a resolver
No reemplaza el diseño del juego, así que no te va a decir si tu mecánica es divertida, y tampoco decide por ti qué recortar cuando el tiempo no alcanza. Lo que sí hace es que el trabajo se vea y que lo que comprometes quepa en el tiempo real de cada persona, de modo que esas decisiones las tomes a tiempo y con lo que viste en cada build.
Quién lo escribe
Luis Romero. Casi veinte años en producción de videojuegos, en proyectos para clientes como Activision Blizzard, Electronic Arts, DreamWorks y 4A, y con propiedades intelectuales de Guillermo del Toro y de Overbrook, el estudio de Will Smith. Antes de eso, casi diez desarrollando software. Lo escribí para que un equipo indie use lo que los estudios grandes hacen para cumplir fechas, sin cargar con su estructura.



