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\$
  • \$\begingroup\$ Why not have the weapon component specify what type of weapon it is and what / how much ammo it has? \$\endgroup\$ – Charanor Jan 23 '17 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 Jan 23 '17 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 Jan 23 '17 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 Jan 26 '17 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 Feb 1 '17 at 1:44
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\$
  • \$\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 Feb 1 '17 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 Feb 1 '17 at 14:21
  • \$\begingroup\$ @Naros I don't disagree with your answer, though :) \$\endgroup\$ – Vaillancourt Feb 1 '17 at 14:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.