Qual è un livello appropriato di granularità per l'architettura basata su componenti?

Sto lavorando a un gioco con un'architettura basata su componenti. An Entitypossiede una serie di Componentistanze, ognuna delle quali ha una serie di Slotistanze con cui archiviare, inviare e ricevere valori. Funzioni di fabbrica come Playerproduzione di entità con i componenti richiesti e connessioni slot.

Sto cercando di determinare il miglior livello di granularità per i componenti. Ad esempio, in questo momento Position, Velocitye Accelerationsono tutti componenti separati, collegati in serie. Velocitye Accelerationpotrebbe essere facilmente riscritta in un'uniforme Deltacomponente, o Position, Velocitye Accelerationpotrebbero essere combinati insieme componenti come Frictione Gravityin un monolitico Physicscomponente.

Un componente dovrebbe avere la minima responsabilità possibile (a scapito di molte interconnessioni) o i componenti correlati dovrebbero essere combinati in elementi monolitici (a scapito della flessibilità)? Mi sto sporgendo verso il primo, ma potrei usare una seconda opinione.

C'è una linea tra la granularità completa, che non porta allo spreco di codice o allo stato simile a un BLOB (motivo per cui le architetture dei componenti sono preferite) e all'usabilità.

Ovviamente le cose possono avere un Position, ma non sono necessariamente dinamiche (quindi perché hanno Velocitye Acceleration?). Tuttavia, qualcosa con Velocitya sarà un oggetto in movimento, quindi ha senso anche Accelerationraggrupparsi.

Avete intenzione di avere un caso in cui v e una sta per essere necessario, ma non si vuole una simulazione fisica per loro? Allo stesso modo, ci sarà un punto Gravityse non sono oggetti di fisica?

tl; dr Raggruppa ciò che ha senso.

Per evitare di microgestire ogni singola variabile che suggerirei iniziando pesantemente, scegliere le divisioni attorno alla responsabilità e al rifattore quando la situazione si presenta logicamente. Puoi iniziare i primi disegni su carta. Ad un certo punto queste divisioni di responsabilità grossolane diventeranno i mattoni delle tue entità.

Quindi per un esempio affrettato hai Game. Il gioco si divide in Environment + State. L'ambiente si divide in StaticWorld + MovingStuff. Lo stato si divide in AIControlled + PlayerControlled. L'idea grossolana di danno si divide in TakesDamage + GivesDamage.

E così via.

Proprio come il consiglio comune di "Costruisci giochi, non motori!" per i nuovi praticanti raccomando "Costruisci giochi, non sistemi di elaborazione elaborati!" perché solo con l'esperienza personale di un gioco in esecuzione saprai se è richiesto un elaborato sistema di componenti nelle opere future.

La mia ipotesi sarebbe quella di combinare componenti che avranno molta interazione. Nel tuo caso, manterrei la posizione in un singolo componente e la velocità e l'accelerazione sarebbero tenute insieme in un componente fisico.

Ma dipende molto dalle caratteristiche del tuo gioco (a meno che tu non stia costruendo un framework senza un gioco specifico in mente).

Mi rendo conto che questa è una vecchia domanda, ma forse qualcuno troverà utile questa risposta.

Credo che Systemsti aiuterà meglio a capire come costruire componenti. Esistono sistemi nelle architetture in cui i componenti non contengono la propria logica, a parte semplici getter / setter e funzioni di supporto. I sistemi operano su entità che soddisfano i requisiti dei componenti. Questo è il motivo per cui è meglio separare i dati dei componenti tanto quanto ha senso che tali dati vengano elaborati senza gli altri dati.

Ad esempio, potresti avere una MovementSystemche aggiorna le sue Entità in Positionbase alla loro Velocity. Questo potrebbe essere per entità semplici nel gioco. Ma, per il giocatore e i nemici, potresti volere il movimento che ha in Accelerationcui viene elaborato AcceleratedMovementSystem. Ma per gli ostacoli potresti desiderare Friction. Il terreno potrebbe anche avere attrito, ma non avrà una componente di velocità. Ma che dire Gravity? Aggiungilo Player, Enemy e Obstacle e crealo GravitySystemper elaborarlo.

La linea di fondo è che più disaccoppiati vostro Componentssono, più estendibile l' Entitiessarà quando si utilizza Systems.

Modifica: ultima dichiarazione resa più chiara.

Modifica: Ok, ho lavorato sul mio sistema e sono arrivato a questa realizzazione. Un esempio di suddivisione di Posizione e Velocità è che la manipolazione della Velocità fa sì che la Posizione cambi con un Sistema di movimento. Di conseguenza, un "InputMovementSystem" non ha bisogno di una posizione per far muovere il giocatore dall'input dell'utente poiché il MovementSystem rileverà le modifiche in Velocity da applicare alla posizione. Certo, funzionerebbe comunque bene per metterli insieme, ma questo è un esempio del motivo per cui non è necessario.

Di recente ho letto un post sul blog che diceva qualcosa del genere:

"Se disponi di dati che possono essere raggruppati con 2 diversi componenti, è meglio creare un terzo componente con tali dati."