La structure des répertoires dans Construct 2
Puisque vous aurez affaire à des fichiers individuels dans les répertoires du projet, cela vaut la peine de savoir comment est structuré le projet et à quoi sert chaque répertoire et fichier. Voici la structure générale d'un projet :
Pour commencer, le fichier principal du projet est un fichier .caproj (en réalité un simple fichier XML) à la racine. Le fichier .uistate est un autre fichier XML qui enregistre séparément l'état de l'interface de l'utilisateur, comme par exemple les onglets ouverts. Ceci est enregistré dans un fichier séparé dans la mesure où vous n'avez pas envie de le partager. Avoir à historiser un changement pour le reste de l'équipe juste parce que vous avez interverti un onglet, n'est pas nécessaire et une source possible de problèmes, donc Construct 2 sauvegarde délibérément ces informations de façon séparée pour que vous puissiez l'exclure. Fondamentalement, le fichier est pour vous seulement et n'a aucun intérêt pour le reste de l'équipe.
Le répertoire Animations stocke les animations d'objets de type Sprite. Chaque objet Sprite possède un sous-dossier avec son nom, et dans celui-ci un répertoire avec les noms de ses différentes animations, avec à l'intérieur les fichiers PNG pour chaque image de l'animation, numérotées à partir de zéro comme toujours. Par exemple, un Sprite nommé "Ennemi" abvec une seule animation nommée "Default" comprenant 3 images, aurait la structure suivante :
\Animations\Ennemi\Default\000.png
\Animations\Ennemi\Default\001.png
\Animations\Ennemi\Default\002.png
Notez que si vous ajoutez, supprimez ou renommez les objets, les animations ou les images, les fichiers et dossiers du projet sont mis à jour en conséquence.
Le répertoire Event sheets stocke un fichier XML pour chaque feuille d’événement (event sheet). Comme pour le projet principal, chaque feuille d’événement possède aussi un fichier .uistate qui ne devrait pas être partagé.
Aucun sous-dossier n'est créé dans le dossier du projet, même si vous organisez des feuilles d'événement dans des sous-dossiers de Construct 2. Notez également que si vous renommez une feuille d'événement, ses fichiers correspondants seront renommés.
Le dossier Layouts fonctionne de manière très similaire au dossier Event sheets ; c'est une simple liste de fichiers XML par layout, avec un fichier .uistate qui ne doit pas être partagé.
Le dossier Textures stocke les images pour les objets qui ont des images mais pas d'animations, comme l'objet Tiled Background. Chaque objet a un fichier PNG correspondant à son image dans ce dossier, par exemple TiledBackground.png. Notez que si vous renommez l'objet, le fichier image est également renommé.
Enfin le répertoire Files stocke tous les autres fichiers du projet, tels que les sons, les musiques, et tout autre fichier projet importé.
Principes de contrôle de la source
L'image ci-dessous montre l'architecture de base d'un système de contrôle de source :
Le serveur a la copie maîtresse du projet. C'est la version avec les changements de tout le monde fusionné en un seul endroit.
Les clients ont leurs propres copies indépendantes du projet, appelées leur copie de travail . Cela signifie que les modifications de chaque membre de l'équipe n'affectent pas immédiatement le serveur et que les autres membres de l'équipe ne peuvent pas voir immédiatement ce qu'ils ont modifié. Si un membre de l'équipe a terminé une unité de travail et souhaite fusionner ses modifications, il exécute un commit de ses modifications sur le serveur, et son travail est fusionné. Une fois que les modifications sont dans la copie maîtresse du projet hébergée sur le serveur, les autres membres de l'équipe peuvent effectuer une mise à jour pour télécharger les nouvelles modifications apportées, à leur propre copie de travail.
Un flux de travail typique dans une seule session de travail ressemble à peu près à ceci :
1. D'abord une mise à jour pour obtenir la dernière version du projet.
2. Vous effectuez vos modifications.
3. Une fois terminé, valider les modifications sur le serveur (commit).
Après la validation, la prochaine fois que chaque membre de l'équipe met à jour , il recevra ces modifications de la part du serveur.
Si vous apportez des modifications puis mettez à jour sans valider, vos modifications seront annulées et remplacées par la copie du serveur. Habituellement, le système de contrôle de la source vous avertit avant que cela n'arrive.
Le principal problème avec ce processus est les conflits : lorsque deux personnes changent la même partie d'un projet en même temps, puis effectuent un commit. La première personne peut valider les modifications, mais lorsque la seconde personne lance un commit, le serveur remarquera que ses modifications entrent en conflit avec la modification précédente et l'empêcheront. Ils devront d'abord lancer une mise à jour, fusionner les autres changements (ou simplement écraser leurs propres changements), puis recommencer. Nous allons décrire cela en détail plus tard. Si tout le monde ne travaille que sur des parties séparées du projet, ou tout du moins se coordonne pour s'assurer que deux personnes ne changent pas la même chose en même temps, vous devriez être capable d'éviter la plupart des conflits.
Notez que le serveur peut être, et est souvent, sur l'ordinateur d'un membre de l'équipe. Dans ce cas, il existe toujours une copie distincte du projet sur son ordinateur pour le serveur. Par conséquent, l'ensemble du processus s'applique également à ce membre de l'équipe. Il exécute également le serveur.
Les membres de l'équipe peuvent se connecter sur un réseau local, ce qui signifie qu'aucun équipement supplémentaire n'est nécessaire, mais ils ne peuvent pas valider ou mettre à jour si l'ordinateur serveur est éteint. Vous pouvez également configurer un système dédié permanent pour exécuter le serveur ou héberger des serveurs sur Internet.