0
\$\begingroup\$

I have some count of weapons - pistol, shotgun, rifle. And I have one system which deals with all weapons, and another system which deals only with pistol. So I need to create both components "weapons" and "pistol", and I add them both to the entity - "Pistol". So now we have next components - "Weapons", "Pistol", "Rifle", "Shotgun", becase probably I will need to have separate system for different weapons in future. Then in the same reasons I create next Components - "Character", "Player", "Enemy", "Friend" (maybe more types of Enemies and Friends), "Ammo", "AmmoForPistol", "AmmoForRifle" ... And there are too much different components only for tagging different entities regarding to the types. How can I avoid this amount of Components?

\$\endgroup\$
9
  • \$\begingroup\$ Why not have the weapon component specify what type of weapon it is and what / how much ammo it has? \$\endgroup\$
    – Charanor
    Commented Jan 23, 2017 at 8:33
  • \$\begingroup\$ And then system which need to deal only with an entity - "Pistol" (or Shotgun ...), will have to work with all weapons-entity instead only one entity- "Pistol". Under "will have to work" I mean that an update cycle will have to go through all weapons on the level to find "Pistol". \$\endgroup\$
    – saxartom
    Commented Jan 23, 2017 at 12:27
  • \$\begingroup\$ What does the system that is specific to the pistol need to do different? i.e. what makes a system handling the general weapon component incapable of what is specific to a 'pistol entity'? As for your Character, Player etc component, you need to wonder whether these should be components itself in the first place, or whether the entities aren't simply a composite of already existing components (e.g. a player has a collider and an enemy too, so they are handled by the same system). Try to find the parts entities will have in common \$\endgroup\$
    – Athos vk
    Commented Jan 23, 2017 at 18:05
  • \$\begingroup\$ @Athosvk Pistol it is for example)) There will be something like grenade launcher. ) But thanks I understand your thought? so try to find out solution. \$\endgroup\$
    – saxartom
    Commented Jan 26, 2017 at 11:35
  • \$\begingroup\$ Something tells me that the foundations of your ECS design is a bit shaky. Characters, Players, Enemy, Friends, etc seem to me as they should be entities, not components. Same goes for Weapons and Pistols. \$\endgroup\$
    – Vaillancourt
    Commented Feb 1, 2017 at 1:44

2 Answers 2

1
\$\begingroup\$

There is really no harm in adding a single WeaponComponent which holds a TYPE attribute to describe whether it's a Pistol, Rifle, Shotgun, Knife, etc.

Nothing dictates however that you must store all WeaponComponent instances in the same list inside your WeaponSystem either. In fact, to avoid branching on specific use cases, it might be advantageous to store each WeaponComponent in a type-specific list and simply iterate over multiple lists as part of your update loop.

I also don't believe that Character and Player make sense to be represented as components.

In order to determine hostility vs friendly could simply be derived by checking whether the entity in question has a specific type of component, perhaps HostileComponent. The assumption here being that all entities are friendly unless that component exists.

There are plenty of ways to split / tag things through components without going overboard.

\$\endgroup\$
0
\$\begingroup\$

How can I avoid this amount of Components?

You can't.

ECS are made to decouple and specialize your game logic. You'll want your components to represent something specific. By doing so, you won't have a choice: you have many tiny components.

\$\endgroup\$
3
  • \$\begingroup\$ A component is meant to represent a cohesive junction of data for a specific feature. That doesn't imply that a component represents something so specific that you end up with hundreds or thousands of tiny components. As my answer points out, you have lots of choices with how you interact with components. A single component can represent multiple ideas that are shared and it becomes the responsibility of your systems to take advantage of programming paradigms to use those components efficiently and effectively without overburdening the user of such ECS frameworks. \$\endgroup\$
    – Naros
    Commented Feb 1, 2017 at 14:14
  • \$\begingroup\$ @Naros "[...] you have lots of choices with how you interact with components." There you go. It really depends on how you view your ECS, how you've built it. The main reason I see of using an ECS architecture is to not overburden components with what you don't need, keep them as lean as possible in order to maximize what you get from it. I guess making a good software with ECS is an art, though. \$\endgroup\$
    – Vaillancourt
    Commented Feb 1, 2017 at 14:21
  • \$\begingroup\$ @Naros I don't disagree with your answer, though :) \$\endgroup\$
    – Vaillancourt
    Commented Feb 1, 2017 at 14:22

You must log in to answer this question.

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