Dwarf Fortress adota controle de versão após dez anos de recusa

Três citações de Tarn Adams, separadas por dez anos, mostram uma trajetória rara no setor: o autor de uma das simulações mais complexas da história dos games primeiro recusou abertamente o sistema de controle de versão e, em 2023, passou a usá-lo. O desenvolvedor e blogueiro Simon Willison reuniu essas declarações numa linha do tempo e observou, com certo pesar, que os dias sem version control, pelo visto, acabaram.

Três citações, uma evolução

Em março de 2013, respondendo a perguntas no Reddit num AMA, Adams explicou que não gostava da sensação de "commitar o código numa caixa-preta sem benefício imediato". A motivação é compreensível e muito humana: a ferramenta exige disciplina desde o primeiro dia, mas sua utilidade só aparece no momento da catástrofe.

Em março de 2016, numa entrevista à PC Gamer, ele foi além. Segundo Adams, quem não sabe o que é version control não vai gritar com ele, mas quem sabe pergunta: "O que há de errado com vocês? Como é que vocês trabalham?" Ele admitiu que "simplesmente não foi feito para isso" e que, ao longo de 15 anos, os motivos mudaram, mas o resultado continuou o mesmo.

Em março de 2023, numa entrevista à Game Developer sobre a preparação do lançamento oficial de Dwarf Fortress na Steam, apareceu outra fala: é preciso acompanhar os canais do Discord e "usar version control", e por isso o processo ficou "definitivamente um pouco mais complicado".

Por que justamente este código

O que mais surpreende Willison, nas palavras dele, é o seguinte: dada a complexidade interna de Dwarf Fortress, é difícil imaginar uma base de código que precisasse mais de controle de versão. O jogo simula um mundo, sua história e personagens individuais, e qualquer alteração pode quebrar uma cadeia de dependências num ponto inesperado. Trabalhar durante anos num projeto assim, sem histórico de alterações e sem poder reverter mudanças, pode de fato ser chamado de arte. Willison, aliás, chama exatamente assim.

Um detalhe importante: as citações não permitem saber quando exatamente ocorreu a transição, qual ferramenta é usada nem quem a introduziu. Sabe-se apenas que, na primavera de 2023, o controle de versão já fazia parte do fluxo de trabalho.

O que mudou: Steam e dinheiro

A citação de março de 2023 refere-se ao período posterior à chegada do jogo à Steam. De acordo com a PC Gamer, esse lançamento tornou os autores milionários depois de 20 anos de trabalho na simulação. Willison brinca que ficou um pouco frustrado: os desenvolvedores "desistiram" antes de chegar a esse marco, mas a trajetória em si impressiona.

Há uma explicação plausível à mão, embora seja uma interpretação, e não um fato extraído das citações: o projeto passou a ter mais participantes, mais processos e mais compromissos externos. Para uma pessoa sozinha, com um único computador, o histórico de alterações parece burocracia. Para uma equipe com ciclo de lançamentos e um produto comercial, ele é questão de sobrevivência.

Principais marcos

• Março de 2013, AMA no Reddit: recusa do version control por causa da "caixa-preta sem benefício imediato".
• Março de 2016, PC Gamer: "Eu simplesmente não fui feito para isso"; o desenvolvimento já durava cerca de 15 anos.
• Março de 2023, Game Developer: version control mencionado como parte do trabalho diário, junto com os canais do Discord.
• O lançamento na Steam, segundo a PC Gamer, transformou os autores em milionários.
• Desconhecidos: a data exata da transição e a ferramenta usada.

Lição prática para desenvolvedores

A história de Dwarf Fortress ilustra bem que a ausência de version control é algo que se consegue suportar, mas não escalar. Num projeto individual, é questão de hábito; para uma equipe, é questão de sobrevivência.

Se você trabalha com agentes de IA para código, o argumento fica ainda mais forte. Um agente pode reescrever dezenas de arquivos numa única sessão, e sem um commit limpo antes de iniciá-lo não há como reverter o resultado. O conjunto mínimo de práticas: fazer commit antes de cada sessão com o agente, manter um branch separado para cada tarefa e revisar o diff antes de aceitar as alterações. Adams passou dez anos provando que dava para viver sem isso. Mas ele próprio acabou desistindo dessa posição.