Desain game tradisional , seperti yang saya tahu, menggunakan polimorfisme dan fungsi virtual untuk memperbarui status objek game. Dengan kata lain, rangkaian fungsi virtual yang sama disebut dengan interval reguler (ex: per-frame) pada setiap objek dalam game.
Baru-baru ini, saya menemukan, bahwa ada sistem pesan berbasis event lain yang tersedia untuk memperbarui status objek game. Di sini, objek biasanya tidak diperbarui berdasarkan per-frame. Alih-alih, sistem pesan acara yang sangat efisien dibuat, dan objek permainan diperbarui hanya setelah menerima pesan acara yang valid.
Arsitektur Game Driven Event dijelaskan dengan baik di: Game Coding Lengkap oleh Mike McShaffry .
Bisakah saya meminta bantuan dengan pertanyaan-pertanyaan berikut:
- Apa kelebihan dan kekurangan dari kedua pendekatan tersebut?
- Di mana yang lebih baik dari yang lain?
- Apakah desain game yang didorong Event universal dan lebih baik di semua bidang? Apakah karena itu direkomendasikan untuk penggunaan bahkan di platform mombile?
- Mana yang lebih efisien dan mana yang lebih sulit untuk dikembangkan?
Untuk memperjelas, pertanyaan saya bukan tentang menghapus polimorfisme sepenuhnya dari desain game. Saya hanya ingin memahami perbedaan dan manfaat dari menggunakan pesan yang digerakkan oleh acara vs panggilan biasa (per-frame) ke fungsi virtual untuk memperbarui status permainan.
Contoh: Pertanyaan ini menyebabkan sedikit kontroversi di sini, jadi izinkan saya menawarkan Anda contoh: Menurut MVC, mesin permainan dibagi menjadi tiga bagian utama:
- Lapisan Aplikasi (Perangkat Keras dan komunikasi OS)
- Logika Game
- Tampilan Game
Dalam gim balap, Game View bertanggung jawab untuk merender layar secepat mungkin, setidaknya 30fps. Game View juga mendengarkan input pemain. Sekarang ini terjadi:
- Pemain menekan pedal bahan bakar hingga 80%
- GameView membuat pesan "Pedal 2 Bahan Bakar Mobil Ditekan hingga 80%" dan mengirimkannya ke Game Logic.
- Game Logic mendapatkan pesan, mengevaluasi, menghitung posisi dan perilaku mobil baru dan membuat pesan berikut untuk GameView: "Draw Car 2 Fuel Pedal Pressed 80%", "Car 2 Sound Acceleration", "Car 2 Coordinates X, Y" .. .
- GameView menerima pesan dan memprosesnya sesuai
sumber
update). Yang kedua bisa Anda lakukan dengan olahpesan karena berbagai alasan.Jawaban:
Saya sangat percaya pada kebutuhan menjadi ibu dari penemuan. Saya tidak suka kode apa pun kecuali kebutuhannya jelas dan terdefinisi dengan baik. Saya pikir jika Anda memulai proyek Anda dengan mengatur sistem pesan acara, Anda salah melakukannya. Saya percaya bahwa hanya sekali Anda telah membuat dan menguji infrastruktur Anda dan memiliki semua bagian untuk proyek Anda yang terdefinisi dengan baik, modul kerja harus Anda fokuskan pada bagaimana Anda akan menghubungkan modul-modul ini satu sama lain. Mencoba merancang sistem pesan acara sebelum Anda memahami bentuk dan kebutuhan setiap modul tidak sesuai.
Apa kelebihan dan kekurangan dari kedua pendekatan tersebut?
Saya pikir beberapa orang akan berpendapat bahwa ada sistem pesan yang baik di luar sana yang siap diinstal dan digunakan. Mungkin ini benar. Tentu saja kinerja solusi membangun-khusus yang dirancang khusus untuk kebutuhan Anda akan lebih besar daripada bus pesan tujuan umum. Pertanyaan besarnya adalah - berapa banyak waktu yang Anda habiskan untuk membangun sistem pesan daripada menggunakan sesuatu yang sudah dibangun. Jelas, jika Anda dapat menemukan semacam sistem acara dengan set fitur yang Anda butuhkan, maka itu adalah keputusan yang cukup mudah. Inilah sebabnya saya memastikan bahwa saya mengerti apa yang saya butuhkan sebelum saya membuat keputusan itu.
Di mana yang lebih baik dari yang lain?
Kita dapat berbicara tentang memori dan sumber daya di sini. Jika Anda mengembangkan perangkat keras apa pun dengan sumber daya terbatas, tentu saja merupakan masalah untuk menggunakan sistem acara yang akan memotongnya secara signifikan. Tapi sungguh, saya pikir masalahnya adalah apa yang Anda butuhkan, yang seperti yang saya sebutkan sudah merupakan sesuatu yang Anda tidak tahu sampai Anda melihat seperti apa semua potongan itu. Jika Anda memiliki cukup pengalaman dalam membangun sistem ini yang Anda tahu sebelumnya persis seperti apa semua bagiannya, maka Anda dapat menjawab pertanyaan ini sebelumnya. Saya kira Anda tidak memiliki pengalaman ini, karena Anda tidak akan menanyakan pertanyaan ini jika Anda melakukannya.
Apakah desain game yang didorong Event universal dan lebih baik di semua bidang? Apakah karena itu direkomendasikan untuk penggunaan bahkan di platform seluler?
Universal dan lebih baik di semua bidang? Pernyataan selimut yang cantik seperti itu mudah ditolak. Apa pun yang menambahkan overhead harus membawa bagiannya dari beban kerja. Jika Anda tidak cukup menggunakan acara untuk menjamin overhead desain, maka itu desain yang salah.
Mana yang lebih efisien dan mana yang lebih sulit untuk dikembangkan?
Efisiensi tergantung pada bagaimana penerapannya. Saya pikir desain tradisional yang berkembang dengan baik akan mengalahkan sistem berbasis acara setiap hari dalam seminggu. Ini karena komunikasi antar potong dapat dikelola secara mikro dan dibuat sangat efisien. Tentu saja, ini juga membuatnya lebih sulit untuk dirancang dari sudut pandang pengalaman dan waktu yang dibutuhkan untuk menyelesaikannya dan membuatnya lebih efisien. Di sisi lain, jika Anda kurang pengalaman ini atau tidak punya waktu untuk mengembangkan aplikasi dengan baik, maka menggunakan desain berbasis acara yang sesuai dengan kebutuhan Anda akan lebih efisien. Jika Anda memiliki kebutuhan acara khusus yang tidak mudah masuk ke dalam struktur berbasis acara, ini bisa membuat struktur berbasis acara sangat sulit untuk dirancang - terutama untuk menjaga agar desain tetap efisien.
sumber
Saya pikir Anda membandingkan apel dan jeruk di sini. Polimorfisme tidak digantikan oleh olah pesan sama sekali. Anda mungkin ingin acara / pesan untuk menghubungkan komponen yang digabungkan secara longgar. Misalnya. untuk mengirim pesan dari suatu entitas ketika tabrakan terjadi, untuk memperbarui skor pemain atau mungkin untuk memicu efek suara. Sehingga masing-masing kelas tidak mengenal kelas lain dan hanya mengirim dan / atau menangani pesan.
Tetapi game Anda kemungkinan besar akan memiliki loop pembaruan di suatu tempat dan karena Anda memiliki loop pembaruan itu, itu dapat dengan mudah digunakan untuk memperbarui semua entitas game yang perlu diperbarui setiap frame juga. Ini tidak mencegah Anda dari menggunakan olahpesan ...
Jika Anda memiliki semacam struktur tempat Anda menambahkan / menghapus entitas game, Anda dapat memasukkannya ke dalam loop pembaruan Anda alih-alih mengirimkan pesan pembaruan kepada mereka setiap frame. Jadi mengapa tidak memanggil pembaruan pada entitas game Anda secara langsung saat Anda menggunakan pesan untuk menghubungkan berbagai sub-sistem game Anda? Saya juga suka konsep Sinyal / Slot ( lihat contoh qt ) untuk sistem seperti acara.
Intinya: Tidak ada pendekatan yang lebih baik, juga tidak eksklusif.
sumber
Ini dimulai sebagai komentar untuk jawaban bummzack, tetapi panjang.
Kecuali jika Anda benar-benar menjadikannya tidak sinkron (mengirim acara pada utas baru), objek Anda masih mendapatkan memo secara sinkron. Dengan asumsi dispatcher acara Anda menggunakan tabel hash dasar dengan daftar yang ditautkan dalam sel, urutannya akan menjadi urutan di mana objek diiklankan ke sel itu.
Lebih lanjut, kecuali Anda memutuskan untuk menggunakan pointer fungsi karena suatu alasan, Anda masih menggunakan panggilan fungsi virtual karena setiap objek yang menerima pesan harus mengimplementasikan IEventListener (atau apa pun namanya). Acara adalah abstraksi tingkat tinggi yang Anda buat menggunakan polimorfisme.
Gunakan peristiwa di mana Anda harus memanggil daftar metode pencucian untuk berbagai kejadian dalam gim untuk menyinkronkan berbagai sistem dalam gim atau di mana berbagai objek dan reaksi sistem sehingga kejadian tersebut tidak dapat didefinisikan dengan jelas atau Anda inginkan untuk menambahkan lebih banyak reaksi terhadap kejadian tersebut di masa depan.
Mereka adalah alat yang hebat, tetapi seperti kata bummzack, jangan menganggap bahwa polimorfisme dan peristiwa memecahkan masalah yang sama.
sumber
Saya akan mengatakan bahwa memilih satu atau yang lain cukup salah. Beberapa objek perlu memanggil setiap frame - beberapa tidak. Jika Anda memiliki objek yang ingin Anda render, Anda harus membuat panggilan render ke setiap frame. Acara tidak dapat membuat perubahan ini. Hal yang sama berlaku untuk objek fisika berbasis waktu apa pun - Anda harus memanggil mereka setiap bingkai.
Namun, saya tidak membuat panggilan setiap frame ke objek manajemen objek saya, atau objek input pengguna saya, atau yang seperti itu. Panggilan virtual massal ke setiap objek pada bingkai adalah ide yang buruk.
Desain yang digunakan untuk objek tertentu harus didasarkan pada kebutuhan objek tersebut, dan tidak didasarkan pada beberapa ideologi untuk sistem secara keseluruhan.
Diedit agar lebih jelas pada kalimat pertama saya.
sumber