Sobrevivir a un colapso de equipo: qué aprendí cuando todo se vino abajo
Entré en Hometopia como desarrollador UI. En un año, el equipo pasó de 15 a 5 personas, y acabé siendo el programador líder. Esto es lo que me enseñó sobre persistencia, pragmatismo y publicar juegos.
Entré en Hometopia como desarrollador UI. El juego llevaba cuatro años en desarrollo, con aproximadamente un año hasta Early Access. La UI estaba hecha un desastre, y necesitaban a alguien que la arreglara.
Lo que no sabía era que me quedaría durante el colapso del equipo, acabaría siendo el programador líder, y aprendería más sobre desarrollo de juegos en dos años que en los cuatro anteriores.
Cómo empezó
Cuando entré, el equipo era de unas siete personas. El juego era ambicioso—un sandbox de decoración de casas multijugador con construcción, personalización y funciones sociales. Tenía potencial, pero bajo el capó, la cosa pintaba mal. Cuatro años de desarrollo con manos técnicas entrando y saliendo habían dejado el código lleno de deuda técnica.
Mi trabajo era la UI. Trabajé con el director del juego y los artistas, arreglando flujos rotos y eliminando UX frustrante. Esa parte fue bien. Pero podía ver los problemas más profundos: problemas de rendimiento, bugs de iluminación, sistemas que apenas se sostenían.
El liderazgo técnico estaba quemado. Algunos parecían que ya les daba igual. Empecé a señalar los problemas que veía, y poco a poco, la gente empezó a escuchar.
El colapso
Early Access se lanzó. No fue bien.
El lanzamiento fue demasiado ambicioso. Las reseñas fueron duras. Los jugadores encontraron bugs y problemas de rendimiento. La situación era mala.
Lo que vino después fue peor. El liderazgo técnico se fue. El publisher empezó a hacer recortes. El equipo pasó de quince personas a cinco.
Me quedé.
¿Por qué me quedé?
¿Sinceramente? Creía en el juego. Debajo de todos los problemas, Hometopia era genuinamente divertido. El core loop funcionaba. El arte era encantador. Solo necesitaba a alguien que arreglara lo que estaba roto.
Los cinco que quedamos tomamos una decisión: no íbamos a dejar morir este juego. Recortaríamos lo que no pudiéramos mantener, arreglaríamos lo que se pudiera, y sacaríamos actualizaciones para los jugadores que seguían ahí.
La recuperación
Establecimos un ritmo sostenible. Una actualización grande cada mes o dos, parches más pequeños entre medias. Nos enfocamos en lo fundamental: rendimiento, estabilidad, bugs que afectaban de verdad a los jugadores.
Acabé tocando de todo. Optimización de memoria, porque el juego iba mal en máquinas de gama baja. Arreglos de iluminación y post-procesado que llevaban meses rotos. Nuevas funcionalidades de gameplay que pedían los jugadores. DevOps, porque alguien tenía que mantener los builds funcionando.
La relación con el publisher fue difícil. Querían progreso más rápido, más gente. Sabíamos que la base de código no podía con eso—ya lo habíamos intentado, y la gente nueva se volvía productiva justo a tiempo para que la reasignaran a otro sitio. Mantuvimos la cabeza agachada y nos centramos en lo que podíamos controlar.
La crisis del multijugador
Entonces llegó el problema del multijugador.
Trajimos a alguien que supuestamente tenía experiencia con networking. Trabajó en ello durante semanas. Cuando por fin probamos su implementación, no funcionaba. Se había estado inventando los informes de progreso.
Tuvimos que despedirlo, y de repente el multijugador era problema mío.
Construí todo el sistema desde cero en menos de un mes. Netcode for GameObjects, integración con Steamworks, todo. Mis compañeros ayudaron con las pruebas, pero la arquitectura era mía. Se publicó, y funcionó.
Fue entonces cuando dejé de verme como “solo un desarrollador de UI.”
Qué aprendí
La persistencia importa más que el currículum. No me contrataron para ser el líder. Me convertí en el líder porque me quedé cuando otros se fueron e hice lo que había que hacer.
Los equipos pequeños pueden moverse más rápido que los grandes. Con cinco personas, no teníamos sobrecarga de coordinación. Todos sabían en qué estaban trabajando los demás. Las decisiones se tomaban en minutos, no en reuniones.
Recorta lo que no puedas mantener. Eliminamos funcionalidades que consumían recursos sin aportar valor. Dolió, pero nos permitió centrarnos en hacer sólida la experiencia principal.
La deuda técnica es una elección. No siempre tuya, pero aun así tienes que lidiar con ella. La pregunta no es si abordarla, sino qué partes abordar y cuándo.
Publica algo. A los jugadores les dan igual tus luchas internas. Les importa si el juego funciona y si está mejorando. Las actualizaciones regulares, incluso las pequeñas, generan confianza.
El final
El juego sigue en Early Access. Al final se retiró la financiación, y el desarrollo se detuvo. Esa es la realidad de la industria—a veces el buen trabajo no basta.
Pero no me arrepiento de haberme quedado. El equipo que aguantó convirtió un proyecto fallido en algo estable y jugable. Publicamos docenas de actualizaciones. Arreglamos problemas que llevaban años rotos. Y aprendí que puedo con prácticamente cualquier cosa que un proyecto me lance.
A veces la habilidad más valiosa es la persistencia.