Apa peran "sistem" dalam arsitektur entitas berbasis komponen?


177

Saya telah membaca banyak tentang komponen entitas dan sistem dan berpikir bahwa gagasan entitas hanya menjadi ID cukup menarik.

Namun saya tidak tahu bagaimana ini sepenuhnya bekerja dengan aspek komponen atau aspek sistem. Komponen hanyalah objek data yang dikelola oleh beberapa sistem yang relevan. Sistem tumbukan menggunakan beberapa BoundsComponent bersama dengan struktur data spasial untuk menentukan apakah tumbukan telah terjadi.

Semua baik sejauh ini, tetapi bagaimana jika beberapa sistem memerlukan akses ke komponen yang sama? Di mana seharusnya data tinggal? Sistem input dapat memodifikasi entitas BoundsComponent, tetapi sistem fisika memerlukan akses ke komponen yang sama seperti halnya beberapa sistem rendering.

Juga, bagaimana entitas dibangun? Salah satu kelebihan yang saya baca banyak tentang fleksibilitas dalam konstruksi entitas. Apakah sistem secara intrinsik terkait dengan suatu komponen? Jika saya ingin memperkenalkan beberapa komponen baru, apakah saya juga harus memperkenalkan sistem baru atau memodifikasi yang sudah ada?

Hal lain yang sering saya baca adalah bahwa 'tipe' suatu entitas disimpulkan oleh komponen apa yang dimilikinya. Jika entitas saya hanya sebuah id, bagaimana saya bisa tahu bahwa entitas robot saya perlu dipindahkan atau dirender dan kemudian dimodifikasi oleh beberapa sistem?

Maaf untuk posting lama (atau setidaknya sepertinya begitu dari layar ponsel saya)!

Jawaban:


336

Ada banyak cara untuk mewakili dan menerapkan sistem komponen entitas, tetapi di sini ada penjelasan satu cara. Ingatlah bahwa tidak ada definisi konkret tentang arsitektur entitas / komponen / sistem, jadi ini hanya satu implementasi.

Saya akan memperkenalkan analogi untuk entitas / komponen / arsitektur sistem yang mungkin membantu. Mari kita pikirkan entitas seperti kunci.

Entitas

Kunci entitas

Kunci juga memiliki gigi (biru tua). Gigi kunci entitas kami adalah komponen yang membuatnya. Anda dapat membedakan entitas dengan ID mereka, bahkan jika mereka memiliki gigi yang sama. Jadi apa yang cocok dengan kunci? Kunci. Kunci adalah sistem kami. Misalnya, sistem pergerakan.

Sistem

Kunci sistem gerakan

Kunci hanya berfungsi jika kunci kami memiliki gigi untuk posisi dan kecepatan. Sistem ini hanya memproses entitas yang memiliki posisi dan kecepatan. Ada beberapa cara untuk mengatur bagaimana sistem ini mengenali entitas mana yang akan diproses, tetapi satu cara adalah dengan menggunakan a long. Setiap bit dicadangkan untuk tipe komponen. Sebagai contoh, mari kita asumsikan tipe 4 bit daripada panjang 64 bit. Entitas contoh kami akan memiliki semua komponen yang tersedia. Jadi kuncinya adalah 1111. Kemudian, sistem mencari entitas yang memiliki 11--. ( -Representasi tidak peduli, karena gerakan tidak peduli jika ada sprite atau kesehatan). Itu dapat memeriksa entitas dengan ANDoperasi sederhana . Jadi entitas kami cocok jika ((1111 & 1100) == 1100). Jika saya kehilangan Anda di sana, periksa lebih lanjut tentang operasi bitwise .

Seperti yang Anda lihat, sistem memiliki akses ke sumber daya luar. Mereka dapat mengakses waktu, grafik, suara dan sebagainya. Mereka hanyalah prosesor kecil yang mengambil satu kunci sekaligus, dan memproses data. Anda melihat bahwa sistem pergerakan mengambil kecepatan, waktu delta dan posisi; kemudian melakukan beberapa perhitungan dan menyimpan hasilnya kembali ke posisi semula.

Kunci entitas sangat mudah dibuat. Anda dapat menambah atau menghapusnya sesuka hati. Entitas tidak peduli, itu hanya cara untuk mengelompokkan dan memegang komponen. Komponen tidak memiliki saling ketergantungan. Komponen terdekat yang berinteraksi dengan satu sama lain adalah ketika suatu sistem beroperasi pada mereka dan menggunakan data dari satu untuk memperbarui yang lain, seperti contoh gerakan kami.

Mari kita lihat sistem lain untuk membantu memperkuat ide:

Menggambar kunci sistem

Ini adalah sistem gambar kami. Itu mencari komponen yang cocok 1-1-. Entitas ini cocok karena: ((1111 & 1010) == 1010)Selain itu, Anda dapat melihat bahwa sistem ini menampilkan informasi ke layar, dengan menggambar sprite entitas pada posisinya.

OKE, satu lagi. Mari kita lihat entitas lain dan lihat bagaimana hal itu sesuai dengan contoh kita sejauh ini.

Kunci entitas yang tidak dapat dipindahkan

Seperti yang Anda lihat, entitas ini memiliki lebih sedikit komponen yang melekat padanya. Dengan melihat komponen-komponen yang dimilikinya, sepertinya itu bisa menjadi benda statis seperti batu. Itu hanya memiliki posisi dan sprite. Itu tidak akan bergerak dan tidak akan terpengaruh oleh perubahan kesehatan. Entitas ini akan menghasilkan kunci 1010. Jadi sistem apa yang beroperasi pada entitas ini? Mari kita periksa:

Melawan sistem pergerakan kita: ((1010 & 1100) != 1100)Tidak. Sepertinya sistem pergerakan tidak peduli dengan entitas ini, karena tidak memiliki komponen yang diperlukan.

Melawan sistem menggambar kami: ((1010 & 1010) == 1010)Hei, itu cocok. Entitas ini akan dioperasikan oleh sistem gambar. Sistem gambar akan menggambar sprite pada posisi yang ditentukan.


Mudah-mudahan Anda dapat melihat betapa mudahnya sekarang menambahkan sistem lain yang akan mengambil komponen kami dan mengoperasikannya. Biarkan saya memastikan saya telah menjawab pertanyaan Anda:

Bagaimana jika banyak sistem memerlukan akses ke komponen yang sama? Di mana seharusnya data tinggal?

Biasanya, sistem beroperasi satu demi satu. Mereka memproses semua entitas yang sesuai dengan kebutuhan mereka, kemudian sistem selanjutnya melakukan hal yang sama dan seterusnya. Data tinggal bersama entitas. Seharusnya tidak ada sesuatu yang disimpan dalam sistem, itu hanya kunci yang diputar, kuncinya adalah di mana informasi tetap dan bergerak dari kunci ke kunci.

Bagaimana entitas dibangun? Apakah sistem secara intrinsik terkait dengan suatu komponen? Jika saya ingin memperkenalkan beberapa komponen baru, apakah saya juga harus memperkenalkan sistem baru atau memodifikasi yang sudah ada?

Entitas hanyalah tas komponen. Mereka memiliki ID unik dan daftar komponen. Sistem hanya terikat pada komponen dengan cara yang dijelaskan di atas. Anda dapat memiliki komponen tanpa sistem yang beroperasi pada mereka, tetapi itu tidak ada gunanya. Demikian pula Anda dapat memiliki sistem yang mencari komponen yang tidak dimiliki entitas. Itu tidak ada gunanya, karena mereka mungkin hanya menunggu entitas yang dibuat yang cocok dengan kunci mereka. Jadi, ya, jika Anda memperkenalkan komponen baru, Anda ingin membuat sistem yang menggunakan komponen itu. Kalau tidak, Anda hanya menambahkan gigi ke kunci Anda untuk kunci yang tidak ada.

Jika entitas saya hanya sebuah id, bagaimana saya bisa tahu bahwa entitas robot saya perlu dipindahkan atau dirender dan kemudian dimodifikasi oleh beberapa sistem?

Saya pikir saya menjawab ini dengan gagasan longkunci yang mendefinisikan komponen yang terkandung dalam suatu entitas. Anda tahu karena kunci cocok dengan kunci.

Fiuh! Itu posting yang panjang! (Atau setidaknya sepertinya begitu dari monitor besar saya.)


23
Analogi utama ini sangat membantu untuk memahami seluruh gagasan sekarang. Ide brilian! Lol di paragraf terakhir Anda :)
bio595

16
+1 Untuk penjelasan terbaik dan terbaik dari sistem entitas-komponen yang pernah saya lihat. :HAI!
knight666

7
-1 dari saya - bukan karena ini adalah pendekatan yang buruk, tetapi karena itu digambarkan sebagai pendekatan THE. Namun ada banyak sistem di mana tidak ada pemisahan komponen dan layanan (mis. Di Unity), dan ada cara yang lebih sederhana untuk sistem untuk mengetahui entitas mana yang akan diproses (tambahkan saja ketika entitas dibuat).
Kylotan

37
@Kylotan Saya memang mengatakan " Ada beberapa cara untuk mengatur bagaimana sistem ini mengenali entitas mana yang akan diproses, tetapi satu cara adalah dengan menggunakan a long. " Selain itu, saya biasanya menyimpan suara turun untuk jawaban yang tidak berguna (seperti teks hover kata). Saya pikir Anda akan menghabiskan banyak waktu untuk memberikan suara jika Anda melakukannya untuk semua jawaban yang tidak mencakup 100% dari topik yang mereka bahas.
MichaelHouse

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.