Daftarkan Komponen Objek Game di Subsistem Game? (Desain Objek Game berbasis Komponen)

Saya membuat sistem objek game berbasis komponen . Beberapa tips:

GameObjecthanyalah daftar Components.
Ada GameSubsystems. Misalnya, rendering, fisika, dll. Masing GameSubsystem- masing berisi pointer ke beberapa Components. GameSubsystemadalah abstraksi yang sangat kuat dan fleksibel: ia mewakili setiap irisan (atau aspek) dari dunia game.

Ada kebutuhan dalam mekanisme mendaftar Componentsmasuk GameSubsystems(ketika GameObjectdibuat dan disusun). Ada 4 pendekatan :

1: Pola rantai tanggung jawab . Setiap Componentditawarkan kepada setiap orang GameSubsystem. GameSubsystemmembuat keputusan Componentsuntuk mendaftar (dan bagaimana mengaturnya). Misalnya, GameSubsystemRender dapat mendaftarkan Komponen yang Dapat Diurai.

pro. Componentstidak tahu apa-apa tentang bagaimana mereka digunakan. Kopling rendah. A. Kita dapat menambahkan yang baru GameSubsystem. Sebagai contoh, mari kita tambahkan GameSubsystemTitles yang mendaftarkan semua ComponentTitle dan menjamin bahwa setiap judul adalah unik dan menyediakan antarmuka untuk menanyakan objek berdasarkan judul. Tentu saja, ComponentTitle tidak boleh ditulis ulang atau diwariskan dalam kasus ini. B. Kita dapat mengatur kembali yang sudah ada GameSubsystems. Misalnya, GameSubsystemAudio, GameSubsystemRender, GameSubsystemParticleEmmiter dapat digabungkan ke dalam GameSubsystemSpatial (untuk menempatkan semua audio, emmiter, render Componentsdalam hierarki yang sama dan gunakan transformasi relatif orangtua).

menipu. Pemeriksaan setiap-untuk-setiap. Sangat tidak efisien.

menipu. Subsystemstahu tentang Components.

2: Setiap Subsystempencarian untuk Componentsjenis tertentu.

pro. Performa yang lebih baik daripada di Approach 1.

menipu. Subsystemsmasih tahu tentang Components.

3: Componentmendaftar sendiri GameSubsystem(s). Kita tahu pada saat kompilasi bahwa ada GameSubsystemRenderer, jadi mari kita ComponentImageRender akan memanggil sesuatu seperti GameSubsystemRenderer :: register (ComponentRenderBase *).

pro. Performa. Tidak ada pemeriksaan yang tidak perlu seperti pada Approach 1.

menipu. Componentsburuk ditambah dengan GameSubsystems.

4: Pola mediator . GameState(yang berisi GameSubsystems) dapat mengimplementasikan registerComponent (Komponen *).

pro. Componentsdan GameSubystemstidak tahu apa-apa tentang satu sama lain.

menipu. Dalam C ++ akan terlihat seperti typeid-switch jelek dan lambat.

Pertanyaan: Pendekatan mana yang lebih baik dan sebagian besar digunakan dalam desain berbasis komponen? Apa Kata Praktek? Ada saran tentang implementasi Approach 4?

Terima kasih.

c++ architecture component-based

— kanan atas
sumber

Saya mencium bau over-engineering. Komponen mendaftar sendiri dengan GameObject. Jika GameSubsystem adalah apa yang saya pikirkan, maka itu hanya daftar komponen yang dapat ditambahkan ke GameObject sekaligus. Bagaimana Anda menggambarkannya, sepertinya ada semacam "keajaiban" bagaimana GameObjects dan Komponen berkumpul (mereka mencari satu sama lain? Mengapa?). Saya juga merasa bahwa Anda mencoba menggunakan komponen untuk semua yang ada di mesin Anda, yang juga akan saya pertimbangkan. Untuk apa nilainya, saya hanya akan mempertimbangkan opsi 3 atau 4.

— LearnCocos2D

@GamingHorror, Mendaftar Componentsdi GameObjectsluar ruang lingkup pertanyaan saya. Baca artikel tentang pendekatan berbasis komponen atau ajukan pertanyaan Anda sendiri di situs ini jika Anda tertarik. Apa yang Anda pikirkan GameSubsystembenar-benar salah.

— topright

Saya bias mengembangkan komponen untuk logika game, bukan komponen mesin, dan deskripsi Anda sepertinya mengarah ke arah itu. Saya memahami sistem komponen dengan sangat baik, saya pikir saya terlempar karena saya tidak terbiasa dengan terminologi yang Anda gunakan, khususnya GameSubsystem. Dari apa yang saya baca, sepertinya Anda mencoba membangun semuanya (mis. Seluruh mesin) hanya dari komponen.

— LearnCocos2D

Ya, "Objek permainan berbasis komponen" dan "Pemrograman berorientasi komponen" adalah istilah yang berbeda, bisa membingungkan. Jangan menjadi bias, lebih baik menjadi "bilased": scottbilas.com/files/2002/gdc_san_jose/game_objects_slides.ppt

— topright

Pintu nomor 3 ... Komponen mendaftar sendiri di GameSubsystem

Komponen sudah ada untuk menjaga agar kopling tetap diabstraksi dari GameObject itu sendiri. Entah bagaimana, di suatu tempat sesuatu memang perlu berinteraksi dengan subsistem dan ini adalah komponen dan tujuannya.

Kopling sebenarnya bukan hal yang buruk dalam kasus ini.

Kinerja pada dasarnya diperlukan dalam hal ini jika Anda berharap memiliki kompleksitas dalam sistem Anda, Anda tidak mampu membayar pendekatan gaya pencarian opsi lain.

Akhirnya jika satu subsistem perlu reaktif ke yang lain (renderer, fisika, audio semua perlu melakukan hal-hal ketika sesuatu terjadi) komponen dapat memfasilitasi ini satu sama lain melalui objek permainan dan menjaga jenis tertentu dari sistem cross-coupling dikelola melalui komponen.

— Rick
sumber

Itu bagus. Tetapi bagaimana komponen tahu tentang GameSubsystems? Apakah semua subsistem lajang? Itu tidak jelek? ... Saya sedang memikirkan solusi lain seperti injeksi ketergantungan ... tetapi kapan dan siapa yang memberikan instance subsistem ke setiap komponen?

— Dani

@Dani Components tidak perlu mengakses langsung ke instance subsistem, mereka hanya perlu mengirim pesan meminta pendaftaran dilakukan, mereka tidak perlu tahu apa itu Subsystem (tetapi mereka kemungkinan besar akan) dan mengapa apakah mereka akan menjadi lajang? Itu bukan persyaratan, bahkan jika dalam kebanyakan kasus Anda hanya perlu satu instance subsistem untuk setiap subsistem.

— Pablo Ariel

@Pablo - setuju.

— Rick