Come si archiviano i dati di contesto globale in un sistema di componenti di entità?

La mia domanda è questa:

Come si archiviano i dati di contesto globale, ad es. informazioni sui dati mondiali, ora mondiale attuale, ecc. in un sistema di componenti di entità?

Sto pensando di lavorare per costruire un gioco di simulazione mondiale aperto in stile Dwarf Fortress in C ++. Ho creato un motore di gioco in stile componente di entità solo per divertimento e attualmente sto cercando di capire come lavorerò con tutte le funzionalità che desidero. Oltre al gioco standard (rendering, fisica, dati dei componenti specifici dell'entità, ecc.), Vorrei anche avere alcuni dati contestuali globali a cui tutti i sistemi pertinenti avrebbero accesso (ovvero, i dati mondiali come l'anno in cui si trova attualmente , indipendentemente dal fatto che stia accadendo il riscaldamento globale, qualsiasi tipo di cosa rilevante per la simulazione di un mondo). Inizialmente avevo pensato di creare un componente "mondiale", ma questo sembra inutile e difficile se molti sistemi diversi hanno bisogno di accedere a questi dati logicamente "globali".

Avrebbe senso avere un componente "world" o dovrei archiviare questi dati in qualche altro modo?

Avevo anche pensato di rendere semplicemente globali questi dati, dando così accesso a tutti i sistemi che avrebbero voluto usarli; sembra una violazione dei principi della componente entità in generale, e forse disordinato per altri motivi, ma ho pensato che potesse davvero funzionare.

L'altra cosa a cui avevo pensato sarebbe stata quella di incorporare i dati rilevanti del contesto mondiale direttamente nei sistemi stessi. Ad esempio, se avessi un AgeSystem"invecchiato" di tutte le entità che hanno un getsWeakerAsTimePassescomponente o quant'altro, allora forse questo sistema potrebbe archiviare i dati temporali rilevanti per il mondo direttamente come dati membro che userebbe per calcolare il passare del tempo e quanto l'età e l'indebolimento delle persone, ecc. Questa terza opzione era la mia meno preferita, ma qualcosa che mi era venuto in mente durante il brainstorming.

Qualcuno può consigliare?

Ogni modo che funziona è un modo che funziona. Sembra stupido, ma in realtà il tuo gioco è 1000 volte più importante della tua architettura. Scegli qualsiasi approccio che ti piace e trova facile da usare.

Quelli che ho visto in giochi di spedizione reali (usando il design basato su componenti, non specificamente ECS; non ho mai visto ECS puro "in the wild", sebbene molti progetti di componenti abbiano elementi simili a ECS) includono:

• Singletons
• Oggetti "contestuali" passati a componenti / sistemi che contengono riferimenti a tutti gli altri sistemi rilevanti
• Fabbriche di componenti che passano gli handle di sistema ai singoli componenti
• Componenti che memorizzano i riferimenti ai sistemi nella radice di una gerarchia di oggetti (solo in alcuni giochi Unity dispari)
• Singoli oggetti "Engine" passati a sistemi o componenti che contengono riferimenti a tutti gli altri sistemi
• Sistemi di ricerca delle risorse basati su stringhe (che ti consentono in C ++ di fare qualcosa del tipo handle<PhysicsSystem> = GetResource<PhysicsSystem>("/systems/physics"), sì, davvero)
• Mucchi di dati globali e funzioni gratuite in stile C che operano su di essi
• Spazi / sottospazi e video di accompagnamento

Funzionano tutti. Ho dei problemi con alcuni approcci e un ovvio favorito, ma sono stati tutti usati per spedire giochi AAA. A volte approcci multipli in un singolo progetto (40-100 + team di ingegneri tendono a creare codice duplicato casuale, ahimè).