Apakah layak menerapkan mekanisme / aturan game secara terpisah dari kode utama?

Tidak yakin apakah itu cocok dengan ruang lingkup komunitas ini, atau harusnya pergi ke Stackoverflow.

Mari kita anggap bahwa saya ingin permainan saya dapat dengan mudah diperpanjang pada intinya, yaitu saya ingin bahwa banyak orang, bahkan tanpa pengetahuan pemrograman yang baik, akan dapat tidak hanya mengubah aturan yang ada, tetapi bahkan menambahkan mekanisme permainan yang sama sekali baru ke dalamnya. Saya sendiri bukan programmer yang baik, tetapi saya siap belajar, saya hanya perlu beberapa arahan dan jaminan itu bisa dilakukan.

Apa yang saya pikirkan adalah apakah mungkin / layak untuk menerapkan mekanisme permainan secara terpisah dari kode utilitas utama? Maksud saya, untuk permainan di meja kami memiliki buku aturan yang tidak berisi algoritma sebenarnya dari semua tindakan, tetapi lebih menggambarkan beberapa protokol dan batasan, sangat merujuk konteks setiap item tersebut. Apakah mungkin untuk melakukan sesuatu yang serupa untuk game PC, seperti, menjelaskan semua aturan dalam tingkat yang sangat tinggi, mudah dibaca (dan dapat diubah) oleh bahasa pemrograman manusia, yang kemudian "dikonsumsi" dan diuraikan oleh kode utilitas menjadi sebuah contoh kerja mekanik game?

Itu benar-benar sepertinya saya perlu menulis bahasa saya sendiri dan kompiler untuk itu)) Yang tentu saja saya tidak akan bisa melakukannya. Tetapi mungkin ada pendekatan yang lebih mudah untuk masalah ini?

FYI: Bahasa pilihan saya untuk kode utilitas adalah Python 3.x

Secara umum, kemudahan dengan mana sistem dapat diperluas tergantung pada sejauh mana subsistemnya erat atau longgar digabungkan . Biasanya, subsistem yang lebih longgar ditambah, semakin mudah untuk memodifikasinya karena mereka terisolasi & tidak perlu memerlukan pemahaman lengkap tentang sistem secara keseluruhan.

Tidak ada yang gratis - sistem seperti itu biasanya membutuhkan lebih banyak sumber daya (berbagai kombinasi waktu, uang & keterampilan) untuk dibangun. Tingkat kelenturan yang Anda gambarkan membuat saya merasa langsung berselisih dengan tingkat keterampilan yang Anda kaitkan dengan diri Anda sendiri. Itu bisa dilakukan, tetapi menyusun perangkat lunak seperti yang Anda gambarkan itu adalah pekerjaan yang sangat menantang.

Hal-hal terdekat yang ada yang saya sadari adalah Vassal (yang jauh lebih terprogram daripada yang telah Anda jelaskan), atau membuat mod untuk Tabletop Simulator (yang sebagian besar tergantung pada interaksi manusia untuk menafsirkan & menegakkan aturan permainan apa pun).

Apa yang saya pikirkan adalah apakah mungkin / layak untuk menerapkan mekanisme permainan secara terpisah dari kode utilitas utama?

Sangat mungkin. Salah satu cara yang sering digunakan dalam bermain game adalah Lua scripting .

Dari artikel yang ditautkan:

Lua awalnya dirancang pada tahun 1993 sebagai bahasa untuk memperluas aplikasi perangkat lunak untuk memenuhi meningkatnya permintaan untuk kustomisasi pada saat itu.

Banyak game menggunakan Lua. (Saya akan menautkan tetapi reputasi pengguna baru membatasi jumlah tautan saya.)

Skrip Lua dapat dikompilasi pada saat run-time. Ini berarti mereka dapat (misalnya) menjadi file teks yang berada di direktori "skrip" game Anda, mudah diedit oleh seorang modder. Game Anda memuatnya dan menjalankannya.

Saya telah melihat skrip Lua mendefinisikan properti unit dalam game. Sini adalah contoh acak dari TA Spring.

Tetapi Anda ingin "menggambarkan semua aturan". Itu mungkin dalam teori, karena Lua adalah bahasa penuh, tetapi masalahnya adalah Anda harus cukup ahli untuk memiliki kode permainan inti tahu untuk mencari skrip untuk memperluas perilakunya.

Misalnya Anda mungkin mengembangkan permainan kartu yang tahu mencari kartu di direktori "skrip / kartu". Itu bagus untuk menambahkan kartu baru, atau mengedit yang sudah ada. Tetapi jika nanti Anda ingin memperluas gim Anda untuk memasukkan miniatur ke dalam kisi, Anda harus mengedit kode inti - tidak ada jumlah Lua yang mengutak-atik yang akan membawa Anda ke sana sendiri.

Harap dicatat: Saya membuka Lua karena saya tahu ini umum digunakan baik di game maupun di perangkat lunak untuk penyesuaian. Saya tidak menyarankan itu adalah satu-satunya solusi, juga bukan yang terbaik untuk kebutuhan si penanya.

Ada serangkaian pendekatan dan apakah salah satu dari mereka layak akan tergantung pada apa yang Anda coba lakukan. Secara khusus, berapa banyak kontrol yang ingin Anda tawarkan pada tweaker?

Di ujung kontrol yang ekstrem, Anda dapat membiarkan tweaker memodifikasi kode seluruh permainan. Pada titik itu Anda pada dasarnya akan menerbitkan kode utilitas dan setidaknya satu contoh cara menggunakannya. Tweak dapat menggunakan kode sebanyak atau sesedikit yang mereka inginkan.

Suatu pendekatan yang menawarkan sedikit kontrol akan entah bagaimana "membekukan" kode utilitas Anda (katakan dengan mengkompilasi sebelumnya) dan hanya membiarkan tweaker mengisi fungsi tertentu (panggilan balik), membatasi apa yang dapat mereka lakukan. Bergantung pada apa yang ingin Anda lakukan, pendekatan ini dapat mengambil banyak bentuk. Metode yang umum adalah menempatkan semua bagian tampilan di utilitas / kode utama dan semua mekanik di bagian tweakable. Atau, Anda mungkin ingin menyimpan beberapa mekanik di bagian "beku" karena pemain tidak mungkin ingin mengubahnya, atau membuatnya berubah terlalu rumit.

Di ujung kontrol rendah kontinum hanya membiarkan tweaker mengubah nilai dalam rentang tetap. File data yang memungkinkan Anda memilih warna hal-hal dalam gim akan menjadi contoh. Namun, Anda dapat menggunakan pendekatan ini dan masih menawarkan banyak penyesuaian. Adalah mungkin untuk menentukan pilihan fungsi dan memungkinkan tweaker untuk menyusunnya untuk membuat panggilan balik dari pendekatan sebelumnya, tetapi tidak memungkinkan mereka untuk mendefinisikan yang baru. Atau mungkin Anda melewatkan bagian komposisi dan hanya menawarkan pilihan yang terbatas.

Detail semua pendekatan ini dan yang mana yang cocok dengan kasus penggunaan Anda bergantung pada jenis game dasar yang ingin Anda buat dan seberapa besar kontrol yang ingin Anda berikan. Perhatikan bahwa permainan komersial umumnya hanya menggunakan metode kedua dan ketiga karena yang pertama memungkinkan pemain untuk membuat game yang sepenuhnya terpisah, yang memperkenalkan masalah perizinan yang rumit. Perhatikan bahwa karena pendekatan ini membentuk sebuah kontinum, pendekatan kedua dapat memperkenalkan masalah ini juga.

Sangat mungkin untuk memisahkan aturan sistem dari kode yang menerapkan aturan tersebut. Saya lebih suka menyusun kode saya seperti itu untuk proyek yang kompleks, karena membuatnya lebih mudah untuk menambahkan aturan baru atau mengubah aturan nanti tanpa memasukkan bug ke dalam sistem yang mendasarinya. Dan bug dalam mesin aturan ditemukan lebih cepat dari bug dalam sistem di mana aturan dan kode lainnya dicampur bersama-sama higgledy-piggledy, karena mesin aturan yang sama akan digunakan berulang kali oleh setiap aturan.

Apakah layak itu tergantung pada kompleksitas sistem. Sepertinya aku tidak akan repot-repot untuk Pac-Man, tapi aku tidak bisa membayangkan menulis Dwarf Fortress dengan cara lain.

Itu pasti layak. Jika itu layak, itu tergantung pada tujuan Anda.

Anda tidak harus menciptakan bahasa Anda sendiri atau menulis kompiler untuk membuat ini berfungsi.

Jika Anda ingin gim Anda dapat diperpanjang dengan mudah, mungkin ide yang bagus untuk melakukannya.

Mungkin lebih banyak bekerja untuk Anda, setidaknya jangka pendek, untuk membuat sistem yang dapat dimengerti dan membuat hal-hal mudah untuk dimodifikasi.

Salah satu permainan yang melakukan ini adalah Rimworld (saya tidak memiliki afiliasi) dan Anda mungkin dapat melihat & belajar dari cara mereka melakukannya, pada dasarnya menempatkan banyak data game dan mekanik dalam file XML yang ada di folder game untuk dilihat dan dilihat siapa saja. memodifikasi. Inti / mesin game dibuat menggunakan Unity.

Ada juga kemungkinan untuk memperluas game lebih jauh / lebih dalam dengan coding yang sebenarnya, saya tahu sedikit tentang itu tetapi Anda bisa belajar dengan melihat di forum mods.

Kemungkinan modding membuat permainan lebih menarik bagi banyak orang dan saya pikir itu telah berkontribusi banyak pada keberhasilannya. Hal ini juga memungkinkan para pengembang untuk membawa konten mod yang mereka inginkan ke dalam game inti dan dengan cara, yang mempercepat pengembangan dan meningkatkan game karena mereka mendapatkan bantuan dari banyak orang, dan mereka dapat memutuskan untuk mengambil hal-hal berdasarkan pada apa yang populer, apa yang tampaknya berhasil, dll.

Dan tentu saja, terutama untuk studio kecil independen, mereka memiliki ratusan orang yang datang dengan ide dan menguji mereka untuk mereka, yang merupakan banyak pekerjaan yang tidak dapat mereka lakukan sendiri, atau mungkin mempekerjakan orang untuk melakukannya.

Anda mungkin ingin melihat Desain Berorientasi Objek . Python memiliki dukungan yang baik untuk itu.

Buku tebal ditulis tentang ini yang bisa menakutkan ketika Anda baru, tetapi prinsip-prinsip utamanya cukup mudah.

Poin utamanya adalah Anda mengidentifikasi objek seperti apa yang sedang Anda kerjakan. Anda tidak mengatakan jenis permainan apa yang Anda pikirkan, tetapi hal-hal seperti Player, Monster, Item, Equipment, Weapon, Armor dan sebagainya adalah objek tipikal.

Jika Anda menginginkan jenis permainan yang berbeda, Anda mungkin menginginkan objek Permainan yang menjaga kondisi kemenangan dan semacamnya. Mungkin objek Peta juga?

Terkadang tidak jelas apakah sesuatu pantas menjadi objek atau tidak, misalnya kerusakan. Jika Anda tidak membuat kerusakan pada suatu objek, kode tersebut akan lebih sederhana, tetapi menjadikannya objek yang membuatnya lebih mudah untuk dikustomisasi.

Subklasifikasi: Baik Senjata dan Armour adalah Peralatan. Peralatan adalah Item. Mungkin ada jenis Item lainnya. Anda mungkin akan merasa berguna untuk mendefinisikan Combatant kelas yang menjadi subclass Pemain dan Monster.

Idenya adalah bahwa misalnya Senjata akan memiliki banyak kesamaan dengan semua jenis Item lainnya, mereka memiliki bobot, ukuran, dan properti lain seperti itu.

Jadi, subclassing memberi Anda cara untuk mengatakan bahwa "Senjata seperti Item lainnya, tetapi selain itu Anda dapat menggunakan mereka, mereka mempengaruhi kerusakan yang Anda lakukan, dll."

Subclassing juga memungkinkan pembangun mod Anda mengatakan "Senjata jenis baru saya sama seperti senjata standar kecuali itu ..."

Maka Anda harus memutuskan objek mana yang bertanggung jawab untuk apa. Ini tidak semudah kelihatannya dan Anda harus memikirkannya. Membuat pilihan yang salah tidak akan banyak mempengaruhi permainan dasar, tetapi akan membuatnya lebih sulit untuk dikustomisasi.

Selama Anda hanya mengutak-atik sendiri Anda dapat mengubah hal-hal di sekitar tetapi saat Anda merilis sesuatu kepada publik, membuat perubahan menjadi jauh lebih sulit! Orang akan membuat mod yang bergantung pada hal-hal yang sama seperti sekarang. Bahkan serangga. Orang-orang akan menulis mod yang bergantung pada bug yang ada di kode. Jika Anda mengubah banyak hal, mod-mod itu akan rusak dan monster lynch akan muncul di rumah Anda.

Sebagai contoh:

Seorang pemain yang menggunakan Senjata menyerang monster yang menggunakan beberapa Armour. Ini terjadi dalam mode Game tertentu dan pada Peta tertentu.

Kedua Combatant mungkin memiliki Keterampilan seperti Hit Kritis dan Dodge.

Sekarang, objek mana yang bertanggung jawab untuk apa?

Tidak ada satu jawaban yang benar untuk ini. Banyak hal bergantung pada jenis penyesuaian apa yang ingin Anda izinkan.

Jika Anda tidak pernah memanggil objek (misalnya Peta), objek itu tidak dapat mengubah serangan dengan cara apa pun.

Setelah membuat semua keputusan ini, dokumentasikanlah . Tulis "Manual modders" yang mencantumkan metode moddable apa yang dimiliki masing-masing objek, parameter apa yang mereka ambil, apa yang harus mereka kembalikan, dan seterusnya dan seterusnya ...

Semoga berhasil!

Cara sederhana untuk mendapatkan dukungan dasar untuk ini adalah dengan memisahkan sebagian besar nilai numerik menjadi satu atau lebih file teks terpisah untuk memungkinkan orang yang tertarik untuk mengubah mereka menjadi terlupakan.

Misalnya, Anda menyebutkan game meja; jika Anda memiliki permainan berdasarkan D & D Anda mungkin memiliki weapon_damagefile yang berisi baris seperti Battleaxe: 1d12. Kode utilitas Anda akan membaca file itu dan setiap kali kerusakan ditangani oleh Battleaxekode Anda generate a number from 1-12, 1 time(s)dan menambahkannya. Tweak baris untuk dibaca Battleaxe: 4d6sebagai gantinya generate a number from 1-6, 4 time(s)dan menambahkannya. Demikian pula, Anda dapat memiliki folder Creaturesdan di dalamnya Anda memiliki file untuk setiap makhluk, termasuk baris seperti AC: 12; kemudian menambahkan file baru ke folder itu akan membuat makhluk baru. Itu bahkan bisa dilakukan untuk kelas karakter, tipe medan, banyak hal.

Gaya penyesuaian non-kode ini masih bisa sangat kuat dan mencakup banyak bagian dari gim Anda. Namun, ini tidak benar-benar memungkinkan pengguna untuk membuat perubahan yang tidak Anda tentukan secara eksplisit. Misalnya, Anda dapat mengaktifkan Sneak Attack: [damage]untuk diberikan pada setiap Makhluk atau Kelas untuk ditambahkan[damage] ke serangan apa pun yang memenuhi persyaratan untuk Serangan Sneak. Anda bahkan dapat memberikan cara untuk mengubah apa kondisinya, seperti "setiap kali Anda menyerang dari stealth" atau "setiap kali Anda mengapit" atau "setiap kali Anda memiliki keuntungan". Namun, jika pengguna memutuskan bahwa mereka ingin serangan menyelinap menjadi "Ketika Anda membuat roll serangan, Anda juga dapat roll diam-diam terhadap persepsi target. Jika kedua roll berhasil, maka tambahkan kerusakan Serangan Sneak"

Jika Anda ingin seorang pengguna dapat menambahkan perilaku yang sama sekali baru ke dalam game tanpa perlu keterampilan coding pada tingkat yang sama dengan pengembang, maka seperti yang orang katakan Anda sedang melihat pada dasarnya membuat mesin permainan atau bahasa pemrograman yang terpisah. Untuk modifikasi yang tidak memerlukan pengetahuan pengkodean, file data berbasis teks dan struktur folder masih dapat menyediakan banyak opsi. Jika Anda ingin pengguna memodifikasi lebih dari itu, Anda harus meminta mereka untuk belajar atau mengetahui bahasa pemrograman.

[Saya adalah pengembang perangkat lunak selama beberapa dekade, tetapi tanpa pengalaman pengembangan game, jadi mungkin industri game mengambil pendekatan berbeda, mungkin untuk alasan yang baik ...]

Pendekatan Anda benar-benar masuk akal bagi saya. Inti memberikan fungsionalitas dasar yang dibangun oleh mekanik dan aturan, jadi ini adalah API yang akan digunakan oleh komponen tingkat yang lebih tinggi.

Dan ketika mendesain API, panduan favorit saya adalah membuat bahasa yang Anda inginkan untuk mengekspresikan kode level yang lebih tinggi (tentu saja, dengan menyertakan batasan sintaksis bahasa pemrograman Anda).

Jadi, pendekatan yang baik adalah dengan menulis beberapa aturan hipotetis dan mekanika persis seperti yang Anda inginkan untuk diekspresikan (dengan sintaksis Python, tentu saja), sehingga mencari tahu apa yang Anda ingin API inti sediakan untuk aturan dan mekanika lapisan.

Dan tentu saja, saya akan merekomendasikan untuk melihat fasilitas scripting game yang ada untuk mendapatkan ide tentang apa yang mereka lakukan.