Domain Driven Design oyunlar için iyi mi?

Sadece Domain modellerini okudum ve sadece veri tutan bir sınıfa (birkaç davranış / yöntem) sahip bir oyun geliştirdiğimden beri beni aydınlatıyor. Bu sınıfları yönetme işini yöneticilere verdim ... ve şimdi yöneticim bir Tanrı nesnesi gibi görünüyor. Mantığı işlemesi gereken oyun nesnem sadece anemik bir etki alanı modelidir.

Şu anki tasarım modelim Singleton'da ve bu şeyleri çıkarmak için bazı kayıt yapmak istiyorum. Oyunlarda hiç DDD görmedim (şu andan itibaren) ama bu iyi bir yaklaşım mı? Ben sadece acemi bir programcıyım (oyuna eğilimli), bu yüzden oyun yeniden tasarlanmak için çok şişirilmeden önce iyi mimari hakkında daha fazla bilgi edinmek istiyorum.

Gönderinizden önce alan adı odaklı tasarımı hiç duymamıştım. Burada ve burada birkaç referansa hızlı bir bakış, üniversitede okuduğum geleneksel görünen 90'lı nesne yönelimli programlama yöntemi için süslü bir isim olduğunu gösteriyor, burada görünen her isim için sınıf yazmaya çalışıyorsunuz yazılımla modellemeye çalıştığınız durumda, yazılımın yapısı gerçek dünya kavramının yapısını takip ediyor gibi görünüyor.

Bu nedenle, cevabım bunun "iyi" olmadığıdır. Genellikle makul bir başlangıç ​​noktasıdır, ancak ilerledikçe yetersiz kalmaktadır. Nadiren tek bir etki alanınız vardır ancak bir yazılım parçası içinde birkaç farklı etki alanınız vardır - örneğin, oyunun etki alanına (dünya, karakterler, öğeler), oluşturucunun etki alanına (gölgelendiriciler, ağlar, malzemeler), girdi alanını (dosya sistemi, ağ, klavye ve fare) ve alan adlarının çakıştığı ve birbirini etkilediği yerlerde sorunlar ortaya çıkar. Genellikle 2 alana bir araya gelme sırasında, aslında bir değişiklik gerektiren bir bağımlılık olduğunu fark edersiniz, yani temsillerinizden biri bir yardımdan daha fazla bir yük haline gelir.

Belirsiz bir örnek, bir konsoldaki bir matematik kütüphanesi ve oyun içi karakterleriniz olabilir. Matematik kitaplığınızda, verimli bir şekilde çalışmak için büyük bir veri listesi ve ardından bu listede gerçekleştirilecek 1 talimat bulunacaktır. Oyun içi karakterlerinizin her biri, oluşturma ve animasyon vb. İçin kendi köşe verisi kümesine sahip olacaktır. Şimdi, tek seferde işlemek için karakterlerinizin her birinden tüm köşe verilerinin uzun bir listesini nasıl alırsınız? Yavaş bir kopyalama işlemi gerçekleştirebilir veya bunun yerine karakterlerinizi yeniden düzenleyebilirsiniz, böylece verileri matematik kütüphanesi tarafından işlenmeye daha uygundur - ancak alanlarınızdan biri diğerini tercih etmek için ayrılır.

Şahsen ben "Ne olursa olsun-Tasarım" benzeyen herhangi bir etiket çok temkinli. Yazılım, onu oluşturmak için her şeye uyan bir yaklaşım olması için hem çok geniş kapsamlı hem de çok karmaşıktır. Bunun yerine, yapabileceğim en iyi yazılımı yazmaya çalışırken, SOLID ilkelerine geri dönmeye çalışıyorum . Bunlar, takip edebileceğiniz ve sihirli bir şekilde iyi koda erişebileceğiniz bir yöntemin vaadini vermeden, kodunuzun ne kadar iyi olduğu hakkında iyi bir fikir verir. Ne yazık ki, böyle bir ek metodoloji olmadan, bu yönergelere nasıl uyulacağını öğrenmeden önce çok fazla deneyim gerekir, bu yüzden muhtemelen birçok kişi bu metodolojileri sever.

Anemik sınıflara ve yönetici nesnelerine sahip olma sorununuzla ilgili olarak, bu genellikle giriş nesnesi yönlendirme derslerinde kapsanan bir şeydir ve bunu 'düzeltmek' için herhangi bir özel metodolojiye bağlı kalmanızı gerektirmez. (Yeni başlıyorsanız, nesne yönelimli programlama hakkında bir kitap almak isteyebilirsiniz.) Sınıf, davranışın bu durumu değiştirdiği durum ve davranışın birleşimidir ve buna kapsülleme denir. Genel olarak mümkün olduğunca kapsamaya çalışırsınız ve bu, durumun nesnenin kendisi (ve yalnızca o nesne) tarafından manipüle edilmesi gerektiği anlamına gelir. Yalnızca sınıf içinde modellenemeyen davranışlar için, yönetici gibi bir dış sınıfa temsil edersiniz, bu nedenle yönetici sınıflarının varlığı genellikle kötü yazılmış nesne yönelimli kodun bir işareti olarak kabul edilir.

Şu anki tasarım modelim Singleton'da ve bu şeyleri çıkarmak için bazı kayıt yapmak istiyorum.

O çizgiyle ne demek istediğini bilmiyorum. Tasarım deseni, programınızın küçük bir bölümünü yazmanın bilinen bir yoludur. 'Mevcut' bir tasarım deseniniz olmaz ve programınızın geri kalanını da şekillendirmez. Yeni başlayanlar için, bu desenler sizi doğru yola sokmak için yararlıdır, oysa uzmanlar için ortak kod durumları hakkında iletişim kurmanın bir yoludur. Ancak bir şey önemlidir: singletonlar neredeyse her zaman kötü bir fikirdir ve mümkün olduğunca onlardan kaçınmalısınız. Bu sitede ve Stack Overflow üzerinde singletonlar hakkında birçok fikir bulabilirsiniz, ancak bunlara ihtiyacınızdan kaçınmanıza yardımcı olacak cevapları olan pratik bir soru .

paradigma

Bu cevabın yazıldığı tarihte, burada yayınlanan diğer cevapların hepsi yanlış.

Etki Alanına Dayalı Tasarım'ın oyunlar için iyi olup olmadığını sormak yerine. "Alan Adı Modelleme" nin oyunlar için iyi olup olmadığını sormalısınız.

Alan adı modellemesi oyunlar için iyi mi?

Cevap: bazen kesinlikle harika. Ancak, bir platform oyunu ya da FPS gibi gerçek zamanlı bir oyun ya da her türlü oyun (MANY MANY çeşit oyun) oluşturuyorsanız, o zaman hayır. Bu sistemler için uygun olmayabilir. Bununla birlikte, etki alanı model modelini uygulamanın etkili olduğu oyunlarda sistemler olabilir.

Diğerlerinin burada belirttiği gibi, bileşen-varlık çerçeveleri çok popüler ve iyi bir nedenden dolayıdır. Bununla birlikte, oyun geliştirme kültüründe katmanlı mimarilerin belirgin bir eksikliği var gibi görünüyor. Yine, bu, insanların geliştireceği çoğu oyunun varlıklar üzerinde sadece mutasyon durumunu geliştireceği ve ortaya çıkan sonuçların oyun olmasına izin vereceği için iyi bir nedendir.

TÜM YAZILIM YAZMADIĞINIZ YAZILIM DEĞİLDİR. Bazıları diğerlerinden oldukça farklıdır.

Etki alanı modellemesinin iyi çalıştığı alanlara örnek olarak kart oyunları, masa oyunları ve olaya dayalı diğer sistem türleri verilebilir.

Çekirdek etki alanı kavramları olarak zaman deltaları tarafından belirlenen hareket vs ile X kare hızında çalışan oyunlar büyük olasılıkla çok uygun değildir. Bu durumda, "alanımız" genellikle o kadar basittir ki alan modellemeye gerek yoktur. Çarpışma tespiti, yeni varlıkların ortaya çıkması, kuvvetlerin mevcut varlıklar üzerindeki etkisi vb. Çoğu oyunu kapsamaktadır.

Ancak, işler karmaşıklaştıkça, belirli davranış ve hesaplama türlerini ele almak için geliştiricilerin varlıkları içinde etki alanı modelleri uyguladıklarını görmeye başlarsınız.

Oyun mimarilerinde alan modeli modeli

Oyun motorunuz (örneğin, Unity3D) genellikle bileşen-varlık yönelimlidir. Platformda karakteriniz için bir varlığınız olabilir ve durumu, konumu güncellemek için sürekli olarak değiştirilir.

Bununla birlikte, daha olay odaklı bir oyunda, bileşen-varlık çerçevesinin rolünün sadece Kullanıcı Arayüzü olarak bulunması daha olasıdır. Sonunda katmanlı bir mimari elde edersiniz.

Kullanıcı arabirimi, oyun durumunu kullanıcıya sunar. Kullanıcı, kullanıcı arayüzüyle etkileşime girerek hizmet katmanındaki komutları tetikler. Hizmet katmanı etki alanı nesneleriyle etkileşime giriyor. Etki alanı nesneleri, etki alanı olaylarını artırdı. Olay dinleyicileri olayları duyar ve kullanıcı arayüzündeki değişiklikleri tetikler.

Kullanıcı Arayüzü> Hizmet Katmanı> Etki Alanı Modeli

Kısacası, bir hizmet katmanı uygulamasına sahip model-görünüm-denetleyicisine son verin.

Bu mimariyi kullanarak, olaya dayalı bir arayüzle tamamen birim test edilebilir bir oyun çekirdeğine (Oyun geliştirme kültüründe nadirlik gösterir ve gösterir) sahip olursunuz.

Tamam, DDD nedir?

Etki Alanına Dayalı Tasarım özellikle, etki alanı hakkında bilgi edinmek için kullanılan analitik örüntüler üzerinde vurgu yapan bir kültür / harekettir, böylece aslında doğru olanı inşa edersiniz ve daha sonra, etki alanı modelindeki kavramları dilinizin deyimini kullanarak. DDD, karmaşık alan adlarıyla çalışan ve her zaman alan adı modellemesine odaklanarak uygulamalarında yüksek karmaşıklığı yönetmenin yollarını arayan bir topluluktan gelir.

DDD, hedefiniz sadece kodlamaya başlamak, sistemle oynamak ve daha sonra ne inşa etmek istediğinizi bulmak vb. İçin iyi bir şey yapmaz. Var olan bir alanın az çok olduğunu varsayar. Yani, oyununuzun ne olacağı hakkında hiçbir fikriniz yoksa .. O zaman, işe yaramayacak.

Hayır, DDD veya başka bir "moda sözcük" mimarisinin oyunlar için gerçekten iyi olduğunu düşünmüyorum. Burada gerçekten popüler görünen "bileşen sistemi" olası istisna dışında.

Böyle sorular ve tartışmalar duyduğumda bu siteyi hatırlattım . Çeşitli mimari terimleri düşünmek, genellikle kendi uygulamanızı tasarlamaktan ve kodlamaktan daha az iyi sonuç verir.

Evet, ama adapte olmalısınız.

DDD kullanırken her alanın modülerliğini ve tek sorumluluğunu alacaksınız. Ama başka her şey işleri karmaşık hale getirir.

Cevabımı burada gör