two heroes fight simulation

ผู้เขียน: มิคาล โปวาวา
พื้นที่เก็บข้อมูลต้นทาง: การจำลองการต่อสู้แบบฮีโร่สองคน

ฮีโร่สองคนต่อสู้จำลอง

พื้นที่เก็บข้อมูลนี้มีวิธีแก้ปัญหาสำหรับงานที่กำหนด (ด้านล่างในไฟล์นี้) ที่ได้รับการเข้าถึงด้วยวิธีต่างๆ แต่ละวิธี (ที่เสร็จสิ้นแล้ว) มีสาขาและแท็กของตัวเอง แอปพลิเคชันรันได้ในรูปแบบ cli

วัตถุประสงค์ของพื้นที่เก็บข้อมูลนี้คือ (สำหรับฉัน) เพื่อฝึกฝนโค้ดที่สะอาดและการออกแบบโค้ดที่ดีเล็กน้อย ซึ่งมีดังนี้:

1. เสาหลักสี่ประการของ OOP (สำหรับฉันถ้าคุณมุ่งเน้นไปที่ SOLID มันก็เกิดขึ้นเอง)
   • นามธรรม
   • มรดก
   • การห่อหุ้ม
   • ความแตกต่าง
2. หลักการที่มั่นคง
   • ความรับผิดชอบเดี่ยว (แต่ละชั้นเรียนของฉันมีงานเฉพาะของตัวเอง)
   • เปิด/ปิด (เมื่อฉันเริ่มเล่นด้วยแนวทางที่แตกต่างกัน ระบบภายในส่วนใหญ่ของฉันยังไม่มีใครแตะต้อง เพียงแค่ต้องเพิ่มฟังก์ชันการทำงานใหม่)
   • หลักการทดแทน Liskov (โค้ดของฉันใช้นามธรรมเมื่อจำเป็นและไม่ทราบถึงการใช้งานพื้นฐาน ดูที่คลาส Unit และ Colleague เป็นต้น)
   • หลักการแยกอินเทอร์เฟซ (อินเทอร์เฟซขนาดเล็กจำนวนมากแทนที่จะเป็นอินเทอร์เฟซขนาดใหญ่อันเดียว)
   • หลักการผกผันการพึ่งพา (ที่เดียวที่คลาสถูกสร้างอินสแตนซ์คือสคริปต์ run.php และโรงงาน และดูที่ Randomizer - มันสามารถเยาะเย้ยได้! ฉันไม่ได้ใช้ rand() โดยตรงในคลาสใด ๆ )
3. รูปแบบการออกแบบ
   • มัณฑนากร (src/ตัวแก้ไข)
   • วิธีการจากโรงงาน
   • รูปแบบผู้สังเกตการณ์ (สาขาที่เหมาะสม)
   • รูปแบบผู้ไกล่เกลี่ย (สาขาที่เหมาะสม)
4. รูปแบบยุทธวิธี DDD
   • วัตถุค่า (src/คุณสมบัติ)
   • รวม (src/Unit - ทุกบิตของตรรกะที่สามารถสรุปได้ที่นี่)
   • บริการโดเมน (TurnService)
   • บริการแอพพลิเคชั่น (GamePlayService)
   • โรงงาน (โรงงาน)
   • กิจกรรม (src/กิจกรรม) (ใช่ ฉันสามารถใช้บัสเหตุการณ์แทนได้)
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
• แอปพลิเคชันจะต้องแสดงผลลัพธ์ในแต่ละเทิร์น: เกิดอะไรขึ้น, ทักษะใดที่ใช้ (ถ้ามี), ความเสียหายที่เกิดขึ้น, สุขภาพที่เหลืออยู่ของผู้พิทักษ์
• หากเรามีผู้ชนะก่อนที่จะถึงจำนวนรอบสูงสุด เขาจะต้องได้รับการประกาศ

สาขาและแท็ก

• สาขา: ฐาน; แท็ก: แอพที่ทำงานบนฐาน:
  ประกอบด้วยโซลูชันพื้นฐาน (ฟังก์ชันหลัก ทดสอบแล้ว) ที่ยังไม่รองรับการพิมพ์
• สาขา: รูปแบบผู้สังเกตการณ์; แท็ก: การรันแอปรูปแบบผู้สังเกตการณ์:
  ประกอบด้วยโค้ดทั้งหมดจากสาขา base และขยายด้วยการพิมพ์และการบันทึกด้วยการใช้ Observer Pattern
• สาขา: รูปแบบผู้ไกล่เกลี่ย; แท็ก: การรันแอปไกล่เกลี่ยรูปแบบ:
  ประกอบด้วยโค้ดทั้งหมดจากสาขา base และขยายด้วยการพิมพ์และการบันทึกด้วยการใช้ Mediator Pattern

สาขาและวิธีการเพิ่มเติมที่จะเพิ่ม...

สาขาปัจจุบัน: ฐาน

คำชี้แจง

โซลูชัน 'เว็บแอป' ที่ง่ายที่สุดและมากที่สุดคือการใช้บัสเหตุการณ์ภายนอกหรือที่สร้างขึ้นเอง แต่ฉันแค่อยากเล่นกับรูปแบบการออกแบบ (ฉันอาจเพิ่มวิธีแก้ปัญหานั้นสักวันหนึ่ง)

สิ่งที่ต้องทำ

• ลืมใช้ miss ability...
• แก้ไขการมอบหมายที่ไม่มีอยู่ในตัวตกแต่ง MagicShield