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

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.

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.

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.

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.