Esistono molti modi per rappresentare e implementare sistemi di componenti di entità, ma ecco una spiegazione di un modo. Tieni presente che non esiste una definizione concreta di architetture di entità / componente / sistema, quindi questa è solo un'implementazione.
Presenterò un'analogia per architetture di entità / componente / sistema che potrebbe aiutare. Pensiamo a un'entità come una chiave.
L'entità
Le chiavi hanno anche denti (blu scuro). I denti della nostra chiave di entità sono i componenti che lo compongono. Puoi distinguere le entità in base al loro ID, anche se hanno gli stessi denti. Quindi in cosa si inseriscono le chiavi? Serrature. Le serrature sono i nostri sistemi. Ad esempio, un sistema di movimento.
Il sistema
La serratura funziona solo se la nostra chiave ha i denti sia per la posizione che per la velocità. Questo sistema elabora solo entità che hanno una posizione e una velocità. Esistono diversi modi per impostare il modo in cui questi sistemi riconoscono quali entità elaborare, ma un modo è utilizzare a long. Ogni bit è riservato per un tipo di componente. Per il nostro esempio ipotizziamo un tipo a 4 bit anziché a 64 bit. La nostra entità di esempio avrebbe tutti i componenti disponibili. Quindi sarebbe la chiave 1111. Quindi, il sistema sta cercando qualsiasi entità che abbia un 11--. (Al -rappresentante non importa, perché al movimento non importa se c'è uno sprite o una salute). Può controllare un'entità con una semplice ANDoperazione. Quindi la nostra entità corrisponde se ((1111 & 1100) == 1100). Se ti perdessi, dai un'occhiata alle operazioni bit per bit .
Come puoi vedere, i sistemi hanno accesso a risorse esterne. Possono accedere al tempo, alla grafica, al suono e così via. Sono semplicemente piccoli processori che accettano una chiave alla volta ed elaborano i dati. Vedi che il sistema di movimento prende la velocità, il tempo delta e la posizione; quindi esegue alcuni calcoli e memorizza il risultato in posizione.
Le chiavi dell'entità sono davvero facili da generare. Puoi aggiungerli o rimuoverli a piacimento. All'entità non importa, è solo un modo per raggruppare e conservare i componenti. I componenti non hanno interdipendenza. Il più vicino in cui i componenti interagiscono tra loro è quando un sistema opera su di essi e utilizza i dati di uno per aggiornarne un altro, come nel nostro esempio di movimento.
Diamo un'occhiata a un altro sistema per aiutare a consolidare l'idea:
Questo è il nostro sistema di disegno. Cerca componenti corrispondenti 1-1-. Questa entità corrisponde perché: ((1111 & 1010) == 1010)Inoltre, puoi vedere che questo sistema genera informazioni sullo schermo, disegnando lo sprite dell'entità nella sua posizione.
OK, ancora uno. Diamo un'occhiata a un'altra entità e vediamo come potrebbe rientrare nel nostro esempio finora.
Come puoi vedere, a questa entità sono associati meno componenti. Guardando i componenti che ha, sembra che potrebbe essere un oggetto statico come una roccia. Ha solo una posizione e uno sprite. Non si muoverà e non sarà influenzato da alcun cambiamento di salute. Questa entità produrrebbe una chiave di 1010. Quindi quali sistemi operano su questa entità? Controlliamo:
Contro il nostro sistema di movimento:
((1010 & 1100) != 1100)No. Sembra che il sistema di movimento non si preoccupi di questa entità, perché non ha i componenti richiesti.
Contro il nostro sistema di disegno:
((1010 & 1010) == 1010)Ehi, è una partita. Questa entità sarà gestita dal sistema di disegno. Il sistema di disegno disegna lo sprite nella posizione definita.
Spero che tu possa vedere quanto sia facile ora aggiungere un altro sistema che possa prendere i nostri componenti e operare su di essi. Lasciami assicurarti di aver risposto alle tue domande:
Cosa succede se più sistemi devono accedere allo stesso componente? Dove dovrebbero vivere i dati?
In genere, i sistemi funzionano uno dopo l'altro. Elaborano tutte le entità che soddisfano i loro requisiti, quindi il sistema successivo fa lo stesso e così via. I dati convivono con l'entità. Non dovrebbe esserci nulla memorizzato nel sistema, è solo un blocco che viene attivato, la chiave è dove le informazioni rimangono e si sposta da un blocco all'altro.
Come sono costruite le entità? I sistemi sono intrinsecamente legati a un componente? Se voglio introdurre un nuovo componente, devo anche introdurre un nuovo sistema o modificarne uno esistente?
Le entità sono solo sacchi di componenti. Hanno un ID univoco e un elenco di componenti. I sistemi sono legati ai componenti solo nel modo sopra descritto. Puoi avere componenti senza sistemi che funzionano su di essi, ma è abbastanza inutile. Allo stesso modo puoi avere sistemi che cercano componenti che nessuna entità ha. È meno inutile, perché potrebbero solo essere in attesa di creare un'entità che corrisponda al loro blocco. Quindi, sì, se si introduce un nuovo componente, si vorrebbe creare un sistema che utilizza quel componente. Altrimenti stai solo aggiungendo i denti alla tua chiave per un lucchetto che non esiste.
Se la mia entità è solo un ID come posso sapere che la mia entità robot deve essere spostata o renderizzata e quindi modificata da un sistema?
Penso di rispondere a questo con l'idea di una longchiave che definisce i componenti contenuti in un'entità. Sai perché la chiave si adatta alla serratura.
Accidenti! Quello era un lungo post! (O almeno sembra così dal mio grande monitor.)