two heroes fight simulation

المؤلف: ميشال بواوا
مستودع المصدر: محاكاة قتال بين بطلين

محاكاة قتال بين بطلين

يحتوي هذا المستودع على حلول (حلول) لمهمة معينة (أدناه في هذا الملف) تم التعامل معها بطرق مختلفة. كل نهج (تم الانتهاء منه) له فرع خاص به وعلامة خاصة به. التطبيق قابل للتشغيل على شكل cli.

الغرض من هذا المستودع (بالنسبة لي) هو ممارسة التعليمات البرمجية النظيفة وقليلًا من تصميم التعليمات البرمجية الجيد، وهو ما يلي:

1. أربع ركائز لـ OOP (بالنسبة لي، إذا ركزت على SOLID فقد ظهرت بنفسها)
   • التجريد
   • الميراث
   • التغليف
   • تعدد الأشكال
2. المبادئ الصلبة
   • مسؤولية واحدة (لكل فصل في صفي مهمة فريدة خاصة به)
   • مفتوح/مغلق (عندما بدأت اللعب بأساليب مختلفة، لم يتم المساس بمعظم أجهزتي الداخلية، فقط كنت بحاجة إلى إضافة وظائف جديدة)
   • مبدأ استبدال ليسكوف (يستخدم الكود الخاص بي التجريد عند الحاجة ولا يدرك التنفيذ الأساسي؛ انظر إلى فصول الوحدة والزملاء على سبيل المثال)
   • مبدأ فصل الواجهة (العديد من الواجهات الصغيرة بدلاً من واجهة واحدة كبيرة)
   • مبدأ انعكاس التبعية (المكان الوحيد الذي يتم فيه إنشاء مثيل للفئات هو البرنامج النصي والمصانع run.php، وانظر إلى Randomizer - يمكن الاستهزاء به! أنا لا أستخدم rand() مباشرة في أي فصل دراسي)
3. أنماط التصميم
   • الديكور (src/المعدل)
   • طريقة المصنع
   • نمط المراقب (الفرع المناسب)
   • نمط الوسيط (الفرع المناسب)
4. أنماط DDD التكتيكية
   • كائن القيمة (src/الخاصية)
   • التجميع (src/Unit - كل جزء من المنطق الذي يمكن تغليفه هنا موجود هنا)
   • خدمة المجال (TurnService)
   • خدمة التطبيقات (GamePlayService)
   • المصانع (المصانع)
   • الأحداث (src/Event) (نعم، يمكنني استخدام ناقل الأحداث بدلاً من ذلك)
5. اقتران فضفاض (ينشأ من SOLID)
   أدوات تسجيل الأحداث/الأحداث، ومسجلات الأخطاء، والطابعة (القارئ)، والمنطق الأساسي جميعها مقترنة ببعضها البعض بشكل غير محكم
6. تد
   لأكون صادقًا، هذا ليس TDD خالصًا حيث تقوم أولاً بتنفيذ الاختبارات التي تفشل ثم الكود المصدري وبعد ذلك تمر الاختبارات (أعتقد أن هذا ليس عمليًا) ولكن بعد أن أنشأت بعض مستويات التجريد أو الفصل الدراسي، قمت باختباره على الفور وإصلاح جميع الأخطاء الطفيفة إذا الأخطاء المطلوبة أو المنطقية التي لم أفكر فيها. ولهذا السبب عندما قمت بتنفيذ البرنامج النصي run.php (وهو نقطة الدخول إلى التطبيق) وقمت بذلك كخطوة أخيرة، نجح الكود! أعتقد أن هذا جيد بما فيه الكفاية وليس هناك حاجة إلى TDD النقي.

كيفية الجري

1. قم بتشغيل docer: docker-compose up -d
   • تشغيل التطبيق: docker-compose exec cli php run.php
   • تشغيل اختبارات الوحدة docker-compose exec cli vendor/bin/phpunit tests/

مهمة

إنشاء محاكاة المعركة بين Orderus والوحش. في كل مرة تبدأ فيها المعركة، يتم إنشاء الوحش وOrderus بإحصائيات مختلفة تتبع القواعد التالية:

• الطلب:
  • الصحة: ​​70 - 100
  • القوة: 70 - 80
  • الدفاع: 45 – 55
  • السرعة: 40 - 50
  • الحظ: 10% - 30% (0% يعني عدم وجود حظ، 100% محظوظ طوال الوقت)
  • مهارات إضافية:
    • الضربة السريعة: اضرب مرتين بينما يأتي دوره في الهجوم؛ هناك احتمال 10% أن يستخدم هذه المهارة في كل مرة يهاجم فيها
    • الدرع السحري: يتلقى فقط نصف الضرر المعتاد عندما يهاجم العدو؛ هناك تغيير بنسبة 20% أنه سيستخدم هذه المهارة في كل مرة يدافع فيها
• وحش:
  • الصحة: ​​60 - 90
  • القوة: 60 - 90
  • الدفاع: 40 - 60
  • السرعة: 40 - 60
  • الحظ: 25% - 40%

قواعد اللعب:

• يتم الهجوم الأول بواسطة اللاعب ذو السرعة الأعلى. إذا كان لدى كلا اللاعبين نفس السرعة، فسيتم تنفيذ الهجوم من قبل اللاعب صاحب الحظ الأعلى.
• بعد الهجوم، يتبادل اللاعبون الأدوار: يدافع المهاجم الآن ويهاجم المدافع الآن.
• يتم حساب الضرر الذي أحدثه المهاجم بالمعادلة التالية: Damage = Attacker strength – Defender defence
• يتم خصم الضرر من صحة المدافع. يمكن للمهاجم أن يخطئ في ضربته ولا يسبب أي ضرر إذا كان المدافع محظوظًا في ذلك الدور.
• تحدث مهارات Orderus بشكل عشوائي، بناءً على فرصها، لذا ضعها في الاعتبار في كل منعطف.
• تنتهي اللعبة عندما يبقى أحد اللاعبين بدون صحة أو يصل عدد الأدوار إلى 20.
• يجب أن يقوم التطبيق بإخراج النتائج في كل دور: ما حدث، ما هي المهارات المستخدمة (إن وجدت)، الضرر الذي حدث، صحة المدافع المتبقية.
• إذا كان لدينا فائز قبل الوصول إلى الحد الأقصى لعدد الجولات، فيجب الإعلان عنه.

الفروع والعلامات

• فرع: قاعدة؛ العلامة: التطبيق الأساسي للتشغيل:
  يحتوي على الحل الأساسي (الوظيفة الأساسية، تم اختبار الوحدة) الذي لا يدعم printig حتى الآن
• الفرع: نمط المراقب؛ العلامة: تشغيل نمط مراقب التطبيق:
  يحتوي على كل التعليمات البرمجية من الفرع base ويمتدها بالطباعة والتسجيل باستخدام نمط المراقب
• الفرع: نمط الوسيط؛ العلامة: نمط تشغيل التطبيق الوسيط:
  يحتوي على كل التعليمات البرمجية من الفرع base ويمتدها بالطباعة والتسجيل باستخدام نمط الوسيط

سيتم اضافة المزيد من الفروع والمناهج...

الفرع الحالي: القاعدة

كلمة الشرح

سيكون الحل الأسهل والأكثر "تطبيق ويب" هو استخدام بعض ناقلات الأحداث الخارجية أو ذاتية الصنع ولكني أريد فقط اللعب باستخدام أنماط التصميم (قد أضيف هذا الحل يومًا ما).

المهام

• نسيت تنفيذ القدرة المفقودة ...
• إصلاح التفويض غير الموجود في ديكور MagicShield