Dwarf Fortress adopta el control de versiones tras diez años de rechazo

Tres citas de Tarn Adams, separadas por diez años, cuentan una historia poco habitual en la industria: el autor de una de las simulaciones más complejas de la historia de los videojuegos rechazó abiertamente el control de versiones y, en 2023, ya lo utilizaba. El desarrollador y bloguero Simon Willison reunió esas declaraciones en una cronología y señaló, con cierta nostalgia, que los días sin control de versiones parecen haber terminado.

Tres citas, una evolución

En marzo de 2013, en un AMA de Reddit, Adams explicó que no le gustaba la sensación de hacer commit del código «en una caja negra sin beneficio inmediato». El motivo es comprensible y muy humano: la herramienta exige disciplina desde el primer día, pero su utilidad solo se hace evidente en el momento de la catástrofe.

En marzo de 2016, en una entrevista con PC Gamer, fue más lejos. Según sus palabras, quien no sabe qué es el control de versiones no le va a gritar, pero quien sí lo sabe le preguntará: «¿Qué les pasa? ¿Cómo trabajan, en realidad?». Adams admitió que «simplemente no estoy hecho para esto» y que, a lo largo de 15 años, las razones fueron cambiando, pero el resultado seguía siendo el mismo.

En marzo de 2023, en una entrevista con Game Developer sobre la preparación del lanzamiento oficial de Dwarf Fortress en Steam, apareció una frase distinta: hay que revisar los canales de Discord y «usar control de versiones», de modo que el proceso se ha vuelto «definitivamente algo más complicado».

Por qué precisamente este código

Willison plantea así su principal sorpresa: dada la complejidad interna de Dwarf Fortress, cuesta imaginar una base de código que necesitara más el control de versiones. El juego simula un mundo, su historia y a cada personaje por separado, y cualquier cambio puede romper una cadena de dependencias en un lugar inesperado. Trabajar durante años en un proyecto así, sin historial de cambios ni posibilidad de revertirlos, se puede calificar de verdadero arte. Willison, por cierto, lo llama exactamente así.

Un matiz importante: de las citas no se puede deducir cuándo se produjo el cambio, qué herramienta se utiliza ni quién la introdujo. Solo se sabe que en la primavera de 2023 ya formaba parte del flujo de trabajo.

Qué cambió: Steam y el dinero

La cita de marzo de 2023 corresponde al periodo posterior al lanzamiento del juego en Steam. Según PC Gamer, ese lanzamiento convirtió a los autores en millonarios tras 20 años de trabajo en la simulación. Willison bromea con que está algo decepcionado: los desarrolladores «se rindieron» antes de alcanzar ese hito, pero la carrera en sí resulta impresionante.

Hay una explicación plausible a mano, aunque es una interpretación y no un hecho extraído de las citas: el proyecto tiene ahora más participantes, más procesos y más compromisos externos. Para una sola persona con un solo ordenador, el historial de cambios parece burocracia. Para un equipo con ciclo de lanzamientos y un producto comercial, es imprescindible.

Hitos clave

• Marzo de 2013, AMA de Reddit: rechazo del control de versiones por ser una «caja negra sin beneficio inmediato».
• Marzo de 2016, PC Gamer: «Simplemente no estoy hecho para esto»; el desarrollo dura unos 15 años.
• Marzo de 2023, Game Developer: el control de versiones se menciona como parte del trabajo diario, junto con los canales de Discord.
• El lanzamiento en Steam, según PC Gamer, convirtió a los autores en millonarios.
• Se desconoce: la fecha exacta del cambio y la herramienta utilizada.

Conclusión práctica para desarrolladores

La historia de Dwarf Fortress ilustra bien que se puede sobrevivir sin control de versiones, pero no escalar sin él. En un proyecto individual es una cuestión de hábito; en un equipo, de supervivencia.

Si trabajas con agentes de IA para programar, el argumento es aún más contundente. Un agente puede reescribir decenas de archivos en una sola sesión y, sin un commit limpio antes de lanzarlo, no hay forma de revertir el resultado. Un conjunto mínimo de prácticas: hacer commit antes de cada sesión con el agente, mantener una rama independiente para cada tarea y revisar el diff antes de aceptar los cambios. Adams pasó diez años demostrando que se puede prescindir de todo esto. Pero al final fue él mismo quien dejó de hacerlo.