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


25

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


Karena Anda tidak berpengalaman dan bekerja sebagai pengembang tunggal, saya sarankan Anda tidak mencoba menerapkan semuanya sendiri. Menggunakan perpustakaan SDL2 dapat sangat membantu Anda di banyak area dan mereka memiliki binding Python sehingga Anda dapat bekerja dalam bahasa yang Anda sukai. Untuk mencapai apa yang Anda tuju, desain arsitektur Anda harus dilakukan dengan sangat, sangat, hati-hati dan saya akan mengantisipasi setidaknya satu penulisan ulang penuh bahkan untuk tim yang berpengalaman. Selain itu, Python sebenarnya tidak terlalu mudah untuk dipelajari daripada bahasa lain dan menurut saya memiliki gotcha utama di tingkat menengah.
ttbek

Konsep yang Anda cari adalah hal yang umum di luar game dev. Ada kumpulan alat perangkat lunak yang disebut mesin aturan bisnis yang harus saya lakukan persis seperti ini. Di game dev, Anda juga bisa memanfaatkan alat ini. GameplayKit Apple misalnya termasuk kelas GKRuleSystem dan GKRule untuk tujuan yang sama. Perlu upaya untuk memperluas untuk memungkinkan pengeditan eksternal ini, tetapi dapat disusun dengan cara mengubah perilaku tanpa kompilasi ulang kode Anda.
Sandy Chapman

Jawaban:


34

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).


Saran yang solid. Saya mencoba untuk menjaga kode saya sebagai longgar digabungkan mungkin untuk memudahkan ekstensibilitas, tetapi Anda akan selalu memiliki kasus di mana jauh lebih mudah untuk hardcode / pasangan sesuatu. Bahkan sebagai pengembang profesional bukanlah tugas yang mudah, dan jelas bukan pemula yang ramah.
angarg12

TTS sekarang mendukung Lua dan menegakkan aturan tidak sepenuhnya sampai pada interaksi manusia sekarang.
Ave

17

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.


7
Jawaban ini menyiratkan bahwa Lua adalah satu-satunya bahasa scripting yang digunakan seperti itu. Ada banyak bahasa scripting lain yang dapat disematkan dalam mesin game. Beberapa mesin juga menjalankan cara mereka sendiri dan mengimplementasikan bahasa scripting khusus domain mereka sendiri. Saya biasanya tidak akan merekomendasikan itu (karena membangun bahasa adalah satu ton pekerjaan), tetapi harus disebutkan.
Philipp

3

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.


Membuatnya sebagai opensource adalah tujuan saya, sebenarnya. Apa yang saya lihat sebagai masalah adalah bagaimana menerapkan ekstensibilitas ini dengan cara yang paling mudah, sehingga pemain lain dalam game (yaitu game MP, btw) dapat membuat ekstensi mereka sendiri dari seperangkat aturan dasar, dan membaginya dengan masing-masing lainnya, entah bagaimana menghindari konflik pada saat bersamaan. Jadi, jika satu pengguna mengembangkan beberapa ekstensi yang mengesampingkan aturan tertentu, dan yang lain mengembangkan ekstensi yang berbeda, bagaimana memastikan bahwa pengguna ke-3 yang ingin menggunakan kedua hal itu di gimnya tidak akan mengalami masalah kompatibilitas? Selain memaksa mereka untuk berkolaborasi dengan erat.
tis

..dan untuk mengimplementasikannya sedemikian rupa sehingga tidak memerlukan modifikasi kode utilitas apa pun dan karena itu terlalu banyak pengetahuan tentang pemrograman.
tis

1
Saya tidak berpikir akan ada cara untuk mencegah masalah kompatibilitas, (bahkan mengatur warna sesuatu dapat menyebabkan itu!) Saya pikir hal yang lebih baik untuk dilakukan adalah memiliki cara untuk mendeteksi kemungkinan masalah kompatibilitas dan memiliki cara yang baik untuk pengguna untuk merespon. Bergantung pada desain antarmuka kode utilitas, dan ekstensi yang dimaksud, mungkin ada cara untuk memesan panggilan balik dll. Yang menghasilkan hasil yang diinginkan. Kemudian lagi, mungkin tidak ada. Memberitahu pengguna bahwa mungkin ada masalah dan mengapa sepertinya pengalaman pengguna yang lebih baik daripada hal-hal yang melanggar tanpa penjelasan.
Ryan1729

2

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.


Terima kasih, @Robyn. Adakah saran membaca untuk seseorang yang tidak tahu cara mendekati desain ini dengan benar? Apakah ada beberapa pola desain yang mapan untuk aplikasi seperti itu? Adakah buku yang membahas masalah ini?
tis

Tidak ada buku, maaf. Tetapi ide dasar dari mesin aturan sederhana: buat kelas aturan yang memiliki properti untuk setiap informasi yang Anda butuhkan untuk menggambarkan aturan. Jika beberapa properti ini memiliki fungsi lambda maka Anda dapat menetapkan perilaku kompleks kepada mereka. Buat kelas yang membuat daftar Aturan, jadi semua aturan Anda ada di satu tempat. Buat kelas lain yang memiliki metode yang mengambil daftar Aturan sebagai input dan menerapkannya ke sistem.
Robyn

2

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.


Meskipun saya bisa melihat bagaimana data game dapat didefinisikan dengan xml, saya tidak bisa membayangkan bagaimana Anda bisa menggunakannya untuk mendefinisikan mekanisme / aturan permainan. Bisakah Anda memberikan beberapa contoh / artikel tentang masalah, mungkin?
tis

Aturan @tis hanyalah jenis data lainnya. Jika mesin saya memiliki "Jika A do B" Saya dapat memuat A dan B dari file XML, sekarang pengguna dapat menempatkan aturan yang sewenang-wenang, satu bit tambahan yang dapat membantu adalah menyediakan daftar dengan semua As dan B yang mungkin Anda dukung per se , misalnya "Jika status statustipe lalu bergerak dengan kecepatan 100", "Jika status status dan waktu> x maka status statustipe" Jadi dalam desain Anda pikirkan tentang jenis aturan apa yang ingin Anda izinkan pada jenis objek apa (status, waktu, kecepatan gerak) dan dengan jenis komposisi apa yang memungkinkan (dan / atau, dll ...). Jika status bawah laut dan waktu> 5 kesehatan -10.
ttbek

1

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!


Masukan Anda benar-benar dihargai, dan Anda melakukan banyak upaya di dalamnya, jadi itu pasti bernilai +1, tapi saya kebetulan mengetahui tentang OOP, secara umum (meskipun kurang pengalaman di dalamnya). Masalah saya saat ini adalah dengan pendekatan desain paling umum yang harus saya ambil. Game saya bukan sesuatu yang sebesar D & D dalam skala, namun masih sangat dalam dalam mekanisnya. Itu berarti banyak yang rumit, bercampur pada aturan level yang berbeda. Yang saya ingin memungkinkan pengguna untuk memperluas secara signifikan, tidak hanya sedikit mengubah beberapa nilai. Mungkin tidak ada solusi yang lebih mudah, tentu saja ..
tis

@tis Kunci untuk ini adalah membuat keputusan yang benar tentang apa yang benar - benar objek dalam model game OO Anda. Tempat yang "jelas" untuk memulai adalah dengan "kata benda" seperti senjata, baju besi, dll bukan satu-satunya cara, dan itu dapat menyebabkan kekacauan kode yang tidak dapat disesuaikan. Jika aturan mengatakan "Anda hanya menembak beberapa monster dengan peluru perak di halaman gereja di tengah malam" di mana Anda menegakkan aturan itu dalam kode? Di kelas Gun (atau Bullet), di kelas Monster, di kelas Fighter dari pengguna senjata, di kelas Churchyard, atau di kelas Time? Jawaban terbaik mungkin "tidak ada di atas" ...
alephzero

... dan pikirkan kembali seluruh desain dalam hal kelas Aturan (yang mungkin benar-benar basis data) dan kelas Resolusi Konflik. Sekarang, aturan lain seperti "jika kamu tidak punya peluru, kamu masih bisa menggunakan senjatamu sebagai tongkat" dan "jika Alice melemparkan mantra yang sebagian (tapi tidak sepenuhnya) melindungi Bob dari luka tembak, sementara Charlie mencoba menembak Bob, lalu .... "punya tempat tunggal, dan" jelas, "untuk diterapkan dalam kode. Anda mungkin menemukan bahwa kelas Gun asli Anda sekarang melakukan sangat sedikit, kecuali menghasilkan beberapa efek audio-visual - dan bahkan tidak, jika itu adalah permainan berbasis teks!
alephzero

1

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.


Ya, saya perlu mengizinkan mereka untuk menambahkan mekanisme baru juga, hanya mengubah beberapa nilai tidak akan berhasil. Saya juga berpikir ini mungkin perlu bahasa yang terpisah, saya hanya berpikir mungkin sudah ada yang bisa saya gunakan dalam kode utilitas Python saya.
tis

@tis Sudahkah Anda mempertimbangkan apa yang Wikipedia miliki tentang topik ini? en.wikipedia.org/wiki/Logic_programming
ttbek

0

[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.

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.