Toplama Olarak Varlık Yaratma

Geçenlerde varlıkları davranışlarından nasıl ayıracağımı ve bu makaleye bağlı ana cevabı sordum : http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/

Burada yazılan nihai kavram şudur: SAF BİR TOPLUM OLARAK NESNE.

C # kullanarak saf birleştirme olarak oyun varlıkları oluşturmak için nasıl gidebilirim merak ediyorum. Bunun nasıl çalışabileceği kavramını tam olarak anlamadım. (Belki de varlık, belirli bir arabirimi veya temel türü uygulayan bir nesne dizisidir?)

Şu anki düşüncem hala her bir varlık türü için ilgili arayüzleri (Taşınmaz, ICollectable, ISpeakable vb.) Uygulayan somut bir sınıfın olmasını içeriyor.

Bir işletme için söz konusu işletme için herhangi bir somut tür içermeden, yalnızca bir toplulaştırma olarak nasıl varlık oluşturabilirim?

Bu bağlantılı makalede Batı tarafından tarif edilen "saf toplama" yaklaşımı bir "varlık" nesnesinden tamamen kaçınır. Bellekte dolaşan bileşenler vardır, ancak bunlar yalnızca örtük ilişkilerle birbirine bağlanır.

Bunu yapmanın bir yolu dıştan takmalı bir yaklaşımdır . Böyle bir sistemde, bileşenler onları yöneten veya başka şekilde kontrol eden sistemler tarafından tutulur (burada "yönet" terimini kullanıyorum, ancak bunu tutmak için bir grup * Yönetici sınıfına sahip olmanızı önerdiğim anlamına gelmemelisiniz. bileşen türleri). Örneğin, fizik sisteminiz, simülasyon dünyasındaki her bir katı cismi temsil eden bir grup şeyi tutabilir ve bunları Fizik Bileşenleri olarak ortaya çıkarabilir. Bileşenler, söz konusu alt sistem tarafından işlenen gerçek nesneler olabilir veya gerektiğinde bu nesneler için proxy olabilirler.

Böyle bir sistemde, bir "Varlık" sınıfının onu oluşturan bileşenlere bir referans koleksiyonu tutması gerekmemektedir; bunun yerine bir "varlığın" oluşturulması veya imhası ile ilgili bir bildirim yapılır ve bileşenleri işleyen her alt sistem, yaratılan / yok edilen varlığın açıklamasına bakar (genellikle bazı verilerden yüklenir) ve bunun için bir bileşenin gerekli olup olmadığını belirler.

Bu yaklaşımın avantajlarından biri, her bileşen için gerçekten iyi bir referans konumu elde etmenizdir. Ne yazık ki, biraz garip, genel ve karşılaştığım bileşen tabanlı varlıkların en samimi tadı değil. Bazen, bir nesneyi temsil eden gerçek bir nesneye sahip olmak gerçekten uygundur, ancak bu nesne hala diğer alt sistemler tarafından tutulan bileşenlere zayıf referanslar toplasa bile (başka bir şey yoksa, bileşenler arasındaki mesajları yönlendirmek için kolay bir yol sağlar) .

Bileşene yönelik oyun nesne sistemlerini uygulamanın birkaç iyi yolu vardır; gerçekten, gerçekten, gerçekten sisteminizden çıkmak istediğiniz gereksinimler hakkında sağlam bir fikriniz varsa yardımcı olur - Unity gibi popüler çerçevelerin örnekler için ne yaptığını görebilirsiniz. Kendiniz için katı gereksinimler belirlemeksizin, sistemi gerçekten inşa etmeden sonsuz bir şekilde "tasarlama" sorunuyla karşılaşabilirsiniz, mükemmel uygulamaya vurmaya boşuna çalışın. Her ne sebeple olursa olsun, bunu bileşen sistemlerinde çok gördüm.

Unity'nin bunu yapması, tüm komut dosyalarının (sizin durumunuzda, bir oyun nesnesine özgü oyun kodu) temel sınıftan MonoBehaviourtüretilmesidir, ki bu da kendisi sizin durumunuzla daha alakalı olan sınıftan türetilir Component. GameObject sınıfını asla düzenlemezsiniz (ve koduna erişemezsiniz).

Oyun nesnesi tüm bunları içermekten sorumludur Component. Görünüşe göre üzerlerinde ilgili işlevleri çağırmaktan da sorumludur (yani Update). Unity, hangi işlevleri çağıracağını belirlemek için yansıma kullanır ( bu sayfadaki "Geçersiz Kılan İşlevler" bölümüne bakın ), ancak muhtemelen bunları sanal hale getirmek istersiniz.

Yani Unity'de kullandığınız mekanizmalardan biri, mevcut oyun nesnenizde (veya alt öğelerinde) türlerine göre bileşenler elde etmektir. Bazı ortak şeyleri saran bazı yardımcı özellikler vardır. Örneğin, oyun nesnesinin Transformbileşenine (oyun nesnesinin konumunu / dönüşünü / ölçeğini kontrol etmek için) erişmek istiyorsanız, normalde böyle bir şey yapmanız gerekir this.GetComponent<Transform>().position, ancak bunu yardımcı bir this.transform.positionçağrıya sararlar . Başka bir yaygın desen, geçerli oyun nesnesinin Rendererbileşenine erişmektir . Dolayısıyla, mevcut oyun nesnesinin malzemesini değiştirmek gibi bir şey yapmak istiyorsanız, başka bir komut dosyasından benzer bir şey yapabilirsiniz this.renderer.material = someOtherMaterialve oyun nesneniz uygun şekilde güncellenir.

Bunun Unity'de çalışmasının yollarından biri, düzenleyicilerinin, sahnenizde zaten bağlanmış bileşenleri olan oyun nesnelerini oluşturabileceğiniz şekilde ayarlanmasıdır. Unity'nin durumunda, tüm oyun nesnelerinin bir Transformbileşeni vardır, ancak beklediğiniz şeyi yapan AudioListenerveya gibi yerleşik türleri de içerebilir Renderer. Ya da yapmasını istediğiniz her şeyi yapan kendi bileşenlerinizi ekleyebilirsiniz. Editör ayrıca bileşenlerinizdeki genel / serileştirilebilir alanları da açığa çıkarır, böylece aynı temel kodu kullanmak, ancak birkaç sihirli sayıyı değiştirmek isterseniz farklı komut dosyaları oluşturmanız gerekmez.

Sonuçta oldukça kaygan ve Unity'nin ücretsiz sürümünü indirmenizi ve komut dosyası sisteminin nasıl elde etmek istediğinizin kavramının oldukça iyi bir kanıtı olarak nasıl kurulduğunu oynamayı öneririm.

Adam'ın t-machine blogundaki vizyonuna daha yakın bir yaklaşımı seviyorum. Bileşenler sadece veri olmalı ve sistemler tüm işi onlarla yapıyor.

C # 'daki ES uygulaması örneğine bakın: https://github.com/thelinuxlich/artemis_CSharp

Ve bunu kullanan bir örnek oyun (XNA 4): https://github.com/thelinuxlich/starwarrior_CSharp