Saya tidak yakin apakah Anda masih membaca ini tetapi saya telah berjuang dengan masalah semacam ini untuk waktu yang lama.
Saya telah merancang berbagai jenis sistem pengaruh. Saya akan membahasnya sebentar sekarang. Ini semua berdasarkan pengalaman saya. Saya tidak mengklaim tahu semua jawaban.
Pengubah Statis
Jenis sistem ini sebagian besar mengandalkan bilangan bulat sederhana untuk menentukan modifikasi apa pun. Misalnya, +100 ke Max HP, +10 untuk menyerang dan sebagainya. Sistem ini juga bisa menangani persen. Anda hanya perlu memastikan bahwa penumpukan tidak lepas kendali.
Saya tidak pernah benar-benar menembolok nilai yang dihasilkan untuk jenis sistem ini. Misalnya, jika saya ingin menampilkan kesehatan maksimal dari sesuatu, saya akan menghasilkan nilai di tempat. Ini mencegah hal-hal dari rawan kesalahan dan hanya lebih mudah dimengerti untuk semua orang yang terlibat.
(Saya bekerja di Jawa sehingga yang mengikuti adalah berbasis Java tetapi harus bekerja dengan beberapa modifikasi untuk bahasa lain) Sistem ini dapat dengan mudah dilakukan dengan menggunakan enum untuk jenis modifikasi, dan kemudian bilangan bulat. Hasil akhirnya dapat ditempatkan ke dalam semacam koleksi yang memiliki pasangan kunci, nilai yang diurutkan. Ini akan menjadi pencarian cepat dan perhitungan, sehingga kinerjanya sangat baik.
Secara keseluruhan, ini bekerja sangat baik hanya dengan pengubah statis datar. Padahal, kode harus ada di tempat yang tepat untuk pengubah yang akan digunakan: getAttack, getMaxHP, getMeleeDamage, dan seterusnya dan seterusnya.
Di mana metode ini gagal (bagi saya) adalah interaksi yang sangat kompleks antara penggemar. Tidak ada cara nyata yang mudah untuk berinteraksi kecuali dengan sedikit mengatasinya. Itu memang memiliki beberapa kemungkinan interaksi sederhana. Untuk melakukan itu, Anda harus membuat modifikasi dengan cara Anda menyimpan pengubah statis. Alih-alih menggunakan enum sebagai kunci, Anda menggunakan sebuah String. String ini akan menjadi nama Enum + variabel ekstra. 9 kali dari 10, variabel tambahan tidak digunakan, jadi Anda masih mempertahankan nama enum sebagai kunci.
Mari kita lakukan contoh cepat: Jika Anda ingin dapat mengubah kerusakan terhadap makhluk mayat hidup, Anda dapat memiliki pasangan yang dipesan seperti ini: (DAMAGE_Undead, 10) DAMAGE adalah Enum dan Undead adalah variabel tambahan. Jadi selama pertempuran, Anda dapat melakukan sesuatu seperti:
dam += attacker.getMod(Mod.DAMAGE + npc.getRaceFamily()); //in this case the race family would be undead
Bagaimanapun, ini bekerja dengan cukup baik dan cepat. Tetapi gagal pada interaksi yang kompleks dan memiliki kode "khusus" di mana-mana. Misalnya, pertimbangkan situasi "25% kesempatan untuk berteleportasi pada kematian". Ini adalah yang “cukup” kompleks. Sistem di atas dapat mengatasinya, tetapi tidak mudah, karena Anda memerlukan yang berikut:
- Tentukan apakah pemain memiliki mod ini.
- Di suatu tempat, miliki beberapa kode untuk mengeksekusi teleportasi, jika berhasil. Lokasi kode ini adalah diskusi sendiri!
- Dapatkan data yang tepat dari peta Mod. Apa artinya nilainya? Apakah ini kamar tempat mereka berteleportasi juga? Bagaimana jika seorang pemain memiliki dua mod teleport pada mereka ?? Tidak akankah jumlahnya ditambahkan bersama ?????? KEGAGALAN!
Jadi ini membawa saya ke yang berikutnya:
Sistem Penggemar Yang Sangat Kompleks
Saya pernah mencoba menulis MMORPG 2D sendiri. Ini adalah kesalahan yang mengerikan tetapi saya belajar banyak!
Saya menulis ulang sistem yang terpengaruh 3 kali. Yang pertama menggunakan variasi yang kurang kuat di atas. Yang kedua adalah apa yang akan saya bicarakan.
Sistem ini memiliki serangkaian kelas untuk setiap modifikasi, jadi hal-hal seperti: ChangeHP, ChangeMaxHP, ChangeHPByPercent, ChangeMaxByPercent. Saya memiliki jutaan orang ini - bahkan hal-hal seperti TeleportOnDeath.
Kelas saya memiliki hal-hal yang akan dilakukan sebagai berikut:
- applyAffect
- removeAffect
- checkForInteraction <--- penting
Terapkan dan hapus menjelaskan sendiri (meskipun untuk hal-hal seperti persen, pengaruhnya akan melacak berapa banyak meningkatkan HP untuk memastikan ketika dampaknya berkurang, itu hanya akan menghapus jumlah yang ditambahkan. Ini adalah kereta, lol, dan Butuh waktu lama untuk memastikan itu benar. Saya masih belum mendapatkan perasaan yang baik tentang hal itu.).
Metode checkForInteraction adalah sepotong kode yang sangat rumit. Di masing-masing kelas yang mempengaruhi (yaitu: ChangeHP), itu akan memiliki kode untuk menentukan apakah ini harus dimodifikasi oleh input yang mempengaruhi. Jadi misalnya, jika Anda memiliki sesuatu seperti ....
- Buff 1: Menawarkan 10 damage api saat menyerang
- Buff 2: Meningkatkan semua kerusakan akibat kebakaran sebesar 25%.
- Buff 3: Meningkatkan semua damage api sebesar 15.
Metode checkForInteraction akan menangani semua dampak ini. Untuk melakukan ini, masing-masing pengaruh pada SEMUA pemain di dekat harus diperiksa !! Ini karena jenis pengaruh yang saya hadapi dengan banyak pemain dalam rentang area. Ini berarti kode TIDAK PERNAH MEMILIKI pernyataan khusus seperti di atas - "jika kita baru saja mati, kita harus memeriksa teleport pada kematian". Sistem ini secara otomatis akan menanganinya dengan benar pada waktu yang tepat.
Mencoba untuk menulis sistem ini butuh waktu 2 bulan dan dibuat oleh kepala meledak beberapa kali. NAMUN, itu BENAR-BENAR kuat dan bisa melakukan sejumlah hal gila - terutama ketika Anda memperhitungkan dua fakta berikut untuk kemampuan dalam permainan saya: 1. Mereka memiliki rentang target (yaitu: tunggal, mandiri, hanya grup, PB AE sendiri , Target PB AE, target AE, dan sebagainya). 2. Kemampuan bisa memiliki lebih dari 1 mempengaruhi mereka.
Seperti yang saya sebutkan di atas, ini adalah sistem pengaruh ke 2 dari 3 untuk game ini. Mengapa saya menjauh dari ini?
Sistem ini memiliki kinerja terburuk yang pernah saya lihat! Itu sangat lambat karena harus melakukan begitu banyak memeriksa setiap hal yang terjadi. Saya mencoba memperbaikinya, tetapi menganggapnya gagal.
Jadi kita sampai pada versi ketiga saya (dan tipe lain dari sistem buff):
Mempengaruhi Kelas Kompleks dengan Penangan
Jadi ini cukup banyak kombinasi dari dua yang pertama: Kita dapat memiliki variabel statis dalam kelas yang mempengaruhi yang berisi banyak fungsi dan data tambahan. Kemudian panggil saja penangan (bagi saya, cukup banyak beberapa metode utilitas statis daripada subclass untuk tindakan tertentu. Tapi saya yakin Anda bisa menggunakan subclass untuk tindakan jika Anda menginginkannya juga) ketika kita ingin melakukan sesuatu.
Kelas Affect akan memiliki semua barang bagus yang berair, seperti tipe target, durasi, jumlah penggunaan, kesempatan untuk mengeksekusi dan seterusnya dan seterusnya.
Kami masih harus menambahkan kode khusus untuk menangani situasi, misalnya, teleport pada kematian. Kami masih harus memeriksa ini dalam kode tempur secara manual, dan kemudian jika ada, kami akan mendapatkan daftar efek. Daftar pengaruh ini berisi semua efek yang saat ini diterapkan pada pemain yang berurusan dengan teleportasi pada saat kematian. Kemudian kita akan melihat masing-masing dan memeriksa untuk melihat apakah itu dieksekusi dan berhasil (Kami akan berhenti di yang sukses pertama). Itu berhasil, kami hanya akan memanggil pawang untuk mengurus ini.
Interaksi dapat dilakukan, jika Anda mau. Itu hanya harus menulis kode untuk mencari penggemar tertentu pada pemain / dll. Karena memiliki kinerja yang baik (lihat di bawah), seharusnya cukup efisien untuk melakukan itu. Itu hanya akan membutuhkan penangan yang lebih kompleks dan sebagainya.
Jadi ia memiliki banyak kinerja sistem pertama dan masih banyak kerumitan seperti yang kedua (tetapi tidak banyak). Di Jawa setidaknya, Anda dapat melakukan beberapa hal rumit untuk mendapatkan kinerja yang hampir pertama dalam kebanyakan kasus (yaitu: memiliki peta enum ( http://docs.oracle.com/javase/6/docs/api/java /util/EnumMap.html ) dengan Enums sebagai kunci dan ArrayList mempengaruhi sebagai nilainya. Ini memungkinkan Anda untuk melihat apakah Anda dengan cepat memengaruhi [karena daftar akan menjadi 0 atau peta tidak memiliki enum] dan tidak memiliki untuk terus-menerus mengulangi daftar pengaruh pemain tanpa alasan. Saya tidak keberatan untuk mengulang pengaruh jika kita membutuhkannya saat ini. Saya akan mengoptimalkan nanti jika itu menjadi masalah).
Saat ini saya sedang membuka kembali (menulis ulang game di Java alih-alih basis kode FastROM seperti semula) MUD saya yang berakhir pada 2005 dan saya baru-baru ini bertemu bagaimana saya ingin menerapkan sistem buff saya? Saya akan menggunakan sistem ini karena bekerja dengan baik di permainan saya yang gagal sebelumnya.
Yah, semoga seseorang, di suatu tempat, akan menemukan beberapa wawasan ini berguna.