Comment stocker des données de contexte global dans un système de composants d'entité?

Ma question est la suivante:

Comment stocker des données de contexte global, c.-à-d. informations sur les données mondiales, heure mondiale actuelle, etc. dans un système de composants d'entité?

Je pense à travailler à la construction d'un jeu de simulation de monde ouvert de style Dwarf Fortress en C ++. J'ai construit un moteur de jeu de style composant d'entité juste pour le plaisir, et j'essaie actuellement de comprendre comment je vais travailler dans toutes les fonctionnalités que je veux. En plus du jeu standard (rendu, physique, données de composants spécifiques à l'entité, etc.), j'aimerais également avoir des données contextuelles globales auxquelles tous les systèmes pertinents auraient accès (c.-à-d. Les données mondiales comme l'année en cours). , si le réchauffement climatique se produit, tout type de chose qui serait pertinent pour simuler un monde). J'avais à l'origine pensé à créer un composant "mondial", mais cela semble inutile et difficile si de nombreux systèmes différents ont besoin d'accéder à ces données logiquement "globales".

Serait-il sensé d'avoir un composant "mondial" ou devrais-je stocker ces données d'une autre manière?

J'avais aussi pensé à simplement rendre ces données globales, donnant ainsi accès à tous les systèmes qui voudraient les utiliser; cela semble être une violation des principes des composants d'entité en général, et peut-être désordonné pour d'autres raisons, mais j'ai pensé que cela pourrait vraiment fonctionner.

L'autre chose à laquelle j'aurais pensé serait d'intégrer des données pertinentes du contexte mondial directement dans les systèmes eux-mêmes. Par exemple, si j'avais une AgeSystementité qui "vieillissait" toutes les entités qui ont un getsWeakerAsTimePassescomposant ou autre, alors peut-être que ce système pourrait stocker des données temporelles pertinentes pour le monde directement en tant que données de membre qu'il utiliserait pour calculer le passage du temps et combien de vieillir et affaiblir les gens, etc. Cette troisième option était ma moins préférée, mais quelque chose qui m'était venu à l'esprit lors d'un brainstorming.

Quelqu'un peut-il me conseiller?

Toute façon qui fonctionne est une façon qui fonctionne. Cela semble sournois, mais vraiment, votre jeu est 1000 fois plus important que votre architecture. Choisissez n'importe quelle approche que vous aimez et trouvez facile à utiliser.

Ceux que j'ai vus dans de vrais jeux d'expédition (en utilisant une conception basée sur des composants, pas ECS spécifiquement; je n'ai jamais vu d'ECS pur "dans la nature", bien que de nombreuses conceptions de composants contiennent des éléments de type ECS):

• Singletons
• Objets "contextuels" transmis aux composants / systèmes contenant des références à tous les autres systèmes pertinents
• Usines de composants qui transmettent les poignées du système à des composants individuels
• Composants qui stockent des références à des systèmes à la racine d'une hiérarchie d'objets (uniquement dans certains jeux Oddball Unity)
• Objets "Engine" singuliers transmis aux systèmes ou composants qui contiennent des références à tous les autres systèmes
• Systèmes de recherche de ressources basés sur des chaînes (vous permettant en C ++ de faire quelque chose comme handle<PhysicsSystem> = GetResource<PhysicsSystem>("/systems/physics"), oui, vraiment)
• Des tas de données globales et des fonctions libres de style C qui les exploitent
• Espaces / sous-espaces et vidéo d'accompagnement

Ils fonctionnent tous. J'ai des problèmes avec certaines approches et un favori évident, mais elles ont toutes été utilisées pour expédier des jeux AAA. Parfois, plusieurs approches dans un même projet (40-100 + équipes d'ingénieurs ont tendance à créer un code en double au hasard, hélas).