Collaborer sur khanat-assets-sources - OpenNeL legacy

Ce dépôt concerne la création des éléments graphiques en 2D et en 3D qui serviront en jeu. Nous y concevons donc tous les fichiers qui seront ensuite passés au pipeline pour fournir les éléments nécessaires au système de jeu selon ses spécifications.

Nous y conservons les versions finales des fichiers qui ont servi à créer le résultat, dans le format nécessaire au pipeline (qui ira ensuite dans Collaborer sur Khanat assets - OpenNeL legacy). Mais nous y stockons également les versions préparatoires de façon à en faciliter l'éventuelle déclinaison ou transformation à l'avenir.

N'hésitez donc pas à y déposer les fichiers multicalques, les textures sources, les bibliothèques 3D etc. qui pourraient être réutilisées par la suite.

Pour commencer, il vous faudra forker le dépôt principal : khanat-assets-sources. Ainsi, vous aurez votre propre dépôt, sur lequel vous pourrez effectuer vos modification sans interférer avec le dépôt principal.

Pour cela, il vous suffit de clique sur le bouton suivant sur la page d’accueil du projet.

Vous serrez alors redirigé vers votre copie du dépôt.

Si vous êtes un développeur “officiel” chez nous, vous aurez accès au dépôt principal sur notre GitLab : khanat-assets-sources.

Vous n'aurez pas à créer un dépôt personnel (sauf si vous en avez envie) pour pouvoir contribuer, il vous suffira de travailler sur des branches en interne.

Khanat utilise un workflow simplifié.Les branches principales sont :

• Branche Master : Branche stable, qui contient toutes les données finales quiont été validées et qui ont permis de créer les assets en jeu.

• Branche feature/XXX_nom_de_la_feature : Branche contenant des données qui répondront à l'Issue XXX, en cours de travail.

Les branches feature, que ce soit sur votre fork ou sur les dépôts officiels, doivent être nommées de la façon suivante:

• Branche Feature : Doit être nommée “feature/[numéro(s) de(s) (l')issue][nom de la feature sans espaces ni ponctuation]”
  • Exemple : “feature/0014_reorganize_RC_env_tex”

Chaque dossier est numéroté en fonction de l'Issue à laquelle il répond, avec un nom descriptif. À l'intérieur de chacun de ces dossiers, il suffit d'avoir un répertoire /_final pour les fichiers finaux destinés au système de jeu et un autre /work pour les fichiers qui auront servi à les créer. À l'intérieur de ces deux répertoires, on peut organiser comme on veut.

Tant que le travail est en cours, accoler le suffixe _wip à son répertoire principal. Lorsque le travail est terminé, le dernier commit doit ôter ce suffixe.

Les fichiers dans le répertoire /_final doivent impérativement respecter les conventions de nommage des fichiers graphiques, et le format selon leur type.

Une fois que vous considérez la feature que vous avez développé terminée, vous pouvez créer une Merge Request, à destination de Master. Cette requête doit respecter ces impératifs :

• La Merge Request doit clairement expliquer en quoi elle répond à la feature

Lorsqu'on a terminé une Feature, il faut faire une demande de Merge Request en expliquant en quoi la tâche est terminée et l'affecter à une autre personne même si on a la capacité de merger directement.

Cela permettra d'avoir un contrôle, ne serait-ce que formel, sur l'ajout.

On ne merge jamais soi-même directement sur Master.

De préférence à la la base TAF, créez les demandes de travaux graphiques sur le système Gitlab de ce dépôt.

De même, avant de commencer une tâche, créez une Issue que vous vous attribuez, comme ça vous pouvez numéroter la branche correctement et on sait que quelqu'un a commencé à travailler sur ce sujet.

Cela peut concerner des créations graphiques en 2D pour l'interface (fenêtres, icônes ou pointeur de souris), de nouvelles textures, des objets à modéliser ou des animations à générer.

Les travaux à faire, modifications de fichier, créations, doivent être indiqués en se servant du système d'Issues de ce dépôt : Issue sur Khanat-assets-sources

Il suffit de cliquer sur :

Vous renseignez ensuite les différents champs.

Le titre doit être concis et le plus explicite possible.
Par contre, n'hésitez pas à être le plus précis possible dans la zone Description.

Il y a ensuite 3 zones de champs à renseigner :

• Assignee pour indiquer la personne à qui affecter la tâche ;
• Milestone qui désigne la version du projet pour laquelle ce travail devra être fait ;
• Labels permet de choisir des tags pour déterminer le genre de tâche ;
• Select due date propose de fixer une date de remise des travaux.

Dans le doute, n'indiquez rien dans ces quatre champs. De toute façon, tout est éditable a posteriori donc ce n'est pas grave si vous faites des erreurs ou n'êtes pas assez précis.

On se servira des mêmes milestones que pour les autres dépôts et secteurs de développement du projet, présentés sur la page milestones.

Nous n'utilisons pas de Tags sur ce dépôt Git pour le moment.

Les Labels doivent être génériques et concerner de préférence un type technique d'asset graphique et permettre ainsi de regrouper par genre de compétence. Il est possible d'en créer lors de la génération d'une Issue si aucune ne convient mais cela peut être fait par la suite, surtout quand on est indécis.