Conspiratio.Lib

Conspiratio.lib

これは、Conspiratio Winformsクライアントから削除されたConspiratioのゲームプレイロジックを備えたC＃.NETフレームワーク4.6.2クラスライブラリの現在のステータスです。 Bibiliothekはまだ完全ではありませんが、すでに最も重要なクラスと方法が含まれており、Unityクライアントの基本的な構成要素として機能します。

パッケージ

建てる

プロジェクトは、Visual Studio 2019で作成されました

手動ビルドのために、プロジェクトフォルダーConspiratio.Lib.slnを開いてコンパイルするだけです。

システムの要件 /依存関係

• .NETフレームワーク4.6.2

ゲームの陰謀について

「陰謀」と呼ばれるファンプロジェクトは、現代の自由な経済シミュレーションであり、カルトプレイ「Die Fugger 2」に強く基づいています。

当初、プレーヤーは老朽化した生産施設と親relativeの控えめな節約を継承します。彼はそれを使用して、商品を製造して販売することで、商人としてのスキルを実証し、よく考えられている投資をしたり、賢い輸出業者として自分自身を主張したりすることができます。プレイヤーは、新しく獲得した富と関連する影響を使用できます。

• さらなる生産施設を取得するために、
• タイトルと特権を取得するには、
• スパイと妨害者を送るために
• 尊敬される現職を操作するには、
• または、強力な役人になることさえあります。

しかし、注意してください！一部の競合他社でさえ、問題を避けません...

このリポジトリについて

目標は、表面と移植の書き直しと、ゲームプレイロジックと現在のWindowsフォームバージョンからUnityゲームまでのアーキテクチャ全体の再作用です。この新しいUnityクライアントは完全にオープンソースになります。協力と共同開発に他の人を単に含め、ホビープロジェクトはコミュニティプロジェクト、ファンのファンになるはずです。

GitHubの問題は、開発を計画および制御するのに役立つはずです。

参加してください

このプロジェクトに参加したいですか？素晴らしい！ DiscordやOldschoolを介して電子メールでお問い合わせください。詳細を明確にしてください。
どんな助けも大歓迎です。

gitワークフロー

重要：マスターブランチに直接コミットしてプッシュすることはありません！
その理由は、少なくとも別の開発者による透明性の欠如と4目の原則の欠落またはコントロールの欠如です。

陰謀への変更ごとに、新しい個人的なブランチを常に作成する必要があります。業界の名前は、常に次の名前のいずれかから始まり、次にスラッシュが続く必要があります。

• 改善（=ゲームのコードまたは機能の改善、リファクタリング）
• 修正（=修正）
• 機能（=ゲームの新しい機能）

例：修正/クラッシュと過剰

さらに、Umlautsと特殊文字は避けるべきであり、業界名の技術的な制限のためにスペースを使用することもできないため、代わりにここで拘束力のあるラインを使用します。

自分のブランチが安定しており、すべての目的の変更/拡張機能が含まれている場合、マージのリクエストをマスターブランチに作成できます。これは常に別の開発者に試験するために割り当てられる必要があります。これは、小さなコードレビューを行い、おそらくコードにフィードバックを提供し、修理後にブランチを統合する可能性があります。独自の枝は、例外的な場合のみで構成されている必要があります（たとえば、時間的緊急性）。

コードガイドライン

C＃のコーディングガイドラインとして、特に新しいコードに次のリファレンスを使用します。これは、標準として優先されているためです。
https://docs.microsoft.com/de-de/dotnet/csrogramming-guide/inside-a-a-program/coding conventions

命名と標準に関して、この参照も使用されます。
https://www.dofactory.com/reference/csharp-coding-standards

既存のコードベース全体がすでにドイツ語で構築されているため、コード内のコメントの言語としてドイツ語を使用していることに注意してください。もちろん、すべての方法のすべてのキーワードが完全にドイツ語である必要はありません。たとえば、 GetUmsatzProSpielerは完全に合法であること（GETは単にすべての開発者にとって標準である必要があるため）ですが、 GetVolumeOfSalesPerPlayerのようなものは問題があります。

古いコードは、これらのガイドラインに徐々に変換される可能性があります。そうすることで、後で混乱はありませんが、最初は最優先事項ではありません。ただし、古いコードを変更またはリファクタリングする場合は、スカウトモットーによると、ここで新しいガイドラインを適用して、ここに新しいガイドラインを適用する必要があります。
常に場所（コード）を見つけたよりも良い状態にしてください。

ドキュメント

広範な機能またはその他の興味深い方法、クラスなどのドキュメントは、GitHub Wikiのコードで行われます。 Github Wikiは、技術文書のみを提供する必要があり、プレイヤーのドキュメントではなく、Wikiがあります。

Changelog

まず第一に、このコンセプトから多くを使用しています：https：//keepachangelog.com/de/1.0.0/

Changelogは、changelog.mdファイルに維持されています。すべての変更がここで文書化され、常に「未発表」の領域で文書化されることが重要です。逆に、これは、すべてのプル要求が常に変更ログファイルの変更を含める必要があることを意味します。そうでなければ、完全ではありません。

Changelogでは、次のグループを使用して変更を分割します。

• 拡張機能
• 変更
• 修正
• バランス