Organizzare un sistema di entità con gestori di componenti esterni?

Sto progettando un motore di gioco per un gioco sparatutto multiplayer 2D top-down, che voglio essere ragionevolmente riutilizzabile per altri giochi sparatutto top-down. Al momento sto pensando a come dovrebbe essere progettato qualcosa come un sistema di entità in esso. Per prima cosa ho pensato a questo:

Ho una classe chiamata EntityManager. Dovrebbe implementare un metodo chiamato Update e un altro chiamato Draw. Il motivo per cui ho separato Logic e Rendering è perché posso omettere il metodo Draw se eseguo un server autonomo.

EntityManager possiede un elenco di oggetti di tipo BaseEntity. Ogni entità possiede un elenco di componenti come EntityModel (la rappresentazione disegnabile di un'entità), EntityNetworkInterface ed EntityPhysicalBody.

EntityManager possiede anche un elenco di gestori componenti come EntityRenderManager, EntityNetworkManager ed EntityPhysicsManager. Ogni gestore componenti mantiene i riferimenti ai componenti entità. Esistono vari motivi per spostare questo codice fuori dalla propria classe dell'entità e farlo collettivamente. Ad esempio, sto usando una libreria di fisica esterna, Box2D, per il gioco. In Box2D, aggiungi prima i corpi e le forme a un mondo (di proprietà dell'EntityPhysicsManager in questo caso) e aggiungi i callback di collisione (che verrebbero inviati all'oggetto entità stesso nel mio sistema). Quindi esegui una funzione che simula tutto nel sistema. Trovo difficile trovare una soluzione migliore per farlo che farlo in un componente esterno come questo.

La creazione dell'entità avviene in questo modo: EntityManager implementa il metodo RegisterEntity (entityClass, factory) che registra come creare un'entità di quella classe. Implementa anche il metodo CreateEntity (entityClass) che restituirebbe un oggetto di tipo BaseEntity.

Ora arriva il mio problema: come verrebbe registrato il riferimento a un componente ai gestori componenti? Non ho idea di come farei riferimento ai gestori dei componenti da una fabbrica / chiusura.

I sistemi dovrebbero archiviare una coppia chiave-valore di Entity to Component in una sorta di mappa, oggetto dizionario o array associativo (a seconda della lingua utilizzata). Inoltre, quando crei il tuo Entity Object, non mi preoccuperei di memorizzarlo in un gestore a meno che non sia necessario essere in grado di annullare la registrazione da uno qualsiasi dei Sistemi. Un'entità è un composto di componenti, ma non dovrebbe gestire nessuno degli aggiornamenti dei componenti. Ciò dovrebbe essere gestito dai sistemi. Tratta invece la tua Entità come una chiave che è mappata a tutti i componenti che contiene nei sistemi, così come un hub di comunicazione per far dialogare tra loro quei componenti.

Il bello dei modelli Entity-Component-System è che puoi implementare abbastanza facilmente la capacità di passare i messaggi da un componente al resto dei componenti di un'entità. Ciò consente a un componente di parlare con un altro componente senza sapere chi sia quel componente o come gestirlo. Passa invece un messaggio e consente al componente di cambiare se stesso (se esiste)

Ad esempio, un sistema di posizione non contiene molto codice, ma tiene traccia degli oggetti Entity associati ai loro componenti di posizione. Ma quando una posizione cambia, possono inviare un messaggio all'entità interessata, che a sua volta viene trasmessa a tutti i componenti di tale entità. Una posizione cambia per qualsiasi motivo? Il sistema di posizione invia a Entity un messaggio che dice che la posizione è cambiata, e da qualche parte, il componente di rendering dell'immagine di quell'entità ottiene quel messaggio e si aggiorna dove verrà disegnato successivamente.

Al contrario, un sistema fisico deve sapere cosa stanno facendo tutti i suoi oggetti; Deve essere in grado di vedere tutti gli oggetti del mondo per testare le collisioni. Quando si verifica una collisione, aggiorna il componente di direzione dell'entità inviando una sorta di "Messaggio di cambio di direzione" all'entità invece di fare riferimento direttamente al componente dell'entità. Questo disaccoppia il manager dalla necessità di sapere come cambiare direzione usando un messaggio invece di fare affidamento su un componente specifico che si trova lì (che potrebbe non essere affatto lì, nel qual caso il messaggio cadrà solo per non udenti invece di un errore si verifica perché un oggetto previsto era assente).

Noterai un enorme vantaggio da questo poiché hai menzionato che hai un'interfaccia di rete. Un componente di rete ascolta tutti i messaggi in arrivo che tutti gli altri dovrebbero conoscere. Adora i pettegolezzi. Quindi, quando il Sistema di rete si aggiorna, i componenti di Rete inviano quei messaggi ad altri Sistemi di Rete su altri computer client, che quindi reinviano quei messaggi a tutti gli altri componenti per aggiornare le posizioni dei giocatori, ecc. Potrebbe essere necessaria una logica speciale in modo che solo determinate entità possano inviare messaggi attraverso la rete, ma questa è la bellezza del sistema, puoi semplicemente controllare la logica registrandoti le cose giuste.

In breve:

Entity è una composizione di componenti che possono ricevere messaggi. L'entità può ricevere messaggi, delegando tali messaggi a tutti i loro componenti per aggiornarli. (Posizione modificata Messaggio, Direzione cambio velocità, ecc.) È come una cassetta postale centrale che tutti i componenti possono ascoltare gli uni dagli altri invece di parlare direttamente tra loro.

Il componente è una piccola parte di un'entità che memorizza un certo stato dell'entità. Questi sono in grado di analizzare determinati messaggi e gettarne altri. Ad esempio, un "Componente di direzione" si occuperebbe solo di "Messaggi di cambio di direzione" ma non di "Messaggi di cambio di posizione". I componenti aggiornano il proprio stato in base ai messaggi, quindi aggiornano gli stati di altri componenti inviando messaggi dal proprio sistema.

Il sistema gestisce tutti i componenti di un determinato tipo ed è responsabile dell'aggiornamento di tali componenti per ciascun frame, nonché dell'invio di messaggi dai componenti che gestiscono alle entità a cui appartengono i componenti

I sistemi potrebbero essere in grado di aggiornare tutti i loro componenti in parallelo e archiviare tutti i messaggi mentre vanno. Quindi, quando l'esecuzione dei metodi di aggiornamento di tutti i sistemi è completa, si chiede a ciascun sistema di inviare i propri messaggi in un ordine specifico. I controlli prima possibile, seguiti da Fisica, seguiti da direzione, posizione, rendering, ecc. Importa in quale ordine vengono inviati poiché un Cambio di direzione fisica dovrebbe sempre pesare un cambio di direzione basato sul controllo.

Spero che sia di aiuto. È un inferno di un modello di progettazione, ma è ridicolmente potente se fatto bene.

Sto usando un sistema simile nel mio motore e il modo in cui l'ho fatto è che ogni Entità contiene un elenco di Componenti. Da EntityManager, posso interrogare ciascuna delle Entità e vedere quali contengono un determinato Componente. Esempio:

class Component
{
    private uint ID;
    // etc...
}

class Entity
{
    List<Component> Components;
    // etc...
    public bool Contains(Type type)
    {
        foreach(Component comp in Components)
        {
            if(typeof(comp) == type)
                return true;
        }
        return false;
    }
}

class EntityManager
{
    List<Entity> Entities;
    // etc...
    public List<Entity> GetEntitiesOfType(Type type)
    {
        List<Entity> results = new List<Entity>();
        foreach(Entity entity in Entities)
        {
            if(entity.Contains(type))
                results.Add(entity);
        }
        return results;
    }
}

Ovviamente questo non è il codice esatto (in realtà avresti bisogno di una funzione modello per verificare la presenza di diversi tipi di componenti, piuttosto che usare typeof) ma il concetto è lì. Quindi potresti prendere quei risultati, fare riferimento al componente che stai cercando e registrarlo con la tua fabbrica. Ciò impedisce qualsiasi accoppiamento diretto tra i componenti e i loro gestori.

1) Al tuo metodo Factory dovrebbe essere passato un riferimento a EntityManager che lo ha chiamato (userò C # come esempio):

delegate BaseEntity EntityFactory(EntityManager manager);

2) Chiedi a CreateEntity di ricevere anche un ID (ad es. Una stringa, un numero intero, dipende da te) oltre alla classe / al tipo di entità e registra automaticamente l'entità creata su un dizionario usando quell'id come chiave:

class EntityManager
{
    // Rest of class omitted

    BaseEntity CreateEntity(string id, Type entityClass)
    {
        BaseEntity entity = factories[entityClass](this);
        registry.Add(id, entity);
        return entity;
    }

    Dictionary<Id, BaseEntity> registry;
}

3) Aggiungi un Getter a EntityManager per ottenere qualsiasi entità per ID:

class EntityManager
{
    // Rest of class omitted

    BaseEntity GetEntity(string id)
    {
        return registry[id];
    }
}

E questo è tutto ciò che serve per fare riferimento a qualsiasi ComponentManager all'interno del metodo Factory. Per esempio:

BaseEntity CreateSomeSortOfEntity(EntityManager manager)
{
    // Create and configure entity
    BaseEntity entity = new BaseEntity();
    RenderComponent renderComponent = new RenderComponent();
    entity.AddComponent(renderComponent);

    // Get a reference to the render manager and register component
    RenderEntityManager renderer = manager.GetEntity("RenderEntityManager") as RenderEntityManager;
    if(renderer != null)
        renderer.Register(renderComponent)

    return entity;
}

Oltre a Id puoi anche usare una sorta di proprietà Type (un enum personalizzato, o semplicemente fare affidamento sul sistema dei tipi di linguaggio) e creare un getter che restituisca tutte le BaseEntities di un certo tipo.