Conspiratio.Lib
2.3.0
Il s'agit de l'état actuel de la bibliothèque de classe C # .NET Framework 4.6.2 avec la logique de gameplay de Conspiratio, supprimée du client Conspiro WinForms. Le Bibiliothek n'est pas encore terminé, mais contient déjà les classes et méthodes les plus importantes et peut servir de bloc de construction de base pour le client Unity.
Le projet a été créé avec: Visual Studio 2019
Ouvrez et compilez simplement le dossier du projet Conspiratio.Lib.sln pour la construction manuelle.
Le projet de fans intitulé "Conspiration" est une simulation économique libre des temps modernes, qui est fortement basé sur le jeu culte "Die Fugger 2".
Au début, le joueur hérite d'une installation de production délabrée et de la modeste économie d'un parent. Il peut l'utiliser pour démontrer ses compétences en tant que marchand en fabriquant et en vendant des marchandises, en réalisant des investissements bien et en s'affirmant comme un exportateur intelligent. Le joueur peut utiliser la richesse nouvellement acquise et l'influence associée:
Mais soyez prudent! Même certains concurrents ne hésiteront pas aux choses ...
L'objectif est une réécriture de la surface et du portage ainsi que de la refactorisation de la logique de gameplay et de l'ensemble de l'architecture de la version actuelle de Windows Forms à un jeu d'unité, car nous avons beaucoup plus de multimédia et, surtout, des options graphiques et il y a une certaine indépendance de la plate-forme. Ce nouveau client Unity sera entièrement open source, nous aimerions simplement inclure d'autres personnes dans la coopération et le co-développement et le projet de loisirs devrait devenir un projet communautaire, les fans des fans.
Les problèmes de GitHub devraient servir à planifier et à contrôler le développement.
Voulez-vous participer à ce projet? Super! Il suffit de nous contacter via Discord ou Oldschool par e-mail et nous clarifions les détails.
Toute aide est la bienvenue.
IMPORTANT: Nous ne nous engageons jamais et ne poussons jamais directement dans la branche principale!
La raison en est simplement un manque de transparence et un principe à 4 yeux manquant ou un manque de contrôle par au moins un autre développeur.
Une nouvelle branche personnelle doit toujours être créée pour chaque changement à complot. Le nom de l'industrie doit toujours commencer par l'un des noms suivants, suivi d'une barre oblique:
Exemple: corrigez / crash et surfette
De plus, les umlauts et les caractères spéciaux doivent être évités et l'espace ne peut pas non plus être utilisé en raison de restrictions techniques dans le nom de l'industrie, c'est pourquoi nous utilisons les lignes de liaison ici à la place.
Si votre propre branche est alors stable et contient toutes les modifications / extensions souhaitées, une demande sur la fusion peut être créée dans la branche maître. Cela doit toujours être attribué à un autre développeur pour examen, ce qui fait une petite revue de code, éventuellement des commentaires au code, puis fusionne également la branche après la réparation. Les propres succursales ne doivent être composées que dans des cas exceptionnels (par exemple, l'urgence temporelle).
En tant que directives de codage pour C #, nous utilisons la référence suivante en particulier pour le nouveau code, car elle a maintenant prévalu comme norme:
https://docs.microsoft.com/de-de/dotnet/csrogramming-guide/inside-a-a-program/coding-conventions
En ce qui concerne la dénomination et les normes, cette référence est également utilisée:
https://www.dofactory.com/reference/csharp-coding-standards
Veuillez noter que nous utilisons l'allemand comme langue des commentaires dans le code et également la plupart des identifiants, car toute la base de code existante est déjà construite en allemand. Bien sûr, tous les mots clés de chaque méthode ne doivent pas être complètement allemands, par exemple, GetUmsatzProSpieler seraient complètement légitimes (puisque GET devrait simplement être standard pour chaque développeur), mais quelque chose comme GetVolumeOfSalesPerPlayer serait problématique, car nous ne trouvons pas ce qui signifie ailleurs, ni dans la surface de jeu ni dans le code existant et donc il peut y avoir rapidement ce qui signifie.
L'ancien code peut et doit être progressivement converti à ces directives afin qu'il n'y ait pas de confusion plus tard, mais au début, ce n'est pas la priorité la plus élevée. Mais si vous modifiez ou refactorisant le code plus ancien, vous devez faire l'effort et appliquer les nouvelles directives ici, selon la devise Scout:
Laissez toujours un endroit (code) en meilleur état que vous ne l'avez trouvé.
La documentation des fonctionnalités étendues ou d'autres méthodes, classes intéressantes, etc. se déroule dans le code du wiki GitHub. Le Wiki GitHub ne devrait servir que la documentation technique et non la documentation pour les joueurs, il y aura un wiki.
Tout d'abord: nous utilisons beaucoup de ce concept ici: https://keepachangelog.com/de/1.0.0/
Le Changelog est maintenu dans le fichier Changelog.md, ici même dans la racine. Il est important que chaque changement soit documenté ici, toujours dans le domaine de "non publié". Inversement, cela signifie que chaque demande de traction doit toujours contenir des modifications du fichier ChangeLog, sinon elle n'est pas complète.
Dans le changelog, nous utilisons les groupes suivants pour diviser les changements:
