two heroes fight simulation

penulis: Michał Powała
repositori sumber: simulasi pertarungan dua pahlawan

simulasi pertarungan dua pahlawan

Repositori ini berisi solusi untuk tugas yang diberikan (di bawah dalam file ini) yang didekati dengan cara yang berbeda. Setiap pendekatan (yang sudah selesai) memiliki cabang dan tagnya sendiri. Aplikasi dapat dijalankan dari cli.

Tujuan dari repositori ini (bagi saya) adalah untuk mempraktikkan kode yang bersih dan sedikit desain kode yang baik, sebagai berikut:

1. Empat pilar OOP (bagi saya jika Anda fokus pada SOLID, pilar tersebut akan muncul sendiri)
   • Abstraksi
   • Warisan
   • Enkapsulasi
   • Polimorfisme
2. Prinsip PADAT
   • Tanggung jawab tunggal (setiap kelas saya memiliki tugas uniknya sendiri)
   • Terbuka/tertutup (ketika saya mulai bermain dengan pendekatan berbeda, sebagian besar internal saya tidak tersentuh, hanya perlu menambahkan fungsionalitas baru)
   • Prinsip substitusi Liskov (kode saya menggunakan abstraksi jika diperlukan dan tidak mengetahui implementasi yang mendasarinya; lihat kelas Unit dan Rekan misalnya)
   • Prinsip pemisahan antarmuka (banyak antarmuka kecil, bukan satu antarmuka besar)
   • Prinsip inversi ketergantungan (satu-satunya tempat di mana kelas dipakai adalah skrip dan pabrik run.php, dan lihat Randomizer - ini dapat diejek! Saya tidak menggunakan rand() secara langsung di kelas mana pun)
3. Pola Desain
   • Dekorator (src/Pengubah)
   • Metode Pabrik
   • Pola Pengamat (cabang yang tepat)
   • Pola Mediator (cabang yang tepat)
4. Pola taktis DDD
   • Objek Nilai (src/Properti)
   • Agregat (src/Unit - setiap logika yang dapat diringkas di sini ada di sini)
   • Layanan Domain (Layanan Putar)
   • Layanan Aplikasi (Layanan GamePlay)
   • Pabrik (pabrik)
   • Acara (src/Event) (ya, saya bisa menggunakan bus acara saja)
5. Kopling longgar (muncul dari SOLID)
   Pencatat tindakan/peristiwa, pencatat kesalahan, printer (pembaca), dan logika inti semuanya digabungkan secara longgar satu sama lain
6. TDD
   Sejujurnya itu bukan TDD murni di mana Anda pertama kali mengimplementasikan tes yang gagal dan kemudian kode sumber setelah tes lulus (saya pikir itu tidak praktis) tetapi setelah saya membuat beberapa level abstraksi atau kelas saya langsung mengujinya dan memperbaiki semua bug kecil jika diperlukan atau kesalahan logis yang belum saya pikirkan. Itu sebabnya ketika saya mengimplementasikan skrip run.php (yang merupakan titik masuk ke aplikasi) dan saya melakukannya sebagai langkah terakhir, kodenya berfungsi! Saya rasa itu sudah cukup dan TDD murni tidak diperlukan.

Bagaimana cara menjalankannya

1. Jalankan docer: docker-compose up -d
   • jalankan aplikasi: docker-compose exec cli php run.php
   • jalankan pengujian unit docker-compose exec cli vendor/bin/phpunit tests/

TUGAS

Buat simulasi pertempuran antara Orderus dan binatang buas. Setiap kali pertempuran dimulai, beast dan Orderus dihasilkan dengan statistik berbeda yang mengikuti aturan berikut:

• Pesan kami:
  • Kesehatan: 70 - 100
  • Kekuatan: 70 - 80
  • Pertahanan: 45 – 55
  • Kecepatan: 40 – 50
  • Keberuntungan: 10% - 30% (0% berarti tidak beruntung, 100% selalu beruntung)
  • keterampilan tambahan:
    • Serangan cepat: Menyerang dua kali saat gilirannya menyerang; ada kemungkinan 10% dia akan menggunakan skill ini setiap kali dia menyerang
    • Perisai ajaib: Hanya menerima setengah dari kerusakan biasa saat musuh menyerang; ada perubahan 20% dia akan menggunakan skill ini setiap kali dia bertahan
• Binatang buas:
  • Kesehatan: 60 - 90
  • Kekuatan: 60 - 90
  • Pertahanan: 40 – 60
  • Kecepatan: 40 – 60
  • Keberuntungan: 25% - 40%

Aturan permainan:

• Serangan pertama dilakukan oleh pemain dengan kecepatan lebih tinggi. Apabila kedua pemain mempunyai kecepatan yang sama, maka penyerangan dilakukan oleh pemain yang mempunyai keberuntungan tertinggi.
• Setelah serangan, para pemain berganti peran: penyerang sekarang bertahan dan pembela sekarang menyerang.
• Kerusakan yang dilakukan penyerang dihitung dengan rumus sebagai berikut: Damage = Attacker strength – Defender defence
• Kerusakan dikurangi dari kesehatan pembela. Seorang penyerang dapat melewatkan pukulannya dan tidak menimbulkan kerusakan jika pemain bertahan beruntung pada giliran itu.
• Keterampilan Orderus terjadi secara acak, berdasarkan peluangnya, jadi pertimbangkan keterampilan tersebut di setiap giliran.
• Permainan berakhir ketika salah satu pemain tetap tanpa kesehatan atau jumlah putaran mencapai 20.
• Aplikasi harus menampilkan hasil setiap giliran: apa yang terjadi, keterampilan apa yang digunakan (jika ada), kerusakan yang terjadi, sisa kesehatan pemain bertahan.
• Jika kita mempunyai pemenang sebelum jumlah putaran maksimum tercapai, dia harus diumumkan.

CABANG dan TAG

• cabang: pangkalan; tag: aplikasi yang berjalan dasar:
  Berisi solusi dasar (fungsi inti, unit diuji) yang belum mendukung printig
• cabang: pola pengamat; tag: menjalankan-aplikasi-pengamat-pola:
  Berisi semua kode dari cabang base dan memperluasnya dengan pencetakan dan logging dengan penggunaan Pola Pengamat
• cabang: pola mediator; tag: menjalankan-aplikasi-pola-mediator:
  Berisi semua kode dari cabang base dan memperluasnya dengan pencetakan dan logging dengan penggunaan Pola Mediator

Lebih banyak cabang dan pendekatan yang akan ditambahkan...

Cabang saat ini: basis

KATA PENJELASAN

Solusi 'aplikasi web' yang paling mudah dan paling banyak adalah dengan menggunakan bus acara eksternal atau buatan sendiri, tetapi saya hanya ingin bermain-main dengan Pola Desain (saya mungkin menambahkan solusi itu suatu hari nanti).

TODO

• Lupa menerapkan kemampuan rindu...
• Perbaiki delegasi yang tidak ada di dekorator MagicShield