MVC (Model-View-Controller) Oyun Motoru Mimarisi - Evet mi Hayır mı? [kapalı]


18

Harika bir kitap okuyorum, Oyun Kodlama Tamamlandı ve bu kitap üç anahtar katmanla MVC (Model-View-Controller) yaklaşımını kullanmanızı şiddetle tavsiye ediyor :

  1. Oyun Uygulama Katmanı
  2. Oyun Mantığı
  3. Oyun Görünümü

Bana göre, bu yaklaşım bir mobil bilgisayar oyunu için aşırıya kaçmaya benziyor.

Fikriniz nedir lütfen? Modüller arasında ihtiyaç duyulan ekstra iletişimi eklese bile bu mimariyi uygulamaya değer mi? Bu tasarım o kadar fazla CPU gücü tüketebilir ki, sonuçta sonuç, uygulanmadığından önemli ölçüde daha yavaş olur mu?


5
-1 ve oy vermek için kapatın. Oyunlarda MVC hakkında söylenmeye değer her şey gamedev.stackexchange.com/questions/3426/… ' de söylendi ve şimdiye kadar burada tek yaptığımız çöp.

@Joe Wreschnig oldukça sert, ama sanırım doğru ...
Spooks

@chaos: Aslında, cevabınızı oyladım, ama gerçekten "eğer yardım ederlerse kalıp kullan, eğer yapmazlarsa kullan" diyen başka bir cevaba ihtiyacımız yoktu. Ya da belki de yaptık, ama o zaman bu hala çok üzücü. Yine de çöp dışında "Kalıtım gibi çalışma zamanı tasarımları" gibi ifadelere nasıl atıfta bulunacağımı bilmiyorum.

2
@Joe: Oh, teşekkürler. :) OOP'un maliyetsiz olduğu iddiası, zihni biraz şaşırtıyor. Bazı standartlara göre , tekrarlanan benimki gibi noktalara ihtiyacımız olmamalı , ancak noobs'lar oluyor ve bu yüzden de tartışmalı soruları tekrarlıyoruz. Ayrıca, benim gibi siteye geç gelenlerin, büyük ölçüde ölmüş olmasına rağmen, küçük bir temsilciyi kazımasına izin verme işlevini de yerine getirir. :) Yani, lanet olsun, ben SO 40K temsilcisi var, ama burada bir etiket wiki bile düzenleyemiyorum.
kaos

Yanıtlar:


30

Basit bir mobil oyun için bile bir MVC yapısı kullanmayı biraz destekliyorum. Başka bir şey değilse, yeterince ısırılmamış geliştiricilerin rahatsız ettiği bir sorunla yardımcı olur: ekran kodunu oyun mantığından ayırmak.

Bununla birlikte, MVC'nin, tüm tasarım desenleri gibi , hayatınızı kolaylaştırmak için var olduğunu da aklımızda tutacağım . Bu, herhangi bir zamanda, MVC'yi kullanırken ne yapmanız ve yapmamanız gerektiğine dair bazı kurallar dahilinde kalmak, hayatınızı zorlaştırıyorsa, görmezden geldiğiniz anlamına gelir . İki şeyden biri olacak: 1) daha sonra ısırılırsınız ve daha sonra ilk etapta farklı bir şekilde yapmanın neden uzun vadede hayatınızı daha kolay hale getireceğini anlarsınız veya 2) hiçbir sonuç olmaz.

Bilgisayar programlama, doğası gereği, gerçekten bir şeyi başarmaktan ötürü zarif ilkeye bağlılığa değer veren çok sayıda kural takipçisi alır ve değer sistemlerini sunmayı severler; sizi onlardan biri yapmasına izin verme. Oyununuzda olabilecek en önemli şey nakliye .


Sevgili Kaos, cevabınızı en çok seviyorum, bu yüzden sorumun cevabı olarak işaretliyorum. MVC yaklaşımı kod tasarımına soyutlama ekler. Soyutlama, daha düz bir tasarımla önlenebilecek ekstra kod adımlarını ususally ekler. Doğru anladığım gibi, MVC tasarımının bir sonucu olarak eklenen soyutlamanın getirdiği maliyetten endişelenmem gerekmiyor.
Bunkai.Satori

1
İyi cevap, + 1'leyin .. Teori her şey yolunda ve iyi ama eğer bunu yapmazsanız oyunların gönderilmesine neden olabilir.
James

@ Bunkai.Satori: Soyutlama ekler ve IMO, yolunu ödeyen yararlı soyutlamadır. Son açıklamanıza katılıyorum , bir maliyet olduğunu ve bunun için endişelenmeniz gerektiğini düşünmüyorum.
kaos

4

Derleme zamanı tasarımları, inanılmaz derecede berbat bir derleyiciniz olmadığı sürece CPU gücünü tüketmez. Nesneye yönelik bir dil veya yaklaşım, performans özelliklerinde yordamsal olandan farklı değildir. MVC kullanmak için ek yük getirmeyeceksiniz. Modülerlik, kod satır içine alındıktan ve optimize edildiğinde, çalışma zamanında değil, derleme zamanında mevcuttur, hiçbir fark yaratmaz.

Birçok modern oyun aslında modelleri ve ayrı iş parçacıkları hakkındaki görüşleri çalıştırır ve çoğu platformda büyük performans avantajları elde eder.

Nihayetinde, MVC ücretsiz olarak daha fazla bakım ve daha az hata vb . Kullanmamak için hiçbir sebep yok . Bu for, elle yazılmışlar yerine neden bir döngü kullanmanız gerektiğini sormak gibidir goto. Aklınızda üstün bir tasarım yoksa, kesinlikle hiçbir şeyden daha iyi değildir.

Düzenleme: Derleme zamanı tasarımları CPU gücü tüketmez. Kalıtım gibi çalışma zamanı tasarımları açıktır.


-1. MVC tasarım zamanı kararıdır. Kalıtım bir tasarım zamanı kararıdır. Her ikisi de derleme zamanı ve çalışma zamanından önce gerçekleşir. Her ikisinin de performans üzerinde büyük etkileri vardır. Inlining her zaman kodu daha hızlı yapmaz. İş parçacığı teklifiniz inanılmaz derecede naif. Hiçbir şey bedava değil.

Cevabınız için DeadMG'ye teşekkür ederiz. Temel olarak, her soyutlama seviyesiyle, kodun daha fazla ara adım eklendiği için kodun eğildiğini kastediyorum. MVC daha soyut bir tasarımdır, bu muhtemelen aynı görevi yerine getirmek için daha fazla adımla sonuçlanır. Bunun hız üzerinde etkisi olur, imo.
Bunkai.Satori

4

Kodun netliği ile programın teknik gereksinimleri (hız, bellek, vb.) Arasında neredeyse her zaman bir ödünleşim vardır. Nesne yönelimli dillerin işlemsel dillere kıyasla genel bir yükü vardır, ancak özellikle uzun süreli kod bakımında (hatalar, vb.) Ve çoğu zaman geliştirme hızında da işlem dillerine göre birçok avantajları olduğu gösterilmiştir.

Bunu akılda tutarak, MVC'nin oyun programcısı olarak uğruna uygulamaya değer olduğunu öneriyorum . Kodunuz, özellikle kapsülleme olmak üzere nesne yönelimli ilkeleri daha iyi izleyecektir ve muhtemelen onu korumak için çok daha kolay bir zamanınız olacaktır (hataları düzeltmek veya yeni özellikler eklemek).

Öte yandan, bir oyunu gerçekten bitirdiğinizden ve "motor" üzerinde çalışmak için çok fazla zaman harcamadığınızdan emin olun.

Daha fazla bilgi için lütfen "MVC ve TDD neden oyun mimarisinde daha fazla kullanılmıyor?" ve gerçekten uzun cevabım.


1
OO dilleri hiç de yordamsal dillerden daha yavaş değildir. C ++ 'da bit kaydırma yapan bir kod yazarsanız, C'den daha yavaş olmaz. Bir dil veya program, yalnızca nesne yönelimli olduğu için yordamla karşılaştırıldığında daha yavaş değildir. Programlar yalnızca kötü yazılmış oldukları için performans zararları sergilerler . Sonuç olarak, cevabınızı küçümseme ihtiyacını hissediyorum.
DeadMG

Merhaba Ricket, yoru açıklaması için teşekkürler. Kulağa çok mantıklı geliyor. DeadMG, bir tarafta haklısınız, Öte yandan OO yaklaşımının derlenmiş kodda yordamsal dilden daha fazla bilgi parçası eklediğini düşünüyorum. OO ile ilgili kodun bu fazladan biti, sonuçta ortaya çıkan kodu yavaşlatır. Katılıyor musun?
Bunkai.Satori

3
Peki şimdi ... C ++ gibi basit bir çizgi, C ile a++aynı olacaktır a++( ailkel tip, vb.). Ancak, bir şey yapan sanal bir işleve sahip basit bir C ++ sınıfını düşünün, bu sanal işlev, iç kod aynı olsa bile, basit bir C işlevine karşı ağır bir ek yüke neden olur. Nesneye yönelik diller bir ek yüke sahiptir . Açıkça "hız" dediğim için üzgünüm. Fazladan bellek ayırma ve benzeri işlemler daha yavaş bir programla sonuçlanmazsa, kesinlikle haklısınız demektir.
Ricket

2
İşlev sanal ise, programın çalışma zamanında aynı işlevin 2 farklı sürümü arasında seçim yapması gerektiği anlamına gelir. (Aksi takdirde, sanal hale getiremezsiniz.) Bu durumda, yine de kendinizi yordamsal bir dilde (örn. Bir işlev işaretçisi veya anahtar deyimi aracılığıyla) uygulamak zorunda kalacağınız ekstra bir koşullu veya dolaylı düzeyiniz vardır. . Bu havai değil - bu sorunun özüdür.
Kylotan
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.