In un motore del sistema entità-componente, come gestisco i gruppi di entità dipendenti?


48

Dopo aver esaminato alcuni schemi di progettazione del gioco, mi accontento di Entity-Component-System (ES System) per il mio motore di gioco. Ho letto articoli (principalmente T = Machine ) e recensito del codice sorgente e penso di averne abbastanza per iniziare.

C'è solo un'idea di base con cui sto lottando. Come gestisco gruppi di entità dipendenti l'uno dall'altro?

Vorrei usare un esempio:

Supponiamo che stia realizzando uno sparatutto aereo standard (pensa Jamestown ) e voglio costruire una "entità boss" con più parti distinte ma connesse. La suddivisione potrebbe apparire come questa:

  • Corpo della nave: movimento, rendering
  • Cannone: Posizione (bloccato rispetto al corpo della Nave), Inseguimento \ Fuoco sull'eroe, Subisci danni fino a quando non viene disabilitato
  • Nucleo: Posizione (bloccato rispetto al corpo della Nave), Inseguimento \ Fuoco sull'eroe, Subire danni fino a quando disabilitato, Disabilitare (er ... distruggere) tutte le altre entità nel gruppo di navi

Il mio obiettivo sarebbe qualcosa che sarebbe identificato (e manipolato) come un elemento di gioco distinto senza dover riscrivere il sottosistema dal fondo ogni volta che voglio costruire un nuovo elemento aggregato.

Come posso implementare questo tipo di design in ES System?

  1. Implemento un qualche tipo di relazione tra entità genitore-figlio (le entità possono avere figli)? Questo sembra contraddire la metodologia secondo cui le Entità sono solo contenitori vuoti e la fanno sentire più OOP.
  2. Le implemento come entità separate, con un qualche tipo di componente di connessione (BossComponent) e sistema correlato (BossSubSystem)? Non posso fare a meno di pensare che questo sarà difficile da attuare poiché il modo in cui i componenti comunicano sembra essere una trappola per orsi.
  3. Devo implementarli come un'unica entità, con una raccolta di componenti (ShipComponent, CannonComponents, CoreComponent)? Questo sembra deviare l'intento del Sistema ES (i componenti qui sembrano troppo entità pesanti), ma lo so, quindi ho pensato che l'avrei messo lì.
  4. Li implemento come qualcos'altro che ho citato?

So che questo può essere implementato molto facilmente in OOP, ma la mia scelta di ES su OOP è quella su cui mi atterrò. Se dovessi rompere con la pura teoria ES per implementare questo progetto lo farò (non come se non avessi mai dovuto compromettere il design puro prima), ma preferirei farlo per motivi di prestazioni piuttosto che iniziare con un cattivo design.

Per ulteriore credito, pensa allo stesso design, ma ognuna delle "entità boss" era in realtà collegata a una "entità BigBoss" più grande composta da un corpo principale, core principale e 3 "Entità Boss". Questo mi farebbe vedere una soluzione per almeno 3 dimensioni (nonno-genitore-figlio) ... che dovrebbe essere più che sufficiente per me.


2
Si tratta semplicemente di diversi componenti mesh collegati a un'entità, mesh di navi e cannoni attaccati all'entità boss, non troppo ingegnosi. Tra un sistema di componenti di entità è OOP!
Maik Semder

2
Sì, il peggio di quegli articoli T-Machine è l'idea errata che questo non sia in qualche modo orientato agli oggetti. La maggior parte dei sistemi componenti per entità sono completamente orientati agli oggetti, ma non basati sull'ereditarietà.
Kylotan,

3
Penso che sottolineino la natura non OOP perché "pensare OOP classico" ti metterà così nei guai. Finora ho aiutato alcune persone a iniziare con i sistemi di entità e questo è il maggiore ostacolo. Cercare di inserire codice nei componenti, provare ad avere componenti che si sottoclassano a vicenda, ecc. È inizialmente un grosso problema, ma è bello vedere la luce accendersi quando l'idea viene finalmente colta.
PSpeed

@MaikSemder Ho ripulito i miei commenti e li ho spostati in chat
MichaelHouse

1
Solo così capisco @MaikSemder, nel sistema ES il tuo riferimento, un'entità può avere più componenti dello stesso tipo e il sottosistema responsabile di tali componenti dovrebbe occuparsi di quel fatto? Quindi un'entità può avere più componenti di rendering e quei dati e sottosistemi di tali componenti determinerebbero come renderli correttamente? Ciò porterebbe a un minor numero di entità, potenzialmente meno componenti ma una logica del sottosistema un po 'più profonda, corretta?
John Daniels,

Risposte:


42

Se mi trovassi in questa situazione, creerei ogni parte del capo come entità separata. Queste "entità secondarie" includerebbero qualche tipo di AttachmentPointo ParentEntitycomponente. Questo componente dovrebbe includere un riferimento all'entità capogruppo e uno scostamento dalla posizione principale. Quando si aggiorna la posizione, controllano la posizione principale e applicano l'offset per generare la propria posizione. Inoltre, potrebbe effettuare controlli per assicurarsi che l'entità padre esista ancora. Inoltre, è possibile avere un SubEntitycomponente che tiene traccia dell'esistenza di entità secondarie per l'entità padre. Ciò ti consente di fare cose come rendere vulnerabile il nucleo del boss solo quando le armi con gli scudi vengono distrutte.

Attualmente uso un TargetEntitycomponente nel mio gioco, che viene utilizzato per il monitoraggio della torretta e quando i goblin stanno per raccogliere una risorsa. Può controllare la posizione dell'entità target e modificarne il comportamento di conseguenza. Le entità che non hanno una posizione non vengono mai aggiunte come target, quindi non ci sono preoccupazioni. Tuttavia, quando si arriva ad essere più approfonditi, come controllare la salute dell'entità genitore o figlio, lo scudo, le riserve di energia o altro, è necessario assicurarsi che l'entità genitore o figlio abbia effettivamente il componente correlato.

Rendere ogni parte la propria entità mantiene la flessibilità della struttura entità / componente consentendo di aggiungere componenti aggiuntivi e diversi a ciascuna parte del capo. Ad esempio, una parte del boss potrebbe avere un componente pistola e un componente salute mentre un altro avrebbe un componente scudo e un componente salute.

Ho trovato un'altra discussione su questo argomento qui . In cui gli utenti stanno discutendo di aggiungere più componenti dello stesso tipo a un'entità (che mi sembra una cattiva idea). Sembra una conversazione utile, anche se non ho letto l'intera discussione.


Molte buone informazioni qui. Hai spiegato bene la soluzione, fammi un esempio e probabilmente rispondi a 1 o 2 altre domande che avrei dovuto tornare più tardi. Anche la discussione collegata sembra intrigante, specialmente quando inizio a una più difficile implementazione. Grazie @ Byte56!
John Daniels,

Nessun problema John! Naturalmente ci sono molti modi diversi per implementare un sistema CE. Il sistema che avevo in mente per questa risposta è quello che ho descritto in questa risposta . Buona fortuna con il tuo gioco!
MichaelHouse

Il tuo approccio è il più flessibile ed è consigliabile utilizzarlo in un motore di gioco generalista.
Coyote,

7

Senza conoscere troppi dettagli sui sistemi esistenti, il modo in cui lo modellerei (e in una certa misura nel mio sistema di entità) è quello di avere un componente come AttachedTo (parentEntity). A ciascuno dei bambini può quindi essere assegnato il componente AttachedTo (boss).

Il sistema di rendering (o qualsiasi altra cosa) quindi afferra le entità con componenti: Posizione, Attaccato, ecc. E forma le gerarchie appropriate.


Questa sembra essere la risposta del consenso. La prossima volta fornirò maggiori dettagli di implementazione affinché le persone possano mordicchiarsi. Grazie @PSpeed!
John Daniels,

4

Se si desidera che un'entità sia rappresentata solo da un ID, il contenimento delle entità può essere effettuato tramite un componente speciale. È possibile chiamarlo CompositeComponent e questo contiene un elenco di ID entità figlio e interfacce per aggiungere / rimuovere elementi secondari da tale elenco.

Ovviamente tutti i componenti che dipendono dalla posizione ecc. Dovranno lavorare con questo per posizionare correttamente l'entità. Come implementarlo dipenderà in qualche modo da come implementate il posizionamento attualmente.

A proposito, non esiste una "pura teoria dell'ES": la creazione di entità dai componenti è un approccio popolare, ma il metodo preciso non è ancora standardizzato.


Sì, dovrei imparare a non usare la parola "puro" in qualsiasi discussione di progettazione ... niente del genere. Il percorso ConpositeComponent sembra il consenso qui. Grazie @Kylotan!
John Daniels,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.