Contribuer au SDK
Les problèmes du SDK se signalent dans les issues du dépôt bullet-hero/sdk, et les modifications du code s'y envoient en pull requests. Les règles pour les contributeurs se trouvent dans le même dépôt, à côté du code
Le dépôt est bullet-hero/sdk, la branche par défaut est master
Où signaler
| À propos de quoi | Où |
|---|---|
| le SDK et son code | bullet-hero/sdk/issues |
| le jeu : bugs et demandes des joueurs | bullet-hero/releases/issues |
| le texte de la documentation | bullet-hero/docs |
Où sont les règles
Les règles pour les contributeurs se trouvent dans le dépôt du SDK lui-même, à côté du code qu'elles décrivent :
| Fichier | Ce qu'il contient |
|---|---|
| README.md | dépendances, paquets de niveaux, compilation de la DLL et du paquet, l'exemple de vérification |
| CLAUDE.md | le modèle mental, un index des dossiers et les conventions de toute la bibliothèque |
CLAUDE.md dans chaque dossier | les règles locales de ce dossier, par exemple Serialization, Validations, Publishing |
| Docs/VERSIONING.md | axes de version, générations, migration et refus |
| Docs/IDENTIFIERS.md | comment le modèle adresse les entités : Guid, int, image, chemin de champ |
| Politique de licence des niveaux des joueurs (sur ce site) | la politique de licences du contenu des utilisateurs, modifiée en même temps que TrustedSourceCatalog |
| Versions/README.md | comment écrire un instantané et un migrateur |
| Generators/README.md | le contrat des générateurs |
| Roslyn/README.md | les analyseurs et le générateur de modèles, comment les recompiler |
| UnityIntegration/README.md | le contrat de double compilation |
| CHANGELOG.md | les changements par version sv, la plus récente en haut |
Compilation et tests
dotnet build -c Release BH.SDK.csproj
dotnet test Tests/BH.SDK.Tests.csproj
dotnet pack -c Release BH.SDK.csproj
- ici, les mêmes sources que compile Unity sont compilées sans Unity. Un fichier qui rompt le contrat d'indépendance vis-à-vis du moteur casse cette compilation
- la sortie va dans
bin~etobj~ - la commande pack ne fait que créer un
.nupkg. La publication sur nuget.org est faite par le workflowreleasedu dépôt quand un tagsvest poussé
Les analyseurs et le générateur de modèles sont livrés sous forme de BH.SDK.Roslyn.dll précompilé à la racine du SDK. Après avoir modifié quoi que ce soit dans Roslyn/, recompile-le et copie-le par-dessus. Sinon, l'ancien générateur continue de tourner, même si les sources disent autre chose
cd Roslyn
dotnet build BH.SDK.Roslyn.csproj -c Release
cp bin~/Release/BH.SDK.Roslyn.dll ../BH.SDK.Roslyn.dll
dotnet test Tests~/BH.SDK.Roslyn.Tests.csproj -c Release
Dans l'éditeur Unity, l'élément de menu Tools > BH.SDK.Roslyn > Build Analyzer fait la même chose
Invariants à connaître d'avance
- le cœur ne référence pas un seul type de
UnityEngine. Le code qui a besoin du moteur va dansUnityExtensions/ou dansUnityIntegration/derrière#if BHSDK_UNITY, avec une branche sans moteur - le code fonctionne de la même façon avec des fichiers et avec des données en mémoire et n'utilise que l'asynchronisme de la BCL
netstandard2.1et C# 9 sont ce avec quoi compile le projet Unity. On ne les monte pas- un modèle est une
[GenerateModel] public sealed partial class. Chaque champ sérialisé prend sa clé dansNames.cs - toute modification d'un modèle est une nouvelle génération avec un instantané et un migrateur. Plus - Versions et migrations
- la version du SDK vit à trois endroits :
SdkVersion.cs,package.jsonet<Version>dansBH.SDK.csproj.SdkVersionAgreementTestséchoue si l'un d'eux a bougé seul