Travail d'équipe dans l'unité

J'ai un projet Unity sans aucun contrôle de version et je dois le partager avec un autre développeur afin que nous puissions tous les deux travailler sur le projet.

Quelles stratégies devraient être utilisées qui fonctionnent bien avec Unity Assets?

Unity dispose d'une fonction intégrée pour prendre correctement en charge le contrôle de version.

Allez simplement dans Fichier-> Paramètres du projet-> Éditeur et activez le contrôle de version externe.

Je recommande d'utiliser Git, c'est gratuit et le meilleur autour.

Il y a quelque temps, j'ai écrit sur le contrôle de version (en utilisant Git) sur mon blog

Longue histoire courte:

Activez le contrôle de version externe Fichier-> Paramètres du projet-> Éditeur et créez le fichier .gitignore afin d'éviter des choses inutiles sur le dépôt (ce n'est pas vraiment nécessaire, mais cela n'aura pas de prix pendant le développement).

Voici à quoi devrait ressembler le fichier:

[Oo]bj/
[Tt]emp/
[Ll]ibrary

#These are files in the root folder of the project
*.tmproj
*.csproj
*.unityproj
*.sln
*.suo
*.user
*.pidb
*.userprefs

Unity 3.0 est configuré pour jouer correctement avec subversion. (Au moins plus agréable qu'avant) Je ne sais pas si c'est uniquement dans la version pro ou non, je vais devoir vérifier.

En général cependant, le système de contrôle de version le plus recommandé est le Unity Asset Server.

Spécifique à Unity - travaillez à tout moment sur différentes scènes et différents fichiers de code et fusionnez manuellement les modifications de l'autre personne. Si vous devez tous les deux travailler sur la même scène, dupliquez-la et utilisez la copie comme test. Sinon, si vous modifiez tous les deux la même scène, les changements d'une personne remplaceront l'autre. Vous pouvez toujours utiliser le contrôle de code source pour vos fichiers source, mais ne les déplacez pas du tout, dans le système de fichiers ou via Unity, une fois qu'ils ont été créés.

Conseils aux débutants - procurez-vous un outil de diff / fusion décent (j'aime WinMerge ) et habituez -vous à l'utiliser pour voir les modifications apportées par l'autre personne et pour fusionner manuellement les modifications dans les fichiers en conflit. Mettre en place un espace de documentation central, par exemple. un document écrit par Google ou un wiki, et conservez votre documentation là-bas - la documentation devrait contenir une liste de fonctionnalités de base au minimum afin que vous sachiez ce que vous visez, et idéalement une liste de tâches dérivée de la liste de fonctionnalités, avec une indication claire de qui travaille sur la tâche. Parlez-vous les uns aux autres pour avoir une idée approximative de qui doit travailler sur quelle tâche et rayez-les de la liste au fur et à mesure. Continuez à revoir et à réévaluer la liste pour voir si tout est toujours valide et si vous avez besoin de retravailler des priorités.

Je travaille avec une équipe qui se fait appeler Defective Studios. Nous avons lutté avec le même problème pendant des années, et tout récemment, j'ai finalement cédé et commencé à écrire une extension pour m'aider à fusionner les objets de jeu.

Fondamentalement, l'approche consiste à créer une interface de type inspecteur dans une fenêtre qui aligne chaque objet de jeu, composant et propriété côte à côte pour comparaison, et fournit des boutons pour copier des valeurs (ou des objets entiers) d'un côté à l'autre. Si vous connaissez la SerializedPropertyclasse, c'est ce qui fait la majeure partie du travail ici. Nous créons essentiellement une interface graphique qui synchronise l'état de dépliage entre le côté droit et le côté gauche, et crée un espace vertical partout où un GameObjectouComponentn'existe que du côté droit ou gauche. Une fonction de comparaison vérifie l'égalité à chaque niveau et transforme l'arrière-plan de chaque ligne en rouge ou vert en fonction de l'état de l'égalité. Toute ligne dont les enfants contiennent une différence deviendra également rouge, et nous avons également inclus un bouton astucieux pour rechercher récursivement l'arborescence et développer tous les objets qui sont différents ou qui ont des différences dans leurs enfants.

De plus, il existe un ensemble de champs de masque qui vous permettent de filtrer certains types de composants hors de la comparaison. Les attributs GameObject comme le nom, la couche et la balise sont également comparés. Nous utilisons SerializedObjectet SerializedPropertypour parcourir les gameObjectpropriétés de, et les dessiner exactement comme ils sont dessinés dans l'inspecteur. Cela garantit la cohérence et est beaucoup plus facile à coder!

Un dernier détail intéressant est que le processus de comparaison (déclenché lorsque les objets sont chargés et chaque fois qu'un changement est effectué) est exécuté dans une coroutine ad hoc qui est mise à jour par la EditorWindow.Updatefonction, de sorte que si vous comparez un objet extrêmement compliqué, la fenêtre ne verrouille pas l'éditeur. C'était un must lors de la comparaison d'objets avec des centaines (ou des milliers!) D'enfants. Dans l'ensemble, c'était une sorte de "projet lego" comme mon ami aime à le dire, mais certainement un outil inestimable qui est instantanément devenu une partie de notre flux de travail de collaboration.

L'outil, Unity Merge est documenté sur le wiki Unify, qui comprend une feuille de route et une adresse e-mail pour les commentaires et les rapports de problèmes. Si vous êtes vraiment aux prises avec une fusion compliquée, essayez-la et dites-nous ce que vous en pensez! De plus, je n'ai pas pris la peine de le construire dans une DLL, alors n'hésitez pas à fouiller à la source. L'implémentation et les SerializedPropertymanipulations ad hoc de coroutine , ainsi que quelques astuces d'interface graphique dont j'ai fini par avoir besoin sont une grande partie de votre boîte à outils d'extension d'éditeur. Je suis très intéressé par les changements / améliorations que les utilisateurs pourraient avoir, alors contactez-moi!

Si vous avez les fonds nécessaires, le serveur d'actifs avec la version pro de Unity est assez décent. Je l'ai utilisé dans le cadre d'un grand projet pluriannuel dans le passé et il a fait le travail. Pour le contrôle de la version vanilla, il a fait ce que nous attendions.

J'ai essayé d'utiliser un référentiel SVN avec un projet Unity et c'était un peu compliqué. Cependant, nous avons fini par abandonner l'idée avant de la faire fonctionner. Unity conserve un grand nombre de fichiers de sauvegarde que je ne voulais pas prendre le temps de découvrir ce qui se passerait s'ils n'étaient pas synchronisés avec le serveur. Je pense qu'avec un peu de finesse, cela pourrait être faisable, mais je n'ai pas d'expérience avec le bon fonctionnement.

J'ai réalisé un petit projet en utilisant les fonctionnalités gratuites de DropBox. Cela m'a rendu nerveux mais nous n'avons jamais eu de problème. Et, je ne pense pas que nous ayons fini par avoir besoin de véritables éléments de contrôle de version pour ce projet, donc je ne peux pas parler beaucoup de la façon dont la restauration ou la fusion de fichiers aurait été.

Dropbox prend en charge la gestion des versions par fichier (plutôt que par commit) et fonctionne parfaitement avec Unity. Il est gratuit au départ (2 gigaoctets) et assez bon marché par la suite (environ 10 $ pour 50gig). Vous avez besoin de l'addon PackRat pour avoir accès à l'historique des versions.

Tout comme avec SVN, CVS, GIT, etc., vous devrez vous assurer de créer des dossiers de balises lorsque vous arriverez à chaque étape clé du développement (par exemple, fin de semaine, fin de jalon). Contrairement à ce qui précède, il sera beaucoup plus difficile de revenir à une telle étape si vous ne le faites pas, car vous devrez annuler chaque fichier individuellement. Gardez cela à l'esprit lors du développement et vous passerez un moment facile sans payer pour le serveur d'actifs.