Apa tingkat granularity yang tepat untuk arsitektur berbasis komponen?

26

Saya sedang mengerjakan game dengan arsitektur berbasis komponen. An Entitymemiliki satu set Componentinstance, yang masing-masing memiliki satu set Slotinstance untuk menyimpan, mengirim, dan menerima nilai. Fungsi pabrik seperti Playermenghasilkan entitas dengan komponen dan koneksi slot yang diperlukan.

Saya mencoba menentukan tingkat granularitas terbaik untuk komponen. Sebagai contoh, sekarang Position, Velocitydan Accelerationsemua komponen yang terpisah, dihubungkan secara seri. Velocitydan Accelerationbisa dengan mudah ditulis ulang menjadi seragam Deltakomponen, atau Position, Velocitydan Accelerationdapat dikombinasikan bersama komponen seperti Frictiondan Gravitymenjadi monolitik Physicskomponen.

Haruskah komponen memiliki tanggung jawab sekecil mungkin (dengan biaya banyak interkonektivitas) atau haruskah komponen terkait digabungkan menjadi yang monolitik (dengan biaya fleksibilitas)? Saya condong ke arah yang pertama, tetapi saya bisa menggunakan pendapat kedua.

architecture entity-system component-based

— Jon Purdy
sumber

Pertanyaan serupa: gamedev.stackexchange.com/questions/4914/…

— Den

Apakah Anda akan menggunakan mesin fisika Anda sendiri atau mengintegrasikan yang sudah ada?

— Den

@Den: Saya sedang menulis beberapa kode fisika , tetapi ini bukan mesin dengan cara apa pun. Hanya kinematika 2D biasa.

— Jon Purdy

14

Ada garis antara granularity lengkap, yang mengarah ke tidak ada pemborosan kode atau keadaan seperti gumpalan (itulah sebabnya arsitektur komponen disukai), dan kegunaan.

Jelas hal-hal mungkin memiliki Position, tetapi mereka belum tentu dinamis (jadi mengapa harus Velocitydan Acceleration?). Namun, sesuatu dengan a Velocityakan menjadi objek yang bergerak, jadi masuk akal juga untuk Accelerationdikelompokkan.

Apakah Anda akan memiliki kasus di mana v dan a akan dibutuhkan, tetapi Anda tidak ingin simulasi fisika untuk mereka? Demikian pula, akan ada gunanya Gravityjika mereka bukan benda fisika?

tl; dr Kelompok apa yang masuk akal.

— Bebek Komunis
sumber

1

Terdengar adil. Sistem saya memiliki sentralisasi yang sangat sedikit: jika suatu Entitymemiliki Positiondan beberapa komponen yang membuatnya Positionberpartisipasi dalam fisika, maka itu Entityadalah fisik de facto . Saya pikir apa yang dapat saya lakukan hanyalah menambahkan beberapa komponen untuk pengelompokan logis, dan menjaga semua komponen mendasar menjadi satu tanggung jawab. Jadi menambahkan, katakanlah, Movableke Entityakan memiliki efek yang sama seperti menambahkan Position, Velocity, dan Acceleration.

— Jon Purdy

6

Untuk menghindari pengelolaan mikro setiap variabel yang saya sarankan dengan memulai yang berat, pilih divisi di sekitar tanggung jawab dan refactor ketika situasi muncul dengan sendirinya secara logis. Anda dapat memulai desain pertama di atas kertas. Pada titik tertentu, pembagian tanggung jawab besar ini akan menjadi blok bangunan entitas Anda.

Jadi sebagai contoh bergegas Anda memiliki Game. Game terbagi menjadi Lingkungan + Negara. Lingkungan terbagi menjadi StaticWorld + MovingStuff. Status dibagi menjadi AIControlled + PlayerControlled. Gagasan kotor Damage terbagi menjadi TakesDamage + GivesDamage.

Dan seterusnya.

Sama seperti saran umum untuk "Bangun game, bukan mesin!" untuk praktisi baru saya sarankan "Bangun Game, bukan sistem komponen yang rumit!" karena hanya dengan pengalaman pribadi dengan game yang berjalan Anda akan tahu apakah sistem komponen yang rumit diperlukan untuk pekerjaan mendatang.

— Patrick Hughes
sumber

Saya bukan pengembang baru. Jika saya memiliki komponen berdasarkan konsep daripada perilaku (yaitu, top-down versus bottom-up), bukankah arsitektur saya akan lebih rapuh, dan lebih rumit? Saya bisa menerapkan perilaku apa pun yang saya inginkan dari komponen kecil, tetapi saya tidak selalu bisa mendapatkan perilaku yang diinginkan dari yang sudah dikombinasi. Belum lagi saya tidak bisa memprediksi semua yang ingin saya capai bahkan dalam konteks satu pertandingan.

— Jon Purdy

Kelemahan dari bawah ke atas adalah bahwa komunikasi antar komponen menjadi masalah, dan orang-orang cenderung mulai terlalu mikro dalam skala apa yang mereka modelkan. Saya terutama berusaha untuk menjauh dari super-mikro "xyz adalah komponen" "rotasi adalah komponen" "rgb adalah komponen" level untuk seseorang yang belum berpengalaman.

— Patrick Hughes

Cukup adil. Saya hanya ingin memastikan saya mengerti Anda dengan benar. Dengan sistem slot yang saya miliki, itu sederhana dan efisien untuk komponen untuk berkomunikasi, jadi saya benar-benar tidak melihat kekurangan pada skala "super-mikro". Saya tidak bermaksud mengubah ini menjadi mesin mandiri, tetapi jika saya lakukan, maka saya selalu dapat memperkenalkan abstraksi seperti kelompok komponen yang saya sebutkan dalam komentar saya pada jawaban The Communist Duck.

— Jon Purdy

4

Dugaan saya adalah menggabungkan komponen yang akan memiliki banyak interaksi. Dalam kasus Anda, saya akan menjaga posisi dalam satu komponen, dan memiliki kecepatan & akselerasi yang disatukan dalam komponen fisika.

Tapi itu sangat tergantung pada apa fitur game Anda (kecuali Anda membangun kerangka kerja tanpa memikirkan game tertentu).

— XGouchet
sumber

2

Masalah dengan menggabungkan komponen dengan banyak interaksi adalah bahwa kadang-kadang bagian lain tidak diperlukan.

— Bebek Komunis

4

Saya menyadari ini adalah pertanyaan lama tetapi mungkin seseorang akan menemukan jawaban ini bermanfaat.

Saya percaya itu Systemsakan lebih membantu Anda untuk memahami bagaimana membangun Komponen. Sistem ada dalam arsitektur di mana komponen tidak mengandung logika mereka sendiri, selain dari fungsi pengambil / setter dan penolong sederhana. Sistem beroperasi pada Entitas yang memenuhi persyaratan Komponen. Inilah sebabnya mengapa yang terbaik adalah memisahkan data komponen sebanyak masuk akal untuk data yang akan diproses tanpa data lainnya.

Misalnya, Anda mungkin memiliki MovementSystempembaruan yang Entitasnya Positionberdasarkan Velocity. Ini bisa untuk entitas sederhana dalam game. Tapi, untuk Player dan Musuh, Anda mungkin menginginkan gerakan yang telah Accelerationdiproses AcceleratedMovementSystem. Tapi untuk Hambatan mungkin Anda inginkan Friction. The Terrain mungkin juga memiliki gesekan, tetapi tidak akan memiliki komponen kecepatan. Tapi bagaimana dengan itu Gravity? Tambahkan saja Player, Musuh, dan Rintangan, dan buat GravitySystemuntuk memprosesnya.

Intinya adalah bahwa semakin dipisahkan Anda Components, semakin extensible yang Entitiesakan ketika menggunakan Systems.

Sunting: Membuat pernyataan terakhir lebih jelas.

Sunting: Oke, saya sudah mengerjakan Sistem saya sendiri dan sampai pada realisasi ini. Contoh untuk membagi Posisi dan Velocity adalah bahwa memanipulasi Velocity menyebabkan Posisi berubah dengan MovementSystem. Akibatnya, 'InputMovementSystem' tidak memerlukan Posisi untuk membuat Player berpindah dari Input pengguna karena MovementSystem akan mengambil perubahan dalam Velocity untuk diterapkan ke Posisi. Memang, itu masih bekerja dengan baik untuk menyatukan mereka, tetapi itulah contoh mengapa tidak perlu.

Saya membaca posting blog baru-baru ini yang mengatakan sesuatu seperti ini:

"Jika Anda memiliki data yang dapat dikelompokkan dengan 2 komponen berbeda, yang terbaik adalah membuat komponen ketiga dengan data itu."

— Dan H.
sumber