Mengapa menempatkan entitas konfigurasi di luar skrip?

11

Saya telah melihat banyak game yang mendefinisikan komponen entitas dalam file skrip, tetapi ketika mereka mengkonfigurasi setiap entitas dan menentukan komponen apa yang dimilikinya, mereka menggunakan beberapa format file lain (seperti XML). Mengapa mereka melakukan itu?

Saya meminta sebagian besar untuk melihat apa alasan orang lain untuk ini. Saya juga mengkonfigurasi entitas saya di luar skrip (meskipun saya memilih JSON bukan XML). Alasan saya melakukan ini adalah untuk membuatnya lebih mudah bagi saya untuk mengimplementasikan save game dan juga karena saya pikir konfigurasi seperti ini lebih terorganisir dalam sesuatu seperti XML atau JSON.


@ Christopher Larsen menjawab: Terlalu panjang untuk mengirim sebagai komentar

Saya khawatir Anda mungkin telah sedikit menyimpang dari subjek pertanyaan. Masalah yang Anda uraikan lebih terkait dengan entitas berbasis hierarki; perhatikan dalam pertanyaan saya saya sebutkan saya sedang berbicara tentang entitas berbasis komponen.

Ini adalah contoh dari apa yang ingin saya tanyakan. Berikut adalah dua cara alternatif untuk mengonfigurasi entitas: melalui skrip dan melalui file JSON eksternal. Pertanyaan saya adalah, mengapa banyak orang lebih suka mengkonfigurasi entitas di luar skrip?

Kelas Entitas dasar:

class Entity:
    def __init__(self, name):
        pass
    def addComponent(self, comp):
        pass

Pendekatan skrip:

orc = Entity('Orc')
orc.addComponent(PositionComponent(3.4, 7.9))

Pendekatan JSON:

{
    "name" : "Orc",
    "components":
    {
        "PositionComponent": {
            "x" : 3.4,
            "y" : 7.9
        }
    }
}

Saya sudah menyatakan alasan saya untuk menggunakan pendekatan ini, yaitu teknis dan organisasi. Saya ingin tahu mengapa begitu banyak orang lain (dari apa yang saya lihat) menggunakan ini.

Paul Manta
sumber

Jawaban:

13

Keuntungan utama yang muncul di benak saya adalah memungkinkan konfigurasi untuk diedit / dikelola oleh non-programmer tanpa mengharuskan mereka menyentuh salah satu skrip game.

Dave Sherohman
sumber
Ini dapat dicapai dengan hanya memiliki dua file (equalivilents dari .h dan kemudian .cpp). Saya bertanya-tanya siapa yang akan menjadi orang yang ingin membuat objek (selain mengatakan do-nothing ini terlihat seperti vas dan do-nothing terlihat seperti butterly) yang juga tidak ingin menambahkan beberapa logika untuk itu (seperti jika seseorang tertutup serbuk sari dari bunga-bunga di dalam vas, tarik kupu-kupu). Dapat dibaca manusia itu hebat dan salah satu pemikiran saya tentang mengapa ini, tetapi di sana saya memindahkan JSON, Lua tables, dan XML semuanya memiliki tingkat keterbacaan manusia yang sama oleh non-programmer.
James
2
Glest adalah game yang dimodelkan dengan xml. Banyak non-programmer membuat mod untuk itu. Jelas lebih mudah didekati untuk memiliki xml / json daripada skrip.
Will
6

Salah satu alasan saya biasanya menggunakan file konfigurasi daripada skrip untuk ini adalah:

Satu-satunya cara untuk memeriksa kebenaran skrip misalnya menetapkan semua nilai dan itu adalah dengan menjalankannya.

Menulis kode untuk memungkinkan skrip mengkonfigurasi nilai-nilai berarti menulis kode untuk membuat objek kerangka bagi skrip untuk mengisi nilai-nilai dan kemudian memvalidasi bahwa skrip melakukannya dan itu. Lebih banyak kode dan kode buggier daripada memuat dari file konfigurasi datar, sering menggunakan pustaka yang mendukung semacam mekanisme validasi.

Akan
sumber
5
Kembali ketika pengembangan perangkat lunak utama lebih baik, ini dikenal sebagai Prinsip Least Power : Saat ini kita harus menghargai alasan untuk memilih bukan solusi yang paling kuat tetapi paling tidak kuat. Alasan untuk ini adalah bahwa semakin tidak kuat bahasanya, semakin banyak yang dapat Anda lakukan dengan data yang disimpan dalam bahasa itu.
1
@ Jo Itu benar-benar menggambarkan dengan cukup baik salah satu alasan saya juga menggunakan pendekatan ini. Pada awalnya saya mencoba mengkonfigurasi entitas saya dalam skrip, tetapi merasa sulit untuk menerapkan save-game (tidak dapat melacak hubungan antar komponen). Menggunakan file konfigurasi eksternal sangat membantu saya.
Paul Manta
Saya sebenarnya melihat ini sebagai sebaliknya, jika Anda sudah menggunakan antarmuka skrip maka Anda sekarang juga harus menyediakan metode validasi data untuk file konfigurasi daripada menggunakan antarmuka skrip yang sudah ditentukan untuk melakukannya untuk Anda.
James
2

Konfigurasi entitas dapat berupa serialisasi entitas tertentu. Ini memungkinkan Anda menangani pengeditan game dan memodulasi keluaran alat dengan cara yang kira-kira sama seperti halnya menyimpan game. Khususnya, untuk game di mana Anda tidak dapat memprediksi di negara mana entitas tertentu akan selama penyimpanan game - misalnya karena AI mereka atau karena mereka sebagian dihasilkan secara prosedural di tempat pertama - ini berguna untuk dapat membuang keseluruhan data yang mendefinisikan apa entitas "adalah" (sebagai lawan dari apa yang "dilakukannya") sebagai aliran byte yang akan disimpan.

Martin Sojka
sumber
1

Pola yang Anda gambarkan adalah implementasi Sistem Berbasis Data.

Sistem berbasis data biasanya digunakan dalam pengembangan game karena memungkinkan definisi konten untuk dienkapsulasi di luar sumber. Representasi eksternal ini kemudian dapat dengan mudah dimodifikasi (dan bahkan diperbarui secara realtime oleh aplikasi yang mengawasi modifikasi) untuk mengubah cara perilaku suatu entitas.

Setelah data didefinisikan secara eksternal, Anda memiliki segala macam kemungkinan dalam cara para desainer berinteraksi dengannya mulai dari mengedit file teks (ugh!) Secara langsung hingga UI canggih yang memandu pilihan perancang dengan logis, konsisten, dan bahkan diverifikasi kebenarannya (dari perspektif keseimbangan permainan).

Jika data disematkan secara langsung dalam kode, setiap perubahan akan membutuhkan pembangunan kembali aplikasi yang untuk proyek besar memakan waktu cukup lama serta waktu yang diperlukan untuk penyebaran binari (misalnya binari baru harus digunakan dan diinstal pada server).

Mari kita ambil contoh entitas sterotipikal "orc" ...

Salah satu cara implementasi untuk orc kami adalah dengan menulis deskripsi lengkap dalam kode semua karakteristik dan logika untuk orc tersebut.

  • maxhealth = 10
  • kerusakan = 3 kerusakan per detik
  • pelarian = benar
  • kabur ketika = kesehatan <10
  • agresif = benar

Ketika kita instantiate orc, semua nilainya diinisialisasi persis sama (atau mungkin statis). Masalah yang muncul adalah beberapa desainer akan datang dan mengatakan "Kami membutuhkan jenis orc yang berbeda untuk area pemula, yang memiliki kesehatan yang lebih sedikit, tidak pernah lari dan tidak agresif. Itu akan memungkinkan pemain baru terbiasa bertarung tanpa meningkatkan kesulitan dan kebingungan saat mempelajari sistem pertempuran ".

Hebat, sekarang Anda membutuhkan kelas yang berbeda atau (mungkin kami memandang ke depan) menyesuaikan nilai yang kami berikan ke "pabrik" yang membuat orc saat membuat mereka di area "pemula". Jadi kami melakukan perubahan, gunakan binari baru. Hanya untuk memiliki playtester kembali dan mengatakan nilai-nilai kesehatan baru terlalu rendah karena kita membunuh para Orc dalam satu pukulan.

Jika sistem kami didorong oleh data (dan poin bonus untuk aplikasi yang mendukung pemuatan ulang saat modifikasi dilakukan), maka modifikasi yang diperlukan untuk memuaskan perancang dan penguji permainan adalah perubahan data sederhana tanpa memerlukan kompilasi ulang / penyebaran yang diperlukan. Ini membuat desainer senang karena mereka tidak terjebak menunggu perubahan kode, dan itu membuat programmer senang karena kami terus-menerus memodifikasi kode sumber untuk mengubah nilai.

Mengambil sistem yang didorong data hingga ekstrem memungkinkan semuanya, mulai dari level gim, mantra, dan bahkan tugas diimplementasikan dengan perubahan sederhana pada data Anda yang tidak memerlukan perubahan kode sama sekali. Pada akhirnya, ini adalah tentang membuatnya mudah untuk membuat, mengubah dan mengulangi konten game.

Christopher Larsen
sumber
2
Skrip juga data menurut sebagian besar definisi
Will
1
-1. Pertanyaannya bukan tentang data didorong vs hard-coding, tetapi tentang skrip dinamis vs deklarasi statis.
@Christopher Saya menambahkan balasan panjang di OP saya. Silakan periksa.
Paul Manta
0

Dalam contoh Anda, Anda sebenarnya sudah menggunakan dua bahasa scripting. Ini adalah cara saya akan mengatakan dalam jangka panjang berhasil lebih baik tetapi saya akan menyarankan Anda menyatukan bahasa scripting yang Anda gunakan. Jika contoh skrip yang Anda berikan dilakukan di Lua daripada Json, saya akan mengatakan menggunakan tabel Lua untuk membangun objek Anda. Sintaksnya sebenarnya mirip dan memungkinkan Anda untuk mendukung satu antarmuka untuk mengekspos komponen Anda.

Untuk menyentuh mengapa orang memilih untuk melakukannya biasanya dalam XML dan kemudian skrip dalam logika, apakah ini masuk akal ketika Anda mengatakannya. Berikut adalah definisi objek pada data, apakah format penyimpanan data yang baik? Hampir selalu XML (meskipun saya juga menggunakan JSON;). Dan kemudian ketika mereka ingin menambahkan logika, baik yang dikodekan atau dimasukkan ke dalam file skrip.

Ini bukan pemikiran yang salah tetapi di mata saya orang tidak akan pergi ke langkah berikutnya. Lihatlah bahasa lengkap apa pun, c / c ++ / c # ,. Anda dapat mendefinisikan objek dan logikanya semua dalam satu bahasa, mengapa tidak melakukan hal yang sama di antarmuka skrip Anda ... Ini hampir seperti mengatakan kita harus mendefinisikan kelas kita dalam XML dan metode kita di c # ketika Anda memikirkannya. Mungkin bahasa skrip permainan yang lebih lama tidak cukup kuat dan masih hanya bertahan seperti yang dilakukan.

James
sumber