Hometopia

Situación

Hometopia es un sandbox multijugador de construcción y decoración de casas. Cuando entré como desarrollador de UI/UX llevaba cuatro años en desarrollo y le quedaba uno para salir en Early Access. Muchos programadores habían pasado por el proyecto y se habían ido. La base de código arrastraba años de deuda técnica: problemas de rendimiento, fallos de iluminación y posprocesado, y bugs de los que nadie se hacía cargo.

Mi trabajo de UI fue bien. Los cimientos del juego, no. El lanzamiento en Early Access fue demasiado ambicioso y salió mal: malas reseñas, jugadores con problemas y un equipo bajo presión.

Después la dirección técnica se marchó y despidieron a la mayor parte del equipo. El estudio pasó de 15 personas a 5.

Qué hice

Me quedé. Los cinco decidimos que el juego merecía seguir vivo, y yo pasé a ser el lead programmer de facto.

Primero, estabilizar. Rendimiento y cierres inesperados antes que nada. Object pooling, streaming de LOD, atlas de texturas y consolidación de materiales pusieron la memoria bajo control. Se arreglaron la iluminación y el posprocesado. El contenido que el equipo ya no podía mantener se recortó en vez de dejarlo a medio romper.

Reconstruir el multijugador. La persona contratada para el multijugador había reportado avances que no existían. Cuando salió a la luz, construí el sistema desde cero en menos de un mes sobre Netcode for GameObjects con Steamworks, con los compañeros probando cada build. El juego tiene una gran cantidad de objetos colocables, así que la sincronización de estado tenía que ser compacta y fiable.

Arreglar los sistemas de debajo. Reescribí el sistema de guardado con una serialización compacta, segura para red y preparada para Steam Workshop. Implementé deshacer y rehacer sobre un framework de comandos determinista. Migré la entrada al Input System de Unity. Construí herramientas de editor a medida para que diseñadores y artistas configuraran objetos sin un programador.

Hacer aburridos los lanzamientos. Ramas en Plastic SCM, automatización con Unity Cloud Build y un pipeline de miniaturas sobre Addressables. Una cadencia estándar de actualizaciones: una grande cada uno o dos meses y parches pequeños entre medias.

Mantener al equipo trabajando. Hice de mentor de los ingenieros junior durante la recuperación, y seguimos adelante con un publisher que una y otra vez metía gente en el equipo y la volvía a sacar.

Resultado

• Cierres por memoria eliminados y consumo de memoria bajo control.
• Multijugador publicado, construido en menos de un mes.
• Un ritmo de actualizaciones previsible con el que los jugadores podían contar: una grande cada uno o dos meses y parches entre medias.
• Un equipo pequeño que mantuvo vivo y en mejora un proyecto que se hundía, hasta que se retiró la financiación y el desarrollo se detuvo. El juego sigue en Early Access.

No fue un trabajo de arquitectura desde cero. Fue un rescate: heredar una base de código con problemas, sobrevivir a un colapso y mejorar las cosas mientras se publicaba para los jugadores cada pocas semanas.

Stack

Unity, C#, Netcode for GameObjects, Steamworks, Addressables, Plastic SCM, Unity Cloud Build.