Gerenciamento de ativos, banco de dados ou sistema de versionamento?

Ao desenvolver os recursos do jogo (malhas, texturas, sons, vídeos), como você os gerencia?

1. Mantê-los juntos com o código-fonte dentro do sistema de controle de versão? (forçosamente, git, etc.)
2. Ou ter um banco de dados central com backup dedicado aos ativos e fazer com que os editores sempre funcionem gostaram? (PostgreSQL, MySQL, etc ...)
3. De outros?

Quais são os prós e os contras de cada um, e por que um deve escolher sobre o outro / s?

Para muitos de nós - especialmente trabalhando em jogos menores -, você absolutamente deve ter ativos no mesmo repositório que sua fonte .

A sugestão de que os ativos pertencem a um repositório separado faz sentido apenas para conjuntos muito grandes de ativos ou para conjuntos um pouco grandes de ativos quando há um limite de mecanismo / dados claramente definido. A menos que haja uma razão técnica específica para isso - é um mau conselho!

Você deseja que seu controle de versão se comporte como controle de versão . Você deseja retroceder e avançar rapidamente, ramificar e mesclar revisões e ainda ter seu jogo funcionando. E seu código e ativos vai depender um do outro.

Por exemplo: Seu código pode esperar ser capaz de definir um parâmetro em um sombreador, e esse sombreador pode depender da existência de uma textura. Ou talvez o formato dos dados dos seus níveis possa depender de uma versão específica do código do seu jogo.

Quase certamente ficará confuso. E você tem coisas melhores a fazer do que tentar mantê-lo organizado.

Agora, como Mike Wagner comentou ( nesta resposta ) - você não deseja nem precisa de todas as versões "em andamento" de seus ativos sob controle de versão! Apenas a versão final / de trabalho, conforme usada pelo seu código, serve - geralmente é isso que você exporta da sua ferramenta.

(Embora se você deseja controlar a versão das versões em andamento dos ativos - tudo bem. E adequado para um repositório separado. Pessoalmente, acho que basta uma boa organização de pastas e um sistema de backup adequado.)

Dito isto - às vezes é bom ter a opção de manter os ativos "em andamento" sob controle de versão. Normalmente, isso envolve ter um pipeline de conteúdo que possa lidar com qualquer etapa de 'exportação' para você - por exemplo: nivelar uma imagem de várias camadas para uma única textura.

Sistema de versionamento.

Com uma abordagem do tipo "faça você mesmo", você acabaria implementando um sistema de controle de versão, então é melhor usar um que já tenha anos de ciclos de projeto / código / teste.

Mantenha os ativos em um repositório separado da origem, para facilitar o mínimo de tempo de checkout / sincronização e tomar decisões diferentes sobre quanto histórico manter (embora o espaço em disco seja barato, mantenha tudo sempre que possível. mudar muito ao longo da vida de um projeto).

Marcar arquivos XML como ferramentas binárias de mesclagem tendem a ser muito ruins na mesclagem de marcações aninhadas e os artistas provavelmente não encontrarão marcações quebradas se a ferramenta achar que não há conflitos.

Se você puder, organize uma verificação de sintaxe ou mesmo a construção de ativos em cada confirmação e rejeite a confirmação com um email de volta para a pessoa que confirmará se ela falhar; isso economizará muito tempo da equipe.

Tudo em um repositório, se você puder pagar em termos de tamanho. Ouvi falar de repositórios do Subversion nas proximidades de 1 TB. Atualmente, estamos um pouco abaixo dos 400 GB.

Além disso, os artistas fazem muito check-in de tudo, incluindo as 30 linhas gerais de um conceito; usamos árvores de pastas separadas para "ativos de origem" e "exportados" - os que entram no script de criação de ativos. Se o seu artista for atropelado por um ônibus amanhã, será necessário que alguém continue trabalhando em seus bens no dia seguinte, apenas olhando no repositório (sem arqueologia em sua máquina pessoal). Era uma vez quando os jogos eram 2D ​​e os sprites eram pré-renderizados a partir de cenas complexas animadas do Max, tivemos que enviar um monte de unidades em um jogo RTS com uma aparência um pouco ruim e muito inconsistente (vs. o resto das unidades), até embora fosse uma questão de re-renderizar com configurações de iluminação e antialiasing ligeiramente diferentes - porque o artista original havia desistido e não tínhamos suas cenas originais de Max. Don '