I'm in a situation where a player can be given the control of small parts of an entity (i.e. Left missile battery). Therefore I started implementing sub entities as follow.

Entities are Objects with 3 arrays:

  • pointers to components
  • pointers to sub entities
  • communication subscribers (temporary implementation)

Now when an entity is built it has a few components as you might expect and also I can attach sub entities which are handled with some dedicated code in the Entity and Component classes.

I noticed sub entities are sharing data in 3 parts:

  • position: the sub entities are using the parent's position and their own as an offset.
  • scrips: sub entities are draining ammo and energy from the parent.
  • physics: sub entities add weight to the parent

I made this to quickly go forward, but as I'm slowly fixing current implementations I wonder if this wasn't a mistake.

Is my current implementation something commonly done? Will this implementation put me in a corner?

I thought it might be a better thing to create some sort of SubEntityComponent where sub entities are attached and handled.

But before changing anything I wanted to seek the community's wisdom.

  • 3
    \$\begingroup\$ Game programming is very, very often a case of: if it works, don't fix it. If it doesn't cause bugs and it doesn't cause slow-downs, don't touch it. \$\endgroup\$
    – knight666
    Sep 11, 2012 at 9:05
  • \$\begingroup\$ I'm worried my implementation will result in a mess of interlinked entities, I feel it would be way simpler to maintain the inter entity relationships in one place. Therefore I'm asking if it would be a wise choice. Maybe event looking for a hint on how others (would) do this and why. \$\endgroup\$
    – Coyote
    Sep 11, 2012 at 11:24

2 Answers 2


We use a Child Component which has a list of templates to spawn when the owner of the child component is spawned. A template is a defined set of components that make up a given entity. So our AIs can have multiple weapon entities where each weapon entity has different components, effects, etc. The behaviors on the parent AI would then figure out which weapon to use based off other rules at runtime. If setup incorrectly this certainly can have un-needed complexity. I think it works out ok since we have specific standards and formatting to the data.

The children entities don't know about their parent and don't need too beyond a possible scene-graph based parenting relationship.

  • \$\begingroup\$ This sounds like a step towards the direction I was considering. How do you handle the comunication and sync between the entities? For example, when you entity moves, do your sub-entities move as well or do they already share the data with the parent? \$\endgroup\$
    – Coyote
    Sep 12, 2012 at 12:16
  • \$\begingroup\$ I should have added that child entities are automatically parented to their parent entity via their transformation component if they have one. That handles movement. Otherwise, they deal with events and processing like any other entity. \$\endgroup\$
    – dzeligman
    Sep 12, 2012 at 20:34

I'm no expert in entity system but your case seems unnecessary complicated. I will instinctively say that making sub-entities sounds like a mistake, using a wrong system to solve that problem.

Lets explore why...

Components for me are basic building blocks. If you need something to be damageable, you add DamageableComponent, if you need it to move you add MoveableComponent ... and so on. If you add sub-entities, the whole thing becomes unclear.. do sub-entities inherit components of parent? Would be logical on first thought, but then again if they are almost the same as parents, why have them divided into smaller parts at all with all that duplication going around? On the other hand, if they don't share parent's components, they are drastically changing what the parent entity is about, because how can it be "Damageable" if it has parts that are not "Damageable". I find it easy to look at them as basic building blocks, no smaller divisions.

I can propose 2 solutions:

  1. If you really need parts of entity to be controllable and it will be used often, not just as exception to the rule on a single object but as a system that will appear often in the game: Make a component that describes that the entity object has parts, like "PartsComponent". The component will contain data about various parts that entity has, their name and specifics that don't belong to parent entity. This will probably be more complex as you'll need to modify ControlComponent to manage parts also, or make a new component for that.

  2. if you need an exception just for few times: screw it, make a single component "LeftMissleBatteryControllable" and code directly dependent on the class :)

Again, I'm not expert by any means, just worked with entity systems in games, I'm open to suggestions and criticism :)

  • \$\begingroup\$ I cannot implement the weapons as just components without making a mess of exception cases, and duplicating code. Each weapon entity has components for input, for UI control and other systems, these weapons can be removed, and replaced by other non weapon things. When attached to a player the weapons request UI changes through a small and very simple component (used across all controllable entities) for example. I like this flexibility and I'm not ready to give-up the sub-entity architecture. I simply want to make sure my implementation is not a dead end in some cases. \$\endgroup\$
    – Coyote
    Sep 12, 2012 at 12:26
  • \$\begingroup\$ Currently the sub-entities are placed in code, but in the future I wanted to allow players to customize their vehicles. Then I will need something like a parts component which will hold information about available slots and such, but I don't really think that such a component should have a bunch of functions beyond the slots. I even think there should be one PartComponent per empty slot in an entity. \$\endgroup\$
    – Coyote
    Sep 12, 2012 at 12:31

You must log in to answer this question.

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