Arsitektur Mesin Game MVC (Model-View-Controller) - Ya atau Tidak? [Tutup]

18

Saya membaca satu buku bagus, Game Coding Complete , dan buku itu sangat merekomendasikan menggunakan pendekatan MVC (Model-View-Controller) , dengan tiga lapisan utama:

  1. Lapisan Aplikasi Game
  2. Logika Game
  3. Tampilan Game

Bagi saya, pendekatan ini terlihat seperti kerja keras untuk permainan komputer seluler.

Apa pendapat Anda? Apakah layak menerapkan arsitektur ini, bahkan jika itu menambahkan komunikasi tambahan yang diperlukan antara modul? Bisakah desain ini menghabiskan begitu banyak daya CPU, sehingga pada akhirnya, hasilnya akan jauh lebih lambat, daripada jika tidak diimplementasikan?

architecture Bunkai.Satori
sumber
5
-1 dan pilih untuk menutup. Segala sesuatu yang layak dikatakan tentang MVC dalam game dikatakan di gamedev.stackexchange.com/questions/3426/… , dan sejauh ini yang kami punya di sini hanyalah sampah.
@ Jo Wreschnig itu cukup keras, tapi kurasa benar ...
Spooks
@chaos: Sebenarnya, saya memilih jawaban Anda, tetapi kami benar-benar tidak membutuhkan jawaban lain yang mengatakan "gunakan pola jika mereka membantu, jangan jika tidak." Atau mungkin kita lakukan, tapi itu masih sangat menyedihkan. Saya masih tidak tahu bagaimana merujuk ke ekspresi seperti "Desain run-time like inheritance" selain sampah.
2
@ Jo: Oh, terima kasih. :) Argumen bahwa OOP bebas biaya agak membingungkan pikiran. Saya kira dengan beberapa standar kita tidak perlu poin seperti milik saya ditegaskan kembali, tetapi noobs bisa terjadi dan begitu juga pertanyaan duplikat yang bisa diperdebatkan. Ini juga melayani fungsi membiarkan orang yang datang terlambat ke situs seperti saya mengumpulkan sedikit rep meskipun aktivitas telah secara besar-besaran mereda. :) Maksudku, sial, aku punya rep 40K pada SO, tapi di sini aku bahkan tidak bisa mengedit tag wiki.
kekacauan

Jawaban:

30

Saya agak mendukung menggunakan struktur MVC bahkan untuk gim seluler sederhana. Jika tidak ada yang lain, ini membantu dengan masalah yang mengganggu pengembang yang belum cukup digigit olehnya: memisahkan kode tampilan dari logika game.

Saya juga akan mengatakan, perlu diingat bahwa MVC, seperti semua pola desain, ada untuk membuat hidup Anda lebih mudah . Itu berarti bahwa jika, pada waktu tertentu, tetap berada dalam seperangkat aturan tentang apa yang harus dan tidak harus Anda lakukan ketika menggunakan MVC membuat hidup Anda lebih sulit, abaikan saja . Satu dari dua hal akan terjadi: 1) Anda akan digigit kemudian, dan kemudian akan mengerti mengapa melakukannya secara berbeda sebenarnya akan membuat hidup Anda lebih mudah dalam jangka panjang, atau 2) tidak ada konsekuensi apa pun.

Pemrograman komputer, berdasarkan sifatnya, mendapat banyak pengikut aturan yang menghargai kepatuhan terhadap prinsip elegan daripada benar-benar mencapai apa pun, dan mereka suka mengemukakan sistem nilai mereka; jangan biarkan mereka menjadikan Anda salah satu dari mereka. Hal terpenting yang dapat terjadi pada gim Anda adalah mengirimkannya .

kekacauan
sumber
Dear Chaos, saya paling suka jawaban Anda, karena itu saya menandainya sebagai jawaban untuk pertanyaan saya. Pendekatan MVC menambah abstraksi ke dalam desain kode. Abstraksi biasanya menambahkan langkah-langkah kode tambahan, yang bisa dihindari dengan desain yang lebih maju. Seperti yang saya pahami dengan benar, saya tidak perlu khawatir dengan biaya yang dikeluarkan oleh abstraksi yang ditambahkan sebagai hasil dari desain MVC.
Bunkai.Satori
1
Jawaban yang bagus, memberi +1 pada hal itu .. Teori baik-baik saja dan baik tetapi dapat menyebabkan game tidak dikirimkan jika Anda tidak menyelesaikannya.
James
@ Bunkai.Satori: Itu memang menambah abstraksi, dan IMO itu abstraksi berguna yang membayar jalannya. Saya setuju dengan pernyataan terakhir Anda, dengan klarifikasi bahwa ada adalah biaya, dan bahwa saya tidak berpikir Anda perlu khawatir tentang hal itu.
kekacauan
4

Desain waktu kompilasi tidak mengkonsumsi daya CPU, kecuali jika Anda memiliki kompiler yang sangat buruk. Bahasa berorientasi objek atau pendekatan tidak berbeda dalam karakteristik kinerja daripada yang prosedural. Anda tidak akan meminta overhead tambahan untuk menggunakan MVC. Modularitas ada pada waktu kompilasi, bukan run-time, setelah kode diuraikan dan dioptimalkan, itu tidak akan membuat perbedaan sama sekali.

Banyak game modern benar-benar menjalankan model dan pandangan pada utas terpisah dan mendapatkan manfaat kinerja yang luar biasa pada kebanyakan platform.

Pada akhirnya, MVC adalah desain yang bagus yang membuat Anda meningkatkan pemeliharaan dan mengurangi bug dll secara gratis . Tidak ada alasan untuk tidak menggunakannya. Ini seperti bertanya mengapa Anda harus menggunakan forloop daripada tulisan tangan goto. Kecuali Anda memiliki desain yang unggul dalam pikiran, itu pasti lebih baik daripada tidak sama sekali.

Sunting: Desain waktu kompilasi tidak mengkonsumsi daya CPU. Desain run-time seperti pewarisan jelas dilakukan.

DeadMG
sumber
-1. MVC adalah keputusan desain-waktu. Warisan adalah keputusan desain-waktu. Keduanya terjadi sebelum waktu kompilasi dan waktu berjalan. Keduanya memiliki dampak besar pada kinerja. Inlining tidak selalu membuat kode lebih cepat. Proposal threading Anda sangat naif. Tidak ada yang gratis.
DeadMG terima kasih atas jawaban Anda. Pada dasarnya, saya maksudkan bahwa dengan setiap tingkat abstraksi, kode akan hilang, karena semakin banyak langkah perantara ditambahkan. MVC adalah desain yang lebih abstrak, yang kemungkinan besar akan menghasilkan lebih banyak langkah untuk mencapai tugas yang sama. Ini akan berpengaruh pada kecepatan, imo.
Bunkai.Satori
4

Hampir selalu ada tradeoff antara kejelasan kode dan persyaratan teknis (kecepatan, memori, dll.) Dari program. Bahasa berorientasi objek memiliki overhead dibandingkan dengan bahasa prosedural, tetapi mereka telah terbukti memiliki banyak keunggulan dibandingkan bahasa prosedural, terutama dalam pemeliharaan jangka panjang kode (bug, dll.) Dan sering kali kecepatan pengembangan juga.

Maka dengan itu dalam pikiran, saya mengusulkan bahwa MVC layak diterapkan untuk kepentingan Anda sebagai programmer game . Kode Anda akan lebih baik mengikuti prinsip-prinsip berorientasi objek, terutama enkapsulasi , dan Anda mungkin akan memiliki waktu yang lebih mudah untuk mempertahankannya (memperbaiki bug atau menambahkan fitur baru).

Di sisi lain, pastikan untuk benar-benar menyelesaikan permainan dan tidak menghabiskan banyak waktu bekerja pada "mesin" yang tidak pernah selesai.

Untuk info lebih lanjut, silakan baca pertanyaan "Mengapa MVC & TDD tidak dipekerjakan lebih banyak dalam arsitektur game?" dan jawaban saya yang sangat panjang.

Ricket
sumber
1
Bahasa OO tidak lebih lambat dari bahasa prosedural sama sekali. Jika Anda menulis beberapa kode dalam C ++ yang melakukan bit-shifting, itu tidak akan lebih lambat dari pada C. Bahasa atau program tidak lebih lambat dibandingkan dengan prosedural sama sekali hanya karena berorientasi objek. Program hanya menunjukkan kerugian kinerja karena ditulis dengan buruk . Sebagai hasilnya, saya merasa perlu untuk mengecilkan jawaban Anda.
DeadMG
Hai Ricket, terima kasih atas penjelasan yoru. Kedengarannya sangat logis. DeadMG, well, di satu sisi Anda benar, Di sisi lain, saya pikir pendekatan OO menambahkan lebih banyak bit informasi dalam kode yang dikompilasi daripada bahasa prosedural. Bit tambahan kode terkait OO ini membuat kode yang dihasilkan lebih lambat. Apa kamu setuju?
Bunkai.Satori
3
Whoa sekarang ... Tentu garis sederhana di C ++ suka a++akan sama persis seperti a++di C (di mana aadalah tipe primitif, dll.). Tetapi pertimbangkan kelas C ++ sederhana dengan fungsi virtual yang melakukan sesuatu, fungsi virtual itu menimbulkan overhead yang lumayan vs fungsi C sederhana, bahkan jika kode bagian dalamnya identik. Bahasa berorientasi objek memiliki overhead . Maaf karena secara eksplisit mengatakan "kecepatan". Jika alokasi memori tambahan dan semacamnya tidak menghasilkan program yang lebih lambat maka Anda benar sekali.
Ricket
2
Jika fungsinya virtual, itu menyiratkan bahwa program perlu memilih antara 2 versi berbeda dari fungsi yang sama pada saat run time. (Jika tidak, Anda tidak akan membuatnya virtual.) Dalam hal ini, Anda memiliki syarat atau tingkat tipuan tambahan, yang harus Anda implementasikan sendiri dalam bahasa prosedural (mis. Melalui penunjuk fungsi atau pernyataan pergantian) . Itu bukan overhead - itu intrinsik untuk masalah.
Kylotan