Gestion des actifs, base de données ou système de gestion des versions?

Lors du développement des actifs du jeu (maillages, textures, sons, vidéos) comment les gérez-vous?

1. Les garder ensemble avec le code source dans le système de gestion des versions? (forcément, git, etc…)
2. Ou avoir une base de données centrale sauvegardée dédiée aux actifs et avoir toujours le travail des éditeurs qui lui plait? (PostgreSQL, MySQL, etc…)
3. Autre?

Quels sont les avantages et les inconvénients de chacun, et pourquoi l'un devrait-il le choisir par rapport aux autres?

Pour beaucoup d'entre nous - en particulier pour les petits jeux - vous devez absolument avoir des actifs dans le même référentiel que votre source .

La suggestion que les actifs appartiennent à un référentiel séparé n'a de sens que pour de très grands ensembles d'actifs, ou pour des ensembles d'actifs assez grands lorsqu'il existe une frontière moteur / données clairement définie. À moins qu'il y ait une raison technique spécifique à cela - c'est un mauvais conseil!

Vous voulez que votre contrôle de version se comporte comme un contrôle de version . Vous voulez être en mesure de rembobiner et d'avancer rapidement, de créer des branches et de fusionner des révisions et de faire fonctionner votre jeu. Et votre code et actifs seront fonction de l'autre.

Par exemple: votre code peut s'attendre à pouvoir définir un paramètre sur un shader, et ce shader peut dépendre de la présence d'une texture. Ou peut-être que le format de données de vos niveaux peut dépendre d'une version particulière de votre code de jeu.

Cela deviendra presque certainement désordonné. Et vous avez mieux à faire que d'essayer de le ranger.

Maintenant, comme l'a commenté Mike Wagner ( sur cette réponse ) - vous ne voulez pas ou n'avez pas besoin de toutes les versions "en cours" de vos actifs sous contrôle de version! Seule la version finale / de travail, telle qu'utilisée par votre code, fera l'affaire - c'est souvent ce que vous exportez à partir de votre outil.

(Bien que si vous voulez contrôler les versions des versions en cours des actifs - c'est très bien. Et bien adapté à un référentiel séparé. Personnellement, je trouve qu'une bonne organisation des dossiers et un système de sauvegarde approprié suffisent.)

Cela étant dit - il est parfois agréable d'avoir la possibilité de simplement coller les actifs "en cours" sous le contrôle de la version. En règle générale, cela implique d'avoir un pipeline de contenu qui peut gérer toutes les étapes «d'exportation» pour vous - par exemple: aplatir une image multicouche en une seule texture.

Système de versioning.

Avec une approche roll-your-own, vous finiriez effectivement par rouler un système de versioning, donc mieux utiliser un système standard qui a déjà eu des années de conception / code / cycles de test.

Conservez les actifs dans un référentiel séparé de la source, afin de réduire au minimum les heures de paiement / synchronisation et de prendre différentes décisions sur la quantité d'historique à conserver (bien que l'espace disque soit bon marché, conservez-le tout autant que possible. Les textures individuelles ne ça change pas tant au cours de la vie d’un projet).

Marquez les fichiers XML comme binaires, les outils de fusion ont tendance à très mal fusionner le balisage imbriqué et les artistes ne sont pas susceptibles de repérer le balisage cassé si l'outil pense qu'il n'y a pas de conflits.

Si vous le pouvez, organisez une vérification de la syntaxe ou même la création d'actifs à chaque validation et rejetez la validation avec un e-mail à la personne qui s'engage en cas d'échec; cela permettra d'économiser beaucoup de temps d'équipe.

Tout dans un seul référentiel, si vous pouvez vous le permettre en termes de taille. J'ai entendu parler de référentiels Subversion à proximité de 1 To. Nous sommes actuellement un peu en dessous de 400 Go.

De plus, les artistes vérifient beaucoup tout, y compris les 30 grandes lignes d'un concept; nous utilisons des arborescences de dossiers distinctes pour les "ressources source" et pour "exportées" - celles qui entrent dans le script de création de ressources. Si votre artiste est heurté par un bus demain, vous devez pouvoir demander à quelqu'un de continuer à travailler sur ses actifs le lendemain, uniquement en parcourant le référentiel (pas d'archéologie sur sa machine personnelle). Il était une fois où les jeux étaient en 2D et les sprites étaient pré-rendus à partir de scènes Max animées complexes, nous avons dû expédier un tas d'unités dans un jeu RTS avec un look un peu merdique et très incohérent (par rapport au reste des unités), même bien qu'il s'agisse de restituer avec des paramètres d'éclairage et d'anticrénelage légèrement différents - parce que l'artiste d'origine avait quitté, et nous n'avions pas ses scènes Max originales. Don'