Pengecoran Ejaan - Cara mengoptimalkan kerusakan per detik


23

Bayangkan kita memiliki penyihir yang tahu beberapa mantra. Setiap mantra memiliki 3 atribut: Kerusakan, waktu pendinginan, dan waktu pemeran. Barang RPG standar cantik.

Waktu pendinginan: jumlah waktu (t) yang diperlukan sebelum dapat mengucapkan mantra itu lagi. Mantra melanjutkan "cooldown" saat ia mulai melakukan casting.

Cast time: jumlah waktu (t) yang diperlukan untuk menggunakan mantra. Sementara wisaya sedang melakukan sesuatu, mantra lain tidak bisa dilemparkan dan itu tidak bisa dibatalkan.

Pertanyaannya adalah: Bagaimana Anda memaksimalkan kerusakan karena set mantra yang berbeda?

Mudah untuk menghitung kerusakan tertinggi per waktu tuang. Tetapi bagaimana dengan situasi di mana lebih baik menunggu kemudian untuk mendapatkan "macet" casting mantra kerusakan rendah ketika yang jauh lebih tinggi tersedia?

Sebagai contoh,

  1. Bola api: 3000 kerusakan, 3 detik waktu casting, 6 detik dingin.

  2. Frostbolt: 20 kerusakan, 4 detik waktu casting, 4 detik pendinginan.

  3. Fireblast: 3 kerusakan, 3 detik waktu casting, 3 detik pendinginan.

Dalam hal ini kerusakan Anda per detik lebih tinggi jika Anda memilih untuk menggunakan mantra DPCT yang lebih rendah (fireblast) daripada frostbolt. Jadi kita harus mempertimbangkan konsekuensi memilih mantra. teks alternatif

Dalam contoh berikut adalah kasus "over casting" dan "waiting". teks alternatif


Mengapa saya melakukan 1-3-1 dalam situasi ini? Kenapa tidak 1-2-1? Mengapa tidak 1-2-3-1, yang lebih efisien dari 1-3-1-X jika 1-3-1 saja tidak akan membunuh target?

@ Jo Wreschnig: Terima kasih sudah menunjukkannya. Ada kesalahan dalam contoh saya. Sederhana sekarang menjadi hanya 2 kasus.
aaronfarr

1
Serakah, seperti dalam memilih mantra dps tertinggi yang tersedia bila memungkinkan. Mengabaikan logika lain yaitu. menunggu.
aaronfarr

1
Hanya untuk mengeruhkan air. Pertimbangkan mantra yang tidak merusak, tetapi membutuhkan waktu 50 detik untuk melepaskan. Ini dps / dpct adalah ∞, tetapi itu tidak boleh diambil jika target dapat dibunuh dengan cara lain dalam waktu kurang dari 50 detik.
deft_code

1
Anda harus menautkan ke korban penipuan di math.stackexchange.com/questions/10414/...
Sparr

Jawaban:


23

Semua AI adalah pencarian!

Ketika Anda masuk ke nyali AI, sungguh menakjubkan betapa banyak yang benar-benar dicari .

  • negara : sisa cooldown dari semua mantra yang tersedia.
  • kebugaran : kerusakan total dilakukan
  • biaya : total waktu yang diambil
  • cabang : mantra yang dikenal. Jika mantra masih dalam cooldown, tambahkan saja nilai itu ke waktu tuangnya.
  • tujuan : kesehatan total target. Tujuannya harus jumlah kerusakan yang terbatas, jadi dalam kasus target yang tidak diketahui, pilih kesehatan terbesar yang mungkin.
    Atau, tujuan dapat menghabiskan waktu kurang dari 50 detik dan pencarian akan menemukan kerusakan maksimal yang dapat dilakukan dalam 50 detik.

Masukkan parameter ini ke dalam Uniform Cost Search (UCS) dan presto, dijamin rencana pertempuran yang optimal. Bahkan lebih baik jika Anda dapat menemukan heuristik, cari dengan A * , atau IDA * dan Anda akan mendapatkan jawaban yang sama lebih cepat.

Beberapa kelebihan menggunakan UCS adalah dapat menemukan urutan pemain optimal untuk situasi yang jauh lebih rumit daripada yang Anda berikan dengan hanya 3 variabel. Beberapa aspek lain yang dapat dengan mudah ditambahkan:

  • kerusakan seiring waktu
  • menyegarkan mantra untuk mengurangi cooldown dari mantra lain
  • Mantra tergesa-gesa menyebabkan mantera lain melakukan lebih cepat.
  • damage booster yang menyebabkan spell lain melakukan lebih banyak damage.

UCS tidak mahakuasa. Itu tidak bisa memodelkan manfaat mantra perlindungan. Untuk itu, Anda harus meningkatkan ke penelusuran alfa-beta atau minimum.
Juga ia tidak menangani area yang terpengaruh dan pertarungan kelompok dengan sangat baik. UCS dapat diubah untuk memberikan solusi yang masuk akal dalam situasi ini, tidak dijamin untuk menemukan solusi yang optimal.


2

Ini adalah masalah optimisasi kombinatorial khusus. Ketika jumlah mantra meningkat, kesulitan dalam menemukan kombinasi optimal / pola mantra meningkat secara signifikan. Heuristik mirip dengan yang digunakan untuk masalah ransel akan sangat berharga dalam menyelesaikan masalah ini.


1

Anda perlu berpikir dalam hal 'kerusakan per unit waktu casting' (DPCT) - misalnya, bola api dengan pemain 3 detik dan melakukan 3000 kerusakan akan menghasilkan 1000 DPCT.

Jika Anda harus menunggu 3 detik untuk cooldown sebelum melemparkannya, itu akan menguranginya menjadi 500 DPCT (3000 kerusakan, dibagi dengan total 6 detik, termasuk menunggu)

Jadi, Anda hanya perlu menentukan damage-per-cast-time dari masing-masing mantra, termasuk sisa menunggu cooldown. Pilih satu dengan DPCT tertinggi, Tunggu jika perlu, lalu masukkan. Ulangi sampai bos mati :)


masalahnya adalah DPCT bisa sangat menyesatkan. Katakanlah misalnya kita menambahkan 2 mantra lagi ke dalam campuran Fireball: 3000 damage, cast 3 detik, cooldown 6 detik, DPCT: 1000 Spell # kerusakan 2, cast 4 detik, cooldown 4 detik, DPCT: 5 Spell # 3: 3 damage, 3 cast kedua, cooldown 3 detik, DPCT: 1 (ingat, cooldown dimulai saat spell dilemparkan) Meskipun Spell # 3 memiliki DPCT yang lebih rendah itu akan menghasilkan DPS yang lebih tinggi (1-3-1-3 .. .) dari Ejaan # 2 (1-2-1-2 ...).
aaronfarr

1

Menggunakan contoh Anda, Anda mungkin ingin kedua mantra lebih efektif, tetapi mungkin memberi Anda keuntungan yang berbeda. Memiliki waktu casting yang pendek (atau tidak ada waktu casting dalam hal ini) akan sangat berguna, jadi mungkin layak untuk digunakan bahkan jika itu tidak terlalu merusak dan membutuhkan waktu lebih lama untuk digunakan lagi.

Anda selalu bisa memaksakan elemen lain ke dalam persamaan. Mana / Poin Ajaib dapat melayani tujuan ini, dengan memungkinkan pemain untuk menentukan apakah penggunaan poin-poin tersebut sepadan dengan manfaatnya.

Namun secara keseluruhan, seperti yang dikatakan bluescrn, DPCT (atau DPS seperti yang disebut di banyak game yang sangat disetel dan didiskusikan oleh para pemain yang mencari campuran terbaik) benar-benar elemen utama yang ingin Anda keseimbangan, terutama jika Anda memiliki jenis pohon teknologi / keterampilan yang memungkinkan pemain yang berbeda untuk maju dengan keterampilan yang berbeda, namun dengan kemampuan untuk melakukan jumlah kerusakan yang sama pada posisi yang diberikan mereka dalam permainan.


0

Mencari tahu algoritma ini yang berfungsi dengan baik untuk tujuan saya.

Orang-orang mengemukakan beberapa poin bagus. Memberikannya parameter tujuan akhir akan memungkinkan algoritma pencarian normal untuk melakukan hal mereka. yaitu. lakukan kerusakan optimal dalam t detik, lakukan kerusakan x dalam waktu optimal.

Algoritme saya hanya mengembalikan urutan mantra dengan DPS tertinggi. Ini adalah algoritma cepat karena mengurangi ukuran set yang Anda lintasi, tidak memerlukan pengetahuan tentang teknik pohon pencarian lainnya.

Langkah pertama adalah mengidentifikasi mantera dengan kerusakan tertinggi per waktu tuang. Mantra ini menjadi mantra "dasar" karena itu akan menjamin kerusakan tertinggi per detik. Artinya, Anda harus selalu menggunakan mantra ini jika 2 kondisi berikut terpenuhi: 1) mantra dasar tersedia (bukan pada cooldown). 2) Saat ini Anda tidak menggunakan mantra.

Jadi itu kemudian menjadi masalah mengisi mantra lain sementara mantra dasar adalah pada cooldown. Antara (waktu cast) dan (cooldown - waktu cast). Namun, beberapa tumpang tindih dapat terjadi (aturan 2 di atas salah).

Ini kemudian menjadi masalah berulang melalui semua mantra non-baseline untuk menemukan semua urutan mantra yang tidak melanggar 2 aturan.

Untuk mantra yang DO tumpang tindih Anda harus menghukum mereka untuk potensi kerusakan yang bisa dilakukan oleh mantra awal (hingga kerusakan maksimum).

Ambil contoh, 2 mantra

1: 300 damage, 3s cast time, 10s cooldown

2: 290 kerusakan, 3s waktu casting, 3s cooldown

Kerusakan paling banyak berasal dari urutan 1 - 2 - 2 - 2. Yang menyebabkan tumpang tindih 2 detik menjadi pemain # 1 potensial. Namun, ini masih menguntungkan karena jika Anda tidak menggunakan mantra ketiga (mis. 1 - 2 - 2) Anda akan melakukan 880 kerusakan dengan 1 detik tersisa. Jika Anda menggunakan mantra # 2 ekstra Anda akan melakukan 1170 - 2 detik dari # 1 yaitu 200. Jadi 970 kerusakan adalah kerusakan relatif Anda.


-2

Anda dapat melakukan case switch gaya "tingkat keamanan" sederhana.

Ini hanya di atas kepala saya jadi waspadalah terhadap kesalahan logika di luar tingkat kelelahan pikiran saya, tapi saya harap ini bisa membantu Anda memulai.

Dengan asumsi waktu Anda dilakukan dalam bilangan bulat blok -

// after casting spell
int remainingTime = (coolDown - castTime);
switch(spellJustCast)
{
  // assuming the cast method will have some input validation for whether the spell
  // is off cooldown or not, pass the time as a parameter
  case 3 : castSpell1(remainingTime);
           castSpell2(remainingTime);
           break;
  case 1 : castSpell2(remainingTime);
           castSpell3(remainingTime);
           break;
  case 2 : castSpell1(remainingTime);
           castSpell3(remainingTime);
           break;
  default: System.out.println("Debug!");
           break;
}

Beberapa panggilan metode tidak perlu karena waktu ejaan Anda, tetapi selalu ada ruang untuk pembaruan dengan cara ini.

Sunting: Saya baru sadar, Anda perlu mengatur ulang waktu yang tersisa setelah mantra baru dilemparkan, mungkin yang terbaik untuk menjadikannya atribut kelas / bidang dan mengaturnya dari panggilan dalam metode castSpell.


Saya benar-benar tidak tahu apa yang Anda coba dapatkan di sini, tetapi tidak ada mesin game modern yang memiliki fungsi seperti castSpell1 dan castSpell2.

1
@ Jo Wreschnig Maksud saya mereka adalah metode sendiri di kelas permainan kustomnya, ini hanya contoh abstrak, bukan yang detail.
kymully

1
Benar, bukan itu cara kerja mantra di mesin modern. Ada satu fungsi castSpell yang mengambil objek yang bidangnya dibaca dari file. Pernyataan pergantian seperti itu tidak mungkin dipertahankan di engine nyata apa pun, dan beberapa jenis algoritma perencanaan diperlukan.

@ Jo Wreschnig, saya mengerti. Saya hanya memberikan cara untuk menyelesaikan masalah. Contoh ini ditulis dalam java, tidak dimaksudkan untuk mesin atau kerangka kerja tertentu. Tetapi jika itu tidak dapat diimplementasikan seperti yang Anda katakan, jawaban saya tidak berlaku.
kymully
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.