Contrôle de source pour tout stocker du projet de jeu?

Est-il habituel de gérer non seulement le code source, mais tous les actifs, textures, illustrations, fichiers de documentation, etc. sous le référentiel git pour le contrôle de version? Par exemple, je veux récupérer l'ancienne version de la texture. Si c'est une très mauvaise pratique, quels outils utilisez-vous pour le contrôle de version des actifs et d'autres choses?

Je dirais que c'est une très bonne pratique. Le contrôle de source doit être utilisé pour la source et les actifs. Vous pouvez y penser comme une sauvegarde, vous voulez pouvoir restaurer à partir du contrôle des sources tout ce qui est nécessaire pour construire votre jeu.

J'ai lié une question qui concerne le stockage d'actifs dans un référentiel. Il existe certains référentiels qui fonctionnent mieux que d'autres pour stocker de l'art. Ils vous permettront de "différencier" l'art et de voir ce qui a changé. D'autres traiteront simplement les actifs comme des données binaires, vous devrez donc les vérifier pour voir ce qui est différent. Cela signifie également que vous devrez télécharger l'intégralité de l'actif lorsqu'il change, car il ne sera pas possible pour le référentiel de «savoir» (analyser) ce qui a changé entre les versions.

Je stocke tout dans le référentiel. Lorsque j'ai obtenu mon nouvel ordinateur portable, j'ai pu consulter mon référentiel et créer mon jeu, sans avoir besoin de copier des actifs de n'importe où ailleurs. Cela signifie que je stocke également les bibliothèques, les actifs et le contrôle de source tiers dans mon référentiel.

Git n'est pas idéal pour les fichiers non textuels. Le clonage d'un référentiel git nécessite le téléchargement de toutes les versions historiques d'un fichier, sauf si vous utilisez une extension de gros fichier (non standard, souvent non prise en charge par les interfaces graphiques) ou des commandes spéciales (nécessite d'être un gourou git). Il en va de même pour la plupart des systèmes DVCS. Pour une texture, un modèle ou un clip audio, cela signifie extraire de nombreuses copies d'un fichier très volumineux. 1 Go d'actifs peut facilement représenter 200 Go de données de révision historiques, et git vous permet de tout télécharger lorsque vous clonez un nouveau référentiel, et de télécharger toutes les révisions intermédiaires lorsque vous récupérez la dernière. Cela devient un énorme goulot d'étranglement sur la route lorsque vous pouvez le moins tolérer les retards de production.

Subversion, Perforce, etc. sont de meilleurs choix pour les actifs, car ils ne nécessitent que le téléchargement de la révision souhaitée (la plus récente, généralement). Vous pouvez les utiliser uniquement pour les actifs et utiliser git pour le code, ou les utiliser également pour la source. Perforce a certaines fonctionnalités qui lui permettent d'agir comme un DVCS très maladroit, et est meilleure que la fonctionnalité SVN (bien que beaucoup plus complexe) selon mon expérience, mais le coût signifie que vous utiliserez probablement Subversion.

La plupart des professionnels du contenu ont peu besoin de DVCS, et certains ont même des problèmes avec les bases du VCS classique. Ne selle pas avec git. Ou Mercurial, DARCS, etc.

C'est une bonne pratique, même en tant qu'artiste lorsque vous travaillez sur un projet, il y a généralement une forme de contrôle de version, une corruption de fichiers ou des bugs, sans que les artistes de contrôle de source aient tendance à faire des sauvegardes de révision de toute façon, ce qui n'est qu'un énorme gâchis.

Un exemple concret que vous pouvez voir est les projets de films ouverts réalisés avec Blender (Big Buck Bunny, Durian, etc.)

Le pipeline d'art pour un jeu est plus ou moins le même, sauf qu'il peut y avoir une étape de construction pour les actifs eux-mêmes pour effectuer une conversion des données volumineuses au format spécifique au moteur, comme la compression de texture et la conversion de format de modèle.

Certains outils, comme GitHub, proposent même de bons outils de comparaison d'images, ce qui est beaucoup mieux que de comparer un blob binaire.

Puisqu'un référentiel d'actifs peut être absolument énorme, ma / notre préférence est de conserver un référentiel d'actifs séparé qui est un sous-module dans le référentiel du projet. Vous ne voulez pas tirer vers le bas des gigaoctets d'actifs alors que tout ce que vous voulez est de brancher la source par exemple.