Conspiratio.Lib
2.3.0
هذا هو الحالة الحالية لمكتبة فئة C# .NET Framework 4.6.2 مع منطق اللعب لـ Conspiratio ، تمت إزالته من عميل Conspiratio Winforms. لم يكتمل Bibiliothek بعد ، ولكنه يحتوي بالفعل على أهم الفئات والأساليب ويمكن أن يكون بمثابة لبنة أساسية لعميل الوحدة.
تم إنشاء المشروع مع: Visual Studio 2019
ببساطة فتح وتجميع مجلد المشروع Conspiratio.Lib.sln للبناء اليدوي.
مشروع المعجبين يسمى "Conspiratio" هو محاكاة اقتصادية مجانية للأوقات الحديثة ، والتي تعتمد بقوة على مسرحية عبادة "Die Fugger 2".
في البداية ، يرث اللاعب منشأة إنتاج متهالكة وتوفير متواضع لأحد الأقارب. يمكنه استخدامه لإظهار مهارته كتاجر من خلال صنع وبيع البضائع ، والاستثمارات التي يتم التفكير فيها بشكل جيد أو يؤكد نفسه كمصدر ذكي. يمكن للاعب استخدام الثروة المكتسبة حديثًا والتأثير المرتبط:
لكن كن حذرا! حتى بعض المنافسين لن يخجلوا من الأمور ...
الهدف هو إعادة كتابة السطح والنقل وكذلك إعادة تشكيل منطق اللعب والهندسة المعمارية بأكملها من إصدار Windows Forms الحالي إلى لعبة الوحدة ، نظرًا لأن لدينا المزيد من الوسائط المتعددة ، وقبل كل شيء ، خيارات رسومية وهناك استقلال معين من النظام الأساسي. سيكون عميل الوحدة الجديد هذا مفتوح المصدر تمامًا ، ونود ببساطة تضمين أشخاص آخرين في التعاون والتطوير المشترك ويجب أن يصبح مشروع Hobby مشروعًا مجتمعيًا ، والمشجعين للجماهير.
يجب أن تعمل قضايا جيثب على التخطيط والتحكم في التطوير.
هل تريد المشاركة في هذا المشروع؟ عظيم! فقط تواصل معنا عبر Discord أو Oldschool عبر البريد الإلكتروني ونوضح التفاصيل.
أي مساعدة موضع ترحيب.
هام: نحن لا نلتزم ودفعها مباشرة إلى الفرع الرئيسي!
والسبب هو مجرد نقص في الشفافية وفقدان مبدأ 4 عيون أو عدم السيطرة من قبل مطور آخر على الأقل.
يجب دائمًا إنشاء فرع شخصي جديد لكل تغيير إلى Conspiratio. يجب أن يبدأ اسم الصناعة دائمًا بواحد من الأسماء التالية ، يليه مائل:
مثال: إصلاح/تحطم وتفوق
بالإضافة إلى ذلك ، يجب تجنب 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 سيكون مشكلة ، لأننا نجد مثل هذه المصطلحات في أي مكان آخر ، ولا في سطح اللعبة ، وبالتالي يمكن أن يكون هناك سرعان ما يمكن أن يكون هناك يعني.
يمكن وينبغي أن يتم تحويل الكود القديم تدريجياً إلى هذه الإرشادات بحيث لا يوجد أي ارتباك لاحقًا ، ولكن في البداية ليس هذا هو الأولوية الأعلى. ولكن إذا قمت بتغيير الكود الأقدم أو إعادة تشكيله ، فعليك أن تأخذ الجهد وتطبيق الإرشادات الجديدة هنا ، وفقًا لشعار الكشافة:
اترك دائمًا مكانًا (رمز) في حالة أفضل مما وجدته.
تتم توثيق ميزات واسعة أو غيرها من الأساليب والفئات المثيرة للاهتمام في الكود في Withub Wiki. يجب أن يخدم GitHub Wiki الوثائق الفنية فقط وليس الوثائق للاعبين ، سيكون هناك ويكي.
بادئ ذي بدء: نستخدم الكثير من هذا المفهوم هنا: https://keepachangelog.com/de/1.0.0/
يتم الحفاظ على changelog في ملف changelog.md ، هنا في الجذر. من المهم أن يتم توثيق كل تغيير هنا ، دائمًا في مجال "لم يخرج". على العكس ، هذا يعني أن كل طلب سحب يجب أن يحتوي دائمًا على تغييرات في ملف Changelog ، وإلا فإنه غير مكتمل.
في Changelog نستخدم المجموعات التالية لتقسيم التغييرات:
