Kalıtım ve Kompozisyon

Paramı C # 'da kazanıyorum Genellikle bu dilde arayüzleri kullanarak her şeyi yüksek göklere ayırmayı seviyorum. Bu bana kurumsal kodda iyi hizmet etti ama C # oyunları yazarken kendimi temel sınıflar için bazı varsayılan davranışları tanımlayabildiğim için mirasa doğru eğilimli buluyorum. Bunu yaparken kirli hissediyorum, sanki bir zamanlar "miras üzerine kompozisyon lehine" diyen bir mimari tanrıya itaat etmiyormuşum gibi. Siyah ve beyaz olmadığını biliyorum ama aynı zamanda biraz daha fazla çalışma ile arayüzler kullanabileceğimi ve kabaca aynı şeyi elde edebileceğimi hissediyorum.

Diğer insanlar ne yapar? Miras oyunlar için doğru yaklaşım mıdır yoksa bazı arayüzlerde yeniden düzenleme yapmalı mıyım?

c# architecture

— Peter Short
kaynak

Arayüzler de kompozisyon değildir, bu yüzden ne sorduğunuz açık değildir.

Sadece C # ile çalıştığınız için, C # gerçek çoklu kalıtım desteklemediğinden miras kullanmayı seçerseniz zor zamanınız olacağını belirtmek isterim. Birden fazla arabirim yöntemini kullanmak, 4-5 arabirim aralığına girene ve aynı uygulamayı paylaşan her sınıf arasında 25'ten fazla kod satırı kesip yapıştırmak zorunda olana kadar iyidir. Bazı turlar var, ancak dil doğrudan destek sağlamadığı için onlar da çirkin.

— NtscCobalt

Yanıtlar:

Oyunlarda kalıtım aslında yapabileceğiniz en kötü şeylerden biridir - özellikle de tüzel kişiler açısından. Oku Bu yüzden için. Miras üzerine kompozisyon, oyunlarla sizi uzun bir yol alır. Motorunuzun diğer alanlarına gelince, gerçekten önemli değil. Diyelim ki bir çeşit harici şebeke servisine çağrı yapıyorsunuz, o zaman örneğin bir tür Genel Servis devralın. HTTPService ve SocketService - alıştığınız kurumsal uygulamalarda olduğu gibi.

Oyun gerçekten basit sürece, olacak bir bileşen tabanlı varlık (CBE) mimarisini kullanmak istiyorum. Genel fikir, varlıklarla, miras yerine çok yaygın olarak oluşturulmalarının nedeni , belirli bir varlığın hangi yeteneklere sahip olacağını çalışma zamanına kadar bilememenizdir.. Örneğin, oyuncunun gemisini bir uzay atıcısına götür. Oyun sırasında bir noktaya kadar, oyuncunun hangi silahları, zırhları, sistemleri (yani bileşenleri) toplayacağını, satın alacağını, satacağını, satılacağını, kaybedeceğini, imha edileceğini vs. bilmiyorsunuz. nesne kompozisyonu aracılığıyla. Bu senaryonun artı tarafı, o düşman türünü her gördüğünüzde daima aynı olan düşmanlardan ziyade, aynı şekilde inşa edilmiş tamamen özelleştirilebilir düşmanlara sahip olabilmenizdir. Yani CBE'lerde, bir Marslı Yük Gemisi görebilir ve "Ah, sadece küçük lazerler var, aşağı çekeceğim" ve genellikle bu doğru olur, ancak menzil içine girdiğinizde aniden büyük bir kıç olduğunu fark edersiniz. solucan deliği tabancası. Sürpriz sürpriz!

Bileşenleşme, mantıkın örtülü eşleşmesini ortadan kaldırıyor ve bu İYİ.

— Mühendis
kaynak

Tavsiye arkadaşı için teşekkürler :) Sesler duymadığımı bilmek güzel!

— Peter Short

+1 Makale için teşekkürler, bunu bir süredir oyunumda yapmak istedim

— John McDonald

Oyun varlıklarının yüksek oranda bağımlı olmasından dolayı, kalıtımın genellikle işleri karmaşıklaştırdığı ve sürdürülebilirliği ve yaygınlaştırmayı hantal bir görev haline getirdiğine dikkat edilmelidir. Bileşen sistemleri bu sorunu güzel bir şekilde ele alır ve diğer ek fayda, yukarıdaki cevapta listelenen şeydir;)

— James

Şunu da belirtmeliyim ki "ama menziliniz bittiğinde aniden büyük götlü bir solucan deliği silahı olduğunu fark edersiniz. Sürpriz sürpriz!" kötü oyun tasarımı: D

— Jonathan Connell

Sürprizler eğlencelidir, ancak sizi OHKO yapabilen düşük seviyeli bir gemi gibi, uyarmadan öldüğünüz anlamına gelen sürprizler sadece sinir bozucudur;) Elbette bu cevabınızda kastettiğiniz şey olmayabilir. Ayrıca, bir oyunda sadece oyun tasarımından çok daha fazlası vardır.

— Jonathan Connell

Almanca konuşan kişiler için ilginç bir kitap: http://www.amazon.com/Architektur-Kerns-einer-Game-Engine-Implementierung/dp/3639324471/ref=sr_1_1?ie=UTF8&qid=1314875533&sr=8-1

Hangi mimarinin ne zaman ve neden burada bulunabileceğine daha yakından bakın: /programming/1901251/component-based-game-engine-design

Kendim için, projemin boyutuna ve kodu genişletme veya yeniden kullanma olasılığına bağlı olarak mimarime karar veriyorum. Kodu tekrar kullanma şansınızın olmadığı bir mikro projenin mimarisine neden saatlerce yatırım yapmalısınız? Aynı zamanda projeyi bitirebilirsiniz.

Bileşim ve Bileşenler Bileşenler havalı süslü şeylerdir, ancak çoğu projede / mimaride bileşim de işleri yapar (bileşen tabanlı ek yük olmadan). Bileşen sisteminizin bu bileşimin sağlayamadığı şeylere bağlıdır.

Örneğin, oyuncunun gemisini bir uzay atıcısına götür. Oyun sırasında bir noktaya kadar, oyuncunun hangi silahları, zırhları, sistemleri (yani bileşenleri) toplayacağını, satın alacağını, satacağını, satılacağını, kaybedeceğini, imha edileceğini vs. bilmiyorsunuz. nesne kompozisyonu aracılığıyla.

uzun zaman önce bile bileşenler olmadan mümkün olan her şey

— idefix
kaynak

-1, bileşenler bir bileşim şeklidir.

farklı özellikler sağladıkları için bir form ama aynı değil. (Bu yüzden yorumunuzu anlamıyorum ve -1)

— idefix

Eğer "bileşenleri vs kompozisyon" dediğimizde bileşenler beri farkların istatistiksel ne olduğu açık değildir vardır kompozisyon. Yani dinamik bileşenler mi yoksa statik bileşenler mi? Ne ailesel ne de yapısal olarak ilişkili türlerin bileşimine karşı? "Bileşen tabanlı ek yük" nedir? Statik bileşen sistemlerinde (ve birçok dinamik sistemde) ek yük neredeyse sıfırdır.

Hm, ilginç noktalar. Biraz daha ayrıntılı tartışmayı düşünür müsünüz? Değilse size posta adresimi başka bir platformda göndermek istiyorum.

— idefix