Git pour le développement de jeux
Massivement Fun Git pour le développement de jeux Git pour le développement de jeux 14 mars 2012 J’ai utilisé plusieurs systèmes de gestion de versions différents au fil des ans pour la production cinématographique et ludique : CVS, Perforce, et même quelques outils maison. Ils m’ont toujours semblé être des maux nécessaires mais lourdingues – indispensables pour suivre l’avancement d’un gros projet, mais aussi une source permanente de confusion, de goulots d’étranglement et de rigidité dans la production.
Git a fait son apparition sur mon radar il y a environ six mois. Il semblait incroyablement puissant et flexible. Les développeurs de Massively Fun l’utilisaient déjà pour le code lorsque j’ai rejoint l’équipe. J’étais impatient de voir si nous pouvions l’adapter à la production artistique.
Cet article raconte ce qu’il s’est passé ensuite. Contexte : qu’est-ce que Git ? Git est un système de gestion de versions distribué. La plupart des professionnels du jeu vidéo connaissent déjà au moins un autre système de ce type, comme Subversion ou Perforce.
Comme ces autres systèmes, Git nous permet de suivre les nombreuses versions différentes de tous les fichiers constituant un projet. Mais Subversion et Perforce sont des systèmes centralisés : tous les fichiers sont validés (check-in) ou extraits (check-out) depuis un dépôt hébergé sur un serveur central. Git fonctionne différemment.
Il ne dépend pas d’un serveur central. Chaque utilisateur obtient une copie complète de l’intégralité du dépôt, avec tout son historique et toutes ses révisions.
Cette conception a plusieurs implications importantes, dont la plupart sont positives. Mais ce qui distingue le plus Git à mes yeux, c’est la façon dont il rend les opérations de branche et de fusion presque triviales. Vous pouvez créer une branche pour travailler sur une idée expérimentale, une autre pour corriger un problème sans rapport, et encore une autre pour une nouvelle fonctionnalité. Vous pouvez basculer rapidement entre ces différentes branches et les fusionner selon vos besoins.
Connexes : — Illustrations, outils et modèles prêts à l'emploi qui s'intègrent directement dans votre projet Unity.
C’est une fonctionnalité incroyablement utile. Obstacles Malgré ses nombreux atouts, Git tel quel présente deux défauts évidents pour la production artistique : Il n’est pas adapté aux artistes.
L’interface par défaut de Git est la ligne de commande. Il y a beaucoup de commandes et d’options à apprendre, ainsi que des concepts sous-jacents suffisamment différents des autres systèmes de gestion de versions pour prêter à confusion. La documentation est abondante mais souvent difficile à comprendre. Tout cela forme un ensemble peu accessible et quelque peu intimidant.
Il n’est pas conçu pour gérer les gros fichiers binaires produits par les artistes. Le fait que chaque dépôt local contienne tout l’historique et toutes les révisions signifie qu’une grande quantité d’œuvres artistiques en évolution rapide peut rapidement occuper beaucoup d’espace disque. Nous avons trouvé des solutions à ces deux problèmes.
Notre sélection : — Cours à la demande couvrant la programmation Unity, Unreal, C++, C# et shader.
L’interface compte Il existe plusieurs bonnes interfaces graphiques pour Git. Les artistes doivent toujours comprendre les concepts de base de Git, mais une interface bien conçue rend l’outil considérablement plus facile à prendre en main et à utiliser. Nous avons découvert que SourceTree d’Atlassian fonctionnait parfaitement dans notre environnement basé sur Mac : il est puissant, intuitif et gratuit (pour l’instant) – un point important pour une start-up débrouillarde.
L’équipe de SourceTree a également répondu rapidement (< 12 heures) à nos demandes de support publiées sur Twitter. Une extension Git astucieuse Git-media remédie aux lacunes de Git concernant les gros fichiers binaires.
C’est une extension Git qui vous permet de stocker les fichiers en dehors de Git. Git continue de suivre les versions des fichiers ; il stocke simplement leur contenu ailleurs que dans le dépôt. Nous avions prévu de stocker nos gros fichiers binaires dans le cloud Amazon S3. Pas si vite Utiliser SourceTree avec Git-media présente toutefois un piège : le transfert de fichiers entre nos dépôts et Amazon S3 nécessite l’exécution d’une commande shell, c’est-à-dire : $ git media sync Un flux de travail obligeant les artistes à quitter le confort relatif d’une application graphique pour taper des commandes shell n’est pas adapté aux artistes.
SourceTree offre bien un moyen d’exécuter cette commande en tant qu’action personnalisée, mais cela ne suffisait pas. Les artistes devraient toujours se souvenir de l’exécuter aux moments appropriés.
Tôt ou tard, ils oublieraient, et quelqu’un perdrait un temps précieux à déterminer ce qui n’allait pas et à le corriger. Comment faire en sorte que SourceTree et Git-media collaborent harmonieusement ? Git Wrap Nous avons écrit un script d’enveloppe générique qui exécute éventuellement d’autres commandes avant et/ou après la commande Git elle-même. Nous l’avons configuré pour appeler automatiquement ‘git media sync’ avant ou après les commandes interagissant avec un dépôt distant, selon le cas.
Nous avons configuré SourceTree pour invoquer ce script d’enveloppe plutôt que Git tel quel. Le code source de l’enveloppe est disponible ici sur Github. L’aventure continue J’aimerais pouvoir dire que c’était la fin de l’histoire, que SourceTree et Git-media fonctionnaient parfaitement ensemble et que nous vécûmes heureux et eûmes beaucoup d’enfants.
Ils ont effectivement fonctionné, jusqu’à un certain point. Hélas, ce n’était pas suffisant. SourceTree fait généralement un bon travail de prévisualisation des fichiers image.
Cela est crucial pour les artistes lorsqu’ils valident ou fusionnent des modifications sur ce type de fichiers. Mais l’utilisation de Git-media a compromis la capacité de SourceTree à prévisualiser ces fichiers, car cela signifiait que nous ne stockions plus les images dans Git ; nous ne stockions que les informations de version relatives aux images.
Nous n’avons trouvé aucune solution acceptable à ce problème ; c’était rédhibitoire. Au moment où j’écris ces lignes, nous tentons une nouvelle approche avec la fonctionnalité de sous-modules de Git. Stocker nos ressources artistiques dans un sous-module est une autre façon de minimiser la taille du dépôt principal du projet. SourceTree comprend et prend assez bien en charge les sous-modules, et sa capacité à prévisualiser les images reste intacte.
Les sous-modules présentent certes certaines idiosyncrasies, mais rien qui ne semble trop perturbateur pour le flux de travail de nos artistes. Restez à l’écoute pour des mises à jour ; nous vous tiendrons informés de l’évolution de la situation. commentaires du blog propulsés par Disqus
Créez des jeux HTML5 dans votre navigateur
Moteur HTML5 sans code basé sur un navigateur qui exporte vers le Web, les appareils mobiles et les ordinateurs de bureau