Controle de origem para armazenar tudo do projeto do jogo?

É usual gerenciar não apenas o código-fonte, mas todos os ativos, texturas, arte, arquivos de documentação etc. no repositório git para controle de versão? Por exemplo, quero voltar à versão antiga da textura. Se for uma prática muito ruim, que ferramentas você usa para controle de versão de ativos e outras coisas?

Eu diria que é uma prática muito boa. O controle da fonte deve ser usado para a fonte e os ativos. Você pode pensar nisso como um backup, você deseja restaurar do controle de origem tudo o necessário para criar seu jogo.

I ligada a uma pergunta que é sobre o armazenamento de ativos em um repositório. Existem alguns repositórios que funcionam melhor que outros para armazenar arte. Eles permitirão que você "diferencie" a arte e veja o que mudou. Outros apenas tratam os ativos como dados binários, então você terá que verificar para ver o que é diferente. Isso também significa que você precisará fazer o upload do ativo inteiro quando ele mudar, pois não será possível que o repositório "saiba" (analise) o que mudou entre as versões.

Eu guardo tudo no repositório. Quando comprei meu novo laptop, pude verificar meu repositório e criar meu jogo, sem a necessidade de copiar quaisquer ativos de qualquer outro lugar. Isso significa que eu também armazeno as bibliotecas, ativos e controle de origem de terceiros no meu repositório.

Git não é ótimo para arquivos que não são de texto. A clonagem de um repositório git requer o download de todas as versões históricas de um arquivo, a menos que seja usada uma grande extensão de arquivo (não padrão, geralmente não suportada por GUIs) ou comandos especiais (requer ser um git guru). O mesmo vale para a maioria dos sistemas DVCS. Para uma textura, modelo ou clipe de áudio, isso significa obter muitas cópias de um arquivo muito grande. 1 GB de ativos pode ser facilmente 200 GB de dados históricos de revisão, e o git faz o download de tudo quando você clona um novo repositório e baixa todas as revisões intermediárias ao obter as mais recentes. Isso se torna um grande gargalo no caminho, quando você pode tolerar menos atrasos na produção.

Subversion, Perforce e assim por diante são melhores opções para ativos, pois exigem apenas o download da revisão desejada (a mais recente, geralmente). Você pode usá-los apenas para ativos e git para código, ou também para fonte também. O Perforce possui alguns recursos que permitem que ele funcione como um DVCS muito desajeitado e é melhor que a funcionalidade SVN (embora muito mais confusa) na minha experiência, no entanto, o custo significa que você provavelmente usará o Subversion.

A maioria dos profissionais de conteúdo tem pouca necessidade de DVCS, e alguns têm problemas com o básico do VCS clássico. Não fique com o git. Ou Mercurial, DARCS, etc.

É uma boa prática, mesmo como artista quando você está trabalhando em um projeto, costuma haver alguma forma de controle de versão, corrupção de arquivos ou bugs, sem que os artistas de controle de origem tendam a salvar as revisões de qualquer maneira, o que é uma grande bagunça.

Exemplo do mundo real que você pode ver é o de filmes abertos feitos com o Blender (Big Buck Bunny, Durian, etc)

O pipeline de arte para um jogo é mais ou menos o mesmo, exceto que pode haver uma etapa de construção para os próprios ativos fazerem alguma conversão de big data para formato específico do mecanismo, como compactação de textura e conversão de formato de modelo.

Algumas ferramentas, como o GitHub, oferecem ótimas ferramentas de comparação de imagens e similares, o que é muito melhor do que comparar um blob binário.

Como um repositório de ativos pode ser absolutamente enorme, minha / nossa preferência é manter um repositório de ativos separado, que é um submódulo no repositório do projeto. Você não deseja reduzir gigabytes de ativos quando tudo o que você quer é ramificar a fonte, por exemplo.