Oyun Nesnesi Bileşenleri Oyun Alt Sistemlerine Kaydedilsin mi? (Bileşen Tabanlı Oyun Nesnesi tasarımı)

Ben yaratıyorum bileşen tabanlı oyun nesne sistemini . Bazı ipuçları:

GameObjectsadece bir listesidir Components.
Var GameSubsystems. Örneğin, oluşturma, fizik vb. Her biri GameSubsystembazılarına işaretçiler içerir Components. GameSubsystemçok güçlü ve esnek bir soyutlamadır: oyun dünyasının herhangi bir dilimini (veya yönünü) temsil eder.

Kayıt Componentsolma mekanizmasına ihtiyaç vardır GameSubsystems(ne zaman GameObjectyaratılır ve oluşturulursa). Orada 4 yaklaşımlar :

1: Sorumluluk zinciri modeli. Her Componentşey herkese sunulur GameSubsystem. GameSubsystemhangi Componentskaydın kaydedileceğine (ve nasıl düzenleneceğine) karar verir. Örneğin GameSubsystemRender, Yenilenebilir Bileşenleri kaydedebilir.

pro. Componentsnasıl kullanıldıkları hakkında hiçbir şey bilmiyorlar. Düşük bağlantı. A. Biz yeni ekleyebilirsiniz GameSubsystem. Örneğin, tüm ComponentTitle'ı kaydeden GameSubsystemTitles'ı ekleyelim ve her başlığın benzersiz olduğunu garanti eden ve nesneleri sorguya göre başlığa arayüz sağlayan garanti edelim. Tabii ki, ComponentTitle bu durumda yeniden yazılmamalı veya devralınmamalıdır. B. Mevcut olanı yeniden düzenleyebiliriz GameSubsystems. Örneğin, GameSubsystemAudio, GameSubsystemRender, GameSubsystemParticleEmmiter, GameSubsystemSpatial ile birleştirilebilir (tüm sesleri, vericiyi yerleştirmek, Componentsaynı hiyerarşiye dönüştürmek ve üst göreli dönüşümleri kullanmak için).

con. Her kontrol. Çok verimsiz.

con. Subsystemshakkında bilmek Components.

2: Her biri belirli türleri Subsystemarar Components.

pro. İçinden daha iyi performans Approach 1.

con. Subsystemshala biliyorum Components.

3: Componentkendini kaydeder GameSubsystem(s). Derleme zamanında bir GameSubsystemRenderer olduğunu biliyoruz, bu yüzden ComponentImageRender'ın GameSubsystemRenderer :: register (ComponentRenderBase *) gibi bir şey çağıralım.

pro. Verim. Gerektiği gibi gereksiz kontroller yok Approach 1.

con. Componentskötü bir şekilde birleşti GameSubsystems.

4: Arabulucu deseni. GameState(içeren GameSubsystems) registerComponent (Component *) uygulayabilir.

pro. Componentsve GameSubystemsbirbirleri hakkında hiçbir şey bilmiyorlar.

con. C ++ 'da çirkin ve yavaş tipid anahtarı gibi görünecektir.

Sorular: Hangi yaklaşım daha iyidir ve çoğunlukla bileşen tabanlı tasarımda kullanılır? Uygulama Ne Diyor? Uygulanması hakkında herhangi bir öneriniz var Approach 4mı?

Teşekkür ederim.

c++ architecture component-based

— sağ üst
kaynak

Aşırı mühendislik kokusu alıyorum. Bileşenler kendilerini GameObject'e kaydeder. GameSubsystem bence bu, o zaman bir GameObject için eklenebilir sadece bileşenlerin bir listesi. Nasıl tanımlandığınızı, GameObjects ve Components'ın nasıl bir araya geldiği bir çeşit "sihirli" gibi görünüyor (birbirlerini arıyorlar? Neden?). Ayrıca, temel olarak motorunuzdaki her şey için bileşenleri de kullanmaya çalıştığınız hissini alıyorum, ki bu da yeniden düşüneceğim. Ne için değer ben sadece 3 veya 4 seçenekleri düşünün.

— LearnCocos2D

@GamingHorror, Kayıt Componentsolmak sorumun GameObjectskapsamı dışında. Bileşen tabanlı yaklaşım hakkındaki makaleleri okuyun veya ilgileniyorsanız bu sitede kendi sorunuzu sorun. Ne düşündüğün GameSubsystemtamamen yanlış.

— 20'de topright

Motor bileşenleri için değil, oyun mantığı için bileşenler geliştirmeye karşı önyargılıyım ve açıklamanız bu yöne işaret ediyor gibiydi. Bileşen sistemlerini çok iyi anlıyorum, sanırım ders dışı bırakıldım çünkü kullandığınız terminolojiye, özellikle GameSubsystem'a aşina değilim. Okuduğum kadarıyla, her şeyi (örn. Tüm motor) sadece bileşenlerden oluşturmaya çalışıyormuşsunuz gibi geldi .

— LearnCocos2D

Evet, "Bileşen tabanlı oyun nesneleri" ve "Bileşen odaklı programlama" farklı terimlerdir, kafa karıştırıcı olabilir. Önyargılı olmayın, "bilased" olsanız iyi olur: scottbilas.com/files/2002/gdc_san_jose/game_objects_slides.ppt

— topright

Kapı numarası 3 ... Bileşen kendini GameSubsystem (s) sistemlerine kaydediyor

Bileşen, bağlantıyı GameObject öğesinden soyutlamak için yerinde. Her nasılsa, bir yerlerde bir şeyin aslında alt sistemler ile etkileşime ihtiyacı vardır ve bu bileşen ve amacıdır.

Bağlantı bu durumda aslında kötü bir şey değildir.

Sisteminizde herhangi bir karmaşıklık olmasını bekliyorsanız, performans esasen bu durumda gereklidir , diğer seçeneklerin arama stili yaklaşımlarını karşılayamazsınız.

Son olarak, bir alt sistemin diğerine reaktif olması gerekiyorsa (oluşturucu, fizik, ses, bir şey olduğunda bir şeyler yapmalıdır) bileşenler, oyun nesnesi aracılığıyla bunu birbiriyle kolaylaştırabilir ve bu özel çapraz sistem bağlantı türünü bileşenler.

— burkulma
kaynak

Bu iyi. Ancak bileşenler GameSubsystems hakkında ne biliyor? Tüm alt sistemler tekil midir? Bu çirkin değil mi? ... Bağımlılık enjeksiyonu gibi başka bir çözüm düşünüyorum ... ama alt bileşen örneğini her bileşene ne zaman ve kim iletir?

— Dani

@Dani Components'ın doğrudan alt sistem örneğine erişmesi gerekmez, sadece kaydın yapılmasını isteyen bir mesaj göndermeleri gerekir, Alt Sistemin ne olduğunu bilmeleri gerekmez (ancak büyük olasılıkla) singleton olur mu? Çoğu durumda her alt sistem için yalnızca tek bir alt sistem örneğine ihtiyacınız olsa bile bu bir zorunluluk değildir.

— Pablo Ariel

@Pablo - katılıyorum.

— Rick