Ruolo di uno stato entità in un sistema basato su componenti?

8

I sistemi di entità basati su componenti sono di gran moda in questi giorni; tutti sembrano concordare che sono la strada da percorrere, ma nessuno ha davvero un'implementazione definitiva di un tale sistema. Mi chiedevo, che ruolo hanno le entità (camminare a sinistra, in piedi, saltare, ecc.) In una CBS? Si comportano come controller (ovvero gestiscono eventi e modificano gli attributi dell'entità in base a tali eventi)?

Che dire dei casi in cui uno stato richiederebbe, ad esempio, che l'entità entri in modalità no-clip? Lo stato, quando entra, dovrebbe forse impostare il componente Collision dell'entità su un puntatore null o qualcosa del genere? (Quindi, all'uscita, lo stato dovrebbe ripristinare il CollisionComponent dell'entità al suo stato precedente.)

Inoltre, immagino sia compito dello stato attuale cambiare lo stato dell'entità in qualcos'altro, giusto?

architecture component-based entity-system

— Paul Manta
fonte

5

Direi che non esiste una "implementazione definitiva" perché tutti i giochi hanno requisiti diversi e ogni decisione che prendi nella progettazione di un sistema ha il suo set di compromessi. Fai solo ciò che ha senso per te e assicurati di fare il refactoring quando le cose si sporcano.

— Tetrad,

L'anatra comunista era un po 'bassa ... haha

— deceleratedcaviar

9

Ho avuto l'impressione che in una progettazione basata su componenti le entità siano essenzialmente contenitori di componenti (con eventualmente qualche messaggio inserito). Visto da questa prospettiva, ciascun componente memorizzerebbe un po 'dello stato. Ad esempio, se i componenti del comportamento fantasma decidono che deve entrare nella modalità immateriale, invia anche un messaggio al componente di fisica dicendogli di abilitare il non-clip. Probabilmente manderebbe anche un messaggio ai componenti del modello fantasma dicendo di dare il via all'alfa.

— deft_code
fonte

2

Le macchine e i componenti di stato sono tecniche ortogonali. Puoi avere stati nei tuoi componenti o no, così come puoi avere stati in qualsiasi classe. Puoi fare in modo che un componente osservi (vedi Modello osservatore) e cambiare lo stato di un altro componente. Le macchine a stati hanno molti usi e l'implementazione dipenderà dalle tue esigenze.

Per il personaggio che il personaggio afferma di aver descritto (camminare, stare in piedi, saltare), ho visto implementazioni in cui tutti i vari componenti mantengono le proprie macchine a stati ... fisica, animazione, controlli, ai. I componenti dovrebbero avere una chiara autorità su quali altri componenti reagiscono e su quali componenti possono cambiare.

— Evan Rogers
fonte

2

Progetta componenti come strutture con solo dati, nessuna logica più complessa di getter e setter. Non creare dipendenze tra i componenti o finirai per perdere la maggior parte dei vantaggi di un sistema di entità.

Vedi un esempio di questo approccio (vicino alla visione di t-machine) qui: https://github.com/thelinuxlich/starwarrior_CSharp

E il motore stesso: https://github.com/thelinuxlich/artemis_CSharp

— thelinuxlich
fonte

Sono piuttosto in disaccordo con "nessuna logica più complessa di getter e setter", ma vengo dal quadro di riferimento di Unity in cui tutto è un componente. Penserei che i componenti dovrebbero essere in grado di gestirsi da soli.

— Tetrad,

1

È perché Unity non ha nulla come Sistemi collegati al gioco stesso, che elabora le entità i cui componenti compongono l'aspetto del sistema.

— thelinuxlich,