Warisan vs Komposisi

Saya menghasilkan uang dalam bahasa C # Umumnya dalam bahasa itu saya suka memisahkan segala sesuatu ke langit tinggi menggunakan antarmuka. Ini telah membantu saya dengan baik dalam kode perusahaan tetapi dalam menulis game di C # Saya mendapati diri saya cenderung ke warisan karena mampu mendefinisikan beberapa perilaku default untuk kelas dasar. Saya merasa kotor melakukan ini, seperti saya tidak menaati beberapa dewa arsitektur yang pernah berkata "mendukung komposisi daripada warisan". Saya tahu ini bukan hitam dan putih tetapi saya juga merasa seperti saya bisa menggunakan antarmuka dengan sedikit lebih banyak pekerjaan dan mencapai hal yang hampir sama.

Apa yang dilakukan orang lain? Apakah pewarisan pendekatan yang tepat untuk game atau haruskah saya refactor di beberapa antarmuka?

c# architecture

— Peter Short
sumber

Antarmuka juga bukan komposisi, jadi tidak jelas apa yang Anda tanyakan.

Saya hanya ingin menyebutkan bahwa karena Anda bekerja dengan C #, Anda akan mengalami kesulitan jika Anda memilih untuk menggunakan warisan karena C # tidak mendukung multiple inheritance yang sebenarnya. Menggunakan metode banyak antarmuka baik-baik saja sampai Anda masuk ke kisaran antarmuka 4-5 dan harus memotong / menempelkan 25+ baris kode antara setiap kelas yang berbagi implementasi yang sama. Ada beberapa putaran pekerjaan tetapi mereka juga jelek karena bahasa tidak memberikan dukungan langsung.

— NtscCobalt

Jawaban:

Warisan dalam permainan sebenarnya adalah salah satu hal terburuk yang dapat Anda lakukan - khususnya dalam hal entitas. Baca ini untuk alasannya. Komposisi atas warisan membawa Anda jauh dengan permainan. Sedangkan untuk area lain dari mesin Anda, itu tidak terlalu penting. Katakan misalnya Anda membuat panggilan ke beberapa jenis layanan jaringan eksternal, maka Anda dapat mewarisi satu jenis layanan generik ke misalnya. HTTPService dan SocketService - sangat banyak seperti di aplikasi perusahaan yang biasa Anda gunakan.

Kecuali gim Anda benar-benar sederhana, Anda akan ingin menggunakan arsitektur entitas berbasis komponen (CBE). Gagasan umum adalah bahwa dengan entitas, alasan mereka begitu umum dikomposisikan daripada diwariskan adalah karena Anda tidak dapat mengetahui sampai runtime kemampuan apa yang akan dimiliki entitas tertentu. Misalnya, ambil kapal pemain dalam penembak ruang. Anda tidak tahu sampai titik tertentu selama permainan, apa senjata, baju besi, sistem (yaitu komponen) yang pemain akan ambil, beli, jual, kalah, hancurkan, dll. Jadi satu-satunya cara realistis untuk memodelkan ini adalah melalui komposisi objek. Sisi positifnya dalam skenario ini adalah Anda juga dapat memiliki musuh yang sepenuhnya dapat disesuaikan, dibangun dengan cara yang sama, daripada musuh yang selalu sama persis setiap kali Anda melihat tipe musuh itu. Jadi dengan CBE, Anda mungkin melihat Freighter Mars dan berpikir, "Ah itu hanya memiliki laser kecil, saya akan menurunkannya", dan biasanya itu benar tetapi ketika Anda berada dalam jangkauan tiba-tiba Anda menyadari bahwa ia memiliki pantat besar senjata lubang cacing. Kejutan kejutan!

Componentisation menghapus kopling logika implisit, dan itu BAIK.

— Insinyur
sumber

Terima kasih atas saran teman :) Senang mengetahui bahwa saya tidak mendengar suara!

— Peter Short

+1 Terima kasih atas artikelnya, saya sudah lama ingin melakukan ini di permainan saya

— John McDonald

Harus dicatat bahwa karena saling ketergantungan yang tinggi dari entitas game, pewarisan sering mempersulit hal-hal dan menjadikan pemeliharaan dan perluasan tugas yang rumit. Sistem komponen mengatasi masalah ini dengan baik dan manfaat tambahan lainnya adalah apa yang tercantum dalam jawaban di atas;)

— James

Perlu juga dicatat bahwa "tetapi ketika Anda tiba dalam jangkauan tiba-tiba Anda menyadari itu memiliki senjata lubang cacing pantat besar. Kejutan mengejutkan!" adalah desain game yang buruk: D

— Jonathan Connell

Kejutan itu menyenangkan, tetapi kejutan itu berarti Anda mati tanpa peringatan, seperti kapal tingkat rendah yang bisa OHKO Anda, hanya membuat frustrasi;) Tentu saja ini mungkin bukan yang Anda maksudkan dalam jawaban Anda. Selain itu, ada banyak hal yang lebih dari satu game daripada hanya desain game.

— Jonathan Connell

Bagi mereka yang berbicara bahasa Jerman buku yang menarik: http://www.amazon.com/Architektur-Kerns-einer-Game-Engine-Implementierung/dp/3639324471/ref=sr_1_1?ie=UTF8&qid=1314875533&sr=8-1

Pandangan lebih dekat tentang kapan dan mengapa menggunakan arsitektur mana yang dapat ditemukan di sini: /programming/1901251/component-based-game-engine-design

Untuk diri saya, saya memutuskan arsitektur saya tergantung pada ukuran proyek dan kemungkinan untuk memperpanjang atau menggunakan kembali kode. Mengapa berinvestasi berjam-jam ke dalam arsitektur proyek mikro di mana tidak ada peluang Anda menggunakan kode lagi? Pada saat yang sama Anda dapat menyelesaikan proyek.

Komposisi vs Komponen Komponen adalah barang mewah yang keren, tetapi di sebagian besar proyek / komposisi arsitektur akan mengerjakannya juga (tanpa overhead berbasis komponen). Itu tergantung apa yang dapat diberikan oleh komponen-sistem Anda yang komposisi tidak bisa.

Misalnya, ambil kapal pemain dalam penembak ruang. Anda tidak tahu sampai titik tertentu selama permainan, apa senjata, baju besi, sistem (yaitu komponen) yang pemain akan ambil, beli, jual, kalah, hancurkan, dll. Jadi satu-satunya cara realistis untuk memodelkan ini adalah melalui komposisi objek.

semua itu mungkin tanpa komponen sejak dulu juga

— perbaikan ide
sumber

-1, komponen adalah bentuk komposisi.

baik, bentuk tetapi tidak sama karena mereka menyediakan fitur yang berbeda. (Jadi saya tidak mengerti komentar Anda dan -1)

— idefix

Ketika Anda mengatakan "komposisi vs komponen" tidak jelas apa yang Anda bandingkan karena komponen adalah komposisi. Apakah maksud Anda komponen dinamis vs. komponen statis? Salah satu dari mereka versus komposisi jenis terkait baik keluarga maupun struktural? Apa itu "overhead berbasis komponen"? Dalam sistem komponen statis (dan banyak yang dinamis) overhead hampir nol.

Hm, poin menarik. Apakah Anda keberatan dengan diskusi yang lebih rinci? Jika tidak, saya ingin mengirimi Anda alamat email saya di platform lain.

— idefix