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

29

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?

NocturnDragon
la source
Bonne question. Je suis assez intéressé à entendre comment les autres abordent cela.
David McGraw
1
Pour plus d'informations sur le contrôle de version: gamedev.stackexchange.com/questions/480/… et gamedev.stackexchange.com/questions/245/… Je ne pense pas que ce soit un doublon car il s'agit spécifiquement d'actifs
Sean James

Réponses:

22

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.

Andrew Russell
la source
10

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.

l'ombre de la lune
la source
2
Convenu de conserver les actifs artistiques et les actifs de code dans des référentiels séparés. Vous pouvez également constater que les artistes sont plus réticents à vérifier quelque chose que les codeurs, et pas nécessairement parce qu'ils trouvent le système intimidant. Ils peuvent avoir 30 grandes lignes d'un concept et ne pas vouloir le soumettre avant de l'avoir réduit à quelque chose qu'ils aiment. Prenez cela en compte dans le pipeline de production. S'il y a un directeur technique qui respire dans le cou pour vérifier tout, il passera plus de temps dans le repo que dans les ébauches.
Casey Wagner
1
Sur le marquage des fichiers XML comme binaires: si votre VCS autorise des outils de différenciation distincts, demandez-lui d'utiliser quelque chose qui se spécialise dans la différence XML pour les fichiers XML. Cela peut aider à éviter un balisage cassé étrange.
Jeff
+1 à ce sujet. :) Les actifs appartiennent à leur propre référentiel - s'ils le sont dans un référentiel. Peut-être en utilisant un logiciel de dépôt d'actifs dédié? Spécifiquement créé à cet effet, au lieu d'essayer de l'adapter aux systèmes de contrôle de version conçus pour un contenu principalement textuel.
jacmoe
8

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'

Unsigner
la source
1
Vote positif pour la mention de "facteur de bus")
Kromster dit soutenir Monica le