Bileşen varlık sistemi - Güncellemeler ve çağrı siparişleri

Bileşenlerin her kareyi güncelleyebilmeleri (ve bu işlevselliği gerekmeyen bileşenlerin dışında bırakabilmeleri) için bir UpdateComponent bileşeni yapma fikrim var. MovableComponent(Hızı tutan) gibi diğer bileşenler IUpdatablesoyut sınıftan miras alır . Bu MovableComponentbir Update(gametime dt)yöntem ve bir işaretçi RegisterWithUpdater()veren başka bir yöntem uygulamak için zorlar . Birçok bileşen bunu yapabilir ve daha sonra kim veya ne olduklarına dikkat etmeden tüm yöntemlerini çağırabilir .UpdateComponentMovableComponentUpdateComponentUpdate(gametime dt)

Sorularım:

1. Bu normal veya herkes tarafından kullanılan bir şey gibi mi görünüyor? Bu konuda hiçbir şey bulamıyorum.
2. Konum değişikliği sonrasında fizik gibi bileşenlere nasıl bir emir verebilirim? Bu bile gerekli mi?
3. Her kareyi işlemesi gereken bileşenlerin aslında işlenmesini sağlamanın diğer yolları nelerdir?

DÜZENLEME
Ben varlık yöneticisine güncellenebilir türlerin bir listesini vermek nasıl düşüneceğim düşünüyorum. Daha sonra, bu türdeki TÜM bileşenler varlık başına yönetmek yerine güncellenebilir (yine de sistemimdeki dizinler).

Hala. Sorularım benim için geçerli. Bunun makul / normal olup olmadığını veya başkalarının ne yapmaya meyilli olduğunu bilmiyorum.

Ayrıca, Insomniac insanlar harika! /DÜZENLE

Önceki örnek için kaynayan kod:

class IUpdatable
{
public:
    virtual void Update(float dt) = 0;
protected:
    virtual void RegisterAsUpdatable() = 0;
};

class Component
{
    ...
};

class MovableComponent: public Component, public IUpdatable
{
public:
    ...
    virtual void Update(float dt);
private:
    ...
    virtual void RegisterWithUpdater();
};

class UpdateComponent: public Component
{
public:
    ...
    void UpdateAll();
    void RegisterUpdatable(Component* component);
    void RemoveUpdatable(Component* component);
private:
    ...
    std::set<Component*> updatables_;
};

Bileşen sisteminin birincil faydalarından biri, önbellek desenlerinden yararlanabilme yeteneğidir - iyi icache ve tahmin, aynı kodu tekrar tekrar çalıştırdığınız için, iyi dcache çünkü nesneleri homojen havuzlarda ayırabileceğiniz ve herhangi, sıcak kal.

Bileşenlerinizi yapılandırma şekliniz bu avantaj tamamen kaybolur ve aslında çok daha fazla sanal çağrı ve vesilelerle daha fazla nesne yaptığınız için miras tabanlı bir sistemle karşılaştırıldığında bir performans yükümlülüğü haline gelebilir.

Yapmanız gereken, tür başına havuzları saklamak ve güncellemeleri gerçekleştirmek için her türü bağımsız olarak yinelemek.

Bu normal veya herkes tarafından kullanılan bir şey gibi mi görünüyor? Bu konuda hiçbir şey bulamıyorum.

Büyük oyunlarda yaygın değildir, çünkü avantajlı değildir. Birçok oyunda yaygındır, ancak teknik olarak ilginç değildir, bu yüzden kimse bu konuda yazmaz.

Konum değişikliği sonrasında fizik gibi bileşenlere nasıl bir emir verebilirim? Bu bile gerekli mi?

C ++ gibi dillerde kod yürütmek için doğal bir yol vardır: ifadeleri bu sırayla yazın.

for (PhysicsComponent *c : physics_components)
    c->update(dt);
for (PositionComponent *c : position_components)
    c->update(dt);

Gerçekte, bu mantıklı değil çünkü sağlam bir fizik sistemi bu şekilde yapılandırılmamıştır - tek bir fizik nesnesini güncelleyemezsiniz. Bunun yerine, kod daha çok şöyle görünecektir:

physics_step();
for (PositionComponent *c : position_components)
    c->update(dt);
// Updates the position data from the physics data.

Bahsettiğin şey makul ve oldukça yaygın. Bu size biraz daha bilgi verebilir.

Bu yaklaşımları seviyorum:

• Hiyerarşinizi Geliştirin
• Varlık Sistemleri MMO'ların Geleceğidir Bölüm 5

Kısaca: Güncelleme davranışını bileşenler içinde tutmaktan kaçının. Bileşenler davranış değildir . Davranış (güncellemeler dahil) bazı tek örnekli alt sistemlerde uygulanabilir. Bu yaklaşım, birden çok bileşen için benzer davranışların toplu işlenmesine de yardımcı olabilir (belki bileşen verilerinde parallel_for veya SIMD talimatları kullanarak).

IUpdatable fikri ve Güncelleme (gametime dt) yöntemi biraz fazla kısıtlayıcı görünüyor ve ek bağımlılıklar getiriyor. Alt sistemler yaklaşımını kullanmıyorsanız iyi olabilir, ancak bunları kullanırsanız, IUpdatable yedekli bir hiyerarşi düzeyidir. Sonuçta, MovingSystem, bu bileşenleri içeren tüm varlıklar için Konum ve / veya Hız bileşenlerini doğrudan güncellemesi gerektiğini bilmelidir, bu nedenle bazı ara IUpdatable bileşenlerine gerek yoktur.

Ancak Güncellenebilir bileşeni, Konum ve / veya Hız bileşenlerine sahip olmalarına rağmen bazı varlıkları güncellemeyi atlamak için bir mekanizma olarak kullanabilirsiniz. Güncellenebilir bileşen, ayarlanabilen falseve her Güncelleştirilebilir farkında alt sisteme bu özel varlığın şu anda güncelleştirilmemesi gerektiğini bildiren bir bool bayrağı içerebilir (bu bağlamda, Dondurucu bileşen için daha uygun bir ad gibi görünmektedir).