Git para Desenvolvimento de Jogos

14 de março de 2012 Ao longo dos anos, utilizei diversos sistemas de controle de versão para produção de filmes e jogos: CVS, Perforce e até algumas ferramentas internas. Eles sempre me pareceram males necessários, porém desajeitados – indispensáveis para acompanhar o trabalho em grandes projetos, mas também uma fonte constante de confusão, gargalos e inflexibilidade na produção.

O Git chamou minha atenção pela primeira vez há cerca de seis meses. Ele parecia incrivelmente poderoso e flexível. Os desenvolvedores da Massively Fun já o utilizavam para desenvolvimento de código quando ingrei na equipe. Eu estava ansioso para ver se conseguiríamos adaptá-lo à produção de arte.

Este post conta a história do que aconteceu depois.

Contexto: O que é o Git? O Git é um sistema de controle de versão distribuído. Quase todos no setor de desenvolvimento de jogos já devem estar familiarizados com pelo menos outro sistema de controle de versão, como Subversion ou Perforce.

Assim como esses outros sistemas, o Git nos permite acompanhar as muitas versões diferentes de todos os arquivos que compõem um projeto. No entanto, Subversion e Perforce são sistemas centralizados – todos os arquivos são enviados (check-in) ou baixados (check-out) de um repositório hospedado em um servidor central. O Git é diferente. Ele não depende de um servidor central.

Cada usuário obtém uma cópia completa de todo o repositório, com todo seu histórico e revisões. Esse design traz várias implicações importantes, a maioria delas positivas. Mas, aos meus olhos, o que mais destaca o Git é como ele torna as operações de branch e merge quase triviais.

Relacionado: Unity Asset Store — Arte, ferramentas e modelos prontos que vão direto para o seu projeto Unity.

Você pode criar um branch para trabalhar em alguma ideia experimental, outro para corrigir algum problema não relacionado e ainda outro para uma nova funcionalidade. É possível alternar rapidamente entre esses diferentes branches e mesclá-los conforme necessário. É uma funcionalidade incrivelmente útil.

Obstáculos Apesar de seus muitos pontos fortes, o Git pronto para uso apresenta duas falhas óbvias para a produção de arte: Não é amigável para artistas. A interface padrão do Git é a linha de comando.

Há muitos comandos e opções para aprender, além de conceitos subjacentes que diferem o suficiente de outros sistemas de controle de versão a ponto de gerar confusão. A documentação é abundante, mas frequentemente difícil de entender. Tudo isso resulta em um pacote pouco acessível e somewhat intimidador. Não foi projetado para gerenciar os grandes arquivos binários que os artistas criam.

Se você estiver comprando: Construct 3 — Mecanismo HTML5 sem código baseado em navegador que exporta para web, dispositivos móveis e desktop.

O fato de cada repositório local conter todo o histórico e revisões significa que muitos arquivos de arte em rápida evolução podem consumir muito espaço em disco rapidamente. Desenvolvemos soluções para ambos esses problemas.

A Interface Importa Existem várias boas interfaces gráficas para o Git. Os artistas ainda precisam compreender os conceitos básicos do Git, mas um front-end bem projetado torna a adoção e o uso consideravelmente mais fáceis.

Descobrimos que o SourceTree, da Atlassian, funcionou perfeitamente em nosso ambiente baseado em Mac: é poderoso, intuitivo e gratuito (por enquanto) – uma consideração importante para uma startup enxuta. A equipe do SourceTree também respondeu prontamente (< 12 horas) às nossas consultas de suporte enviadas via Twitter.

Uma Extensão Elegante para o Git O Git-media aborda as limitações do Git no que diz respeito a grandes arquivos binários. É uma extensão do Git que permite armazenar arquivos fora do repositório Git. O Git ainda rastreia as versões dos arquivos; apenas armazena o conteúdo dos arquivos em algum lugar fora do repositório. Planejávamos armazenar nossos grandes binários na nuvem Amazon S3.

Não Tão Rápido Usar o SourceTree com o Git-media, no entanto, apresenta uma pegadinha: transferir arquivos entre nossos repositórios e a Amazon S3 exige a execução de um comando de shell; ou seja, $ git media sync. Um fluxo de trabalho que obriga os artistas a sair do relativo conforto de uma aplicação gráfica para digitar comandos de shell não é amigável para artistas.

O SourceTree oferece uma maneira de executar esse comando como uma ação personalizada, mas isso não era suficiente. Os artistas ainda teriam que lembrar de executá-lo nos momentos apropriados. Mais cedo ou mais tarde, eles esqueceriam, e alguém perderia um tempo valioso descobrindo o que deu errado e corrigindo o problema. Como poderíamos fazer o SourceTree e o Git-media trabalharem harmoniosamente juntos?

Relacionado: JetBrains Rider — IDE .NET/C# multiplataforma com suporte de primeira classe para Unity e Unreal Engine.

Git Wrap Escrevemos um script wrapper genérico que opcionalmente executa alguns outros comandos antes e/ou após o próprio comando git. Configuramo-lo para chamar automaticamente ‘git media sync’ antes ou depois de comandos que interagem com um repositório remoto, conforme apropriado. Configuramos o SourceTree para invocar o wrapper em vez do Git padrão. O código-fonte do wrapper está disponível aqui no Github.

A Aventura Continua Gostaria de dizer que essa foi o fim da história, que o SourceTree e o Git-media trabalharam juntos perfeitamente e todos vivemos felizes para sempre. De fato, eles funcionaram, até certo ponto.

Infelizmente, não foi bom o suficiente. O SourceTree normalmente faz um bom trabalho ao visualizar arquivos de imagem. Isso é crucial para os artistas ao fazer commit ou mesclar alterações nesses arquivos. Mas usar o Git-media quebrou a capacidade do SourceTree de visualizar esses arquivos, pois significava que não estávamos mais armazenando as imagens no Git; estávamos armazenando apenas informações de versão sobre as imagens.

Favorito do leitor: Amazon: Game Dev Books & Gear — Livros de programação de jogos, teclados mecânicos, monitores e hardware de mesa de desenvolvimento.

Não conseguimos encontrar uma solução aceitável para isso; foi um impasse. Até o momento desta publicação, estamos fazendo outra tentativa com o recurso de submódulos do Git. Armazenar nossos ativos de arte em um submódulo é outra maneira de minimizar o tamanho do repositório principal do projeto.

O SourceTree compreende e oferece suporte razoável a submódulos, e sua capacidade de visualizar imagens permanece intacta. Os submódulos têm algumas idiossincrasias, mas nada que pareça demasiado disruptivo para o fluxo de trabalho dos nossos artistas. Fique atento a este espaço para atualizações; informaremos como as coisas se desenrolarão.

comentários do blog powered by Disqus