I'm falling in love with simple grace of entity-component design, although I still have issues breaking from MVC and OOP practices. Some of my game entities have membership relationships with each other (ex: a player is a member of a city, a city is a member of a nation), and I am unsure on the best way to implement it.

My initial reaction is to have a a MemberOfCity component that points to the appropriate city component, but components are suppose to have no references to each other. My other option is to have a System do it, but that would require the system to persist data outside of a component.

Is there a clean way to do this in an entity-component design, or am I trying to use a hammer on a screw and should use a hybrid/another approach?

  • 1
    \$\begingroup\$ How are you going to use this membership information? How do you query your components? Try thinking in a mix of SQL and OOP: 'how do I get all components ("rows") that have given property ("field") value in a decoupled way?'. \$\endgroup\$
    – Den
    Apr 11, 2012 at 9:00
  • \$\begingroup\$ I plan on using my mini-engine for a minecraft plugin (can player place block here, can player a attack player b) and hopefully for my outerspace colony building game. I was thinking SQL for at least the former as the structure lends itself to a relational database. \$\endgroup\$
    – croxis
    Apr 12, 2012 at 2:15
  • \$\begingroup\$ Do you already have some implementation of your component system? Describing your existing architecture might make your question more answerable. \$\endgroup\$
    – Den
    Apr 12, 2012 at 16:18
  • \$\begingroup\$ I'm using the artemis framework in java. I haven't spent too much time on the components as I wasn't sure the best way to go forward. I also haven't found any good reading on how to structure components, just how to write a framework like artemis. \$\endgroup\$
    – croxis
    Apr 14, 2012 at 0:24

2 Answers 2


My interpretation of this comment by Adam Martin, discussing how to model an airplane in an entity system --

Since an entity is formally just “a name”, a component can refer to other entities easily.

Personally, I’d be tempted to have a separate “plane” entity that had a “PlaneParts” component that was just a list of the names of the other entities on the plane.

-- is that components should never reference other components, but components can reference entities.

So I see two ways to do this:

  1. The player entity (not the player component) has a 'citizenOf' component, which has a reference to the city entity (not the city component).
  2. The city entity (not the city component) has a 'citizens' component, which (cf. the first part of Boreal's answer) contains a list of player entities (not player components)

Which way you want to model it probably depends on which way is going to make it more efficient to access the data.

Note that in neither case (contra the second part of Boreal's answer) does any component know about any other component, nor does any component care what other components the related entities have.

This, IMO, is the major advantage of an entity system for designers -- if you decide on the fly that potatoes can be citizens, or potatoes can have citizens, there's nothing in the entity-component system to stop you from doing that.

(And yes, you're probably not going to do make potatoes citizens, but you might make NPCs citizens; and yes, you're probably not going to make a player a citizen of a potato, but you might make a player a citizen of a village, or a guild, or a city-less nomadic tribe.)


I'd do it the other way around: the city has a Population component that is a list of Person entities. Components should generally be linked if they are linked in definition.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .