# How would one store global context data in an entity component system?

My question is this:

How would one store global context data, ie. world data information, current world time, etc in an entity component system?

I'm think of working towards building a Dwarf Fortress-style open ended world simulation game in C++. I've build up an entity component style game engine just for fun, and I'm currently trying to figure out how I am going to work in all the features I want. In addition to standard game play (rendering, physics, entity-specific component data, etc), I would also like to have some global contextual data that all relevant systems would have access to (ie, the world data like what year it currently is, whether global warming is happening, Any kind of thing that would be relevant to simulating a world). I had originally thought of making a "world" component, but this seems pointless and difficult if a lot of different systems need access to this logically "global" data.

Would it make sense to have a "world" component or should I store this data some other way?

I'd also thought of simply making this data global, thus giving access to any systems that would want to use it; it seems like a violation of entity-component principles in general, and maybe messy for other reasons, but I thought that it might really work.

The other thing I'd thought of would be to actually embed relevant world-context data directly into the systems themselves. For example, if I had an AgeSystem that "aged" all entities that have a getsWeakerAsTimePasses component or whatnot, then maybe this system could store relevant time data for the world directly as member data that it would use to calculate the passage of time and how much to age and weaken people, etc. This third option was my least favorite, but something that had occurred to me in brainstorming.

• Rationale for downvotes is polite and useful to not only the OP, but other users. – MichaelHouse Aug 17 '13 at 2:01
• You have built a hammer and now everything looks like a nail. I give you permission to use more than just ECS to hold and manipulate data in your program because not everything is a nail. – Patrick Hughes Aug 17 '13 at 5:26

Any way that works is a way that works. That sounds snide, but really, your game is 1000x more important than your architecture. Pick any approach you like and find easy to use.

The ones I've seen in real shipping games (using component-based design, not ECS specifically; I've never seen pure ECS "in the wild", though many component designs have ECS-like elements to them) include:

• Singletons
• "Context" objects passed to components/systems that contain references to all relevant other systems
• Component factories that pass system handles to individual components
• Components which store references to systems in the root of an object hierarchy (only in some oddball Unity games)
• Singular "Engine" objects passed to systems or component which hold references to all other systems
• String-based resource lookup systems (allowing you in C++ to do something like handle<PhysicsSystem> = GetResource<PhysicsSystem>("/systems/physics"), yes, really)
• Piles of global data and C-style free functions that operate on them
• Spaces/subspaces and accompanying video

They all work. I have gripes with some approaches and an obvious favorite, but they've all been used to ship AAA games. Sometimes multiple approaches in a single project (40-100+ engineer teams tend to create haphazard duplicate code, alas).

• I'm curious to know which is your obvious favourite. – ashes999 Aug 18 '13 at 4:18
• The links I provided are to my slides and a video of me giving a talk on the topic, if that's any hint. :) – Sean Middleditch Aug 18 '13 at 17:42
• Ah, so your favourite is spaces/subspaces then. :) – ashes999 Aug 18 '13 at 22:21
• Great answer. I think I have something worked out, and I actually went ahead and incorporated the "spaces/subspaces" concept into my gameplan. – Awesomania Aug 19 '13 at 1:15