# Guide de développement pour [Khaganat](https://khaganat.net) Ce manuel est rédigé collaborativement en Markdown à l’adresse suivante : ## Sources et inspirations Très inspiré par et basé sur le « [Gamemakin](https://gamemak.in) UE4 Style Guide » disponible sur [GitHub](https://github.com/Allar/ue5-style-guide). Godot propose quelques conseils sur la façon de travailler pour son propre projet dans une section [Les meilleures pratiques](https://docs.godotengine.org/fr/stable/tutorials/best_practices/index.html) ainsi qu’un [Guide de style](https://docs.godotengine.org/fr/stable/development/editor/editor_style_guide.html#editor-style-guide) et un [Bonnes pratiques pour les contributeurs au moteur](https://docs.godotengine.org/fr/stable/community/contributing/best_practices_for_engine_contributors.html) destinés à celles qui souhaitent contribuer au développement du moteur lui-même. ## Principes de base ### Un manuel vivant Ce manuel a vocation à rendre la contribution plus efficace, Khaganat est ouvert à la discussion et possède un canal XMPP où on peut échanger sur tout cela : [https://khaganat.net/irc/](https://khaganat.net/irc/). ### Respectez la loi Khaganat respecte la loi française et vous demande de faire de même, donc merci de ne rien introduire d’illégal dans le projet par vos actions. En particulier : - ne réemployez pas le travail d’autrui si vous n’en avez pas reçu l’autorisation explicite - respectez les licences d’usage des éléments que vous souhaitez copier depuis un autre projet, en particulier si l’attribution est demandée (comme avec les licences CC BY) - avant d’y apporter des éléments externes, vérifiez-en la compatibilité avec les licences du projet Khaganat ## Terminologie ### Identifiants Un `Identifiant` est ce qu’on appelle communément un « nom » : celui d’un objet 3D, d’un fichier de son, d’un répertoire, d’une variable ou d’un script… #### Caractères autorisés dans les identifiants Dans un `Identifiant`, jamais on n’utilise un de ces caractères : * les espaces * les barres obliques ou barres obliques inverses `\`, `/` * des symboles du genre `#!@$%` * des caractères Unicode Un `Identifiant` ne doit donc comprendre que les caractères suivants : * ABCDEFGHIJKLMNOPQRSTUVWXYZ * abcdefghijklmnopqrstuvwxyz * 1234567890 * _ (avec parcimonie) Pour résumer, un `Identifiant` doit pouvoir répondre à l’expression régulière `[A-Za-z0-9_]+`) Ces règles permettent la plus grande compatibilité entre systèmes et pays. #### L’usage des casses Il y a plusieurs façon d’écrire les `Identifiants`, dont voici les plus courants (dénommés par leurs désignation en anglais, conventionnelle). ##### PascalCase On met une majuscule à chaque mot et on supprime les espaces : `Coffre avec poignees` devient `CoffreAvecPoignees`. ##### camelCase C’est similaire au PascalCase, sauf que la première lettre du premier mot est en minuscule : `Coffre avec poignees` devient `coffreAvecPoignees`. Plus de précisions sur [Wikipédia](https://fr.wikipedia.org/wiki/Camel_case). ##### snake_case Les espaces sont remplacés par des underscores « _ » : `Coffre avec poignees` devient `coffre_avec_poignees` Bien que par convention, on puisse choisir de mettre ou pas des majuscules aux mots, nous retenons l’idée de tout mettre en minuscule pour nos usages du snake_case. `Coffre avec poignees` devient donc `coffre_avec_poignees` Plus de précisions sur [Wikipédia](https://fr.wikipedia.org/wiki/Snake_case). ##### lisp-case / kebab-case Les espaces sont remplacés par des tirets (le signe moins) « - » : `Coffre avec poignees` devient `coffre-avec-poignees`. La désignation de cette casse n’est pas définitive, *kebab-case* semblant le plus fréquent, mais lisp l’utilise aussi depuis de très nombreuses années. #### Variables / Propriétés Les termes `Variable` et `Propriété` sont généralement interchangeables, mais si ils sont utilisés dans le même contexte, cela signifie plus précisément : - pour `Propriété` que cela désigne une variable dans une classe. - pour `Variable`, cela désigne généralement un argument de fonction ou une variable locale dans une fonction. Dans une classe, cela peut indiquer un statut à préciser/ définir. ## Les types de fichiers ### Godot - **.escn** : *Exported Scene Data*. Format utilisé pour exporter des scènes depuis Blender vers Godot. - **.gd** : *Source Code*. Fichiers avec le code source natif de Godot. - **.gdc** : *Compiled Script*. Fichiers compilés. - **.gdshader** : *Shader Data*. Shader spécifique à Godot (du GLSL modifié). - **.godot** : *Project. Fichier descriptif du projet. - **.import** : *Import Settings Data*. Fichier sidecar aux formats externes, qui contient les paramètres d’import. - **.material**: *Godot material*. Matériau. - **.mesh** : *Mesh Data*. Informations sur la géométrie d’un objet 3D. - **.meshlib** : *Mesh Library*. Catalogue de meshes. - **.oggstr** : *OGG Audio Data*. Fichier audio. - **.pck** : *Game Package*. Paquet de jeu - **.profile** : *Feature Profile Data* - **.res** : *Binary Resource Data*. Ressource binaire. - **.sample** : *Audio Sample Data*. Fichier audio. - **.scn** : *Binary Scene Data*. Scène sous forme binaire. - **.stex** : *Stream Texture Data*. - **.tpz** : *Export Template Archive*. - **.tres** : *Text Resource Data*. Fichier descriptif d’une ressource. - **.tscn** : *Text Scene Data*. Scène, élément de base d’un projet. ## Convention de nommage ### Noms de fichiers Indépendamment de leur extension, les fichiers peuvent comporter trois parties, séparées chacune de la précédente par un **underscore** : préfixe, corps et suffixe. Le préfixe et le suffixe sont déterminés par le type de fichier (son extension donc). #### Nommage des éléments internes aux fichiers ##### Blender Sauf indication contraire, tous les éléments internes aux fichiers Blender doivent être écrits en *kebab-case*. Le recours à un préfixe ou suffixe sera indiqué le cas échéant. ###### Collections Les objets destinés au jeu Khanat doivent être placés dans une collection nommée « khanat », située à la racine de la collection principale. ###### Objets Les *Objects* doivent être rassemblé dans des sous-collections pertinentes, et il faut veiller à ce que l’*Object Data qui y est associé soit nommé de façon identique.* #### Godot Les signaux doivent avoir un nom avec un verbe au passé, car cela indique un état qui vient d’être connu par l’émetteur. Les fonctions doivent commencer par un verbe, voire un verbe avec un auxiliaire si elles retournent un booléen (« is_green », « has_been_healed »). Les variables et les classes commencent généralement plutôt par un nom. ###### Export glTF Les objets à destination du mùoteur de jeu Godot doivent être exportés au format glTF. Il faut pour cela sélectionner tous les objets à exporter puis aller dans `File > Export > glTF`, avec les options suivantes à vérifier particulièrement : - `Format > glTF Embeddded`. - `Copyright : Khaganat`. - On peut cocher `Remember export settings` pour ne pas avoir à revérifier à chaque export de ces modèles. - `Include > Limit to Selected Objects` coché. - `Geometry > Apply modifiers` coché. Les autres options par défaut conviennent. ## Le suivi de version avec Git ### Le dépôt principal ### Forker sur gitlab / cloner en local ### Gestion des branches ### Le merge request ### Les commits #### Généralités Les messages de commit se rédigent en anglais de façon à faciliter la collaboration internationale. #### Rédaction des commits La rédaction des commits se base sur les [conventionnal commits](https://www.conventionalcommits.org/en/v1.0.0/#specification) avec des spécificités. Structure d’un message de commit : (portée, facultative): sujet (si élément suivant présent) Corps de description plus complète (un ou plusieurs paragraphes), facultatif (si élément suivant présent) , facultatif ##### Les _types_ Les types de commits possibles sont les suivants : - **fix** : résoud un bug qui doit être mentionné dans le titre/description avec un hashtag et son numéro de ticket (entraîne un changement de type _patch_ dans le versionnement). - **feat** : ajoute une fonctionnalité qui doit être mentionnée dans le titre/description avec un hashtag et son numéro de ticket (entraîne un changement de type _mineur_ dans le versionnement). - **ci** : concerne le fonctionnement de la CI du dépôt. - **docs** : reprise de la documentation du code sans toucher aux fonctionnalités. - **refactor** : refactorisation du code sans modifier son comportement, ajouter une fonctionnalité ou réparer un bug. - **style** : reprise formelle du code sans en modifier le fonctionnement (typos, espacements, tabulations etc.) Le cas échéant, il est possible d’ajouter de nouveaux types selon les besoins (se référer à [la convention Angular](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#type) par exemple). Le type doit être écrit en minuscule, sans espace. ##### La portée Indiquée entre parenthèses, en minuscule sans espace, elle permet de préciser éventuellement sur quel partie du code la modification porte. Elle peut être choisie dans cette liste : - **core** : concerne le code de base, les systèmes essentiels au fonctionnement du jeu - **ui** : concerne l’interface utilisateur - **shading** : concerne les shaders d’affichage - **ia** : concerne l’intelligence artificielle des créatures en jeu D’autres portées peuvent être ajoutées à la liste au fur et à mesure des besoins. ##### Rupture de compatibilité Si le commit entraîne une rupture de compatibilité dans le code, le type doit se voir accoler un point d’exclamation avant les deux points, quel que soit son type (entraîne un changement de type _majeur_ dans le versionnement).Il faut alors également lui ajouter un pied de page avec la mention « BREAKING CHANGE: » suivi de la mention de l’endroit où la rupture s’opère. ##### Le sujet Laissant une espace après les deux points, il ne comporte pas de majuscule au début ni de point à la fin. Le sujet doit décrire en peu de mot le changement qu’opère le nouveau code. Exemples de première ligne correcte : feat(ui)!: change methods for IG windows, close #18 fix(core): address collision problems for player, close #37 feat: add color wheel for windows background, close #16 ##### Corps de description Facultatif, il permet de décrire de façon détaillée ce qui a motivé les choix opérés et mettre l’emphase sur les améliorations espérées par rapport à l’ancien état. ##### Pied de page Il peut comporter deux éléments : - si le commit clôt un ticket, il faut indiquersur une ligne son numéro de la façon suivante : `« Close #58 »` - si le commit entraîne une rupture de compatibilité, il doit comporter une ligne avec la mention « BREAKING CHANGES » en majuscules. ### Projets Godot Il n’est pas utile de versionner le répertoire `.import/` situé à la racine d’un projet car son contenu peut être généré depuis les fichiers originaux et leur fichier de configuration annexe (avec l’extension `.import`, par exemple pour `icone.png` cela donne `icone.png.import`). Il convient donc d’ajouter le répertoire `.import/` dans le `.gitignore` comme c’est proposé dans [la documentation Godot](https://docs.godotengine.org/en/latest/tutorials/assets_pipeline/import_process.html#files-generated). ## License CC BY SA Khaganat - 2022