Tres años en el mismo proyecto, sin publisher, sin salario fijo, con el editor abierto hasta las cuatro de la mañana. Si me preguntas si he tenido burnout, la respuesta es que he tenido dos colapsos serios y probablemente varios menores que no supe nombrar a tiempo. Esta no es una guía de cinco pasos. Es lo que aprendí quemándome.
¿Qué es realmente el burnout para un indie dev, no la versión de LinkedIn?
No es cansancio. El cansancio se va con dormir. El burnout es cuando abres Godot y el proyecto te parece vacío antes de haber escrito una sola línea. Cuando la feature que llevas tres semanas construyendo te produce exactamente la misma emoción que lavar los platos. Cuando te das cuenta de que llevas semanas trabajando por obligación hacia una versión pasada de ti mismo que prometió algo, y ya no sabes si esa persona tenía razón.
Hay una encuesta de la IGDA (International Game Developers Association) que circula en la industria: alrededor del 42% de los desarrolladores de videojuegos reportan haber experimentado burnout severo en los últimos dos años, y más del 59% dicen trabajar en condiciones de crunch regular. Eso es en estudios con equipo y sueldo. En indie solo, los números son peores porque no tienes a nadie que te diga que pares.
¿Por qué el scope creep es la causa de burnout que nadie nombra así?
Arre, el scope creep. La trampa favorita de todo dev indie con más ideas que calendario. A las dos de la mañana añades un sistema de clima dinámico porque te pareció buena idea. A la semana siguiente, un árbol de diálogo secundario para un personaje que aparece dos veces. Al mes, una mecánica de crafteo que "encaja perfectamente con la visión del juego."
Cada feature que agregas sin quitar otra es deuda emocional diferida. Lo que parece ambición en el momento es un reloj que corre en tu contra. Mi proyecto, Asura's Thread, lleva tres años en desarrollo parcialmente porque tardé dieciséis meses en aprender a decir que no a mis propias ideas. El documento de diseño original tenía cuatro mecánicas. A los ocho meses tenía dieciséis. A los doce meses, volví a cuatro. Ese retroceso de cuatro meses fue la decisión más inteligente que tomé en todo el proyecto.
Hollow Knight tardó cuatro años. Team Cherry tenía tres personas. Lo que no tuvieron fue un roadmap público con fechas grabadas en piedra ni un Discord lleno de gente esperando features específicas. Si alguien te pregunta "¿cuándo sale?", la respuesta correcta es siempre "cuando esté listo."
¿Cómo afecta el aislamiento del trabajo indie a la salud mental?
Koramangala tiene buena conexión a internet y el peor problema del trabajo solo es exactamente ese: cuando algo falla, no hay nadie que lo relativice. Mi build se rompió tres días seguidos la semana pasada. En un estudio con equipo, eso es un bug que alguien más ve y comenta. Trabajando sola, es la confirmación de que quizás toda la arquitectura está mal y el proyecto completo es un error y debería haber terminado el grado.
La soledad no crea el burnout. Pero convierte cada fracaso pequeño en un evento sin contexto, y eso es devastador a largo plazo. En India, en España, en Argentina, el dev indie trabaja solo o en equipos de dos personas, y la industria no habla suficientemente de esto. Según el portal DeVuego.es, el repositorio más completo de la industria hispana del videojuego, hay más de 1.835 estudios activos y 6.210 desarrolladores indexados en España y el mercado hispanohablante — pero la mayoría de esos estudios son equipos de menos de cinco personas. El aislamiento es estructural, no es un problema tuyo.
Tener una sola persona con quien hablar de tu proyecto con regularidad — un Discord con otros devs, una comunidad como la de DeVuego.es o los grupos de Madrid Games Week — cambia el ciclo de forma medible. No porque te den soluciones. Porque te ayudan a distinguir los problemas reales de los problemas que creó la soledad.
¿Cómo saben los estudios indie experimentados lo que tú todavía aprendes?
Tequila Works lleva haciendo juegos en Madrid desde 2009. RIME tardó cuatro años y varios rediseños. MercurySteam, también españoles, lleva desde 2002. Ninguno de los dos construyó su reputación destrozando a su equipo, y MercurySteam es conocido específicamente por su disciplina técnica en proyectos como Castlevania: Lords of Shadow.
La industria española del videojuego es más grande de lo que parece desde fuera. La AEVI (Asociación Española de Videojuegos) estima que el mercado español superó los 1.900 millones de euros en 2024, con más de 16 millones de jugadores activos. No toda esa cifra va a estudios indie locales, está claro, pero significa que hay un ecosistema real donde sobrevivir.
Lo que hacen los estudios que duran no es un secreto: producción acotada, lanzamientos iterativos, cultura interna que permite decir "esto no funciona" sin que sea una crisis de identidad. Cuando eres un dev solo, tienes que construir esa cultura contigo mismo, lo que es objetivamente más difícil y merece ser nombrado como lo que es.
¿Qué señales concretas te dicen que ya estás en burnout, no "solo cansado"?
Esta es la pregunta que más me han hecho y la que más me costó responder para mí misma. La diferencia entre cansancio y burnout:
El cansancio se va con un día lejos del ordenador. Te levantas con ganas de volver. El burnout no se va así. Me tomó cuatro días sin tocar el código en mi primer colapso para darme cuenta de que el problema no era el descanso — era que después de cuatro días sin trabajar todavía no quería volver.
Señales específicas que yo reconozco ya: trabajo en el proyecto pero en modo mecánico, sin decisiones reales. Llevo semanas sin tomar una decisión de diseño que importe, solo ejecutando tareas pequeñas que siento seguras. Abro el editor y el primer instinto es cerrarlo. Cuando alguien me pregunta por el juego, respondo con información técnica en vez de con emoción. Eso último es el más claro: cuando Asura's Thread se convierte en "un 2D action-RPG basado en folclore kannada con mecánicas de combate de danza Yakshagana" en vez de en "lo que llevo tres años construyendo y que me importa más que casi nada."
¿Qué funciona realmente para no quemarse, aparte de "tómate un descanso"?
Haan, el consejo de "descansa" es el más inútil que existe si no viene acompañado de estructura. Lo que a mí me funciona, con la honestidad de que nada funciona siempre:
Límites temporales no negociables. No "intento parar a las once." Paro a las once. El código no va a ir a ningún lado sin mí y mi cerebro en modo privación de sueño toma peores decisiones que una IA de 2019. Los estudios sobre productividad cognitiva son consistentes en que más de seis horas de trabajo creativo intenso al día produce rendimientos decrecientes. Después de seis horas, el volumen de trabajo no compensa la calidad que pierdes.
Separar el proyecto de la identidad. Esta es la más difícil y probablemente la más importante. Asura's Thread no soy yo. Es algo que estoy construyendo. Si el juego falla, eso dice algo sobre el mercado, la ejecución, el timing. No dice que yo soy un error. Lo tengo que recordar activamente porque mi cerebro por defecto colapsa ambas cosas.
Milestones pequeños, no hitos de lanzamiento. "Terminar el juego" es un objetivo que literalmente no puedes completar hoy. "Implementar el sistema de salud del primer boss" sí. La dopamina de los checkboxes completados no es despreciable — el cerebro no distingue entre "terminé el juego" y "terminé este sistema específico" si el milestone era real.
Hablar del proceso, no solo del producto. Esto va contra el instinto de todo dev indie que tiene imposter syndrome, que somos todos. Pero escribir sobre lo que estás construyendo, aunque sea en un diario privado o con otros devs, mantiene la narrativa de que eres alguien haciendo algo, no alguien que todavía no ha terminado nada.
¿Cuándo es más honesto pausar o redefinir el proyecto que seguir?
La pregunta que nadie quiere hacerse. Yo la evité durante meses en el segundo colapso y costó más de lo que habría costado hacerla a tiempo.
La respuesta honesta: cuando el proyecto ya no existe en tu cabeza como algo que quieres hacer, sino como una deuda que tienes que saldar, has cruzado una línea importante. Trabajar por obligación hacia una versión pasada de ti mismo que prometió algo no es perseverancia, es daño acumulado con nombre de virtud.
Pausar y redefinir el scope es diferente a abandonar. Tequila Works rediseñó RIME de forma sustancial varias veces. La Mecánica del Caracol, el estudio argentino detrás de proyectos como La máquina que nunca se rompe, habla abiertamente de haber pivotado proyectos a mitad de producción. Eso no es fracaso. Es desarrollo honesto.
Lo que sí es cancelar: cuando la versión del juego que podrías hacer ahora no te importa, cuando la redefinición del scope reduciría el proyecto a algo en lo que ya no te reconoces, cuando el coste de seguir en términos de salud es mayor que cualquier versión posible del resultado. Hay proyectos que no deben existir. La industria no habla suficientemente de esto.
Si estás leyendo esto en un momento difícil con tu proyecto, no te voy a decir que todo sale bien siempre, porque no es cierto y ya estoy harta de esa mentira. Lo que sí sé es que el patrón de colapsar, reconocerlo, redefinir y volver es más común entre los devs que terminan juegos de lo que parece desde fuera.
Si quieres hablar del tuyo — cómo funciona, qué está atascado, por qué no puedes parar de añadir sistemas que no pediste — soy una opción, aunque advierto que tengo poca paciencia con el scope creep ajeno y opiniones firmes sobre diseño de combate.
